<div dir="ltr">Hello Ilia<div><br></div><div><br></div><div>Thank you for the irc reference, I'll check there for live responses the next time I look into this. </div><div>I will post here what I have found out for now, just to write it down:</div><div><div><br></div><div>Running with R600_DEBUG=nosb yields the same results. </div><div>It makes sense because the driver kicks the bytecode out before the sb phase takes place.</div><div><br></div><div>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:</div><div><br></div><div><div>EE r600_asm.c:426 reserve_cfile - Failed to reserve cfile when looking for 517</div><div>EE r600_asm.c:427 reserve_cfile - hw_cfile_addr are [514,514,-1,-1]</div><div>EE r600_asm.c:594 check_and_set_bank_swizzle - Scalar couldn't be checked for alu: 4</div></div><div><br></div><div>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.</div></div><div><br></div><div>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. </div><div><br></div><div><br></div><div>I will keep looking it up.</div><div><br></div><div>Greetings</div><div><br></div><div>Jaime García Villena</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 7 January 2017 at 18:33, Ilia Mirkin <span dir="ltr"><<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Jan 7, 2017 at 10:30 AM, Jaime García Villena<br>
<<a href="mailto:garciavillena.jaime@gmail.com">garciavillena.jaime@gmail.com</a><wbr>> wrote:<br>
> I can't find the place where TGSI src registers are assigned into r600 GPR<br>
> or CFILE registers. I'm planning to make an exception for these kind of<br>
> chips, and prevent the 3rd CFILE assignation, somehow.<br>
><br>
> Where does r600 shader operands assignation happen? Can you give some<br>
> directions on where to look?<br>
<br>
</span>Someone might probably answer in some more depth, but there are two<br>
stages - one is to convert TGSI -> r600 asm, which happens in<br>
r600_asm.c as you've found. Then there's an optimizing compiler,<br>
called "sb", which takes the asm and optimizes it, based on various<br>
internal rules; the logic for this is in the r600/sb directory. A<br>
restriction of the sort you're talking about would have to be taken<br>
into account by sb as well. You can test to see if that's the issue by<br>
running with R600_DEBUG=nosb, which will skip the second stage. If<br>
that works, then the issue definitely lies in sb. Otherwise it's in<br>
the tgsi -> r600 asm phase.<br>
<br>
More generally, you may find it faster to get help in #radeon and<br>
#dri-devel on <a href="http://irc.freenode.net" rel="noreferrer" target="_blank">irc.freenode.net</a> than asking in emails (since it's<br>
easier to ask follow-up questions).<br>
<br>
Cheers,<br>
<br>
  -ilia<br>
</blockquote></div><br></div>