I can't reproduce this on Canary on my Win10 bot with NVidia Quadro K2200

Can you provide the about:gpu content on the machine where you can reproduce this?

Also, can the shader / WebGL code be further reduced but still capable of reproducing this issue?

See the new attachment for about:gpu on the machine where we can reproduce.

Deleted: ChromeAboutGpu.txt 10.9 KB

ChromeAboutGpu.txt 10.9 KB View Download

I also can't reproduce this in Stable (M65).

I do get a warning from ANGLE though:

[8920:10936:0329/102358.338:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(140,31-70): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them C:\fakepath(145,142-182): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them C:\fakepath(114,17-71): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them C:\fakepath(145,142-182): warning X4119: indefinite logarithm

It's not entirely unexpected that there will be a black flash in case there's a too heavy shader - in this case the GPU timeouts and the graphics driver gets reset. Of course if the shader is still doing something that could be considered reasonable for the given GPU, then the issue may be more worth looking into.

I don't think the pow() warnings are really relevant.

Thanks for the comment on heavy shaders. In this case, Firefox for instance does not suffer from a black flash, and seems to compile and render that shader without too much delay.

As far as I know both Chrome and Firefox use ANGLE, but I guess in different ways. Would it be interesting / possible to get the ANGLE output that is actually pass onto the driver for both Firefox and Chrome, and diff them?

Also: reducing the shader would require an automated and reliable way to detect this black flash, which we unfortunately do not have at hand.

Can you go to chrome://crashes/ and see if there is a recent crash ID that's related to this bug? If not, can you turn on crash reporting and let Chrome catch one and give the ID to us? We want to confirm if it's Chrome's GPU watchdog killing it or not.

Then yes, if Firefox doesn't crash, it would be interesting to figure out why.

Here comes a crash ID for that issue:

Uploaded Crash Report ID 1227d03e8dfe9a6c (Local Crash ID: 86708c71-b1bd-4270-b341-76a015013427)
Crash report captured on Friday, March 30, 2018 at 11:23:19 AM, uploaded on Friday, March 30, 2018 at 11:26:09 AM

Hope that helps!

Thank you!

CRASHED [EXCEPTION_STACK_OVERFLOW @ 0x00007ffa3d190534 ] MAGIC SIGNATURE THREAD

The stack is just 500 lines of nvwgf2umx_cfg.dll

Looking together with kbr, it seems this is a recursion that went too deep on this GPU.

It would be interesting to know the difference in the HSLS that Chrome feeds to the driver from the one Firefox feeds to the driver.

Interesting indeed. Is there an easy way to capture that HLSL for both Chrome and Firefox?

You can use WebGL_debug_shaders extension (https://www.khronos.org/registry/webgl/extensions/WEBGL_debug_shaders/) to catch the shaders sent to the driver. Chrome implements and exposes it by default I think. Not sure about Firefox though. 

In Firefox, you can enable (in about:config) the following pref: webgl.enable-privileged-extensions
to expose WEBGL_debug_shaders.

Thanks for pointing to the WebGL_debug_shader extension, I've added the fragment shader translated sources for both browsers as attachment. Chrome reports a GLSL and HLSL part, but unfortunately Firefox only reports GLSL, despite using ANGLE (I double-checked that it is the case).

The GLSL looks similar for both browser, except the randomized variable names. The diff after renaming all variable to webgl_VAR is:

--- renamedChrome.txt   2018-04-03 09:57:59.243541200 +0100
+++ renamedFirefox.txt  2018-04-03 09:58:03.943825700 +0100
@@ -7,2 +7,3 @@
 highp vec3 webgl_VAR = vec3(0.6435011, 0.79539883, 2.0943952);
+highp float webgl_VAR = 0.0;
 highp vec2 webgl_VAR;
@@ -75,2 +76,3 @@
 highp vec2 webgl_VAR(in highp vec3 webgl_VAR, in highp vec3 webgl_VAR){
+highp float webgl_VAR = 0.0;
 highp float webgl_VAR = 49.5;
@@ -113,2 +115,3 @@
 highp vec3 webgl_VAR = atan(webgl_VAR, webgl_VAR);
+highp vec3 webgl_VAR = (webgl_VAR / webgl_VAR);
 highp vec3 webgl_VAR = sin((min((webgl_VAR.x * webgl_VAR), 1.3) * webgl_VAR));

So Firefox has three more lines. Checking the code before variable renaming, the two variables that are initialised to 0.0 (namely webgl_2fb1bd2bbb577a35 on line 8 and webgl_fd2c24ada20499ef on line 77) are actually never used, as they are shadowed by local variables with the same name. In the original shader (temp_5649.frag, also added as attachment to refer to lines), webgl_2fb1bd2bbb577a35 seem to reflect the 'gTime' at line 23 and webgl_fd2c24ada20499ef the 'float h' at line 153, which are indeed both shadowed.

The third variable (webgl_1f35271981942898, line 116) actually never appears anywhere else. In the original shader, it seem to correspond to the 'cv' variable, only present in lines 201-202:

 vec3 cv = cu / cw;
 vec3 ray = sin(min((true ? uv.x * cu : step(uv.y, cv)), 1.3) * cw);

Note that the ternary operator condition being true, I guess both browsers remove the else branch which is the only usage of 'cv'. Hence It looks like the few differences at the GLSL level seem to be due to some leftovers in Firefox which have been optimised away in Chrome.


I also tried Chrome with --use-gl:desktop and it does succeed to render the shader, so the issue seem to be in ANGLE. With this flag, the translated shader GLSL is identical to the GLSL part of the translated shader when using ANGLE.

I can see two possible next steps:

 - Do you know if there is a way to access the HLSL in Firefox?

 - Is there a way to programmatically obtain the crash report, and thus to grep the "EXCEPTION_STACK_OVERFLOW" on the GPU? That would open the possibility to use our reducer on the shader. Best would be to access this report from the webpage (via JS), but accessing it from outside the browser would also be workable.

Deleted: temp_5649.frag 5.9 KB

temp_5649.frag 5.9 KB Download

Deleted: ChromeFragmentTranslated.txt 20.9 KB

ChromeFragmentTranslated.txt 20.9 KB View Download

Deleted: FirefoxFragmentTranslated.txt 9.6 KB

FirefoxFragmentTranslated.txt 9.6 KB View Download

I think that getting the HLSL from Firefox is the key. I doubt that the GLSL differences between Chrome and Firefox are significant.

Unable to reproduce the issue on Win-10 using chrome reported version #65.0.3325.181 and latest canary #67.0.3386.1.

Following are the steps followed to reproduce the issue.
1. Opened the attached bug.HTML file in Chrome on a Windows 10 with a Nvidia GPU. 
2. Observed that the web page looped on rendering the WebGL shader, without issues as expected.

Forwarding the issue to inhouse team as per comment #8 for further triaging of the issue.

Thanks...!!

Add d3d11 trace of Firefox starting + rendering the shader, captured with apitrace. We can see a few shaders, but I don't know enough about D3D and Firefox to be sure one of them corresponds to the webgl shader (grep'ing for angle/webgl does not match anything). I hope that helps.

Deleted: firefox_apitrace.txt 7.1 MB

firefox_apitrace.txt 7.1 MB View Download

Using nVidia 750 Ti and test html from #0 in Windows 7:

* Chrome 32-bit has no problems!
  (all versions since WebGL2 was enabled via r429885) 

* Chrome 64-bit (all versions since r429885, including Canary) shows only the first 2-5 fragments, 
  flashes the entire window with what seems a black fill for an instant, 
  then spits out errors continuously: 
  TypeError: Failed to execute 'shaderSource' on 'WebGL2RenderingContext': parameter 1 is not of type 'WebGLShader'.

  GPU log (attached) contains an ANGLE warning from #c4 and then:
  GpuProcessHostUIShim: The GPU process crashed!
  [14588:13276:0403/172722.628:ERROR:gl_utils.cc(297)] : [.DisplayCompositor-000000000F73C060] GL_INVALID_OPERATION: Texture was not generated

Deleted: gpu.txt 12.4 KB

gpu.txt 12.4 KB View Download

Geoff, assigning this to you since it looks like a shader translator issue.

Does Firefox use ANGLE too? If so, can we replace the libglesv2.dll with a debug build of ANGLE, and see the generated HLSL shader?

I'll be able to take a look next week (traveling this week).