[Mesa-dev] r600g: status of my work on the shader optimization

[Vadim Girlin]

On 03/02/2013 10:06 AM, Sebastien Caty wrote:
> On March 1, 2013 06:24:01 PM Matt Turner wrote:
>> On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty <scaty at dcinformatique.com>
> wrote:
>>> Trying to dig more and found out which shader is causing trouble but I
>>> haven't found out how to run a specific test with piglit. Documentation
>>> isn't to friendly...Id appreciate some help with this.
>>
>> If you click the test {pass,fail,crash} in the generated html summary
>> it will contain the command used to run the test.
>
> Doh! Thanks that will do. All the piglit regression I had found so far pass
> when I run them alone, one by one.

Some tests may fail randomly, so you might want to run them few times to 
be more sure.

>
> Went back to Serious Sam 3 to isolate a shader that's causing problems. Found
> one, shader 35. I get several errors like this :
>
> error at : DOT4     __,    t113 at R14.x, t114F at R125.x
>    : expected operand value t113 at R14.x, gpr contains R11.x.3||FP at R14.x
> error at : DOT4     __,    t85 at R14.x, t86F at R124.x
>    : expected operand value t85 at R14.x, gpr contains R11.x.3||FP at R14.x
> error at : DOT4     __,    t87 at R13.y, t88F at R124.y
>    : expected operand value t87 at R13.y, gpr contains R12.x.5||FP at R13.y
>

It's internal error in r600-sb. Probably this should be reproducible 
with my card, so if you could use apitrace to record the trace that 
reproduces the issue and upload it somewhere, then I should be able to 
debug this locally on my system.

> bytecode 8 dw -- 2 gprs -- 0 stack entries -------
> shader 35 -- 7
> 0000 00000002 81000000  VTX 1 @4
>   0004 7C00A000 88CD1001 00080000   VFETCH         R1.xyzw, R0.x,  RID:160
> VERTEX MFC:31 UCF:0 FMT(DTA:35 NUM:0 COMP:0 MODE:1)
> 0002 00000000 8A000000  RET @0
> --------------------------------------

In fact this is not the correct shader 35 that corresponds to the full 
dump on pastebin, though it's not very important in this case, I see the 
problem in the pastebin dump anyway. It may be misleading, but there are 
two different shader numbering schemes in the dumps. Probably it's 
simpler just to send me the full dump. After locating the shader using 
_DSKIP_ env vars just prepend "R600_DUMP_SHADERS=2 R600_SB_DUMP=3" to 
the resulting command line to create the dump. It may be big enough, so 
it's probably better to compress it and send directly to my mail (not to 
mesa-dev).

> ______________________________________________________________
> --------------------------------------------------------------
> FRAG
> PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1
> DCL IN[0], GENERIC[12], PERSPECTIVE
> DCL IN[1], GENERIC[13], PERSPECTIVE
> DCL OUT[0], COLOR
> DCL SAMP[0]
> DCL CONST[1]
> DCL TEMP[0], LOCAL
> DCL TEMP[1], LOCAL
> DCL TEMP[2], LOCAL
> IMM[0] FLT32 {    0.2500,     0.0000,     0.0000,     0.0000}
>    0: MIN TEMP[0], IN[1], CONST[1].zwzw
>    1: MAX TEMP[0], TEMP[0], CONST[1].xyxy
>    2: TEX TEMP[1], TEMP[0].xyyy, SAMP[0], 2D
>    3: MUL TEMP[1], TEMP[1], IMM[0].xxxx
>    4: TEX TEMP[0], TEMP[0].zwww, SAMP[0], 2D
>    5: MAD TEMP[1], TEMP[0], IMM[0].xxxx, TEMP[1]
>    6: MIN TEMP[0], IN[0], CONST[1].zwzw
>    7: MAX TEMP[0], TEMP[0], CONST[1].xyxy
>    8: TEX TEMP[2], TEMP[0].xyyy, SAMP[0], 2D
>    9: MAD TEMP[1], TEMP[2], IMM[0].xxxx, TEMP[1]
>   10: TEX TEMP[0], TEMP[0].zwww, SAMP[0], 2D
>   11: MAD TEMP[0], TEMP[0], IMM[0].xxxx, TEMP[1]
>   12: MOV OUT[0], TEMP[0]
>   13: END
>
>
> The full dump data is here : http://pastebin.com/B4VtnwYK
>
> Hope it can help you a little.

Yes, I understand the problem now. Thanks for testing.
If you could create the trace with apitrace, it may simplify further 
debugging.

Vadim