Why are you setting __GLX_VENDOR_LIBRARY_NAME? That seems to be the source of the problem.
On 2/14/20 12:59 PM, Marcello Blancasio wrote: > # cat /etc/redhat-release > 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)] > ContextResult::kTransientFailure: Failed to send > GpuChannelMsg_CreateCommandBuffer. > [VGL] ERROR: in VirtualWin-- > [VGL] 75: Could not clone X display connection > [13551:13:0214/185929.197750:ERROR:command_buffer_proxy_impl.cc(124)] > ContextResult::kTransientFailure: Failed to send > GpuChannelMsg_CreateCommandBuffer. > > NoMachine: > [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 process due to errors during initialization > > On 13/02/2020 00:15, DRC wrote: >> I was unable to reproduce the issue on CentOS 7 with an nVidia GPU or on >> CentOS 8 with VMWare Tools. Can you provide more details regarding your >> system? >> >> DRC >> >> On 1/28/20 11:13 AM, Marcello Blancasio wrote: >>> Hello, >>> >>> I'm not able to run recent Chrome with GPU acceleration ( >>> google-chrome-stable.x86_64, version 79.0.3945.130-1, installed from >>> google-chrome repo): >>> >>> [6981:6981:0128/172712.708029:ERROR:gl_surface_glx.cc(129)] Failed to >>> get GLXConfig >>> [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. >>> >>> Chrome succeeds to start but chrome://gpu reports "Software only" for >>> WebGL/WebGL2. >>> >>> I also tried the workaround suggested here: >>> https://github.com/VirtualGL/virtualgl/issues/73 >>> >>> without success. I exported VGL_DEFAULTFBCONFIG=GLX_ALPHA_SIZE,8 to >>> the environment but nothing changed. >>> >>> - >>> M. > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/d09b6db3-d97a-17fa-d46d-6761fcc038d9%40virtualgl.org.
