Created attachment 62087 [details] R600_DUMP_SHADERS=1 output Trying to reproduce bug #50325 on Mesa git caused this error: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed ! Bug can be reproduced by one of these: build/glretrace lt-glyphy-demo.trace demo/glyphy-demo I get the translation failed error both with R600_LLVM=0, and R600_LLVM=1. I've attached the R600_DUMP_SHADERS=1 output. glretrace is from https://github.com/apitrace/apitrace/tree/1.0 and glyphy is from https://code.google.com/p/glyphy/source/checkout lt-glypy-demo.trace is here: https://bugs.freedesktop.org/attachment.cgi?id=62078 git version of Mesa: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL version string: 2.1 Mesa 8.1-devel (git-35f302d) OpenGL shading language version string: 1.30 OpenGL extensions: Built with (on Debian unstable): ./configure --with-dri-drivers= --with-gallium-drivers=r600,swrast --enable-glx-tls --enable-gallium-llvm LLVM_CONFIG=/usr/bin/llvm-config-3.1
Created attachment 62088 [details] R600_DUMP_SHADERS=1 output from working Mesa 8.0.2 shader dump from working: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL version string: 2.1 Mesa 8.0.2 OpenGL shading language version string: 1.20 OpenGL extensions:
Tried to bisect and I got to the commit (783e4da72aa203a645737dec81b001341951a942) that introduced GPR limit checking. Before that commit the shader compiles, but the rendered output is wrong (see #50325). However in Mesa git master I don't see the GPR limit error. Bisecting again to see where the GPR limit message was lost I get to the point where GLSL 1.30 was enabled: 12bedaa24ba8f4cdb3f2b58482ce8f9ac5715703 is the first bad commit commit 12bedaa24ba8f4cdb3f2b58482ce8f9ac5715703 Author: Dave Airlie <airlied@redhat.com> Date: Sat Apr 21 10:37:08 2012 +0100 r600: enable glsl 1.30 on r700 I've done a piglit run on rv740 and confirmed no regressions. We don't get GL3 on r700 due to transform feedback being busted still. Signed-off-by: Dave Airlie <airlied@redhat.com> The problem is probably still that there are too many registers, except that message is no longer printed.
(In reply to comment #2) > The problem is probably still that there are too many registers, except that > message is no longer printed. Yes, you are right. I think the message is not printed because the build fails before that check - register count is checked when the shader is built, to get the exact number with additional temporary registers etc. We can do additional check before the build, to catch more problematic cases, but on the other hand we have the error message anyway, though not so descriptive, and broken shader code won't be used on gpu - so there are no lockups. I doubt that non-LLVM shader backend will be able to handle that shader anytime soon. LLVM backend currently can't handle it due to another problem, but it's going to be fixed.
This should be fixed since v17.3.
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.