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 should be easy) -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
