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 <thellst...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
