https://bugs.freedesktop.org/show_bug.cgi?id=89069
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.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #1 from smoki smoki00790@gmail.com ---
It works for me with mesa 10.2, so bisecting would help.
Just guessing, but might be the same as bug 89064
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #2 from smoki smoki00790@gmail.com ---
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...
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #3 from smoki smoki00790@gmail.com --- But i tested this on Kabini, so who knows... Iaroslav can you test if reverting 0e9cdedd2e3943bdb7f3543a3508b883b167e427 fixes your issue?
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #4 from commiethebeastie@gmail.com --- Yes, you are right. Commenting of a 0e9cdedd2e3943bdb7f3543a3508b883b167e427 in mesa-10.6 helped me.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #5 from Iaroslav Andrusyak pontostroy@gmail.com --- (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
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #6 from smoki smoki00790@gmail.com ---
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.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #7 from Daniel Scharrer daniel@constexpr.org --- 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)
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #8 from smoki smoki00790@gmail.com ---
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.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #9 from smoki smoki00790@gmail.com --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #10 from Daniel Scharrer daniel@constexpr.org --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #11 from smoki smoki00790@gmail.com ---
(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".
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #12 from smoki smoki00790@gmail.com ---
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?
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #13 from Daniel Scharrer daniel@constexpr.org --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #14 from smoki smoki00790@gmail.com --- (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?
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #15 from Daniel Scharrer daniel@constexpr.org --- Yes, there are no faults without reverting that commit (with current Mesa git and LLVM svn).
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #16 from Iaroslav Andrusyak pontostroy@gmail.com --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #17 from smoki smoki00790@gmail.com --- (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 ;)
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #18 from Iaroslav Andrusyak pontostroy@gmail.com --- Compiler optimization does not change anything. llvm + gcc -03 missing grass llvm + clang -03 missing grass llvm + clang -02 missing grass
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #19 from smoki smoki00790@gmail.com ---
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) {
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #20 from Michel Dänzer michel@daenzer.net --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #21 from smoki smoki00790@gmail.com ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=89069
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #22 from Michel Dänzer michel@daenzer.net --- Module: Mesa Branch: master Commit: 4db985a5fa9ea985616a726b1770727309502d81 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=4db985a5fa9ea985616a726b177...
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"
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #23 from Daniel Scharrer daniel@constexpr.org --- 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 ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✓ ✓ ✗ ✗ ✓ ✗ ✗ ✓ ✗ ✓ ✓ ✓ ✗ ✓ ✗ ✗ ✓ ✗ ✓ ✗ ✓ ✓ ✗ ✓ ✓ ✗ ✓ ✗ ✓ ✓ ✓ ✓ ✗
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #24 from Marek Olšák maraeo@gmail.com --- I don't understand. Shaders are whole programs. The OpenGL program object has no meaning to gallium drivers.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #25 from Daniel Scharrer daniel@constexpr.org --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #26 from Marek Olšák maraeo@gmail.com --- A wild guess: do the VM faults go away if you turn off DPM?
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #27 from Daniel Scharrer daniel@constexpr.org --- No, I still get GPU faults when booting with radeon.dpm=0.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #28 from smoki smoki00790@gmail.com --- After http://cgit.freedesktop.org/mesa/mesa/commit/?id=c6d79ed289a75f13c65f011be87... 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.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #29 from Michel Dänzer michel@daenzer.net --- (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?
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #30 from smoki smoki00790@gmail.com --- (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
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #31 from smoki smoki00790@gmail.com --- OpenArena 0.8.8 is also a bit faster here on Kabini, etc...
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #32 from Michel Dänzer michel@daenzer.net --- Sounds like it may be worth a shot to enable it again then.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #33 from Marek Olšák maraeo@gmail.com --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #34 from Daniel Scharrer daniel@constexpr.org --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=89069
--- Comment #35 from Daniel Scharrer daniel@constexpr.org --- Confirmed that both GPU faults and garbage being rendered happens independently of unsafe-fp-math. New trace in bug 87278 comment 29.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org