Am 12.01.2017 um 22:03 schrieb Matteo Bruni: > 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". > 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
