[Mesa-dev] OpenGL compositors and glxWaitX()

[James Jones]

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.

> 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, but if you would like to do explicit
synchronization, please check out the X Fence Sync work I've done (X
Synchronization extension version 3.1, GL_EXT_x11_sync_object), which can be
used to solve the race condition you describe.

Thanks,
-James

> Any input appreciated.
> Thanks,
> Thomas
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

nvpublic