[Mesa-dev] [RFC PATCH] nir/algebraic: Simplify max(abs(a), 0.0) -> abs(a)

[Ilia Mirkin]

On Fri, May 24, 2019 at 2:46 PM Alyssa Rosenzweig <alyssa at rosenzweig.io> wrote:
>
> > I /think/ that should be adequate here too.
>
> Do inexact values not need to handle NaNs strictly, then? I'm not sure
> what this corresponds to in the various GLs/CLs/Vulkan specs, hence
> labeling this RFC.

I don't know about Vulkan, but GL has a very childish approach to
NaN's -- you can pretty much do whatever and be in-spec.

Applications fall into two categories -- ones that expect NaN's and
carefully deal with them (maybe DX10, definitely DX11+), and ones that
are from a time before NaN on GPUs existed (DX9 and earlier).

I'm generally a lot less concerned about inexact opts that remove
NaN's (e.g. a - a -> 0, but Inf - Inf = NaN, or a * 0 -> 0, but Inf *
0 = NaN) than ones that add NaN's such as this one. I don't have a
specific example, but I can well imagine an application that would
expect this to have cleared out any NaN's, and you'll suddenly remove
their op.

But I also see the benefit of doing it since 99.99999% of the time
it's perfectly safe :)

  -ilia