Re: [Mesa-dev] tgsi dump and parsing
Yes, if we change the representation, we should keep backwards compatability in
tgsi text parsing
Jose
- Original Message -
> 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 wrote:
> > - Original Message -
> >> On Wed, Aug 28, 2013 at 3:32 PM, Dave Airlie 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
Re: [Mesa-dev] tgsi dump and parsing
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 wrote:
> - Original Message -
>> On Wed, Aug 28, 2013 at 3:32 PM, Dave Airlie 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
Re: [Mesa-dev] tgsi dump and parsing
- Original Message -
> On Wed, Aug 28, 2013 at 3:32 PM, Dave Airlie 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
Re: [Mesa-dev] tgsi dump and parsing
On Wed, Aug 28, 2013 at 3:32 PM, Dave Airlie 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.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] tgsi dump and parsing
>> 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.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] tgsi dump and parsing
- Original Message -
> On 08/26/2013 02:38 AM, Dave Airlie wrote:
> > Hi TGSI guys mostly :-)
> >
> > So I'm wondering how circular and perfect tgsi->text->tgsi roundabouts
> > should be,
>
> Ideally, they should be consistent.
>
>
> > currently the TGSI dump code uses .4f in one place, which makes things
> > like 1e6 not make it across the divide, I was thinking of dumping
> > immediates in 32-bit hex format so we know for definite what happens
> > on the other side,
>
> Yeah, I think we'd have to dump floats as hex to always preserve their
> value.
>
> However, I'd like to maintain the readability of float immediates in
> dumps. Maybe they could be displayed as a comment. Something like:
>
> 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.
Jose
>
>
> > I've been thinking of maybe adding a debug option to softpipe to dump
> > to text and read it back, to see what other regression lie in wait.
>
> Sounds OK to me but it could be a TGSI debug option that would test
> dumping + reassembling a shader whenever tgsi_dump() is called.
>
> -Brian
>
> ___
> 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
Re: [Mesa-dev] tgsi dump and parsing
On 08/26/2013 02:38 AM, Dave Airlie wrote:
Hi TGSI guys mostly :-)
So I'm wondering how circular and perfect tgsi->text->tgsi roundabouts
should be,
Ideally, they should be consistent.
currently the TGSI dump code uses .4f in one place, which makes things
like 1e6 not make it across the divide, I was thinking of dumping
immediates in 32-bit hex format so we know for definite what happens
on the other side,
Yeah, I think we'd have to dump floats as hex to always preserve their
value.
However, I'd like to maintain the readability of float immediates in
dumps. Maybe they could be displayed as a comment. Something like:
IMM[0] FLT32 { 0x, 0x, 0x, 0x } # 1.0, 3.0, 2.0, 4.0
I've been thinking of maybe adding a debug option to softpipe to dump
to text and read it back, to see what other regression lie in wait.
Sounds OK to me but it could be a TGSI debug option that would test
dumping + reassembling a shader whenever tgsi_dump() is called.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] tgsi dump and parsing
Hi TGSI guys mostly :-) So I'm wondering how circular and perfect tgsi->text->tgsi roundabouts should be, currently the TGSI dump code uses .4f in one place, which makes things like 1e6 not make it across the divide, I was thinking of dumping immediates in 32-bit hex format so we know for definite what happens on the other side, I've been thinking of maybe adding a debug option to softpipe to dump to text and read it back, to see what other regression lie in wait. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
