On 06/06/2011 05:20 PM, James Jones wrote:
On 6/6/11 2:09 AM, "Thomas Hellstrom"<thellst...@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.
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...
Thanks,
Thomas
Thanks,
-James
Any input appreciated.
Thanks,
Thomas
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
nvpublic
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
