[Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal
ckoenig.leichtzumerken at gmail.com
Tue Apr 20 14:58:54 UTC 2021
Am 20.04.21 um 16:53 schrieb Daniel Stone:
> On Mon, 19 Apr 2021 at 11:48, Marek Olšák <maraeo at gmail.com
> <mailto:maraeo at gmail.com>> wrote:
> Deadlock mitigation to recover from segfaults:
> - The kernel knows which process is obliged to signal which fence.
> This information is part of the Present request and supplied by
> - If the producer crashes, the kernel signals the submit fence, so
> that the consumer can make forward progress.
> - If the consumer crashes, the kernel signals the return fence, so
> that the producer can reclaim the buffer.
> - A GPU hang signals all fences. Other deadlocks will be handled
> like GPU hangs.
> 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.
> 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
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.
> GPU hangs also look pretty similar; it's an infinite wait, until the
> client resubmits a new buffer which would replace (& discard) the old.
Correct. You just need to assume that all queues get destroyed and
re-initialized when a GPU reset happens.
> So signal-fence-on-process-exit isn't helpful and doesn't provide any
> extra reliability; it in fact probably just complicates things.
Well it is when you go for partial GPU resets.
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev