On Wed, Jul 28, 2021 at 6:57 AM Pekka Paalanen <ppaala...@gmail.com> wrote: > > 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. >
Hmm, seems like we could come up with a way for a shader to figure out if a fence has signaled or not on the GPU, and then either sample from the current or previous window surface? BR, -R
