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