(Docs) New chromium v108 needs --use-gl=egl

[ScoreUnder]

I need to use --use-gl=egl to get chromium to render through virtualgl.

VGL_LOGO=1 vglrun -d /dev/dri/card0 chromium --use-gl=egl

I see the VGL logo in the bottom-right of all webpages with this config. If I don't use that flag, I get some perplexing output from Chromium on launch:

[2141831:2141831:1224/040031.269333:ERROR:gl_display.cc(508)] EGL Driver message (Error) eglCreateContext: eglCreateContext
[2141831:2141831:1224/040031.269397:ERROR:gl_context_egl.cc(370)] eglCreateContext failed with error EGL_SUCCESS
[2141831:2141831:1224/040031.269428:ERROR:gpu_channel_manager.cc(884)] Failed to create GLES3 context, fallback to GLES2.

(repeated ad nauseam with some other errors interspersed.) This causes chromium's compositor to fall back to software rendering and causes it to refuse to render WebGL despite saying "WebGL: Hardware accelerated but at reduced performance".

For some reason --disable-seccomp-filter-sandbox was not necessary for me.

Arch Linux, Chromium 108.0.5359.124, OpenGL renderer string: AMD Radeon RX 6700 XT (navi22, LLVM 14.0.6, DRM 3.48, 6.0.7-pf4-1.1), running in Xvnc.

[dcommander]

Are you using the 3.1 beta release of VirtualGL? If so, then this is a bug. Since VGL 3.1 emulates EGL/X11, Chromium should now work by default. I will investigate when I get a chance (probably not until after the new year.)

[ScoreUnder]

I am running from git 3979e912 using the virtualgl-git AUR package. Its version is fully reported as 2.4.r681.g3979e912-1 by the package manager which seems a little misleading because it is in fact part of the in-progress 3.1 beta and includes references to such in its changelog.

[dcommander]

Arch has historically biffed the packaging of VirtualGL, so more times than not, bugs reported against their VGL package can't be reproduced with our official builds. I will try to reproduce the issue on an officially supported platform and get back to you.

[dcommander]

VirtualGL 3.0.91 breaks VLC when playing an mp4 file after invoking the desktop environment through vglrun, segmentation fault happens no matter what.

Post as a separate issue, please.

[dcommander]

Sorry for the immense delay. I've been putting out libjpeg-turbo and TurboVNC fires for the past two months. On my machine (CentOS 7) running VirtualGL 3.1 post-beta and Chromium v110.0.5481.77, I can confirm that --use-gl=egl is also necessary, but the error I get when I don't use it is different:

$ VGL_LOGO=1 vglrun -d egl chromium-browser --disable-seccomp-filter-sandbox
[1:1:0223/164306.375546:ERROR:file_path_watcher_inotify.cc(823)] Failed to read /proc/sys/fs/inotify/max_user_watches
[9655:9655:0223/164306.847063:ERROR:gpu_init.cc(523)] Passthrough is not supported, GL is angle, ANGLE is 
[9655:9655:0223/164306.875122:ERROR:gpu_memory_buffer_support_x11.cc(49)] dri3 extension not supported.
[9655:9655:0223/164306.937356:ERROR:gl_surface_egl.cc(482)] eglCreateWindowSurface failed with error EGL_BAD_CONFIG
[9690:26:0223/164306.950423:ERROR:command_buffer_proxy_impl.cc(325)] GPU state invalid after WaitForGetOffsetInRange.

The EGL/X11 feature was specifically developed for Chrome, so apparently Google changed something that broke it. :( I will investigate.

[dcommander]

The issue seems to be that Chromium is choosing a specific X visual for its window, then it is searching through the list of EGLConfigs to find one that matches that visual ID:

https://github.com/chromium/chromium/blob/51d4c63284a91d5519408306821d8fe2b4ff9e07/ui/gl/gl_surface_egl_x11_gles2.cc#L99-L137

Blerg. That is really poor design, and I wish applications would stop doing it. More specifically, it seems to be searching for a visual that matches specific GLX attributes:

https://github.com/chromium/chromium/blob/51d4c63284a91d5519408306821d8fe2b4ff9e07/ui/base/x/visual_picker_glx.cc#L195-L210 https://github.com/chromium/chromium/blob/51d4c63284a91d5519408306821d8fe2b4ff9e07/ui/base/x/visual_picker_glx.cc#L98-L168

With the TurboVNC Viewer, that causes it to choose Visual 0x392, the first double-buffered depth-32 RGBA8 visual with no stencil or depth buffer. However, since VirtualGL doesn't care about GLX attributes when choosing an X visual to match an EGLConfig, it would never choose Visual 0x392 to match any EGLConfig.

Ultimately, anything I did to work around this would be a lot messier than just passing --use-gl=egl to Chromium, which causes it to use desktop OpenGL with EGL rather than GLES with EGL, thus avoiding the issue.

[dcommander]

Oddly, v85 and later also needs --use-gl=egl, but I swear that was not necessary when I was developing the EGL/X11 back end. Something may have changed externally to Chrome/Chromium to make it necessary.

[ehfd]

@m1k1o Relevant to https://github.com/selkies-project/docker-nvidia-egl-desktop/issues/20

[m1k1o]

Thanks for notifying! I'll try.