GLSL bug: a/a = 1, 0*a=0 for a = NaN
Reported by
fabrice....@gmail.com,
Nov 30 2017
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36 Example URL: https://www.shadertoy.com/view/ltfBW7 Steps to reproduce the problem: 1: a = NaN ( a ordinary non-const variable ) 2: a/a = 1, 0*a = 0, while (a+zero)/a=NaN , zero*a+1 = NaN if compiler ignore that zero=0 What is the expected behavior? NaN/NaN = NaN 0*NaN = NaN What went wrong? on windows : NaN/NaN = 1 on windows & linux: 0*NaN = 0 Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? No firefox Chrome version: 58.0.3029.81 Channel: n/a OS Version: Flash Version: Shockwave Flash 27.0 r0 on https://www.shadertoy.com/view/ltfBW7 , all should be black. On windows, left is white. on linux, bottom left is white. top: a/a bottom: 0*a+1 right: simplification hidden to the compiler May somebody please add the tags Blink>WebGL Internals>GPU ? thanks ! ⛆ |
|
|
,
Nov 30 2017
,
Dec 1 2017
First, note that this is not a violation of the GLSL spec. More detailed explanation of this can be found in https://bugs.chromium.org/p/chromium/issues/detail?id=772657#c11 This is related to how ANGLE uses the HLSL compiler. There's a HLSL compiler flag to toggle IEEE strict mode on that would likely help with this case: D3DCOMPILE_IEEE_STRICTNESS https://msdn.microsoft.com/en-us/library/windows/desktop/gg615083(v=vs.85).aspx But since the flag comes with a performance penalty, I'd be hesitant to enable it. This example in particular is very artificial and I have not seen any real apps that would have demonstrated a need for IEEE strictness. We could consider setting the flag for compute shaders exclusively, or making a WebGL extension that would provide a "#pragma ieee_strict_float" preprocessor directive or something like that for shaders to use. But the extension would be of no use when WebGL is backed by OpenGL.
,
Dec 1 2017
I understand. Sure acid tests are artificial :-) . Still, since +Inf ends up as white, and -Inf & NaN ends up as black, I wonder whether this might appear in various existing shader (consciently or not). (a bit like for these ones I did purposely (background is black in OpenGL): https://www.shadertoy.com/view/XsdXRl https://www.shadertoy.com/view/XstXzs https://www.shadertoy.com/view/XlfBW7 https://www.shadertoy.com/view/XtfBW7 ) Also, a behavior giving white or black depending on the optimizer and the OS is always a bit frightening. It also means that when using isinf() and isnan() one have to be sure at which stage to test it to be sure the expression is meaningful. The flags sounds like a very good idea to me. Maybe glsl might be interested by adding one too some day ? ( none of the variable qualifiers have this side effect, BTW ? )
,
Dec 1 2017
I agree with Olli that we don't want to apply D3DCOMPILE_IEEE_STRICTNESS in general. Exposing an extension sounds like a good idea.
,
Dec 2 2017
Filed here: https://github.com/KhronosGroup/WebGL/issues/2554 Marking as ExternalDependency because I don't think we will do anything about this in Chrome until after we have discussed adding such an extension.
,
Dec 2 2017
,
Oct 9
,
Jan 21
(2 days ago)
Adding blocked on bug angleproject:3064, an alternative to defining the undefined behavior |
|||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by cbiesin...@chromium.org
, Nov 30 2017