[Mesa-dev] OpenGL compositors and glxWaitX()

[Thomas Hellstrom]

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
>
>