On Sun, Oct 11, 2015 at 6:58 AM, Marek Olšák <mar...@gmail.com> wrote: > On Sun, Oct 11, 2015 at 4:29 AM, Roland Scheidegger <srol...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
