[Mesa-dev] glsl_to_tgsi error in register renumbering or merging?

Ilia Mirkin imirkin at alum.mit.edu
Fri Jan 29 10:24:35 PST 2016


Hello,

I've been looking at removing some of the optimization passes ahead of
nouveau's codegen, and noticed a huge increase in instructions for
some shaders. Upon further investigation, I think there's an error in
the renumbering pass, which causes a bunch of values to be overwritten
and thus dead (which nouveau then dutifully eliminates).

Here's a TGSI sequence without renumbering:

 94: MUL TEMP[56].xyz, TEMP[34].xxxx, TEMP[55].xyzz
 95: MOV TEMP[32].yzw, TEMP[56].yxyz
 96: FSGE TEMP[57].x, TEMP[48].xxxx, IMM[3].zzzz
 97: UIF TEMP[57].xxxx :0
 98:   MOV TEMP[58].xyz, TEMP[56].xyzx
 99: ELSE :0
100:   MOV TEMP[58].xyz, IMM[3].zzzz
101: ENDIF
102: MOV TEMP[59].xyz, TEMP[58].xyzx
103: MOV TEMP[32].xyz, TEMP[58].xyzx

And here's the same sequence with merging and renumbering enabled:

 94: MUL TEMP[5].xyz, TEMP[7].xxxx, TEMP[5].xyzz
 95: MOV TEMP[5].yzw, TEMP[5].yxyz
 96: FSGE TEMP[7].x, TEMP[13].xxxx, IMM[3].zzzz
 97: UIF TEMP[7].xxxx :0
 98:   MOV TEMP[5].xyz, TEMP[5].xyzx
 99: ELSE :0
100:   MOV TEMP[5].xyz, IMM[3].zzzz
101: ENDIF
102: MOV TEMP[16].xyz, TEMP[5].xyzx
103: MOV TEMP[5].xyz, TEMP[5].xyzx

Note that the IF selects between TEMP[56].xyz and some immediate,
where TEMP[56].xyz is the output of the MUL at label 94.

However in the merged/renumbered version, it immediately overwrites
TEMP[5].yzw with TEMP[5].xyz. If things had been adjusted to then use
TEMP[5].yzw instead of .xyz, then it would make sense, but it doesn't
seem like such an adjustment was made.

Mainly my question is... does my analysis appear to be correct? I
guess it should avoid merges (or renumbers?) when it does a MOV with a
non-identity swizzle?

Thanks,

  -ilia

P.S. FTR, this particular shader is from "Dungeon Defenders", but it's
hardly the only example.


More information about the mesa-dev mailing list