On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter <daniel@xxxxxxxx> wrote: > > > Ofc in reality you can still flood your compositor and they're not very > > > robust, but with umf it's trivial to just hang your compositor forever and > > > nothing happens. > > > > 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.
