[Mesa-dev] [RFC PATCH] dri3: Sync after buffer swaps with glXSwapBuffers

Thomas Hellstrom thellstrom at vmware.com
Tue Jun 20 08:56:41 UTC 2017


On 06/20/2017 07:17 AM, Thomas Hellstrom wrote:
> On 06/20/2017 05:09 AM, Michel Dänzer wrote:
>> On 20/06/17 03:00 AM, Thomas Hellstrom wrote:
>>> On 06/19/2017 07:44 PM, Thomas Hellstrom wrote:
>>>> On 06/19/2017 07:26 PM, Eric Anholt wrote:
>>>>> Thomas Hellstrom <thellstrom at vmware.com> writes:
>>>>>
>>>>>> Applications calling glXSwapBuffers should be able to expect that 
>>>>>> any X
>>>>>> rendering submitted after the call to glXSwapBuffers returns should
>>>>>> be ordered
>>>>>> with respect to the glXSwapBuffers call. (For example piglit reading
>>>>>> out from
>>>>>> a window). This appears not to be the case at least with the current
>>>>>> server
>>>>>> side present extension implementation.
>>>>>>
>>>>>> Fixes piglit glx-multithread-texture on svga/vmwgfx.
>>>>> I don't believe that's true.  From the 1.4 spec:
>>>>>
>>>>> "glXSwapBuffers is in the X stream if and only if the display and
>>>>> drawable are not those belonging to the calling thread’s current
>>>>> context;"
>>>>>
>>>>> So if you want to sync X rendering after swap, you need 
>>>>> glXWaitForGL().
>>>> Hmm. You're right.
>>>>
>>>> Then I guess we need to fix both dri3's glXWaitGL to include the wait
>>>> for sbc and in addition fix piglit to call glXWaitGL.
>>>> Another complication is in the glXWaitGL man page, which states that
>>>> glFinish can be used instead of glXWaitGL and I guess that might be a
>>>> bit problematic.
>>> Actually, looking into the piglit code it uses glReadPixels. It doesn't
>>> read from X, which means the problem is probably that GL is 
>>> occasionally
>>> reading from the front before the swap has been posted to the 
>>> device. So
>>> the patch might be correct after all but the fix is in the fact it
>>> introduces a GL stream read barrier rather than an X barrier. But since
>>> it also introduces an X barrier, it corrects the glXWaitGL behavior as
>>> well.
>> While your patch fixes the problem, I think it's not quite correct (the
>> same problem could happen with target_msc != 0) and overkill at the same
>> time. Instead, we should wait for pending presentations to complete
>> before using the front buffer.
>>
>>
> So glXSwapBuffersMscOML is also a GL stream barrier then I guess.
>
> So to summarize we need to implement a wait for outstanding buffer 
> swaps in the following cases?
>
> 1) Before a readPixels() on the front buffer.
> 2) During a glFinish(),
> 3) During a glXWaitGL()
> 4) Before setting the front buffer as the GL draw buffer or at 
> drawable validate time if the front buffer is the current GL draw buffer
>
> Thomas
>
So I have a dri3 + gallium implementation that does the above. Seems to 
work, and there should be no X protocol overhead unless the above 
situations are hit. I've also included the copyTex[Sub]Image functions 
in 1). I'll clean it up and post it for review.

That said, the piglit failure I started out with was actually due to a 
piglit test bug. It was reading out from a newly swapped back-buffer, 
and the reason my previous patch fixed it was probably that it enabled 
the previous back buffer to be reused.

/Thomas




More information about the mesa-dev mailing list