# GLMakie on Raspberry Pi 400
**URL:** https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401
**Category:** General Usage
**Tags:** raspberry-pi, glmakie, opengl
**Created:** [June 29, 2024, 9:06pm UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401 "2024-06-29T21:06:21Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@devel-chm](https://discourse.julialang.org/u/devel-chm)
#### Post date: [June 29, 2024, 9:06pm UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/1 "2024-06-29T21:06:21Z")
I recently installed julia 1.6.7 on a Raspberry Pi 400 computer as that was
what was available from [julialang.org](http://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
---
### Author:  [@devel-chm](https://discourse.julialang.org/u/devel-chm)
#### Post date: [June 30, 2024, 3:22pm UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/2 "2024-06-30T15:22:31Z")
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.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [June 30, 2024, 3:30pm UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/3 "2024-06-30T15:30:40Z")
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.
---
### Author:  [@devel-chm](https://discourse.julialang.org/u/devel-chm)
#### Post date: [June 30, 2024, 3:38pm UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/4 "2024-06-30T15:38:46Z")
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.
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [July 1, 2024, 2:48pm UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/5 "2024-07-01T14:48:36Z")
Possible workarounds:
1. [Install Vulkan on Raspberry Pi 4 - Q-engineering](https://qengineering.eu/install-vulkan-on-raspberry-pi.html)
This Makie backend might then work, mostly made for AMD/ray-tracing but not just:
> **[RPRMakie | Makie](https://docs.makie.org/stable/explanations/backends/rprmakie)**
>
> Create impressive data visualizations with Makie, the plotting ecosystem for the Julia language. Build aesthetic plots with beautiful customizable themes, control every last detail of publication quality vector graphics, assemble complex layouts and...
> - `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](https://doc.qt.io/archives/qt-4.8/opengl-module.html) ES is missing the immediate mode and does not support quads, we have to create triangle arrays.
---
### Author:  [@devel-chm](https://discourse.julialang.org/u/devel-chm)
#### Post date: [July 1, 2024, 4:14pm UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/6 "2024-07-01T16:14:48Z")
> [@Palli](#):
>
> Possible workarounds:
>
> 1. [Install Vulkan on Raspberry Pi 4 - Q-engineering](https://qengineering.eu/install-vulkan-on-raspberry-pi.html)
>
> This Makie backend might then work, mostly made for AMD/ray-tracing but not just:
> …
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.
---
### Author:  [@Jake](https://discourse.julialang.org/u/Jake)
#### Post date: [September 5, 2024, 9:56pm UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/7 "2024-09-05T21:56:41Z")
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](https://www.noasakurajin.de/opengl-core-on-raspberry-pi-4/) 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.
---
### Author:  [@sdanisch](https://discourse.julialang.org/u/sdanisch)
#### Post date: [September 6, 2024, 8:21am UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/8 "2024-09-06T08:21:51Z")
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.
---
### Author:  [@devel-chm](https://discourse.julialang.org/u/devel-chm)
#### Post date: [September 6, 2024, 12:36pm UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/9 "2024-09-06T12:36:09Z")
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.
---
### Author:  [@sdanisch](https://discourse.julialang.org/u/sdanisch)
#### Post date: [September 6, 2024, 12:38pm UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/10 "2024-09-06T12:38:27Z")
Uh that’s weird, can you show what you tried and the exact error?
---
### Author:  [@devel-chm](https://discourse.julialang.org/u/devel-chm)
#### Post date: [September 6, 2024, 1:36pm UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/11 "2024-09-06T13:36:44Z")
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
---
### Author:  [@sdanisch](https://discourse.julialang.org/u/sdanisch)
#### Post date: [September 6, 2024, 1:42pm UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/12 "2024-09-06T13:42:42Z")
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…
---
### Author:  [@Jake](https://discourse.julialang.org/u/Jake)
#### Post date: [September 6, 2024, 11:36pm UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/13 "2024-09-06T23:36:52Z")
I just tried opening a new project on the RPi and doing the following:
```julia
using WGLMakie
x = 0:pi/8:4pi
y = sin.(x)
lines(x,y)
```
The first time through it gave a
```julia
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.
---
### Author:  [@Jake](https://discourse.julialang.org/u/Jake)
#### Post date: [September 7, 2024, 1:07am UTC](https://discourse.julialang.org/t/glmakie-on-raspberry-pi-400/116401/14 "2024-09-07T01:07:47Z")
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.