Am 13.01.24 um 15:02 schrieb Joshua Ashton:
We need to bump the karma of the drm_sched job in order for the context that we just recovered to get correct feedback that it is guilty of hanging.
Big NAK to that approach, the karma handling is completely deprecated.
When you want to signal execution errors please use the fence error code.
Without this feedback, the application may keep pushing through the soft recoveries, continually hanging the system with jobs that timeout.
Well, that is intentional behavior. Marek is voting for making soft recovered errors fatal as well while Michel is voting for better ignoring them.
I'm not really sure what to do. If you guys think that soft recovered hangs should be fatal as well then we can certainly do this.
Regards, Christian.
There is an accompanying Mesa/RADV patch here https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27050 to properly handle device loss state when VRAM is not lost.
With these, I was able to run Counter-Strike 2 and launch an application which can fault the GPU in a variety of ways, and still have Steam + Counter-Strike 2 + Gamescope (compositor) stay up and continue functioning on Steam Deck.
Signed-off-by: Joshua Ashton joshua@froggi.es
Cc: Friedrich Vock friedrich.vock@gmx.de Cc: Bas Nieuwenhuizen bas@basnieuwenhuizen.nl Cc: Christian König christian.koenig@amd.com Cc: André Almeida andrealmeid@igalia.com Cc: stable@vger.kernel.org
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c index 25209ce54552..e87cafb5b1c3 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c @@ -448,6 +448,8 @@ bool amdgpu_ring_soft_recovery(struct amdgpu_ring *ring, struct amdgpu_job *job) dma_fence_set_error(fence, -ENODATA); spin_unlock_irqrestore(fence->lock, flags);
- if (job->vm)
drm_sched_increase_karma(&job->base);