With Mesa master there are strange flickering 'rectangles' in the terrain texture when watching the planet from sky in kerbal space program. This is a regression, used to look fine before. I've bisected the regression in to following commit: --- 8< --- 42a26cb5e441a01d5288b299980f23affaad53fe is the first bad commit commit 42a26cb5e441a01d5288b299980f23affaad53fe Author: Matt Turner <mattst88@gmail.com> Date: Wed Apr 9 13:38:14 2014 -0700 i965: Don't make instructions with a null dest a barrier to scheduling. Now that we properly track accumulator dependencies, the scheduler is able to schedule instructions between the mach and mov in the common the integer multiplication pattern: mul acc0, x, y mach null, x, y mov dest, acc0 Since a null destination implies no dependency on the destination, we can also safely schedule instructions (that don't write the accumulator) between the mul and mach. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Created attachment 98960 [details] Screenshot of the artifacts
Nice bug. Could you capture the GLSL shaders from the game using Eric's shader-db tools and send a tarball to me privately so I can debug it?
(In reply to comment #2) > Nice bug. Could you capture the GLSL shaders from the game using Eric's > shader-db tools and send a tarball to me privately so I can debug it? Sure, will do.
Created attachment 99539 [details] 49.diff Reverting the commit and comparing shader disassembly doesn't show me anything plausible. Reverting the patch causes the code to change in shaders 49 and 52 (and their duplicates 103 and 106, respectively). The changes are just rescheduling some cmp instructions with null destinations, like -cmp.l.f0(16) null g24<8,8,1>D 30D { align1 WE_normal 1H switch }; mad(16) g4<1> g42<4,4,1>F g74<4,4,1>F g36<4,4,1>F { align16 WE_normal 1H }; send(16) g16<1>UW g2<8,8,1>F sampler (1, 0, 0, 2) mlen 4 rlen 8 { align1 WE_normal 1H }; +cmp.l.f0(16) null g24<8,8,1>D 30D { align1 WE_normal 1H switch }; cmp's source is never touched in the interval in which it moves. The flag register also isn't read or written. At first I thought the send might write g24 but it just writes g16-g23. Can you confirm that reverting the patch fixes the problem? Did running the game (when you captured the shaders) demonstrate the problem? If not, we might not have found the broken shader yet.
Created attachment 99540 [details] 52.diff
(In reply to comment #4) > Can you confirm that reverting the patch fixes the problem? Did running the > game (when you captured the shaders) demonstrate the problem? If not, we > might not have found the broken shader yet. Could it be possible that the change you did exposes a bug that we have elsewhere? I will try to run by reverting only the bisected patch (did not try this yet).
Yes, using Mesa master (f0748b5) and reverting the patch fixes the issue. Just noticed I did not reply to .. > Did running the game (when you captured the shaders) demonstrate the problem? Yes
Reverted 0d3f83f4ad5f66a3ad62f1ec0cdc5029487e92f3 on master. Tagged to be picked back to 10.2.
FYI it is specifically the first change in the patch that causes the artifacts to appear. I'm trying to figure out what is the instruction involved.
(In reply to comment #9) > FYI it is specifically the first change in the patch that causes the > artifacts to appear. I'm trying to figure out what is the instruction > involved. Do you still have the crash issues when starting the game? Could the patch be somehow causing those (I don't see crashes anymore with latest Mesa nor the rendering issues)?
(In reply to comment #10) > (In reply to comment #9) > > FYI it is specifically the first change in the patch that causes the > > artifacts to appear. I'm trying to figure out what is the instruction > > involved. > > Do you still have the crash issues when starting the game? Game does not crash but seems to wait forever for something, I'm not sure if this is related though, I get this 'hang' only when using a saved game, not when starting always a new one. > Could the patch be somehow causing those (I don't see crashes anymore with > latest Mesa nor the rendering issues)? The patches were reverted so rendering issues are gone. Did you experience the 'hang' also?
(In reply to comment #9) > FYI it is specifically the first change in the patch that causes the > artifacts to appear. I'm trying to figure out what is the instruction > involved. I posted the two instruction diffs. The actual differences between them are pretty much the same. I really can't see anything in the shader diffs that looks like a problem. With the patch, maybe try running with INTEL_DEBUG=no16?
(In reply to comment #11) > The patches were reverted so rendering issues are gone. Did you experience > the 'hang' also? I remember KSP doing something which required continuing the game from gdb to actually to be able to run it, and this happening only when I was using Mesa version that caused the rendering artifacts. I didn't investigate it more (no debug symbols available for KSP libs, Steam's ubuntu libs etc), so I don't know whether they were really related.
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.