On Thu, Jan 5, 2017 at 10:06 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 05.01.2017 um 21:50 schrieb Samuel Pitoiset: >> >> >> 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. > Ok, it's difficult to argue against that... > "Everybody is actually doing it wrong so we must follow them or we'll > see bugs..." Pretty sure this is essentially some issue coming from a > time when gpus didn't have NaNs so everybody relied on result being > non-NaN and now because all drivers do it still noone notices they still > have bugs relying on that behavior. > Anyway, I'm fine with any solution as long as the abs behavior isn't > implied by the tgsi opcode...
No, drivers are not doing it wrong. OpenGL says that sqrt(x < 0) is undefined, so drivers can do anything and it would be correct. It's only unfortunate that some apps rely on a specific behavior where no behavior is formally defined by OpenGL. It looks like you don't like it because VMWare has GL<->D3D translators, but I don't see how this would impact VMWare, because if you replace Mesa with a closed driver, you'll have the same problem. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
