# OpenGL, software rendering and VNC
**URL:** https://community.mrtrix.org/t/opengl-software-rendering-and-vnc/2728
**Category:** Uncategorized
**Created:** [August 1, 2019, 5:10pm UTC](https://community.mrtrix.org/t/opengl-software-rendering-and-vnc/2728 "2019-08-01T17:10:46Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@rusty](https://community.mrtrix.org/u/rusty)
#### Post date: [August 1, 2019, 5:10pm UTC](https://community.mrtrix.org/t/opengl-software-rendering-and-vnc/2728/1 "2019-08-01T17:10:46Z")
Hello,
I’ve been trying to create a portable build of Mrtrix3 for use on our HPC cluster, but I’m running into OpenGL issues. I built Mrtrix on a virtual machine (Centos 7.2, gcc 8.3, qt 5.9.2, mesa 18.0.5) and then used a package\_mrtrix type approach to bundle mrtrix with the qt plugins and dependent libraries (with the exception of lib_GL_ and libfontconfig). After I deployed mrtirx to the cluster machines, I also used patchelf to modify rpath and interpreter settings within the libraries and binaries.
As far as I can tell, the non-gui functions work as expected on all the OS images we support. On our newest OS image (Centos 7.2, no GPU hardware or drivers, mesa 18.0.5, TurboVNC 1.2.2), however, attempting to run mrview in a VNC session gives:
```auto
[me@machine]$ mrview -debug
(mrview:101557): Gtk-WARNING **: 17:23:00.259: Theme parsing error: other-applications.css:310:8: Missing name of pseudo-class
(mrview:101557): Gtk-WARNING **: 17:23:00.260: Theme parsing error: other-applications.css:381:50: Missing name of pseudo-class
mrview: [DEBUG] No config file found at "/etc/mrtrix.conf"
mrview: [DEBUG] No config file found at "/home/me01/.mrtrix.conf"
WARNING: Application calling GLX 1.3 function "glXCreatePbuffer" when GLX 1.3 is not supported! This is an application bug!
mrview: [INFO] GL renderer: llvmpipe (LLVM 6.0, 256 bits)
mrview: [INFO] GL version: 2.1 Mesa 18.0.5
mrview: [INFO] GL vendor: VMware, Inc.
mrview: [WARNING] unable to determine OpenGL version - operation may be unstable if actual version is less than 3.3
mrview: [DEBUG] loading font into OpenGL texture...
mrview: [DEBUG] compiling OpenGL vertex shader:
#version 330 core
layout(location = 0) in vec2 pos;
layout(location = 1) in vec2 font_pos;
uniform float scale_x;
uniform float scale_y;
out vec2 tex_coord;
void main () {
gl_Position = vec4 (pos[0]*scale_x-1.0, pos[1]*scale_y-1.0, 0.0, 1.0);
tex_coord = font_pos;
}
mrview: [ERROR] GLSL log [vertex shader]: 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES
mrview: [ERROR] error compiling OpenGL vertex shader ID 1
mrview: [SYSTEM FATAL CODE: SIGSEGV (11)] Segmentation fault: Invalid memory access
```
The version related error messages disappear if I set the various MESA\_\*\_VERSION\_OVERRIDE environment variables to 3.3 or 330, but mrview comes to a pretty hard stop:
```auto
mrview: xcb_out.c:486: _xcb_out_flush_to: Assertion `((int64_t) ((c->out.request_written) - (request)) >= 0)' failed.
Abort (core dumped)
```
Within the same VNC session, glxgears does work, and glxinfo gives:
```auto
[me@machine]$ glxinfo | grep -i opengl
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 6.0, 256 bits)
OpenGL version string: 2.1 Mesa 18.0.5
OpenGL shading language version string: 1.30
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 18.0.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:
```
The same build of mrview seems to work nicely with VirtualGL on one of our other images (Ubuntu 16.04, NVIDIA GPUs, Nvidia driver version 390.30, mesa version 17.2.8, TurboVNC v2.1), but not on a third image (Scientific Linux 6.5, NVIDIA GPUs, Nvidia driver version 340.65, mesa 10.1.2, TurboVNC v1.2.2).
I was wondering whether anyone could offer any advice on getting software rendering to work? As I understand it, Mesa 18.0.5 should support OpenGL 3.3, but could there be some specific limitation in the version of swrast\_dri.so we’re using?
Thanks very much for reading, any advice would be much appreciated.
---
### Author:  [@jdtournier](https://community.mrtrix.org/u/jdtournier)
#### Post date: [August 8, 2019, 3:34pm UTC](https://community.mrtrix.org/t/opengl-software-rendering-and-vnc/2728/2 "2019-08-08T15:34:11Z")
Unfortunately, this is a longstanding issue with no simple solution. We [describe the issue in some detail in the docs](https://mrtrix.readthedocs.io/en/3.0_rc3/troubleshooting/display_issues.html), and you will also find some discussion around possible workarounds on various posts here (e.g. [here](https://community.mrtrix.org/t/mrview-in-remote-server-and-opengl/2023/2) and [here](https://community.mrtrix.org/t/opengl-mrview-errors-rhel6-hpc/326/5)) and on the GitHub forum (e.g. [this one](https://github.com/MRtrix3/mrtrix3/issues/1398)).
In your particular case, the issue is that the GL version is not supported, most likely because it’s trying to use GLX and GLX doesn’t (as far as I know) support OpenGL \>= 3. These are the relevant lines:
```auto
WARNING: Application calling GLX 1.3 function "glXCreatePbuffer" when GLX 1.3 is not supported! This is an application bug!
mrview: [INFO] GL renderer: llvmpipe (LLVM 6.0, 256 bits)
mrview: [INFO] GL version: 2.1 Mesa 18.0.5
mrview: [INFO] GL vendor: VMware, Inc.
mrview: [WARNING] unable to determine OpenGL version - operation may be unstable if actual version is less than 3.3
```
For the record, `mrview` will attempt to run anyway regardless of these errors since in some cases, things seem to work despite the system reporting versions that shouldn’t work…
I’ve not been able to figure out the criteria that would allow `mrview` to run over a regular X11 remote rendering connection – even though I have seen it work. I think it’s dependent not just on the version of `mesa` installed on the remote system, but also what’s installed on the local system, and whether it determines that it can perform (software) rendering on the remote server or if it tries to use a more standard GLX connection with rendering on the local system (which won’t work AFAIK).
I wish I had a better understanding of these issues… But in the meantime, I’m hoping that [Wayland](https://wayland.freedesktop.org/) will eventually make all these problems disappear (although it might be a while before we get there…).
---
### Author:  [@rusty](https://community.mrtrix.org/u/rusty)
#### Post date: [August 27, 2019, 5:28pm UTC](https://community.mrtrix.org/t/opengl-software-rendering-and-vnc/2728/3 "2019-08-27T17:28:29Z")
Apologies it’s taken me so long to reply, I just wanted to say thanks very much for your comments, and for the links to additional information. The way the various parts of the OpenGL stack interact is pretty opaque to me, so any anything that sheds any light is very welcome.
Interestingly, the error message we get seems to suggest we’re using GLX \< 1.3, while glxinfo suggests we’re using GLX 1.4 (the same version available to the setup that does work), although GLSL is limited to 1.3 on the system that doesn’t work:
On Centos 7 (doesn’t work):
direct rendering: Yes
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL renderer string: llvmpipe (LLVM 6.0, 256 bits)
OpenGL version string: 2.1 Mesa 18.0.5
OpenGL shading language version string: 1.30
Ubuntu 16.04 with vglrun (works):
direct rendering: Yes
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL renderer string: TITAN X (Pascal)/PCIe/SSE2
OpenGL version string: 4.6.0 NVIDIA 390.30
OpenGL shading language version string: 4.60 NVIDIA
It also looks like we’re using a version of llvmpipe that should support OpenGL 3.3 (e.g. [https://mesamatrix.net/#Version\_OpenGL3.3-GLSL3.30](https://mesamatrix.net/#Version_OpenGL3.3-GLSL3.30)), but perhaps the specific GLX extensions offered by the VNC server we’re using are the limiting factor.
Anyway, I would like to try and understand how it all fits together a bit better, but for now I think I’ll take your advice and steer people towards vglrun and local installs of mrview!
Thanks again for your help
---
### Author:  [@shoeoffhead](https://community.mrtrix.org/u/shoeoffhead)
#### Post date: [June 9, 2020, 12:25pm UTC](https://community.mrtrix.org/t/opengl-software-rendering-and-vnc/2728/4 "2020-06-09T12:25:54Z")
How and at what point does TurboVNC “decide” if it can use hardware acceleration or use the software llvm-pipe OpenGL fallback? Can one convince/force TurboVNC to attempt hardware acceleration?
Can you shortly describe how to best use VirtualGL or link to a good intro?