[Mesa-dev] About border values in fp64 conversion tests

[Roland Scheidegger]

Pretty sure this should be all undefined. double->int isn't really any
different than float->int there where you can have values which are too
large too.
Note that for float->int (and it should be the same for doubles) d3d10
requires that you clamp to destination type range, and NaN gets
converted to 0. Hence why implementations tend to do this. But still
undefined in glsl (which, of course, doesn't mean someone might not rely
on d3d10 behaviour there...).

Roland


Am 05.04.2016 um 09:33 schrieb Andres Gomez:
> Hi,
> 
> I haven't had any other feedback than Ilia's (thanks Ilia!) so my
> doubts still stand.
> 
> I'd welcome more info regarding this topic.
> 
> Thanks!
> 
> Br.
> 
> On Tue, 2016-03-15 at 17:46 +0200, Andres Gomez wrote:
>> Hi,
>>
>> as complementary work to the one done to "Add FP64 support to the
>> i965
>> shader backends" at:
>> https://bugs.freedesktop.org/show_bug.cgi?id=92760
>>
>> I've been working to add piglit tests that would check the new
>> features
>> added by this addition.
>>
>> One of the topics we have been creating tests for is
>> implicit/explicit
>> conversion from and to doubles in GLSL. We have created already a
>> generator for it but have some doubts about what to expect when
>> dealing
>> with conversions from a value out of range in the destination type.
>>
>> Specifically, I'm talking about negative doubles explicitly converted
>> into unsigned int or too big negative or positive double values
>> converted into int or unsigned int.
>>
>> What I've observed from running with the NVIDIA proprietary driver or
>> with other backends is that, typically, the conversion will result in
>> a
>> value which is the lowest or the highest defined in the destination
>> type, depending on the side of the happening overflow.
>>
>> However, I've been unable to find documentation in the GLSL specs
>> specifying how the conversions should work in this cases.
>>
>> My conclusion is that the behavior is undefined and will depend on
>> implementation. Hence, we won't add tests for these cases.
>>
>> Opinions?
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev