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 interference. 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)
Any ideas what's wrong in the SIMD16 version of the shader? Are we not enforcing some other ILK SIMD16 restriction?
INTEL_DEBUG=fs output would be very helpful.
Created attachment 114129 [details] INTEL_DEBUG=fs,ann output on ILK
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.
Appears to be fixed on master as of 14/2/2016. (And something has made a big difference to performance, too!)
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
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.