一個月內為 M4 Mac Mini 打造 OpenGL ES 3.0 Linux GPU 驅動程式

摘要

Cody Ho 和 Niklas 在約一個月內為 M4 Mac Mini 和 MacBook Neo 交付了一個可運作的 OpenGL ES 3.0 Linux 驅動程式，證明了大型語言模型輔助的反向工程可以取代數年的人工努力。

專案概覽

  • 目標： 為 Linux 上的 Apple 晶片 GPU（M4、A18 Pro、M5）建立符合標準的 OpenGL ES 3.0 驅動程式（未來支援 Vulkan）。
  • 時間線： 約 4 週的高強度工作，遠短於開發新 GPU 驅動程式通常需要多年的時間。
  • 關鍵成果： Chrome/Firefox WebGL 示範可運行，Minecraft 達到 200 fps，並產生了完整的 Linux 核心驅動程式及使用者空間堆疊。
  • 方法論： 使用 hypervisor 擷取硬體追蹤資料進行乾淨室反向工程，並結合 LLM（Codex、GPT-5.6 Sol、GPT-6 Astra）進行 ABI 發現、程式碼生成及系統性除錯。

反向工程韌體 ABI（核心空間）

  • Apple 的模型： GPU 運行自訂 RTOS（RTKit），並暴露共享記憶體 ABI，而非直接硬體暫存器。
  • 複雜度： A18 Pro 的 ABI 擁有約 1.5 倍於 M1/M2 ABI 的結構體數量，且指標數量是後者的兩倍，使其解碼難度大幅增加。
  • 方法：
    1. 即時探查： 使用 hypervisor 觀察 macOS GPU 活動，在韌體啟動後的第一個 "kick" 時擷取整個 GPU 記憶體狀態。
    2. 重放與簡化： 迭代修剪擷取的狀態，直到只剩下必要的最小資料，迫使 LLM 推斷結構體佈局。
    3. 針對性擷取： 對於計算工作，啟動進入單使用者模式，早期啟動一個小型 Metal 計算程式，並擷取其追蹤資料。
    4. 部分渲染： 生成觸發 TVB（Tiled Vertex Buffer）溢位的合成工作負載，然後重放並學習儲存與恢復協議。
  • 成果： 完整的 AGX 韌體 ABI 描述，發布於 agx-re 儲存庫中，使能夠與 RTKit 通訊的 Linux 核心驅動程式成為可能。

建立 Linux 核心驅動程式

  • 從原型到生產： 一個 Python 原型在三天內被重寫為 Rust，遵循現有的 drm-shim 設計。
  • 關鍵步驟：
    1. 將 drm-shim 移植到 Rust 以實現同步驅動程式。
    2. 將前端轉換為非同步，同時保持 GPU 提交為同步。
    3. 用與韌體通知綁定的事件驅動柵欄取代輪詢。
    4. 添加低層級優化，例如批次提交。
  • LLM 的角色： Codex 生成了大部分 Rust 骨架，並積極使用 hypervisor 快照來除錯不匹配，大幅加速了開發。

使用者空間堆疊（Mesa 整合）

  • 硬體優先 vs. Mesa 優先： 探索了兩種策略：
    • 硬體優先（Cody）： 徹底反向工程指令語義，然後撰寫規格讓 LLM 實現。
    • Mesa 優先（Niklas）： 增量式建立 Mesa 驅動程式，僅在需要缺失功能時才使用反向工程。
  • 結果： Niklas 的 Mesa 優先方法進展更快，因為它讓 LLM 專注於具體的驅動程式目標。
  • 關鍵元件：
    • IR/著色器編譯器： 從 Mesa 的 NIR 到 AGX ISA 的自訂編譯器，可重複用於 Vulkan。
    • 命令流建構器： 建構韌體消耗的緩衝區。
    • 功能發現： 識別了未記錄的硬體功能，例如原生 64 位元加法、128 向異向性、新的矩陣單元模式，以及 uniform_mov 的 7 位元立即數。
  • 符合性： OpenGL ES 3.0 CTS 通過，僅缺少可選擴展。

交付成果

剩餘工作與上游化挑戰

  • 功能路線圖： Vulkan 1.4、OpenGL 4.6、OpenGL ES 3.2、OpenCL 3.1、Direct3D 12（透過 Proton）以及光線追蹤。
  • 上游障礙： Asahi Linux 專案執行嚴格的禁止 AI 政策；M1/M2 驅動程式尚未上游化，因此 M4 驅動程式必須等待該先例。
  • 法律與社群疑慮： 一些評論者質疑當 LLM 可能是在專有二進位檔案上訓練時，乾淨室反向工程的合法性，並指出作者曾在 Apple 任職。
  • 需要人工審查： 在任何上游提交之前，都需要進行廣泛的測試、程式碼審查和重構。

社群反應（Hacker News 精選）

"他們能這麼快做出可運作的驅動程式，這令人印象深刻。我認為這是 LLM 最好的用例之一。" – ndiddy

"由於發文者是前 Apple 員工，所有這些工作都受到污染。Linux 不可能接受這些程式碼..." – thrwy19940314

"Asahi Linux 最大的痛點是 M3 及更新版本缺乏 GPU 加速。Asahi 的禁止 AI 政策意味著這些工作無法上游化。" – porphyra

"如果擔心，現在有人可以白盒重新實現這個。" – getcrunk

"一個之前不是驅動程式開發者的人能在幾週內實現這一點，純粹是奇蹟。把法律問題留給 Linux 基金會的律師。" – SXX

經驗教訓

  1. LLM 驅動的反向工程有效： 大型語言模型可以自主重放擷取的 GPU 狀態、推斷結構體佈局並生成驅動程式碼，大幅縮短反向工程週期。
  2. 早期擷取，保持精簡： 最可靠的擷取是在韌體啟動後立即進行，並包含最小工作負載（例如小型計算核心）。
  3. 任務優先級很重要： 在處理較難的功能（部分渲染）之前，指導 LLM 處理最簡單的缺失功能（計算），可以帶來更快的整體進展。
  4. 乾淨室紀律： 團隊避免了 Apple 二進位檔案，將任何所需的 blob 視為不透明，並發布所有追蹤資料，保留了可驗證的乾淨室流程。
  5. 社群政策影響採用： 具有嚴格反 AI 立場的專案（例如 Asahi Linux）可能會拒絕 LLM 生成的程式碼，儘管具有技術價值，但限制了上游潛力。

未來方向

  • 更廣泛的硬體支援： 將相同的方法應用於 M5 和未來的 Apple 晶片世代；使用者空間程式碼似乎具有高度可移植性。
  • Vulkan 前端： 利用現有的 NIR-to-AGX 編譯器來實現 Vulkan 驅動程式，使 Linux 上的現代圖形 API 成為可能。
  • 機器學習工作負載： 研究與 PyTorch 或 Metal Performance Shaders 的整合，以將 GPU 暴露給 AI 工作負載。
  • 開源治理： 與 Linux 基金會和 Asahi 維護者合作，定義 LLM 輔助驅動程式貢獻的政策。

本文基於 Cody Ho 的部落格文章「I Came, I Prompted, I Left Part 2: Building a GPU Driver From Scratch in One Month」以及得票最高的 Hacker News 評論。

Sources

相關