On 10 November 2015 at 06:36, Brian Paul <bri...@vmware.com> wrote: > On 11/09/2015 01:15 PM, Dave Airlie wrote: >> >> On 10 November 2015 at 00:30, Roland Scheidegger <srol...@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().
The DRI swrast driver on the other hand doesn't. Granted it also fails all these tests with XGetImage.The question is whether using an error handler is prone to all sorts of race conditions and other problems, I'm guessing it would be. > > It also sounds like the piglit tests in question need to be fixed somehow. It's all of piglit, see the nvidia guys talking about pixel ownership as well. piglit executes tests in a undefined environment with -auto wrt OpenGL, it works for us now on DRI2. Granted even with that fixed, some tests do fail, due to tests alpha channel on the front buffer, which we sort of lose when we use Put/GetImage from what I can see. Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
