Hello everyone. First of all, I apologize for the possible incomplete info from this post, or lack of organization. I'm unfamiliar with the Mesa3D development environment, but I'll try my best to behave. I post here because the topic seemed too specific for the "mesa-users" list.
For TL;DR, one can skip to the final "What I'm asking" part. I've been digging into the r600_shader code, and into the r600 processor ISA documentation for quite a while, in a personal quest against this error. I could keep looking this up for myself, but I think it's time to ask for indications. I'm trying to solve this issue: EE r600_shader.c:155 r600_pipe_shader_create - translation from TGSI failed ! EE r600_state_common.c:755 r600_shader_select - Failed to build shader variant (type=1) -1 I'm using a MacBook Pro 8,2 (this is, Radeon 6750M) running Fedora 24. With the latest Mesa3D release, compiled with this config: ./configure --with-dri-drivers=i915,i965,nouveau,radeon,swrast --enable-texture-float --enable-gles1 --enable-gles2 --enable-dri3 --enable-glx=dri --enable-gallium-osmesa --enable-glx-tls --enable-glx-tls --enable-gallium-llvm --enable-llvm-shared-libs I'm testing this running gzdoom 2.2.0. All you get is a black screen, and the error repeating in the console output. https://github.com/coelckers/gzdoom This issue has been referenced here: https://bugs.freedesktop.org/show_bug.cgi?id=50338, although I can't be sure if there it happens for the same reason I'm stating here. This is what I found out so far: I've been placing several R600_ERR(); functions to get an idea of what is going on, and analyzing console output. And I came to this conclusion: TGSI instructions with 3 operands sometimes are assigned with 3 constant registers as source operands. It can be seen in reserve_cfile() function in r600_asm.c that, for chips later than R700 you have only two read ports for cfiles. I could find that this error pops out when you try to assign the 3rd register: reserve_cfile exits with -1, and so does check_bank_swizzle, and then r600_bytecode_add_alu fails as well. This can be tracked all the way up to r600_pipe_shader_create. Intense inspection of r600_asm.c makes me think that the bytecode check is correct, as it is written exactly as it says in the ISA, so I want to track the 3rd cfile assignation back to the TGSI to r600 translation. I have some auxiliar, not-cleaned-up commits saved in this branch of mine: https://github.com/gvJaime/Mesa-3D/tree/r600_shader_error What I'm asking: I can't find the place where TGSI src registers are assigned into r600 GPR or CFILE registers. I'm planning to make an exception for these kind of chips, and prevent the 3rd CFILE assignation, somehow. Where does r600 shader operands assignation happen? Can you give some directions on where to look? Thank you for your attention.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
