Am 20.12.2014 um 03:02 schrieb Matt Turner: > 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. >
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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
