It works for me with mesa 10.2, so bisecting would help.

 Just guessing, but might be the same as bug 89064

 OK it is not the same, bisected this to 0e9cdedd2e3943bdb7f3543a3508b883b167e427

 radeon/llvm: enable unsafe math for graphics shaders

 This optimization looks like should be disabled for graphic too on 32bit, but will slow down things a little of course because it will render proper :D ... at least guessing should be disabled for 32bit only  until sameone approve it happens on 64bit mesa/software too.

 Ha, this one looks like good potentional candidate who made those GTT_WC issues on 32bit, need to recheck that...

 But i tested this on Kabini, so who knows... Iaroslav can you test if reverting 0e9cdedd2e3943bdb7f3543a3508b883b167e427 fixes your issue?

Yes, you are right. Commenting of a 0e9cdedd2e3943bdb7f3543a3508b883b167e427 in mesa-10.6 helped me.

(In reply to smoki from comment #3)
>  But i tested this on Kabini, so who knows... Iaroslav can you test if
> reverting 0e9cdedd2e3943bdb7f3543a3508b883b167e427 fixes your issue?

Yes, it helps. 
i think we need something like 
R600_DEBUG=nosfmath in this case

 Thanks for confirmation.

 I know those float point math optimization behave like this, if someone build llvm with gcc and with '-Ofast' that is '-O3 -ffast-math' there are visual regressions (missing fog, etc), but piglits also shows that regression.

 Weird thing about this is that piglit does not show any regression :( but well as we confirm visually grass is not there... Lately '-no-nans-fp-math' is also enabled, so i am a little bit suspicious that it might show similar issue somewhere too.

Same here on TAHITI (Radeon HD 7950) with Mesa git e93566a, LLVM svn r228889 and kernel 3.18.6-gentoo.

I can confirm that reverting 0e9cdedd2e3943bdb7f3543a3508b883b167e427 fixes the grass, but it also brings back the GPU fault errors in dmesg from bug #87278, although not reproducible with the first apitrace there. Here's a new apitrace showing both the missing grass (with 0e9cded) or GPU faults (with 0e9cded reverted):

 http://constexpr.org/tmp/TalosDemo-radeonsi.2.trace.xz (83 MiB)

 I can't reproduce any GPU faults on CIK Kabini with that trace (probably Iaroslav can't on Bonaire too), those GPU faults seems SI or Tahiti specific.

(In reply to Daniel Scharrer from comment #7)
> I can confirm that reverting 0e9cdedd2e3943bdb7f3543a3508b883b167e427 fixes
> the grass, but it also brings back the GPU fault errors in dmesg from bug
> #87278, although not reproducible with the first apitrace there...

 I also tried that one and no GPU faults... but you already say that OK.

 As you say that you can't reproduce it with some traces, you may try to research which exact option in game (and there are planty of them in this game) introduce those GPU faults... start with the lowest one and go up, etc... Also yo can start a game with env MESA_GL_VERSION_OVERRIDE, beceuse it then pick different shaders depending on the version, you may try 2.1, 3.0 or 3.3COMPAT, etc... 

 Anyway reverting that unsafe optimization which broke rendering sholudn't do anything other then fix rendering, but if that holding SI cards to not made GPU faults then it should be reverted for sure right in the mesa git, so that developers can find where are real problems with SI is.

(In reply to smoki from comment #9)
>  As you say that you can't reproduce it with some traces, you may try to
> research which exact option in game

The reason the first trace doesn't show the same GPU faults is because it's only up to the main menu. That used to be enough for the GPU faults, but some recent change in mesa seems to have 'fixed' those. The new trace is longer and all GPU faults happen while loading an actual game or walking around.

Anyway, I don't want to derail this bug too much with the GPU faults - just though it was an interesting detail. If 0e9cded is reverted or another fix lands in mesa master that happens to reintroduce the GPU faults I'll be sure to reopen #87278.

> (In reply to smoki from comment #9)
> 
> Anyway, I don't want to derail this bug too much with the GPU faults - just
> though it was an interesting detail. If 0e9cded is reverted or another fix
> lands in mesa master that happens to reintroduce the GPU faults I'll be sure
> to reopen #87278.

 You can open new bug right now and say "If i revert commit mentioned in this bug, which fixes rendering in Talos Principle for all people there are GPU faults reintroduced for SI".

 Daniel i forget to mention most important thing :D you can disable rendering of grass/flowers/etc... in that game, there is an option called 'Render Crumbs' disable that and you are fine.

 Do you still have GPU faults on SI if you disable that?

Disabling crumbs does not get rid of the GPU faults, at least not all of them. Even with all settings turned down there are occasional faults, but less than there are with higher settings.

(In reply to Daniel Scharrer from comment #13)
> Disabling crumbs does not get rid of the GPU faults, at least not all of
> them. Even with all settings turned down there are occasional faults, but
> less than there are with higher settings.

 And all those GPU faults are caused now only by reverting that  0e9cdedd2e3943bdb7f3543a3508b883b167e427 commit?

Yes, there are no faults without reverting that commit (with current Mesa git and LLVM svn).

(In reply to smoki from comment #8)
>  I can't reproduce any GPU faults on CIK Kabini with that trace (probably
> Iaroslav can't on Bonaire too), those GPU faults seems SI or Tahiti specific.

Yes no GPU faults on Bonaire with this trace.

(In reply to Daniel Scharrer from comment #15)
> Yes, there are no faults without reverting that commit (with current Mesa
> git and LLVM svn).

 As i said open a bug about, this reverted should and should preferably always work. You have another SI specific bug when GPU rendering more, in this case when rendering correctly.

(In reply to Iaroslav Andrusyak from comment #16)
> 
> Yes no GPU faults on Bonaire with this trace.

 Yes i know CIK are not affacted, keep it reverted and test.

 It is just matter of time until someone found what other issues this causes... i just found for now that this causes also posibile artifacts when vdpau/flash is used in browser... this optimization breaking more things then it is useful because of little speedness and should be disabled if someone asks me ;)

Compiler optimization does not change anything.
llvm + gcc -03    missing grass
llvm + clang -03  missing grass
llvm + clang -02  missing grass

 
 I forgot to ask Daniel what happens if you disable optimization for just TGSI_PROCESSOR_FRAGMENT as this missing crumbs happens on that case... one-liner change line 84. Does that still lockup SI card?

 if (type != TGSI_PROCESSOR_COMPUTE && TGSI_PROCESSOR_FRAGMENT) {

(In reply to smoki from comment #19)
>  if (type != TGSI_PROCESSOR_COMPUTE && TGSI_PROCESSOR_FRAGMENT) {

That always evaluates as false, because TGSI_PROCESSOR_FRAGMENT is 0. You probably meant

  if (type != TGSI_PROCESSOR_COMPUTE && type != TGSI_PROCESSOR_FRAGMENT) {

but that might not work, I suspect this problem is more likely related to the vertex shader.

 Ah OK then, it is vertex or vertex+fragment... Best solution currently seems to be that we disable this optimization until someone found why unsafe-fp-math is unsafe :D

Module: Mesa
Branch: master
Commit: 4db985a5fa9ea985616a726b1770727309502d81
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=4db985a5fa9ea985616a726b1770727309502d81

Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Tue Feb 17 17:03:35 2015 +0900

Revert "radeon/llvm: enable unsafe math for graphics shaders"

FWIW, grass (and GPU faults) disappears when setting "unsafe-fp-math" for *either* vertex or fragment shaders - or does this attribute affect the whole program?

VS  GS  PS  Grass missing  GPU faults
✗   ✗   ✗   ✗              ✓
✗   ✗   ✓   ✓              ✗
✗   ✓   ✗   ✗              ✓
✗   ✓   ✓   ✓              ✗
✓   ✗   ✗   ✓              ✗
✓   ✗   ✓   ✓              ✗
✓   ✓   ✗   ✓              ✗
✓   ✓   ✓   ✓              ✗

I don't understand. Shaders are whole programs. The OpenGL program object has no meaning to gallium drivers.

(In reply to Marek Olšák from comment #24)
> I don't understand.

Since setting the unsafe-fp-math attribute just for vertex shaders or just for fragment shaders was both enough to trigger the bug (break grass and hide the GPU faults), I was just wondering if setting that attribute on one of the shader stages somehow also affected the optimization passes and/or codegen for the other shader stages.

> Shaders are whole programs. The OpenGL program object
> has no meaning to gallium drivers.

I'm really not that familiar with the Mesa / Gallium internals, so thanks for clearing that up.

A wild guess: do the VM faults go away if you turn off DPM?

No, I still get GPU faults when booting with radeon.dpm=0.

 After http://cgit.freedesktop.org/mesa/mesa/commit/?id=c6d79ed289a75f13c65f011be870f7e43a0fedc7 which improve code quality i can enable unsafe-fp-math and grass is now there with trace from Comment 7

 Daniel and others, you might want to recheck this.

 I guess unsafe-fp-math might be reenabled now if is stabilise SI and of course because of better radeonsi performance.

(In reply to smoki from comment #28)
>  I guess unsafe-fp-math might be reenabled now if is stabilise SI and of
> course because of better radeonsi performance.

Do you have any numbers for the effect of enabling unsafe-fp-math?

(In reply to Michel Dänzer from comment #29)
> (In reply to smoki from comment #28)
> >  I guess unsafe-fp-math might be reenabled now if is stabilise SI and of
> > course because of better radeonsi performance.
> 
> Do you have any numbers for the effect of enabling unsafe-fp-math?

 I see something like +5% in quake 3 engine games like ioRTCW, OpenJK and older OpenArena 0.8.5.

 https://github.com/iortcw/iortcw
 https://github.com/JACoders/OpenJK

 OpenArena 0.8.8 is also a bit faster here on Kabini, etc...

Sounds like it may be worth a shot to enable it again then.

(In reply to Michel Dänzer from comment #32)
> Sounds like it may be worth a shot to enable it again then.

I think unsafe-fp-math enables Abs and Neg source modifiers and other optimizations, so it's definitely worth it.

(In reply to smoki from comment #28)
>  After
> http://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=c6d79ed289a75f13c65f011be870f7e43a0fedc7 which improve code quality i
> can enable unsafe-fp-math and grass is now there with trace from Comment 7
> 
>  Daniel and others, you might want to recheck this.

I can confirm that there is still grass with Mesa git-e1ae0c3 + LLVM r236436 and

diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c.old b/src/gallium/drivers/radeon/radeon_llvm_emit.c
index 624077c..0f9dbab 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_emit.c.old
+++ b/src/gallium/drivers/radeon/radeon_llvm_emit.c
@@ -80,6 +80,10 @@ void radeon_llvm_shader_type(LLVMValueRef F, unsigned type)
        sprintf(Str, "%1d", llvm_type);
 
        LLVMAddTargetDependentFunctionAttr(F, "ShaderType", Str);
+
+       if (type != TGSI_PROCESSOR_COMPUTE) {
+               LLVMAddTargetDependentFunctionAttr(F, "unsafe-fp-math", "true");
+       }
 }

I still get GPU faults with The Talos Principle, even with "unsafe-fp-math" enabled now - although not with either of the traces I posted. I also get some garbage rendered / flickering stuff, but I don't think it's related to "unsafe-fp-math". I'll test more and post a new trace when I have time.

Confirmed that both GPU faults and garbage being rendered happens independently of unsafe-fp-math. New trace in bug 87278 comment 29.