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 <[email protected]> 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. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
