On Fri, Dec 19, 2014 at 5:04 PM, Jason Ekstrand <ja...@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. [1] http://754r.ucbtest.org/drafts/archive/2006-10-04.pdf _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
