WebGL not working with 3.0.90-20230201 #228
Comments
Some applications, including Firefox, support both EGL/X11 and GLX, so VGL shouldn't throw a fatal error if those applications call eglGet*Display() to probe for EGL/X11 support. I suspect that this fixes the Firefox complaint in #228. NOTE: From a usability point of view, it would seemingly be nicer to automatically use an EGL device with the EGL/X11 interposer, but that would require introducing a separate environment variable/command-line option so that an EGL device could be specified for the EGL/X11 interposer without forcing the EGL back end to be used with the GLX interposer. At the moment, it makes more sense to tie the EGL/X11 interposer to the EGL back end, since the GLX back end is primarily a backward compatibility feature.
|
The primary purpose of the VirtualGL 3.1 release series is to introduce an EGL/X11 interposer to support Chrome and Firefox and other applications (VLC, etc.) that have migrated from GLX to EGL/X11. Chrome supports (supported?) another OpenGL path using low-level XCB-GLX functions, but VirtualGL's XCB interposer is not sophisticated enough to support that path. (Our XCB interposer does only the minimum necessary to support Qt, so it isn't a complete XCB-GLX interposer.) It was easier to just interpose EGL/X11 rather than try to interpose all of XCB-GLX. Thus, you may have been able to use VirtualGL 3.0.2 with Chrome, but I seriously doubt that it was GPU-accelerated. There was an issue in VirtualGL 3.1 beta1 whereby the interposed General notes
FirefoxDefinition of "Success" with Firefox
Definition of "Failure" with Firefox
Observed behaviorVirtualGL 3.0.2 and 3.0.91, Firefox v80-v106 (did not test versions prior to v80)
VirtualGL 3.0.2, Firefox v107-v110
VirtualGL 3.0.91, Firefox v107-v110
Conclusions
Chrome/Chromium v110-v111NOTE: Prior to releasing VirtualGL v3.1 beta1, I did a similar study to the above with Chrome, so I am confident that the existing Chrome/Chromium app recipe in the VGL User's Guide is correct. This section simply reiterates those findings vis-a-vis the latest version. Definition of "Success" with Chrome/Chromium
Definition of "Failure" with Chrome/Chromium
Observed behaviorVirtualGL 3.0.2
VirtualGL 3.0.91
Conclusions
|
|
tl;dr When using the latest VGL 3.1 post-beta pre-release build, Firefox should now work as it did with VGL 3.0.2. I strongly suspect that Chrome/Chromium didn't work because you weren't following the application recipe, but please let me know if you still observe a failure after following that recipe. |
- Clarify why Chrome/Chromium needs --use-gl=egl. (Expand upon 03b3d16.) - Update the Firefox app recipe based on 7a2d5c7 and new findings: #228 (comment)
... based on new findings: #228 (comment)
|
I have been investigating the update issue observed with Firefox v89-v106. It is definitely VirtualGL-specific, as I can reproduce the issue on the local display with VirtualGL but not without VirtualGL. I have tried setting |
|
@langeschro Please test the latest VirtualGL 3.1 post-beta pre-release (https://virtualgl.org/DeveloperInfo/PreReleases) using the documented recipes for Firefox and Chrome (a recipe is only needed with Firefox < v94) and confirm whether the issues are fixed. |
|
@langeschro A timely response is appreciated. The VirtualGL 3.1 release is overdue, and I need independent confirmation that this issue is fixed. |
|
Hi @dcommander thanks for your response, this is extremely helpful. |
|
Tried the 3.0.91 version now that was uploaded yesterday. Firefox (102.8.0esr 64bit): Chrome (110.0.5481.100 64bit): It seems like EGL is not working at all currently for us, so we did a fallback to GLX for Firefox in the past already I assume. VGL_LOGO=1 vglrun +tr -d egl google-chrome --use-gl=egl --disable-seccomp-filter-sandbox |
|
Ah, OK. It appears that your 2D X server doesn't have a GLX extension, which is why the EGL back end isn't working. When the EGL back end is emulating GLX, it needs to "borrow" the 2D X server's GLX extension in order to report GLX errors properly (since there is no 3D X server GLX extension for it to use.) However, EGL/X11 doesn't need to report GLX errors, so I'll see if I can make that a non-fatal error, which should allow Chrome to work in your environment. I should be able to reproduce your environment by disabling the GLX extension in TurboVNC. |
Some applications, including Chrome/Chromium, support both EGL/X11 and GLX, so the EGL back end shouldn't throw a fatal error if those applications call XQueryExtension(..., "GLX", ...) or glXQueryExtension() and the 2D X server doesn't have a GLX extension. Instead, the EGL back end now throws a fatal error only if it actually needs to use the 2D X server's GLX extension to handle a GLX error. Fixes one of the complaints in #228
|
@langeschro The latest pre-release build should now allow Chrome/Chromium to work properly even if the 2D X server doesn't have a GLX extension. The EGL back end needs the 2D X server's GLX extension in order to properly implement GLX error handling, so |
|
Hi @dcommander I've tested the latest build and seem to be getting the same error message as before. Command line: [VGL 0xcb9bcf80] XOpenDisplay (name=NULL dpy=0x3edc0026e800(:1) ) 0.508070 ms Also tried without "--e-gl=egl" but I am receiving the same error message. |
|
There is no way that the latest build can generate that error message in the body of |
|
Hi @dcommander no idea what went wrong there, I definitely had the correct package installed, maybe some weird caching that was going on. Partial success Graphics Feature Status The "disable-seccomp-filter-sandbox" option does not seem to be required for me either. Please let me know if this is the result you would expect and if I should provide any further information. Thanks a lot for your quick help, highly appreciated. |
|
It should be |
|
Oh, that's really embarrassing, there must have gone something wrong in my notepad when copy/pasting. Retried now using "VGL_LOGO=1 vglrun +tr -d egl google-chrome --use-gl=egl --disable-seccomp-filter-sandbox" Partial success For some reason Multiple Raster Threads is "disabled" in my case, you mentioned that this should be enabled for a "success". Canvas: Hardware accelerated Also "--disable-seccomp-filter-sandbox" is now required when using "--use-gl=egl" |
|
OK, great. I'm not sure why, but sometimes Chrome disables multiple raster threads with certain GPUs. I don't observe that with my Quadro P620, 525.xx, and Rocky Linux 8.7, but maybe it is specific to the T4. Chrome might do the same thing when you run it on the local display without VirtualGL, but I wouldn't worry about it either way. |
Since the beginning, VirtualGL has cleared new "virtual window" Pbuffers (Pbuffers that it creates to emulate OpenGL windows) when the Pbuffers are made current for the first time. Unlike new X windows, the contents of new Pbuffers are undefined, and "back in the day", some OpenGL implementations did not clear new Pbuffers. Applications were particularly economical with their 3D rendering back then, and some of them relied on the fact that new X windows start out blank. Thus, VirtualGL had to clear new virtual window Pbuffers, particularly ones that it created in midstream (in response to a window resize that occurred between glXSwapBuffers() or glXMakeCurrent() calls.) Since the Pbuffer clearing code was introduced before VirtualGL was open sourced, information about the specific OpenGL implementations and 3D applications that necessitated it has been lost to history. Clearing new virtual window Pbuffers is likely never necessary in 2024, and it definitely isn't necessary unless the default framebuffer is bound to the GL_DRAW_FRAMEBUFFER target. (FBOs weren't a thing "back in the day.") VirtualGL handles midstream window resizes in the body of glViewport(), but because FBOs and their bindings are attached to a specific context rather than a specific drawable, the first glViewport() call that a 3D application makes after its window is resized might be made while an FBO is bound to the GL_DRAW_FRAMEBUFFER target. That is the case with Firefox, so VirtualGL's attempt to clear the new virtual window Pbuffer that it created in the body of glViewport() cleared part of an FBO instead, resulting in the disappearance of random characters or other elements of the Firefox window. Modern OpenGL implementations seem to clear new Pbuffers, at least in my limited testing, so we could probably get away with jettisoning the Pbuffer clearing code altogether. However, the minimally invasive fix is simply to forego clearing a new virtual window Pbuffer if an FBO is bound to the GL_DRAW_FRAMEBUFFER target. Note that this appears to have been the "update issue" that I observed in certain versions of Firefox and documented in #228 (comment) In fact, the issue was always reproducible with either back end. I didn't always observe it because it didn't always occur unless you resized the Firefox window repeatedly, and it was more likely to occur with the GLX back end than with the EGL back end.
Since the beginning, VirtualGL has cleared new "virtual window" Pbuffers (Pbuffers that it creates to emulate OpenGL windows) when the Pbuffers are made current for the first time. Unlike new X windows, the contents of new Pbuffers are undefined, and "back in the day", some OpenGL implementations did not clear new Pbuffers. Applications were particularly economical with their 3D rendering back then, and some of them relied on the fact that new X windows start out blank. Thus, VirtualGL had to clear new virtual window Pbuffers, particularly ones that it created in midstream (in response to a window resize that occurred between glXSwapBuffers() or glXMakeCurrent() calls.) Since the Pbuffer clearing code was introduced before VirtualGL was open sourced, information about the specific OpenGL implementations and 3D applications that necessitated it has been lost to history. Clearing new virtual window Pbuffers is likely never necessary in 2024, and it definitely isn't necessary unless the default framebuffer is bound to the GL_DRAW_FRAMEBUFFER target. (FBOs weren't a thing "back in the day.") VirtualGL handles midstream window resizes in the body of glViewport(), but because FBOs and their bindings are attached to a specific context rather than a specific drawable, the first glViewport() call that a 3D application makes after its window is resized might be made while an FBO is bound to the GL_DRAW_FRAMEBUFFER target. That is the case with Firefox, so VirtualGL's attempt to clear the new virtual window Pbuffer that it created in the body of glViewport() cleared part of an FBO instead, resulting in the disappearance of random characters or other elements of the Firefox window. Modern OpenGL implementations seem to clear new Pbuffers, at least in my limited testing, so we could probably get away with jettisoning the Pbuffer clearing code altogether. However, the minimally invasive fix is simply to forego clearing a new virtual window Pbuffer if an FBO is bound to the GL_DRAW_FRAMEBUFFER target. Note that this appears to have been the "update issue" that I observed in certain versions of Firefox and documented in #228 (comment) In fact, the issue was always reproducible with either back end. I didn't always observe it because it didn't always occur unless you resized the Firefox window repeatedly, and it was more likely to occur with the GLX back end than with the EGL back end.
Since the beginning, VirtualGL has cleared new "virtual window" Pbuffers (Pbuffers that it creates to emulate OpenGL windows) when the Pbuffers are made current for the first time. Unlike new X windows, the contents of new Pbuffers are undefined, and "back in the day", some OpenGL implementations did not clear new Pbuffers. Applications were particularly economical with their 3D rendering back then, and some of them relied on the fact that new X windows start out blank. Thus, VirtualGL had to clear new virtual window Pbuffers, particularly ones that it created in midstream (in response to a window resize that occurred between glXSwapBuffers() or glXMakeCurrent() calls.) Since the Pbuffer clearing code was introduced before VirtualGL was open sourced, information about the specific OpenGL implementations and 3D applications that necessitated it has been lost to history. Clearing new virtual window Pbuffers is likely never necessary in 2024, and it definitely isn't necessary unless the default framebuffer is bound to the GL_DRAW_FRAMEBUFFER target. (FBOs weren't a thing "back in the day.") VirtualGL handles midstream window resizes in the body of glViewport(), but because FBOs and their bindings are attached to a specific context rather than a specific drawable, the first glViewport() call that a 3D application makes after its window is resized might be made while an FBO is bound to the GL_DRAW_FRAMEBUFFER target. That is the case with Firefox, so VirtualGL's attempt to clear the new virtual window Pbuffer that it created in the body of glViewport() cleared part of an FBO instead, resulting in the disappearance of random characters or other elements of the Firefox window. Modern OpenGL implementations seem to clear new Pbuffers, at least in my limited testing, so we could probably get away with jettisoning the Pbuffer clearing code altogether. However, the minimally invasive fix is simply to forego clearing a new virtual window Pbuffer if an FBO is bound to the GL_DRAW_FRAMEBUFFER target. Note that this appears to have been the "update issue" that I observed in certain versions of Firefox and documented in #228 (comment) In fact, the issue was always reproducible with either back end. I didn't always observe it because it didn't always occur unless you resized the Firefox window repeatedly, and it was more likely to occur with the GLX back end than with the EGL back end.
WebGL is not working with Chrome and Firefox after updating to 3.0.90-20230201.
This works again after changing the version to 3.0.2-20230201
OS is Rocky Linux 8 and I've been using an Nvidia T4 GPU with driver version 525.60.13
A simple test is to visit https://get.webgl.org/
There should be a spinning cube if WebGL is working.
The text was updated successfully, but these errors were encountered: