現代のハードウェア向けに機能的なGPUドライバを構築することは、多くの場合、数年を要する手動のリバースエンジニアリングを必要とする困難なエンジニアリングの課題です。AppleのSiliconにおいては、複雑なファームウェアABI（Application Binary Interface）を利用する「AGX」GPUアーキテクチャによってその難易度がさらに高まります。このシステムでは、Linuxカーネルドライバはハードウェアと直接通信するのではなく、カスタムのリアルタイムオペレーティングシステム（RTKit）を実行しているGPUファームウェアとやり取りします。M4 Mac MiniおよびMacBook Neo向けの新しいドライバの開発者たちは、特に手強い障壁に直面しました。A18 ProのファームウェアABIは、以前の世代よりも大幅に複雑化しており、構造体は1.5倍、ポインタは2倍存在するため、手動での再構築は極めて困難でした。
記事では、以前の世代と比較したA18 ProファームウェアABIの複雑さという手強い障壁について説明しています。
この課題を克服するため、チームはハードウェアトレースと「リプレイ」メカニズムを中心とした手法を採用しました。カスタムビルドされたハイパーバイザを使用することで、macOSがGPUとどのように相互作用しているかを正確に観察し、それらのハードウェアトレースをリプレイすることが可能になりました。これにより、特定の隔離されたキャプチャをLLM（Codex）に供給し、ファームウェアの共有メモリ構造を分解することができました。例えば、当初のリプレイが不可能であった336MBという巨大な計算トレースに直面した際、チームは「シングルユーザーモード」戦略へと転換しました。GUIなしで起動し、極めて小さな純粋な計算プログラムを実行することで、LLMが数日以内に使用可能なコードへと分解できる、より小さく管理可能なトレースをキャプチャしたのです。このプロセスは、ファームウェアとのインターフェースやバッファ割り当てを管理するカーネル空間と、シェーダコンパイラやコマンドストリームの構築を処理するユーザー空間の2つの半分に分割されました。
このプロジェクトは、複雑なエンジニアリングにおいてAIエージェントを使用する際の明確なトレードオフも浮き彫りにしました。著者は、LLMがフルアドレス空間を既知の良好なサンプルと比較するといった体系的なデバッグには非常に効果的であった一方で、「細かすぎる（pedantic）」側面もあったと指摘しています。ある開発者は、ハードウェアの完全性に焦点を当てたエージェントが、些細で重要ではない細部に固執して行き詰まることが多かったと述べました。対照的に、別の開発者は、まずMesaグラフィックススタックを構築する必要性に「接地（grounded）」されたエージェントを使用し、特定の機能を解放するために必要な時だけリバースエンジニアリングを行うことで、より迅速な進捗を得ました。完成したドライバはMinecraftを200fpsで動作させるのに十分な速度を持ち、ChromeやFirefoxでのWebGLをサポートしていますが、著者らは、このコードはまだ一般ユーザー向けの準備が整っているわけではなく、「部分レンダリング」のような複雑な機能は依然として非常に不安定で安定化が難しいことを明らかにしています。
テキストでは、ドライバがMinecraftを200fpsで実行するのに十分な速さであることが言及されています。
記事では、ドライバがChromeとFirefoxでWebGLをサポートしていることが記されています。
この急速な開発は、このようなコードの出所と将来に関する議論を巻き起こしています。このプロジェクトはプロプライアティハードウェアをナビゲートするためにLLMを利用したため、コードのアップストリームに対する厳格な「No-AI」ポリシーを維持しているAsahi Linuxのようなプロジェクトとの間で摩擦が生じる可能性があります。さらに、プロプライアティハードウェアとインターフェースするためのAI生成コードの使用は、結果として得られるバイナリの「汚染（tainted）」された性質や、そのような作業がいつか公式にLinuxカーネルに受け入れられる可能性があるかという疑問を投げかけています。現時点では、このプロジェクトは、AI支援のリバースエンジニアリングがハードウェア移植のタイムラインを数年から数週間に短縮できることを示す概念実証（proof of concept）として機能しています。