| RFC-0285：Magma GPU 開放原始碼專案 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 提案：將 Magma 發展為開放標準，並提供共用的參考實作。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2026-06-23 |
| 審查日期 (年-月-日) | 2026-07-24 |
摘要
本 RFC 以 RFC #198 為基礎，提議成立 Magma-GPU 探索委員會。委員會的目標是將 Magma 發展為多 OS 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 使用者之間共用系統驅動程式庫部分內容
Non-Goal
- 一體適用於所有內容
- 將 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 Crate，特定 OS 可利用這些 Crate 建構自己的 MSD。
委員會將決定確切細節。
原始碼位置
微核心驅動程式分散在 Fuchsia Git、RedoxOS GitLab 和 GitHub 中。如要進行全產業合作，我們必須符合下列規定：
- 每個 Magma GPU 元件 (用戶端程式庫、通訊協定和系統驅動程式庫) 都必須易於修改，方便感興趣的開發人員使用
- 通用程式碼不得依賴作業系統專屬功能
我們去年在 freedesktop 上提議了新的 GitLab 位置，但最終決定採用 magma-gpu 專案 GitHub 機構。您可以採取以下幾種做法：
系統駕駛人最好住在梅薩市。舉例來說，在類似以下的結構中：
src/magma-gpu/lib(通訊協定定義、用戶端程式庫)src/magma-gpu/bin(MSD 伺服器二進位檔)src/magma-gpu/ffi(FFI 繫結至 C Mesa 驅動程式)
供應商已在 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 驅動程式是不可抗拒的趨勢
在業餘愛好者、OS 開發人員和硬體供應商之間複雜的互動下，開放原始碼已成為開發 GPU 驅動程式的最佳方式。Linux 生態系統最能體現這點。
Mesa：一切的開端 (1993 年 → 1997 年)
Mesa 包含數十個開放原始碼 GPU UMD。Mesa 最初是由 Silicon Graphics 開發人員 Brian Paul 於 1993 年開始開發。
Brian 當時的副業是建立 OpenGL 1.0 的軟體實作，並在網路上發布。並迅速受到歡迎。
1997 年，Mesa Glide 驅動程式庫新增了硬體加速功能，但使用封閉原始碼系統驅動程式。
顧問公司建立的 Linux 系統驅動程式 (1999 年 → 2004 年)
Red Hat 和 Intel 委託的顧問公司 Precision Insight，負責開發 Linux Direct Rendering Manager (DRM) 核心模組，適用於 3Dlabs 的 GMX2000 GPU 和 Intel 的 i810 驅動程式庫。這項技術成為當今仍在使用的基礎架構基礎。
VALinux 隨後新增了 Radeon DRM 驅動程式。
Tungsten graphics 是 Precision Insights 的衍生產品，新增了 i915 Intel 核心模組。
開放原始碼圖像成為主流 (2004 年 → 2010 年)
Intel 的開放原始碼技術中心成立於 2000 年代中期，並成為 Linux DRM 和 Mesa 結構變革的最大推手。
AMD 開始為 Radeon 驅動程式庫貢獻心力。一位法國研究生對 Nvidia 驅動程式庫進行逆向工程，並將其命名為 nouveau。
Line in the sand (2010)
Android 推出後，多家行動裝置供應商 (Qualcomm、Imagination、ARM) 嘗試上游化 Linux 系統驅動程式，但未開放 UMD 原始碼。Linux 核心 GPU 維護人員 Dave Airlie 於 2010 年劃清界線，要求系統驅動程式庫必須先併入 Linux 核心，才能使用開放原始碼 UMD。這項規定已納入相關要求：
簡而言之，凡是新增 DRM uAPI，都必須有對應的開放原始碼 Userspace 修補程式，且這些修補程式必須經過審查，並準備好合併至合適的標準上游專案。
Linux 桌面和愛好者引領潮流 (2011 年 → 2021 年)
行動裝置供應商未開放 UMD 原始碼的原因有很多：
- GPU 驅動程式庫堆疊被視為加值元件
- 封閉原始碼 UMD 的法律問題
- 開放原始碼所需的時間投入
無論如何，Linux 桌機早已支援開放原始碼 GPU 驅動程式。Valve 開始投資開放原始碼遊戲，而 ChromeOS 的 Freon 堆疊也受惠於開放原始碼。愛好者對 freedreno 和 panfrost 進行了逆向工程。
ChromeOS 隨附 Freedreno Chromebook，且僅需極少的 Qualcomm 協助。
行動裝置供應商、Nvidia 和 Android 投資開放原始碼 (2021 年至今)
開放原始碼 GPU 驅動程式的品質和維護優勢不容忽視。ARM 和 Imagination 都開始投資 Mesa 和 Linux DRM。
Qualcomm 聘用了 freedreno 維護人員，Nvidia 也開始投資 Linux DRM (但不是 Mesa)。
Freedreno 廣泛用於 Android 遊戲，Steam Frame 也會採用這項技術。
Android 打算持續更新 Mesa 驅動程式，這在過去是前所未有的做法。
附錄 III：Khronos
Khronos Group 是產業機構，負責制定 3D 繪圖、機器學習和 AR/VR 的開放標準。許多業界標準 (Vulkan、OpenGL、OpenXR、OpenCL、glTF) 都是透過 Khronos 程序建立。
標準誕生前，會經過眾所皆知的管道：
- 第 1 階段：輕鬆組成且幾乎零成本的探索群組
- 第 II 階段：取得 Khronos 董事會的核准，成立工作團隊
- 第 III 階段：草擬正式規格
- 第 IV 階段：核准規格並撰寫合規套件
後續修訂則須經過正式的投票程序。