Referring to the VirtualGL User's Guide, Display :0 is what we refer to
as the "3D X server", because it has a GPU attached. Display :10 in
your case is what we refer to as the "2D X server." The 2D X server is
also, in your case, an "X proxy": an X server that renders X11
primitives into images using a virtual framebuffer located in the
system's main memory (Xvfb, for example, is another type of X proxy,
although in that case, there is no remote display server attached to
it.) You can't see the output of glxgears when it is routed to Display
:0, because that output is going to the monitor attached to the graphics
card (assuming it even has a monitor-- some nVidia GPUs are headless,
and the 3D X server acts solely as a way of accessing the GPU for
Because X proxies aren't "real" X servers, they can't ever render OpenGL
with hardware acceleration (because doing so requires that the
framebuffer reside in GPU memory, not in main memory.) Some X proxies
don't support OpenGL at all. XRDP apparently doesn't. Upon further
examination, XRDP does work in concert with TigerVNC to support VNC
clients, but it is its own separate solution, and apparently the X proxy
in XRDP doesn't support GLX and OpenGL. Even if it did, its
implementation of OpenGL still wouldn't be hardware-accelerated. In
short, don't become overly focused on the fact that you have to use
vglrun to launch glxgears. That's going to be the case more often than
not when dealing with X proxies, and it's the reason VirtualGL exists.
VirtualGL splits the 3D rendering and sends it to Display :0.
Meanwhile, the 2D rendering goes to Display :10, and whenever the 3D
application swaps its buffer, VirtualGL reads those pixels back from the
GPU and composites them into Display :10.
As Robert indicated, we also do recommend that you use TurboVNC, because
it is designed to provide the performance necessary to run 3D
applications interactively, and it has additional features that are
designed specifically around the needs of such applications. RDP will
be somewhat slower. TurboVNC is also a lot easier to install and configure.
On 9/18/16 6:37 PM, Joshua Moore wrote:
> I'm able to get glxgears to run without vlgrun to run on DISPLAY 0 over
> the Remote connection, but then it doesn't show any graphics on my
> remote display (which is :10), but I get the text output. I can also
> get it to run using ANSYS's Mesa libraries oddly
> enough /ansys_inc/v172/Framework/bin/Linux64/Mesa.
> I played around with trying to get the right libraries to load in /lib64
> /lib /usr/lib and /usr/lib64, but I still wasn't able to get it to run
> without vlgrun.
> I am basically following the setup here for XRDP + TigerVNC for Remote
> Desktop (with the addition that I also had to add ssl certificates to
> get it to work)
> That page suggests to add to xorg.conf
> * Section “Module”
> * Load “extmod”
> * Load “due”
> * Load “type1”
> * Load “freetype”
> * Load “clx”
> * EndSection
> However, after doing this and rebooting, then vlgrun doesn't work anymore.
> Anyway, it is working now it seems. I can use
> VGL_LOGO=1 vglrun glxgears (or glxspheres64 or runwb2) and then I get
> the VGL_LOGO to appear, which I think means I am getting hardware
> On Sun, Sep 18, 2016 at 6:13 PM, Robert Goley <rago...@rdasys.com
> <mailto:rago...@rdasys.com>> wrote:
> My understanding of xrdp is that it is a stand alone x server just
> like turbo NC or TigerVNC are. I question how you are running both x
> servers with a single X client. I would recommend using just
> turbovnc on the server and the turbo vnc client with security
> extensions turned on to replace the use of rdp entirely.
> On Sep 18, 2016 12:39 AM, "Joshua Moore" <jdmo...@ncsu.edu
> <mailto:jdmo...@ncsu.edu>> wrote:
> I think I figured it out finally.
> I only can get it to work using
> vglrun runwb2
> Previously I had LD_LIBRARY_PATH to include
> /ansys_inc/v172/Framework/bin/Linux64/Mesa. I think that was
> overriding some of the NVIDIA drivers or something.
> Now it runs and doesn't crash and no errors.
> Why can't I get glxgears to run without (vglrun glxgears). Is
> it not compatible with NVIDIA's OpenGL libraries?
> On Sat, Sep 17, 2016 at 11:56 PM, Joshua Moore <jdmo...@ncsu.edu
> <mailto:jdmo...@ncsu.edu>> wrote:
> I am using Windows Remote Desktop to connect to a CentOS7.2
> box with a NVIDIA GeForce GT 720 graphics card. I also have
> a NVIDIA Tesla K40c on it as well.
> I am using TigerVNC and XRDP and then launching workbench with
> vglrun runwb2
> Everything seems to work ok, except when I try to open
> "System Coupling".
> Then I get
> [VGL] ERROR: in init--
> [VGL] 218: Invalid argument
> Exception caught in virtual
> Ans::Graphics::Scene::EventProcessor::~EventProcessor() @line176
> Then Workbench closes immediately with no other error message
> I am very new to using VNC, and Remote Desktop to access
> Linux, as well as even newer to OpenGL and VirtualGL.
> Does anyone know what is going on? Or if someone else is
> using ANSYS and can duplicate this error?
> I have ANSYS on another machine running CentOS7.2. It does
> not have a NVIDIA graphics card. Actually I'm not even sure
> what kind of graphics card it is running, but it definitely
> isn't a good one. It runs just fine. I can open ANSYS
> without VirtualGL just with runwb2 and can open System
> Coupling and it seems to run just fine. I do get error in
> the WorkbenchLog files which state that I don't have
> hardware acceleration.
VirtualGL-Users mailing list