OK, let me know if you are unable to do that, because it should be possible to re-order VirtualGL's visual table to give the default visual precedence. I would rather not have to do that, however, unless this same problem can be shown to affect multiple X servers.
On 2/21/20 2:55 PM, Marcello Blancasio wrote: > 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] > <mailto:[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 >>>> functionCreateDummyWindow(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] >> <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] > <mailto:[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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/virtualgl-users/CAOoseGnBd32ep1hNeSfL9nYTw3n5WYdiLAKZCVaP1PuJ4VGazA%40mail.gmail.com > <https://groups.google.com/d/msgid/virtualgl-users/CAOoseGnBd32ep1hNeSfL9nYTw3n5WYdiLAKZCVaP1PuJ4VGazA%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/bba43a89-2a47-3a88-7944-125c6dd6984c%40virtualgl.org.
