From: "Michel Dänzer" <michel@daenzer.net>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Marek Olšák" <maraeo@gmail.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
"ML Mesa-dev" <mesa-dev@lists.freedesktop.org>,
"Alex Deucher" <alexdeucher@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Dave Airlie" <airlied@gmail.com>,
"Jason Ekstrand" <jason@jlekstrand.net>,
"Bas Nieuwenhuizen" <bas@basnieuwenhuizen.nl>
Subject: Re: [Mesa-dev] Linux Graphics Next: Userspace submission update
Date: Tue, 1 Jun 2021 15:18:10 +0200 [thread overview]
Message-ID: <1945baa6-95d4-3f59-0c0e-01ae65033018@daenzer.net> (raw)
In-Reply-To: <b0d65f94-cc56-a4db-3158-7b1de3952792@gmail.com>
On 2021-06-01 2:10 p.m., Christian König wrote:
> Am 01.06.21 um 12:49 schrieb Michel Dänzer:
>> On 2021-06-01 12:21 p.m., Christian König wrote:
>>> Am 01.06.21 um 11:02 schrieb Michel Dänzer:
>>>> On 2021-05-27 11:51 p.m., Marek Olšák wrote:
>>>>> 3) Compositors (and other privileged processes, and display flipping) can't trust imported/exported fences. They need a timeout recovery mechanism from the beginning, and the following are some possible solutions to timeouts:
>>>>>
>>>>> a) use a CPU wait with a small absolute timeout, and display the previous content on timeout
>>>>> b) use a GPU wait with a small absolute timeout, and conditional rendering will choose between the latest content (if signalled) and previous content (if timed out)
>>>>>
>>>>> The result would be that the desktop can run close to 60 fps even if an app runs at 1 fps.
>>>> FWIW, this is working with
>>>> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 , even with implicit sync (on current Intel GPUs; amdgpu/radeonsi would need to provide the same dma-buf poll semantics as other drivers and high priority GFX contexts via EGL_IMG_context_priority which can preempt lower priority ones).
>>> Yeah, that is really nice to have.
>>>
>>> One question is if you wait on the CPU or the GPU for the new surface to become available?
>> It's based on polling dma-buf fds, i.e. CPU.
>>
>>> The former is a bit bad for latency and power management.
>> There isn't a choice for Wayland compositors in general, since there can be arbitrary other state which needs to be applied atomically together with the new buffer. (Though in theory, a compositor might get fancy and special-case surface commits which can be handled by waiting on the GPU)
>>
>> Latency is largely a matter of scheduling in the compositor. The latency incurred by the compositor shouldn't have to be more than single-digit milliseconds. (I've seen total latency from when the client starts processing a (static) frame to when it starts being scanned out as low as ~6 ms with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1620, lower than typical with Xorg)
>
> Well let me describe it like this:
>
> We have an use cases for 144 Hz guaranteed refresh rate. That essentially means that the client application needs to be able to spit out one frame/window content every ~6.9ms. That's tough, but doable.
>
> When you now add 6ms latency in the compositor that means the client application has only .9ms left for it's frame which is basically impossible to do.
You misunderstood me. 6 ms is the lowest possible end-to-end latency from client to scanout, but the client can start as early as it wants/needs to. It's a trade-off between latency and the risk of missing a scanout cycle.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
next prev parent reply other threads:[~2021-06-01 13:18 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-27 21:51 Linux Graphics Next: Userspace submission update Marek Olšák
2021-05-28 14:41 ` Christian König
2021-05-28 22:25 ` Marek Olšák
2021-05-29 3:33 ` Marek Olšák
2021-05-31 8:25 ` Christian König
2021-06-01 9:02 ` Michel Dänzer
2021-06-01 10:21 ` Christian König
2021-06-01 10:49 ` Michel Dänzer
2021-06-01 12:10 ` [Mesa-dev] " Christian König
2021-06-01 12:30 ` Daniel Vetter
2021-06-01 12:51 ` Christian König
2021-06-01 13:01 ` Marek Olšák
2021-06-01 13:24 ` Michel Dänzer
2021-06-02 8:57 ` Daniel Stone
2021-06-02 9:34 ` Marek Olšák
2021-06-02 9:38 ` Marek Olšák
2021-06-02 18:48 ` Daniel Vetter
2021-06-02 18:52 ` Christian König
2021-06-02 19:19 ` Daniel Vetter
2021-06-04 7:00 ` Christian König
2021-06-04 8:57 ` Daniel Vetter
2021-06-04 11:27 ` Christian König
2021-06-09 13:19 ` Daniel Vetter
2021-06-09 13:58 ` Christian König
2021-06-09 18:31 ` Daniel Vetter
2021-06-10 15:59 ` Marek Olšák
2021-06-10 16:33 ` Christian König
2021-06-14 17:10 ` Marek Olšák
2021-06-14 17:13 ` Christian König
2021-06-17 16:48 ` Daniel Vetter
2021-06-17 18:28 ` Marek Olšák
2021-06-17 19:04 ` Daniel Vetter
2021-06-17 19:23 ` Marek Olšák
2021-06-03 3:16 ` Marek Olšák
2021-06-03 7:47 ` Daniel Vetter
2021-06-03 8:20 ` Marek Olšák
2021-06-03 10:03 ` Daniel Vetter
2021-06-03 10:55 ` Marek Olšák
2021-06-03 11:22 ` Daniel Vetter
2021-06-03 17:52 ` Marek Olšák
2021-06-03 19:18 ` Daniel Vetter
2021-06-04 5:26 ` Marek Olšák
2021-06-02 9:44 ` Christian König
2021-06-02 9:58 ` Marek Olšák
2021-06-02 10:06 ` Christian König
2021-06-01 13:18 ` Michel Dänzer [this message]
2021-06-01 17:39 ` Michel Dänzer
2021-06-01 17:42 ` Daniel Stone
2021-06-02 8:09 ` Michel Dänzer
2021-06-02 19:20 ` Daniel Vetter
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=1945baa6-95d4-3f59-0c0e-01ae65033018@daenzer.net \
--to=michel@daenzer.net \
--cc=airlied@gmail.com \
--cc=alexdeucher@gmail.com \
--cc=bas@basnieuwenhuizen.nl \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jason@jlekstrand.net \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).