[Xorg] Damage/Composite + direct rendering clients

[Andy Ritger]

On Mon, 17 May 2004, Keith Packard wrote:

> 
> Around 15 o'clock on May 17, Andy Ritger wrote:
 
[snip]

> > The tricky part here is that the damage event shouldn't be sent to
> > Damage clients until the hardware has completed the damage, but
> > that is the vendor's problem... I'm just trying to make sure
> > everything that is needed is in place so that vendors can solve that.
> 
> It can't even be seen by the X server until the rendering is complete.
> When using 'automatic' update mode, there isn't an external application 
> waiting for the event; the X server updates the screen directly.

Ah right, good point.

> > One solution would be for the direct rendering client to send private
> > protocol to the X server as soon as the rendering is sent to the hw.
> 
> Sure; just as long as the X server could then block awaiting completion.
> 
> > BeginComposite/EndComposite bracketing would facilitate that (it
> > would be BeginComposite's job to make sure the hw had completed).
> 
> There's no need for these extra requests -- the X server just needs to
> block when using the indicated source window buffer.  This way, the X 
> server can actually pend lots of other parts of the compositing operation 
> and only when the affected window finally comes into play will the X 
> server block.

I'm debating whether it is better for the X server to not even know
of the damage until it has completed in hardware, or if it is
better to tell the X server as soon as the rendering has kicked off,
and then require X to wait for completion only when it needs to
use the drawable as a source.  The former will avoid blocking in
the server, while the latter may reduce latencies... that will
require some experimentation.

> I just thought of another case here -- we want to allow for direct 
> rendering compositing managers as well.  That will require inter-client
> synchronization along the same lines...

This introduces the problem of how to get the pixmap data to the
client efficiently.  That's a whole separate thread.

> >     glxgears is then redrawn (and swapped) before the compositing
> >     is performed.  When the compositing is performed, the xterm
> >     and the portion of the glxgears window beneath the xterm are
> >     recomposited into the backing pixmap, which is then blitted to
> >     the visible screen.  At this point, we have a tear between the
> >     portion of the glxgears window that is not beneath the xterm
> >     and the part that is (the part that is beneath the xterm is
> >     from glxgear's new frame, while the part not beneath the xterm
> >     is from the old frame).
> 
> The window of vulnerability isn't as long as you fear -- the compositing 
> manager can always use the damaged region of each window precisely at the 
> time of the compositing operation, without reference to any events it has 
> received.  That's because the damage accumulates inside X server regions
> where it can be used to compute correct updates.

OK, I think that makes sense.

> As long as the compositing manager holds the server grabbed (which
> presumably locks out direct clients as well) while it updates the screen,
> there shouldn't be any tearing.  No need to drain the event queue or 
> anything else so dramatic.

Yes, if the composite manager grabs the server while updating the
screen, then everything will be fine.  Your sample xcompmgr doesn't
grab the server when updating the screen, and I expect many future
composite managers will use xcompmgr as a starting point.

> > > information related to a specific drawable.  Any future requests for 
> > > contents from that drawable must delay until that damage has actually 
> > > occurred.
> > 
> > Right, but how is that enforced?  Who delays until the damage has
> > actually occurred?
> 
> The X server would have to stall waiting for the swap to complete. It 
> would "know" to do this because the direct client would have indicated 
> that the swap was queued to the hardware.

OK, so X drivers would have to hook into this and stall when
appropriate.

> > True, but window managers can't cause video memory to be freed,
> > which would be really nice to do when you are transitioning into a
> > fullscreen application.
> 
> They can free the extra buffers used for Composite, and the X server can 
> migrate less used pixmaps from the video card.

That seems possible.  However, that seems like a lot to ask of all
window managers.  Would common functionality like that be better
contained within an X server extension?


> > Even the RandR implementation naively leaves the video memory allocated for
> > the largest possible root window size.
> 
> Not in kdrive.

OK, that's something I'd like to fix in the monolithic server.

> > OK; how does a driver differentiate the per-window pixmaps from
> > regular pixmaps?
> 
> The driver can see them associated with windows by wrapping 
> SetWindowPixmap.

OK.

> > So if the X server might start compositing, then the driver can't advertise
> > the overlay port; is that correct?
> 
> It could pretend the overlay port was busy for new apps and silently
> translate an existing overlay application to textures.  I don't quite 
> know; I use overlay video with composite now and it works as long as the 
> windows are aligned on the screen correctly.  I'd like to make that 
> possible in the future as well, but I'm not quite sure how to do that.

Interesting; this will require some more thought.

Thanks,
- Andy



> -keith
> 
> 
>