[Mesa-dev] soft/llvmpipe front buffer access and piglit regressions

Brian Paul brianp at vmware.com
Mon Nov 9 12:36:09 PST 2015


On 11/09/2015 01:15 PM, Dave Airlie wrote:
> On 10 November 2015 at 00:30, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 09.11.2015 um 04:44 schrieb Dave Airlie:
>>> So it appears my patch to enable front buffer access on soft/llvmpipe
>>> causes some piglit regressions. However these are due to piglit having
>>> undefined behaviour where it doesn't create a window but has tests
>>> requiring a front buffer. The new code does an XGetImage on the front
>>> buffer and when it fails all sorts of bad things tend to happen. I
>>> don't think there is a way to check if we have a window mapped inside
>>> Mesa to avoid this path.
>>>
>>> swrast suffers from the same failure pattern in a number of tests when
>>> run with -auto.
>>>
>>> I'm not sure what to do here, the patch is making the driver
>>> conformant and is fixing a missing
>>> feature being used by OpenGL apps (gtk).
>>>
>>> I can probably make it fail more gracefully (llvmpipe deadlocks on the
>>> Xlib error path inside it's rasteriser threads), but I'm not sure I
>>> want to go back to the old behaviour just to satisfy piglit's
>>> requirement to do undefined things.
>>>
>>
>> I don't really understand all this interface stuff, however it feels
>> wrong to me that we have to care in the driver for something which you
>> say is totally bogus. Couldn't that be handled outside? Albeit I don't
>> really understand what exactly happens in the first place.
>
> Well the bug is piglit runs tests without mapping the window. On DRI2
> this works as we have the fake front buffer, so reading the front doesn't
> require content on the screen. However it's really undefined behaviour for GL.
>
> Now with drisw you use GetImage/PutImage to get things from the real front
> buffer. However if the window is never mapped, these will return BadMatch,
> and things fall over. However we have real apps wanting proper front buffer
> interactions, and we have piglit wanting the undefined behaviour.

The old xlib/swrast code has an X error handler to catch failing 
XGetImage calls.  We probably need something like that.  See 
xm_buffer.c's xmesa_MapRenderbuffer().

It also sounds like the piglit tests in question need to be fixed somehow.

-Brian


>
> I think I'll decide in favour of the former, but it might be a bit of a shock to
> people who run piglit runs and things start regressing.
>
> Dave.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



More information about the mesa-dev mailing list