Question about linux-explicit-synchronization

[Scott Anderson]

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.
> 
> Cheers,
> Daniel