[snap] Default ANGLE renderer doesn't work in headless mode

Bug #1959416 reported by Adrianna Pińska
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)
Fix Released
Medium
Olivier Tilloy

Bug Description

I use a headless browser with Selenium to automate access to a WebGL-heavy site. The current Snap package of Chromium (Chromium 97.0.4692.99 snap) running on Ubuntu 20.04.3 LTS cannot use WebGL in headless mode.

I was able to use the same script with the Snap package previously, but unfortunately a lot of time has elapsed since I last tried it, so I'm not sure exactly when this issue first appeared. I believe that the implementation of headless WebGL has changed recently, so perhaps this is related.

I can can easily reproduce this issue in the terminal by attempting to open a WebGL test page in a headless browser. This outputs multiple errors:

$ chromium --headless "https://webglreport.com/?v=2"
[0128/113614.313931:ERROR:angle_platform_impl.cc(44)] Display.cpp:894 (initialize): ANGLE Display::initialize error 0: Internal Vulkan error (-3): Initialization of an objec
t could not be completed for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:1068.
[0128/113614.314052:ERROR:gl_surface_egl.cc(783)] EGL Driver message (Critical) eglInitialize: Internal Vulkan error (-3): Initialization of an object could not be completed
 for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:1068.
[0128/113614.314112:ERROR:gl_surface_egl.cc(1391)] eglInitialize SwANGLE failed with error EGL_NOT_INITIALIZED
[0128/113614.314154:ERROR:gl_ozone_egl.cc(20)] GLSurfaceEGL::InitializeOneOff failed.
[0128/113614.315496:ERROR:viz_main_impl.cc(161)] Exiting GPU process due to errors during initialization
[0128/113614.324786:ERROR:angle_platform_impl.cc(44)] Display.cpp:894 (initialize): ANGLE Display::initialize error 0: Internal Vulkan error (-3): Initialization of an objec
t could not be completed for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:1068.
[0128/113614.324890:ERROR:gl_surface_egl.cc(783)] EGL Driver message (Critical) eglInitialize: Internal Vulkan error (-3): Initialization of an object could not be completed
 for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:1068.
[0128/113614.324929:ERROR:gl_surface_egl.cc(1391)] eglInitialize SwANGLE failed with error EGL_NOT_INITIALIZED
[0128/113614.324978:ERROR:gl_ozone_egl.cc(20)] GLSurfaceEGL::InitializeOneOff failed.
[0128/113614.325972:ERROR:viz_main_impl.cc(161)] Exiting GPU process due to errors during initialization
[0128/113614.333428:ERROR:angle_platform_impl.cc(44)] Display.cpp:894 (initialize): ANGLE Display::initialize error 0: Internal Vulkan error (-3): Initialization of an objec
t could not be completed for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:1068.
[0128/113614.333559:ERROR:gl_surface_egl.cc(783)] EGL Driver message (Critical) eglInitialize: Internal Vulkan error (-3): Initialization of an object could not be completed
 for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:1068.
[0128/113614.333617:ERROR:gl_surface_egl.cc(1391)] eglInitialize SwANGLE failed with error EGL_NOT_INITIALIZED
[0128/113614.333657:ERROR:gl_ozone_egl.cc(20)] GLSurfaceEGL::InitializeOneOff failed.
[0128/113614.334806:ERROR:viz_main_impl.cc(161)] Exiting GPU process due to errors during initialization
[0128/113614.339446:ERROR:gpu_init.cc(457)] Passthrough is not supported, GL is disabled, ANGLE is

When I ran a script to use selenium to save the output of this webpage, it reported that WebGL was disabled. (Using the screenshot option, which I was previously unaware of, should provide the same result.)

I have confirmed that the identical version of Google Chrome (installed from the .deb package on Google's website) works, and so does a slightly older version of Chromium from a .deb package installed from a PPA. The executables from these packages do not produce the errors above, and WebGL works correctly in headless mode.

While searching for these error messages I found various bug reports for similar WebGL-related problems. I noticed that some of the suggested solutions referred to library files which are installed by the working packages but not by the Snap package (for example libvk_swiftshader.so).

Revision history for this message
Olivier Tilloy (osomon) wrote :

I can confirm the problem.

If I run with the "--use-gl=swiftshader-webgl" command-line option, I can get WebGL to work in headless mode (as suggested in https://bugs.chromium.org/p/chromium/issues/detail?id=1209250).

Can you confirm this works around the problem for you too?

Changed in chromium-browser (Ubuntu):
status: New → Incomplete
Revision history for this message
Adrianna Pińska (confluence) wrote :

The snap version of Chromium has now been updated to 98.0.4758.80. In this version, both --use-gl=swiftshader-webgl and --use-gl=swiftshader allow WebGL to work in headless mode.

I definitely tried --use-gl=swiftshader in my tests with the previous snap version (my software had already been setting that flag by default), and it appeared to have no effect.

I've done some additional tests with 97.0 and 98.0 versions of google-chrome and the .deb Chromium packages, and as far as I can tell, in version 97.0 the swiftshader flag is ignored (whether I use it or not, the renderer is reported as ANGLE, but with additional information about a SwiftShader device and driver), but in 98.0 it is being respected again (when I use the flag, the renderer is reported as "Google SwiftShader").

But in addition to this, WebGL doesn't work in headless mode with the default ANGLE renderer in the Chromium snap (but it *does* work in both the Chromium .deb package and in Google Chrome). Is that a bug, or a permanent limitation of the snap (because of some security restriction)?

Revision history for this message
Olivier Tilloy (osomon) wrote :

I can confirm this didn't work in the snap version 97.0.4692.99 (revision 1878) previously in the stable channel, and it is now working with version 98.0.4758.80 currently in the stable channel.

Revision history for this message
Olivier Tilloy (osomon) wrote :

I can also confirm that the default ANGLE renderer does work for Google Chrome packaged as a deb when run in headless mode, whereas it doesn't for the chromium snap.

I'm not sure why that is, but the following log is certainly relevant:

[0204/112747.679225:ERROR:angle_platform_impl.cc(44)] Display.cpp:940 (initialize): ANGLE Display::initialize error 0: Internal Vulkan error (-3): Initialization of an object could not be completed for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:1092.
[0204/112747.679325:ERROR:gl_surface_egl.cc(808)] EGL Driver message (Critical) eglInitialize: Internal Vulkan error (-3): Initialization of an object could not be completed for implementation-specific reasons, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, initialize:1092.
[0204/112747.679364:ERROR:gl_surface_egl.cc(1430)] eglInitialize SwANGLE failed with error EGL_NOT_INITIALIZED
[0204/112747.679402:ERROR:gl_ozone_egl.cc(20)] GLSurfaceEGL::InitializeOneOff failed.
[0204/112747.680198:ERROR:viz_main_impl.cc(188)] Exiting GPU process due to errors during initialization

summary: - WebGL broken in headless mode
+ [snap] Default ANGLE renderer doesn't work in headless mode
Changed in chromium-browser (Ubuntu):
status: Incomplete → Confirmed
importance: Undecided → Medium
tags: added: snap
Revision history for this message
Adrianna Pińska (confluence) wrote :

I can see that in the snapcraft.yaml file for the Chromium snap there is a hardcoded list of library files which are copied during installation. This list excludes several files which are present in both the Google Chrome and the .deb Chromium install directories (e.g. libvulkan.so.1, libvk_swiftshader.so, libVkICD_mock_icd.so, vk_swiftshader_icd.json -- I don't know if they're all related). I can also see copies of these files in various Electron apps that I have installed. Is it possible that this list just needs to be updated?

Revision history for this message
Olivier Tilloy (osomon) wrote :

Very good catch Adrianna. I rebuilt the chromium snap from the stable channel with the missing libvk_swiftshader.so, libvulkan.so.1 and vk_swiftshader_icd.json, and I can confirm that the default ANGLE renderer now works in headless mode.

Fixed with https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/commit/?id=35d0f6379f0d82a40e936b6dee48592add46d204.

Changed in chromium-browser (Ubuntu):
status: Confirmed → Fix Committed
assignee: nobody → Olivier Tilloy (osomon)
Revision history for this message
Adrianna Pińska (confluence) wrote :

That's great; thanks for the fix! I can use the workaround until the next release.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Note that I've kicked off rebuilds of the stable snap with the fix, so it won't be necessary to wait for a new upstream release.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Revision 1899 (for amd64), with the fix, is now in the stable channel.

Changed in chromium-browser (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Adrianna Pińska (confluence) wrote :

I have confirmed that the issue is fixed in the latest revision. Thanks!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.