# Blender on remote Linux machine via X server

I am trying to get Blender to start on a remote machine via an X11 session. I have tried this in the past (circa Blender 2.6 ~ 2.69) and it has worked without problems.

The Linux machine (VM Running Ubuntu 18.04.2 LTS) is setup with all necessary libraries. glxgears (and a set of other programs that I need) starts without any complaints but Blender fails.

The failure paths are as follows:

1. Install Blender via apt-get

• When you try to start it you get a segmentation fault.
2. Install Blender via a straight zip download from blender.org. In my case, blender-2.80rc1-linux-glibc218-x86_64.

• When you try to start it you get a bunch of error code: 1, request code: 143, minor code: 34, error text: BadRequest (invalid request code or no such operation) that conclude with:

Error! Unsupported graphics card or driver. A graphics card and driver with support for OpenGL 3.3 or higher is required.

• (Fair Enough)
• When you try to start blender-softwaregl (as I have been doing in the past), everything appears to be going well, you even get a window on the local machine titled "blender" but the errors are now error code: 159, request code: 143, minor code: 34, error text: 159 that conclude with:

Xlib: extension "MIT-SHM" missing on display "localhost:10.0".

• xdpyinfo reports 23 extensions enabled, none of which appears to be MIT-SHM. (BIG-REQUESTS, DAMAGE, DEC-XTRAP, DOUBLE-BUFFER, Extended-Visual-Information, GLX, MIT-SUNDRY-NONSTANDARD, RANDR, RECORD, RENDER, SECURITY, SGI-GLX, SHAPE, SYNC, TOG-CUP, X-Resource, XC-APPGROUP, XC-MISC, XEVIE, XFIXES, XInputExtension, XKEYBOARD, XTEST).

Is there an alternative way to get Blender running in this configuration that I may be missing here?

UPDATE 1:

Noticing that xdpyinfo does not make any reference to MIT-SHM when it lists extensions, I created a 20-enable_mit.conf in /usr/share/X11/xorg.conf.d with:

Section "Extensions"
Option "MIT-SHM" "Enable"
EndSection


I restarted the system but the extension is still not being reported by xdpyinfo.

Any ideas?

After quite a bit of trial and error, the latest version of Blender that can run through blender-softwaregl in the above mentioned configuration is 2.79.

There is nothing in the changelog of 2.79 or 2.80 to indicate any sort of reason for this.

Update:

The short answer seems to be that it is impossible to run Blender 2.80 over XDMCP in the described setup.

The longer answer is that Blender makes use of an X11 extension that is only effective when both the "client" and the "server" are running on the same machine.

In the client-server architecture, a process connects to another process and asks it to carry out tasks for it. This communication is governed by a strict "language" (the protocol). Usually, you don't think twice about who is the "client" and who is the "server". For example, internet browsers are clients to web servers and they exchange information over HTTP.

In the X Window System, the machine that should be considered as "the server", is the machine that shares its resources. As there can be only one mouse, keyboard, actual video output and so on, the server is the one process that "talks to them" and manages access of other processes.

This is where it might get a bit confusing. The typical way by which access is gained to a remote machine is through a Secure Shell connection.

This implies that the machine we are trying to connect to is running a Secure Shell Server and the connection is initiated by a Secure Shell client such as ssh in Linux or putty in Windows and others.

After authentication, we might try to start an application with a Graphical User Interface.

To do this, in this setup, the computer that executes the SSH client, needs to also be running an X11 server (the machine that provides the actual resources is not the one that is running the SSH server / Blender).

So, the complete round trip starts with the SSH Client (e.g. putty), connecting to the SSH Server, the user starts a piece of software (e.g. Blender) that uses the X Window Manager, it, in turn attempts to connect to a "display" server and initiates a connection back to the X Server that runs on the same machine that initiated the SSH connection (e.g. to something like XMing).

The end result of this is that the client process (Blender) does not run in the same memory space as the server process.

The MIT-SHM extension is an interprocess communication mechanism for the two communicating processes to share large amounts of memory.

When the extension is supported, the client might reserve a memory space through a "special" set of calls which ensures that another process (the X Server) has access to it too. This is to make the main connection less data heavy (and therefore faster). Instead of sending a huge amount of data over the connection, the processes might simply exchange the "handle" of the memory space which is just a number.

This makes sense for a heavy application such as Blender.

The XMing server does not support the MIT-SHM extension. This is the reason behind this specific error.

Even if the XMing did support the MIT-SHM, the client and server processes would run in different memory spaces and therefore this "handle" from one machine would not make sense to a different machine. This is why it is impossible to run Blender 2.80 under this setup.

Any attempt to force that feature off or circuimvent it would imply getting data from one machine to the other via the network (in one or another form), at which point, it would probably be equivalent to running Blender via VNC (if you can) where everything runs on the remote machine and the output is streamed back to the local machine.

Hope this helps.

Notes:

1. An X Server and an X Client are communicating via XDMCP

2. There are a few ways of trying to circumvent this MIT-SHM "limitation", but they basically imply running an X Server at the remote machine at which point, that remote machine would have to handle software rendering for Blender and streaming of the output. This is outside my use case and have not looked into it further but you are probably better trying to do this via a VNC type solution (if you can) rather than trying to "re-wire" X.

• I don't know if there are ways to solve this via Distributed Shared Memory in Linux, but again even if it was possible (without starting a local X Server), the data that are supposed to be travelling between the two processes via the MIT-SHM would now have to travel over the network which, in the case of remote machines, is not going to happen faster than a VNC type connection.

Everything below was working fine until Blender >=2.80, which crashes on exit, but seems to work well except this. With Blender 2.80 or 2.81, you need blender-softwaregl. Note that I'm only doing some scripting, so I'm not testing everything.

TLDR: use TurboVNC, it can provide OpenGL acceleration

Base OS is Centos 7, minimal install.

Install some X stuff, maybe everything is not required

yum install -y xorg-x11-server-Xorg xorg-x11-xauth xorg-x11-server-utils mesa-dri-drivers mesa-libGLU libXi libXrender xorg-x11-server-Xvfb xorg-x11-utils


Install turbovnc

curl -L -o /etc/yum.repos.d/TurboVNC.repo https://turbovnc.org/pmwiki/uploads/Downloads/TurboVNC.repo
yum install -y turbovnc


Setup TurboVNC (if you want to connect directly, remove -nohttp and -localhost):

mkdir ~/.vnc
echo mypassword | /opt/TurboVNC/bin/vncpasswd -f > ~/.vnc/passwd
chmod 600 ~/.vnc/passwd
cat <<EOF > /etc/sysconfig/tvncservers
VNCSERVERS="1:myuser"
VNCSERVERARGS[1]="-geometry 800x600 -nohttpd -localhost"
EOF

systemctl start tvncservers


Now to run blender, you have to set the DISPLAY, and force OPENGL version beforehand

export DISPLAY=:1
export MESA_GL_VERSION_OVERRIDE=3.3
./blender-2.81-linux-glibc217-x86_64/blender
# or
# ./blender-2.81-linux-glibc217-x86_64/blender-softwaregl

• Thank you very much, given the specifics of my setup, I might have to modify some of these steps and this needs a bit of time to test it, glad to hear that there might be a way to get blender up and running this way, even if it is in somewhat "reduced" way. – A_A Dec 17 '19 at 9:52