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 <jajo...@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 _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel