# Remote display issues

**URL:** <https://community.mrtrix.org/t/remote-display-issues/2547>\
**Category:** Wiki\
**Tags:** mrview, opengl\
**Created:** [May 23, 2019, 4:46pm UTC](https://community.mrtrix.org/t/remote-display-issues/2547 "2019-05-23T16:46:44Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\
**Post date:** [May 23, 2019, 4:46pm UTC](https://community.mrtrix.org/t/remote-display-issues/2547/1 "2019-05-23T16:46:44Z")

</div>

The GUI components in _MRtrix3_ (`mrview` & `shview`) use the OpenGL 3.3 API to make full use of modern graphics cards. Unfortunately, X11 forwarding is not officially supported for OpenGL \>= 3. So it is in general not possible to use `mrview` or `shview` over a standard remote X11 connection. However, some users have reported success in running these applications remotely – see the note below.

There are a number of reasons for the lack of official OpenGL 3.3 remote rendering support:

- OpenGL 1 & 2 used the [OpenGL fixed function pipeline](https://www.opengl.org/wiki/Fixed_Function_Pipeline) (now deprecated), whereas OpenGL \>= 3 relies much more explicitly on [shaders](https://www.opengl.org/wiki/Shader) and [buffer objects](https://www.opengl.org/wiki/Buffer_Object). Amongst other things, the use of buffer objects implies that potentially very large amounts of data be downloaded onto the GPU. In a X11 forwarding context, this would mean transferring these data over the network, which would probably end up being prohibitively slow in a sufficient number of situations that including support for it into the [GLX](http://en.wikipedia.org/wiki/GLX) was not thought to be worth the effort.

- X11 is unbelievably outdated, even according to the [X.org](http://www.x.org/wiki/) developers themselves (as very clearly explained in [this `linux.conf.au` talk](https://www.youtube.com/watch?v=RIctzAQOe44)). Current development efforts are going into its replacement, [Wayland](http://wayland.freedesktop.org/), which will start replacing X11 in earnest over the next few years (it’s already available and usable on the latest distributions). Thankfully, remote display capability is planned for Wayland, and [support for it has already been added](http://www.phoronix.com/scan.php?page=news_item&px=MTM0MDg).

### Note:

Some users have reported successful remote rendering over X11 connections. However, it’s proved difficult to replicate across systems, most likely because it will depend on both ends of the connection providing the right features. We expect this will only work using the open-source [Mesa 3D graphics library](https://www.mesa3d.org/intro.html) drivers (they provide OpenGL 3.3 support as of version 10.x), most likely using their [Gallium llvmpipe software rasteriser](https://www.mesa3d.org/llvmpipe.html). This means that if it works, the connection will _not_ support hardware acceleration, and will most likely perform all its rendering on the remote system.

However, there is very little documentation around this, and as previously noted, we are unsure of the correct settings required to get this work. We welcome user insights on the topic!

### Why does _MRtrix3_ use OpenGL 3.3 if it come with such limitations?

Because it’s clearly the most future-proof option. The [older OpenGL versions are deprecated](https://www.opengl.org/wiki/Fixed_Function_Pipeline), and not recommended for modern applications. The OpenGL 3.3 API is much closer to the way modern graphics hardware works, and can therefore provide better performance. Finally, as explained above, X11 will eventually be phased out anyway…

### What can be done about this?

There are a number of options available to deal with this, each with their own idiosyncraties. The simplest is to render locally (option 1), the other options require a fair bit of setting up on the server, and potentially also on the clients.

#### 1. Use MRView locally

This is the simplest option, and allows the use of the local graphics hardware (much like X11 forwarding would have). To use this relatively seamlessly, the simplest option is to access the remote data using a network filesystem, such as [SSHFS](http://en.wikipedia.org/wiki/SSHFS), [SMB](http://en.wikipedia.org/wiki/Server_Message_Block) or [NFS](http://en.wikipedia.org/wiki/Network_File_System), and run `mrview` locally, loading the data from the network share. While this may seem inefficient, bear in mind that _MRtrix3_ will typically only load the data it needs to, so operation will probably not be slower than it would have been with the MRtrix 0.2.x version. Besides, the largest data files are likely to be track files (which will need to be loaded in their  
entirety); in the MRtrix 0.2.x version these needed to be streamed in whole over the network _for every screen update_.

Of the networked filesystems listed above, the simplest to use would probably be [SSHFS](http://en.wikipedia.org/wiki/SSHFS), since it shouldn’t require any additional setup on the server (assuming users already have an SSH account), and is readily available on all platforms (using [Win-SSHFS](https://code.google.com/p/win-sshfs/) on Windows, [OSXFuse](http://osxfuse.github.io/) on MacOSX).

#### 2. Use an OpenGL-capable VNC server

Using the [VNC protocol](http://en.wikipedia.org/wiki/Virtual_Network_Computing), the server is responsible for doing all the rendering remotely, and sends the resulting screen updates over the network. With this approach, users are presented with a full-blown desktop environment running on the server. This may consume too many resources on the remote server, depending on the desktop environment used. Also, since rendering is performed on the remote server, it needs to be equipped with an OpenGL 3.3 capable graphics stack - this means decent hardware _and_ an up to date driver. However, it has the advantage of being widely supported and readily available on all platforms, with many implementations available. The only tricky part here is ensuring the VNC server is OpenGL-capable. As far as I can tell, [x11vnc](http://www.karlrunge.com/x11vnc/) can be used for this.

#### 3. Use VirtualGL to allow OpenGL forwarding within X11

The [VirtualGL project](http://www.virtualgl.org/) offers a means of rendering OpenGL graphics on the remote server, and sending the updated contents of the OpenGL window to the local display, alongside the normal X11 connection. This provides a means of running `mrview` in a potentially more familiar X11 over SSH session. As with the VNC solution, rendering needs to be performed on the remote server, meaning it needs to be equipped with an OpenGL 3.3 capable graphics stack - this means decent hardware _and_ an up to date driver. Also, it requires the installation of additional software on the local system. Finally, for this to work, all OpenGL commands need to be prefixed with `vglrun`  
(not particularly problematic as this can be scripted or aliased). This has been reported to work well with _MRtrix3_.

---

<div class="post-metadata">

**Author:** ![jingleil](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jingleil/32/2661_2.png) [@jingleil](https://community.mrtrix.org/u/jingleil)\
**Post date:** [June 16, 2020, 7:57am UTC](https://community.mrtrix.org/t/remote-display-issues/2547/2 "2020-06-16T07:57:16Z")

</div>

Hi all  
I strongly recommend mobaxterm for the remote display of “mrview”. [https://mobaxterm.mobatek.net/](https://mobaxterm.mobatek.net/)  
It supports openGL which is required by mrview. I tested it on my windows machine and it works super well.

Best,  
Jinglei

---

<div class="post-metadata">

**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\
**Post date:** [June 16, 2020, 9:27am UTC](https://community.mrtrix.org/t/remote-display-issues/2547/3 "2020-06-16T09:27:42Z")

</div>

Yes, software rendering seems to work on modern versions of mesa (which I assume these projects are built on). I’ve just successfully remote-rendered over X11 between my work and home Linux desktops, both running very current versions of `mesa`. But the limitation there is software-only rendering, and volume rendering doesn’t seem to work.

Also, this configuration requires that both the local workstation and the remote server have modern versions of mesa installed, otherwise it won’t work (as far as I know)…

---

<div class="post-metadata">

**Author:** ![suren](https://community.mrtrix.org/user_avatar/community.mrtrix.org/suren/32/3215_2.png) [@suren](https://community.mrtrix.org/u/suren)\
**Post date:** [November 19, 2021, 7:18am UTC](https://community.mrtrix.org/t/remote-display-issues/2547/4 "2021-11-19T07:18:45Z")

</div>

Hello,

Yes, it works fine. If you are working on remote computers with super computers at another location. We use modules. So,

module load mesa/gnu/18.3.4  
module load mrtrix  
mrview

This gives a nice little mrview GUI, works well.

Volume rendering is little unhappy with this, though 😅

Many Thanks,  
Suren

---

<div class="post-metadata">

**Author:** ![Travis\_Beckwith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/travis_beckwith/32/3698_2.png) [@Travis\_Beckwith](https://community.mrtrix.org/u/Travis_Beckwith)\
**Post date:** [February 4, 2022, 8:17am UTC](https://community.mrtrix.org/t/remote-display-issues/2547/5 "2022-02-04T08:17:20Z")

</div>

Hi,

I just installed MRtrix on WSL and was having similar issues. I was able to get mrview to work using VcXsrv, checking Clipboard and Disable Access Control, not checking the Native opengl, and running

export LIBGL\_ALWAYS\_INDIRECT=

before starting mrview.

---

<div class="post-metadata">

**Author:** ![RobbieTheK](https://community.mrtrix.org/user_avatar/community.mrtrix.org/robbiethek/32/4378_2.png) [@RobbieTheK](https://community.mrtrix.org/u/RobbieTheK)\
**Post date:** [July 25, 2023, 5:02pm UTC](https://community.mrtrix.org/t/remote-display-issues/2547/6 "2023-07-25T17:02:22Z")

</div>

> [@suren](#):
>
> module load mesa/gnu/18.3.4

Any chance you could share your modulefile? What environment variables from mesa is mrtrix looking for?

I combined the Mesa SDK to load together in this file:

```auto
#%Module -*- tcl -*-
##
## modulefile
##
proc ModulesHelp { } {

  puts stderr "\tAdds mesa 23.05.1 to your environment variables,"
}

module-whatis "adds mesa 23.05.1 to your environment variables"

set root /path/to/mesa/mesa-r23.05.1
prepend-path PATH $root/binary
setenv MESASDK_ROOT /path/to/mesa/sdk23.7.3/mesasdk
setenv OMP_NUM_THREADS 2 
setenv MESA_DIR /path/to/mesa/mesa-r23.05.1
prepend-path PATH /path/to/mesa/sdk23.7.3/mesasdk/bin/
prepend-path MANPATH /path/to/mesa/sdk23.7.3/mesasdk/share/man/
setenv PGPLOT_DIR /path/to/mesa/sdk23.7.3/mesasdk/lib/pgplot
if { [module-info mode load] } {
system "source /path/to/mesa/sdk23.7.3/mesasdk/bin/mesasdk_init.sh"
}

```

I get this error:

```auto
QOpenGLWidget: Failed to make context current

QOpenGLShaderProgram: could not create shader program

QOpenGLShader: could not create shader

Could not link shader program:

""

mrview: [SYSTEM FATAL CODE: SIGSEGV (11)] Segmentation fault: Invalid memory access

```