[Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

[Christian König]

Am 20.04.21 um 16:53 schrieb Daniel Stone:
> Hi,
>
> 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
>     userspace.
>     - 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 
> waits.

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.

Regards,
Christian.

>
> Cheers,
> Daniel
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20210420/0c1f56ce/attachment-0001.htm>