No direct rendering for tigervnc and Nvidia

[patric...@legi.grenoble-inp.fr]

Dear TigerVnc users,

Some months ago I've setup a tigervnc config successfully on a linux host:

• RHEL 6
  
• ATI FirePro W7000
• tigervnc-server-1.1.0-16.el6.x86_64
• radeon driver module
  

All worked fine completly out of the box and testing rendering in a vnc session gives:

bash-4.1$ glxinfo |grep render
direct rendering: Yes

Since one week I'm tryng to setup a second Tigervnc config on a different host but I'm unable to get direct rendering.

• CentOS 6.6
• NVIDIA Quadro FX 4800 (two GPU installed, one connected to a screen for local use)
• tigervnc-Linux-x86_64-1.4.3.tar.gz for the application
• NVIDIA-Linux-x86_64-340.76.run for the nvidia drivers
  

On the host direct rendering is OK

$glxinfo |grep render
 direct rendering: Yes
 OpenGL renderer string: Quadro FX 4800/PCIe/SSE2
 

But in a VNC session I only get:

$ glxinfo |grep render
 direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
 

My application (licensed software) is a meshing tool and require OpenGL. Without Nvidia drivers (e.g. using nouveau) it doesn't run on the host.
With the configuration detailed there, it works also in the tigervnc viewer (it doesn't work with older tigervnc like tigervnc-Linux-x86_64-1.3.1.tar.gz or the Centos rpm 1.1.0-16.el6.centos )

But, with two graphics board how can I setup tigervnc to use direct rendering ?

Thanks for your advices, I'm stucked on this problem for several days...

Patrick

NB: I've tried to post this email this week-end at tigervn...@googlegroups.com but as it doesn't appear there, so I post it again on the web interface. Sorry for any possible duplicate.

[Pierre Ossman]

On Mon, 4 May 2015 04:17:55 -0700 (PDT)
patric...@legi.grenoble-inp.fr wrote:

>
> But in a VNC session I only get:
> $ glxinfo |grep render

> direct rendering: *No* (If you want to find out why, try setting
> LIBGL_DEBUG=verbose)
>

The Nvidia driver does not support direct rendering for anything but
the local display. To get it to work with TigerVNC you need to either
force your application to use the Mesa libGL (e.g. using
LD_LIBRARY_PATH), or use VirtualGL to redirect things via the local
display. The latter gives you some hardware acceleration, so it might
be the more interesting route.

Rgds
--
Pierre Ossman Software Development
Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköping http://facebook.com/ThinLinc
Phone: +46-13-214600 http://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Brian Hinz]

On Mon, May 4, 2015 at 8:14 AM, Pierre Ossman wrote:

>
> But in a VNC session I only get:
> $ glxinfo |grep render
>  direct rendering: *No* (If you want to find out why, try setting
> LIBGL_DEBUG=verbose)
>

The Nvidia driver does not support direct rendering for anything but
the local display. To get it to work with TigerVNC you need to either
force your application to use the Mesa libGL (e.g. using
LD_LIBRARY_PATH), or use VirtualGL to redirect things via the local
display. The latter gives you some hardware acceleration, so it might
be the more interesting route.

But unless LD_LIBRARY_PATH is already being set, v1.4.3 should be linking against the private libGL.so in /usr/lib64/tigervnc and SW based rendering should still be in effect.

How did you install it?  DId you uncompress the entire contents of the tarball or did you just extract the Xvnc binary?

-brian

[Pierre Ossman]

On Mon, 4 May 2015 08:47:12 -0400
Brian Hinz <bph...@users.sourceforge.net> wrote:

>
> But unless LD_LIBRARY_PATH is already being set, v1.4.3 should be
> linking against the private libGL.so in /usr/lib64/tigervnc and SW
> based rendering should still be in effect.
>

That only covers the swrast driver loaded by Xvnc. The applications
will still load the Nvidia libGL unless you tell them otherwise. And
that libGL does not support talking DRI with the Mesa swrast driver in
Xvnc.

[Brian Hinz]

On Mon, May 4, 2015 at 8:51 AM, Pierre Ossman wrote:

On Mon, 4 May 2015 08:47:12 -0400
Brian Hinz wrote:

>
> But unless LD_LIBRARY_PATH is already being set, v1.4.3 should be
> linking against the private libGL.so in /usr/lib64/tigervnc and SW
> based rendering should still be in effect.
>

That only covers the swrast driver loaded by Xvnc. The applications
will still load the Nvidia libGL unless you tell them otherwise. And
that libGL does not support talking DRI with the Mesa swrast driver in
Xvnc.

Gotcha.  Patrick - you might want to try using the pre-built EL6 rpms (look in the "Files" section on bintray).  Those do not link against a private libGL but rely on the distro supplied libGL (which, as I understand it, gets supplanted with Nvidia's version when you install the driver).  It seems like that should eliminate the need to set LD_LIBRARY_PATH.

[Pierre Ossman]

On Mon, 4 May 2015 09:00:21 -0400
Brian Hinz <bph...@users.sourceforge.net> wrote:

>
> Gotcha. Patrick - you might want to try using the pre-built EL6 rpms
> (look in the "Files" section on bintray). Those do not link against
> a private libGL but rely on the distro supplied libGL (which, as I
> understand it, gets supplanted with Nvidia's version when you install
> the driver). It seems like that should eliminate the need to set
> LD_LIBRARY_PATH.
>

But at that point we're back the original problem of Xvnc failing to
load swrast and disabling GLX completely. Or am I missing something?

[Brian Hinz]

On Mon, May 4, 2015 at 9:09 AM, Pierre Ossman wrote:

On Mon, 4 May 2015 09:00:21 -0400
Brian Hinz wrote:

>
> Gotcha.  Patrick - you might want to try using the pre-built EL6 rpms
> (look in the "Files" section on bintray).  Those do not link against
> a private libGL but rely on the distro supplied libGL (which, as I
> understand it, gets supplanted with Nvidia's version when you install
> the driver).  It seems like that should eliminate the need to set
> LD_LIBRARY_PATH.
>

But at that point we're back the original problem of Xvnc failing to
load swrast and disabling GLX completely. Or am I missing something?

You're probably right.  It's kind of a shame that if their driver only accelerates local displays that it doesn't(?) allow falling back to swrast for non-local ones... 

So the best "workaround" is probably to continue using the generic binaries and prefix LD_LIBRARY_PATH with /usr/lib64/tigervnc.  The best "solution" is probably (as Pierre mentioned) to use VirtualGL.

[patric...@legi.grenoble-inp.fr]

Thanks for these suggestions. I've just print out the VirtualGL documentation and begin to look at it's configuration.
For TigerVNC, I've unpacked the tar.gz archive from / with root login. The server is not in prod and I can launch many tests and re-install quickly with kikstart.
With 1.3.1 version of tigerVNC I had some refresh problem in the graphic windows (the one showing the 3D mesh and only this one) behind the mouse cursor. It works fine with the latest version.