| RFC-0285：Magma GPU 开源项目 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 一项旨在将 Magma 发展为具有通用共享参考实现的开放标准的提案。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2026-06-23 |
| 审核日期（年-月-日） | 2026-07-24 |
摘要
在 RFC #198 的基础上，此 RFC 提议成立 Magma-GPU 探索委员会。该委员会的目标是将 Magma 发展成为一种多操作系统 GPU 标准，用于桥接 GPU 驱动程序堆栈的高级部分1和低级部分2。
动机
如需了解背景信息和定义，建议读者查看附录，了解 GPU 复杂性和向开源发展的行业趋势。
Magma 是 Fuchsia 的 GPU 驱动程序模型。Magma 承认 UMD 和系统驱动程序设计存在很大的差异化空间，但旨在使跨驱动程序接口本身更加标准化。这在 Fuchsia 之外也很有用 - Android GPU 虚拟化工作建议将 Magma 上游化到 Mesa，以解决 virtio 碎片化问题（一种称为 magmavirt 的设计）。
虽然上游合并请求仍在进行中，但围绕该请求的讨论揭示了 Mesa 在对类微内核系统的支持方面存在的不足。
| 操作系统 | Mesa 状态 | 开源系统驱动程序 |
|---|---|---|
| Fuchsia | Mesa 分支 | Fuchsia Git |
| HaikuOS | 支持树内软件渲染 | 正在进行的 NVK 移植 |
| QNX | 维护 Mesa 分支 | 封闭式系统驱动程序 |
| Redox OS | LLVMpipe 的 Mesa 分支 | 开始开发 Intel GPU 驱动程序 |
每个微内核项目都创建自己的接口和系统驱动程序，这对于维护人员和微内核开发者来说效率都很低。
硬件供应商不太可能支持 Fuchsia、QNX、Redox 和 Haiku 的系统驱动程序。目前大多数微内核系统 GPU 驱动程序都是用 C/C++ 编写的，而 Linux DRM 已经过渡到 Rust。
为了解决这些问题，此 RFC 提议将 Magma 发展成为行业范围内的开源微内核 GPU 标准。
利益相关方
辅导员：
审核者：
目标
- 成立 Magma GPU 探索委员会
- Magma GPU 探索委员会定期召开季度会议
- 在至少一个 Mesa Vulkan 驱动程序中实现 Magma
- 就一组通用接口达成一致意见
- 可能在 Magma 用户之间共享系统驱动程序部分
非目标
- 一刀切
- 将 Magma-in-Mesa 工作流与闭源工作流统一起来
设计
我们将成立 Magma-GPU 探索委员会，以促进 Fuchsia Graphics、Android GPU 虚拟化和非 Fuchsia 微内核开发者之间的协作。
鉴于微内核项目的资源有限，委员会将每季度通过视频聊天召开一次会议，每次会议时长为一小时，目标是达到 Mesa 级标准。
我们将采用共识驱动的方法，类似于 Khronos 探索性小组的方法。
如果架构正确，GPU 驱动程序的许多工作都可以共享。
| 组件 | 位置 | 主要功能 | 估计重复使用次数 |
|---|---|---|---|
| 用户空间客户端库 | Mesa | API 翻译、着色器编译为 IR/机器代码、状态跟踪。 | 90% - 95% |
| 硬件核心逻辑 | 系统驱动程序 | 命令缓冲区格式设置、设备寄存器定义、执行流水线。 | 70% - 90% |
| 电源管理 | 系统驱动程序 | 时钟门控、电压缩放、热限制、暂停/恢复处理。 | 50% - 70% |
| 内存管理 | 系统驱动程序 | 为直接内存访问 (DMA) 分配、固定和映射物理内存。 | 0% |
| 硬件发现和 IRQ | 系统驱动程序 | 绑定到 PCI 总线，处理硬件中断。 | 0% |
| 堆栈平均总分 | 总计 | 功能全面的 GPU 驱动程序。 | 70% - 80% |
委员会的职责是将各种可能性转化为实际代码。
Magma GPU API 和协议设计
干净的协议意味着干净的实现。Fuchsia 目前的 Magma 库和协议均不受供应商和操作系统限制，将作为委员会构建的基础。库和协议都将进行版本控制，以便为消费者提供可靠性保证。
创新
与现状相比，微内核设计可以在许多方面进行创新。这些领域包括但不限于 GPU 重置、用户空间命令提交和虚拟化。
在保持现有应用的软件兼容性的同时进行创新是一项有趣的技术挑战。
跨平台 Magma 系统驱动程序 (MSD) 的设计
当前实现假定每个 GPU 供应商对应一个系统驱动程序。例如，Haiku RadeonGfx 不同于 Haiku Nvidia 驱动程序。Fuchsia Intel MSD 是不同于 Fuchsia ARM MSD 的二进制文件，但两者都利用 sys_driver 库来实现通用代码。
为了避免中间层错误，同时最大限度地提高代码重用率，高级设计可以是一组可组合的 Rust 箱，特定操作系统可以利用这些箱来构建自己的 MSD。
委员会将决定具体细节。
源代码位置
微内核驱动程序分散在 Fuchsia Git、RedoxOS GitLab 和 GitHub 中。对于行业范围的协作，我们需要满足以下要求：
- 每个 Magma GPU 组件（客户端库、协议和系统驱动程序）都需要易于修改，以供感兴趣的开发者使用
- 通用代码不能依赖于特定于操作系统的功能
我们去年在 freedesktop 上提出了新的 GitLab 位置，但最终确定使用 magma-gpu 项目 GitHub 组织。接下来，您可以考虑以下几种选择：
最好让系统驱动程序位于 Mesa 本身中。例如，在如下结构中：
src/magma-gpu/lib（协议定义、客户端库）src/magma-gpu/bin（MSD 服务器二进制文件）src/magma-gpu/ffi（与 C Mesa 驱动程序的 FFI 绑定）
供应商已在 Mesa 上；我们不需要再为他们提供一个提交代码的位置。同时更新 UMD 和系统驱动程序可能会带来一些缺点。
回退到已创建的 GitHub 组织。
版权
Magma GPU 项目遵守最高的道德和法律标准。Mesa 已经基于 MIT，而 Magma 客户端库也将基于 MIT。Magma 系统驱动程序 (MSD) 二进制文件的通用代码将采用 MIT 许可。
如果 GPL-2.0 代码的传染性可以得到控制，则可能可以在 MSD 代码中策略性地引用 GPL-2.0 许可的 Linux DRM 代码。不过，这需要探索性委员会和组成项目进一步讨论（以及另一项可能的 Fuchsia RFC）。此 RFC 未解决该问题。
人员配备和时间承诺
我们预计，高优先级的内部工作将成为 Fuchsia 团队的重点。 无需申请或安排额外的人员。这是一项早期生态系统计划。
附录 I：GPU 驱动程序很复杂
GPU + NPU 驱动程序堆栈共享类似的拓扑：
用户模式驱动程序 (UMD) 包含
- 一种编译器，可从领域特定语言（SPIRV、CUDA C++ 或 HLSL）输出 GPU 汇编
- 标准化 API（Vulkan、CUDA、OpenGL、OpenCL）的实现
UMD 将命令提交给系统驱动程序，后者可安全地协调对硬件的访问。
典型的 UMD 和系统驱动程序各自的范围为 100 到 500 kLOC。AMD Linux 内核驱动程序有 600 万行，其中 150 万行是逻辑代码。
在系统驱动程序之下，现代 GPU 驱动程序依赖于固件 blob（也高达 100 万行以上的代码）。这些 blob 用于处理电源管理、调度和散热限制。
Apple 的 M1 GPU 和 Nvidia 的 GSP 协处理器 都运行嵌入式 RTOS，而 ARM 的新 Mali CSF 设计 具有高级固件。Timothy Roscoe 教授认为，这些协处理器和 blob 需要重新考虑操作系统设计。
附录 II：开源 GPU 驱动程序是不可抗拒的趋势
爱好者、操作系统开发者和硬件供应商之间的复杂互动促使开源成为开发 GPU 驱动程序的最佳方式。这种情况在 Linux 生态系统中最为明显。
Mesa：一切的起点（1993 年 → 1997 年）
Mesa 包含数十个开源 GPU UMD。Mesa 最初由 Silicon Graphics 开发者 Brian Paul 于 1993 年启动。
作为副项目，Brian 创建了 OpenGL 1.0 的软件实现，并将其发布到互联网。很快就广受欢迎。
1997 年，添加了硬件加速的 Mesa Glide 驱动程序，但它使用的是闭源系统驱动程序。
咨询公司创建的 Linux 系统驱动程序（1999 年 → 2004 年）
Precision Insight 是一家由 Red Hat 和 Intel 签约的咨询公司，负责领导开发 Linux Direct Rendering Manager (DRM) 内核模块，该模块是为 3Dlabs 的 GMX2000 GPU 和 Intel 的 i810 驱动程序开发的。这为当今仍在使用的基础设施奠定了基础。
VALinux 随后不久便添加了 Radeon DRM 驱动程序。
Precision Insights 的衍生公司 Tungsten Graphics 添加了 i915 Intel 内核模块。
开源图形成为现实 (2004 年 → 2010 年)
Intel 的开源技术中心成立于 2000 年代中期，他们成为推动 Linux DRM 和 Mesa 结构性变化的最大动力。
AMD 开始为 Radeon 驱动程序贡献代码。一位法国研究生对 Nvidia 驱动程序进行了逆向工程，并将其称为 nouveau。
Line in the sand (2010)
随着 Android 的问世，多家移动供应商（高通、Imagination、ARM）试图将自己的 Linux 系统驱动程序上游化，但并未将自己的 UMD 开源。Linux 内核 GPU 维护人员 Dave Airlie 于 2010 年划定界限，要求在将系统驱动程序合并到 Linux 内核之前，必须先有开源 UMD。这已编入要求：
简而言之，任何 DRM uAPI 的添加都需要相应的开源用户空间补丁，并且这些补丁必须经过审核，并准备好合并到合适的规范上游项目中。
Linux 桌面设备和爱好者引领潮流 (2011 年 → 2021 年)
移动设备供应商未将其 UMD 开源的原因有很多：
- GPU 驱动程序堆栈被视为增值组件
- 与闭源 UMD 相关的法律问题
- 将它们开源所需的时间投入
无论如何，开源 GPU 驱动程序早已成为 Linux 桌面的标配。 Valve 开始投资开源游戏，而 ChromeOS 的 Freon 堆栈受益于开源。爱好者对 freedreno 和 panfrost 进行了逆向工程。
ChromeOS 在极少的 Qualcomm 协助下发布了 Freedreno Chromebook。
移动设备供应商、Nvidia 和 Android 投资于开源项目（2021 年至今）
开源 GPU 驱动程序的质量和维护优势变得不容忽视。ARM 和 Imagination 都开始投资于 Mesa 和 Linux DRM。
高通聘用了 Freedreno 维护人员，而 Nvidia 已开始投资于 Linux DRM（但不是 Mesa）。
Freedreno 广泛用于 Android 游戏，Steam Frame 将利用它。
Android 计划首次持续更新 Mesa 驱动程序。
附录 III：Khronos
Khronos Group 是一个行业机构，致力于为 3D 图形、机器学习和 AR/VR 制定开放标准。许多行业标准（Vulkan、OpenGL、OpenXR、OpenCL、glTF）都是通过 Khronos 流程创建的。
在标准诞生之前，它会经历一个众所周知的流程：
- 第一阶段：易于组建且基本上零成本的探索性群组
- 第二阶段：获得 Khronos 董事会的批准，成立工作组
- 第 III 阶段：起草正式规范
- 第 IV 阶段：批准规范并编写一致性套件
后续修正案将遵循正式的投票流程。