[Mesa-dev] [Bug 50338]radeon: TGSI takes more than two cfiles from r600_shader.

[Jaime García Villena]

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.

[Ilia Mirkin]

On Sat, Jan 7, 2017 at 10:30 AM, Jaime García Villena

Post by Jaime García Villena
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?

Someone might probably answer in some more depth, but there are two
stages - one is to convert TGSI -> r600 asm, which happens in
r600_asm.c as you've found. Then there's an optimizing compiler,
called "sb", which takes the asm and optimizes it, based on various
internal rules; the logic for this is in the r600/sb directory. A
restriction of the sort you're talking about would have to be taken
into account by sb as well. You can test to see if that's the issue by
running with R600_DEBUG=nosb, which will skip the second stage. If
that works, then the issue definitely lies in sb. Otherwise it's in
the tgsi -> r600 asm phase.

More generally, you may find it faster to get help in #radeon and
#dri-devel on irc.freenode.net than asking in emails (since it's
easier to ask follow-up questions).

Cheers,

-ilia

[Jaime García Villena]

Hello Ilia


Thank you for the irc reference, I'll check there for live responses the
next time I look into this.
I will post here what I have found out for now, just to write it down:

Running with R600_DEBUG=nosb yields the same results.
It makes sense because the driver kicks the bytecode out before the sb
phase takes place.

With further reading of the Evergreen ISA, I can see that in chapter 4.6.4
"ALU Constants" it says that the Trans ALU can only reference two
constants. My custom R600_ERR messages keep outputting this:

EE r600_asm.c:426 reserve_cfile - Failed to reserve cfile when looking for
517
EE r600_asm.c:427 reserve_cfile - hw_cfile_addr are [514,514,-1,-1]
EE r600_asm.c:594 check_and_set_bank_swizzle - Scalar couldn't be checked
for alu: 4

That is, when trying to assign cfile 517, the driver finds that there are
already two of them reserved, and returns with an error. This happens for
ALU number 4, which is the ALU.Trans. After a while I get some more errors
with another ALUs here and there, but they are seldom compared to the Trans
one.

I think this may be fixed in the TGSI -> r600_asm phase, but before
bytecode checks. I'm still unfamiliar with how GPRs and constants are
assigned from TGSI to r600 so I still have no clue where to fiddle with the
code.


I will keep looking it up.

Greetings

Jaime García Villena

On Sat, Jan 7, 2017 at 10:30 AM, Jaime García Villena

Post by Jaime García Villena
I can't find the place where TGSI src registers are assigned into r600

GPR

Post by Jaime García Villena
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?

Someone might probably answer in some more depth, but there are two
stages - one is to convert TGSI -> r600 asm, which happens in
r600_asm.c as you've found. Then there's an optimizing compiler,
called "sb", which takes the asm and optimizes it, based on various
internal rules; the logic for this is in the r600/sb directory. A
restriction of the sort you're talking about would have to be taken
into account by sb as well. You can test to see if that's the issue by
running with R600_DEBUG=nosb, which will skip the second stage. If
that works, then the issue definitely lies in sb. Otherwise it's in
the tgsi -> r600 asm phase.
More generally, you may find it faster to get help in #radeon and
#dri-devel on irc.freenode.net than asking in emails (since it's
easier to ask follow-up questions).
Cheers,
-ilia