<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
My main question is what does the iris driver better than radeonsi
when the client doesn't support the robustness extension?<br>
<br>
From Daniels description it sounds like they have at least a partial
recovery mechanism in place.<br>
<br>
Apart from that I completely agree to what you said below.<br>
<br>
Christian.<br>
<br>
<div class="moz-cite-prefix">Am 26.03.22 um 01:53 schrieb Olsak,
Marek:<br>
</div>
<blockquote type="cite" cite="mid:DM6PR12MB473154C6C678EA97C03979A4F91B9@DM6PR12MB4731.namprd12.prod.outlook.com">
<style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
<p style="font-family:Arial;font-size:10pt;color:#0000FF;margin:5pt;" align="Left">
[AMD Official Use Only]<br>
</p>
<br>
<div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
amdgpu has 2 resets: soft reset and hard reset.<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
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).<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<span style="font-size:12pt">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.</span><br>
<span style="font-size:12pt"></span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<span style="font-size:12pt">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.</span><br>
<span style="font-size:12pt"></span><br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
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.<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
Marek<br>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b>
Koenig, Christian <a class="moz-txt-link-rfc2396E" href="mailto:Christian.Koenig@amd.com"><Christian.Koenig@amd.com></a><br>
<b>Sent:</b> March 23, 2022 11:25<br>
<b>To:</b> Daniel Vetter <a class="moz-txt-link-rfc2396E" href="mailto:daniel@ffwll.ch"><daniel@ffwll.ch></a>; Daniel
Stone <a class="moz-txt-link-rfc2396E" href="mailto:daniel@fooishbar.org"><daniel@fooishbar.org></a>; Olsak, Marek
<a class="moz-txt-link-rfc2396E" href="mailto:Marek.Olsak@amd.com"><Marek.Olsak@amd.com></a>; Grodzovsky, Andrey
<a class="moz-txt-link-rfc2396E" href="mailto:Andrey.Grodzovsky@amd.com"><Andrey.Grodzovsky@amd.com></a><br>
<b>Cc:</b> Rob Clark <a class="moz-txt-link-rfc2396E" href="mailto:robdclark@gmail.com"><robdclark@gmail.com></a>; Rob Clark
<a class="moz-txt-link-rfc2396E" href="mailto:robdclark@chromium.org"><robdclark@chromium.org></a>; Sharma, Shashank
<a class="moz-txt-link-rfc2396E" href="mailto:Shashank.Sharma@amd.com"><Shashank.Sharma@amd.com></a>; Christian König
<a class="moz-txt-link-rfc2396E" href="mailto:ckoenig.leichtzumerken@gmail.com"><ckoenig.leichtzumerken@gmail.com></a>; Somalapuram,
Amaranath <a class="moz-txt-link-rfc2396E" href="mailto:Amaranath.Somalapuram@amd.com"><Amaranath.Somalapuram@amd.com></a>; Abhinav
Kumar <a class="moz-txt-link-rfc2396E" href="mailto:quic_abhinavk@quicinc.com"><quic_abhinavk@quicinc.com></a>; dri-devel
<a class="moz-txt-link-rfc2396E" href="mailto:dri-devel@lists.freedesktop.org"><dri-devel@lists.freedesktop.org></a>; amd-gfx list
<a class="moz-txt-link-rfc2396E" href="mailto:amd-gfx@lists.freedesktop.org"><amd-gfx@lists.freedesktop.org></a>; Deucher, Alexander
<a class="moz-txt-link-rfc2396E" href="mailto:Alexander.Deucher@amd.com"><Alexander.Deucher@amd.com></a>; Shashank Sharma
<a class="moz-txt-link-rfc2396E" href="mailto:contactshashanksharma@gmail.com"><contactshashanksharma@gmail.com></a><br>
<b>Subject:</b> Re: [PATCH v2 1/2] drm: Add GPU reset sysfs
event</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">[Adding Marek and Andrey as well]<br>
<br>
Am 23.03.22 um 16:14 schrieb Daniel Vetter:<br>
> On Wed, 23 Mar 2022 at 15:07, Daniel Stone
<a class="moz-txt-link-rfc2396E" href="mailto:daniel@fooishbar.org"><daniel@fooishbar.org></a> wrote:<br>
>> Hi,<br>
>><br>
>> On Mon, 21 Mar 2022 at 16:02, Rob Clark
<a class="moz-txt-link-rfc2396E" href="mailto:robdclark@gmail.com"><robdclark@gmail.com></a> wrote:<br>
>>> On Mon, Mar 21, 2022 at 2:30 AM Christian
König<br>
>>> <a class="moz-txt-link-rfc2396E" href="mailto:christian.koenig@amd.com"><christian.koenig@amd.com></a> wrote:<br>
>>>> Well you can, it just means that their
contexts are lost as well.<br>
>>> Which is rather inconvenient when deqp-egl
reset tests, for example,<br>
>>> take down your compositor ;-)<br>
>> Yeah. Or anything WebGL.<br>
>><br>
>> System-wide collateral damage is definitely a
non-starter. If that<br>
>> means that the userspace driver has to do what
iris does and ensure<br>
>> everything's recreated and resubmitted, that
works too, just as long<br>
>> as the response to 'my adblocker didn't detect
a crypto miner ad' is<br>
>> something better than 'shoot the entire user
session'.<br>
> Not sure where that idea came from, I thought at
least I made it clear<br>
> that legacy gl _has_ to recover. It's only vk and
arb_robustness gl<br>
> which should die without recovery attempt.<br>
><br>
> The entire discussion here is who should be
responsible for replay and<br>
> at least if you can decide the uapi, then punting
that entirely to<br>
> userspace is a good approach.<br>
<br>
Yes, completely agree. We have the approach of
re-submitting things in <br>
the kernel and that failed quite miserable.<br>
<br>
In other words currently a GPU reset has something like
a 99% chance to <br>
get down your whole desktop.<br>
<br>
Daniel can you briefly explain what exactly iris does
when a lost <br>
context is detected without gl robustness?<br>
<br>
It sounds like you guys got that working quite well.<br>
<br>
Thanks,<br>
Christian.<br>
<br>
><br>
> Ofc it'd be nice if the collateral damage is
limited, i.e. requests<br>
> not currently on the gpu, or on different engines
and all that<br>
> shouldn't be nuked, if possible.<br>
><br>
> Also ofc since msm uapi is that the kernel tries to
recover there's<br>
> not much we can do there, contexts cannot be shot.
But still trying to<br>
> replay them as much as possible feels a bit like
overkill.<br>
> -Daniel<br>
><br>
>> Cheers,<br>
>> Daniel<br>
><br>
><br>
<br>
</div>
</span></font></div>
</div>
</blockquote>
<br>
</body>
</html>