opengl info empty on a linux bux without display/X11 forwarding

I run matlab R2015b in a display-less linux environment and plotting 3D graphics to png files is painfully slow. I suspect this is because matlab is not using opengl, although this is installed on the machine.

If I ssh to the machine without X11 forwarding and I run matlab as

matlab -nodesktop -nosplash

and then view the opengl info in matlab I get:

>> opengl info

                          Version: ''

                           Vendor: ''

                         Renderer: 'None'

            RendererDriverVersion: ''

        RendererDriverReleaseDate: ''

                   MaxTextureSize: 0

                           Visual: ''

                         Software: 1

             HardwareSupportLevel: 'none'

        SupportsGraphicsSmoothing: 0

    SupportsDepthPeelTransparency: 0

       SupportsAlignVertexCenters: 0

                       Extensions: {}
               MaxFrameBufferSize: 0

If I enable X11 forwarding (ssh -X to the machine) I instead get:

>> opengl info

                          Version: '2.1 Mesa 7.2'

                           Vendor: 'Brian Paul'

                         Renderer: 'Mesa X11'

                   MaxTextureSize: 2048

                           Visual: 'Visual 0x4d, (RGBA 32 bits (8 8 8 8), Z depth 16 bits, Hardware acceleration, Double buffer, Antialias 0 samples)'

                         Software: 'true'

             HardwareSupportLevel: 'none (known graphics driver issues)'

        SupportsGraphicsSmoothing: 0

    SupportsDepthPeelTransparency: 1

       SupportsAlignVertexCenters: 0

                       Extensions: {114x1 cell}

               MaxFrameBufferSize: 4096

and plotting to png files is ~10-20x faster. If I clear the DISPLAY environment variable, I am back to the 'empty' opengl info and painfully slow plotting.

In the production environment I can not use X11 forwarding, so how can I make matlab use opengl plotting in a displayless environment ?

Answer 1

[Andrew Long]

I don't know if you've found a solution to this, but I've spent the last few days trying to compile different options because we have a very similar issue in our group. There seem to be two options to get around the getframe issue:

1) Use "print" function with the -RGBImage flag, returns a cdata array that is equivalent to frame2im(getframe)

2) Use Xvfb (X virtual frame buffer) to load a virtual X11 context for matlab to run in on your compute nodes (see this solution out of MSU: https://wiki.hpcc.msu.edu/pages/viewpage.action?pageId=19595894), requires Xvfb to be installed.

Here's some basic timings to get an idea how these vary (only timing the saving png file phase).

Test system: plot(rand(5000));

• no x11 window (blank opengl) - saveas: 580s
• no x11 window (blank opengl) - print RGB: 348s
• X11 Xvfb (software opengl) - getframe: 107s
• X11 actual window (software opengl) - getframe: 33s

So Xvfb is 3-4x worse than an actual X11 window, but still quite a bit faster than just calling saveas. Print is pretty costly overall, but it does allow some speedup if you don't have access to Xvfb. As a side note: for Xvfb if you compute values and want them printed out to read in a log file, make sure to make a diary as all the matlab output will be pushed into that virtual X11 window (which will just disappear at the end).

Hope this helped,

Andy Long

[Robert Cadman]

The MSU web page referenced in this answer either has been taken down or is not accessible to outsiders.