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. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
