GLMakie on Raspberry Pi 400

General Usage
, ,
1

I recently installed julia 1.6.7 on a Raspberry Pi 400 computer as that was
what was available from julialang.org 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?

Thanks,
Chris

2

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.
3

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
4

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
5

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.

6

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.

7

I have an application that does use GLMakie that I am trying to use on the RPi 4 8GB. It is complaining that it will not compile. Doing some reading I found a reference that claims to make it work. They seem to prefer Manjaro Arm or Ubuntu for the PI, I am running the latest 64 bit RPi OS, Bookworm.

I am wondering if anyone has tried this out for any OS on the Pi and what their experience is. I am particularly interested in whether someone has made it work for the Raspberry Pi OS.

8

You could try first to get WGLMakie runnning, to see if there’s any basic problems without OpenGL.
It might be the better solution in any case, since the opengl acceleration on the PI wont be great even if you get it running.

9

FYI: I tried WGLMakie and it still ended up needing OpenGL which
still had the version 3.3 support issues and I was back to software
rendering.

10

Uh that’s weird, can you show what you tried and the exact error?

11

I don’t have access to that platform at the moment.

I remember trying to add WGLMakie and then it seemed to be pulling
in whatever required the OpenGL 3.3 acceleration again.

Everything is a moving target hardware and software-wise.
I’m sorry I cannot be of more help. -chm

12

95% sure WGLMakie shouldn’t pull in any OpenGL related things, so I think it must be something with the environment…
Maybe Electron somehow got in there? But I would think that will only start erroring once you start Electron.
Or did you maybe also had GLMakie in the repository? That already needs OpenGL while precompiling…

13

I just tried opening a new project on the RPi and doing the following:

using WGLMakie
x = 0:pi/8:4pi
y = sin.(x)
lines(x,y)

The first time through it gave a

MethodError: no method matching wait_for_ready(:Nothing)

The second time I tried lines(x,y) it plotted in the browzer.

I tried CairoMakie as well and it errored when using CarioMakie was called. A second invocation and it didn’t error and plotted successfully.

Trying GLMakie did not work.

14

Some more experimenting… I have Firefox set up as the default browzer for the Pi. When I execute the 'lines(x,y)` statement, Julia will hang if the browzer is not already up on the desktop. If it is already up on the desktop there is no problem. The same problem does not exist if I make Chromium the default browzer.

Neither browzer shows the numbers on the x or y axis with WGLMakie.