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. 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 - Marcello. Il giorno martedì 18 febbraio 2020 19:45:12 UTC+1, DRC ha scritto: > > 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? > Now, as to the visual vs. FB config matching issue, the next step is to > figure out why you observe that issue but I don't. Which versions of > Chrome and TurboVNC did you test when you observed the failure? > > 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 > On 2/18/20 10:35 AM, Marcello Blancasio wrote: > > Tried also env -u __GLX_VENDOR_LIBRARY_NAME vglrun google-chrome > and it didn't help. > > Log reported something went wrong in function CreateDummyWindow(Display* > display): > > https://github.com/chromium/chromium/blob/master/ui/gl/gl_surface_glx.cc > > It looks that such dummy window inherits visual from parent (the root > window), then the list of available GLXFBConfig > is searched for one matching GLX_VISUAL_ID. No match is found and Chrome > falls back to software rendering. > > Provided that Visuals and GLXFBconfigs come from different X server, is it > possible they match somehow? > > > Il giorno lunedì 17 febbraio 2020 18:55:49 UTC+1, DRC ha scritto: >> >> The other possible value is no value at all. VirtualGL doesn't use >> libGLX, so you shouldn't set that environment variable. >> On 2/14/20 4:07 PM, Marcello Blancasio wrote: >> >> I'm doing that to select nvidia dispatch in libGLX: it works fine with >> glxinfo. >> The other possible value is "mesa" but it makes display :0 fallback to >> glx indirect rendering. >> >> Il Ven 14 Feb 2020, 21:33 DRC <[email protected]> ha scritto: >> >>> 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 >>> . >>> >> -- >> 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/CAOoseGkfVR50AByhzrqy8TMohkiQM2hSjjAygSJEEOAUQQQ%2Bpg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/virtualgl-users/CAOoseGkfVR50AByhzrqy8TMohkiQM2hSjjAygSJEEOAUQQQ%2Bpg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- > 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] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/virtualgl-users/c09fd330-8fde-493c-bb29-77868d9f86d5%40googlegroups.com > > <https://groups.google.com/d/msgid/virtualgl-users/c09fd330-8fde-493c-bb29-77868d9f86d5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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/b33730e7-c8be-4028-8cb4-a689aeac022d%40googlegroups.com.
