Jaime García Villena
2017-01-07 15:30:36 UTC
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:
--enable-texture-float --enable-gles1 --enable-gles2 --enable-dri3
--enable-glx=dri --enable-gallium-osmesa --enable-glx-tls --enable-glx-tls
I'm testing this running gzdoom 2.2.0. All you get is a black screen, and
the error repeating in the console output.
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
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:
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.