[PATCH xextproto 0/4] XSync Fence Objects

[James Jones]

On Monday 09 August 2010 1:56:34 pm Keith Packard wrote:
> * PGP Signed by an unknown key
> 
> On Mon, 9 Aug 2010 13:41:54 -0700, James Jones <jajones at nvidia.com> wrote:
> > If anyone thinks docs would make reviewing the code changes easier, I can
> > write them up now rather than waiting for more feedback before moving
> > forward.
> 
> Protocol docs that declare the intended semantics and (even better) some
> kind of justification seem like reasonable first steps to me.

OK.  I will work on capturing that in protocol docs.  In the meantime, here's 
a summary:

When I requested review before, Aaron Plattner sent out this link to the 
slides he presented at last year's XDC.  They give a good overview of the 
motivation behind fence sync objects, and some psuedo-code examples of how 
they would be used:

http://people.freedesktop.org/~aplattner/x-presentation-and-synchronization

Feedback from that presentation led me to consider extending the existing 
XSync extension.  The motivation for creating binary fence sync objects (as 
opposed to using the original counter objects) was also discussed in my prior 
emails:

* Operations that modify the state of fence sync objects are performed 
relative to the previous rendering operations on a specified X screen.  Sync 
counter operations are performed out-of-band with respect to X rendering, 
making them unsuitable for use as synchronization primitives when coordinating 
X rendering with other operations.

* Fence sync objects have binary state.  They are either "triggered" or "not 
triggered."  Only the triggered state may be waited for asynchronously.  This 
greatly simplifies implementing the state transitions and waits on the GPU.  
Perhaps more importantly, it also makes it trivial to tie a fence sync 
object's state to an OpenGL sync object's state and use them to coordinate 
OpenGL and X rendering operations without stalling both rendering streams on 
the CPU.

Thanks,
-James