[Mesa-dev] [PATCH] st/dri: Add an option to always request a front buffer from the loader

Thomas Hellstrom thellstrom at vmware.com
Mon Sep 18 20:40:55 UTC 2017


On 09/18/2017 01:10 PM, Thomas Hellstrom wrote:
> On 09/18/2017 12:43 PM, Eric Anholt wrote:
>> Thomas Hellstrom <thellstrom at 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
>
>



More information about the mesa-dev mailing list