Bug 95370 - [965GM] piglit fails many tests after a5d7e144
Summary: [965GM] piglit fails many tests after a5d7e144
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
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: 2016-05-12 20:51 UTC by Mark Janes
Modified: 2016-05-27 23:45 UTC (History)
0 users

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 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


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