From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: "Daniel Stone" <daniel@fooishbar.org>, "Marek Olšák" <maraeo@gmail.com>
Cc: ML Mesa-dev <mesa-dev@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal
Date: Tue, 20 Apr 2021 16:58:54 +0200 [thread overview]
Message-ID: <136d3b55-ff1e-c47b-d443-22bd27427956@gmail.com> (raw)
In-Reply-To: <CAPj87rO7_Q2L0PogryGmuxLJk-DA3ckM+6vmDioErZ3_6s0iRQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2088 bytes --]
Am 20.04.21 um 16:53 schrieb Daniel Stone:
> Hi,
>
> On Mon, 19 Apr 2021 at 11:48, Marek Olšák <maraeo@gmail.com
> <mailto:maraeo@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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[-- Attachment #1.2: Type: text/html, Size: 4888 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-04-20 14:58 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-19 10:47 [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal Marek Olšák
2021-04-19 15:48 ` Jason Ekstrand
2021-04-20 2:25 ` Marek Olšák
2021-04-20 10:15 ` [Mesa-dev] " Christian König
2021-04-20 10:34 ` Daniel Vetter
2021-04-20 11:03 ` Marek Olšák
2021-04-20 11:16 ` Daniel Vetter
2021-04-20 11:59 ` Christian König
2021-04-20 14:09 ` Daniel Vetter
2021-04-20 16:24 ` Jason Ekstrand
2021-04-20 16:19 ` Jason Ekstrand
2021-04-20 12:01 ` Daniel Vetter
2021-04-20 12:19 ` [Mesa-dev] " Christian König
2021-04-20 13:03 ` Daniel Stone
2021-04-20 14:04 ` Daniel Vetter
2021-04-20 12:42 ` Daniel Stone
2021-04-20 15:45 ` Jason Ekstrand
2021-04-20 17:44 ` Daniel Stone
2021-04-20 18:00 ` [Mesa-dev] " Christian König
2021-04-20 18:15 ` Daniel Stone
2021-04-20 19:03 ` Bas Nieuwenhuizen
2021-04-20 19:18 ` Daniel Stone
2021-04-20 18:53 ` Daniel Vetter
2021-04-20 19:14 ` Daniel Stone
2021-04-20 19:29 ` Daniel Vetter
2021-04-20 20:32 ` Daniel Stone
2021-04-26 20:59 ` Marek Olšák
2021-04-27 8:02 ` Daniel Vetter
2021-04-27 11:49 ` Marek Olšák
2021-04-27 12:06 ` Christian König
2021-04-27 12:11 ` Marek Olšák
2021-04-27 12:15 ` Daniel Vetter
2021-04-27 12:27 ` Christian König
2021-04-27 12:46 ` Marek Olšák
2021-04-27 12:50 ` Christian König
2021-04-27 13:26 ` Marek Olšák
2021-04-27 15:13 ` Christian König
2021-04-27 17:31 ` Lucas Stach
2021-04-27 17:35 ` Simon Ser
2021-04-27 18:01 ` Alex Deucher
2021-04-27 18:27 ` Simon Ser
2021-04-28 10:01 ` Daniel Vetter
2021-04-28 10:05 ` Daniel Vetter
2021-04-28 10:31 ` Christian König
2021-04-28 12:21 ` Daniel Vetter
2021-04-28 12:26 ` Daniel Vetter
2021-04-28 13:11 ` Christian König
2021-04-28 13:34 ` Daniel Vetter
2021-04-28 13:37 ` Christian König
2021-04-28 14:34 ` Daniel Vetter
2021-04-28 14:45 ` Christian König
2021-04-29 11:07 ` Daniel Vetter
2021-04-28 20:39 ` Alex Deucher
2021-04-29 11:12 ` Daniel Vetter
2021-04-30 8:58 ` Daniel Vetter
2021-04-30 9:07 ` Christian König
2021-04-30 9:35 ` Daniel Vetter
2021-04-30 10:17 ` Daniel Stone
2021-04-28 12:45 ` Simon Ser
2021-04-28 13:03 ` Alex Deucher
2021-04-27 19:41 ` Jason Ekstrand
2021-04-27 21:58 ` Marek Olšák
2021-04-28 4:01 ` Jason Ekstrand
2021-04-28 5:19 ` Marek Olšák
2021-04-27 18:38 ` Dave Airlie
2021-04-27 19:23 ` Marek Olšák
2021-04-28 6:59 ` Christian König
2021-04-28 9:07 ` Michel Dänzer
2021-04-28 9:57 ` Daniel Vetter
2021-05-01 22:27 ` Marek Olšák
2021-05-03 14:42 ` Alex Deucher
2021-05-03 14:59 ` Jason Ekstrand
2021-05-03 15:03 ` Christian König
2021-05-03 15:15 ` Jason Ekstrand
2021-05-03 15:16 ` Bas Nieuwenhuizen
2021-05-03 15:23 ` Jason Ekstrand
2021-05-03 20:36 ` Marek Olšák
2021-05-04 3:11 ` Marek Olšák
2021-05-04 7:01 ` Christian König
2021-05-04 7:32 ` Daniel Vetter
2021-05-04 8:09 ` Christian König
2021-05-04 8:27 ` Daniel Vetter
2021-05-04 9:14 ` Christian König
2021-05-04 9:47 ` Daniel Vetter
2021-05-04 10:53 ` Christian König
2021-05-04 11:13 ` Daniel Vetter
2021-05-04 12:48 ` Christian König
2021-05-04 16:44 ` Daniel Vetter
2021-05-04 17:16 ` Marek Olšák
2021-05-04 21:06 ` Jason Ekstrand
2021-04-28 9:54 ` Daniel Vetter
2021-04-27 20:49 ` Jason Ekstrand
2021-04-27 12:12 ` Daniel Vetter
2021-04-20 19:16 ` Jason Ekstrand
2021-04-20 19:27 ` Daniel Vetter
2021-04-20 14:53 ` Daniel Stone
2021-04-20 14:58 ` Christian König [this message]
2021-04-20 15:07 ` [Mesa-dev] " Daniel Stone
2021-04-20 15:16 ` Christian König
2021-04-20 15:49 ` Daniel Stone
2021-04-20 16:25 ` Marek Olšák
2021-04-20 16:42 ` Jacob Lifshay
2021-04-20 18:03 ` Daniel Stone
2021-04-20 18:39 ` Daniel Vetter
2021-04-20 19:20 ` Marek Olšák
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=136d3b55-ff1e-c47b-d443-22bd27427956@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=daniel@fooishbar.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=maraeo@gmail.com \
--cc=mesa-dev@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).