Bug 90902 - [bsw][regression] dEQP: "Found invalid pixel values"
Summary: [bsw][regression] dEQP: "Found invalid pixel values"
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 10.6
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-08 19:22 UTC by Brian Wilson
Modified: 2016-03-26 09:57 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Brian Wilson 2015-06-08 19:22:57 UTC
Hardware: BSW RVP

Bug detailed description
=======
The following drawElements tests appear to have regressed between Mesa 10.5.0 and 10.6.0:
- dEQP-GLES3.functional.rasterization.fbo.rbo_multisample_4.interpolation.lines_wide
- dEQP-GLES3.functional.rasterization.fbo.rbo_multisample_max.interpolation.lines_wide

Cases where the test passed:
- ChromeOS on BSW w/ mid-November commit of Mesa (on platforms Haswell, Baytrail, Broadwell and Braswell - not sure of the commit on this)
- ChromeOS w/ mesa commit we were trying to move to (c2a0600 i965: Don't set NirOptions for stages that will use the vec4 backend.) on platforms Haswell, Baytrail, Broadwell - possible BSW-only regression

Cases where the test failed:
- ChromeOS build (bsw system) from current Google upstream tree (same mid-November Mesa commit)
- Upstream Linux (bsw system) using Mesa commit from 2014-11-24; commit ID: c88385603ae8d983314b736a9459bbf7d002cf11
- ChromeOS build (bsw system) w/ mesa commit we were trying to move to (c2a0600 i965: Don't set NirOptions for stages that will use the vec4 backend.)
- Upstream Linux (bsw system) using the mesa commit we were trying to move to
- Upstream Linux (bsw system) using current ToT mesa (as of 5/20/15)

Reproduce Steps
==============
1. Run indicated drawElements test with indicated version of Mesa or ToT Mesa
2. Compare test results against older (mid-November) Mesa commit

Expected Result
=============
- No failure with current ToT Mesa

Actual Result
===========
- "129 invalid pixel(s) found"

Full diff between "before" test result and "after" test result
**********
< <Text>ALIASED_LINE_WIDTH_RANGE = [1, 7.875]</Text>
—
> <Text>ALIASED_LINE_WIDTH_RANGE = [1, 40]</Text>
25c25,79
< <Text>Line width 10 not supported, skipping iteration.</Text>
—
> <Text>Generated vertices:</Text>
> <Text> (0.506412, 0.560052, 0, 1), color= (1, 0, 0, 1)</Text>
> <Text> (-0.592623, 0.70225, 0, 1), color= (0, 1, 0, 1)</Text>
> <Text> (-0.835676, 0.874938, 0, 1), color= (0, 0, 1, 1)</Text>
> <Text> (-0.143044, 0.0755453, 0, 1), color= (1, 0, 0, 1)</Text>
> <Text> (0.256429, -0.591691, 0, 1), color= (0, 1, 0, 1)</Text>
> <Text> (-0.0305212, -0.827533, 0, 1), color= (0, 0, 1, 1)</Text>
> <Text>Verifying rasterization result. Native format is RGB888</Text>
> <Text>Found an invalid pixel at (132,23)
> Pixel color: RGBA(0, 35, 188, 255)
> Native color: (0, 35, 188)
> Allowed error: (0, 0, 0)
> Reference native color min: (0, 35, 209)
> Reference native color max: (0, 45, 222)
> Reference native float min: (0, 35.262, 209.348)
> Reference native float max: (0, 44.3039, 221.181)
> Fmin: (0, 0.138282, 0.820972)
> Fmax: (0, 0.173741, 0.867377)
> </Text>
> <Text>Found an invalid pixel at (126,29)
> Pixel color: RGBA(0, 31, 192, 255)
> Native color: (0, 31, 192)
> Allowed error: (0, 0, 0)
> Reference native color min: (0, 30, 213)
> Reference native color max: (0, 40, 226)
> Reference native float min: (0, 30.952, 213.751)
> Reference native float max: (0, 39.8586, 225.585)
> Fmin: (0, 0.12138, 0.838239)
> Fmax: (0, 0.156308, 0.884647)
> </Text>
> <Text>Found an invalid pixel at (131,33)
> Pixel color: RGBA(0, 61, 162, 255)
> Native color: (0, 61, 162)
> Allowed error: (0, 0, 0)
> Reference native color min: (0, 64, 179)
> Reference native color max: (0, 75, 192)
> Reference native float min: (0, 64.7962, 179.538)
> Reference native float max: (0, 74.5473, 191.223)
> Fmin: (0, 0.254103, 0.704071)
> Fmax: (0, 0.292342, 0.749893)
> </Text>
> <Text>Found an invalid pixel at (132,34)
> Pixel color: RGBA(0, 67, 156, 255)
> Native color: (0, 67, 156)
> Allowed error: (0, 0, 0)
> Reference native color min: (0, 72, 172)
> Reference native color max: (0, 83, 184)
> Reference native float min: (0, 72.3003, 172.034)
> Reference native float max: (0, 82.1287, 183.641)
> Fmin: (0, 0.283531, 0.674643)
> Fmax: (0, 0.322073, 0.720162)
> </Text>
> <Text>Omitted 12 pixel error description(s).</Text>
> <Text>16 invalid pixel(s) found.</Text>
> <ImageSet Name="Verification result" Description="Result of rendering" />
36c90,103
< <Text>No invalid pixels found.</Text>
—
> <Text>Found an invalid pixel at (208,30)
> Pixel color: RGBA(0, 1, 31, 255)
> Expected background color.
> </Text>
> <Text>Found an invalid pixel at (209,30)
> Pixel color: RGBA(0, 3, 93, 255)
> Expected background color.
> </Text>
> <Text>Found an invalid pixel at (204,31)
> Pixel color: RGBA(0, 7, 89, 255)
> Expected background color.
> </Text>
> <Text>Omitted 125 pixel error description(s).</Text>
> <Text>129 invalid pixel(s) found.</Text>
39,40c106,107
< <Number Name="TestDuration" Description="Test case duration in microseconds" Tag="Time" Unit="us">183831</Number>
< <Result StatusCode="Pass">Pass</Result>
—
> <Number Name="TestDuration" Description="Test case duration in microseconds" Tag="Time" Unit="us">503174</Number>
> <Result StatusCode="Fail">Found invalid pixel values</Result>
Comment 1 Kenneth Graunke 2015-06-08 19:43:52 UTC
For future reference, please set the component for Intel driver related bugs to "Drivers/DRI/i965".  "GLX" is the window system integration for X, and this is almost certainly not a GLX bug :)
Comment 2 Brian Wilson 2015-06-08 20:32:18 UTC
Sorry about that. I had intended "Mesa Core" (and it sounds like that wasn't the proper choice either), which is directly adjacent to GLX in the dropdown. :)
Comment 3 Kenneth Graunke 2015-06-08 23:27:52 UTC
FWIW, you can make these tests pass by reverting f3b709c0, which increased the maximum supported line width on BSW.  I don't think there's any particular benefit to increasing it (nobody actually cares about having a large antialiased line width).

We should probably understand why it breaks, though.
Comment 4 Kenneth Graunke 2015-06-08 23:33:42 UTC
https://bugs.freedesktop.org/show_bug.cgi?id=90749 may also be related.
Comment 5 Alejandro Piñeiro (freenode IRC: apinheiro) 2015-07-31 11:21:38 UTC
I was not able to reproduce it on a hsw machine, so as comment 0 suggest, probably this was a bsw regression. I edited the summary to reflect that.

Having said so ...

(In reply to Kenneth Graunke from comment #4)
> https://bugs.freedesktop.org/show_bug.cgi?id=90749 may also be related.

that bug is already fixed, and as mentioned, seems related. Please try to reproduce the bug again to confirm if it was solved or not.
Comment 6 Kenneth Graunke 2016-03-26 09:57:24 UTC
The offending patch got reverted a long time ago; these tests seem to pass now.


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.