Am 25.05.22 um 16:15 schrieb Daniel Stone:
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.)
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
