Hi, On Wed, 25 May 2022 at 15:07, Simon Ser <contact@xxxxxxxxxxx> wrote: > On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter <daniel@xxxxxxxx> 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.) Cheers, Daniel
