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

[Roland Scheidegger]

Am 11.10.2015 um 12:58 schrieb Marek Olšák:
> 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.
> 
> Marek
> 

I just don't like the total ambiguity we have in gallium (tgsi in
particular) wrt NaNs. In particular, there are drivers which will never
do such a "fix" (which is really just a hack), e.g. llvmpipe
specifically has code to propagate NaNs correctly for "complex"
operations (and will always propagate them for simple operations),
because that's what dx10 requires, and while glsl may not require it I'm
pretty sure some blobs will do that as well - it is certainly allowed,
and typically only applications written for pre-dx10 hw may depend on
not getting NaNs (because the actual hw there didn't support NaNs). Of
course, if you implement sqrt with 1/rsqrt and that causes problems
because you don't get 0 with a 0 input that is something which needs to
be fixed some way, but that's really another story.
But well, you can do what you want for radeon. I think though some day
we need some better handling of this in gallium/tgsi anyway.