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.
>
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 wr
- 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
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 repa
>> 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
- 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
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 div
