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

[Thomas Hellstrom]

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