[Mesa-dev] tgsi dump and parsing

[Jose Fonseca]

----- Original Message -----
> On Wed, Aug 28, 2013 at 3:32 PM, Dave Airlie <airlied at gmail.com> wrote:
> >>> IMM[0] FLT32 { 0x...., 0x...., 0x...., 0x.... }  # 1.0, 3.0, 2.0, 4.0
> >>
> >> If you use "%.9g" instead of "%.4f" then floating point numbers will be
> >> preserved without loss of precision.
> >>
> >
> > I see a -nan in my tests that doesn't get reparsed so I expect hex is
> > still better.
> >
> >
> > oops to list as well this time, sorry.
> 
> Just in case you are wondering its
> tests/shaders/glsl-const-builtin-inversesqrt.shader_test and
> tests/shaders/glsl-const-builtin-normalize.shader_test
> that throw up the -nan in the dumps.

We could teach tgsi_parse to understand `nan` too.

We could also have a new tgsi_compare() function that, instead of doing a bare memcmp, it would scan the tokens, and account for the ambiguity of NaNs in IMM FLT32.


I just feel a bit awkward that we have `IMM[x] INT32 {...}` and `IMM[x] FLT32 {...}` but end up dumping floats as integers. The whole point of INT32/FLT32 is to allow humans to read the numbers, because it is just syntactic sugar: by definition a shader must behave precisely the same way regardless the IMMS have INT32 or FLT32, as in TGSI the type is not defined by the arguments but rather the opcodes.

Also, editing IMM FLT32 by hand will be much harder -- you'll need to convert floats their integer repreentation, as the floats in the comment will likely be ignored..


To me, it seems that would be trading off a concrete advantage -- the usability of the TGSI textual representation --, for this much more dubious advantage of perfect bit-by-bit reversibility of TGSI binary<->text shaders.


That said, I don't feel strongly either way. 


Jose