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

[Jim Gettys]

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.

                                         - Jim

-- 
Jim Gettys <Jim.Gettys at hp.com>
HP Labs, Cambridge Research Laboratory