Also, yes, the "regular" X server needs to be running in order to use
VirtualGL with its GLX back end. Refer to the VirtualGL User's Guide for
more details on that. You can also try the EGL back end, which doesn't
require a "3D X server", but the EGL back end doesn't support some
esoteric and legacy GLX features.
DRC
On 9/30/24 8:03 AM, Paul Melis wrote:
It turned out that the reason Xvnc got killed during startup was that
the regular X server wasn't running. If I start that (and keep it
running) before starting the VNC server then all is well and the vgl
faker libraries end up in LD_PRELOAD and interception works as expected.
There is a weird thing with that though. Since the faker libs are not
present with absolute paths it seems that attempts to load them can
give warnings. For example:
snellius paulm@gcn50 10:21 ~/projects/opengl-triangle-bench-git/build$
git pull
ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'libvglfaker.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'libvglfaker.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored. Already up to date.
This appears to come from ssh-keysign (which is used by git pull):
snellius paulm@gcn50 10:13 ~/projects/opengl-triangle-bench-git/build$
/usr/libexec/openssh/ssh-keysign
ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object 'libvglfaker.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
I haven't noticed any othercommands leading to this warning, but it is
somewhat annoying (especially to users that don't know what it means).
Plus, I do believe that the paths to the VGL fakers in LD_PRELOAD
should be absolute?
On Wednesday, September 25, 2024 at 9:54:06 PM UTC+2 DRC wrote:
Note that specifying TVNC_MT and TVNC_NTHREADS isn't necessary.
Since TurboVNC 2.2, the server automatically enables Tight
multithreading with a thread count equal to the number of CPU cores.
I get the same warning about an X server already running on
display :1, but it appears to be innocuous:
https://forums.freebsd.org/threads/xfce-says-x-server-already-running.30863/
Apparently startxfce4 can start an X server if one isn't already
running, but if it is run against an existing X server, it prints
the warning to indicate that it won't start its own X server.
I suspect that the real problem is that VirtualGL isn't working
for some reason. Start the TurboVNC Server with:
XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/local/share/:/usr/share/ \
/opt/TurboVNC/bin/vncserver -noxstartup -geometry 1240x900 -dpi 90
Then set DISPLAY to the X display of the TurboVNC session you just
started, and run
vglrun /opt/VirtualGL/bin/glxspheres64
I suspect that VirtualGL will fail.
DRC
On 9/25/24 11:32 AM, Paul Melis wrote:
So I'm trying to get this running locally on our system, but run
into an issue.
The batch script to launch the VNC server on a compute node
pretty much does this:
/usr/bin/X &
TVNC_MT=1 TVNC_NTHREADS=4
XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/local/share/:/usr/share/ \
/opt/TurboVNC/bin/vncserver \
-vgl -wm xfce \
-fg \
-geometry 1240x900 \
-dpi 90
When the VNC server starts up it exits quickly:
snellius paulm@gcn154 17:28 ~$ TVNC_MT=1 TVNC_NTHREADS=4
XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/local/share/:/usr/share/
/opt/TurboVNC/bin/vncserver -vgl -wm xfce -fg -geometry
1240x900 -dpi 90
Desktop 'TurboVNC: gcn154.local.snellius.surf.nl:1
<http://gcn154.local.snellius.surf.nl:1> (paulm)' started on
display gcn154.local.snellius.surf.nl:1
<http://gcn154.local.snellius.surf.nl:1>
Starting applications specified in
/opt/TurboVNC/bin/xstartup.turbovnc
(Enabling VirtualGL)
Log file is /home/paulm/.vnc/gcn154.local.snellius.surf.nl:1.log
Killing Xvnc process ID 1426621
Looking in the VNC log file:
25/09/2024 17:14:01 framebuffer updates 0, rectangles 0, bytes 0
xstartup.turbovnc: Creating new session bus instance:
xstartup.turbovnc:
unix:abstract=/tmp/dbus-qn7ynuWttb,guid=fd2fba716838b6b1474ecf7f66f428b9
xstartup.turbovnc: Using 'xfce' window manager in
xstartup.turbovnc: /usr/share/xsessions/xfce.desktop
xstartup.turbovnc: Executing /usr/bin/ssh-agent vglrun +wm
/etc/X11/xinit/Xsession "startxfce4"
Environment variable $XAUTHORITY not set, ignoring.
Failed to import environment: Process org.freedesktop.systemd1
exited with status 1
/bin/startxfce4: X server already running on display :1
The "already running on display :1" message is really curious.
There isn't any existing XFCE session running on the node. I
found a (very old, 2014) forum post and link to bug report that
lists the same error,
https://bbs.archlinux.org/viewtopic.php?id=180965. But I'm not
sure if this is still relevant?
This is with TurboVNC 3.1.1 and VirtualGL 3.1.1 on a RHEL9
compute node, btw. The installed XFCE is 4.18.3. I still need to
test on our regular visualization nodes with A100s, the above is
one with an H100, but I think the startup doesn't even come close
anything GPU related.
On Friday, September 6, 2024 at 5:45:18 PM UTC+2 DRC wrote:
No downsides. As a matter of fact, TurboVNC makes that
easier for you. You can simply pass '-vgl -wm xfce' to
/opt/TurboVNC/bin/vncserver, or set
$useVGL = 1;
$wm = "xfce";
in turbovncserver.conf (under /etc for system-wide or ~/.vnc
for per-user). The -wm argument/$wm variable correspond to a
session desktop file under /usr/share/xsessions. In the case
of Xfce, the session desktop file does nothing but run
startxfce4, but other window managers (e.g. GNOME) sometimes
have additional arguments or environment variables embedded
in their session desktop files, so using -wm/$wm is the
preferred way to start a window manager these days.
/opt/TurboVNC/bin/xstartup.turbovnc should take care of all
of the mechanics automatically. Also, you should use
xstartup.turbovnc rather than overriding the X startup
script, because xstartup.turbovnc sets up a separate D-Bus
session bus instance for each TurboVNC session. (Some window
managers, such as GNOME and MATE, need that in order to run
multiple simultaneous sessions.)
All window managers listed here:
https://turbovnc.org/Documentation/Compatibility30
have been tested both with and without VirtualGL.
DRC
On 9/6/24 7:21 AM, Paul Melis wrote:
Hi, I saw this handy tip somewhere, to start the desktop
environment within a VNC server under vglrun, e.g.
`-xstartup "vglrun xfce4"` when using TurboVNC with XFCE.
This avoids the user within the VNC session to have to use
vglrun for OpenGL apps, but I'm wondering if there's
downsides to this approach that I might be missing.
Paul
--
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/cdb4028a-fbfe-4e61-b890-d663a8beefebn%40googlegroups.com
<https://groups.google.com/d/msgid/virtualgl-users/cdb4028a-fbfe-4e61-b890-d663a8beefebn%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/45d80097-cbaf-4912-9c8a-29208ff1fecbn%40googlegroups.com
<https://groups.google.com/d/msgid/virtualgl-users/45d80097-cbaf-4912-9c8a-29208ff1fecbn%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/3b10eac1-dfff-46d6-8482-fa817e183c1bn%40googlegroups.com
<https://groups.google.com/d/msgid/virtualgl-users/3b10eac1-dfff-46d6-8482-fa817e183c1bn%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/43000074-fe14-4b74-b9e6-f005e49da670%40virtualgl.org.
