2026/02/12 23:17
未来のTyr：ARM Maliハードウェア向けRust製GPUドライバ
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
概要：
Tyrは2025年に開発が始まったArm Mali GPU用のRustベースドライバです。Arm、Collabora、およびGoogleによる共同プロトタイプはLinux Plumbers ConferenceでSuperTuxKartを実行し、有望なパフォーマンスを示しました。6.18カーネルマージには限定的なTyr実装が含まれていますが、下流のコードベースには完全なプロトタイプがありながらも、電力管理制御、GPUリカバリルーチン、完全なメモリ分離（GEM shmemオブジェクト、GPUVM/IOMMUページテーブル）、そして適切なフェンス完了処理といった重要機能が欠けており、メモリ圧力下でデッドロックを引き起こす可能性があります。Rust採用の緊急性は、Dave AirlieによるDRMがまもなく新しいCドライバを禁止するという発表により推進されており、カーネルコミュニティはRustなどの安全な言語へと移行しています。Tyrのロードマップには、レガシー
をファームウェア支援型のJobQueueコンポーネント（Philip Stanner が主導）に置き換え、ドライバをテストベッドとして使用し、Cドライバから呼び出せるAPIを公開することが含まれており、Rust相互運用性にとって重要なマイルストーンとなります。成功すれば、TyrはモバイルMali GPU向けの堅牢で電力効率の高いRustドライバを提供し、将来のカーネルGPUドライバ設計の先駆例となるでしょう。drm_gpu_scheduler
注記： 改訂された概要では、SuperTuxKart、フェンス完了リスク、欠落した抽象化に対する寄与者名を明示し、新たな推論を加えることなくメインメッセージを明確に保っています。
本文
LWN を試してみませんか？
LWN（Linux Weekly News）への購読により、Linux とフリーソフトウェアコミュニティで何が起きているのかを常に把握し、購読者限定機能を活用することができます。今回、クレジットカードは不要で無料トライアルをご提供しますので、自分の目で確かめてください。ぜひご参加ください！
2025 年に始まった Tyr の取り組み
Tyr は、Arm Mali 用の Rust GPU ドライバを作ることを目的に 2025 年に設立されました。年末には Linux Plumbers Conference（LPC）で SuperTuxKart（3D オープンソースレーシングゲーム）を実行できたことが最大の成果です。このプロトタイプは Arm、Collabora、Google の共同作業で構築され、イベント中に安定して動作し、プレイヤーには十分なパフォーマンスを提供しました。さらに、Dave Airlie が Maintainers Summit で「DRM サブシステムが C で書かれた新しいドライバの導入を禁止するまで、約一年程度しかない」と発表したことで、正しいタイミングで勢いを増してきました。今こそ、このすべての作業を upstream に統合し、2026 年のロードマップを策定する時です。
Tyr で何を達成したいか？
Miguel Ojeda の LPC での講演では、Linux カーネル内で Rust がどこに使われているかが紹介されました。Android 用の匿名共有メモリサブシステム（ashmem）など、数百万ユーザーへ迅速に展開されたドライバ例があります。Mali はスマートフォン市場で大きなシェアを持つため、このセグメントへの対応は Tyr の自然な目標です。その後、Mali が搭載されている他の組込みプラットフォームもサポート対象となります。一方で upstream への貢献を忘れずに進めることが重要です。Nova Rust GPU ドライバと共に進化し、将来登場する可能性のある新しいドライバにも役立つエコシステムを確立することが目的です。
プロトタイプは「Arm Mali 用の Rust ドライバが実現できるか」そして「十分なパフォーマンスを発揮できるか」を証明するために作られました。今後はコードを反復し、必要に応じてリファクタリングしていきます。これにより失敗から学び、 upstream 用ドライバとして適切な設計へと落ち着けるようになります。
何があり、何がないか？
Tyr ドライバの一部は 6.18 カーネルリリース向けにマージされましたが、いくつか重要な Rust 抽象化が欠如しているため、大きな機能を提供できません。下流ブランチ（メインラインカーネルにはまだ統合されていない Tyr の部分）は最新プロトタイプをホストしています。このプロトタイプはデスクトップ環境やゲームをサポートする程度に十分動作しますが、電力消費と GPU 復旧の問題は残っています。プロトタイプは upstream 努力の指針となり、さまざまな設計を試す場として活用されます。
Tyr のようなカーネルモード GPU ドライバは、Vulkan や OpenGL などのグラフィックス API を実装するユーザーモードドライバを裏付ける小さなコンポーネントです。ユーザーモードドライバはハードウェアに依存しない API 呼び出しを GPU 固有のコマンドへ変換します。カーネル側の役割は、アプリケーション間でハードウェアリソースを共有し、隔離と公平性を確保し、ハードウェアを稼働状態に保つことです。GPU メモリの提供、ジョブ完了時の通知、ジョブ間の依存関係を記述する手段をユーザースペースへ与えることが求められます。LPC2025 での講演（YouTube 動画）ではこれについて詳しく説明しています。
プロトタイプが動作しているからといって、実運用に耐えうるとは限りません。欠けている要素を検証すると、Mali GPU は主にモバイルデバイスで使用されるため電力効率と熱管理が極めて重要です。しかし Tyr には現在、電力管理や周波数スケーリングのコードが存在しません。さらに Rust 抽象化がまだ提供されていないため、これらの機能を実装することもできません。
GPU のハング（停止）についても懸念があります。システムは可能な限り機能し続ける必要があり、そうでなければユーザーは作業を失う恐れがあります。プロトタイプ段階では GPU 復旧コードがありません。電力管理と復旧はデプロイメントに不可欠です。バッテリーを大量消費したり、発熱し過ぎたり、クラッシュするドライバは配備できません。
さらに、Vulkan が Tyr 上で正しく実装される必要があります。そうでなければ、C ドライバ（PanVK）との drop‑in 互換性を達成できません。Vulkan Conformance Testing Suite を通過させることが目標です。これに成功すれば、現在サポートしている Mali‑G610 を超える GPU モデルへの拡張も自信を持って行えます。最後にベンチマークを実施し、Rust の安全性保証と同時に C ドライバのパフォーマンスに匹敵することを確認します。複雑なゲームを走らせた際には十分な性能が得られました。
どの Rust 抽象化が不足しているか？
以下のインフラストラクチャはまだ開発中です。
- Lyude Paul の GEM shmem オブジェクト
ディスクリート VRAM を持たないシステム向けにメモリを割り当てるために必要です。Tyr にとって重要で、GPU が SoC 内にあるためシステムメモリを共有する必要があります。 - ロックなしで GPU バッファの非重複領域を共有
型システムで表現し、コンパイル時に検証できるようにしたい。詳細は未解決です。 - GPUVM と I/O‑pgtable 抽象化
DRM エコシステムでは GPUVM が GPU アドレス空間を管理します。Rust での抽象化は Alice Ryhl が取り組んでおり、IOMMU ページテーブル操作に必要な io‑pgtable を構築中です（Asahi Lina の以前の作業に基づく）。 - DRM デバイス初期化
現在のコードではドライバ固有データを初期化するために
が必要ですが、逆にdrm::Device
を構築する際にドライバ固有データが必要となる循環参照があります。Tyr では GEM shmem API を通じて GPU メモリを割り当てるためにdrm::Device
が必要です。一方で Tyr のプライベートデータには GEM オブジェクト（例：ファームウェアの解析・起動）が格納されます。Lyude Paul は型システムでデバイス状態をエンコードするdrm::Device
を導入してこの問題に対処しています。drm::DeviceCtx
最初の Tyr パッチが提出された当時と同じく、GEM shmem、GPUVM、io‑pgtable、およびデバイス初期化の課題がロードマップをブロックしています。Nova チームの
register!また、フォーシン（fence）完了への前進パスも検討が必要です。フォーシングは GPU ジョブが実行完了した際にユーザー側へ通知する同期プリミティブです。このパスを正しくアノテーションしないとデッドロックのリスクがあります。また、DMA フォーシングは有限時間で必ずサインアウトされる必要があります。
GFP_ATOMIC今後の展望
Linux GPU ドライバ全体として、ジョブ提出ロジックを Rust で再設計することについて触れていません。現在の設計では
drm_gpu_schedulerRust 社では「JobQueue」と呼ばれる新しいコンポーネントを作成し、ジョブが GPU のリングバッファに割り当てられる前に依存関係が満たされているかだけを保証する設計が主流です。GPU ハードウェアは近年、ファームウェア支援スケジューリングへシフトしており、多くのベンダーがこの方向に移行しています。このコンポーネントはジョブ自体をスケジュールしないため、
JobQueueまた、C ドライバ向けの API を公開する計画もあります。過去に説明した手法を利用すれば、Rust カーネルコンポーネントを C ドライバから呼び出せるようになります。これは Rust がカーネルで使用できる最初のコンポーネントとなり、C と Rust のシームレスな相互運用性を示すマイルストーンです。
Tyr はこのビジョンに合致し、新しい設計のテストベッドとして機能できます。古い
drm_gpu_schedulerJobQueueまとめ
Tyr は過去一年で多大な進展を遂げました。2026 年以降も継続的に発展し、最終的には完全な upstream ドライバとして Linux カーネルに統合されることを期待しています。
（インデックスエントリ：GuestArticlesAlmeida, Daniel）