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.koe...@amd.com>
*Sent:* March 23, 2022 11:25
*To:* Daniel Vetter <dan...@ffwll.ch>; Daniel Stone
<dan...@fooishbar.org>; Olsak, Marek <marek.ol...@amd.com>;
Grodzovsky, Andrey <andrey.grodzov...@amd.com>
*Cc:* Rob Clark <robdcl...@gmail.com>; Rob Clark
<robdcl...@chromium.org>; Sharma, Shashank <shashank.sha...@amd.com>;
Christian König <ckoenig.leichtzumer...@gmail.com>; Somalapuram,
Amaranath <amaranath.somalapu...@amd.com>; Abhinav Kumar
<quic_abhin...@quicinc.com>; dri-devel
<dri-de...@lists.freedesktop.org>; amd-gfx list
<amd-gfx@lists.freedesktop.org>; Deucher, Alexander
<alexander.deuc...@amd.com>; Shashank Sharma
<contactshashanksha...@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 <dan...@fooishbar.org> wrote:
>> Hi,
>>
>> On Mon, 21 Mar 2022 at 16:02, Rob Clark <robdcl...@gmail.com> wrote:
>>> On Mon, Mar 21, 2022 at 2:30 AM Christian König
>>> <christian.koe...@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
>
>
