GLMakie on Raspberry Pi 400

I recently installed julia 1.6.7 on a Raspberry Pi 400 computer as that was
what was available from downloads.

When I tried to install GLMakie which is my preferred plotting program, it
failed at precompile. The error was that OpenGL 3.3 was not available for
the RPi 400 platform.

I was able to force using the software Mesa rendering and successfully
use GLMakie. However, it is very slow and won’t work for the live update
application that I am working on.

I see from some discussion on the rpi web sites that there has been work
to get OpenGL 3.3 running on the RPi 4 family (including the RPi 400).
I had some questions:

  1. What specific features from OpenGL 3.3 versus OpenGL 3.2 are needed?
    It seems like EGL is becoming a more common standard for OpenGL-type
    functionality. Is there a way to substitute that for OpenGL?
  2. Has anyone successfully gotten GLMake working for the RPI?
  3. I’ve seen WGLMakie suggested but did not want to change platforms and
    API support if it is not needed. Anyone have luck with this approach?


I was able to install julia-1.10.4 and julia-1.11.0-rc1 on my raspberry pi 400:

  • I had to increase the swap file size. 2000MB seems to work.
    A size of 1000MB barely made it but I had to close my browser
    to avoid running out of memory.
  • Ran julia with the environment variable LIBGL_SOFTWARE_ALWAYS=1
    and everything thing built (with julia-1.11.0-rc1)
  • Software rendering is slow but the 64-bit OS version is a bit more zippy
    that my previous experience with julia-1.6.7 and the 32-bit Raspberry OS.

Did you try zram? You can also combine it with swap, but according to my experience it is much faster then swap if you just need an extra 50% of RAM.

1 Like

Thanks for reminding me. I was planning on adding it in to the
mix. Nice to hear about the better performance!

Unfortunately, the sticking point at the moment is getting the OpenGL 3.3
for hardware acceleration in plotting.

1 Like

Possible workarounds:

  1. Install Vulkan on Raspberry Pi 4 - Q-engineering

This Makie backend might then work, mostly made for AMD/ray-tracing but not just:

  • RPR.Hybrid: Vulkan backend, fit for real time rendering, using AMDs and NVIDIAs new hardware accelerated ray tracing. Doesn’t work reliably yet and only works with RPR.Uber material.
  • RPR.HybridPro: The same as Hybrid, but works only for Radeon GPUs, using AMDs own hardware acceleration API.

[I would be very curious to know if this works for you, but it’s not ideal since only at best for Pi 4/400, not older.]

  1. I believe you already got CairoMakie to work. It only supports 2D, and with same API I believe. GLMakie and the other support 2D too, but additionally 3D, well seemingly what you want. There are also other non-Makie plotting options giving 3D (these Plots.jl backends, or using them directly “GR, PythonPlot, Plotly(JS), Gaston”). Might work for you, possibly better/not as hardware demanding code. Makie is seemingly the future, thus ideally it would work for all hardware…, with some of its backends. What’s your reason for wanting GLMakie? I see it’s supported by Mousetrap.jl (its only 3D/Makie option?).

  2. Is there a possible OpenGL-to-OpenGL ES adapter available? Software based, I think there might, not though sure about for the Pi. Or to Vulkan for option 1.

  3. Port GLMakie to OpenGL ES. I’m not sure how easy.

Porting OpenGL to OpenGL ES

Since OpenGL ES is missing the immediate mode and does not support quads, we have to create triangle arrays.

Thanks for the ideas.

I’m looking for a lightweight, realtime, interactive graphics display with 2-D figures
and 3-D renderings. GLMakie was the only version that fit the requirements. I did
not think that the RPRMakie was relevant to the RPi-400 hardware.

As is, I’m stuck with the software rendering pipeline until OpenGL 3.3 support
is available for the RPi-400 or Makie targets some graphics API supported by the Pi.
Maybe OpenGL ES could be that option.