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