wp_presentation vs wl_surface_frame

[Maksim Sisov]

I see! Thank you!

On 2022-05-30 11:58, Pekka Paalanen wrote:
> 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

-- 
Best Regards,
Maksim Sisov
* Usual work time - 08:00-16:00 (EEST).