Question about linux-explicit-synchronization

[Daniel Stone]

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.

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