M4 Mac Mini向けLinux GPUドライバを1ヶ月でOpenGL ES 3.0対応にする方法

TL;DR

Cody HoとNiklasは、M4 Mac MiniおよびMacBook Neo向けの動作するOpenGL ES 3.0 Linuxドライバを約1ヶ月で実現し、大規模言語モデルを活用したリバースエンジニアリングが、何年もかかる手作業を代替可能であることを証明した。

プロジェクト概要

  • 目標: AppleシリコンGPU（M4、A18 Pro、M5）向けに、準拠したOpenGL ES 3.0ドライバ（将来はVulkan）をLinux上で構築すること。
  • スケジュール: 通常の新GPUドライバ開発が数年かかるのに対し、約4週間の集中作業で完了。
  • 主な成果: Chrome/FirefoxのWebGLデモが動作、Minecraftで200fpsを達成、Linuxカーネルドライバとユーザースペーススタックを完全に構築。
  • 手法: ハイパーバイザを用いたハードウェアトレースの取得と、LLM（Codex、GPT-5.6 Sol、GPT-6 Astra）を活用したABI発見、コード生成、体系的なデバッグを組み合わせたクリーンルームリバースエンジニアリング。

ファームウェアABIのリバースエンジニアリング（カーネル空間）

  • Appleのアーキテクチャ: GPUはカスタムRTOS（RTKit）を実行し、直接のハードウェアレジスタではなく共有メモリABIを公開している。
  • 複雑さ: A18 ProのABIはM1/M2のABIと比べて構造体が約1.5倍、ポインタ数が2倍に増加しており、解読が大幅に困難になっている。
  • アプローチ:
    1. ライブプロービング: ハイパーバイザを使ってmacOS GPUの動作を観察し、ファームウェア起動直後の最初の「キック」でGPUメモリ全体の状態をキャプチャ。
    2. リプレイと削減: キャプチャした状態を繰り返し縮小し、最小限の必要データだけを残すことで、LLMに構造体レイアウトを推論させる。
    3. ターゲットキャプチャ: コンピュート作業用に、シングルユーザーモードで起動し、小さなMetalコンピュートプログラムを早期に実行してトレースを取得。
    4. 部分レンダリング: TVB（Tiled Vertex Buffer）オーバーフローを引き起こす合成ワークロードを生成し、リプレイして保存・再開プロトコルを学習する。
  • 成果: AGXファームウェアABIの完全な記述をagx-reリポジトリに公開し、RTKitと通信可能なLinuxカーネルドライバの実現に成功した。

Linuxカーネルドライバの構築

  • プロトタイプから本番へ: Pythonで作成したプロトタイプを3日間でRustに書き直し、既存のdrm-shim設計に従った。
  • 主要ステップ:
    1. drm-shimをRustに移植し、同期ドライバを実装。
    2. フロントエンドを非同期化しながらGPU送信は同期的に維持。
    3. ポーリングを、ファームウェア通知に紐づいたイベント駆動型フェンスに置き換え。
    4. バッチ送信などの低レベル最適化を追加。
  • LLMの役割: CodexがRustの骨組みの大部分を生成し、ハイパーバイザスナップショットを積極的に活用して不一致をデバッグするなど、開発を劇的に加速した。

ユーザースペーススタック（Mesa統合）

  • ハードウェア vs Mesa第一: 2つの戦略を検討した：
    • ハードウェア第一（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がプロプライエタリバイナリで学習された可能性がある場合のクリーンルームREの合法性が疑問視されており、著者の元Apple従業員という経歴も指摘されている。
  • 人間によるレビューが必要: 上流への提出前に、広範なテスト、コードレビュー、リファクタリングが必要。

コミュニティの反応（Hacker Newsのハイライト）

"彼らがこれほど迅速に動作するドライバを作れたのは非常に印象的だ。これはLLMの最も良い活用例の一つだと思う。" – ndiddy

"このすべての作業は、元Apple社員が投稿したため、汚染されている。Linuxはそのコードを受け入れるはずがない..." – thrwy19940314

"Asahi Linuxの最大の課題は、M3以降でGPUアクセラレーションが利用できないことだ。AsahiのAI禁止ポリシーにより、この作業はアップストリーム化できない。" – porphyra

"誰かが懸念するなら、ホワイトボックスで再実装できる。" – getcrunk

"以前ドライバ開発経験のなかった人物が数週間でこれを達成できたという事実は、純粋な驚きである。法的問題はLinux Foundationの弁護士に任せよう。" – SXX

学びと教訓

  1. LLM駆動のREは有効: 大規模言語モデルは、キャプチャしたGPU状態を自律的にリプレイし、構造体レイアウトを推論し、ドライバコードを生成できる。リバースエンジニアリングのサイクルを劇的に短縮できる。
  2. 早期キャプチャ、最小化を徹底: ファームウェア起動直後に取得したキャプチャが最も信頼性が高く、最小限のワークロード（例：小さなコンピュートカーネル）を含むべき。
  3. タスクの優先順位が重要: 難易度の高い機能（部分レンダリング）に取り組む前に、最も単純な欠落機能（コンピュート）に集中することで、全体的な進捗が速くなる。
  4. クリーンルームの徹底: Appleのバイナリを一切使用せず、必要なブロブは不透明なものとして扱い、すべてのトレースを公開することで、検証可能なクリーンルームプロセスを維持した。
  5. コミュニティポリシーが採用に影響: 厳格なAI禁止ポリシーを持つプロジェクト（例：Asahi Linux）は、LLM生成コードを拒否する可能性があり、技術的優位性があってもアップストリーム化の可能性が制限される。

今後の方向性

  • 広範なハードウェア対応: 同じ手法をM5および将来のAppleシリコン世代に適用。ユーザースペースコードはほぼ移植可能である。
  • Vulkanフロントエンド: 既存のNIR-to-AGXコンパイラを活用し、Vulkanドライバを実装。Linux上で現代的なグラフィックスAPIを可能にする。
  • 機械学習ワークロード: PyTorchやMetal Performance Shadersとの統合を調査し、GPUをAIワークロードに活用可能にする。
  • オープンソースガバナンス: Linux FoundationおよびAsahiメンテナと協力し、LLM支援ドライバ貢献のためのポリシーを策定する。

この記事はCody Hoのブログ記事「I Came, I Prompted, I Left Part 2: Building a GPU Driver From Scratch in One Month」およびHacker Newsで最も高評価されたコメントに基づいている。

Sources

関連