Question about linux-explicit-synchronization
scott.anderson at collabora.com
Mon Feb 18 10:13:28 UTC 2019
On 18/02/19 11:02 pm, Daniel Stone wrote:
> Hi Scott,
> On Mon, 18 Feb 2019 at 03:27, Scott Anderson
> <scott.anderson at collabora.com> 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.
More information about the wayland-devel