Latest Google Chrome 112 not working with EGL #229
Comments
|
Are you using the Chrome application recipe listed in the VirtualGL User's Guide? |
|
Yes, using
Is there something more that I might be missing? |
|
I can reproduce the failure, but I have no clue why it is occurring. The proximal cause is that Chromium appears to pass but hardware acceleration is still not enabled in Chrome. I spent many hours of uncompensated labor prior to VGL 3.1 figuring out how to accommodate Chrome's quirks with VirtualGL, and it's really disheartening that Google immediately invalidated all of my work. Really wish they would play more nicely with the open source community and stop expecting me to spend my free time cleaning up their messes here and in my other open source projects. (I say this in the context of also having spent about two days of uncompensated labor this week fixing a bug in libjpeg-turbo that was introduced by a feature Google submitted many years ago in support of Android, a feature that has already required me to spend many hours of uncompensated labor on probably half a dozen occasions over the years.) I'm done with this mess. If someone wants to pay for my time to track down all of this Chrome BS and file appropriate bug reports, then fine. Otherwise, it's not my job. |
|
Hi, I looked into the git diff between 111 and 112 and I want to point out a change, that could be the root of this. One if the checks, if passthrough is available is a check for the robust initialization. https://chromium.googlesource.com/chromium/src/+/refs/tags/112.0.5615.134/ui/gl/gl_utils.cc#110 It seems that this is the new intended behavior, since the ANGLE support is widespread enough for googles intentions. It would be interessting to see if disabling the "true" on default would bring back the old behavior or if even more things have to be changed. Would virtualising ANGLE in a similar fashion as it has been done with egl be possible? |
|
ANGLE is supposed to basically translate OpenGL ES calls on the front end to various types of back-end calls, including desktop OpenGL, Direct X, and Vulkan. Thus, I'm not sure if there is an actual ANGLE API to interpose or if it would make sense to do so rather than to interpose the lower-level API, as VirtualGL already does. However, as previously mentioned, Chrome's OpenGL ES interface (which I presume is related to ANGLE somehow) does something really stupid vis-a-vis unnecessarily enforcing a 1:1 relationship between EGLConfigs and X visuals. That's why you have to pass Regardless, unless someone wants to do most of the legwork to figure out how to solve the problem, or unless someone wants to pay me to do that legwork, the chances of it happening any time soon are slim. I've spent a great deal of unpaid hours on this problem already, and Google just instantly invalidated all of that work. If they aren't going to at least try to play nice, then I see no compelling reason to spend my free time supporting their application. |
|
I verified also that VirtualGL 3.1 + google chrome version 113 + TurboVNC does not work ok. I can see that the gpu is used (verified with intel_gpu_top utility from gpu manufacturer) when I run: So I think I have the basic VNC+VirtualGL+GPU card setup ok. I will revert google chrome to v 111, enable vglrun +tr, and try again. I saw some comments on some other post that was experimenting with an vglrun angle option? Setup: Error details: |
|
Reverting to Google Chrome v 111 works a little better. I am now able to use chrome with a 3d game (us.forgeofempires.com), where previously game would not load. When game is in browser, it makes chrome/gameplay super laggy and slow. I will look into it a bit more. It is encouraging to see though that the CPU is hardly used to run the game, when previously the game was taking 95% of cpu to run! I suggest at a minimum can the VirtualGL application recipe for google chrome have a note attached? Something simple like 'use version 111 of chrome if having problems with EGL mode' Details: Command output: my chrome v111 chrome://gpu output: |
I think the issue is: VirtualGL/virtualgl#229
I think the issue is: VirtualGL/virtualgl#229
|
I have been trying, without success, to diagnose this issue. I have gone so far as to build ANGLE from source, in an attempt to reproduce the issue at that level, but the issue does not reproduce. As near as I can figure:
I don't know what else to try at this point. |
|
https://developer.chrome.com/blog/supercharge-web-ai-testing?hl=en#enable-webgpu Possible workaround methods (known as ANGLE through Vulkan). |
|
@ehfd That may work with nVidia's Vulkan drivers, which do something VirtualGL-like if they detect an X proxy, but it won't work with multiple GPUs or other GPU drivers. So this still needs to be fixed somehow for the general case. |
True. But at least there's something. |
|
There are multiple issues at work here:
tl;dr: If I can't find a way to make |
|
If I am attaching the hacks that I made to VirtualGL in order to make it work with Chrome/ANGLE When I use the aforementioned hacks, I can make work with VirtualGL's GLX back end (but not with VirtualGL's EGL back end, perhaps because ANGLE needs some GLX extensions that the EGL back end doesn't currently emulate.) When I use the aforementioned hacks, I can make work with VirtualGL's EGL/X11 front end and EGL back end, but the WebGL performance is awful, and WebGL sometimes freezes the browser. I feel like I've done more than due diligence on this issue and am prepared to say that this it is something that needs to be resolved in Chrome. |
dcommander
added
SEP (somebody else's problem)
and removed
bug
help wanted
funding needed
labels
Referring to #229, passing --use-gl=egl to Chrome v112+ causes the GPU process to crash, even when Chrome is run on a local display without VirtualGL. At the moment, there is no clean way to use Chrome/ANGLE with VirtualGL, because when using ANGLE, Chrome obtains visuals using raw GLX requests/replies (so there is nothing for VirtualGL to interpose.) Through some really messy modifications, VirtualGL can be made to work with Chrome/ANGLE, but the performance is awful. From VirtualGL's point of view, these are pathological behaviors that the Chrome developers need to resolve, much as the GTK developers resolved them. Until then, we cannot claim that Chrome works with VGL.
|
Further notes:
Conclusion: Google needs to
I can work around (2) but not (1). |
|
Apparently |
Chrome/ANGLE attempts to reproduce the visual matching algorithm from GTK v3.15.2 through 4.3.1 (refer to 398e941), but it does so by sending raw GLX requests to and receiving raw GLX replies from the X server. Thus, there is nothing for VirtualGL to interpose, and Chrome picks "system" and "RGBA" visuals based solely on OpenGL rendering attributes assigned to the 2D X server visuals by the 2D X server's GLX implementation, not on OpenGL rendering attributes assigned to the visuals by VirtualGL. As a result, the RGBA visual that Chrome picks is not associated with any EGLConfig that VirtualGL returns. To work around this, two hacks can now be enabled by setting an undocumented environment variable (VGL_CHROMEHACK) to 1: - glxvisual::buildVisAttribTable() scores the 2D X server visuals in the same way that Chrome does, preferring an alpha-enabled visual without a depth buffer, a stencil buffer, or multisampling. - The EGL/X11 interposer chooses the highest-scoring visual and assigns its visual ID to the value of the EGL_NATIVE_VISUAL_ID attribute for any EGLConfigs that have an 8-bit alpha channel. VGL_CHROMEHACK automatically enables VGL_PROBEGLX. This should allow VirtualGL to work with Chrome v112+ if Chrome is passed '--disable-seccomp-filter-sandbox --use-angle=gl-egl'. Refer to #229
|
I went ahead and committed the aforementioned hacks, so you should now be able to run I still observe poor performance or rendering pipeline stalls intermittently on certain configurations, particular with nVidia GPUs, so I am not documenting this as a solution yet. Those performance issues also occur on the local display without VirtualGL. |
|
Thank you for your work on profiling everything. I hope Chromium fixes ANGLE to make it more friendly to VirtualGL. |
|
I've just installed VirtualGL and am messing around with it. In my x2go session with virtualgl 3.1-20230315, chromium v120 and Intel UHD 620 rev 07 I am currently running with Notes:
|
|
Refer to comment above. You need the latest pre-release build of VirtualGL in order to use |
|
Yes good point, I should've stipulated that as I'm not running post commit 5a91ca0 the angle failure was expected. i haven't specifically found much doco on This is a fairly decent cli reference however https://peter.sh/experiments/chromium-command-line-switches/#in-process-gpu |
|
That's probably a nicer solution than |
|
I can confirm that |
|
It seems that Chrome 126 with VirtualGL: about-gpu.txt Direct X11 GLX and EGL: about-gpu.txt |
|
I literally said exactly that in the comment above, and the Chrome application recipe now indicates as such. |
|
Seems like it doesn't even need |
|
It does in the general case. Not specifying |
|
Correction: I'm refreshing my memory as I type. If you don't specify I spent a great deal of time dissecting this issue. Please do not attempt to override my conclusions unless you have spent the same amount of time. |
This clears a lot of things up that I was puzzled of, and is probably what I needed to be aware of. Thank you. |
Hi,
google chrome
111.0.5563.146works withVirtualGL 3.1. In the same environment, when upgraded to112.0.5615.49it does not work anymore.Here is dockerfile with full environment, and here installation of google chrome.
This is log error. Usually
open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2)are not fatal and were displayed even for earlier versions.Related issue: m1k1o/neko#279
The text was updated successfully, but these errors were encountered: