Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event

["Christian König" <christian.koenig@amd.com>]

[-- Attachment #1: Type: text/plain, Size: 5393 bytes --]

My main question is what does the iris driver better than radeonsi when 
the client doesn't support the robustness extension?

 From Daniels description it sounds like they have at least a partial 
recovery mechanism in place.

Apart from that I completely agree to what you said below.

Christian.

Am 26.03.22 um 01:53 schrieb Olsak, Marek:
>
> [AMD Official Use Only]
>
>
> amdgpu has 2 resets: soft reset and hard reset.
>
> The soft reset is able to recover from an infinite loop and even some 
> GPU hangs due to bad shaders or bad states. The soft reset uses a 
> signal that kills all currently-running shaders of a certain process 
> (VM context), which unblocks the graphics pipeline, so draws and 
> command buffers finish but are not correctly. This can then cause a 
> hard hang if the shader was supposed to signal work completion through 
> a shader store instruction and a non-shader consumer is waiting for it 
> (skipping the store instruction by killing the shader won't signal the 
> work, and thus the consumer will be stuck, requiring a hard reset).
>
> The hard reset can recover from other hangs, which is great, but it 
> may use a PCI reset, which erases VRAM on dGPUs. APUs don't lose 
> memory contents, but we should assume that any process that had 
> running jobs on the GPU during a GPU reset has its memory resources in 
> an inconsistent state, and thus following command buffers can cause 
> another GPU hang. The shader store example above is enough to cause 
> another hard hang due to incorrect content in memory resources, which 
> can contain synchronization primitives that are used internally by the 
> hardware.
>
> Asking the driver to replay a command buffer that caused a hang is a 
> sure way to hang it again. Unrelated processes can be affected due to 
> lost VRAM or the misfortune of using the GPU while the GPU hang 
> occurred. The window system should recreate GPU resources and redraw 
> everything without affecting applications. If apps use GL, they should 
> do the same. Processes that can't recover by redrawing content can be 
> terminated or left alone, but they shouldn't be allowed to submit work 
> to the GPU anymore.
>
> dEQP only exercises the soft reset. I think WebGL is only able to 
> trigger a soft reset at this point, but Vulkan can also trigger a hard 
> reset.
>
> Marek
> ------------------------------------------------------------------------
> *From:* Koenig, Christian <Christian.Koenig@amd.com>
> *Sent:* March 23, 2022 11:25
> *To:* Daniel Vetter <daniel@ffwll.ch>; Daniel Stone 
> <daniel@fooishbar.org>; Olsak, Marek <Marek.Olsak@amd.com>; 
> Grodzovsky, Andrey <Andrey.Grodzovsky@amd.com>
> *Cc:* Rob Clark <robdclark@gmail.com>; Rob Clark 
> <robdclark@chromium.org>; Sharma, Shashank <Shashank.Sharma@amd.com>; 
> Christian König <ckoenig.leichtzumerken@gmail.com>; Somalapuram, 
> Amaranath <Amaranath.Somalapuram@amd.com>; Abhinav Kumar 
> <quic_abhinavk@quicinc.com>; dri-devel 
> <dri-devel@lists.freedesktop.org>; amd-gfx list 
> <amd-gfx@lists.freedesktop.org>; Deucher, Alexander 
> <Alexander.Deucher@amd.com>; Shashank Sharma 
> <contactshashanksharma@gmail.com>
> *Subject:* Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
> [Adding Marek and Andrey as well]
>
> Am 23.03.22 um 16:14 schrieb Daniel Vetter:
> > On Wed, 23 Mar 2022 at 15:07, Daniel Stone <daniel@fooishbar.org> wrote:
> >> Hi,
> >>
> >> On Mon, 21 Mar 2022 at 16:02, Rob Clark <robdclark@gmail.com> wrote:
> >>> On Mon, Mar 21, 2022 at 2:30 AM Christian König
> >>> <christian.koenig@amd.com> wrote:
> >>>> Well you can, it just means that their contexts are lost as well.
> >>> Which is rather inconvenient when deqp-egl reset tests, for example,
> >>> take down your compositor ;-)
> >> Yeah. Or anything WebGL.
> >>
> >> System-wide collateral damage is definitely a non-starter. If that
> >> means that the userspace driver has to do what iris does and ensure
> >> everything's recreated and resubmitted, that works too, just as long
> >> as the response to 'my adblocker didn't detect a crypto miner ad'  is
> >> something better than 'shoot the entire user session'.
> > Not sure where that idea came from, I thought at least I made it clear
> > that legacy gl _has_ to recover. It's only vk and arb_robustness gl
> > which should die without recovery attempt.
> >
> > The entire discussion here is who should be responsible for replay and
> > at least if you can decide the uapi, then punting that entirely to
> > userspace is a good approach.
>
> Yes, completely agree. We have the approach of re-submitting things in
> the kernel and that failed quite miserable.
>
> In other words currently a GPU reset has something like a 99% chance to
> get down your whole desktop.
>
> Daniel can you briefly explain what exactly iris does when a lost
> context is detected without gl robustness?
>
> It sounds like you guys got that working quite well.
>
> Thanks,
> Christian.
>
> >
> > Ofc it'd be nice if the collateral damage is limited, i.e. requests
> > not currently on the gpu, or on different engines and all that
> > shouldn't be nuked, if possible.
> >
> > Also ofc since msm uapi is that the kernel tries to recover there's
> > not much we can do there, contexts cannot be shot. But still trying to
> > replay them as much as possible feels a bit like overkill.
> > -Daniel
> >
> >> Cheers,
> >> Daniel
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 11493 bytes --]