Bug 87389 - [ILK] HL2 & CS:Source water shader broken
Summary: [ILK] HL2 & CS:Source water shader broken
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 10.4
Hardware: Other All
: medium normal
Assignee: Chris Forbes
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Blocks: 77449
  Show dependency treegraph
Reported: 2014-12-17 00:15 UTC by Chris Forbes
Modified: 2016-02-15 05:27 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

INTEL_DEBUG=fs,ann output on ILK (52.36 KB, text/plain)
2015-03-08 02:54 UTC, Chris Forbes

Description Chris Forbes 2014-12-17 00:15:06 UTC
SIMD16 water fragment shader produces garbage for some pixels on Ironlake.

Bisected to:

commit 2ec161b2396b08341264965a5825152784b54549
Refs: 10.2-branchpoint-3378-g2ec161b
Author:     Jason Ekstrand <jason.ekstrand@intel.com>
AuthorDate: Mon Oct 6 21:27:06 2014 -0700
Commit:     Jason Ekstrand <jason.ekstrand@intel.com>
CommitDate: Fri Oct 24 16:24:05 2014 -0700

    i965/fs: Don't interfere with too many base registers

    On older GENs in SIMD16 mode, we were accidentally building too much
    interference into our register classes.  Since everything is divided by 2,
    the reigster allocator thinks we have 64 base registers instead of 128.
    The actual GRF mapping still needs to be doubled, but as far as the ra_set
    is concerned, we only have 64.  We were accidentally adding way too much

This commit isn't actually broken -- but before this we failed to compile this shader as SIMD16.

The SIMD8 version of the shader works correctly (we get correct rendering with INTEL_DEBUG=no16)
Comment 1 Ian Romanick 2015-02-11 23:18:13 UTC
Any ideas what's wrong in the SIMD16 version of the shader?  Are we not enforcing some other ILK SIMD16 restriction?
Comment 2 Matt Turner 2015-02-11 23:27:29 UTC
INTEL_DEBUG=fs output would be very helpful.
Comment 3 Chris Forbes 2015-03-08 02:54:37 UTC
Created attachment 114129 [details]
INTEL_DEBUG=fs,ann output on ILK
Comment 4 Kenneth Graunke 2015-03-08 08:33:31 UTC
Chris and I noticed that the sampler message type appears to be totally bogus - it says "sample_l" instead of "sample" sometimes.  This turned out to be a bug in the disassembler.  Chris said he'd put together patches to fix that.

So that's a red herring - don't get lost there.
Comment 5 Chris Forbes 2016-02-14 00:51:03 UTC
Appears to be fixed on master as of 14/2/2016.

(And something has made a big difference to performance, too!)
Comment 6 Rhys Kidd 2016-02-15 05:23:02 UTC
Confirmed here as well on ILK. Visual corruption no longer visible on the water shaders, and certain other effects that had negative performance hits (i.e. fire) don't appear to do so now.

No hard data however to back that up, but Chris' report aligns with my experience.

$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile 
OpenGL version string: 2.1 Mesa 11.2.0-devel (git-816c987 2016-02-14 wily-oibaf-ppa)
OpenGL shading language version string: 1.20
Comment 7 Jason Ekstrand 2016-02-15 05:27:04 UTC
Do we have any idea how recent the fix is?  It would be interesting to get a bisect to know what fixed it.  But I also don't expect either of you to bisect it across thousands of commits.

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.