<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">Am 20.04.21 um 16:53 schrieb Daniel
Stone:<br>
</div>
<blockquote type="cite"
cite="mid:CAPj87rO7_Q2L0PogryGmuxLJk-DA3ckM+6vmDioErZ3_6s0iRQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Hi,</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 19 Apr 2021 at
11:48, Marek Olšák <<a href="mailto:maraeo@gmail.com"
moz-do-not-send="true">maraeo@gmail.com</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div><span style="">Deadlock mitigation to recover from
segfaults:</span><br>
</div>
<div>- The kernel knows which process is obliged to signal
which fence. This information is part of the Present
request and supplied by userspace.<br>
</div>
<div>- If the producer crashes, the kernel signals the
submit fence, so that the consumer can make forward
progress.</div>
<div>- If the consumer crashes, the kernel signals the
return fence, so that the producer can reclaim the
buffer.</div>
<div>- A GPU hang signals all fences. Other deadlocks will
be handled like GPU hangs.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Another thought: with completely arbitrary userspace
fencing, none of this is helpful either. If the compositor
can't guarantee that a hostile client has submitted a fence
which will never be signaled, then it won't be waiting on
it, so it already needs infrastructure to handle something
like this. </div>
</div>
</div>
</blockquote>
<br>
<blockquote type="cite"
cite="mid:CAPj87rO7_Q2L0PogryGmuxLJk-DA3ckM+6vmDioErZ3_6s0iRQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>That already handles the crashed-client case, because if
the client crashes, then its connection will be dropped,
which will trigger the compositor to destroy all its
resources anyway, including any pending waits.</div>
</div>
</div>
</blockquote>
<br>
Exactly that's the problem. A compositor isn't immediately informed
that the client crashed, instead it is still referencing the buffer
and trying to use it for compositing.<br>
<br>
<blockquote type="cite"
cite="mid:CAPj87rO7_Q2L0PogryGmuxLJk-DA3ckM+6vmDioErZ3_6s0iRQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>GPU hangs also look pretty similar; it's an infinite
wait, until the client resubmits a new buffer which would
replace (& discard) the old.</div>
</div>
</div>
</blockquote>
<br>
Correct. You just need to assume that all queues get destroyed and
re-initialized when a GPU reset happens.<br>
<br>
<blockquote type="cite"
cite="mid:CAPj87rO7_Q2L0PogryGmuxLJk-DA3ckM+6vmDioErZ3_6s0iRQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>So signal-fence-on-process-exit isn't helpful and doesn't
provide any extra reliability; it in fact probably just
complicates things.</div>
</div>
</div>
</blockquote>
<br>
Well it is when you go for partial GPU resets.<br>
<br>
Regards,<br>
Christian.<br>
<br>
<blockquote type="cite"
cite="mid:CAPj87rO7_Q2L0PogryGmuxLJk-DA3ckM+6vmDioErZ3_6s0iRQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><span style=""><br>
</span></div>
<div><span style="">Cheers,</span></div>
<div><span style="">Daniel </span></div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
mesa-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>