[Mesa-dev] Fixing dri2 glXWaitX() for pixmaps WAS OpenGL compositors and glxWaitX()
thellstrom at vmware.com
Thu Jun 9 14:49:16 PDT 2011
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.
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"<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
> 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
>> waits for rendering done on the specified display to complete. When
>> composite managers, all the rendering you want to wait for in the
>> 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
>> 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...
>>> Any input appreciated.
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev