[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