Google Chrome: Failed to get GLXConfig
Marcello Blancasio
[6981:6981:0128/172712.708168:ERROR:gl_surface_glx.cc(475)] CreateDummyWindow(gfx::GetXDisplay()) failed
[6981:6981:0128/172712.708199:ERROR:gl_initializer_x11.cc(148)] GLSurfaceGLX::InitializeOneOff failed.
[6981:6981:0128/172712.712314:ERROR:viz_main_impl.cc(180)] Exiting GPU process due to errors during initialization
[7007:12:0128/172712.894210:ERROR:command_buffer_proxy_impl.cc(124)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
DRC
CentOS 8 with VMWare Tools. Can you provide more details regarding your
system?
DRC
Marcello Blancasio
CentOS Linux release 7.7.1908 (Core)
# rpm -qa VirtualGL
VirtualGL-2.6.3-20191024.x86_64
# rpm -qa \*chrome\*
google-chrome-stable-79.0.3945.130-1.x86_64
# rpm -qa \*mesa\*
mesa-libEGL-devel-18.3.4-5.el7.x86_64
mesa-private-llvm-3.9.1-3.el7.x86_64
mesa-libgbm-18.3.4-5.el7.x86_64
mesa-dri-drivers-18.3.4-5.el7.x86_64
mesa-libGLU-9.0.0-4.el7.x86_64
mesa-libxatracker-18.3.4-5.el7.x86_64
mesa-libGLES-devel-18.3.4-5.el7.x86_64
mesa-filesystem-18.3.4-5.el7.x86_64
mesa-libGL-18.3.4-5.el7.x86_64
mesa-debuginfo-18.3.4-5.el7.x86_64
mesa-libEGL-18.3.4-5.el7.x86_64
mesa-libGLES-18.3.4-5.el7.x86_64
mesa-khr-devel-18.3.4-5.el7.x86_64
mesa-libglapi-18.3.4-5.el7.x86_64
mesa-libGLU-debuginfo-9.0.0-4.el7.x86_64
mesa-libGL-devel-18.3.4-5.el7.x86_64
# rpm -qa \*nvidia\*
yum-plugin-nvidia-1.0.2-1.el7.elrepo.noarch
nvidia-x11-drv-libs-430.50-1.el7_7.elrepo.x86_64
kmod-nvidia-430.50-1.el7_7.elrepo.x86_64
nvidia-detect-430.40-1.el7.elrepo.x86_64
nvidia-x11-drv-430.50-1.el7_7.elrepo.x86_64
I get different errors for NoMachine and TruboVNC.
TurboVNC:
[VGL] ERROR: in VirtualWin--
[VGL] 75: Could not clone X display connection
[VGL] ERROR: in VirtualWin--
[VGL] 75: Could not clone X display connection
[13551:13:0214/185928.926089:ERROR:command_buffer_proxy_impl.cc(124)]
GpuChannelMsg_CreateCommandBuffer.
[VGL] 75: Could not clone X display connection
[13551:13:0214/185929.197750:ERROR:command_buffer_proxy_impl.cc(124)]
GpuChannelMsg_CreateCommandBuffer.
[11871:11871:0214/185332.795246:ERROR:gl_surface_glx.cc(129)] Failed to
get GLXConfig
[11871:11871:0214/185332.795435:ERROR:gl_surface_glx.cc(475)]
CreateDummyWindow(gfx::GetXDisplay()) failed
[11871:11871:0214/185332.795463:ERROR:gl_initializer_x11.cc(148)]
GLSurfaceGLX::InitializeOneOff failed.
[11871:11871:0214/185332.816002:ERROR:viz_main_impl.cc(180)] Exiting GPU
DRC
source of the problem.
Marcello Blancasio
--
You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to virtualgl-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/d09b6db3-d97a-17fa-d46d-6761fcc038d9%40virtualgl.org.
DRC
The other possible value is no value at all. VirtualGL
doesn't use libGLX, so you shouldn't set that environment
variable.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/CAOoseGkfVR50AByhzrqy8TMohkiQM2hSjjAygSJEEOAUQQQ%2Bpg%40mail.gmail.com.
Marcello Blancasio
To unsubscribe from this group and stop receiving emails from it, send an email to virtual...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/d09b6db3-d97a-17fa-d46d-6761fcc038d9%40virtualgl.org.
--
You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to virtual...@googlegroups.com.
DRC
Well, yes, it did help. It solved one problem that was
masking another problem, so now we can focus on the real issue.
You still haven't answered my question, though. What prompted
you to set __GLX_VENDOR_LIBRARY_NAME in the first
place? What problem did that solve, if any? Or were you just
trying random things in an attempt to make Chrome work?
VirtualGL 3.0 evolving (the code in the dev branch) now maps GLX FB configs with particular rendering attributes to 2D X server visuals in a round-robin fashion, and it front-loads this mapping in such a way that an application that hunts for a specific rendering attribute will have a high likelihood of finding a visual with an attached GLX FB config that has the desired attribute. That should eliminate the need for VGL_DEFAULTFBCONFIG in almost all cases. However, I certainly didn't consider the pathological case of an application that expects to find a GLX FB config with the same visual ID as the root visual, because in a VirtualGL environment, the visuals are on the 2D X server and the FB configs are on the 3D X server. The Chromium code could instead use glXGetFBConfigFromVisualSGIX(), which is fully supported in VirtualGL.
There may be a way of working around this, but I need to be able to reproduce it first.
DRC
To unsubscribe from this group and stop receiving emails from it, send an email to virtualgl-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/c09fd330-8fde-493c-bb29-77868d9f86d5%40googlegroups.com.
Marcello Blancasio
[VGL 0xe6421b40] glXGetFBConfigs (dpy=0x39632a26c800(:1) screen=0 *nelements=359 ) 0.128031 ms
[VGL 0xe6421b40] glXGetFBConfigAttrib (dpy=0x39632a26c800(:1) config=0x39632a22aec0(0x135) attribute=32779(0x800b) *value=941(0x3ad) ) 0.003815 ms
[VGL 0xe6421b40] glXGetFBConfigAttrib (dpy=0x39632a26c800(:1) config=0x39632a217030(0x136) attribute=32779(0x800b) *value=34(0x22) ) 0.016928 ms
[VGL 0xe6421b40] glXGetFBConfigAttrib (dpy=0x39632a26c800(:1) config=0x39632a22aca0(0x137) attribute=32779(0x800b) *value=33(0x21) ) 0.013113 ms
[VGL 0xe6421b40] glXCreateWindow (dpy=0x39632a26c800(:1) config=0x39632a22aca0(0x137) win=0x02c00002
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/c09fd330-8fde-493c-bb29-77868d9f86d5%40googlegroups.com.
DRC
Well, I've run vglrun google-chrome in TurboVNC, again. This time I kept __GLX_VENDOR_LIBRARY_NAME cleared and *Chrome got WebGL hardware acceleration*!
So I can reproduce the problem with NoMachine but I can't with TurboVNC.
The reason that make me set __GLX_VENDOR_LIBRARY_NAME=nvidia is that I'd like to use Mesa/llvmpipe for Gnome and Nvidia/VGL for Chrome but I couldn't rely on the GLX_EXT_libglvnd extension because my version of Xorg was too old.
If the nVidia proprietary drivers are installed, then libGL
should default to using those drivers if GLVND isn't available.
Also, in the scenario you describe, GLVND should be available on
the 3D X server, so VGL will use the nVidia proprietary drivers if
__GLX_VENDOR_LIBRARY_NAME is unspecified (since libGLX_nvidia is
the default GLX implementation on the 3D X server.) Thus, it
should be possible to set __GLX_VENDOR_LIBRARY_NAME=mesa when
loading the window manager, then unset __GLX_VENDOR_LIBRARY_NAME
when using VirtualGL.
That being said, I don't understand why setting __GLX_VENDOR_LIBRARY_NAME=nvidia causes problems with Chrome. As you observed, setting __GLX_VENDOR_LIBRARY_NAME=nvidia works with other GLX applications. I did notice that, if an application uses dlopen() to load libGLX rather than libGL, VirtualGL's dlopen() interposer doesn't currently handle that case, but fixing that problem doesn't change the situation with Chrome (Chrome appears to be using dlopen() to load libGL, not libGLX.)
By the way, Chrome looks searching the array of GLXFB configs for TurboVNC as well. But in this case the required visual id is found (0x21 being the id of the "dummy window" visual):
[VGL 0xe6421b40] XCreateWindow (dpy=0x39632a26c800(:1) parent=0x000003af x=0 y=0 width=1 height=1 depth=0 c_class=1 visual=0x00000000(0x00) win=0x02c00002 ) 0.005960 ms
[VGL 0xe6421b40] glXGetFBConfigs (dpy=0x39632a26c800(:1) screen=0 *nelements=359 ) 0.128031 ms
[VGL 0xe6421b40] glXGetFBConfigAttrib (dpy=0x39632a26c800(:1) config=0x39632a22aec0(0x135) attribute=32779(0x800b) *value=941(0x3ad) ) 0.003815 ms
[VGL 0xe6421b40] glXGetFBConfigAttrib (dpy=0x39632a26c800(:1) config=0x39632a217030(0x136) attribute=32779(0x800b) *value=34(0x22) ) 0.016928 ms
[VGL 0xe6421b40] glXGetFBConfigAttrib (dpy=0x39632a26c800(:1) config=0x39632a22aca0(0x137) attribute=32779(0x800b) *value=33(0x21) ) 0.013113 ms
[VGL 0xe6421b40] glXCreateWindow (dpy=0x39632a26c800(:1) config=0x39632a22aca0(0x137) win=0x02c00002
I'll see if I can mock up a test case for this.
To unsubscribe from this group and stop receiving emails from it, send an email to virtualgl-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/b33730e7-c8be-4028-8cb4-a689aeac022d%40googlegroups.com.
DRC
I don't understand why that would happen in NoMachine unless
the root visual for the X server wasn't a TrueColor visual.
Otherwise, that visual should have already been hashed to a
GLXFBConfig within the body of VirtualGL's interposed version of
glXChooseFBConfig(), or the visual will be hashed to a
GLXFBConfig within the body of VirtualGL's interposed version of
glXGetFBConfigAttrib(). In a "normal" (non-VirtualGL) GLX
environment, there is a 1:1 correspondence between GLXFBConfigs
and visuals. In a VirtualGL environment, there is not, but the
GLXFBConfig-->X visual relationship is straightforward. For
every GLXFBConfig, VirtualGL simply finds a "compatible" visual
on the 2D X server, which means a visual that matches the depth,
class (TrueColor or DirectColor), bits per RGB, and stereo
properties of the GLXFBConfig's corresponding visual on the 3D X
server. So there should be at least one GLXFBConfig that has
the root visual as a matching visual, unless that root visual is
exotic somehow.
Can you send me the output of xdpyinfo from the NoMachine X server and '/opt/VirtualGL/bin/glxinfo -c' from the 3D X server?
To unsubscribe from this group and stop receiving emails from it, send an email to virtualgl-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/b33730e7-c8be-4028-8cb4-a689aeac022d%40googlegroups.com.
Marcello Blancasio
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/b33730e7-c8be-4028-8cb4-a689aeac022d%40googlegroups.com.
DRC
OK, I think that the proximal cause of the problem is that the default visual is listed last in the NoMachine X server. VirtualGL maintains a list of X visual attributes for all 2D X server visuals returned by XGetVisualInfo(), in the order that those visuals are returned. VirtualGL then uses that attribute list to find a 2D X server visual with the appropriate depth and class to match a particular GLXFBConfig. Thus, in most cases, any TrueColor visual will be an appropriate match for a given GLXFBConfig, and VirtualGL will never use visuals at the end of the visual list.
Do you know why the default visual is last in the NoMachine X
server? I can't find any way to make TurboVNC do that.
To unsubscribe from this group and stop receiving emails from it, send an email to virtualgl-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/57419be8-5678-43a2-b7c6-7ac467475a77%40googlegroups.com.
Marcello Blancasio
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/63de624f-49da-fd07-3acb-21088adde5d7%40virtualgl.org.
DRC
OK, let me know if you are unable to do that, because it
should be possible to re-order VirtualGL's visual table to give
the default visual precedence. I would rather not have to do
that, however, unless this same problem can be shown to affect
multiple X servers.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/CAOoseGnBd32ep1hNeSfL9nYTw3n5WYdiLAKZCVaP1PuJ4VGazA%40mail.gmail.com.
Marcello Blancasio
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/57419be8-5678-43a2-b7c6-7ac467475a77%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to virtual...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/63de624f-49da-fd07-3acb-21088adde5d7%40virtualgl.org.
--
You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to virtual...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/CAOoseGnBd32ep1hNeSfL9nYTw3n5WYdiLAKZCVaP1PuJ4VGazA%40mail.gmail.com.