Am 28.07.21 um 15:57 schrieb Pekka Paalanen:
On Wed, 28 Jul 2021 15:31:41 +0200
Christian König <christian.koe...@amd.com> wrote:
Am 28.07.21 um 15:24 schrieb Michel Dänzer:
On 2021-07-28 3:13 p.m., Christian König wrote:
Am 28.07.21 um 15:08 schrieb Michel Dänzer:
On 2021-07-28 1:36 p.m., Christian König wrote:
At least AMD hardware is already capable of flipping frames on GPU events like
finishing rendering (or uploading etc).
By waiting in userspace on the CPU before send the frame to the hardware you
are completely killing of such features.
For composing use cases that makes sense, but certainly not for full screen
applications as far as I can see.
Even for fullscreen, the current KMS API only allows queuing a single page flip
per CRTC, with no way to cancel or otherwise modify it. Therefore, a Wayland
compositor has to set a deadline for the next refresh cycle, and when the
deadline passes, it has to select the best buffer available for the fullscreen
surface. To make sure the flip will not miss the next refresh cycle, the
compositor has to pick an idle buffer. If it picks a non-idle buffer, and the
pending rendering does not finish in time for vertical blank, the flip will be
delayed by at least one refresh cycle, which results in visible stuttering.
(Until the deadline passes, the Wayland compositor can't even know if a
previously fullscreen surface will still be fullscreen for the next refresh
cycle)
Well then let's extend the KMS API instead of hacking together workarounds in
userspace.
That's indeed a possible solution for the fullscreen / direct scanout case.
Not for the general compositing case though, since a compositor does not want
to composite multiple output frames per display refresh cycle, so it has to
make sure the one frame hits the target.
Yeah, that's true as well.
At least as long as nobody invents a mechanism to do this decision on
the GPU instead.
That would mean putting the whole window manager into the GPU.
Not really. You only need to decide if you want to use the new backing
store or the old one based on if the new surface is ready or not.
At AMD hardware can already do this, we just don't have an OpenGL
extension for it (but maybe already in Vulkan).
Regards,
Christian.
Thanks,
pq
