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 <[email protected]> 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. > 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. > 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. Regards, Christian. > > Thanks & best regards, > Timur > > > > >
