On 2022-05-27 11:43, Pekka Paalanen wrote: > On Thu, 26 May 2022 10:25:24 +0300 > Maksim Sisov <msi...@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. 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. 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 -- Best Regards, Maksim Sisov * Usual work time - 08:00-16:00 (EEST).
