On 4/5/18 8:26 PM, qwofford wrote:
> I am having problems with the way /opt/TurboVNC/bin/Xvnc is being
> launched by /opt/TurboVNC/bin/vncserver, however (which I will refer to
> as Xvnc and vncserver from here forward).
>> My /etc/lightdm/lightdm.conf:
TurboVNC is not designed to be started from the DM, and in fact, it's a
bad idea to do so, because the DM usually runs under a special account
with limited privileges. Let me back up and explain that Xvnc sessions
are virtual. They create a virtual X server that is completely
decoupled from the "root" X server and the server machine's graphics
hardware. That's why VirtualGL is necessary-- it directs the OpenGL
commands from a 3D application to the "root" X server (AKA "3D X
server"), which has GPU hardware attached, and it rewrites the commands
such that OpenGL rendering occurs in an off-screen Pbuffer instead of an
X window. VirtualGL reads back the rendered 3D images in real time
(generally when it detects an end-of-frame trigger command, such as
glXSwapBuffers(), being issued by the application) and displays the 3D
images to the "2D X server" (a TurboVNC session, in your case) using
regular 2D X11 drawing commands. This allows multiple virtual X servers
(TurboVNC sessions) to co-exist simultaneously on the same server
machine, and with VirtualGL, those virtual X servers can share the GPU
hardware to get 3D acceleration. Without VirtualGL, the only way to run
a 3D application with hardware acceleration would be using only the 3D X
server, which would require you to be sitting in front of the server
machine, or it would require the use of a "screen scraper" to send the
pixels from the 3D X server over the network. Such is inherently a
single-user solution and is not what VirtualGL and TurboVNC
fundamentally do. Screen scrapers tend to be slow, they exhibit tearing
artifacts, and they tend not to work well (or at all) with hardware 3D
acceleration (another reason why VirtualGL exists.)
Just log in with a normal SSH terminal and run
/opt/TurboVNC/bin/vncserver to start a server session (or you can just
execute 'ssh {host} /opt/TurboVNC/bin/vncserver' on the client.) That
will ensure that the TurboVNC Server session runs under your user
account, which is what you want. You don't want to run it as root or as
the lightdm user.
> Despite these apparent problems, I am able to start a vncserver, and
> connect to it using the TurboVNC Viewer. The trouble is that, in my
> remote session, I am presented with only a firefox browser opened to
> Centos documentation. I assumed this was because my .vnc/xstartup file
> needed to be edited, so I added a line to start a mate-session. This did
> not change the behavior. In fact, I can stop lightdm entirely, and my
> Xvnc session window with the firefox browser remains intact. Is it
> possible that I'm running an Xsession without a display manager at all?
TurboVNC uses ~/.vnc/xstartup.turbovnc, but you don't even have to edit
it. You can just 'export TVNC_WM=mate-session' prior to starting the
TurboVNC Server, and it will load MATE as the window manager. The
default GNOME 3 window manager in RHEL 7 isn't very VNC-friendly,
because it's a compositing window manager and generally requires
hardware-accelerated OpenGL in order to achieve any kind of decent
performance. You can run the window manager in VirtualGL by passing
-3dwm to vncserver, but it's really much better to just use MATE or
another non-compositing window manager.
> I have configured TurboVNC with VirtualGL and TigerVNC server for
> previous use cases, and the performance was excellent. I do feel that
> the remote desktop component is clunky and unnecessary, however. If you
> were to eliminate the X server from VirtualGL, what would be the ideal
> application for that tool? Would you simply launch a remote app with a
> command like 'vglrun username@server -app '/path/to/OpenGL/app'?
You can't run a Unix OpenGL application without an X server of some
sort. TurboVNC is an "X proxy", so it creates virtual X servers on a
per-user basis (refer to diagrams in the VirtualGL and TurboVNC User's
Guides.) There are any number of other X proxies that can also be used
to accomplish the same task, although I assert that TurboVNC is faster
with 3D application workloads than most if not all of them (except
TigerVNC, but that's only because I added the TurboVNC encoding methods
and optimizations to TigerVNC "back in the day.") Some examples of
other X proxies are: TigerVNC (which you know) and ThinLinc (commercial
product based on TigerVNC), RealVNC (available in an ancient, slow, open
source flavor and a new, faster, closed-source variety), FreeNX,
NoMachine Enterprise (closed-source commercial product-- successor to
NX), xpra, Exceed Freedom (closed-source commercial product), and Oracle
Secure Global Desktop (closed-source commercial product.) There are
others. VirtualGL should work with any of the above, or with any other
2D X server or X proxy.
When used with the VGL Transport (vglclient/vglconnect), the 2D X server
is running on the client machine, so in that configuration, VirtualGL is
being used to prevent the OpenGL/GLX commands and data from traveling
over the network, but the rest of the X11 commands are still sent to the
client machine to be rendered (remote X.) VirtualGL is a bolt-on
technology for remote X in that case, and some people prefer that
configuration when running on a high-speed network with a Unix client,
precisely because it eliminates the need for a remote desktop. Most,
however, just use TurboVNC, because the remote X approach is clunky with
Windows clients.
With the X proxy configuration, both OpenGL/GLX commands and X11
commands are rendered on the server, and only images are sent over the
network (refer to https://virtualgl.org/About/Background.) There is no
other way, of which I'm aware, to solve this problem. As I mentioned,
with some difficulty VirtualGL might be modified such that it doesn't
require a 3D X server, but the 2D X server will always be required (that
is, until Wayland become ubiquitous enough that most applications and
GUI frameworks start using that instead of X11.)
--
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/c2cb5279-69db-10a6-6a0c-4792395e4f5f%40virtualgl.org.
For more options, visit https://groups.google.com/d/optout.
