| Summary: | [llvmpipe] [softpipe] piglit read-front regression | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Vinson Lee <vlee> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | CC: | brianp, idr, jfonseca, marta.lofstedt, nanleychery |
| Version: | 11.2 | Keywords: | bisected, regression |
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
I'm looking into this. Probably the same as bug 94257 and 94253. The problem is glReadPixels is effectively a no-op since the front renderbuffer dimensions are 0 x 0 because the renderbuffer hasn't been validated yet. (In reply to Brian Paul from comment #1) > I'm looking into this. Probably the same as bug 94257 and 94253. > > The problem is glReadPixels is effectively a no-op since the front > renderbuffer dimensions are 0 x 0 because the renderbuffer hasn't been > validated yet. I'm interested in your findings. I've been looking into this since this morning and was thinking that we could add an extra condition to the if (rb) predicate in _mesa_clip_readpixels(), but I don't know yet if this is the right fix. Patch posted to mesa-dev. Vinson, I'm not sure which driver you were using. Maybe you can test with the patch. Fixed by 83b589301f4a150f4b1b13fd3ffd9f6d98ee654683b589301f4a150f4b1b13fd3ffd9f6d98ee6546 |
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: 2999257e0fe703f73d32620fed88040d29ac5bac (master 11.3.0-devel) $ ./bin/read-front -auto Probe color at (0,0) Expected: 0.000000 0.000000 1.000000 Observed: -0.000000 0.000000 0.000000 Probe color at (0,80) Expected: 0.000000 1.000000 0.000000 Observed: -0.000000 0.000000 0.000000 PIGLIT: {"result": "fail" } 605832736a6d9427ad894d403cceeb74a5b18dc1 is the first bad commit commit 605832736a6d9427ad894d403cceeb74a5b18dc1 Author: Nanley Chery <nanley.g.chery@intel.com> Date: Fri Feb 5 16:21:33 2016 -0800 mesa/readpix: Clip ReadPixels() area to the ReadBuffer's The fast path for Intel's ReadPixels() unintentionally omits clipping the specified area to a valid one. Rather than clip in various corner-cases, perform this operation in the API validation stage. The bug in intel_readpixels_tiled_memcpy() showed itself when the winsys ReadBuffer's height was smaller than the one specified by ReadPixels(). yoffset became negative, which was an invalid input for tiled_to_linear(). v2: Move clipping to validation stage (Jason) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92193 Reported-by: Marta Löfstedt <marta.lofstedt@intel.com> Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org> Signed-off-by: Nanley Chery <nanley.g.chery@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> :040000 040000 0f8b2af912e9f15eb83e20c0dfbf625fc7577e6b 08261118001653553be85da5b3d8f9bd3a7ad6f8 M src bisect run success