Running OpenGL apps
How 3D apps render here, which path suits which app, and what to do when one refuses to start.
On this page 3 sections
OpenGL apps work. There are two ways they can render, and which is better depends on the app.
The two paths#
| Path | OpenGL version | Good for |
|---|---|---|
| CPU (the default) | 4.5 | Anything, including apps needing newer OpenGL. Slower for heavy 3D. |
| GPU (opt in) | 4.1 | Apps that stay at 4.1 or below and want the speed. |
The CPU path is software rendering — correct, complete, and slow in proportion to how much the app draws. The GPU path sends OpenGL to your Mac's real graphics hardware, and is capped at OpenGL 4.1 by the Mac side of it.
Turning the GPU path on at all is GPU acceleration for OpenGL in Experimental Features. Individual apps can override it from their right-click menu, which is how you keep one app on the CPU while everything else uses the GPU.
Checking what an app is getting#
From a terminal in the instance:
glxinfo | grep -E "OpenGL (vendor|renderer|version)"A renderer naming llvmpipe is the CPU path. Anything else is the GPU path. glxgears is the quickest way to see whether GL works at all.
If glxinfo is missing, install mesa-utils.
When an app will not start#
| It says | Try |
|---|---|
| Unsupported hardware, or needs OpenGL 4.2 or newer | Put that app on the CPU |
| Cannot open display | Check the Graphics gate on the Sandbox tab |
| Nothing, and exits immediately | Launch it from a terminal to see its own message |
| Lost connection to rendering server | The GPU renderer is not reachable; use the CPU |
Launching from a terminal in the instance is worth doing early. A Linux app that fails on startup almost always says why, and that message never reaches the Mac side.