On 3/6/26 10:36, Michel Dänzer wrote: > On 3/6/26 06:13, Chia-I Wu wrote: >> On Thu, Mar 5, 2026 at 12:52 PM Matthew Brost <[email protected]> >> wrote: >>> On Thu, Mar 05, 2026 at 11:52:01AM +0100, Boris Brezillon wrote: >>>> On Thu, 5 Mar 2026 02:09:16 -0800 >>>> Matthew Brost <[email protected]> wrote: >>>>> On Thu, Mar 05, 2026 at 09:27:11AM +0100, Boris Brezillon wrote: >>>>>> On Wed, 4 Mar 2026 18:04:25 -0800 >>>>>> Matthew Brost <[email protected]> wrote: >>>>>>> On Wed, Mar 04, 2026 at 02:51:39PM -0800, Chia-I Wu wrote: >>>>>>>> >>>>>>>> Thoughts? Or perhaps this becomes less of an issue if all drm_sched >>>>>>>> users have concrete plans for userspace submissions.. >>>>>>> >>>>>>> Maybe some day.... >>>>>> >>>>>> I've yet to see a solution where no dma_fence-based signalization is >>>>>> involved in graphics workloads though (IIRC, Arm's solution still >>>>>> needs the kernel for that). Until that happens, we'll still need the >>>>>> kernel to signal fences asynchronously when the job is done, which I >>>>>> suspect will cause the same kind of latency issue... >>>>>> >>>>> >>>>> I don't think that is the problem here. Doesn’t the job that draws the >>>>> frame actually draw it, or does the display wait on the draw job’s fence >>>>> to signal and then do something else? >>>> >>>> I know close to nothing about SurfaceFlinger and very little about >>>> compositors in general, so I'll let Chia answer that one. What's sure >>> >>> I think Chia input would good, as if SurfaceFlinger jobs have input >>> dependencies this entire suggestion doesn't make any sense. >>> >>>> is that, on regular page-flips (don't remember what async page-flips >>>> do), the display drivers wait on the fences attached to the buffer to >>>> signal before doing the flip. >>> >>> I think SurfaceFlinger is different compared to Wayland/X11 use cases, >>> as maintaining a steady framerate is the priority above everything else >>> (think phone screens, which never freeze, whereas desktops do all the >>> time). So I believe SurfaceFlinger decides when it will submit the job >>> to draw a frame, without directly passing in application dependencies >>> into the buffer/job being drawn. Again, my understanding here may be >>> incorrect... >> That is correct. SurfaceFlinger only ever latches buffers whose >> associated fences have signaled, and sends down the buffers to gpu for >> composition or to the display for direct scanout. That might also be >> how modern wayland compositors work nowadays? > > Many (most of the major ones?) do, yes. (Weston being a notable exception > AFAIK, though since it supports the Wayland syncobj protocol now, switching > to this model shoul
Err, I meant the commit-timing protocol, Weston doesn't support the syncobj protocol yet AFAICT. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
