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. On 2/21/20 5:15 AM, Marcello Blancasio wrote: > Sure. > > Il giorno giovedì 20 febbraio 2020 19:01:31 UTC+1, DRC ha scritto: > > 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]. >>> 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] <javascript:>. >> 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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/virtualgl-users/57419be8-5678-43a2-b7c6-7ac467475a77%40googlegroups.com > <https://groups.google.com/d/msgid/virtualgl-users/57419be8-5678-43a2-b7c6-7ac467475a77%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/63de624f-49da-fd07-3acb-21088adde5d7%40virtualgl.org.
