Bug 72685 - [radeonsi hyperz] Artifacts in Unigine Sanctuary
[radeonsi hyperz] Artifacts in Unigine Sanctuary
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi
git
All Linux (All)
: medium normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks: 75112
  Show dependency treegraph
 
Reported: 2013-12-13 17:24 UTC by Arek Ruśniak
Modified: 2014-09-01 19:32 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
kernel log - system's hung (64.00 KB, text/plain)
2013-12-13 17:24 UTC, Arek Ruśniak
Details
weird lighting/shadow - unigine-sanctuary (1.31 MB, text/plain)
2013-12-13 22:07 UTC, Arek Ruśniak
Details
weird lighting/shadow - unigine-sanctuary (1.31 MB, image/png)
2013-12-13 22:10 UTC, Arek Ruśniak
Details
heaven 4.0/sample no.1/htile "on" (711.05 KB, image/png)
2013-12-18 22:58 UTC, Arek Ruśniak
Details
heaven 4.0/sample no.1/htile "off" (705.51 KB, image/png)
2013-12-18 22:59 UTC, Arek Ruśniak
Details
heaven 4.0/sample no.2/htile "on" (705.51 KB, image/png)
2013-12-18 23:00 UTC, Arek Ruśniak
Details
heaven 4.0/sample no.2/htile "off" (814.63 KB, image/png)
2013-12-18 23:22 UTC, Arek Ruśniak
Details
heaven 4.0/sample no.2/htile "on" (796.04 KB, image/png)
2013-12-18 23:27 UTC, Arek Ruśniak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arek Ruśniak 2013-12-13 17:24:11 UTC
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?
Comment 1 Marek Olšák 2013-12-13 18:40:08 UTC
R600_DEBUG=nohyperz

See also:

R600_DEBUG=help
Comment 2 Arek Ruśniak 2013-12-13 22:07:46 UTC
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.
Comment 3 Arek Ruśniak 2013-12-13 22:10:45 UTC
Created attachment 90752 [details]
weird lighting/shadow - unigine-sanctuary

i've forgot about content type, sorry.
Comment 4 Arek Ruśniak 2013-12-17 22:14:11 UTC
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
Comment 5 Michel Dänzer 2013-12-18 02:31:18 UTC
Thanks for the update, so let's focus on Sanctuary in this report (what about Heaven 4 BTW?)
Comment 6 Arek Ruśniak 2013-12-18 22:58:33 UTC
Created attachment 90953 [details]
heaven 4.0/sample no.1/htile "on"
Comment 7 Arek Ruśniak 2013-12-18 22:59:21 UTC
Created attachment 90954 [details]
heaven 4.0/sample no.1/htile "off"
Comment 8 Arek Ruśniak 2013-12-18 23:00:31 UTC
Created attachment 90955 [details]
heaven 4.0/sample no.2/htile "on"
Comment 9 Arek Ruśniak 2013-12-18 23:22:29 UTC
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.
Comment 10 Arek Ruśniak 2013-12-18 23:27:25 UTC
Created attachment 90959 [details]
heaven 4.0/sample no.2/htile "on"

attached wrong file, fixed
Comment 11 Arek Ruśniak 2014-01-22 12:02:05 UTC
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.
Comment 12 Marek Olšák 2014-01-22 12:04:57 UTC
You have probably set R600_DEBUG=nohyperz globally and that's why it's disabled if you don't set R600_DEBUG.
Comment 13 Arek Ruśniak 2014-01-22 13:15:41 UTC
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.
Comment 14 David Heidelberg (okias) 2014-05-17 14:06:20 UTC
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?
Comment 15 David Heidelberg (okias) 2014-05-17 14:07:27 UTC
I forgot mention, 

GPU model: Gallium 0.4 on AMD SUMO 3.0 Mesa 10.3.0-devel (git-3a1da0a) 256Mb
Comment 16 Michel Dänzer 2014-05-19 03:54:35 UTC
(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.
Comment 17 smoki 2014-05-20 19:36:36 UTC
 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 ;).
Comment 18 smoki 2014-05-22 21:19:02 UTC
 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 :).
Comment 19 David Heidelberg (okias) 2014-05-26 17:32:22 UTC
(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.
Comment 20 Michel Dänzer 2014-08-11 06:30:10 UTC
(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.
Comment 21 smoki 2014-08-11 08:21:46 UTC
(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)
Comment 22 smoki 2014-08-11 08:33:18 UTC
 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
Comment 23 smoki 2014-08-11 08:56:39 UTC
(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."
Comment 24 Marek Olšák 2014-08-16 16:58:27 UTC
(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.
Comment 25 Marek Olšák 2014-08-17 11:40:45 UTC
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.
Comment 26 smoki 2014-08-17 14:00:20 UTC
 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.
Comment 27 smoki 2014-08-17 14:04:26 UTC
 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 :)
Comment 28 smoki 2014-08-17 14:45:02 UTC
 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 :(.
Comment 29 Marek Olšák 2014-08-18 01:23:54 UTC
> 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.
Comment 30 Marek Olšák 2014-08-24 13:44:21 UTC
The final fix for radeonsi:
http://lists.freedesktop.org/archives/mesa-dev/2014-August/066388.html
Comment 31 smoki 2014-08-25 08:51:51 UTC
(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
Comment 32 Marek Olšák 2014-09-01 19:32:19 UTC
Fixed by 91050ff2154417d7f3a16b582f28c8bbdcea6cfb. Closing.