Am 20.04.21 um 16:53 schrieb Daniel Stone:
Hi,
On Mon, 19 Apr 2021 at 11:48, Marek Olšák <mar...@gmail.com
<mailto:mar...@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-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
