[Mesa-dev] [PATCH 1/2] nir: add an isinf opcode, and an option to use it.

[Roland Scheidegger]

Am 17.03.2017 um 04:33 schrieb Roland Scheidegger:
> Am 17.03.2017 um 02:29 schrieb Dave Airlie:
>> On 17 March 2017 at 11:09, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>> On March 16, 2017 5:04:37 PM Dave Airlie <airlied at gmail.com> wrote:
>>>
>>>> From: Dave Airlie <airlied at redhat.com>
>>>>
>>>> In order to get isinf(NaN) correct, at least radv can't
>>>> use an unordered equals which feq has to be for us, this
>>>> passes isinf to the backend and let's it sort it out as it
>>>> pleases.
>>>
>>>
>>> I think comparisons are something that were going to need to sort out better
>>> in general.  SPIR-V's rules are stricter than GL (at least the way we
>>> interpret it).  Could you please be more specific about the issue?
>>
>> IsInf(NaN) unordered appears to end up at true, when the spec for isinf
>> says it should be false.
>>
>> well SPIR-V has the unorder and ordered stuff for OpenCL kernels, just
>> not sure what want in NIR in this area. If I default to using ordered compares
>> for NIR I get isnan and funord fails last I tried.
> 
> FWIW tgsi uses ordered for all comparisons except not equal.
> Ok well maybe not all drivers do, but that's what I'd consider what it
> should be (radeonsi does that too at a quick glance). Because, well, you
> guessed it, d3d10... GL of course won't mandate anything with its super
> relaxed nan rules. But this pretty much matches what you get with
> ordinary comparison operators in c, so may uneducated guess is it would
> be a good match for nir too...

Forgot to mention, doing that should fix isnan, as that uses not equal.
But if spir-v needs all comparisons both in ordered and unordered form
you're screwed either way if you don't have them in nir.

Roland