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

[Adam Jackson]

On Tue, 2010-08-17 at 15:54 -0700, James Jones wrote:
> On Tuesday 17 August 2010 15:01:53 Aaron Plattner wrote:
> > 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.

So, a few things here:

One: Why the screen and not the drawable?  If an X screen is a single
command queue to the hardware with no special ordering (besides
"whatever order clients happened to be serviced") then it doesn't really
matter.  But if you have multiple queues - or schedule rendering among
clients into one queue for fairness - then you now need to keep track of
actual request processing order among _all_ clients with active Fences.

Two: I'm not clear what the mechanism is for asking that the server
trigger a Fence once some X rendering is complete.  You have Trigger and
Reset operations, but if I'm reading those correctly those are commands
from the client and not stalls until a condition is reached.

In GL_NV_fence terms, I think you have:

GL                X
GenFences         CreateFence
DeleteFences      DestroyFence
SetFence          ???
N/A               TriggerFence
N/A               ResetFence
TestFence         QueryFence
FinishFence       AwaitFence

It's okay to not have analogs for Trigger/Reset in GL, because GL fences
are scoped to the GL context; you couldn't use them for IPC if you
wanted to.  But without an analog for SetFence in X, you don't have a
way of getting the server to bind a fence to a particular point in the X
rendering stream.

But maybe you're going for something more like GL_ARB_sync?  Help me out
here.

Three: XSyncSetFence could nicely resolve issue one.  Fences would then
have basically the same scoping rules as GCs; they're per-screen, but
they can only be used on one drawable at a time.  From X's perspective
though, you wouldn't necessarily need them to be per-screen at creation
time; ProcSyncSetFence would do both pScreen->RealizeFence() and
pScreen->SetFence().  But I can see why you might want that binding
early for GL.

Four: The Xinerama interaction here is potentially subtle.  There's only
one protocol screen in Xinerama, so merely creating the Fence relative
to a screen doesn't tell you which GPU you're bound to.  You'd probably
need to do the standard trick of blasting the Fence across all
ScreenRecs, and then Await would wait for completion across them all.
Potentially inefficient, but that's par for the Xinerama course.

> I'll make another pass and try to capture more of the above in the spec, in 
> addition to making more intrusive updates to the sections you reference above.  
> I'll send those out when I send out the xserver changes.  I tried a few 
> directions with the server code, and feel the current spec/implementation fell 
> out most naturally from the existing architecture, so having the code to look 
> at side-by-side with the proto patches might help.  If anyone wants to get 
> ahead of me, the latest xserver changes are available on my github repos at
> 
> http://github.com/cubanismo/xserver/tree/fence_sync

Nice, I'll give that a read.

> > 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.
> 
> See the damageproto changes for a bit more background, but they basically just 
> say what Aaron said above.

This sounds like you're designing it just for the compositor to consume.
I'm not really sure yet whether that's a reasonable thing.

I kind of want to eliminate the SubtractAndTrigger there, it seems like
you should be able to go straight from a FenceNotify (which, admittedly,
your proposal does not have) to the glFinishFence.  To elaborate:
intelligent clients would have a window property naming their Fence, and
would XSyncSetFence when they post a new frame; the compositor would get
an AwaitNotify for that and then glFinishFence as usual.  (The existing
frame sync protocol is not far off from this as it is.)

Maybe I'm overthinking this.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100818/4c80707d/attachment.pgp>