Bug 68527

Created attachment 84587 [details]
GL trace using apitrace from git

Created attachment 84588 [details]
Screenshot of game with sun shader glitch from R600g

Created attachment 84589 [details]
Screenshot of game without glitch from Intel HD3000

I'm also forgot to post full error:
EE r600_shader.c:158 r600_pipe_shader_create - translation from TGSI failed !
EE r600_state_common.c:754 r600_shader_select - Failed to build shader variant (type=1) -1

Created attachment 84590 [details]
GLSL code of sun shader

(In reply to comment #4)
> I'm also forgot to post full error:
> EE r600_shader.c:158 r600_pipe_shader_create - translation from TGSI failed !
> EE r600_state_common.c:754 r600_shader_select - Failed to build shader
> variant (type=1) -1

I don't think that's quite the full output, but it does look somewhat like an issue that was fixed by commit b5ddaf9975f96c46ea3dfb02c4130de5196b238c.

(In reply to comment #4)
> I'm also forgot to post full error:
> EE r600_shader.c:158 r600_pipe_shader_create - translation from TGSI failed !
> EE r600_state_common.c:754 r600_shader_select - Failed to build shader
> variant (type=1) -1

Looks like the shader needs too much registers, it's probably the most frequent reason for such errors. Old backend can't handle it correctly, and I think it's not going to be fixed. LLVM backend should handle it better, so you might want to try it in this case.

By the way, there is a check that should print more specific message, but currently it's performed after the compilation because we don't know exact numbers of temp registers used by backend itself until we compile the shader. Probably we might want to implement similar check before the compilation as well - in most cases we can detect the problem just by checking the number of TGSI_inputs + TGSI_outputs + TGSI_temps, otherwise the backend often fails due to register limit in the middle of compilation without providing any explanation.

Created attachment 84628 [details]
Game log with R600_DUMP_SHADERS=1, error on line 1488

(In reply to comment #6)
> I don't think that's quite the full output, but it does look somewhat like
> an issue that was fixed by commit b5ddaf9975f96c46ea3dfb02c4130de5196b238c.

I'm just tried it with latest Mesa from git and there still same error and glitch.

I'm attached game log with R600_DUMP_SHADERS=1, what else might be helpful here?

(In reply to comment #7)
> Looks like the shader needs too much registers, it's probably the most
> frequent reason for such errors. Old backend can't handle it correctly, and
> I think it's not going to be fixed. LLVM backend should handle it better, so
> you might want to try it in this case.

I'm always think that LLVM used by default. Sorry for such silly question, but how can I determine which backend is used? I also tried to run game using R600_LLVM=1 and other env vars (with or without sb) with no change.

(In reply to comment #10)
> (In reply to comment #7)
> > Looks like the shader needs too much registers, it's probably the most
> > frequent reason for such errors. Old backend can't handle it correctly, and
> > I think it's not going to be fixed. LLVM backend should handle it better, so
> > you might want to try it in this case.
> 
> I'm always think that LLVM used by default. Sorry for such silly question,
> but how can I determine which backend is used? I also tried to run game
> using R600_LLVM=1 and other env vars (with or without sb) with no change.

LLVM backend also needs to be enabled when you're building mesa (configure with --enable-r600-llvm-compiler option). If it's enabled in configure, then it will be used by default.

Created attachment 84640 [details]
R600_DUMP_SHADERS output and error from latest Mesa without LLVM.

(In reply to comment #11)
> LLVM backend also needs to be enabled when you're building mesa (configure
> with --enable-r600-llvm-compiler option). If it's enabled in configure, then
> it will be used by default.

Thanks, I'm successfully build Mesa with LLVM and sun shader work now.

Everything unstable (randomly result in GPU lockup and always result in lockup when SB used) and everything else is just a mess in game, but probably it's result of my own fault. I'll clean up my system and report back.

I didn't expected I'll post in this report one more time, but there is new problem occur related to same shader. Few days ago I'm back to Oibaf PPA for every day use. I'm still using HD6950 1GB.

Now when I try to run game with default sun shader I'm not only get corrupted texture, but also get GPU lockup which turn into full system freeze if I'm didn't switch to virtual terminal quick. Sun shader in-game was modified since I'm posted this bugreport, but I'm also tried old code and it's cause GPU lockup as well.

I can say for sure that without this shader everything works fine.

Is it possible that shader compiler create code which make GPU stuck?
Might be if such problem occur it's shouldn't compile anything at all?
Is there some more information required to debug that problem?

PS: I'm attach slightly updated shaders from newer version of game as well as my dmesg output.

Created attachment 91908 [details]
GPU lockup log from dmesg

Created attachment 91909 [details]
Slightly updated sun shader code from 58772 build

Small update on my issue. In latest version of Mesa this shader don't cause GPU lockup anymore, but retried of shader compilation didn't stop so my console got spammed with tons same errors:

EE ../../../../../../src/gallium/drivers/r600/r600_shader.c:157 r600_pipe_shader_create - translation from TGSI failed !
EE ../../../../../../src/gallium/drivers/r600/r600_state_common.c:745 r600_shader_select - Failed to build shader variant (type=1) -1

Is this reproducible with 10.x ?

Any news here ?

At moment sun shader in build 59607 don't cause GPU lockup, but have exactly same error. Also LLVM shader compiler can't handle it properly so it's only partially compile it.

Newer versions of game completely broken for open source drivers due to dependency on OpenGL 3.2 compatibility profile that isn't supported in Mesa:
http://pa.lennardf1989.com/Tracker/index.php?do=details&task_id=3057
I tried to bypass this problem but stuck on new GPU lockup, but I didn't report it because it's can be related to how I bypass crashes.

Anyway I suppose when developers change code to use 3.2 context game will work on Intel drivers, but there will be one more GPU lockup on R600g.

If somebody want to check it here is trace that from 63180:
https://drive.google.com/file/d/0B5LwC3WbdQ3DUVM2bzMwUlQzSW8
This one have to be opened like that:
MESA_GL_VERSION_OVERRIDE=3.0 qapitrace PA.trace
Then it's will cause GPU lockup on R600g and it's not sun shader, but something else. Actually it's cause lockup with both default and LLVM shader compiler.

I guess this can be related to how MESA_GL_VERSION_OVERRIDE working. When I run glxinfo this MESA_GL_VERSION_OVERRIDE=3.0 it's still show that GLSL 3.3 supported so this is why game able to compile shaders at all.

Possible lockup related to invalid (for Mesa) GL call or something else so I have no idea what this can be.

Same issue here I belive:
https://bugs.freedesktop.org/show_bug.cgi?id=99349

(In reply to Bronson from comment #21)
> Same issue here I belive:
> https://bugs.freedesktop.org/show_bug.cgi?id=99349

Which was fixed in 17.3. Can anybody retest?

Since nobody seems to be able to retest lets assume it was fixed (it likely was) along with bug #99349 and close for now.