OpenGL hardware acceleration through remote X11 SSH connection
Overview
This article is about running an OpenGL application on a remote server and using the local graphics card for rendering. It can help you in different rare scenarios: 1. You have a server in your network and it has some software with graphical output. You want to use that software remotely on many computers in the network without installing it on each machine individually. 2. Your application needs specific hardware configuration or resources that are only available on the server. 3. You experiment with remote OpenGL rendering for some reason.
For demonstration we are going to play chromium-bsu running on a remote server using the local graphics card.
Limitations
You should be aware of the security risk of opening X server for hardware rendering. The ssh server gets more control of the client with inderict rendering enabled.
My environment
I have a server with OpenSUSE Tumbleweed 13.2. It runs in headless mode. I also have a laptop with Lubuntu 15.10 wily that connects to the server through SSH. I will call these machines OpenSUSE and Lubuntu.
Terminology
You need to be familiar with general X11 client / server and SSH concepts. Counter intuitively, in my environment the laptop acts as X server and OpenSUSE Tumbleweed as X client. At the same time, Lubuntu is ssh client and OpenSUSE is ssh server.
Direct rendering – the OpenGL application sends instructions directly to the local hardware bypassing the target X server. This is only possible with single machine. We cannot use it in our scenario.
Software rendering – software rendering engine is used without leveraging the graphics card. It can be slow.
Indirect rendering – The remote application sends instructions to the X server which transfers them to the graphics card. This is what we are going to demonstrate in this article.
Before we start
This article will not explain known topics. We assume that SSH is already configured and all packages and drivers are installed. You have a private key for ssh to connect to the server and the server authorized_keys
contains the corresponding public key.
Configure OpenSUSE
We need to enable X11 forwarding in the sshd
configuration file:
- Open /etc/ssh/sshd_config in your favorite text editor.
- Add or uncomment
X11Forwarding yes
- Restart your sshd daemon
service sshd restart
- Install the game
zypper install chromium-bsu
Nothing else needs to be done on OpenSUSE.
Configure Lubuntu
- Enable trusted forwarding. Open or create
~/.ssh/config
Host ForwardX11Trusted yes
Trusted forwarding is needed to enable 3D hardware rendering.
- Enable indirect redering. Open
/etc/lightdm/lightdm.conf
Add or uncomment:
xserver-command=X +iglx
The command enables iglx, which I believe is indirect glx.
- Restart lightdm or reboot the X server
systemctl restart lightdm.service
Run Chromium B.S.U
- Connect to the SSH server.
- Run chromium-bsu with the environment variables below:
LIBGL_ALWAYS_INDIRECT=1 chromium-bsu
You can also enable debug output for LIBGL with LIBGL_DEBUG=verbose chromium-bsu
The game is already playable. I get 30 FPS.
Make it even faster
To improve the performance further we need to enable direct TCP connection to the X server rather than going through SSH. Please note that this represents a security vulnerability and disabled by default. You can only use in a trusted local network.
- Open
/etc/lightdm/lightdm.conf
Add or uncomment:
xserver-allow-tcp=true
xserver-command=X -listen tcp +iglx
- Open
/etc/xinit/xserverrc
Commend out -nolisten
tcp and another line as follows:
# exec /usr/bin/X -nolisten tcp "$@"
exec /usr/bin/X "$@"
- Enable X11 connection to all clients (very unsafe!):
xhost +
Run Chromium B.S.U. with direct TCP connection
LIBGL_ALWAYS_INDIRECT=1 DISPLAY=<client-tcp>:0 chromium-bsu
This mode gave me the best possible performance. I could not distinguish between the game running locally and remotely from the server.
Troubleshooting and diagnostics
Use LIBGL_DEBUG=verbose
environment variable to see warning messages. I get the following messages when the application falls back to the software rendering:
libGL error: failed to authenticate magic 1
libGL error: failed to load driver: r600
libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
You can also see the following message when X server does not allow iglx (+iglx option):
AIGLX: Screen 0 is not DRI capable
Suse 11 workstation as a router
My task was to connect to my office through VPN from a SUSE workstation and allow another Windows machine to use office network resources. In this scenario SUSE acts as a router forwarding ip packets from the Windows machine to the office network.
I am using NetworkManager for VPN on my SUSE machine. In one of the previous articles I wrote about establishing VPN connection to a windows server from SUSE.
IP forwarding is disabled by default. You can check it with the following command:
cat /proc/sys/net/ipv4/ip_forward
It returns either 1 or 0. 1 means IP forwarding is enabled. I suppose you will see 0. Otherwise you wouldn’t read this article. But use this command later to verify that ip forwarding is enabled.
In my configuration I need to change settings of the SUSE firewall to allow IP forwarding. The settings you see in YAST are not comprehensive and they are not enough for the task.
Instead open /etc/sysconfig/SuSEfirewall2 in gedit. Add your VPN network interface name (run/sbin/ifconfig after connecting to VPN to get all active interfaces) to FW_DEV_EXT. It will make your office network external for the SUSE router. Add your internal network (where the packets will be coming from) to FW_DEV_INT. As a result SUSE knows that your internal network is your home network and your office network is external.
Change FW_ROUTE to yes. This will allow IP forwarding. I also changed FW_MASQUERADE to yes. Not sure it was necessary for my task. By the way masquerading can be configured in YAST GUI tool unlike IP forwarding.
Now if you invoke cat /proc/sys/net/ipv4/ip_forward, you should see 1 returned.
Forwarding will be performed according to your routing table. To see the routing table invoke
/sbin/route -n
Now go to your Windows machine. Say your office network is 111.222.333.0 (255.255.255.0) and the SUSE machine IP address is 193.333.222.1.
route add 111.222.111.0 mask 255.255.255.0 193.123.222.1
This will send packets going to your office network to the SUSE router.
Remote desktop via VPN from SUSE 11.1
I needed to work at weekends and connected to my machine at work. VPN + Remote Desktop
I used this guide to install VPN:
“sudo apt-get install network-manager-pptp” didn’t work in suse. I had to find the rpm packages. There were two I had to install:
NetworkManager-pptp-0.7.0.r4274-2.9.i586.rpm
NetworkManager-pptp-gnome-0.7.0.r4274-2.9.i586.rpm
I installed them running one command:
rpm -ivh <package1> <package2>
Then I installed rdesktop. I connect from command prompt:
rdesktop <full DNS address> -f
-f switch is full screen
There is another switch for setting the resolution:
-g 1024×768
-
Recent
- OpenGL hardware acceleration through remote X11 SSH connection
- GDB: How do I set current source file for list and break commands
- How To Create and Seed a Torrent (Ubuntu server, Transmission)
- GIT TF: Undo shallow pull and pull squashed changeset
- Lynx on Windows 7 and lynx_bookmarks.html file problem
- Old MacBook Overheating and Installation of Mac OS 10.4 on New Hard Drives
- Memory Alignment Of Structures and Classes in C++
- Align label and input vertically
- Google Test Framework and Visual Studio 2010
- Convex Hull
- Run a bash script with sudo, nohup and in the background
- Contact database with web interface – EVPO Members
-
Links
-
Archives
- March 2017 (1)
- May 2015 (1)
- January 2015 (1)
- November 2014 (1)
- October 2014 (1)
- March 2014 (1)
- January 2014 (1)
- June 2013 (1)
- May 2013 (2)
- February 2012 (2)
- October 2010 (1)
- February 2010 (1)
-
Categories
-
RSS
Entries RSS
Comments RSS