On Thu, Jan 5, 2017 at 9:00 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 05.01.2017 um 20:43 schrieb Samuel Pitoiset: >> >> >> On 01/05/2017 06:49 PM, Roland Scheidegger wrote: >>> Meh, I'm not really a big fan of such hacks. GPUs have support for NaNs >>> since ages, and while glsl is lenient the point stands that returning a >>> NaN is a more correct result, so doing extra work to get a wrong result >>> doesn't look all that great to me. >>> FWIW dx10 requires NaNs as results (for both sqrt and rsq). Maybe app >>> specific quirks (if said apps can't be fixed) would be better... >>> But well, it's your driver, so whatever floats your boat. >> >> I think the main idea here is to reduce the number of bug reports when >> applications use D3D-style for RSQ/SQRT instead of what GLSL spec says. > > Well if someone ports from d3d10, he might well expect NaNs since d3d10 > guarantees you get a NaN there... > (That said, with d3d10 NaNs will get converted to zeros on pixel shader > export if the RT isn't a float type, I don't know what mesa drivers to > there.) > Not saying it wouldn't make sense doing such hackery at glsl level but > imho it still should be a quirk.
It looks like closed GL drivers always apply abs before rsq, so we should do so too. The GLSL compiler seems like the correct place. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
