It is likely due to some changes to the X server core code. I'll search for a way for moving the default visual back to the first position. I'm quite confident that will fix the problem. I'll let you know, by the way. Thank you very much.
Il Ven 21 Feb 2020, 20:05 DRC <[email protected]> ha scritto: > 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 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]. >>> 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 >> <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/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 > <https://groups.google.com/d/msgid/virtualgl-users/63de624f-49da-fd07-3acb-21088adde5d7%40virtualgl.org?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/CAOoseGnBd32ep1hNeSfL9nYTw3n5WYdiLAKZCVaP1PuJ4VGazA%40mail.gmail.com.
