[PATCH xextproto 1/4] Document changes in XSync version 3.1

[Aaron Plattner]

On Tue, Aug 17, 2010 at 02:49:41PM -0700, Adam Jackson wrote:
> Apologies for the slow review here...
>
> On Thu, 2010-08-12 at 16:40 -0700, James Jones wrote:
>
> >  <para>
> > -The extension adds <function>Counter</function> and
> > -<function>Alarm</function> to the set of resources managed by the
> > +The extension adds <function>Counter</function>, <function>Alarm</function>,
> > +and <function>Fence</function> to the set of resources managed by the
> >  server. A counter has a 64-bit integer value that may be increased or
> >  decreased by client requests or by the server internally. A client can block
> >  by sending an Await request that waits until one of a set of synchronization
> > -conditions, called TRIGGERs, becomes TRUE.
> > +conditions, called TRIGGERs, becomes TRUE.  A fence has two possible states:
> > +triggered and not triggered. Client requests can put the fence in either of
> > +these states. A client can block until one of a set of fences becomes
> > +triggered by sending an AwaitFence request.
> >  </para>
>
> I feel like this whole section wants a rewrite, since Alarms aren't
> discussed until much later.  Would be worthwhile if doing so to note
> that Fences are explicitly bound to a screen (though I wouldn't insist
> on it to get this merged).  And on that subject...
>
> > +<para>
> > +The <function>CreateFence</function> request allows a client to create a
> > +<function>Fence</function> that can be triggered and reset using
> > +<function>TriggerFence</function> and <function>ResetFence</function>
> > +requests, respectively.  The <function>TriggerFence</function> request changes
> > +the fence's state only after all previous rendering commands affecting objects
> > +owned by the given fence's screen have completed.
> > +</para>
>
> I'm a little unclear on _why_ they're bound to screens.  What semantics
> does that imply?  The only reason I can imagine wanting to do so in the
> protocol is if the server itself would ever trigger a Fence on a
> Drawable, because then you'd need to wire the Fence to the right
> ScreenRec.  But it seems like that should never happen for
> client-created Fences, only for server-created Fences.

James, correct me if I'm wrong, but I don't think the server ever creates
fences on its own; they're *all* client-created.  Fences trigger when the
rendering for the corresponding X screen is done, for requests that were
processed before the triggering request.  Rendering could still be pending
on other screens, and there could be later rendering queued on the same
screen for later requests.

The idea is that a client creates a Fence on a given X screen, binds it to
an OpenGL sync object using a to-be-created GLX extension, then in response
to an XDamageNotify, sends DamageSubtractAndTrigger, tells OpenGL to wait
for the corresponding OpenGL side of the fence, and then performs the
rendering using OpenGL.  This makes the GL wait (on the GPU, ideally) for
the X rendering on that screen to finish without making the client itself
wait on the CPU.