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.

Reply via email to