Bug 94254 - [llvmpipe] [softpipe] piglit read-front regression
Summary: [llvmpipe] [softpipe] piglit read-front regression
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: 11.2
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2016-02-22 22:44 UTC by Vinson Lee
Modified: 2016-02-24 15:58 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vinson Lee 2016-02-22 22:44:50 UTC
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
Comment 1 Brian Paul 2016-02-23 20:15:51 UTC
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.
Comment 2 Nanley Chery 2016-02-23 22:06:02 UTC
(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.
Comment 3 Brian Paul 2016-02-24 01:12:20 UTC
Patch posted to mesa-dev.  Vinson, I'm not sure which driver you were using.  Maybe you can test with the patch.
Comment 4 Brian Paul 2016-02-24 15:58:30 UTC
Fixed by 83b589301f4a150f4b1b13fd3ffd9f6d98ee654683b589301f4a150f4b1b13fd3ffd9f6d98ee6546


bug/show.html.tmpl processed on Jan 16, 2017 at 17:21:20.
(provided by the Example extension).