Bug 78648 - Texture artifacts in Kerbal Space Program
Summary: Texture artifacts in Kerbal Space Program
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Matt Turner
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 79039
  Show dependency treegraph
 
Reported: 2014-05-13 05:48 UTC by Tapani Pälli
Modified: 2014-05-30 09:44 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Screenshot of the artifacts (192.36 KB, image/jpeg)
2014-05-13 05:49 UTC, Tapani Pälli
Details
49.diff (58.60 KB, text/plain)
2014-05-21 22:11 UTC, Matt Turner
Details
52.diff (58.60 KB, text/plain)
2014-05-21 22:11 UTC, Matt Turner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tapani Pälli 2014-05-13 05:48:14 UTC
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>
Comment 1 Tapani Pälli 2014-05-13 05:49:53 UTC
Created attachment 98960 [details]
Screenshot of the artifacts
Comment 2 Matt Turner 2014-05-13 05:58:58 UTC
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?
Comment 3 Tapani Pälli 2014-05-13 06:05:19 UTC
(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.
Comment 4 Matt Turner 2014-05-21 22:11:03 UTC
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.
Comment 5 Matt Turner 2014-05-21 22:11:45 UTC
Created attachment 99540 [details]
52.diff
Comment 6 Tapani Pälli 2014-05-22 04:44:23 UTC
(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).
Comment 7 Tapani Pälli 2014-05-26 11:36:48 UTC
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
Comment 8 Matt Turner 2014-05-26 20:09:33 UTC
Reverted 0d3f83f4ad5f66a3ad62f1ec0cdc5029487e92f3 on master. Tagged to be picked back to 10.2.
Comment 9 Tapani Pälli 2014-05-27 09:17:19 UTC
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.
Comment 10 Eero Tamminen 2014-05-27 12:33:36 UTC
(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)?
Comment 11 Tapani Pälli 2014-05-27 13:13:42 UTC
(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?
Comment 12 Matt Turner 2014-05-28 02:08:09 UTC
(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?
Comment 13 Eero Tamminen 2014-05-30 09:44:29 UTC
(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.


bug/show.html.tmpl processed on Feb 25, 2017 at 20:35:10.
(provided by the Example extension).