[Mesa-dev] [PATCH 1/2] nir: add a compiler option for disabling float comparison simplifications

[Ian Romanick]

On 11/30/2018 02:36 PM, Jason Ekstrand wrote:
> On Fri, Nov 30, 2018 at 4:34 PM Ian Romanick <idr at freedesktop.org
> <mailto:idr at freedesktop.org>> wrote:
> 
>     On 11/30/2018 01:29 PM, Jason Ekstrand wrote:
>     > On Fri, Nov 30, 2018 at 3:18 PM Ian Romanick <idr at freedesktop.org
>     <mailto:idr at freedesktop.org>
>     > <mailto:idr at freedesktop.org <mailto:idr at freedesktop.org>>> wrote:
>     >
>     >     On 11/29/2018 07:47 AM, Connor Abbott wrote:
>     >     > On Thu, Nov 29, 2018 at 4:22 PM Jason Ekstrand
>     >     <jason at jlekstrand.net <mailto:jason at jlekstrand.net>
>     <mailto:jason at jlekstrand.net <mailto:jason at jlekstrand.net>>> wrote:
>     >     >>
>     >     >> Can you provide some context for this?  Those rules are already
>     >     flagged "inexact" (that's what the ~ means) so they won't apply to
>     >     anything that's "precise" or "invariant".
>     >     >
>     >     > I think the concern is that this isn't allowed in SPIR-V,
>     even without
>     >     > exact or invariant. We even go out of our way to do the
>     correct thing
>     >     > in the frontend by inserting an "&& a == a" or "|| a != a",
>     but then
>     >
>     >     If you're that paranoid about it, why not just mark the
>     operations are
>     >     precise?  That's literally why it exists.
>     >
>     >     > opt_algebraic removes it with another rule and then this
>     rule can flip
>     >     > it from ordered to unordered. The spec says that operations
>     don't have
>     >     > to produce NaN, but it doesn't say anything on comparisons
>     other than
>     >     > the generic "everything must follow IEEE rules" and an entry
>     in the
>     >     > table that says "produces correct results." Then again, I
>     can't find
>     >     > anything in GLSL allowing these transforms either, so maybe
>     we just
>     >     > need to get rid of them.
>     >
>     >     What I hear you saying is, "The behavior isn't defined." 
>     Unless you can
>     >     point to a CTS test or an application that has incorrect
>     behavior, I'm
>     >     going to oppose removing this pretty strongly.  *Every* GLSL
>     compiler
>     >     does this.
>     >
>     >
>     > The test case came from VKD3D which does D3D12 on Vulkan.  Someone
>     > (Samuel, maybe?) was going to ask around and see if we can figure out
>     > what D3D12's rules are.  It's possible that it requires IEEE or
>     > something close.  If that's the case, as I said to Samuel on IRC,
>     we're
>     > probably looking at an extension.  I don't think we want a flag like
>     > this that's set per-API.
> 
>     Why isn't it sufficient to mark the operation as precise?  Was that on
>     IRC, and I missed it?
> 
>     It is also possible that we could improve the handling of 'if
>     (!condition)' in the backend to make these transformations less
>     important.  I have some patches for that somewhere.  They didn't really
>     help with these transformations in place, and I never measured the
>     result without these transformations.
> 
> I think we can and that would be better than this flag.

Ok.  I'll resurrect my patches next week.