Fence Sync patches

[Keith Packard]

On Fri, 3 Dec 2010 14:14:34 -0800, James Jones <jajones at nvidia.com> wrote:

> I do think fence objects will be generally 
> useful on all platforms.

Right, I think there's pretty general agreement that integrating OpenGL
fencing into the X protocol is a good idea. And, this is the bulk of the
changes that you've proposed, from an X server perspective.

> The open source drivers have chosen to perform this implicit
> synchronization.  However, it isn't required by any specification.

The other drivers have worked hard to provide synchronization when
reporting damage to a client. This is not any kind of general
synchronization operation, it happens at a well defined point in the
operation of the server, and a point which occurs reasonably
infrequently during normal server execution (once per frame for each
application).

GLX and EGL are not the only direct rendering APIs.  We've also got
several media APIs to deal with. While it would be nice to get fencing
added to these, it's also a practical reality that our kernel drivers
will need to provide synchronization between applications without the
need for API-level fencing at least in the near term.

> Just because new applications and X extensions introduce new
> synchronization needs doesn't mean new forms of implicit
> synchronization should be shoe-horned in at the driver level.

Given support for general fence operations, providing implicit fence
management means that existing compositing applications would just work,
and would not require additional code and potentially additional latency
to the screen. That seems like a pretty compelling argument to me.

> In theory, implicit synchronization would be possible in our driver
> model.

Given that implicit synchronization is possible, I'd suggest that a
compromise could be:

 1) Explicitly state that the usual damage tracking causes synchronous
    rendering between X and all direct rendering APIs supported by the
    system.

 2) Add the new fence-based synchronization mechanism which eliminates
    this guarantee. This means that compositing managers could choose to
    continue to use the existing mechanism and get correct behaviour, or
    they could choose to switch to the new request and gain a potential
    performance advantage.

    I imagine this would require an additional request to set the
    synchronization behaviour of specific Damage objects.

> However, it would almost certainly be more work than adding and maintaining 
> this X extension and modifying a half-dozen composite managers to use
> it

It places the burden of implementation on the people who want the
change. That seems like a good balance to me. There are also more than
half a dozen compositing managers, most of which will never get fixed
leaving them open to future failure.

Please consider my compromise above; accepting the existing usage as
correct and sufficient but also encouraging compositing manager
developers to use fences as a more hardware-friendly synchronization
method.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101203/3914bf5b/attachment.pgp>