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

[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 7 January 2017 at 18:33, Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> On Sat, Jan 7, 2017 at 10:30 AM, Jaime García Villena
> <garciavillena.jaime at gmail.com> wrote:
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170108/fd965c4a/attachment.html>