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

[Thomas Hellstrom]

On 09/18/2017 12:43 PM, Eric Anholt wrote:

Thomas Hellstrom  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.


/Thomas


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Thomas Hellstrom]

On 09/18/2017 01:10 PM, Thomas Hellstrom wrote:

On 09/18/2017 12:43 PM, Eric Anholt wrote:

Thomas Hellstrom  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

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

[Thomas Hellstrom]

Hi.

On 09/18/2017 12:18 PM, Keith Packard wrote:

Thomas Hellstrom  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.

What do you mean by 'invalid'? On a running desktop, reparenting is
typically done before the window gets mapped, so there shouldn't be
*anything* done to the window by this operation. If you restart the
window manager, it will have to reparent all existing windows, which
looks like an unmap followed by a map, but those operations all do well
defined things to the window contents.


Hmm,

So what's happening (timing dependent) is that a window that's supposed 
to be all red after a swapbuffer instead has black borders at the bottom 
and to the right.
So my guess as to what was happening was the server executing the 
swapbuffer, then the window manager would reparent and draw window 
decorations.


But if that's not the case, any idea what might be causing this? It 
happens with both dri2 and dri3, more frequently with dri3.


/Thomas



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Eric Anholt]

Thomas Hellstrom  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

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

[Keith Packard]

Thomas Hellstrom  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.

What do you mean by 'invalid'? On a running desktop, reparenting is
typically done before the window gets mapped, so there shouldn't be
*anything* done to the window by this operation. If you restart the
window manager, it will have to reparent all existing windows, which
looks like an unmap followed by a map, but those operations all do well
defined things to the window contents.

-- 
-keith


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev