Re: [PATCH 3/9] drm/amdgpu/gfx7: Return error code when compute ring tests fail

["Timur Kristóf" <timur.kristof@gmail.com>]

On 2026. július 15., szerda 11:50:30 közép-európai nyári idő Christian König 
wrote:
> On 7/15/26 10:02, Timur Kristóf wrote:
> > On 2026. július 14., kedd 22:41:33 közép-európai nyári idő Alex Deucher 
wrote:
> >> On Tue, Jul 14, 2026 at 4:14 PM Tvrtko Ursulin <tursulin@ursulin.net> 
wrote:
> >>> On 13/07/2026 13:58, Timur Kristóf wrote:
> ...
> 
> >>> I actually might like this because maybe it gets us closer to removing
> >>> the ring->sched.ready hack but what I am just not sure if the idea was
> >>> to allow driver to function with some non-functional rings after resume.
> >>> Under the premise that if they initialized during init, then after
> >>> resume they must too, or if they don't, it is a transient glitch. I
> >>> don't know.. I am being imaginative here thinking about silly driver
> >>> workarounds for weird hardware glitches. It is much more likely this was
> >>> just an oversight and it is completely fine to to error out.
> >>> 
> >>> I have to defer to Alex and Christian on this one.
> >> 
> >> The reason for not checking the errors was because compute queue
> >> failure was not seen as fatal.  There are a lot of compute queues
> >> (relative to other engines), so if something happened, it seemed
> >> better to just continue in a degraded mode with fewer compute queues
> >> than to fail to resume in general.
> > 
> > We had a conversation about a similar topic (it was about UVD), where Alex
> > said that in general we should prefer not to handle degraded functionality
> > in amdgpu. I think the same principle should apply here.
> 
> Yeah, well that's a rather problematic topic.
> 
> Ignore such errors leads to never fix them. But on the other hand if we
> handle that as fatal and UVD doesn't comes up after resume you end up with
> a black screen while otherwise UVD is just not working.

Yeah, that was exactly my point when we talked about it.

However, Alex convinced me that we shouldn't bother supporting these degraded 
use cases. After spending more time working on amdgpu, I think it would raise 
more problems than it solves if we allowed that.

> > 1. My main problem with handling degraded functionality here is that I
> > have
> > never seen any issue where just some compute queues fail to initialize
> > after boot or after suspend/resume. That means we can't meaningfully test
> > that scenario, so we can't trust any code we write to handle that either.
> We had a bunch of cases where some engine didn't worked in the past (UVD,
> VCE, Compute) either on initial load or after suspend/resume.
> 
> Especially there was a Compute issues that was really annoying because it
> only caused trouble after Mesa switched to using compute engines for
> VA-API. Before that we didn't even know that Compute rings sometimes don't
> properly come up again after a resume.

Fortunately now we have ring tests and ring IB tests which we execute on 
initialization to make sure the rings work.

> > 2. It would be very tedious to keep track of which queues didn't work in
> > the first place vs. which are those that don't work because of a bug in
> > the soft reset code. I consider the soft reset as failed if not all
> > queues work correctly.
> > 
> > Considering the above, I vote that we should just expect all queues to
> > work
> > correctly at initialization and after a recovery. What do you guys think?
> 
> Well it's basically choosing what is the lesser evil.

Agreed.