I can confirm this patch fixes the kernel crash I reported.
But as discussed with Christian, we should find the root cause.
On 10/6/23 14:11, Christian König wrote:
bo->tbo.resource can easily be NULL here.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2
are correctly handled there.
Cc: sta...@vger.kernel.org
Signed-off-by: Samuel Pitoiset
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu
-off-by: Samuel Pitoiset
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 143d11afe0e5..eff73c428b12 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
Added GF10.3 support.
I re-tested this on GFX9 and it still works, though on GFX10+ the trap
handler is never reached, is there something obviously wrong in this patch?
Thanks!
On 5/6/21 8:54 AM, Samuel Pitoiset wrote:
A trap handler can be used by userspace to catch shader exceptions
like
. At the moment, we don't know how to set them
via the CP, so they are only emitted if a VMID is reserved.
This introduces a new CS chunk that can be used to set the
TBA/TMA virtual address at submit time.
Signed-off-by: Samuel Pitoiset
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 31
On 8/28/20 10:23 AM, Christian König wrote:
Am 28.08.20 um 10:14 schrieb Samuel Pitoiset:
On 8/28/20 9:57 AM, Christian König wrote:
Am 25.08.20 um 16:07 schrieb Samuel Pitoiset:
A trap handler can be used by userspace to catch shader exceptions
like divide by zero, memory violations etc
On 8/28/20 10:23 AM, Christian König wrote:
Am 28.08.20 um 10:14 schrieb Samuel Pitoiset:
On 8/28/20 9:57 AM, Christian König wrote:
Am 25.08.20 um 16:07 schrieb Samuel Pitoiset:
A trap handler can be used by userspace to catch shader exceptions
like divide by zero, memory violations etc
On 8/28/20 9:57 AM, Christian König wrote:
Am 25.08.20 um 16:07 schrieb Samuel Pitoiset:
A trap handler can be used by userspace to catch shader exceptions
like divide by zero, memory violations etc.
On GFX6-GFX8, the registers used to configure TBA/TMA aren't
privileged and can be configured
)
Signed-off-by: Samuel Pitoiset
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 31
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.h | 4 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 4 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
On 8/24/20 11:32 PM, Alex Deucher wrote:
On Mon, Aug 24, 2020 at 2:33 PM Alex Deucher wrote:
On Mon, Aug 24, 2020 at 7:57 AM Samuel Pitoiset
wrote:
A trap handler can be used by userspace to catch shader exceptions
like divide by zero, memory violations etc.
On GFX6-GFX8, the registers
On 8/24/20 8:17 PM, Marek Olšák wrote:
SET_SH_REG won't work with CP register shadowing. You need to use
WRITE_DATA or WREG32.
You are right, will fix.
Marek
On Mon, Aug 24, 2020 at 7:57 AM Samuel Pitoiset
mailto:samuel.pitoi...@gmail.com>> wrote:
A trap handler can b
CS chunk that can be used to set the
TBA/TMA virtual address at submit time.
TODO:
- add GFX 6,7 and 10 support
- rebase on top of amd-staging-drm-next (this branch currently
hangs my GPU at boot)
Signed-off-by: Samuel Pitoiset
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 31
On 11/13/18 9:14 AM, Christian König wrote:
Am 12.11.18 um 22:45 schrieb Samuel Pitoiset:
On 11/12/18 6:16 PM, Alex Deucher wrote:
On Mon, Nov 12, 2018 at 12:09 PM Christian König
wrote:
We accidentially set the huge flag on the parent instead of the childs.
This caused some VM faults
On 11/12/18 6:16 PM, Alex Deucher wrote:
On Mon, Nov 12, 2018 at 12:09 PM Christian König
wrote:
We accidentially set the huge flag on the parent instead of the childs.
This caused some VM faults under memory pressure.
Signed-off-by: Christian König
Yes, this fixes GPU hangs with F12017
,
Christian.
Am 08.11.18 um 17:17 schrieb Samuel Pitoiset:
Hi,
This change introduces GPU hangs with F1 2017 and Rise of Tomb Raider
on RADV/GFX9. I bisected the issue.
Can you have a look?
Thanks!
On 9/12/18 10:54 AM, Christian König wrote:
This optimizes the generating of PTEs by walking
Hi,
This change introduces GPU hangs with F1 2017 and Rise of Tomb Raider on
RADV/GFX9. I bisected the issue.
Can you have a look?
Thanks!
On 9/12/18 10:54 AM, Christian König wrote:
This optimizes the generating of PTEs by walking the hierarchy only once
for a range and making changes as
Similar to other error messages, might help for tracking down
issues.
Signed-off-by: Samuel Pitoiset
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
Hi there,
I found a performance regression that affects my Vega10 with Dawn Of War
III and RADV (ie. 74FPS -> 71FPS). I bisected to:
commit ea7f492b6ac6eced0d09ccb2b0a2909a0025e22e
Author: Evan Quan
Date: Mon Jul 16 17:23:19 2018 +0800
drm/amd/powerplay: correct the argument for
On 10/31/2017 04:40 PM, Andrey Grodzovsky wrote:
Signed-off-by: Andrey Grodzovsky
---
configure.ac | 2 +-
src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
On 07/20/2017 04:20 AM, zhoucm1 wrote:
On 2017年07月19日 23:34, Marek Olšák wrote:
On Jul 19, 2017 3:36 AM, "zhoucm1" > wrote:
On 2017年07月19日 04:08, Marek Olšák wrote:
From: Marek Olšák
This exposes amdgpu_query_sensor_info().
v2: - add amdgpu_query_sensor_info() to the symbols list
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
amdgpu/amdgpu-symbol-check | 1 +
amdgpu/amdgpu.h| 18 ++
amdgpu/amdgpu_gpu_info.c
+02:00 Samuel Pitoiset <samuel.pitoi...@gmail.com>:
This exposes amdgpu_query_sensor_info().
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
amdgpu/amdgpu.h | 18 ++
amdgpu/amdgpu_gpu_info.c | 15 +++
2 files changed, 33 insertions(+)
This exposes amdgpu_query_sensor_info().
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
amdgpu/amdgpu.h | 18 ++
amdgpu/amdgpu_gpu_info.c | 15 +++
2 files changed, 33 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
On 04/03/2017 10:27 AM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Changes include: PRT and preemption flags, sensor info, and some more
changes for Vega10.
Cool, thanks. I will be able to re-send the sensor info series for mesa. :)
Generated using make
On 03/24/2017 05:33 PM, Marek Olšák wrote:
Hi,
I'm sharing this idea here, because it's something that has been
decreasing our performance a lot recently, for example:
http://openbenchmarking.org/prospect/1703011-RI-RADEONDIR06/7b7668cfc109d1c3dc27e871c8aea71ca13f23fa
I think the problem
- fix amdgpu_dpm check
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 75 +
include/uapi/drm/amdgpu_drm.h | 20 +
3 files chang
On 02/15/2017 08:15 PM, Samuel Pitoiset wrote:
This includes shader/memory clocks, temperature, GPU load, etc.
v2: - add sub-queries for AMDPGU_INFO_GPU_SENSOR_*
- do not break the ABI
v3: - return -ENOENT when amdgpu_dpm == 0
- expose more sensor queries
Signed-off-by: Samuel
ed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 6f021e70f15f..d63c44383660 100644
--- a/dri
On 02/15/2017 04:01 PM, Tom St Denis wrote:
On 14/02/17 09:56 PM, Deucher, Alexander wrote:
-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net]
Sent: Tuesday, February 14, 2017 9:52 PM
To: Deucher, Alexander; 'Samuel Pitoiset'; StDenis, Tom
Cc: amd-gfx
On 02/14/2017 06:01 PM, Deucher, Alexander wrote:
-Original Message-
From: StDenis, Tom
Sent: Tuesday, February 14, 2017 11:58 AM
To: Deucher, Alexander; 'Samuel Pitoiset'; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: expose amdgpu_sensors on pre-
powerplay chips
On 02/14/2017 05:41 PM, Tom St Denis wrote:
On 14/02/17 10:08 AM, Samuel Pitoiset wrote:
Totally untested but as long as read_sensor() has been recently
implemented for dpm based boards, amdgpu_sensors can now be
exposed.
v2: - make sure read_sensor is not NULL on dpm chips
- keep sanity
On 02/14/2017 01:01 AM, Samuel Pitoiset wrote:
The clocks are returned in Mhz and the temperature in millidegrees.
v2: - add sub-queries for AMDPGU_INFO_GPU_SENSOR_*
- do not break the ABI
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
drivers/gpu/drm/amd/
Totally untested but as long as read_sensor() has been recently
implemented for dpm based boards, amdgpu_sensors can now be
exposed.
v2: - make sure read_sensor is not NULL on dpm chips
- keep sanity check for powerplay chips
Cc: Tom St Denis <tom.stde...@amd.com>
Signed-off-by:
On 02/14/2017 03:04 PM, Tom St Denis wrote:
On 13/02/17 07:23 PM, Samuel Pitoiset wrote:
Totally untested but as long as read_sensor() has been recently
implemented for dpm based boards, amdgpu_sensors can now be
exposed.
Cc: Tom St Denis <tom.stde...@amd.com>
Signed-off-by: Samuel Pi
On 02/14/2017 10:18 AM, Nicolai Hähnle wrote:
Hi all,
based on my current theory on how a deadlock could happen in the
buffer allocation code, these two patches should fix the deadlock
without having a use-after-free.
I'm still working on a way to clean up the ttm_bo_init sequence
overall,
On 02/14/2017 10:18 AM, Nicolai Hähnle wrote:
Hi all,
based on my current theory on how a deadlock could happen in the
buffer allocation code, these two patches should fix the deadlock
without having a use-after-free.
I'm still working on a way to clean up the ttm_bo_init sequence
overall,
Totally untested but as long as read_sensor() has been recently
implemented for dpm based boards, amdgpu_sensors can now be
exposed.
Cc: Tom St Denis <tom.stde...@amd.com>
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 +
On 02/14/2017 12:46 AM, Tom St Denis wrote:
On 02/13/2017 06:40 PM, Samuel Pitoiset wrote:
On 02/14/2017 12:17 AM, Tom St Denis wrote:
Hi Samuel,
Hi Tom,
It would be helpful to modify amdgpu_debugfs_sensor_read() to support
dpm based sensors as well. This will let me add it to umr
Add the GPU temperature, the shader clock and eventually the
memory clock (as well as the GPU load on CI). The main goal is
to expose this info to the userspace like Radeon.
v2: - add AMDGPU_PP_SENSOR_GPU_LOAD on CI
- update the commit description
Signed-off-by: Samuel Pitoiset <samuel.pi
The clocks are returned in Mhz and the temperature in millidegrees.
v2: - add sub-queries for AMDPGU_INFO_GPU_SENSOR_*
- do not break the ABI
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
drivers/gpu/drm/amd/
patch yes.
If you can swing that in here that would be helpful if not I can submit
my own patch when this lands.
Cheers,
Tom
On 02/13/2017 05:01 PM, Samuel Pitoiset wrote:
Currently, only the GPU temperature, the shader clock and
eventually the memory clock are implemented. The main goal
On 02/13/2017 07:58 PM, Nicolai Hähnle wrote:
On 13.02.2017 19:38, Samuel Pitoiset wrote:
On 02/13/2017 07:09 PM, Nicolai Hähnle wrote:
On 13.02.2017 19:04, Nicolai Hähnle wrote:
On 13.02.2017 18:49, Samuel Pitoiset wrote:
On 02/13/2017 05:25 PM, Nicolai Hähnle wrote:
On 09.02.2017 11
The clocks are returned in Mhz and the temperature in millidegrees.
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 27 +++
include/uapi/drm/amdgpu
the read_sensor() interface for
pre-powerplay chips. The rest of the series is quite simple.
This has only been tested on Polaris (RX480).
Please review!
Thanks.
Samuel Pitoiset (2):
drm/amdgpu: implement read_sensor() for pre-powerplay chips
drm/amdgpu: expose the current temperature
Currently, only the GPU temperature, the shader clock and
eventually the memory clock are implemented. The main goal
is to expose this info to the userspace like Radeon.
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h | 4 +++-
drive
On 02/13/2017 07:41 PM, Christian König wrote:
Am 13.02.2017 um 19:32 schrieb Samuel Pitoiset:
On 02/13/2017 07:19 PM, Nicolai Hähnle wrote:
On 13.02.2017 19:11, Samuel Pitoiset wrote:
On 02/13/2017 07:04 PM, Nicolai Hähnle wrote:
On 13.02.2017 18:49, Samuel Pitoiset wrote:
On 02/13
On 02/13/2017 07:09 PM, Nicolai Hähnle wrote:
On 13.02.2017 19:04, Nicolai Hähnle wrote:
On 13.02.2017 18:49, Samuel Pitoiset wrote:
On 02/13/2017 05:25 PM, Nicolai Hähnle wrote:
On 09.02.2017 11:33, Samuel Pitoiset wrote:
When ttm_bo_init() fails, the reservation mutex should
On 02/13/2017 07:19 PM, Nicolai Hähnle wrote:
On 13.02.2017 19:11, Samuel Pitoiset wrote:
On 02/13/2017 07:04 PM, Nicolai Hähnle wrote:
On 13.02.2017 18:49, Samuel Pitoiset wrote:
On 02/13/2017 05:25 PM, Nicolai Hähnle wrote:
On 09.02.2017 11:33, Samuel Pitoiset wrote:
When
On 02/13/2017 07:04 PM, Nicolai Hähnle wrote:
On 13.02.2017 18:49, Samuel Pitoiset wrote:
On 02/13/2017 05:25 PM, Nicolai Hähnle wrote:
On 09.02.2017 11:33, Samuel Pitoiset wrote:
When ttm_bo_init() fails, the reservation mutex should be unlocked.
In debug build, the kernel reported
On 02/13/2017 06:49 PM, Samuel Pitoiset wrote:
On 02/13/2017 05:25 PM, Nicolai Hähnle wrote:
On 09.02.2017 11:33, Samuel Pitoiset wrote:
When ttm_bo_init() fails, the reservation mutex should be unlocked.
In debug build, the kernel reported "possible recursive locking
det
On 02/13/2017 05:28 PM, Nicolai Hähnle wrote:
On 09.02.2017 11:33, Samuel Pitoiset wrote:
Like ttm_bo_validate(), ttm_bo_init() might need to move BO and
the number of bytes moved by TTM should be reported. This can help
the throttle buffer migration mechanism to make a better decision.
Hmm
On 02/10/2017 11:37 AM, Christian König wrote:
Am 10.02.2017 um 11:22 schrieb Samuel Pitoiset:
On 02/10/2017 11:19 AM, Christian König wrote:
Am 10.02.2017 um 11:11 schrieb Samuel Pitoiset:
On 02/10/2017 03:55 AM, zhoucm1 wrote:
On 2017年02月10日 06:28, Samuel Pitoiset wrote:
Move
On 02/10/2017 11:19 AM, Christian König wrote:
Am 10.02.2017 um 11:11 schrieb Samuel Pitoiset:
On 02/10/2017 03:55 AM, zhoucm1 wrote:
On 2017年02月10日 06:28, Samuel Pitoiset wrote:
Move amdgpu_bo_unreserve() outside of the switch. While we are
at it, add a missing break in the default
take the BO as parameter, how can this happen?
Regards,
Christian.
Am 09.02.2017 um 23:28 schrieb Samuel Pitoiset:
Move amdgpu_bo_unreserve() outside of the switch. While we are
at it, add a missing break in the default case.
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.
On 02/10/2017 03:55 AM, zhoucm1 wrote:
On 2017年02月10日 06:28, Samuel Pitoiset wrote:
Move amdgpu_bo_unreserve() outside of the switch. While we are
at it, add a missing break in the default case.
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
drivers/gpu/drm/amd/
Move amdgpu_bo_unreserve() outside of the switch. While we are
at it, add a missing break in the default case.
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/d
This removes code duplication.
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu
Like ttm_bo_validate(), ttm_bo_init() might need to move BO and
the number of bytes moved by TTM should be reported. This can help
the throttle buffer migration mechanism to make a better decision.
v2: fix computation
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
drive
ty recently.
v2: only release the mutex if resv is NULL
Fixes: 12a852219583 ("drm/amdgpu: improve AMDGPU_GEM_CREATE_VRAM_CLEARED
handling (v2)")
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 -
1 file changed, 4 insertio
On 02/09/2017 01:58 AM, Michel Dänzer wrote:
On 09/02/17 08:35 AM, Samuel Pitoiset wrote:
Like ttm_bo_validate(), ttm_bo_init() might need to move BO and
the number of bytes moved by TTM should be reported. This can help
the throttle buffer migration mechanism to make a better decision
recently.
Fixes: "drm/amdgpu: improve AMDGPU_GEM_CREATE_VRAM_CLEARED handling (v2)"
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
Here's the report: https://hastebin.com/durodivoma.xml
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +++-
1 file changed, 3 insertions(+
Like ttm_bo_validate(), ttm_bo_init() might need to move BO and
the number of bytes moved by TTM should be reported. This can help
the throttle buffer migration mechanism to make a better decision.
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
drivers/gpu/drm/amd/amdgpu/am
Thanks for fixing this Michel.
Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
On 01/31/2017 07:54 AM, Michel Dänzer wrote:
From: Michel Dänzer <michel.daen...@amd.com>
The kernel driver reports correct values now.
Signed-off-by: Michel Dänzer <michel.daen...@am
63 matches
Mail list logo