[Mesa-dev] NaN behavior in GLSL (was Re: [PATCH] glsl: always do sqrt(abs()) and inversesqrt(abs()))

[Roland Scheidegger]

Am 12.01.2017 um 22:03 schrieb Matteo Bruni:
> 2017-01-11 19:09 GMT+01:00 Jason Ekstrand <jason at jlekstrand.net>:
>> Another reason why I'm not a huge fan is that there is some momentum in the
>> industry to make GLSL better defined with respect to NaN.  I don't know that
>> anything will ever come of it (because it may break apps) but if something
>> does, we may find ourselves having to make SQRT and RSQ NaN-correct in the
>> future and, hey look, it'll break apps.
> 
> Hijacking the thread to focus on this. What's the interest about
> specifically (assuming that's something that can be talked about
> publicly?)
> 
> I'm asking because in Wine we have been bitten many times by the GLSL
> behavior WRT NaN and at the moment we really can't do anything
> sensible about it in the general case. Many d3d9 applications depend
> on not generating NaN in cases where e.g. IEEE 754 would expect to.
> The RSQ (i.e. inversesqrt()) from the original thread is one of those,
> but that's not really a problem for sane applications since it's
> "defined" in d3d8/d3d9 as taking the absolute value of the operand and
> indeed we translate RSQ to inversesqrt(abs(x)). The real issue is with
> cases like 0*inf, which AFAIK on d3d9 are supposed to give 0 as
> result.
> 
> Of course, that changes with d3d10+, which generally requires to
> generate and preserve NaN, as Roland already mentioned.
> 
> So, what would be really nice to have is a GLSL extension for some
> kind of switch to select the requested behavior WRT NaN. For example a
> three-way option with "don't generate NaN in arithmetic operations",
> "do generate NaN" and "don't care". It could also be a GL state if
> that's easier to implement with the existing hardware, since an
> individual application isn't supposed to require different behavior
> from one shader to the next.
> 
> Is anyone interested in / favorable to something like this? It would
> solve the issue with defining NaN behavior in GLSL while making things
> a bit more compatible with "other API a lot of games are ported from
> which happens to be supported by all the desktop GPUs".
> 
Is there actually a formal requirement that d3d9 hw never generates
NaNs? I think d3d9 is very lacking in spec there - if that is specified
somewhere I've never seen it... Maybe just everybody is expecting no
NaNs there too (because earlier hw couldn't do it). I think some hw
couldn't do infinity neither.

In any case, being able to select NaN behavior looks potentially quite
useful to me.

Roland


> Cheers,
> Matteo Bruni.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>