On Fri, Dec 19, 2014 at 6:02 PM, Matt Turner <matts...@gmail.com> wrote: > > 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. >
As a datapoint, apparently Merek (cc'd) bumped into this at one point on some unreal game. Perhaps he could shed some light. > 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." > That seems to imply that min(x, NaN) = min(NaN, x) = x which would make it commutative and associative. > 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
