On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter daniel@ffwll.ch 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.