[Mesa-dev] Fixing dri2 glXWaitX() for pixmaps WAS OpenGL compositors and glxWaitX()

[Thomas Hellstrom]

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"<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.
>
> 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 at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>> nvpublic
>>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev