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? On 2/19/20 11:16 AM, Marcello Blancasio wrote: > 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 >> functionCreateDummyWindow(Display* display): >> >> https://github.com/chromium/chromium/blob/master/ui/gl/gl_surface_glx.cc >> >> <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 >>> <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 >>> >>> <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] > <mailto:[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 > <https://groups.google.com/d/msgid/virtualgl-users/b33730e7-c8be-4028-8cb4-a689aeac022d%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/11ad807a-cfeb-79b3-fe42-bdeb48e84c24%40virtualgl.org.
