[Mesa-dev] [PATCH 24/53] st/nine: Handle RSQ special cases

[Roland Scheidegger]

Slightly OT but IIRC the bug report on at least one of the bug
associated with NaN behavior said no issues with software rendering
(llvmpipe). llvmpipe implements full ieee754 NaN behavior, which
suggests to me it was some driver issue (like I said, I'd be pretty
surprised if full NaN behavior really would be an issue with modern
apps). I believe i965 also implements ordinary NaN behavior, except when
using fixed function pipeline (or maybe ARB_fp, can't remember).
Of course there's quite more stuff in NaN handling dictated by d3d10
than just arithmetic (for instance converting to fixed-point form needs
to give zero), which might not really be required by OpenGL, though I'd
generally expect hardware to adhere to that too...
So, generally I think it makes sense to follow d3d10 rules, especially
because OpenGL doesn't seem to be all that precise (and hardware is
likely to follow d3d10 rules). min/max may or may not be special (I have
no idea if blob drivers really honor the min/max as outlined in (newer
as older ones everything was allowed wrt nans) glsl spec).

Roland


Am 12.01.2015 um 19:47 schrieb Marek Olšák:
> No, TGSI documentation doesn't specify anything AFAIK, but we can
> adopt rules from other APIs.
> 
> The problem is that OpenGL and DX10 aren't the same and OpenGL doesn't
> say much about NaNs. For example, the DX10 "SNE" instructions are
> unordered while others are ordered, but OpenGL doesn't specify this,
> so the instinct says they are all ordered.
> 
> The other problem is that the GLSL compiler performs code
> transformations which are incorrect with NaNs. For example, 0*x is
> replaced by 0 during compilation.
> 
> Since the Unreal Engine doesn't really work with NaNs, I think we have
> no other choice than to turn them off. The problem might be in the
> GLSL compiler, in the GLSL->TGSI translation, in our LLVM backend, or
> even in the Unreal Engine itself.
> 
> Marek
> 
> On Mon, Jan 12, 2015 at 5:27 PM, Tom Stellard <tom at stellard.net> wrote:
>> On Thu, Jan 08, 2015 at 01:46:32PM +0100, Marek Olšák wrote:
>>> On Wed, Jan 7, 2015 at 7:09 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>> On Wed, Jan 7, 2015 at 11:36 AM, Axel Davy <axel.davy at ens.fr> wrote:
>>>>> We should use the absolute value of the input as input to ureg_RSQ.
>>>>>
>>>>> Moreover, an input of 0.0 should return FLT_MAX.
>>>>>
>>>>> Reviewed-by: David Heidelberg <david at ixit.cz>
>>>>> Signed-off-by: Axel Davy <axel.davy at ens.fr>
>>>>>
>>>>> Cc: "10.4" <mesa-stable at lists.freedesktop.org>
>>>>> ---
>>>>>  src/gallium/state_trackers/nine/nine_shader.c | 13 ++++++++++++-
>>>>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/src/gallium/state_trackers/nine/nine_shader.c b/src/gallium/state_trackers/nine/nine_shader.c
>>>>> index da77da5..4dee5f5 100644
>>>>> --- a/src/gallium/state_trackers/nine/nine_shader.c
>>>>> +++ b/src/gallium/state_trackers/nine/nine_shader.c
>>>>> @@ -1957,6 +1957,17 @@ DECL_SPECIAL(POW)
>>>>>      return D3D_OK;
>>>>>  }
>>>>>
>>>>> +DECL_SPECIAL(RSQ)
>>>>> +{
>>>>> +    struct ureg_program *ureg = tx->ureg;
>>>>> +    struct ureg_dst dst = tx_dst_param(tx, &tx->insn.dst[0]);
>>>>> +    struct ureg_src src = tx_src_param(tx, &tx->insn.src[0]);
>>>>> +    struct ureg_dst tmp = tx_scratch(tx);
>>>>> +    ureg_RSQ(ureg, tmp, ureg_abs(src));
>>>>> +    ureg_MIN(ureg, dst, ureg_imm1f(ureg, FLT_MAX), ureg_src(tmp));
>>>>
>>>> When would this MIN not return the value in tmp? In the description
>>>> you say that RSQ(0.0) should return FLT_MAX... is the theory that
>>>> MIN(NaN, FLT_MAX) == FLT_MAX? Is RSQ(0) in tgsi defined to return NaN?
>>>
>>> No, because legacy versions of MIN and MAX aren't commutative. To
>>> clarify this more, the legacy versions of MIN/MAX return x if either
>>> operand is NaN (non-commutative), while DX10 versions return the one
>>> that isn't NaN (commutative). For compatibility with the legacy
>>> versions, the FLT_MAX constant must be in x.
>>>
>>
>> Is it documented anywhere how min/max and other tgsi comparison instructions
>> are supposed to handle NaN and +-inf?  If not, we really need to get this
>> documented somewhere.
>>
>> -Tom
>>
>>> Marek
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=YsgTsMJVGFAmxXyVNA74tSBBXa-zFyaYNU9XO1kbj3E&s=b7JrQ6MbZ_NTFanrZ7730BKXH2nC5mbJH6fhLcGOk5w&e= 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=YsgTsMJVGFAmxXyVNA74tSBBXa-zFyaYNU9XO1kbj3E&s=b7JrQ6MbZ_NTFanrZ7730BKXH2nC5mbJH6fhLcGOk5w&e= 
>