| Summary: | [softpipe] piglit drawbuffer-modes regression | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Vinson Lee <vlee> |
| Component: | Drivers/Gallium/softpipe | Assignee: | mesa-dev |
| Status: | RESOLVED MOVED | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | CC: | airlied |
| Version: | 11.1 | Keywords: | bisected, regression |
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
mesa: 1e8435ce0cce671024ebf9c5465ea8bdcb563b69 (master 11.3.0-devel) This regression is still present. The reason this has stopped working is because the drawable is not refreshed with the data written to the front buffer before reading its pixels. Since https://cgit.freedesktop.org/mesa/mesa/commit/?id=2b676570960277d47477822ffeccc672613f9142, the drawable act as the source for reading the front buffer data. Since this test writes directly to the front buffer, all operations have to be flushed and reflected by the drawable before attempting to read it. On a explicit flush, the state tracker take care of refreshing the drawable with the front buffer data after flushing (see st_glFlush). But in the drawbuffer-modes test, the flush is done implicitly by calling glReadPixels and is handled by the soft/llvm pipes themselves (see *pipe_transfer_map). The drawable does not get refreshed in this case, therefore when the test reads the front buffer data, it reads garbage. It is tricky to refresh the drawable after flushing from the pipes because at that level, we don't know the nature of the resource being mapped for reading (front buffer, back buffer...). Unless I miss something? -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/215. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
mesa: 3694d58e6c4a39bd84e8aef0d8e67c3ae9447f33 (master 11.1.0-devel) $ ./bin/drawbuffer-modes -auto Probe color at (20,20) Expected: 0.100000 0.200000 0.300000 1.000000 Observed: 1.000000 1.000000 1.000000 1.000000 Probe color at (20,20) Expected: 0.300000 0.400000 0.500000 1.000000 Observed: 1.000000 1.000000 1.000000 1.000000 Probe color at (20,20) Expected: 0.400000 0.500000 0.600000 1.000000 Observed: 1.000000 1.000000 1.000000 1.000000 Probe color at (20,20) Expected: 0.600000 0.700000 0.800000 1.000000 Observed: 1.000000 1.000000 1.000000 1.000000 glDrawBuffer(GL_NONE) modifies GL_FRONT_LEFT buffer PIGLIT: {"result": "fail" } 2b676570960277d47477822ffeccc672613f9142 is the first bad commit commit 2b676570960277d47477822ffeccc672613f9142 Author: Dave Airlie <airlied@redhat.com> Date: Fri Oct 9 01:38:08 2015 +0100 gallium/swrast: fix front buffer blitting. (v2) So I've known this was broken before, cogl has a workaround for it from what I know, but with the gallium based swrast drivers BlitFramebuffer from back to front or vice-versa was pretty broken. The legacy swrast driver tracks when a front buffer is used and does the get/put images when it is mapped/unmapped, so this patch attempts to add the same functionality to the gallium drivers. It creates a new context interface to denote when a front buffer is being created, and passes a private pointer to it, this pointer is then used to decide on map/unmap if the contents should be updated from the real frontbuffer using get/put image. This is primarily to make gtk's gl code work, the only thing I've tested so far is the glarea test from https://github.com/ebassi/glarea-example.git v2: bump extension version, check extension version before calling get image. (Ian) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91930 Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by: Dave Airlie <airlied@redhat.com> :040000 040000 1726a5f7f01d9ae1fc76de431bb24cce16cf69ee 75f18ded95766bac58d0c37c96ffa071a4a32071 M include :040000 040000 ee333146b90c837460ceab252445e3b38fc528d5 dc0656326c3fb9750fda1f6d3e75aeed99003bc6 M src bisect run success