Fence Sync patches

[James Jones]

On Friday 03 December 2010 8:26:29 am Owen Taylor wrote:
> On Thu, 2010-12-02 at 09:40 -0800, James Jones wrote:
> > As I mentioned early on, I really want to get the fence sync work in
> > server 1.10.  The server code was reviewed by Adam Jackson (thanks for
> > sifting through all that) and various nvidians, but I still haven't
> > received any external official reviewed-by for the proto updates it
> > relies on, or for the lib code to exercise it.  I've CC'd the suggested
> > reviewers on the latest versions of the patches and here:
> > 
> > -Alan and Adam, because you provided some early feedback on the proto
> > specs but never responded to my updates based on said feedback.
> > 
> > -Keith, because you're the maintainer of the damage subsystem, and there
> > are some minor changes to the damage proto and lib.
> > 
> > If these remaining pieces get reviewed, I can send out pull requests for
> > everything immediately.  I've had this code out for review in some form
> > for about 3 months now, so it'd be pretty disappointing if it had to sit
> > around waiting for another release cycle.
> 
> Hey, is there a good big picture overview of this somewhere?
> 
> As a compositing manager maintainer (Mutter, the GNOME 3 compositing
> manager), I'm wondering what it means for me.
> 
> There's already a lot of magic voodoo dances around both Damage and
> Texture-From-Pixmap, what extra incantations does this add to the
> picture?

I wrote a slide deck on synchronization and presentation ideas for X a year 
ago or so before starting this work:

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

Aaron presented it at XDevConf last year.  However, that doesn't really cover 
the immediately useful function for GL composite managers: 
XDamageSubtractAndTrigger().  I plan on putting some patches to compiz 
together demonstrating the usage, but basically the flow is:

-Create a bunch of sync objects at startup time in your GL/GLES-based 
compositor, and import them into your GL context as GL sync objects.  I'll 
call those syncObjectsX[] and syncObjectsGL[] respectively.

-Rather than calling XDamageSubtract(), call 
XDamageSubtractAndTrigger(syncObjectsX[current]).

-Prefix all the GL rendering that repairs the damage subtracted with a sync 
wait: glWaitSync(syncObjectsGL[current++])

The GL rendering will then wait (on the GPU.  It won't block the application 
unless it gets really backed up) until all rendering that created the damage 
has finished on the GPU.  Managing the ring-buffer of sync objects is a little 
more complicated than that in practice, but that's the basic idea.  This fixes 
a long-standing issue users complain about where they'll press a key in their 
terminal app, and the cursor advances, but the GL compositor just draws a 
blank space where the new character should be because it processed the damage 
event and updated the screen, texturing from the terminal's backing pixmap 
before X even finished drawing the glyph that generated the damage.

I admit this isn't an ideal work-flow, and yes it is one more layer of hard-
to-test voodoo needed to write a robust TFP/EGLimage based composite manager, 
but it's the best we can do without modifying client applications.  However, 
fence sync objects provide a basis for all kinds of cooler stuff once you 
start defining new ways that client applications can use them to notify the 
composite manager when they've finished rendering a frame explicitly.  Then 
the extra step of telling X you want notification when some rendering you've 
already been notified of has completed will go away.  The rendering 
notification (damage event) and a pointer of some sort to the sync object that 
tracks it will arrive together.  That's what I'll be working on after the 
initial object support is wrapped up.

Thanks,
-James

> - Owen
> 
> (I can understand each individual step of the magic voodoo dance, but
> when I go away from the individual problems and come back 6 months
> later, I have to work it all out again. And there's a strong sense that
> only particular code paths that actually are in use are tested and
> anything else probably doesn't work, at least on some drivers.)