4

I am doing some work using Google Cloud Platform，that's to say I use ssh to login. When I run a script(mayavi/test_drawline.py) from others, it tells me:

ERROR: In /work/standalone-x64-build/VTKsource/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 797 vtkXOpenGLRenderWindow (0x3987b00): GL version 2.1 with the gpu_shader4 extension is not supported by your graphics driver but is required for the new OpenGL rendering backend. Please update your OpenGL driver. If you are using Mesa please make sure you have version 10.6.5 or later and make sure your driver in Mesa supports OpenGL 3.2.

So I think I need to up upgrade my mesa. Before that, the glxinfo shows:

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL version string: 1.4 (2.1 Mesa 10.5.4)

I followed the instruction from How to upgrade mesa, but the glxinfo didn't change.

And I tried to compile Mesa from source code. So I followed the instruction from Mesa official website Compiling and Installing. I use Building with autoconf (Linux/Unix/X11). All things are OK, it seemed that I have installed the newest Mesa.

However, when I run glxinfo| grep version again, it still like this:

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL version string: 1.4 (2.1 Mesa 10.5.4)

I have tried reboot, but it doesn't work.

So, does anyone know how to solve it?

Thank you!

Tron Li
  • 43
  • 1
  • 4
  • _where_ did you install mesa? Client or server? And what are you using? – derhass Aug 12 '18 at 12:06
  • I install it on the server. I need a tool named mayavi, which needs a higher edition of mesa on my Google Cloud Platform VM. I just want to use the mayavi to do some visualization task on my server and show the result on my local machine via ssh-X – Tron Li Aug 12 '18 at 19:34
  • @TronLi: `ssh -X` will always redirect *all* X11 traffic, including OpenGL to your local machine. If you're doing visualization work on a remote machine this is hardly what you want. Worst case *all* OpenGL asset data (textures, buffer objects, etc.) is transmitted over the SSH connection as raw data. SSH may apply some compression to it, but if you're visualizing a – say – 1GB volumetric dataset this would pump 1GB of data over the Internet into your local machine to render there. If you want to render on the remote machine, you must not use forwarded GLX over X11. – datenwolf Aug 13 '18 at 16:55

1 Answers1

1

The OpenGL version reported depends on the available Mesa version only be second degree. You're reported GLX-1.4 and OpenGL-1.4 which is an absolute baseline version dating back over 15 years ago. So this is not a Mesa version problem.

What far more likely is, that you're trying to create a OpenGL context in a system configuration which simply can't do more than OpenGL-1.4 without resorting to software rendering. Now one reason for that could be, that you're connecting via SSH using X11 forwarding. In that case all OpenGL commands would be tunneled through the X11 connection (GLX) to your local machine and be executed there. However GLX is very limited in it's OpenGL version profile capabilities. Technically it's supporting up to OpenGL-2.1 (which is the last OpenGL version, that defines GLX transport opcodes for all its functions). But a given configuration might support less.

If the remote machine does have a GPU, you have to use that. A couple of years ago, this would have meant running a Xorg server there. Not anymore. With NVidia GPUs you can use headless EGL. With Intel and AMD GPUs you can also use headless EGL, or use GBM/DRI to create a headless GPU accelerated OpenGL context. Of course this requires a GPU being available on the remote end.

If you don't have a GPU on the remote site, you must use some software implementation. Which with Mesa unfortunately doesn't work with a forwarded X11 session. Your best bet would be running something like Xpra, or Xvnc (i.e. some kind of remote framebuffer), where the X server runs on the remote end, so that the GLX connection terminates there, and not on your local machine.

Or you somehow coax the program you're building to use OSMesa (Off-Screen Mesa), but that requires entirely different OpenGL context setup, entirely different from what's done with GLX, so your VTK application may not work out of the box with that.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • Thank you a lot. Your answer help me to understand how it works! Although I have a GPU on my remote machine, I am not familiar with the headless EGL. So I choose to install Xvnc. I follow the instruction on https://www.linode.com/docs/applications/remote-desktop/install-vnc-on-ubuntu-16-04/#secure-your-vnc-connection. then the error about OpenGL disappeared, but "Xlib: extension "XInputExtension" missing on display ":1"." came out...I am trying to solve it – Tron Li Aug 14 '18 at 01:32
  • @TronLi: Xvnc will not give you GPU acceleration. If you have a GPU your best bet is probably to run a regular Xorg server inside of Xpra (https://xpra.org/trac/wiki/Usage/OpenGL). Headless EGL requires modifications to the applications themself. – datenwolf Aug 14 '18 at 11:02
  • As I am not familiar with the X-server series, So I am not sure if the Xorg server inside of Xpra will solve the "Xlib" error. Speed doesn't matter much, as I cannot run the script now. If Xpra still has the same error, I may try to store my file into JPG to download and show on my local machine. – Tron Li Aug 14 '18 at 15:13