Re: Tackling the indefinite/user DMA fence problem

["Christian König" <christian.koenig@amd.com>]

Am 25.05.22 um 16:15 schrieb Daniel Stone:
> Hi,
>
> On Wed, 25 May 2022 at 15:07, Simon Ser <contact@emersion.fr> wrote:
>> On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>> You can add that to the list of reasons why compositors need to stop
>>>> using buffers with unsignaled fences. There's plenty of other reasons
>>>> there already (the big one being that otherwise slow clients can slow
>>>> down the compositor, even if the compositor uses a high priority context
>>>> and the HW supports preemption).
>>>
>>> Yeah that's tbh another reason why I think we shouldn't do umf as a
>>> transparent thing - compositors need to get better anyway, so we might as
>>> well take this as a chance to do this right.
>> As a compositor dev, I agree -- we should definitely be smarter about
>> this. Note, it would help a lot to have a good way to integrate the
>> waits into a poll(2) event loop.
> The same holds for Weston. We're currently working through a bunch of
> internal infrastructure to be able to handle this. Mutter (aka GNOME)
> is also really well-placed to be able to do this.
>
> Having pollable waits would be really useful, but I don't think it's
> essential. In my strawman I'm just waking up at the usual
> just-before-repaint point and checking; if it doesn't make it for this
> frame then we'll wait for the next frame. If someone submits buffers
> which take 4 repaint periods to clear then we'll have 3 'unnecessary'
> wakeups, but given the GPU is already slammed then it's not an
> efficiency problem I don't think. (I don't know if all the other
> compositor people share this view.)

Oh, well you should already have pollable waits, at least on DMA-buf.

If you are saying you want to have that for drm_syncobj timelines as 
well then that's certainly something we could do.

Regards,
Christian.

>
> Cheers,
> Daniel