I've tested with:
53.0.2769.2 (Official Build) canary (64-bit)
51.0.2704.84 (Official Build) (64-bit)

on a Retina MacBook Pro (NVIDIA GPU) running Mac OS 10.11.5. Works in both cases.

Could you provide about:gpu from an affected machine? Example attached.

It's possible that the work Erik's been doing to enable CHROMIUM_image for WebGL might have broken things temporarily on a Canary build, but I don't think such a change would have made it to Stable. It seems more likely something's up with the machine.

Deleted: about-gpu.txt 7.3 KB

about-gpu.txt 7.3 KB View Download

about:gpu from the machine.

Deleted: about-gpu.txt 7.1 KB

about-gpu.txt 7.1 KB View Download

hpayer@ and I looked at this. Oort Online's rendering reliably fails on the AMD MacBook Pro Retina. The rendering artifact almost looks like something's wrong with clipping planes or the depth test, but clipping planes don't exist in ES 2.0. Maybe the problem is that we don't initialize shader variables to zero in WebGL yet, and the shaders are relying on temporary variables being initialized to zero. Needs more investigation. Also need to confirm on another AMD Retina MBP. All other WebGL content we tested rendered fine.

Also broken on Safari and FF Nightly.

fwiw, the demo also doesn't work on my MBA (it never did)

Through some luck one of the AMD Retina MacBook Pros in our office was running Mac OS 10.11.4, and we've narrowed this down to a regression in Mac OS 10.11.5.

The problem affects desktop Mac Pros with AMD GPUs as well. Changing the synopsis.

zmo@ found that switching Chrome to the OpenGL Core Profile via the command line option --enable-unsafe-es3-apis surprisingly works around the bug, though we still don't know what it is yet.

about:gpu from the Mac Pro in both Compatibility and Core Profile mode attached.

For the time being I'm going to block this on switching Chrome to the Core Profile on Mac OS.

Deleted: about-gpu-compatibility-profile.txt 7.1 KB

about-gpu-compatibility-profile.txt 7.1 KB View Download

Deleted: about-gpu-core-profile.txt 5.3 KB

about-gpu-core-profile.txt 5.3 KB View Download

Filed Radar 26926077 with Apple about this regression.

Marking ExternalDependency for the moment. I'd like to debug exactly what's going wrong but that may take quite some time.

We received feedback from Apple that this is actually a bug in Oort Online's shaders exposed by an update to the shader compiler. Here's the text (there's nothing confidential in it, so I feel there is no issue in sharing the information publicly):

--------

The root problem is that the sunlight diffusing shader(the 83th shader) and some other shaders does not check NaN during arithmetic operations. In sunlight diffusing shader, when the min/max is optimized by shader compiler to clamp, which is computed as min(max(x,minval),maxval). When x is NaN, clamp returns 0. When min/max is taken as is, and one of operand of min is NaN. The final result is 1.0 by float point rules of D3D. It happens that some of our SC version does not optimize min/max to clamp(or some other equivalent  operations). That’s expected behavior. To avoid the visual artifacts, originator should consider checking for NaN in the shader.  To reproduce the visual artifact on other vendors, you could

Replace
_TMP78=max(vec3(0.0, 0.0, 0.0), _TMP3);

with
If (_TMP3.x==1.0 && _TMP3.y==1.0 && _TMP3.z==1.0)
  _TMP78=vec3(1.0, 1.0, 1.0);
else
  _TMP78=max(vec3(0.0, 0.0, 0.0), _TMP3);

to disable min/max optimization.

--------

I'll reach out to Turbulenz to see whether it's possible for them to update the shaders in the demo.

Fixed on 10.12.2. I resolved the radar.