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

Jason Ekstrand jason at jlekstrand.net
Fri Dec 19 18:09:11 PST 2014


On Fri, Dec 19, 2014 at 6:02 PM, Matt Turner <mattst88 at gmail.com> wrote:
>
> 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.
>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141219/1755c586/attachment-0001.html>


More information about the mesa-dev mailing list