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

[Andy Ritger]

On Mon, 17 May 2004, Jim Gettys wrote:

> On Mon, 2004-05-17 at 16:03, Andy Ritger wrote:
> 
> > > >    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?
> 
> Yes.  Exactly.
> 
> > 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?
> 
> No, as Keith says, damage accumulates in the region in the X server
> until the time you need to use the region.  Any view a client has of the
> damaged region is likely to be obsolete by the time it would get it.
> So while it is possible for clients to get informed of damaged regions,
> it isn't really the main-line case damage was designed for.

OK, I think I misunderstood some of the mechanics of Damage.
Storing the region server side and letting the composite manager
say "use that region, whatever is in it" is good.  I am still
slightly worried that a window could be damaged between when the
composite manager decides which windows need recompositing and
when it sends the composite requests (resulting in not compositing
that window until the next iteration of the composite manager).
XGrab/XUngrab would protect against that.

> What you want to avoid is round trips; the damage accumlation allows
> a client (say the compositing manager) to rerender with the accumulated
> damage at the time it operates rather than having to wait for the
> damage to be communicated to the client, avoiding a round trip.

OK, that makes sense.

> > 
> > I'm not sure I see how to apply that idea to the #2 synchronization
> > problem above... what did you have in mind?
> 
> The basic idea of XSync is the ability to block execution on a
> connection until a counter gets to a given value.  I don't think
> as defined this instant that XSync has exactly what we need, but I think
> the idea may have merit. 
> 
> In the original XSync design, the idea was that vertical retrace would
> be a pre-defined system counter, and on hardware without hardware double
> buffering, you could then arrange to do operations during vertical
> retrace, avoiding tearing (unless they took too long to complete,
> and the scan caught up to the operation(s)).
> 
> Fundamentally, we want to have a set of operations that won't take place
> until a certain event happens (the window's contents are stable again,
> in this case, whether unstable from an application via X or DRI),
> but will then take place.
> 
> Certainly, incrementing a counter could cause the
> clients that are blocked on that counter to get a chance at the X
> scheduler (it might do so already, but that code hasn't been seriously
> looked at for a long time, and may not be semantically guaranteed by
> XSync's spec right now).
> 
> What we need in this case is just that the compositing manager get a
> chance to run when the machine is idle, or at least once in a blue moon.
> The big issue is to prevent starvation by applications driving either
> the X server or the graphics engine flat out preventing occasional
> (60HZ) updates to the eye candy.
> 
> It would be good if we can end up with one general mechanism for
> synchronziation, to avoid alot of ad-hoc mechanisms, if we can.
> 
> I need to go back and swap in my knowledge of XSync, which is about a
> decade old.
>                         - Jim

OK, thanks for the explanation.  I'm not sure how applicable this
is to the synchronization concerns I have, though.  My biggest
concern (new damage occuring inbetween when the composite manager
decides what to recomposite, and when it does the composite)
wouldn't be helped by this XSync mechanism.

The other concern (how to make sure direct rendering has completed
by the time the drawable is used as a source in a composite
operation) conceptually would be solved as you describe, but I
expect the implementation would be buried deeper -- either an X
driver doesn't call into the core X server to notify it of damage
until the direct rendered damage has completed, or the X server
has to block, as Keith described, when it receives requests that
uses the pending damaged drawable as a source.  Either way, I think
it makes sense to leave this up to each vendor; the implementation
details will likely be influenced by their architecture, etc.

Thanks,
- Andy


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