I see! Thank you! On 2022-05-30 11:58, Pekka Paalanen wrote: > On Fri, 27 May 2022 20:07:27 +0300 > Maksim Sisov <msi...@igalia.com> wrote: > >> 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. > > 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).
