M4 Mac MiniのためのLinux GPUドライバを1ヶ月で構築する

2026年9月16日原文(codyho.dev)

概要

Apple Silicon 向けにOpenGL ES 3.0対応GPUドライバを約1ヶ月で開発
AGXファームウェアABI とユーザースペースの逆アセンブルが主な課題
Hypervisor を活用したクリーンルームリバースエンジニアリング手法を採用
カーネルドライバ と ユーザースペースドライバ の両方を自作
Chrome/FirefoxのWebGL動作 や Minecraft 200fps 動作を実現

M4 Mac Mini/MacBook Neo向けGPUドライバ開発の舞台裏

OpenGL ES 3.0完全準拠 のGPUドライバを約1ヶ月で開発
- 通常は数年かかる作業を大幅短縮
Chrome/FirefoxのWebGL や Minecraft 200fps 動作を確認
AGX（Apple GPU）ファームウェアABI とユーザースペースの複雑な仕様を逆アセンブル
クリーンルーム手法 による透明性と検証性の確保
- Appleバイナリには一切依存せず、ハードウェアトレースと自作シェーダのみ利用
- 必要なApple blobはブラックボックスとして扱い、外部による文書化を利用
成果物と実験内容を公開 し、検証可能性を担保

カーネルスペースでの課題とアプローチ

Apple Silicon ではカーネルドライバが直接ハードウェアと通信せず、 RTKit 上のGPUファームウェアと通信
ファームウェアABIの解析 が最初の難関
- Appleはカーネルドライバを半分に分割し、片方をファームウェアに、もう片方をカーネルに配置
- 共有メモリ構造体にはファームウェア管理フィールドとホスト管理フィールドが混在
M1/M2と比べてA18 Pro（M4）ABIはさらに複雑化
- 構造体数1.5倍、ポインタ数2倍、ワーク送信プロセスも複雑
リバースエンジニアリング手法
- macOSの動作を観察・再現し、ハイパーバイザーでメモリ状態をキャプチャ・リプレイ
- 逐次的な実験で必要なオブジェクトやポインタ構造を解析
主な問題点と解決策
- レンダー作業のキャプチャ ：ファームウェア起動直後の状態をキャプチャすることで解決
- コンピュート作業のキャプチャ ：GUIを無効化し、Metalプログラムで最小限のトレースを取得
- パーシャルレンダー ：TVB容量不足時の部分描画処理の再現と自動化
Linuxカーネルドライバ移植
- PythonプロトタイプからRustによるdrm-shim実装
- 非同期フロントエンドへの書き換え、ファームウェアイベントによるワーク管理
- バッチ処理などの最適化も実施

ユーザースペースでのリバースエンジニアリング

A18 Proユーザースペース はM1/M2と大きく異なる設計
- 新しいディスクリプタ形式、新ISA、Metal向け設計
リバースエンジニアリングの流れ
- 小さなMetalプログラムを作成・実行、ビット単位で変化を観察
- コマンドストリームやディスクリプタ、ISAの解析
LLM（Claude）活用
- Metalプログラムの逆アセンブル・アセンブル、ディスクリプタ解析
- ただし、独自のプログラム生成やISA理解は難航
チーム開発
- drm-shim開発者Niklasが合流し、ユーザースペース解析を加速

技術的・運用的な工夫

クリーンルーム実装 の徹底
- Appleバイナリやコードを一切参照せず、ハードウェア挙動と自作ツールのみで解析
ハイパーバイザー を用いた動的トレースと比較
- メモリ空間の完全キャプチャと既知の良好サンプルとの比較によるデバッグ
LLM（Codex/Claude）による自動化・補助
- コード生成、デバッグ、トレース解析などに積極活用
- 部分的な失敗や戦略ミスもあったが、全体として大幅な効率化を実現

今後の展望と公開状況

エンドユーザー向けリリース に向けたブラッシュアップを進行中
Vulkan対応 も今後の目標
agx-reリポジトリ に実験・成果物を公開し、オープンな開発体制を維持

Hackerたちの意見

もしかして、俺も年取ったのかな。時代が変わってるのは分かるけど、これが動くっていうのはマジで驚きだよ、まるで黒魔術みたい。慣れるとは思うけど、まだ自分の中で何が可能かっていうモデルが完全に書き換えられてないんだよね。

└

俺もまだ信じられないよ！

これ、めっちゃいいね！Asahi Linuxの一番の問題点は、M3以降のGPUアクセラレーションがないことだよね。特にM6が出た今は余計に！でも、Asahi LinuxはAI禁止のポリシーがあるから、この素晴らしい成果はアップストリームに行けないんだ。多くの人はとにかく動かしたいだけだから、AIを使ったフォークが新しいハードウェアでスムーズに動くのが主流になると思う。一方で、ほんの一握りの純粋主義者だけが古いハードウェアで動いてる非AI版を使い続けるんじゃないかな。 [1] https://asahilinux.org/llm-policy/

└

でも、彼らか他の誰かがその発見をもとに本物のドライバーを書くことができると思うよ。難しいのは、ブラックボックスシステムをリバースエンジニアリングすることだったからね。

└

:) ここにはサプライズが待ってると思うよ。AsahiがApple Silicon用のLinuxを独占してるわけじゃないし、アップストリームのLinuxは絶対にLLMを禁止してないからね。

└

Asahiの長期的な目標は、可能な限りすべてを（実際に）アップストリームプロジェクトに統合することだから、どのディストロでも動くようにしたいんだ。個別の違いのためだけにフォークが増えるよりも、その流れが続くといいなと思うよ（残りの作業セクションを見る限り、彼らはちゃんとしたアップストリーミングを目指してるみたいだし）。

こんなに早く動くドライバーを作れるなんて、ほんとにすごいよね。これはLLMの最高の活用例の一つだと思う。もう誰かが何年もかけて未文書のハードウェアをリバースエンジニアリングする必要はないんだ。LLMが作ったドライバーがどれだけ優れているのか、そしてそれがLinuxカーネルにアップストリームできるかどうかを見るのが楽しみだね。

└

LLMが成功するために必要な数少ないユースケースの一つかもしれないね。この規模と「秘密性」の技術をリバースエンジニアリングする苦労なんて想像できないよ。

└

今日のモデルで感じる問題は、使い捨てのソフトウェアを生み出してしまうことだね。ちゃんとした設計で、耐久性のあるソフトウェアを作るのが苦手なんだ。メンテナンスやバグ修正ができるようなやつね。使い方を知っててうまく導けばいいものが出てくるけど、「これが回帰テストだ。通る実装を書いて」って言うだけだと、しばらくは動くけどすぐに古くなって捨てなきゃいけなくなるものができちゃう。

└

チップを作った人たちやAppleのドライバーを書いた人たちから助けをもらえるなら、すごく簡単なんだろうね。

私は著作権の弁護士じゃないから、元Apple社員からのこういうコードを上流プロジェクトが受け入れるのがいいアイデアかどうか、誰か教えてくれない？特にAppleが今OpenAIを訴えてるからね。

└

いい観察だね、二つのことを言いたい。- Appleにいた時、macOSのソースコードは一切見たことがなかった。ユーザースペースのコンポーネントですらね。SPTMみたいなものも聞いたことがなかった。 - 2025年6月以降はそこで働いてないから、元Appleの雇用がリスクになるとは思わないよ。別の例で言うと、WINEは元Microsoft社員を全員禁止してるわけじゃなくて、Windowsのソースコードを見たことがある人だけを禁止してる。もしAppleでの雇用が内部の秘密に触れる可能性があるなら、コミュニティプロジェクトには貢献しないだろうね。

Hacker Newsで議論の続きを見る

ハクソク