iquilezles: can you a) try in the latest Chrome Canary and b) attach about:gpu from either Canary or Stable?

I just tried this locally in Canary and it worked, about:gpu attached.

Deleted: gpu.html 170 KB

gpu.html 170 KB View Download

Sure. 

* Still crashes in v54 (Canary)
* v52 works good at home (laptop Win10 64bit, GeForce 980M GTX)
* I attached the about://gpu as html, taken for the crashing machine.

Deleted: gpu.html 152 KB

gpu.html 152 KB View Download

Something is happening here:

[12952:13856:0721/124333:ERROR:angle_platform_impl.cc(33)] : ANGLE Display::initialize error 4: Could not create D3D11 device.

I think we might have to add some additional logging to figure out what's going on.

Jamie, may I assign this to you to carry out the investigation? If more logging is needed in ANGLE to better diagnose cases like this, let's add it. They've happened on other kinds of GPUs, too, from recollection.

Yep will look at this soon.

AlteredQualia reported on Twitter in https://twitter.com/alteredq/status/756534658507112448 that WebGL is working in Chrome 52 on his old AMD GPU but not in Chrome 54 (Canary). Perhaps more logging during EGL surface and context creation would help diagnose that situation too.

AlteredQualia here: for what it's worth, that ShaderToy castle thingie does work ok on my old ATI Mobility Radeon 3650 in Chrome 52.

While investigating this seems I've found a cause of problems on my old AMD GPU - WebGL works fine on 64-bit versions of Chrome (both stable 52 and canary 54), while everything GPU-accelerated (including WebGL) completely crashes on 32-bit version of Chrome (my Canary 54 was 32-bit). 

Hence Chrome 52 vs Canary 54 was just a red herring for me.

This is how my errors looked there:

https://gist.githubusercontent.com/anonymous/7f0c4acdb3936581f67c5a992a0fcec8/raw/fb7c1f32bc7aa8259205b6fa85c1afc8607f0a67/gistfile1.txt

Seems like a different thing than Inigo gets on his GTX 980.

------

Though if you are looking for shader compiler crashes, I can contribute there too :)

If you run this demo with ANGLE GL backend (tried on different GPUs: Quadro 2000M, GTX 970M):

http://alteredqualia.com/xg/examples/animation_physics_terrain.html

It crashes with JS console errors about shader compilation failures and this error message in about:gpu:

> GpuProcessHostUIShim: The GPU process crashed!

ANGLE DX11 backend is fine. The same crashing for WebGL2 version:

http://alteredqualia.com/xg/examples/animation_physics_terrain_webgl2.html

Canary 54 behaves the same.

Any progress on this? I can no longer do Shadertoy at work, although that might be a good thing. In my laptop at home it all works fine though. Let me know if I can help in some way

Our team is back from SIGGRAPH now, will have time to look at this this week. Thanks postfilter for the details in comment 7.

If Inigo can't hack Shadertoy at work that's a P0 :)

Thanks Jamie and the ANGLE team for investigating.

So it actually got much worse for me with the newest Canary 54.0.2815.0 (could have happened earlier, this is just when I noticed).

Almost all of my newer demos now fail to compile at least some shaders. For example here:

http://alteredqualia.com/xg/examples/car_zastava.html
http://alteredqualia.com/xg/examples/deferred_skin.html
http://alteredqualia.com/xg/examples/earth_bathymetry.html
http://www.fractalfantasy.net/#/4/uncanny_valley

This happens with D3D11 ANGLE for both WebGL1 and WebGL2. OpenGL ANGLE seems fine.

Platform is Windows 7 64-bit, Nvidia Quadro 2000M / Windows 8.1 64-bit GTX 970M.

postfilter, this new problem in comment #11 is a separate bug in a workaround I added. Thanks for reporting this, I'll follow up in  issue angleproject:851 .

iquilezles@hotmail.com, will try to repro now. Can you try starting chrome with --disable-gpu-sandbox and seeing if that fixes the problem? Also did you install Nsight or another GPU debugging software on your PC recently?

I can confirm that using a Windows 10 machine with a GTX 980 and Nsight installed produced the same device initialization error as in the issue description. You can work around the sandboxing issue by using --disable-gpu-sandbox or by uninstalling Nsight.

Thanks Jamie for tracking down the root cause.

Is it a well known issue that NVIDIA's Nsight is incompatible with Chrome's GPU sandbox? Do you know how to track down which resources it's failing to open, and would it be possible to whitelist them in https://cs.chromium.org/chromium/src/content/common/sandbox_win.cc ?

It is a known issue with Nsight. We could figure out the DLL names, but I'm not sure on the whitelisting. The DLL list in that file seems to be a 'troublesome DLLs' list that cause crashes in the renderer, rather than GPU process whitelist. If you can help figure out where to stick the DLL names I'd certainly be able to find them.

I'm a little surprised that the code which warms up the graphics subsystem in GLSurfaceEGL::InitializeOneOff ( https://cs.chromium.org/chromium/src/ui/gl/gl_surface_egl.cc?q=InitializeOneOff&sq=package:chromium&l=465&dr=CSs ) doesn't already automatically handle the case of loading the Nsight DLLs; this code is called before the sandbox is enabled.

If the issue is simply that a couple of DLLs need to be pre-loaded before the sandbox is enabled, then maybe that could be added to InitializeStaticEGLInternal in https://cs.chromium.org/chromium/src/ui/gl/init/gl_initializer_win.cc .

If access to more named pipes, etc., is needed, then that could be added to AddGenericPolicy in sandbox_win.cc.

Let me know what you find is necessary. We can find reviewers for any of these changes.