Bug 50338

Summary: r600g: EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed !
Product: Mesa Reporter: Török Edwin <edwin+bugs>
Component: Drivers/Gallium/r600Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: elia.argentieri, freedesktop, octoploid, vmerlet
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: R600_DUMP_SHADERS=1 output
R600_DUMP_SHADERS=1 output from working Mesa 8.0.2

Description Török Edwin 2012-05-25 00:21:23 UTC
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
Comment 1 Török Edwin 2012-05-25 00:22:02 UTC
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:
Comment 2 Török Edwin 2012-05-26 01:52:16 UTC
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.
Comment 3 Vadim Girlin 2012-05-26 03:11:52 UTC
(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.
Comment 4 Gert Wollny 2018-03-06 18:38:44 UTC
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.