[Mesa-dev] OpenGL compositors and glxWaitX()
thellstrom at vmware.com
Tue Jun 7 01:17:30 PDT 2011
On 06/06/2011 05:20 PM, James Jones wrote:
> On 6/6/11 2:09 AM, "Thomas Hellstrom"<thellstrom at vmware.com> wrote:
>> 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
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
> 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.
Well unfortunately I need to cope with whatever's out there...
>> Any input appreciated.
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
More information about the mesa-dev