[Mesa-dev] [PATCH v3 134/133] nir/opcodes: Add algebraic properties metadata

[Roland Scheidegger]

Am 20.12.2014 um 03:02 schrieb Matt Turner:
> On Fri, Dec 19, 2014 at 5:04 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>> v3: fmin and fmax technically aren't commutative or associative.  Things
>>     get funny when one of the arguments is a NaN.
> 
> I have a difficult time believing that the GLSL definitions of min()
> and max() intentionally have that effect.
> 
> To recap, the definition of min() in GLSL is
> 
>> Returns y if y < x, otherwise it returns x.
> 
> and since comparisons against NaN are always false, min(x, y) where x
> or y is NaN will always return x, regardless of which argument is NaN.
> That doesn't seem like a useful behavior.
> 
> Indeed the GLSL spec says
> 
>> Operations and built-in functions that operate on a NaN are not required to return a NaN as the result.
> 
> I think based on that text alone, min() and max() should be considered
> commutative and associative.
> 
> Ian, perhaps we should clarify this with Khronos?
> 
> An IEEE 754 spec draft [1] defines minNum(x, y) as "y if x<y, x if
> y<x, the canonicalized floating-point
> number if one operand is a floating-point number and the other a NaN.
> Otherwise it is either x
> or y."
> 
> i965's SEL instruction implements that behavior.
> 

Not only ieee754-2008, but 3d10 (and opencl) require that behavior. So,
all hw will implement it that way (even llvmpipe does though it's extra
work and wouldn't be necessary right now just for opengl), unless it can
possibly switch behavior some way.
Maybe it's an oversight in the spec, older versions didn't really
require consistent behavior wrt NaNs generally (thus the behavior
everybody already does was covered) so only from 4.1 onwards the exact
description (which was not changed) really matters.

Roland