[Xorg] Re: Damage/Composite + direct rendering clients

[Andy Ritger]

On Mon, 17 May 2004, Jim Gettys wrote:

> On Mon, 2004-05-17 at 11:41, Andy Ritger wrote:
> > I've given some thought to how best to integrate direct rendering
> > clients with Damage/Composite.  For the below discussion, I'll focus
> > on GLX as the direct rendering client but the same concepts should
> > apply to XvMC or any other direct rendering client.
> > 
> > For anyone not already familiar with the Damage and Composite
> > extensions, please see Keith Packard's description of how compositing
> > works in the modular X server:
> > 
> >     http://www.freedesktop.org/Software/TranslucentWindows
> > 
> > The relevant extensions are Damage and Composite (explanations
> > of both, as well as links to the specs are available in Keith's
> > above description).  Damage has already been integrated back into
> > the X.org X server; integration of Composite is in progress.
> > 
> > 
> > How should a direct rendering client interact with Damage/Composite?
> > There seem to be two pieces to this: damage notification, and
> > synchronization.
> > 
> > 
> > Damage Notification
> > 
> > Obviously, when rendering is performed by the X server, the X server
> > knows what regions of the X screen have been damaged so that it can
> > send notification to all Damage clients.  When a direct rendering
> > client performs the rendering, the X server does not know when the
> > rendering has been performed.  When a direct rendering client damages
> > the X screen, it needs to communicate that information to the X
> > server so that the X server can notify Damage clients of the damage.
> > 
> > Presumably, any direct rendering client today requires support from a
> > vendor-specific X module to negotiate things like window moves, etc.
> > Given that, it seems best to leave the details up to each vendor.
> > As long as the core X server exposes to X drivers some function
> > such that an X driver can inform the X server of damage, then each
> > vendor can solve the client -> server communication with whatever
> > mechanism works best with their architecture.
> > 
> > 
> > Synchronization
> > 
> > There are atleast two possible race conditions:
> > 
> >    1) client kicks off rendering, notifies X server of damage,
> >       X server sends Damage event to composite manager, composite
> >       manager sends compositing request back to server, server
> >       performs composite.  There needs to be some synchronization to
> >       guarantee that the composite is not performed until the client
> >       rendering is completed by the hardware.
> > 
> >    2) some damage occurs, composite manager sends composite request,
> >       additional rendering is performed, part of which the composite
> >       operation picks up, but the rest of the rendering is not
> >       composited until the next "frame" of the composite manager,
> >       and we see visible tearing.
> > 
> >       Consider this example: a translucent xterm partially overlaps
> >       glxgears.  If the xterm is damaged, and the composite manager
> >       requests a composite, and then glxgears is updated (between
> >       when the composite request is sent, and when the composite
> >       operation is performed), then the part of the glxgears beneath
> >       the xterm will be composited this frame of compositing.  Later,
> >       the composite manager will receive a damage event for glxgears,
> >       and will composite, causing the visible screen to be brought
> >       up to date.  But in the period of time between the first and
> >       second composites, glxgears will tear.
> > 
> >       The above xterm+glxgears scenario is not limited to direct
> >       rendering clients.  The same should be reproducible with any
> >       regular X rendering -- there is a race between when the
> >       composite manager retrieves the damage region(s), when it
> >       sends the composite requests, and any rendering protocol
> >       (or direct rendering) that is processed in between.
> > 
> >       It seems that the complete solution would be for the composite
> >       manager to perform an XGrabServer(3X11) before retrieving the
> >       damage regions, then send the compositing requests, and then
> >       XUngrabServer(3X11).  Unfortunately, that seems very heavy
> >       weight.  On the other hand, it may ensure faster compositing
> >       by effectively raising the priority of the composite manager's
> >       protocol while all other X clients are locked out.
> > 
> >       Some may be inclined to accept the tearing rather than pay
> >       the heavy weight operation of grabbing/ungrabbing around every
> >       compositing frame.  For X clients, that may be OK, but I expect
> >       the tearing will be much more pronounced with OpenGL clients,
> >       because by nature they are more often animating.
> > 
> > 
> > Perhaps the best solution is to introduce two new requests to the
> > Composite extension: a "BeginComposite" and an "EndComposite" that
> > composite managers would call, bracketing their compositing requests.
> > The X server would dispatch these requests into the X driver.
> > This would give vendors the flexibility to perform any necessary
> > synchronization to protect against the above race conditions.
> 
> My thoughts are coming at this from a different but related direction
> than yours: it is the case of an application updating the state of its
> window(s), to minimize flashing.
> 
> The thoughts I've had on this topic is to use an XSync counter: if the
> counter is even/odd, the contents of the window might be
> stable/unstable.  Incrementing a counter is very fast.
> 
> This might also fold into XSync counters for vertical retrace, as per
> the original XSync design/implementation (not implemented on Linux,
> though recently some work has been started).
> 
> A similar situation might be usable for DRI synchronization, giving
> us a common synhronization framework, both for DRI synchronization and
> for application update synchronization.
> 
> I suspect some tweaks to XSync may be necessary to get all this to work.

Thanks, Jim.  That sounds interesting.  So an app would increment
a counter for a window, indicating the window is in flux, and then
increment the counter again when it is done updating the window?
Is this meant as a hint to the X server to note send any damage
events for that window until the app indicates the window is in a
stable state?

I'm not sure I see how to apply that idea to the #2 synchronization
problem above... what did you have in mind?

Thanks,
- Andy


>                                          - Jim
> 
> -- 
> Jim Gettys <Jim.Gettys at hp.com>
> HP Labs, Cambridge Research Laboratory
> 
> 
> _______________________________________________
> xorg mailing list
> xorg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xorg
>