[Mesa-dev] [PATCH 03/10] radeonsi: disable NaNs for LS and HS

[Ilia Mirkin]

On Sun, Oct 11, 2015 at 6:58 AM, Marek Olšák <maraeo at gmail.com> wrote:
> On Sun, Oct 11, 2015 at 4:29 AM, Roland Scheidegger <sroland at vmware.com> wrote:
>> FWIW I'm still baffled by this shader bit.
>> NaNs are absolutely required to be generated and handled as NaNs in
>> shaders (albeit conversion to ints will make them 0) by DX10 (there's
>> plenty of tests which actually check for this). And generally, you
>> really want to generate NaNs for newer glsl versions too I think, albeit
>> this may not be strictly required (of course, currently you can't
>> distinguish this in tgsi, but particularly gs/ls/hs will always be newer
>> glsl versions).
>> So I'm REALLY wondering why there's a shader bit named that way...
>
> I don't know either. The bit basically converts NaNs to 0 before an
> instruction result is written into a register.
>
> From GL_ARB_shader_precision:
>
> "Operations and built-in functions that operate on a NaN are not
> required to return a NaN as the result." I think that NaNs in
> conditional expressions are still handled as NaNs, e.g. if you get
> NaNs from a constant buffer.
>
> Besides that, GLSL optimizations passes and the GLSL->TGSI conversion
> are incorrect with regard to NaNs, so even if the hardware returned
> NaNs according to IEEE, the NaN behavior would different from IEEE.

FWIW one thing that tripped me up on nvc0 is that starting with Fermi,
the shaders started handling denorms. I had to enable flush-to-zero on
all floating point ops in order to make Heaven work, otherwise I got
big solid-color rects all over -- I think it was comparing something
to 0 and failing. We also enable nan-to-zero on the multiply for pow,
i.e. exp2(b * log2(a)) -- if a is zero, then log2(a) is NaN, but we
want 0^0 == 1 for LIT. I believe this is all kosher wrt
ARB_shader_precision.

  -ilia