Bug 95370

Summary: [965GM] piglit fails many tests after a5d7e144
Product: Mesa Reporter: Mark Janes <mark.a.janes>
Component: Drivers/DRI/i965Assignee: Ian Romanick <idr>
Status: RESOLVED FIXED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium    
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Mark Janes 2016-05-12 20:51:24 UTC 
Most of piglit fails pixel comparisons for 965GM at this commit.  Strangely, a similar 965G system continues to pass all tests:

--------------------------------------------------------
a5d7e144eaf43fee37e6ff9e2de194407087632b
Author:     Connor Abbott <cwabbott0@gmail.com>
AuthorDate: Mon Aug 3 17:44:08 2015 -0700

i965/fs: extend exec_size halving in the generator

The HW has a restriction that only vertical stride may cross register
boundaries. Previously, this only mattered for SIMD16 instructions where
we needed to use the same regioning parameters as the equivalent SIMD8
instruction but double the exec size. But we need to do the same
splitting for 64-bit instructions as well as instructions with a stride
of 2 (which effectively consume 64 bits per element). Fix up the code to
do the right thing instead of special-casing SIMD16.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

--------------------------------------------------------

Sample test output:
/tmp/build_root/m64/lib/piglit/bin/shader_runner /tmp/build_root/m64/lib/piglit/generated_tests/spec/glsl-1.10/execution/interpolation/interpolation-none-gl_FrontColor-smooth-none.shader_test -auto
Probe color at (111,55)
  Expected: 0.666667 0.166667 0.166667 1.000000
  Observed: 1.000000 0.913726 0.000000 1.000000
Probe color at (159,45)
  Expected: 0.500000 0.166667 0.333333 1.000000
  Observed: 1.000000 1.000000 0.000000 1.000000
Probe color at (166,83)
  Expected: 0.333333 0.333333 0.333333 1.000000
  Observed: 0.584314 1.000000 0.000000 1.000000
Comment 1 Mark Janes 2016-05-12 23:37:29 UTC 
subsequent re-bisection confirms the commit that introduces this failure.
Comment 2 Matt Turner 2016-05-13 03:24:51 UTC 
Yep, the test Mark gives as an example has this diff:

-add(16)         g6<1>F          g10<8,8,1>UW    -g1<0,1,0>F     { align1 compr };
-add(16)         g8<1>F          g12<8,8,1>UW    -g1.1<0,1,0>F   { align1 compr };
+add(16)         g6<1>F          g10<16,16,1>UW  -g1<0,1,0>F     { align1 compr };
+add(16)         g8<1>F          g12<16,16,1>UW  -g1.1<0,1,0>F   { align1 compr };

16,16,1 isn't a valid region. Provoking some undefined behavior, I think.
Comment 3 Kenneth Graunke 2016-05-13 07:03:05 UTC 
Here's a patch that seems to work:
https://lists.freedesktop.org/archives/mesa-dev/2016-May/116646.html
Comment 4 Mark Janes 2016-05-13 16:13:07 UTC 
Mesa's CI has always treated 965G and 965GM as identical platforms.  Is there any explanation why this only on 965GM?

Unfortunately, we only have one of each platform.  Testing them independently will limit throughput for the CI.
Comment 5 Mark Janes 2016-05-27 23:45:44 UTC 
fixed by dc657a8201fe942fce2c68835f1ee52b348e52f0

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.