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 <[EMAIL PROTECTED]>
HP Labs, Cambridge Research Laboratory
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
