| Bug ID | 89069 |
|---|---|
| Summary | Lack of grass in The Talos Principle on radeonsi (native\wine\nine) |
| Product | Mesa |
| Version | git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | pontostroy@gmail.com |
| QA Contact | dri-devel@lists.freedesktop.org |
Kernel 3.19 LLVM 3.7~svn20150205 Mesa git 2015.02.08 10.6.0-devel git-345e8cc hd 7790 Intel(hd2500) and r600(hd6770) have no problems with grass The game looks as http://www.gearsongallium.com/wp-content/uploads/2015/02/talos-native.png and should look like this: http://www.gearsongallium.com/wp-content/uploads/2015/02/opengl.png Changing settings from ultra to low does not help, but grass should be at all settings.
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 !=3D TGSI_PROCESSOR_COMPUTE &&= TGSI_PROCESSOR_FRAGMENT) { That always evaluates as false, because TGSI_PROCESSOR_FRAGMENT is 0. You probably meant if (type !=3D TGSI_PROCESSOR_COMPUTE && type !=3D TGSI_PROCESSOR_= FRAGMENT) { but that might not work, I suspect this problem is more likely related to t= he 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