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

Andres Gomez agomez at igalia.com
Thu Apr 14 09:26:12 UTC 2016


Thanks a lot for the comments, Roland. This confirms my understanding.

Since there seems not to be any more feedback, I will now send the
patch for conversion tests I was working on for piglit's review.

Thanks again. :)

On Tue, 2016-04-05 at 16:29 +0200, Roland Scheidegger wrote:
> 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
> 
-- 
Br,

Andres

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160414/c860844c/attachment.sig>


More information about the mesa-dev mailing list