It turned out that the problem described below occured because for
pixmaps, dri2 glXWaitX() is a no-op: The X server side doesn't create a
fake front, and the dri2 glx code hence can't send a dri2CopyRegion from
front to fake front.
I'm not sure what the best way to fix this is,
but if I don't receive any better suggestions, I'll make a patch against
the server dri2 code to automatically request a fake front not only for
windows but also for pixmaps. In the pixmap case, the drivers will point
the fake front to the real front.
/Thomas
On 06/07/2011 10:17 AM, Thomas Hellstrom wrote:
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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
