https://bugs.freedesktop.org/show_bug.cgi?id=86720

Felix Schwarz felix.schwarz@oss.schwarz.eu changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |felix.schwarz@oss.schwarz.e | |u Blocks| |77449

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #2 from glwhieuhghfbjds@riseup.net --- After a couple of hours of compiling...

Commit e8c7affa66407932519fc6d82a449b453343d9fc works fine. Commit d26258166ca056da62536bebdf107e21d9ce92fb introduces the issue.

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #4 from glwhieuhghfbjds@riseup.net --- Commit 133280120b4bc714bbb7665e383f36ab262c280a, after the fixes for Cayman in master, still has the issue.

Or did you mean of me to cherry-pick specific fixes?

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #6 from Joti Papadopoulos pan.papadopoulos80@gmail.com --- Actually, i'm having this issue as well with a HD5850. So it's probably not Cayman specific

OS: Arch Linux GPU:Radeon HD5850 Mesa 10.3.5 and 10.5git(last tested about a week ago) CPU:Phenom 2 X3 720

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #8 from Artem Hluvchynskyi excieve@gmail.com --- Created attachment 111977 --> https://bugs.freedesktop.org/attachment.cgi?id=111977&action=edit Part of the log during the lockup

Messages in the attached part of the log are repeating for a while, with monitors going off and on. Eventually the system is usable for a while and then just locks up for good, requiring a hard reset.

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #10 from Felix Schwarz felix.schwarz@oss.schwarz.eu --- I can confirm that the issue was introduced (on master) with this commit:

commit 6fcb5520b78cdf1e5013c125501932315a069955 Author: Marek Olšák marek.olsak@amd.com Date: Tue Oct 28 19:49:44 2014 +0100

Revert "st/mesa: set MaxUnrollIterations = 255"

This reverts commit 20836c81851e0df29a8ee9c86e5e5388738c840b.

255 is a huge number. If you have a loop with 255 iterations, unrolling it will exceed the SM3 instruction limit. Let's use the default again.

The comment about a SM3 limit doesn't make sense. For SM3, we generally want 32 (default) or a lower number due to the SM3 instruction limit, which is 512 instructions. For SM4, we can try higher numbers if needed, but some shaders can end up being pretty huge and shader compilation can take more time.

This fixes a shader compile failure on R500/SM3. Reported on IRC.

Cc: 10.2 10.3 mesa-stable@lists.freedesktop.org Reviewed-by: Brian Paul brianp@vmware.com

Marek: You mentioned that the r600 driver might be unable to handle certain loops. Is there anything the community can do to get this fixed? apitrace? Checking for piglit regressions related to the mentioned commit? I assume that you would be able to fix this much better if you could reproduce the problem easily.

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #12 from Felix Schwarz felix.schwarz@oss.schwarz.eu --- (In reply to Marek Olšák from comment #11)

I'd add a PIPE_CAP and allow the driver to set MaxUnrollIterations with it.

"I'd add" as in "I plan to add" or as in "someone else should fix that by ..."?

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #14 from Marek Olšák maraeo@gmail.com --- Created attachment 113246 --> https://bugs.freedesktop.org/attachment.cgi?id=113246&action=edit patch

Hi guys, could you please test this patch?

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #16 from Marek Olšák maraeo@gmail.com --- Having a piglit test reproducing the issue would be very useful.

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #18 from Felix Schwarz felix.schwarz@oss.schwarz.eu --- I created an API trace which reproduces the problem for me (https://dl.dropboxusercontent.com/s/hc6v7gdcshj4ljd/eu4.trace-lockup.xz?dl=0 , 120 MB, unfortunately trimming produces only invalid states). The shaders itself don't look to bad to me but I don't have any experience deducing a miminal testcase from an apitrace (pointers welcome).

https://bugs.freedesktop.org/show_bug.cgi?id=86720

Joe Glaser jpg84@drexel.edu changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO

--- Comment #20 from Joe Glaser jpg84@drexel.edu --- Hey everyone,

I am a bit new to working with Mesa and haven't needed to patch anything in it before. However, I am experiencing the GPU overload mentioned in the OC's post (Hitting Play at Nation Select causes the game to attempt to load, but crash when displaying the units and requiring a system reboot). I'd like to apply Marek Olšák's patch file, however I am unfamiliar with the commands I need to use to run it on Fedora 21.

Any ideas?

OS: Fedora 21 x86_64 [Gnome3.14.2] GPU: Radeon HD 6520G GPU Driver: Gallium 0.4 on AMD SUMO CPU: AMD A6-3420M APU with Radeon HD Graphics x4

https://bugs.freedesktop.org/show_bug.cgi?id=86720

Joe Glaser jpg84@drexel.edu changed:

What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |critical

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #22 from Médéric Boquien mboquien@free.fr --- Has the patch been committed? I have just tried with Mesa 10.5.1 and the freeze is still there. Thanks!

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #24 from noga.dany@gmail.com --- Still present in 10.6.1 and game is still unplayable on Radeon

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #26 from noga.dany@gmail.com --- I tried run it with nosb parameters like mentioned above "R600_DEBUG=nosb force_s3tc_enable=true /usr/bin/steam %U" and game works, but textures looks very bad.

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #28 from noga.dany@gmail.com --- (In reply to Benjamin Bellec from comment #27)

(In reply to noga.dany from comment #26)

...

I tried run it with nosb parameters like mentioned above "R600_DEBUG=nosb force_s3tc_enable=true /usr/bin/steam %U" and game works, but textures looks very bad.

Remove the "force_s3tc_enable=true" in your command.

And be sure to have the s3tc lib installed (libtxc_dxtn). You can check that with this command: $ glxinfo |grep s3tc

Ok, I have installed libtxc_dxtn 64bit and 32bit and tried it with "R600_DEBUG=nosb /usr/bin/steam %U". Unfortunately it doesn't look good either. Screenshot attached. Mesa 10.6.4 Kernel 4.1.1 AMD HD 6870

So with nosb works but looks bad and without nosb it looks good, but system freezes.

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #30 from a.t.martens@gmail.com --- (In reply to noga.dany from comment #29)

Created attachment 117697 [details] screenshot with R600_DEBUG=nosb on Mesa 10.6.4 and AMD HD 6870

I think the graphics glitches that appear with nosb can be fixed if you disable some of the effects. I can't remember which at the moment. I was able to run with no apparent issues on my HD 6850 after turning on nosb.

https://bugs.freedesktop.org/show_bug.cgi?id=86720

--- Comment #32 from Benjamin Bellec b.bellec@gmail.com --- Marek pushed the fix. So it's likely to be fixed in Mesa 11.0.4 which should be released in less than a week.

https://bugs.freedesktop.org/show_bug.cgi?id=86720

Lukáš Krejza gryffus@hkfree.org changed:

What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freedesktop.or | |g/show_bug.cgi?id=93706

https://bugs.freedesktop.org/show_bug.cgi?id=86720

iive@yahoo.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Assignee|dri-devel@lists.freedesktop |iive@yahoo.com |.org | Resolution|FIXED |--- CC| |iive@yahoo.com

--- Comment #34 from iive@yahoo.com --- Created attachment 125183 --> https://bugs.freedesktop.org/attachment.cgi?id=125183&action=edit EU4 shader #175 in TGSI , unoptmized disassembly, sbdump of all stages and optimized disassembly

While the committed workaround does work for this case, the bug in R600 Shader Backend is not fixed and it is triggered by other more complicated shaders. For example: https://bugs.freedesktop.org/show_bug.cgi?id=94900

I had locally reverted the unroll workaround in order to obtain the form that triggers this bug. If you need to test the bug with this shader, then in `r600_pipe.c:559` you have to set `PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT` to 32, instead of 255.

The buggy shader is the vertex shader of call 1024042 in the trace. When using `R600_DEBUG=ps,vs`, the shader is under #175 .

Like in the other bugreport, this shader causes assertion failure in the sb_checker (if mesa is compiled with debugging) and the bug is also workarounded by `R600_DEBUG=sbsafemath`.

This works because it disables the call to `fold_assoc()` in `expr_handler::fold_alu_op2()` somewhere around `sb_expr.cpp:740`

In order to locate the bug, I've enabled the sbdump for all SB stages.

I'm also uploading a second log, with the "fold_assoc()" disabled, so a side-by-side comparison of both logs could indicate how the function affects the result through the different stages. (I recommend `diffuse` program.)

This shader is easier to analyze, because it contains just one loop with 4 iterations and no other conditional branches and jumps. The loop counter register is used as index for memory access. The memory address calculations might be involved in triggering the bug as `fold_assoc()` works on them. The `sb_checker` complains about instructions that list the counter register, so it is possible that the instruction that increments it is somehow "optimized" out.