SIMD16 water fragment shader produces garbage for some pixels on Ironlake.
Author: Jason Ekstrand <firstname.lastname@example.org>
AuthorDate: Mon Oct 6 21:27:06 2014 -0700
Commit: Jason Ekstrand <email@example.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)
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.