----- Original Message -----
> On Wed, Aug 28, 2013 at 3:32 PM, Dave Airlie <airl...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
