[Mesa-dev] Suboptimal code generation

Roland Scheidegger sroland at vmware.com
Fri Nov 14 11:41:24 PST 2014


Am 14.11.2014 um 19:38 schrieb Henri Verbeet:
> On 14 November 2014 18:50, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> I can't speak for the radeon guys, but I know I sure would love to see
>> any reports of poor code being generated by nouveau in response to
>> legitimate-seeming TGSI (or GLSL). In some cases, a simple
>> optimization can be added to take care of it, and I'd definitely
>> appreciate the extra pair of eyeballs on driver-generated code :)
>>
>> The report can be as simple as "here is the TGSI snippet, take a look
>> at how crappy the code it generates is". At least for nouveau, I can
>> feed that directly into a compiler that can target any of the relevant
>> backends.
>>
>> [Note, r600g didn't have an optimizer enabled until ~1y ago; not sure
>> if your analysis was with or without sb.]
>>
> It was with sb, but probably before TGSI got FSLT/FSGE/etc.
> 
> For reference, what currently happens for r600g is something like this:
> 
> D3D:
>     cnd r[0], r[0].w, c[1], c[2]
> 
> GLSL:
>     R0.xyzw = (R0.w > 0.5 ? ps_c[1].xyzw : ps_c[2].xyzw);
> 
> TGSI:
>     FSLT TEMP[0].x, IMM[0].xxxx, TEMP[0].xxxx
>     UIF TEMP[0].xxxx :0
>       MOV TEMP[0], CONST[1]
>     ELSE :0
>       MOV TEMP[0], CONST[2]
>     ENDIF
> 
> R600:
>     SETGE_DX10         T0.x,  0.5, T0.x
>     CNDE_INT           R0.x,  T0.x, KC0[1].x, KC0[2].x
>     CNDE_INT           R0.y,  T0.x, KC0[1].y, KC0[2].y
>     CNDE_INT           R0.z,  T0.x, KC0[1].z, KC0[2].z
>     CNDE_INT           R0.w,  T0.x, KC0[1].w, KC0[2].w
> 
> While ideally that would just be 4 CNDGE's, that's better than what I
> remember. IIRC there used to be a bunch of int/float conversions as
> well.

That looks quite ok to me. Slightly suboptimal maybe but quite
reasonable - you can't really expect "optimal" code always. (With the
proposal to nuke cnd from tgsi though you'd just generate the same in
any case probably.)
I suspect the bunch of int/float conversions got away when switching
comparison operation stuff in glsl to tgsi translation to using ints
ones on hardware which supports integers (a year ago or so). I know this
made some tgsi look a bit nicer but I don't know the effects this had on
backends (which also probably learned some new tricks since then).



More information about the mesa-dev mailing list