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.)
Cheers, Daniel
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.
Regards, Christian.
Cheers, Daniel
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
linaro-mm-sig@lists.linaro.org
-
Christian König -
Daniel Stone -
Daniel Vetter