There are some TGSI shaders parsed by tgsi_text_translate which
declare floating-point immediates. Any incompatible change to the
parser would break them.
Marek
On Wed, Aug 28, 2013 at 3:57 PM, Jose Fonseca <jfons...@vmware.com> wrote:
> ----- 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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
