On 01/05/2017 09:44 PM, Marek Olšák wrote:
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.
IIRC, NVIDIA blob does it as well.
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
