Re: Tackling the indefinite/user DMA fence problem

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, May 25, 2022 at 04:22:48PM +0200, Christian König wrote:
> 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.

The pollable wait isn't enough because the client could keep issuing more
rendering. So what you actually want is
- dma-buf export to get a sync_file (should land any minute now)
- poll on that (it works, as it doesn on dma-buf)
- tell egl to no do implicit sync or (maybe better) just have a vk
  renderer in your compositor

But interim you can poll on the dma-buf and it'll dtrt for at least
cooperative clients already.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch