On 09/18/2017 01:10 PM, Thomas Hellstrom wrote:
On 09/18/2017 12:43 PM, Eric Anholt wrote:
Thomas Hellstrom <thellst...@vmware.com> writes:
When an application decides to read from the front buffer of a window,
typically a fake front is created and initialized with the real
front window
contents. However, if there was a window manager reparenting
operation between
the last swapbuffer and the read the real front window contents
would be
invalid. This hurts piglit applications that read from the front.
So add an option to always request a front buffer from the dri
loader. This
makes the fake front initialization typically happen before any
drawing- or
swapbuffer operations take place and, as a result, piglit results
from tests
that read from the frontbuffer become robust with dri3.
While there is a memory usage overhead with this option enabled, the
performance overhead with dri3 should be minimal.
With dri2 the situation is different and require more work.
Instead of hacking the GL driver to have a special path for these tests,
could we make those piglit tests loop and try again when they get a
failure but have an expose event pending? That should work for everyone
and handle the race properly.
Given that this is actually what's happening (Keithp thinks that's not
really the case), I think
finding and changing all potentially affected piglit tests is really
not worth the effort.
Actually, that wouldn't bee to hard. A change in the piglit mainloop.
I'll take a look at that.
Still confused as to what might be causing the initial problem, though.
Thomas
/Thomas
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
