[Mesa-dev] OpenGL compositors and glxWaitX()

[Michel Dänzer]

On Die, 2011-06-07 at 10:17 +0200, Thomas Hellstrom wrote: 
> On 06/06/2011 05:20 PM, James Jones wrote:
> > On 6/6/11 2:09 AM, "Thomas Hellstrom"<thellstrom at vmware.com>  wrote:
> >
> >    
> >> Hi!
> >>
> >> While trying to improve the vmwgfx X driver to better cope with OpenGL
> >> compositors, I noticed that compiz never calls glxWaitX() to make sure
> >> the pixmaps that it textures from are updated.
> >>
> >> Since we migrate X rendered data to the dri2 drawables only on demand,
> >> we miss a lot of data.
> >>
> >> Googling for this it seems this has been up for discussion before, and
> >> it appears glxWaitX() is not used because either
> >>
> >> 1) it's considered to be a performance hit.
> >> 2) it only affects the drawables currently bound by the glx context
> >> issuing the command.
> >>
> >> While 1) may be true,
> >>      
> > A properly implemented glXWaitX shouldn't cause much if any noticeable
> > performance hit.  However, I don't know how optimal existing implementations
> > are.
> >    
> 
> Well, something must tell X to flush its rendering buffers and (in the 
> direct rendering case) wait until the X server notifies that it has done 
> so. So there is at least an X server roundtrip and a corresponding 
> client stall, which would degrade client performance if it is CPU bound.
> 
> >    
> >> reading the glx specification it appears to me
> >> that 2) does not hold, even if it appears like some dri2 server side
> >> implementations do not flush all drawables. Furthermore it appears to me
> >> to be a requirement for correctness to call glXWaitX before using the
> >> pixmap content.
> >>
> >> Does anyone on the list have more info on this, and whether not calling
> >> glxWaitX() is the common usage pattern by other compositors?
> >>      
> > 2) is not quite true, but glXWaitX is still not sufficient.  glXWaitX only
> > waits for rendering done on the specified display to complete.  When using
> > composite managers, all the rendering you want to wait for in the composite
> > manager happens on other display connections (the client apps).  glXWaitX is
> > specified to, at best, be equivalent to XSync().
> >
> > I've been told DRI2 based drivers implicitly synchronize texture from pixmap
> > operations with X rendering
> 
> I'm not sure how that will happen, unless the X driver flushes all 
> rendering immediately or at least when the server executes 
> DamageProcessPending() following the rendering operation. If I'm not 
> missing something, a driver that relies on, for example, a block handler 
> or glXWaitX to migrate software rendered stuff to the dri2 drawable will 
> fail.

The major DRI2 drivers achieve this by flushing rendering to the
hardware in a FlushCallback, which is called before events are sent to
clients (so it always happens before the compositing manager gets the
damage events).

The Gallium xorg state tracker could probably do something like that as
well.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer