Re: drm_sched run_job and scheduling latency

["Michel Dänzer" <michel.daenzer@mailbox.org>]

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 <matthew.brost@intel.com> 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 <matthew.brost@intel.com> 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 <matthew.brost@intel.com> 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