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

[Ian Romanick]

On 11/30/2018 01:36 PM, Bas Nieuwenhuizen wrote:
> On Fri, Nov 30, 2018 at 10:29 PM Jason Ekstrand <jason at jlekstrand.net> wrote:
>>
>> On Fri, Nov 30, 2018 at 3:18 PM Ian Romanick <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> 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.
> 
> What do you mean an extension? AFAIU the concern is that Vulkan SPIR-V
> is more restrictive than GLSL here, and disallows these optimization
> right? That makes a strong case that we should remove these rules for
> at least Vulkan. If that means writing a CTS test, maybe we should do
> just that?

Given the existence of mobile GPUs, it seems unlikely to me that Vulkan
SPIR-V is more strict about NaNs or denorms than GLSL or GLSL ES.  The
mobile vendors didn't have the extra DX requirements, so, for a variety
of valid reasons, they pushed back on making much of anything more strict.