wp_presentation vs wl_surface_frame

[Pekka Paalanen]

On Fri, 27 May 2022 20:07:27 +0300
Maksim Sisov <msisov at igalia.com> wrote:

> On 2022-05-27 11:43, Pekka Paalanen wrote:
> > On Thu, 26 May 2022 10:25:24 +0300
> > Maksim Sisov <msisov at igalia.com> wrote:
> >   
> >> Hello!
> >>
> >> I'm currently working on some begin frame issues in Chromium and I
> >> started to wonder if we use available mechanism for synchronization
> >> correctly.
> >>
> >> Wayland compositors may support wl_surface_frame and wp_presentation or
> >> just wl_surface_frame. At the moment, Chromium uses both wp_presentation
> >> to adjust own begin frame scheduling based on the presentation time.
> >> Also, it utilizes wl_surface_frame just before attaching new wl_buffers
> >> to wl_surfaces (we use dmabuf + zwp_linux_dmabuf).
> >>
> >> I wonder if using wl_surface_frame along with wp_presentation is
> >> necessary except the cases when a window is fully occluded.
> >>  
> > 
> > Hi,
> > 
> > presentation-time feedback and frame callbacks are not quite
> > equivalent. It is possible to get frame callbacks before the previous
> > frame was actually presented, allowing you more time to draw and
> > submit. Feedback with "presented" OTOH can only occur once the
> > presentation timestamp is known, which usually means the KMS atomic
> > commit has been replied with a KMS pageflip event in the compositor.
> > 
> > If your question is about finding the optimal time to start drawing in
> > order to minimize latency to screen, then I don't think there is a
> > clear answer to that yet. Some compositors may automatically adjust when
> > they send frame callbacks, others don't. Feedback "presented"
> > definitely occurs after the current frame was presented, but it has no
> > information about when the deadline for the next one is, so all you can
> > do is draw immediately and hope the deadline didn't pass already.
> > 
> > I didn't quite understand your explanation of what Chromium does.
> > 
> > Can you describe the problem you have?
> > 
> > 
> > Thanks,
> > pq  
> 
> Chromium has internal begin frame scheduling that adjusts self according
> to the begin frame scheduling. It can adjust self using vsync
> information from the presentation feedback it receives. The presentation
> feedback won't be used as a signal to start drawing, but rather to
> adjust self better to hit next vblank.

Sounds nice.

The frame submission deadline is always some time earlier than the
next vblank. How much, depends on the compositor, might vary, and
currently there is no protocol to find that out (without occasionally
missing the deadline which causes visual glitches).

There are discussions about improving this, e.g.:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/45
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/103

> And that is something that already happens. However, Chromium also use
> wl_surface.frame that is waited if a buffers are submitted earlier than
> that arrives [1]. It's basically what mesa wayland egl does - whenever
> eglSwapBuffers is called, it checks for the frame callback. If it's not
> received yet, it waits until it's received and proceeds submitting
> buffers.

Yeah, that is the basic mechanism for throttling frame rate, and for
throttling occluded windows.

Mesa is using frame callbacks for eglSwapInterval=1, because nothing
else was possible really when Mesa's EGL Wayland implementation was
written, and it stuck.

Since then, it has caused problems with proposed solutions like
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/99

I recall having talked about disconnecting eglSwapInterval from frame
callbacks, but I've forgot where those comments were. They could be
buried somewhere in the links above.

> However, I wonder if that is even necessary to do. It looks like a
> redundant functionality given internal timer adjusts self according to
> presentation times.
> 
> [1]
> https://source.chromium.org/chromium/chromium/src/+/main:ui/ozone/platform/wayland/host/wayland_frame_manager.cc;l=352;drc=67172ba3828a038c491384620c3f854bd6d0ece9?q=wayland_frame_manager.cc&ss=chromium
> 

Is it required by protocol? No.

Is it a good idea? Not absolutely always, but in many cases yes.

Is it a good idea for Chromium? Hmm. If you do have presentation-time
feedback, maybe you can do without frame callbacks. But you have the
caveat of not knowing when the deadline is, as I explained above. OTOH,
sounds like you will hit that caveat with the current policy anyway.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20220530/4cb0c609/attachment.sig>