Getting VirtualGL working

[ainthelp]

Hello all,

I am currently evaluating NoMachine Workstation 8.15.3-1 on a powerful Dell workstation running openSUSE Leap 15.5 .
It has a Nvidia Quadro RTX 5000 GPU and Nvidia drivers version 470.256.02 from the distro repos installed. We are using KDE Plasma as Desktop type.

On the client side we are running NoMachine Enterprise 6.7.6 on Windows. (I know it’s a bit outdated, but an update to the same version as the server side is in the making at central IT Windows software management.)
We are running scientific applications with a high demand for graphics performance and we aim to also do this from remote.

So far most of the functionalities we are looking for are working well and most of the software we tested is working. With one exception: Our most important software fails with the error “X server has no OpenGL GLX extension.”.

I followed chapter 6.4 from the installation and configuration guide, and also followed the knowledge base article  https://kb.nomachine.com/AR05P00982 .
The configuration I chose is to run all applications including the desktop on the GPU.

If I connect to the physical desktop, everything is fine and the OpenGL software runs. On a virtual KDE desktop, it fails.

I did run
# nxserver –virtualglinstall
and
# /opt/NX/bin/nxserver –virtualgl yes
and I rebooted the system afterwards.

But on a virtual desktop I still get diagnosed that VirtuaGL is not active:

% glxinfo | grep -i “renderer\|vendor”
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control,
GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_OML_swap_method,
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa/X.org (0xffffffff)
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 15.0.7, 256 bits)
% env | grep LD_PRELOAD
LD_PRELOAD=

I read for hours in the knowledge base, FAQs and searched the internet. But I could not find out what I did wrong. The Forum thread  https://forum.nomachine.com/topic/is-virtualgl-working-correctly  seems related, but not exactly the same problem.

Can somebody provide hints or ideas? Thanks in advance!

[Britgirl]

Can you send us the server-side logs. Enable debug and extract them using the instructions here: https://kb.nomachine.com/DT07S00243. The command ‘nxserver --debug --enable‘ allows to gather debug logs for all components: nxserver, nxnode, nxwebplayer/runner and the display agent. Execute it on the server/node machine where the problem occurs. Please don’t remove the node logs as they are important as well.

Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!

[ainthelp]

Just for completeness sake in this thread. Did as requested and provided the logs via PM.

[Britgirl]

Hi, the logs didn’t include the user’s home which is strange, the automatic procedure should include it. Can you try again, this time with the manual procedure?

https://kb.nomachine.com/DT07S00244

 

[ainthelp]

Been there, done that.

[Britgirl]

Thanks for the logs, we will come back to you once they have been analyzed.

[fra81]

Hi.

It’s strange that the LD_PRELOAD variable is not set in the environment, despite we see it being set in the logs. It seems like something else is clearing the environment afterwards, maybe something in the user’s profile.

However, you may check if VirtualGL is functional by trying to run your app through the vglrun command:

/opt/NX/scripts/vgl/vglrun <opengl app>

(assuming NoMachine is installed in ‘opt’ dir, as we see in the logs)

The, you may try to run the whole desktop via the vglrun command by adding it to the DefaultDesktopCommand key in the node.cfg file, e.g.:

DefaultDesktopCommand "/usr/bin/dbus-launch --exit-with-session /opt/NX/scripts/vgl/vglrun gnome-session"

[ainthelp]

Many thanks, fra81, for your reply!

Yes, I also wondered why the LD_PRELOAD environment variable is undefined. I checked the system configuration with

# grep -r LD_PRELOAD /etc/*sh*

and found nothing. Neither deletion nor overwriting of this variable.

I also checked the affected user’s profile with

% grep -R LD_PRELOAD ~/.*

and only found occurrences in the command history.

Then I wondered if it may be related to the fact that we are using  tcsh  as default login shell, not  bash .
I changed one user to  /usr/bin/bash  as login shell and retried. But no difference at all.

When I connect to the physical display, LD_PRELOAD is defined and OpenGL applications are working.
Only when I startup a new virtual KDE desktop, LD_PRELOAD is undefined and OpenGL not working.
Using the  vglrun  command you provided with an OpenGL program I could verify that VirtualGL is functional. Started with  vglrun , the OpenGL application even works on a virtual display.

Manually setting the LD_PRELOAD variable to “/opt/NX/lib/libnxegl.so” does not ‘fix’ the virtual session.

I then tried to start the whole desktop via the vglrun command. We are using KDE Plasma, so I added this line into  node.cfg :

DefaultDesktopCommand “/usr/bin/dbus-launch –exit-with-session /opt/NX/scripts/vgl/vglrun /usr/bin/startplasma-x11”

But even after a reboot of the system there was no change: VirtualGL works in physical session, but fails in virtual session.

I checked for the processes and noticed that the first one started by  nxnode.bin  referred to Wayland:

% ps -lefl | egrep “3069|2964|3163|3174” | grep -v grep | sort -n -k 4
4 S username   2964  2950  4  60 -20 – 842297 do_epo 14:21 ?       00:00:15 /opt/NX/bin/nxnode.bin
0 S username   3069  2964  0  80   0 –  6058 sigsus 14:21 ?        00:00:00 – -c env -u WAYLAND_DISPLAY /usr/bin/dbus-launch –sh-syntax –exit-with-session /usr/bin/startplasma-x11
0 S username   3106  2964  1  80   0 – 299205 do_sys 14:21 ?       00:00:03 /usr/bin/pulseaudio –high-priority=no
0 S username   3114  2964  0  80   0 – 301362 do_sel 14:21 ?       00:00:00 /opt/NX/bin/nxrunner.bin –monitor –pid 3069
0 S username   3163  3069  0  80   0 – 64579 do_sys 14:21 ?        00:00:00 /usr/bin/startplasma-x11
1 S username   3174     1  0  80   0 –  6947 do_sel 14:21 ?        00:00:00 /usr/bin/dbus-launch –sh-syntax –exit-with-session /usr/bin/startplasma-x11
0 S username   3327  3163  0  80   0 – 62553 do_sys 14:21 ?        00:00:00 /usr/bin/plasma_session
0 S username   3448  2964  5  60 -20 – 59013 pipe_r 14:21 ?        00:00:17 /opt/NX/bin/nxcodec.bin

May this be related? We are using X11, because our software is not compatible with Wayland.
OTOH the session itself reported it as X11 session:

% echo $XDG_SESSION_TYPE
x11

Any further ideas? Anything else I can try?

[fra81]

Manually setting the LD_PRELOAD variable to “/opt/NX/lib/libnxegl.so” does not ‘fix’ the virtual session.

Note that LD_PRELOAD is set to a different value in the physical desktop and for a different purpose. In virtual desktops, the value you are supposed to see is:

LD_PRELOAD=/opt/NX/scripts/vgl/libdlfaker.so:/opt/NX/scripts/vgl/libvglfaker.so

You can try to set it manually and check again.

The question is still why LD_PRELOAD is not set, even if in the logs we see that it’s being added to the environment of the desktop process. At the moment I don’t have further ideas, we will check again in our labs with KDE Plasma.

[ainthelp]

Note that LD_PRELOAD is set to a different value in the physical desktop and for a different purpose. In virtual desktops, the value you are supposed to see is:

LD_PRELOAD=/opt/NX/scripts/vgl/libdlfaker.so:/opt/NX/scripts/vgl/libvglfaker.so

You can try to set it manually and check again.

Ah, I didn’t know that.
Yes, if I manually set it to the new value for virtual desktops, the OpenGL application works!

Also the test command yields the expected result now:

% glxinfo | grep -i “renderer\|vendor”
server glx vendor string: VirtualGL
client glx vendor string: VirtualGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro RTX 5000/PCIe/SSE2

 

The OpenGL application still throws an error on start, despite that it finally starts successfully:

libGL error: MESA-LOADER: failed to open swrast: /SW/Schrodinger/current/mmshare-v6.7/lib/Linux-x86_64/libstdc++.so.6: version `GLIBCXX_3.4.30′ not found (required by /usr/lib64/libLLVM.so.15) (search paths /usr/lib64/dri, suffix _dri)
libGL error: failed to load driver: swrast

Don’t know if this could be related or is something different.

 

The question is still why LD_PRELOAD is not set, even if in the logs we see that it’s being added to the environment of the desktop process. At the moment I don’t have further ideas, we will check again in our labs with KDE Plasma.

Let me know if there is anything I can test or diagnose to support you with this.

How can I recognize a virtual desktop session in the shell? Perhaps, if this was possible we could define LD_PRELOAD accordingly in the system wide login files?

 

[Author]

Posts