From: Andy R. <ar...@nv...> - 2004-05-17 20:04:10
|
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...@hp...> > HP Labs, Cambridge Research Laboratory > > > _______________________________________________ > xorg mailing list > xo...@fr... > http://freedesktop.org/mailman/listinfo/xorg > |