Created attachment 90738 [details] kernel log - system's hung after this commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=8ee7370c9bed0be40c5d134f0b92eb3782c6b7e9 GPU's lost stability. I've tested it on unigine-valley/xonotic(ultimate)/some wine apps. Nothing segfaults,no logs, sometimes (with heavy load) gpu crashes with standard dmesg info: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec etc. kernel 3.13rc2 (dpm on by default) x86&x86_64 llvm 3.5 (svn-197173) libdrm 2.4.50 GPU cape verde xt is there any switch to turn off htile by now?
R600_DEBUG=nohyperz See also: R600_DEBUG=help
Created attachment 90751 [details] weird lighting/shadow - unigine-sanctuary i've tested same apps if something works with htile, it does very fast serious sam 3 - gpu crashes unigine-sanctuary - works but massive artifacts unigine-tropics - works unigine-heaven3 - works unigine-heaven4 - works but some artifacts (like sanctuary but less). metro 2033(wine) - works metro ll - works (but still looks like a crap) left 4 dead 2 - works team fortress 2 - works gnome-shell - works but some artifacts all artifacts disappear with "nohyperz" btw thanks for tip.
Created attachment 90752 [details] weird lighting/shadow - unigine-sanctuary i've forgot about content type, sorry.
with: radeonsi: add the htile buffer to the CS ioctl buffer list radeonsi: set CB_DISABLE if the color mask is 0 things get better. No GPU lockups, no artifacts (xonotic/unigine-valley/serious sam 3/stalker(wine)) unigine-sanctuary still shows freaky shadows. I don't try skyrim but if you need i can install it. It looks like performance dropped a little bit, but not much and nothing hangs my PC
Thanks for the update, so let's focus on Sanctuary in this report (what about Heaven 4 BTW?)
Created attachment 90953 [details] heaven 4.0/sample no.1/htile "on"
Created attachment 90954 [details] heaven 4.0/sample no.1/htile "off"
Created attachment 90955 [details] heaven 4.0/sample no.2/htile "on"
Created attachment 90958 [details] heaven 4.0/sample no.2/htile "off" For unigine-heaven4 i found only this. It looks pretty as sanctuary but much less (only in this one scene). I've just realized that the same problem i can see in heaven3.
Created attachment 90959 [details] heaven 4.0/sample no.2/htile "on" attached wrong file, fixed
I have almost forgotten about it. Sanctuary/heaven at latest git (mesa git-6caf34b, llvm svn-199712) all these artifacts are gone. I don't know who/where/when/how but i thint it's not real fix. It looks like hyperz is off by default. When i run sanctuary/heaven with R600_DEBUG=whatever_you_want_except_nohyperz artifacts goes back and performance goes high. I'll try not-involved apps like xonotic or lightsmark or unigine-valley later.
You have probably set R600_DEBUG=nohyperz globally and that's why it's disabled if you don't set R600_DEBUG.
indeed, it's so embarrassing. someone in somehow had to do this to me, surely it had to be the elves. sorry for that mess.
Unigine Sanctuary work perfectly on HD 6550D with 3.14.4 kernel R600_DEBUG=hyperz ./1024x768_windowed.sh Performace without HyperZ: FPS: 28.1 Scores: 1193 Min FPS: 20.0 Max FPS: 30.2 With HyperZ: FPS: 30.1 Scores: 1278 Min FPS: 23.8 Max FPS: 40.0 Can you retest guys?
I forgot mention, GPU model: Gallium 0.4 on AMD SUMO 3.0 Mesa 10.3.0-devel (git-3a1da0a) 256Mb
(In reply to comment #15) > GPU model: Gallium 0.4 on AMD SUMO 3.0 Mesa 10.3.0-devel (git-3a1da0a) 256Mb This bug report is about the radeonsi driver, which doesn't support that card.
I can confirm this with Radeon 8400, hyperz leaves those artifatcs with hyperz enabled... but actually i dont think hyperz is at most quilty here, because first of all rendering on that scene must be proper and actually it is not even with hyperz disabled as i mention in bug 77785 :). I somehow tend to think hyperz just likes proper rendering, otherwise when it is not there will be bugs like this ;).
From my experience all of those "HYPERZ issues" are related to the shadows :). In both Sanctuary and Heavean demos if i only turn off shadows in config file there is no artifacts anymore: <item name="render_force_no_shadows" type="int">1</item> So if someone succesfully fix that currently in various ways broken shadows setup in r600/radeonsi code, he will fix hyperz artifacts too :).
(In reply to comment #16) > (In reply to comment #15) > > GPU model: Gallium 0.4 on AMD SUMO 3.0 Mesa 10.3.0-devel (git-3a1da0a) 256Mb > > This bug report is about the radeonsi driver, which doesn't support that > card. I know, I did retest this, because this also blocking enabling hyperz on r600g. More like hyperz bugs it's seems like just highlight existing bugs in radeon code.
(In reply to comment #18) > So if someone succesfully fix that currently in various ways broken shadows > setup in r600/radeonsi code, he will fix hyperz artifacts too :). It's not that simple unfortunately. At least in Sanctuary, the shadows work perfectly now without HyperZ but are still broken with it.
(In reply to comment #20) > (In reply to comment #18) > > So if someone succesfully fix that currently in various ways broken shadows > > setup in r600/radeonsi code, he will fix hyperz artifacts too :). > > It's not that simple unfortunately. At least in Sanctuary, the shadows work > perfectly now without HyperZ but are still broken with it. I know i mentionied that here: https://bugs.freedesktop.org/show_bug.cgi?id=79035#c6 Anyway besides more artifacts of course (i mentioned yesterday on irc to marek) that if i just disable stencil in si_state.c, there is no lockups in these traces/apps when hyperz is enabled S_028800_STENCIL_ENABLE(0)
And he said chips handle these cases, no driver need to somhow check for those. I gueesed that maybe that "Stencil op fail or zfail is not KEEP" is culprit but who knows :) http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Depth_in-depth.pdf#6 http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Depth_in-depth.pdf#10
(In reply to comment #22) > And he said chips handle these cases, no driver need to somhow check for > those. I gueesed that maybe that "Stencil op fail or zfail is not KEEP" is > culprit but who knows :) > > http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Depth_in- > depth.pdf#6 > http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Depth_in- > depth.pdf#10 I mean that one for an artifacts we have in some apps :) "Unfortunately the conventional method can get artifacts if the shadow volume intersects the near clipping plane (if front plane capping is not used, that is), which has made the Z-fail method the algorithm of choice for most deve lopers."
(In reply to comment #21) > Anyway besides more artifacts of course (i mentioned yesterday on irc to > marek) that if i just disable stencil in si_state.c, there is no lockups in > these traces/apps when hyperz is enabled S_028800_STENCIL_ENABLE(0) I don't understand this. Forcing STENCIL_ENABLE(0) doesn't fix Sanctuary.
smoki, you can ignore that document. Sanctuary doesn't use shadow volumes for shadows. It also doesn't use stencil. There are 2 issues here: 1) HTILE doesn't seem to support rendering to an array texture with SLICE_START == SLICE_MAX != 0 (non-zero layer). The workaround is to set SLICE_START=SLICE_MAX=0 and add slice_size*slice_start to the base address. This won't work with layered rendering, but we should still use the workaround for non-layered rendering, because the performance improvement is really worth it. Note: r600g doesn't use HTILE for array textures, so it may see lower performance increase from HyperZ in Sanctuary. With the workaround above, the rendering is still broken, so it needs one more workaround: 2) In-place DB flushing is broken with HTILE. The DB->CB copy can be used instead.
Yes, as i see shadows are maded in gl_FragData but it touch GL_REPLACE glStencilOp maybe that is because it show artifacts but not sure :). But comment is more about lockups in other bugs, where i see most lockups come where GL_ZERO is used with glStencilOp/glStencilOpSeparate . I have The Cave game which does not lockup when i just comment GL_ZERO op in state, the same also with trace from Bug 64471 it does not lockup, etc.
The point is those stencil ops under hyperz does not operate quite well and give weird results, so i think that needs to be fixed first :)
So as you see zeros are always culprit somehow, so fix looks like to me will be: "fix the zero cases" somehow or mybe workaround them all :D But i don't know for sure why those zeros seems like anywhere? not work with hyperz :(.
> 2) In-place DB flushing is broken with HTILE. The DB->CB copy can be used > instead. The flushing didn't work because of incorrect macrotile bank rotation of non-zero slices. Sanctuary works fine with the first workaround and added bank rotation, so we're close to closing this bug.
The final fix for radeonsi: http://lists.freedesktop.org/archives/mesa-dev/2014-August/066388.html
(In reply to comment #30) > The final fix for radeonsi: > http://lists.freedesktop.org/archives/mesa-dev/2014-August/066388.html Yep i tried that patch from lists 2 days ago, that works :). Fixed Unigine Sanctuary/Heaven shadow artifacts and two piglits EXT_framebuffer_mutisample/accuracy 2 (and 6) stencil_resolve small depthstencil
Fixed by 91050ff2154417d7f3a16b582f28c8bbdcea6cfb. Closing.
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.