more on the same topic: 
implementing isNan or isInf give different results depending the values are const or not.
https://www.shadertoy.com/view/lsjBDy

more on the same topic: 0./0. , 1./0. (NaN and Inf), with const or not.
https://www.shadertoy.com/view/4ldGDN

Thanks for filing the issue, could you please help us with a sample screen shot for expected and actual behavior. This will help us to triage the issue better.

Thanks.!

Due to lack of user response closing this issue, please raise a new issue if you come across the similar one in any of the latest chrome versions.

Thanks!

what ?!

I didn't answered because
- I don't know any system having the expected behavior. (Or should I gimp-paint one ?)
- the expected color behavior is described in the text just below:
  The left column should be all black, the right column should be pink. 

Stated even more simply: columns should be constant color, since math result shouldn't depends on variable being either #def, const, variable, uniform.

The issue here is pretty clear to me and I don't think we need screenshots.

That said, it's not clear to me that this is necessarily a bug. Some of the differences here are almost certainly hardware/driver-dependent (though it does look like it reproduces for me my machine (below)). It will require some significant spec digging to determine whether these differences in behavior are allowed. Even if these behavior differences turn out to be in violation of the spec, I'm not sure that it would be worth it to fix this in Chrome, since it might be expensive.

The spec digging in question would probably be in the GLSL ES specs:
1.00: https://www.khronos.org/files/opengles_shading_language.pdf
3.00: https://www.khronos.org/registry/OpenGL/specs/es/3.0/GLSL_ES_Specification_3.00.pdf
because not all floating point operations in GLSL adhere to IEEE 754.

Reporter: if you're able to find some references in the spec, it would be easier for us to look into this.

I tried testing these on Firefox, but for some reason Shadertoy's WebGL 2 support isn't working in Firefox on my machine. shadertoy.com/view/MtfyRf works the same in Chrome and FF for me, but the others don't load in FF unless I disable WebGL 2. If I do that, some of them look wildly different than they do in Chrome - but it may be a native context version difference.

Chrome version    Chrome/62.0.3202.94
Operating system  Linux 4.9.0-4-amd64
GL_RENDERER       Quadro K620/PCIe/SSE2
GL_VERSION        4.5.0 NVIDIA 375.66

so maybe the "bug" would rather interests those who do the drivers. The neat thing about bugs.chromium is that it is a crossroad of people from various layers and often knowing where to best reroute something.

In a long shader, the fact that changing some variable from const to non-const (or the reverse) will change the output of some function elsewhere is just an evil bug trigger (good luck for debugging). I can't think it serves any on-will purpose, it just look like a mistake.

oetuaho: do you know what's going on here? Do you think anything can be done?

The GLSL spec is quite lenient when it comes to NaNs and how constness affects evaluation of expressions, so in these areas ANGLE is not in violation of the spec as far as I know. I also took some care to follow IEEE rules for generating infinities and zeroes when evaluating constant expressions as the GLSL spec requires.

The errors the linked ShaderToy shaders point out seem to be related to full IEEE compliance, not GLSL spec compliance. Also I don't think the result of 1./floor(1./0.) as evaluated by ANGLE is actually wrong even according to IEEE.

As opposed to following IEEE rules, ANGLE evaluates constant expressions with an undefined result in GLSL as zero and issues a warning. In some cases ANGLE also implements constant folding using standard library functions that may not be fully IEEE compliant. IEEE would require generating specific results in quite a few of these cases. For example sqrt(negative) => NaN, and it seems like floor(Inf) => max float, if we interpret the spec so that "floor" is supposed to implement "rounding towards negative infinity" in IEEE-speak.

If there's a good enough reason to make ANGLE's evaluation of constant expressions more IEEE compliant, it could be done, but fixing everything comprehensively is quite a bit of work.

Non-constant expressions are left to the driver, and ANGLE has limited control over them. So behavior might differ between constants and non-constants on a single platform, but behavior of constant expressions is consistent across platforms. Behavior of constant expressions may affect whether a shader compiles or not, so it's fairly important that they're evaluated consistently. I'm not sure how wildly different hardware platforms differ in their IEEE compliance, and what would be the best steps to take if we want better consistency between const/non-const expression evaluation.


Relevant GLSL ES 3.00.6 spec sections follow:


Section 4.5.1:

"Infinities and zeros are generated as dictated by IEEE."

"NaNs are not required to be generated."

"Operations including built-in functions that operate on a NaN are not required to return a NaN as the result."

"Within the above specification, an implementation is allowed to vary the representation of numeric values, both within a shader and between different shaders.  If necessary, this variance can be controlled using the invariance qualifier."

Invariance can only be required when two expressions have the same const/non-const qualifiers, so this part of the spec is lenient enough even for expressions qualified as invariant.


Section 4.5.3:

"For constant expressions and sub-expressions, where the precision is not defined, the evaluation is performed at or above the highest supported precision of the target (either mediump or highp).  The evaluation of constant expressions must be invariant and will usually be performed at compile time."


Section 13.4:

"Should there be general invariance rules for numeric formats and operations?"

"Operations and formats are in general considered to be variant."

Thanks for this developed answer.
Just 2 remarks:

- There are not only issues with NaN, but also with Inf. In the section 4.5.1 you mention, the IEEE conformance of the later is presented as more strict.

- In case GLSL conformance was considered sufficient and fix by Angle too involved, as you said constructors don't have the same criterions about IEEE conformance (e.g. Nvidia hardware used via Cuda is supposed to be able to run scientific calculations correctly). So it may be that they are interested in conforming better to IEEE... if they are informed of the issues. -> do you have a channel to route them the report ?

CUDA has strict requirements for floating point behavior yes. But in the case of graphics it can make sense to trade some floating point strictness/precision for performance - this is why the GLSL spec is the way it is. The GLSL compiler may generate different machine code than the CUDA compiler for similar operations.

In the linked ShaderToy shaders, I didn't see any operations that are required to generate Inf according to IEEE but that would have been misbehaving for me. If you have an example can you make a minimal test just for that?

I do have channels to get back to our compiler developers and would be interested in hearing about any reproducible NVIDIA-specific conformance bugs, especially if it's visible on newer GPU generations.

"CUDA has strict requirements": what about compute shaders ?

acid test on Inf:  I just reparsed my various tests ( one had a bug :-( ) and did new ones. In fact I (no longer) see any error concerning Inf. 
Sorry for the wrong statement on this point.
-> Only NaN seems to have the issue.

I'd say GLSL compute falls somewhere in between CUDA and GLSL vertex/fragment. Introduction of compute could be a good reason to tighten up ANGLE behavior to be closer to IEEE.

Thanks Olli for your detailed explanation. Also adding some Intel colleagues in case they are also interested.

Thanks for directing the issue! As we're doing compute shader in ANGLE, we will investigate (maybe not very soon as we want to have compute shader OpenGL path work first) this to see if we can improve ANGLE from compute shader perspective. 

Adding blocked on bug angleproject:3064, an alternative to defining the undefined behavior