Add support for the RISC-V open source CPU architecture

[aaronfranke]

Describe the project you are working on

Getting Godot running on RISC-V.

Describe the problem or limitation you are having in your project

Godot doesn't run on RISC-V yet.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I propose that Godot adds RISC-V support. Not official builds, or even necessarily tested, but at least allowing users to compile for RISC-V. Note that this is more likely to appeal to existing RISC-V users rather than existing Godot users.

Why?

There are many reasons to add RISC-V support to Godot:

• Godot is an open source and modular engine. It seems fitting to have Godot able to run on an open source and modular CPU architecture.

• RISC-V is the first open source CPU architecture to have lots of momentum. Many Linux distros have support for RISC-V, and so do Haiku and FreeBSD. It's used in the European Processor Initiative, it's used in various custom American, Russian, Pakistani, and Chinese CPUs, it's used in textbooks for teaching about CPU architectures, and even Apple is interested. It's also gotten attention from Level1Techs, Phoronix, and LinusTechTips.

• As of recently, it is now possible to use high-end AMD GPUs on RISC-V, so game development on RISC-V is now feasible from a hardware perspective.

• I'm not aware of other engines that support RISC-V, so this would make Godot very attractive to the RISC-V community.

  • Not just for games, but also GUI apps. Chrome support on RISC-V is still unavailable, and therefore Electron is not available. Godot on RISC-V would give an alternative solution for making high-end GUI apps on RISC-V.

  • Realistically running games and GUI apps on RISC-V is going to be very niche for awhile, but this proposed support in its current state should be good enough to run servers if anyone wanted to run a server on open hardware.

I'll also cite these reasons for Debian adding RISC-V support, a lot of which applies to Godot:

Which?

RISC-V has 32-bit, 64-bit, and 128-bit versions, and various extensions.

• 32-bit RISC-V is only used with embedded systems, and is not used in any high-end devices. 128-bit RISC-V hardware is non-existent. Most Linux distros with RISC-V support only ship 64-bit versions anyway, so that means Godot should only aim to support 64-bit RISC-V.

• For extensions, I suggest supporting GC, since these are the most common. G is for "general purpose", and includes integer operations, 32-bit and 64-bit float operations, and (some form of?) atomics. C is for "compressed instructions", which significantly decreases the size of the instructions, at the cost of increasing the complexity of the CPU. Later on, another extension worth supporting is "V" (the vector extension), but this is not common yet.

This means that the full architecture name is rv64gc. The "RV" abbreviation is necessary for the architecture name and is a very common shortened form of "RISC-V".

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

master version: godotengine/godot#53508

3.x version: godotengine/godot#53509

These can be compiled with scons use_llvm=yes arch=rv64. I've done so on an emulated RV64 Ubuntu Server 20.04 VM, I don't actually own any real RISC-V hardware myself. EDIT: I do now.

I've been working on this for awhile by making sure the engine does not have strong dependencies on particular parts. For example, making the editor not require the RegEx module was not just for the sake of modularity, it's also to make it possible to compile the editor for RISC-V.

Here is a short list of modules that don't work on RISC-V (all non-essential):

• The RegEx module. Depends on PCRE but this is not supported on RISC-V, it emits JIT instructions that only apply to specific architectures.

• The Raycast module. Depends on Embree, which is not supported on RISC-V.

• The Mono module. Depends on Mono, which is not supported on RISC-V.

• The Theora and WebM modules. Neither of these video libraries are supported on RISC-V. There is discussion of removing video modules from the core engine anyway, in favor of GDExtension plugins.

• The Denoise module. Depends on the OIDN (Open Image Denoise) library, which uses the oneDNN neural network library. The version we currently use in Godot only supports x86_64, but the upstream oneDNN supports RISC-V (recently added), and the upstream OIDN library doesn't support RISC-V yet. Also, the upstream OIDN supports ARM, so it would be nice to upgrade anyway for the sake of supporting ARM devices such as the new M1 Macs, but unfortunately the latest OIDN requires an ISPC compiler which the Godot developers are hesitant about requiring.

Here is a chart of what works and what doesn't on RISC-V (EDIT: Updated 2024-06-06):

	Clang compiles	Clang runs	GCC compiles	GCC runs
master Editor debug	✅	🗣️	❌	❌
master Editor optimized	❌	❌	❌	❌
master Template debug	✅	🗣️	❌	❌
master Template optimized	❌	❌	❌	❌
3.x Editor debug	✅	✅	❌	❌
3.x Editor optimized	✅	❌	❌	❌
3.x Template debug	✅	✅	❌	❌
3.x Template optimized	✅	❌	✅	❌
3.x Headless debug	✅	✅	❌	❌
3.x Headless optimized	✅	✅	❌	❌
3.x Server debug	✅	✅	❌	❌
3.x Server optimized	✅	✅	✅	✅

🗣️ = It runs but only headlessly. It crashes with both the X11 and Wayland display drivers.

Several 3.x versions run and can display and render stuff. Even the editor works, but only in debug mode. However, it uses softpipe, so the performance is absolutely horrible (one frame every 5 seconds, I'm not joking).

GCC builds are all failing due to GCC bugs with atomics, but weirdly 3.x optimized template builds work. I have no clue why?

Old chart when I first opened this proposal (2021-10-01):

	Clang compiles	Clang runs	GCC compiles	GCC runs
master Editor debug	✅	🗣️	❌	❌
master Editor optimized	❌	❌	❌	❌
master Template debug	✅	🗣️	❌	❌
master Template optimized	❌	❌	❌	❌
3.x Editor debug	✅	❔	❌	❌
3.x Editor optimized	❌	❌	❌	❌
3.x Template debug	✅	❔	❌	❌
3.x Template optimized	❌	❌	❌	❌
3.x Headless debug	✅	✅	❌	❌
3.x Headless optimized	❌	❌	❌	❌
3.x Server debug	✅	✅	❌	❌
3.x Server optimized	❌	❌	❌	❌

Godot doesn't compile with GCC, but does compile with Clang. It fails on GCC because of GCC bugs with atomics.

Clang works for compiling debug builds, but not optimized release builds. This is because LLVMgold.so is missing on RISC-V. I tested both Clang 10 and Clang 12.

I have only tested Godot builds that offer headless modes (so, for 3.x, I only tested p=server and not p=x11, which is why those are ❔).

Here's a minimal test script:

func _ready():
	if OS.has_feature("riscv"):
		print("This is RISC-V!")
	else:
		print("This isn't RISC-V!")

When I run the test project with one of the succeeding headless-capable builds of Godot in headless mode, this output shows up:

Godot Engine v3.4.beta.custom_build.aa18d74c6 - https://godotengine.org
 
This is RISC-V!

If this enhancement will not be used often, can it be worked around with a few lines of script?

This won't be used often, and it could be worked around with a few edits to the SCons files, but it would make sense to merge these changes into Godot.

Is there a reason why this should be core and not an add-on in the asset library?

Platform support is a core feature.

[Calinou]

See also #988.

Pull requests for making Godot build on RISC-V are welcome, but I doubt official editor and export template binaries will be produced. (However, the Godot Flatpak could support RISC-V now that the FreeDesktop SDK supports it.)

[atirut-w]

If we can manage to make Godot run at a good performance level on RISC-V, this could benefit other platforms, too.

[fire]

Is this complete?

[aaronfranke]

I recently added RISC-V support to the build system of the GDNative C demos: godotengine/gdnative-demos#63

ubuntu@ubuntu:~/gdnative-demos/c/simple/project$ ~/godot-3/bin/godot_server.x11.tools.rv64.llvm 
Godot Engine v3.4.3.rc.custom_build.5b5b52ce1 - https://godotengine.org
 
Hello World from GDNative Simple C demo on RISC-V!

(you have to add some code to get this to print out - by the default the demo doesn't print this)

I also have a branch for the C++ demos https://github.com/aaronfranke/gdnative-demos/tree/scons-cpu-arch, but it needs some changes in the godot-cpp repo to get godot-cpp to compile for RISC-V (and ARM while we're at it), so I am waiting on this PR to be merged before the C++ demos will run on RISC-V Linux (and ARM Linux). godotengine/godot-cpp#714

---

Also, I have prebuilt Godot binaries for RISC-V for some releases of Godot available here https://drive.google.com/drive/u/0/folders/1mvopK6gcmXFW-KEqdedmBZXbizgug0yY

[akien-mga]

I think this can be closed as fixed by godotengine/godot#53508.

We might want to keep track of other RISC-V related improvements in dedicated proposals (e.g. the possibility to provide official builds eventually).

[aaronfranke]

Support for RISC-V was also added to the godot-cpp repo recently for GDExtension for Godot 4.0: godotengine/godot-cpp#759

[ShalokShalom]

Interesting in this context:

Two different RISCV SBC's, for a low level entry into development

Star64

https://www.pine64.org/2022/08/28/august-update-risc-and-reward/

Visionfive 2

https://www.kickstarter.com/projects/starfive/visionfive-2

[CutestNekoAqua]

@aaronfranke is there a way for us to implement LLVMgold.so so that we can produce release builds?

[aaronfranke]

@CutestNekoAqua I don't know, I never got that far. I will be looking into improving RISC-V support further once I get my hands on Ubuntu on the VisionFive 2.

[CutestNekoAqua]

@CutestNekoAqua I don't know, I never got that far. I will be looking into improving RISC-V support further once I get my hands on Ubuntu on the VisionFive 2.

@aaronfranke Would recomment looking into the archlinux riscv project too, as it seems to be more bleeding edge and thus easier to test new compiler versions.

[aaronfranke]

@CutestNekoAqua I'm actually interested in using Ubuntu because it is less bleeding edge. If something works on a stable version of a compiler then it will probably work on newer versions and the builds will be cross-compatible.

[lokimckay]

Hello, sorry to necro

but I doubt official editor and export template binaries will be produced

As a novice cross-compilation dev building a GDExtension (using Godot 4.2.2), I'm confused why this is the case and how to obtain the export templates on my own.

I incorrectly assumed that every item in the Project -> Export -> Binary Format -> Architecture would be available in the official export templates. In particular I was interested in rv64, ppc64 and ppc32.

From reading these unrelated docs about Compiling for Android, I am guessing that I would need to run ./gradlew generateGodotTemplates in the environment I'd like to target?

Perhaps a more general docs page could be considered for others like me?

[aaronfranke]

@lokimckay The instructions for compiling Godot for other architectures is the same as compiling normally, except you specify the architecture using arch=, and if you either need to use an environment with that architecture (either real hardware or a VM), or set up cross-compilation (which I don't know how to do). For example, try running scons arch=rv64 use_llvm=yes. If you run this from a Linux rv64 environment, it should succeed. scons arch=rv64 without the LLVM flag is intended to work in the future but there are bugs with GCC last time I tried it.

https://docs.godotengine.org/en/stable/contributing/development/compiling/compiling_for_linuxbsd.html

[AThousandShips]

The architecture options are explained in the documentation for building, the general details, here

[lokimckay]

Thanks, but those explanations and linked docs relate to compiling the engine from source correct? I would prefer not to do that. I will try to explain my use case better:

1. Want to build and run a Godot project inside different OS's and architectures in order to run tests in those environments
2. Do this via Github actions runners
3. Create workflow that downloads Godot binary and Export templates to the runner
4. Build and run the Godot project in the runner

This works fine for all build presets, except those that specify rv64, ppc64 or ppc32, because those architectures do not have export templates included in the official .tpz

I assume to solve my use-case I would need to compile Godot for those 3 architectures once in order to get the export templates, (or find them at an unofficial source), and then insert those to each run of the workflow via my own mechanism?

[Calinou]

I assume to solve my use-case I would need to compile Godot for those 3 architectures once in order to get the export templates, (or find them at an unofficial source), and then insert those to each run of the workflow via my own mechanism?

Yes 🙂

You can store these kinds of "permanent" artifacts in a dedicated repository's Releases tab, like I do in https://github.com/Calinou/media.

[aaronfranke]

Update: I re-tested using the latest 2024-05 OS image. I updated the OP with a new table of checkmarks that shows what works and what doesn't.

The OS now ships with sufficient graphics support to launch the 3.x editor and export template with a GUI, but only debug builds, and only Clang, and only 3.x. There is no hardware acceleration yet, it runs through softpipe, so it runs agonizingly slow, about 1 frame every 5 seconds. Still, it boots:

It could be possible to get better performance by connecting a dedicated GPU. I only used the integrated one.

The terminal in the bottom-right shows what happens if I try to launch 4.x, and the same message also shows up when trying to launch 3.x optimized editor/templates. For all cases, it happens when trying to render stuff.

GCC still doesn't compile... except for optimized 3.x templates, both server and non-server? No clue why those succeed. The rest fail due to errors with atomics, like before.

[fwsGonzo]

The rest fail due to errors with atomics

Does Godot use custom atomics, __sync builtins or C++ standard library atomics?