On Fri, May 24, 2019 at 2:46 PM Alyssa Rosenzweig <aly...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
