On 18/02/19 11:02 pm, Daniel Stone wrote:
Hi Scott,
On Mon, 18 Feb 2019 at 03:27, Scott Anderson
<[email protected]> wrote:
In the Weston implementation, it's simply a case of the compositor
getting the fence from the client, using eglWaitSyncKHR (or equivilent)
on it, and passing back a release fence from OUT_FENCE_FD.
Yep, that's pretty much the MVP ...
However, is the protocol intended to allow a compositor which takes a
more active role in monitoring the fences? For example, a compositor
could check the state of the fence at drawing time and decide to use the
client's previous buffer if the fence hasn't been signalled.
Is it worth a compositor being implemented like this? As far as I
understand, doing this would stop any particuarly slow clients from
stalling the compositor's drawing too much and possibly missing vblank.
But I'm not an expert on fences or how eglWaitSyncKHR affects anything
at a driver level.
No, you're totally right. The intention is that compositors should be
able to use this to schedule composition. It's still helpful without
doing that - you get more information for tracing - but in an ideal
world, compositors would be able to delay presentation if it would
endanger full frame rate.
Doing this gets _really_ tricky as you start considering things like
synchronised subsurfaces (which always seems to be the case), since
you have to make sure you're not presenting incoherent results. But
for unrelated surfaces, you can definitely delay presentation.
Ok, cool. That actually answers a follow-up question I would've had.
I've been looking at implementing this in wlroots, and subsurfaces
certainly were a point I was wondering about.
The case in particular would be:
- Parent surface is "ready" (signaled fence or no fence)
- Subsurface is synchronized and fence is not signaled
The intuitive thing would be to delay the parent's content from being
updated until the subsurface is ready, but the protocol itself is a bit
underspecified when it comes to this.
FWIW, eglWaitSyncKHR just ensures that the GPU waits for completion of
the sync object before executing any of the commands you give it
subsequently: it's a guaranteed stall. For making that decision on the
compositor side, you just want to be using the dma-fence FD. You can
add dma-fence FDs to a poll loop, where they become 'readable' when
the fence has been signalled.
Cheers,
Daniel
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
