Add official Linux ARM/Raspberry Pi editor and export template binaries

[Schweini07]

Bugsquad edit: You can use https://github.com/hiulit/Unofficial-Godot-Engine-Raspberry-Pi until official builds are provided.

---

The re-open of godotengine/godot#2671.

NOTE: This issue is more about Godot 3.2, as Godot 3.0.6 and 3.1 are possible to get on the pi, with the costs of a few bugs, for more information read below.

If you have anything to add, please tell me.

Takeaways:

• Godot 3 works on the Raspberry Pi 4 due to the support for GLES3
• A user named efornara got Godot 3.0.6/3.1 with GLES2 working on the Raspberry Pi 3 B+ trough compiling and other methods, see:
  Add official Raspberry Pi support godot#2671 (comment) (The error from compiling was apparently caused due to an upstream bug, see: Add official Raspberry Pi support godot#2671 (comment))
  Add official Raspberry Pi support godot#2671 (comment)
• There's a repo (https://github.com/efornara/frt) which let's the Pi support Godot 2.1/3.0/3.1 BUT not /3.2

Other interesting things I found:

• This website: http://raspbian.raspberrypi.org/raspbian/pool/main/g/godot/, which apparently has Godot 3.2 executables for the Pi
• On https://repology.org/project/godot/versions, there's also apparently Godot 3.2 listed as an official raspbian package, it's not marked Stable but as Testing.
• When you want to install Godot trough apt on the Pi you write apt install godot, Godot 3.0.6 gets installed, as it's apparently the stable package (see link above).
• Someone got export templates for Pi working on 2.1.4: https://github.com/crabcrabcam/godot/releases
• This post: https://www.reddit.com/r/godot/comments/af1cji/compiling_godot_31_for_raspberry_pi/, where someone made instructions, on how to compile Gdot 3.1.1 for the Pi

Describe the project you are working on:
Applies to any project made on a Pi.

Describe the problem or limitation you are having in your project:
It's hard perhaps even impossible, to get Godot 3.2 working on the Pi.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
It's hard to tell why Godot 3.2 doesn't work with Pis below 4. My assumption is that it has to do something with the missing GLES3 or because the Pi has an ARM processor (https://godotengine.org/qa/13114/export-godot-project-for-raspberry-pi). I think it could help to look into: https://github.com/efornara/frt

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
As I don't know the exact problems, I can't tell.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
A few lines of code probably won't do it, but Godot 3.2 is desired from Raspberry Pi users.

Is there a reason why this should be core and not an add-on in the asset library?:
It isn't possible.

[efornara]

As a clarification, FRT (export template) does support Godot 3.2. In fact, I have just noticed this proposal when publishing 3.2.2-beta4 (https://sourceforge.net/projects/frt/files/previews/). Godot 3.2.1-stable is still available (it is the default download).

The unmodified x11 platform of Godot 3.2 should work out of the box on a Pi 4 and, by changing the OpenGL system settings, on a Pi 2/3 too. You should add a compiler flag to select hard float when generating the binaries, and I think some people have problems when using GCC, but, apart from that, it should be fine.

[realkotob]

I've worked with godot 3.2 and 3.1 on the raspberry PI 3A and 3B+

It works pretty well for 2D.

However, even for 2D there are a lot of optimizations and graphical limitations that the user needs to do and figure out on their own.

I still think it would be useful to make an official RPI export template, and I would love to help to make it happen since it would be useful to a lot of users, but this can only happen after #877 is decided since RPI is considered a low-end platform.

Example limitations: Particles do not work at all, and there's a texture memory limit that means that it's better to load things as needed instead of loading everything into the scene at once (or else they will appear black ingame).

[antv199]

I found this Vulkan update for the Raspberry Pi. This might come in handy.

[dh928]

I've worked with godot 3.2 and 3.1 on the raspberry PI 3A and 3B+

It works pretty well for 2D.

However, even for 2D there are a lot of optimizations and graphical limitations that the user needs to do and figure out on their own.

I still think it would be useful to make an official RPI export template, and I would love to help to make it happen since it would be useful to a lot of users, but this can only happen after #877 is decided since RPI is considered a low-end platform.

Example limitations: Particles do not work at all, and there's a texture memory limit that means that it's better to load things as needed instead of loading everything into the scene at once (or else they will appear black ingame).

How did you get it to work on your pi 3B+?

[realkotob]

@dh928 You can use the FRT thing directly or use this thing which makes it run within RetroPie.

Note that some things are not supported, like particle effects or Websockets (but fortunately I used the other TCP option for multiplayer, so wasn't an issue since I changed 1 line).

[ShalokShalom]

Would be nice to find it here 🥳

[Calinou]

@ShalokShalom This can be handled by the Arch Linux ARM packagers already, just like other Linux distributions. This proposal is about distributing official, first-party ARM binaries for Linux. You'd download them on the Godot website just like x86 binaries.

[ShalokShalom]

Yeah, but getting in touch with the distros and actually coming up with a ready to go build script would not hurt the visibility of the project. In the end, its all about making the software available to the people. I could do that 😊

[nobody5050]

Bumping because this would be an awesome thing for godot to do and would also bring more users to the engine.

Edit: the newly released pi 400 is surely powerful to run godot without limitations.

[hiulit]

Hi everybody!

I'm writing from a Raspberry Pi 4 4GB where I successfully compiled all major versions (2.1.6, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.2.1, 3.2.2, 3.2.3 and also 3.2.4 beta 4) of Godot , both the editor and the export templates 🎉

I could't compile 3.0.6 because it doesn't support GLES3. I'm not sure if that's the cause, but I couldn't anyway.

I want to clarify that I'm not an expert at compilattion, architectures and all that stuff, but I'm tech-savy enough to understand them and tinker with them.

I'll try to explain how I did it, what is working and what is not.

But first of all, I want to credit all the sources where I got the information from:

• @efornara 's FRT project.
• @w84death 's "Raspberry Pi 4 as Perfect Indie Console" blog post.
• Raspberry Pi GCC Toolchains.

How I compiled Godot (X11) for the Raspberry Pi

• I followed the official documentation about Compiling for X11 (Linux, *BSD) to install all the dependencies (Debian/ubuntu).
• Then for the scons parameters and flags I used:
  • @efornara 's: scons platform=x11 target=release_debug tools=yes use_llvm=yes CCFLAGS="-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -mlittle-endian -munaligned-access" -j4.
  • @w84death 's: scons platform=x11 target=release_debug tools=yes use_llvm=yes CCFLAGS="-mtune=cortex-a72 -mcpu=cortex-a72 -mfloat-abi=hard -mfpu=neon-fp-armv8" -j4.
  • A mix of @efornara 's and @w84death 's: scons platform=x11 target=release_debug tools=yes use_llvm=yes CCFLAGS="-mtune=cortex-a72 -mcpu=cortex-a72 -mfloat-abi=hard -mlittle-endian -munaligned-access -mfpu=neon-fp-armv8" -j4
  • The one from Raspberry Pi GCC Toolchains: scons platform=x11 target=release_debug tools=yes use_llvm=yes CCFLAGS="-march=armv8-a -mfloat-abi=hard -mfpu=neon-fp-armv8" -j4

For all I can tell, they all seem to work the same.

I don't know the differences between all those flags, but I found the GCC ARM Options site where all those options all explained.

As you can see, all the binaries are compiled using Clang.
GCC is suposed to be better (?), so I also compiled a version using GCC (without lto) to compare it with the Clang version and it seems to performe the same as the Clang binaries.
I could't compile using GCC with lto because it's very RAM consuming and apparently my Raspberry Pi run out RAM.

Editor (IDE)

The only versions that work perfectly are 2.1.6 and 3.2.4 beta 4.

I'm guessing that 2.1.6 works well because it's less demanding (?).
And for 3.2.4 beta 4, it seems that it woks great because of the amazing job the Godot team has done with the GLES2 batching.

All the versions inbetween are very laggy, at least when run at fullscreen (1920x1200). If the editor window is smaller, at between ~1/2 and ~1/3 of that resolution, it performs correctly. I guess if all the new batching features were ported back to those versions they would work perfectly as well.

Here's a comparison example between 3.2.3-stable and 3.2.4 beta 4.

Export templates

All versions seem to work fine.

Conclusions

I think, at least with the Raspberry 4, that it's worth investing the time on adding official support for it. If not for the editor, at least for the export templates.

I can't speak for other ARM single-board computers, but I can speak for the Raspberry Pi 4 and I think it's a perfectly capable device to be used for developing a 2D game.

The Raspberry Pi 4 is the most known single-board computer and it's reasonably priced, even cheap, if I might add.

Giving support to it would give a lot of people who can't afford high-end computers to be able to develop games.

Also, the Raspberry Pi is well know for being an emulation/gaming device and having the ability to play Godot games on it would be great for exposure.

[Calinou]

I could't compile using GCC with lto because it's very RAM consuming and apparently my Raspberry Pi run out RAM.

To compile an LTO-enabled build, you'll need a Raspberry Pi with 8 GB of RAM and lots of patience, or cross-compile the ARM binary from another machine with at least 8 GB of RAM.

[hiulit]

I could't compile using GCC with lto because it's very RAM consuming and apparently my Raspberry Pi run out RAM.

To compile an LTO-enabled build, you'll need a Raspberry Pi with 8 GB of RAM and lots of patience, or cross-compile the ARM binary from another machine with at least 8 GB of RAM.

Do you think that compiling with lto we would see noticeable improvements, performance-wise? Is it worth trying?

[Calinou]

Do you think that compiling with lto we would see noticeable improvements, performance-wise? Is it worth trying?

On x86, it makes the Godot binary 20-25% smaller and about 20-25% faster as well. I think it's very much worth it, but the performance gains may be different on ARM.

[efornara]

The official export templates (x11) work well on a Raspberry Pi 3 too. Today. Latest stable Godot release.

I am not complaining too much about a few additional stars and downloads that FRT is getting, but, really, most people who download FRT would be better served by downloading an official yet unsupported export template for Raspberry Pi 3/4.

In my opinion, at this point, FRT should become a niche "port", downloaded mostly by people targeting Raspberry Pi Zero, Raspberry 2/3 with Legacy driver or platforms where you have to use KMS/DRM (and possibly Wayland, if I find some time to add it).

I think that some sort of official support should be seriously considered for a future Godot 3.2 release, ideally 3.2.4-stable.

[Calinou]

I think that some sort of official support should be seriously considered for a future Godot 3.2 release, ideally 3.2.4-stable.

We want it to happen too, but I don't control the release process itself.

[efornara]

I suppose someone could publish unofficial templates for Godot, as occasionally happens. From what I have seen, these tend not to remain up-to-date for long. My guess is for lack of discoverability, which leads to lack of downloads / stars / likes, and ultimately to loss of interest from the person attempting it.

At the end of the day, I can live without an official export template. What I am missing is a reason, I suppose by who controls the release process itself, because, as things are now, the situation doesn't make much sense to me.

[Calinou]

What I am missing is a reason, I suppose by who controls the release process itself, because, as things are now, the situation doesn't make much sense to me.

The build containers need to be updated to allow for ARM cross-compilation. While feasible, it's not 100% trivial.

[hiulit]

@efornara Do you have any tips on which flags are best suited for compiliing for both the Raspberry Pi 3 and 4?

As you can see in my post above I used diferrent flags, but as far as I could see, they all seemed to perform equally.

[efornara]

@Calinou

The build containers need to be updated to allow for ARM cross-compilation. While feasible, it's not 100% trivial.

Fair enough. I am planning to soon focus on cross-compiling for FRT too. I did a quick test a few months ago, and I think I only had to make just a few minor changes to my detect.py to get a binary that started without crushing.

@hiulit

Do you have any tips on which flags are best suited for compiliing for both the Raspberry Pi 3 and 4?

Not really. I copied the flags that I am using from an unchallenged forum post on the Raspberry Pi forums ages ago. Today, I would use something different (i.e. less specific). I have never changed them because it wasn't broken, so there was no point in risk breaking it. I do plan to simplify them when I switch to cross compiling: I am making a break anyway, so I might as well go all the way.

Same boat as you when it comes to performance. I tried once a benchmark and the results were inconclusive and too noisy.

About LTO. I had problems generating a Godot 3.something editor build, even on a PC with 8G of RAM running qemu-user-static overnight. There is a possibility that a 8G Pi4 won't be enough to generate a 32-bit binary, and you might need to cross compile anyway.

[Calinou]

Here's a suggestion: Temporarily fix this by providing debug and release templates for Linux arm64 headless only for servers and such

4.2.rc1 has official Linux ARM64 + ARM32 binaries for the editor and export templates, which can be run with --headless as usual.

The download card in the blog post doesn't have download links for ARM yet, but you can go to the full download page and click Show all downloads in the bottom-right corner.

[Netherite1701]

I've made some tests on the latest Pi 5 and sadly, there seems to be some issues with the Vulkan drivers on Raspberry Pi OS.
But the good news are that they are working on Ubuntu 23.10 :)

Here's a video running the 2D platformer demo on the Pi 5 on Ubuntu 23.10 using --rendering-driver opengl3_es https://x.com/hiulit/status/1723825137030451599?s=20

Did you test the ubuntu run on the RPI5? Or on another computer?

[hiulit]

Did you test the ubuntu run on the RPI5? Or on another computer?

I tested Ubuntu 23.10 on the RPI5.

[OverloadedOrama]

Now that Godot 4.2 stable is out with official ARM builds, shouldn't this issue be closed? Or are there more things that yet remain to be implemented?

[TheJackiMonster]

Now that Godot 4.2 stable is out with official ARM builds, shouldn't this issue be closed? Or are there more things that yet remain to be implemented?

Depends... originally the issue was about Godot 3 which still supports more devices with lower specs because of the OpenGL ES 2.0 renderer. For example I tried to arm64 build with compatibility profile on my Librem 5 and it couldn't run because it still required OpenGL 3.3 which the etnaviv driver on it does not support yet.

So I personally would still like to have ARM builds in Godot 3. I'm not sure whether there is still an update planned for Godot 3. But it would be neat.

[aaronfranke]

@TheJackiMonster It should already be possible to make Arm builds for Godot 3. Even though the code for it is a bit janky, and there are no plans to backport the architecture refactoring changes in Godot 4, it should still work. I was able to port the RISC-V code to Godot 3 and it compiles/runs fine, so I would expect Arm to also work.

[ecurtz]

The 4.2 release announcement said there were known issues with the Raspberry Pi build, but I didn't see them documented in a quick search. I wouldn't think this should be closed unless those are fixed or new, more focused issues are added so they can be tracked.

[fbcosentino]

Issues with Raspberry Pi build, or with Raspberry Pi OS?

[TheJackiMonster]

@TheJackiMonster It should already be possible to make Arm builds for Godot 3. Even though the code for it is a bit janky, and there are no plans to backport the architecture refactoring changes in Godot 4, it should still work. I was able to port the RISC-V code to Godot 3 and it compiles/runs fine, so I would expect Arm to also work.

@aaronfranke Do you have any instructions for me? Are we still talking about export templates or engine builds? Because if I run arm64 Godot 3, I still get the options to export to x86. Otherwise running a game through the editor works. But if there was an export template, I could use, that would solve my issue.

[ecurtz]

Issues with Raspberry Pi build, or with Raspberry Pi OS?

"in fact, we’re already aware of issues running executables on Raspberry Pi OS".
OS, apparently. If I just missed those and there are already new issues here for that then I don't mind this one being closed.

[hiulit]

@TheJackiMonster It should already be possible to make Arm builds for Godot 3. Even though the code for it is a bit janky, and there are no plans to backport the architecture refactoring changes in Godot 4, it should still work. I was able to port the RISC-V code to Godot 3 and it compiles/runs fine, so I would expect Arm to also work.

@aaronfranke Do you have any instructions for me? Are we still talking about export templates or engine builds? Because if I run arm64 Godot 3, I still get the options to export to x86. Otherwise running a game through the editor works. But if there was an export template, I could use, that would solve my issue.

You can use my unofficial raspberry pi builds.

[hiulit]

I don't know what are the godot team plans, but I would wait at least until you can download ARM binaries from the website. That is what "official" means to me.

[hiulit]

Here some interactions I had with Rémi and other people about this topic:

https://x.com/Akien/status/1719691269910282698?s=20

https://x.com/Akien/status/1727806022792712332?s=20

[akien-mga]

I'll repost what I wrote on the Godot Forum a few days ago:

So I've done some testing on Raspberry Pi 5 8GB RAM indeed, all on RPi OS.

What I found out so far:

• Our new official Linux arm64 binaries in 4.2 (added to the official set of binaries a few weeks ago) don't work on RPi OS, they segfault. This seems caused by the toolchain we use for cross-compilation, I'll need help from @hpvb to fix it. I'm told those same binaries work on Ubuntu 23.10 on RPi 5, so it might be a RPi OS specific bug. Still something we need to fix as it's the base distro.

• Self compiled binaries on real arm64 hardware, or possibly cross-compiled with other toolchains (e.g. clang aarch64 target) should work fine however. So the segfault is really just a problem with how we do the builds, not with Godot itself.

• With a self-compiled build, I was able to test how things work. Both Vulkan and OpenGL ES seem to work ok. For Vulkan, note that RPi OS does not install Vulkan drivers out of the box, you have to install mesa-vulkan-drivers. Other distros might have similar oversights.

• I haven't had luck opening 3D projects with meshes like Kenney's FPS Starter Kit. I think there's a problem with VRAM compression of textures, and generally it seemed to take forever to import assets. I might have just given up too fast.

• It's easy to exhaust the resources of the RPi 5 and make RPi OS deadlock, possibly due to thermal throttling. Though my first tests were done before installing Active Cooling, now with the fan it seems to be doing ok.

• There's still a lot more to test and optimize, but for now I want to fix our official binaries.

---

I also want to provide official Linux ARM binaries for Godot 3.6, but it currently suffers the same issue that the binaries produced by our Linux SDK seem to crash on Raspberry Pi OS. It's not a Godot problem, even a hello world C program crashes on start.

I made a few adjustments to the 3.x branch last week to make sure it builds out of the box on arm64. Notably godotengine/godot@dede8d3 and #85915, so that embree, theora, and webm all build fine too (so no module needs to be disabled).

[akien-mga]

• Our new official Linux arm64 binaries in 4.2 (added to the official set of binaries a few weeks ago) don't work on RPi OS, they segfault. This seems caused by the toolchain we use for cross-compilation, I'll need help from @hpvb to fix it. I'm told those same binaries work on Ubuntu 23.10 on RPi 5, so it might be a RPi OS specific bug. Still something we need to fix as it's the base distro.

Well that went fast, I got @hpvb remote access to my RPi 5 yesterday, and they fixed the issue in our Linux arm64 toolchain: godotengine/buildroot@e6c2704

We now have a new version of our Linux SDKs that should produce valid arm64 binaries for RPi OS: https://downloads.tuxfamily.org/godotengine/toolchains/linux/2023-12-11/

I'm using these new Linux SDKs for 4.2.1-stable, so it should work out of the box on arm64. Please test and confirm:

• https://downloads.tuxfamily.org/godotengine/4.2.1/Godot_v4.2.1-stable_linux.arm64.zip

I also made a test build from the 3.x branch with the same SDKs, which also seems to work for me on both RPi 5 on RPi OS, and the Linux subsystem on an arm64 Chromebook:

• https://downloads.tuxfamily.org/godotengine/testing/Godot_v3.6-beta_x11_arm64.zip

[akien-mga]

So this is implemented and (in my testing) functional in 4.2.1-stable.

I'll also confirmed that arm64 binaries can be built for the 3.x branch, so we should be able to have this in 3.6 too.

[Schweini07]

This is very cool to see, after all this time 😄

[RiptideAtlantic]

Hi! I'm using a Raspberry Pi 5 8gb Ram model on Rasberry Pi OS and I downloaded this version:

I'm using these new Linux SDKs for 4.2.1-stable, so it should work out of the box on arm64. Please test and confirm:

• https://downloads.tuxfamily.org/godotengine/4.2.1/Godot_v4.2.1-stable_linux.arm64.zip

Whenever I execute it through the console or through the file, it works fine until I try to open a project. When I do, it says Godot game engine for a second then crashes. What am I doing wrong?

[Calinou]

Whenever I execute it through the console or through the file, it works fine until I try to open a project. When I do, it says Godot game engine for a second then crashes. What am I doing wrong?

Vulkan support on the Raspberry Pi is still spotty, so you need to create/open projects using the Compatibility rendering method. If the project is configured to use another rendering method, open the project directly on the command line using the --rendering-method gl_compatibility command line argument.

[RiptideAtlantic]

@Calinou Works perfect now, thanks so much!

[real-felix]

@akien-mga It works really well! (I'm testing it on Asahi Linux). Do you know if it'll be available on the official page, with the latest version, in the future?

[Calinou]

@akien-mga It works really well! (I'm testing it on Asahi Linux). Do you know if it'll be available on the official page, with the latest version, in the future?

This was added today in godotengine/godot-website#899.

[sosasees]

will i be able to export to

• Linux/X11 (arm)
• Linux/X11 (arm64)

from Linux/X11 (x86_64) in an upcoming Godot version?

[Calinou]

from Linux/X11 (x86_64) in an upcoming Godot version?

It's already feasible by checking the correct architecture options in the Linux export preset, as long as you have export templates installed. This works because you don't actually compile anything when you export a project to Linux - Godot just copies precompiled export templates for the selected architecture alongside the exported PCK.