| RFC-0285: The Magma GPU open-source project | |
|---|---|
| Status | Accepted |
| Areas |
|
| Description | A proposal to advance Magma as an open standard with a common shared reference implementation. |
| Issues | |
| Gerrit change | |
| Authors | |
| Reviewers | |
| Date submitted (year-month-day) | 2026-06-23 |
| Date reviewed (year-month-day) | 2026-07-24 |
Summary
Building on RFC #198, this RFC proposes the creation of the Magma-GPU exploratory committee. The goal of the committee would be to advance Magma as a multi-OS GPU standard that bridges the high level1 and low level parts2 of the GPU driver stack.
Motivation
For background and definitions, readers are encouraged to read the appendices to understand GPU complexity and industry trends towards open-source.
Magma is Fuchsia's GPU driver model. Magma acknowledges the significant scope for differentiation in UMD and system driver designs, but aims for more standardization in cross-driver interface itself. This is useful outside Fuchsia - the Android GPU virtualization effort proposed upstreaming Magma to Mesa to solve virtio fragmentation issues (a design known as magmavirt).
While the upstream merge request remains a work in progress, the discussion around it revealed gaps in Mesa's support for microkernel-like systems in general.
| OS | Mesa Status | Open-Source System driver |
|---|---|---|
| Fuchsia | Mesa forks | Fuchsia Git |
| HaikuOS | Software rendering supported in-tree | A NVK port in progress |
| QNX | Maintains Mesa forks | Closed system drivers |
| Redox OS | Mesa forks for LLVMpipe | Work started on Intel GPU driver |
Each microkernel project creating its own interface and system drivers is inefficient for both maintainers and microkernel developers.
Hardware vendors are unlikely to support system drivers for Fuchsia, QNX, Redox, and Haiku. Most current microkernel system GPU drivers are written in C/C++, while Linux DRM is already transitioning to Rust.
To solve these issues, this RFC proposes to advance Magma as an industry-wide, open-source microkernel GPU standard.
Stakeholders
Facilitator:
Reviewers:
Goals
- Creation of the Magma GPU exploratory committee
- Regular quarterly meetings of the Magma GPU exploratory committee
- Landing Magma in at least one Mesa Vulkan driver
- Aligning on a set of common interfaces
- Potentially sharing system driver parts amongst Magma users
Non-goals
- One-size-fits-all for everything
- Unifying Magma-in-Mesa workstreams with closed-source workstreams
Design
The Magma-GPU exploratory committee will be created to foster collaboration amongst Fuchsia Graphics, Android GPU virtualization and non-Fuchsia microkernel developers.
Given the limited resources of microkernel projects, the committee will meet quarterly via video chat for one hour and target a Mesa-level standard.
We will follow a consensus-driven approach, similar to that of a Khronos exploratory group.
Much of the work of GPU drivers can be shared, if architected correctly.
| Component | Location | Primary Function | Estimated Reuse |
|---|---|---|---|
| User-Space Client libraries | Mesa | API translation, shader compilation to IR/machine code, state tracking. | 90% - 95% |
| Hardware Core Logic | System Driver | Command buffer formatting, device register definitions, execution pipelines. | 70% - 90% |
| Power Management | System Driver | Clock gating, voltage scaling, thermal limits, suspend/resume handling. | 50% - 70% |
| Memory Management | System Driver | Allocating, pinning, and mapping physical memory for Direct Memory Access (DMA). | 0% |
| Hardware Discovery & IRQs | System Driver | Binding to the PCI bus, handling hardware interrupts. | 0% |
| Total Stack Average | Overall | Fully-functional GPU driver. | 70% - 80% |
The job of the committee is to translate the possibilities into actual code.
Magma GPU API and protocol design
A clean protocol implies a clean implementation. Fuchsia's current Magma library and protocol are both vendor and OS neutral and will serve as the basis for the committee to build upon. Both the library and protocol will be versioned so consumers will have reliability guarantees.
Innovation
There are many areas where microkernel designs can innovate compared to the status quo. These areas include -- but are not limited to -- GPU resets, userspace command submission, and virtualization.
Innovating, while maintaining software compatibility for existing applications, is an interesting technical challenge.
Design of cross-platform Magma System Drivers (MSD)
Current implementations assume one system driver per GPU vendor. For example, the Haiku RadeonGfx is different from the Haiku Nvidia driver. The Fuchsia Intel MSD is a different binary from the Fuchsia ARM MSD, but both leverage the sys_driver library for common code.
To avoid the mid-layer mistake while maximizing code reuse, a high-level design could be a set of composable Rust crates that a specific OS can leverage to build their own MSD.
The committee will decide on the exact details.
Source code location
Microkernel drivers are scattered throughout Fuchsia Git, RedoxOS GitLab, and GitHub. For an industry-wide collaboration, we need to meet the following requirements:
- each Magma GPU component (the client library, protocol, and system driver) needs to be easy to modify for interested developers
- common code cannot depend on OS-specific functionality
We proposed a new GitLab location on freedesktop last year, but ultimately settled on the magma-gpu project GitHub organization. There are a few options going forward:
It may be desirable that the system drivers live in Mesa itself. For example, in a structure like:
src/magma-gpu/lib(protocol definitions, client lib)src/magma-gpu/bin(MSD server binaries)src/magma-gpu/ffi(FFI bindings to C Mesa drivers)
Vendors are already on Mesa; we will not need another location for them to submit code. There could be drawbacks to updating the UMD + system driver at the same time.
Fallback to the already-created GitHub organization.
Copyright
The Magma GPU project adheres to the highest ethical and legal standards. Mesa is already MIT-based and the Magma client library will be MIT-based. The common code for the Magma System Drivers (MSD) binary will be MIT-licensed.
It may be possible to tactically reference GPL-2.0 licensed Linux DRM code in MSD code, if the virality of the GPL-2.0 code can be contained. However, that requires further discussion among the exploratory committee and constituent projects (and another possible Fuchsia RFC). This RFC leaves the issue unresolved.
Staffing and time commitment
We expect high-priority internal efforts to be the focus of the Fuchsia team. Additional staffing is not requested nor required. This is an early-stage ecosystem initiative.
Appendix I: GPU drivers are complex
GPU + NPU driver stacks share a similar topology:
The usermode driver (UMD) contains
- a compiler that outputs GPU assembly from a domain-specific language (SPIRV, CUDA C++, or HLSL)
- an implementation of a standardized API (Vulkan, CUDA, OpenGL, OpenCL)
The UMD submits commands to the system driver, which securely mediates access to the hardware.
Typical UMDs and system drivers range from 100 to 500 kLOC each. The AMD Linux kernel driver is 6 million lines, with 1.5M lines of logic.
Beneath the system driver, modern GPU drivers rely on firmware blobs (also up to 1M+ LoC). These blobs handle power management, scheduling, and thermal throttling.
Both Apple's M1 GPU and Nvidia's GSP co-processor run embedded RTOSes, while ARM's new Mali CSF design features advanced firmware. Professor Timothy Roscoe argues these co-processors and blobs require a rethink of operating system design.
Appendix II: Open-source GPU drivers are an irresistible trend
A complex interplay among hobbyists, OS developers, and hardware vendors has led to open-source becoming the best way to develop GPU drivers. This is most acutely visible in the Linux ecosystem.
Mesa: the side-project that started it all (1993 → 1997)
Mesa is where dozens of open-source GPU UMDs are located. Mesa was first started in 1993 by Silicon Graphics developer Brian Paul.
As a side-project, Brian created a software implementation of OpenGL 1.0 and released it to the internet. It quickly gained popularity.
In 1997, the HW-accelerated Mesa Glide driver was added, but it used a closed-source system driver.
Linux system drivers created by consultancies (1999 → 2004)
Precision Insight, a consulting firm contracted by Red Hat and Intel, led development of the Linux Direct Rendering Manager (DRM) kernel module, developed for the 3Dlabs' GMX2000 GPU and Intel's i810 driver. This serves as the basis for the infrastructure still in use today.
VALinux added the Radeon DRM driver shortly thereafter.
Tungsten graphics, a spinoff of Precision Insights, added the i915 Intel kernel module.
Open-source graphics becomes a thing (2004 → 2010)
Intel's Open-Source Technology Center was formed in the mid-2000s, and they became the biggest drivers of structural changes to Linux DRM and Mesa.
AMD started contributing to the Radeon driver. A French grad student reverse-engineered the Nvidia driver and called it nouveau.
Line in the sand (2010)
With the dawn of Android, several mobile vendors (Qualcomm, Imagination, ARM) tried to upstream their Linux system drivers without open-sourcing their UMDs. Linux kernel GPU maintainer Dave Airlie drew a line in the sand in 2010, requiring open-source UMDs before the system driver could be merged into the Linux kernel. This was codified into the requirements:
The short summary is that any addition of DRM uAPI requires corresponding open-sourced userspace patches, and those patches must be reviewed and ready for merging into a suitable and canonical upstream project.
Linux desktop and hobbyists lead the way (2011 → 2021)
Mobile vendors did not open-source their UMDs for various reasons:
- GPU driver stacks were considered a value-added component
- legal issues surrounding closed-source UMDs
- time investment required to open-source them
Regardless, open-source GPU drivers were already a thing for Linux desktops. Valve started investing in open-source gaming, and ChromeOS' Freon stack benefited from open-source. Hobbyists reverse engineered freedreno and panfrost.
ChromeOS shipped Freedreno Chromebooks with minimal Qualcomm assistance.
Mobile vendors, Nvidia, and Android invest in open-source (2021 → present)
The quality and maintenance benefits of open-source GPU drivers became hard to ignore. ARM and Imagination both started investing in Mesa and Linux DRM.
Qualcomm hired the freedreno maintainer, and Nvidia has started investing in Linux DRM (but not Mesa).
Freedreno is widely used for Android gaming and the Steam Frame will leverage it.
Android intends to update Mesa drivers consistently for the first time ever.
Appendix III: Khronos
The Khronos Group is an industry body that creates open standards for 3D graphics, machine learning, and AR/VR. Many industry standards (Vulkan, OpenGL, OpenXR, OpenCL, glTF) have been created via the Khronos process.
Before a standard is born, it progresses through a well-known pipeline:
- Stage I: An easy-to-form and essentially zero-cost exploratory group
- Stage II: Approval from Khronos board of directors to form a working group
- Stage III: Draft a formal specification
- Stage IV: Ratify the specification and write a conformance suite
Further amendments follow a formal voting process.