On 12/01/2017 22:03, Matteo Bruni wrote:
2017-01-11 19:09 GMT+01:00 Jason Ekstrand <ja...@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".
Preventing NaN from being generated is not sufficient to fix the 0*inf =
0 issue.
For example radeonsi does convert all NaN to zeros via a hardware setting.
But 0*inf = 0 behaviour should be also in mad, and with the NaN to zero
conversion, you get 0 * inf + 24 = 0 instead of 24.
Yours,
Axel Davy
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
