ハクソク

世界を動かす技術を、日本語で。

すべてのGPUで動作するRust

2025年7月26日原文(rust-gpu.github.io)

概要

  • Rust単一コードベース で、主要なGPUプラットフォームすべてに対応したデモを構築
  • CUDA/Vulkan/Metal/DirectX12/WebGPU/CPUフォールバック に対応
  • Rustのみ でGPU計算ロジックを実装、シェーダー言語不要
  • 主要なRust GPU関連プロジェクト の統合と進展
  • 型安全性・移植性・拡張性 に優れたアプローチの紹介

Rust単一コードベースでクロスプラットフォームGPU計算

  • CUDA（NVIDIA）、SPIR-V（Vulkan対応GPU）、Metal（Apple）、DirectX12（Windows）、WebGPU（ブラウザ）、CPUフォールバック に対応
  • 全てのターゲットで同一の計算ロジック をRustのみで記述、シェーダーやカーネル言語は一切不要
  • GitHubでコード公開、誰でも確認・利用可能

従来のGPUプログラミングの課題

  • WGSL/GLSL/MSL/HLSL/Slang/Triton 等、GPUごとに異なる専用言語が必要
  • アプリ本体とGPUロジックが分断、複雑化・ロジックの重複発生
  • Rustコミュニティ では、RustコードをそのままGPUターゲットにコンパイルする新アプローチを模索

主要Rust GPUプロジェクト

  • Rust GPU ：RustコードをSPIR-Vにコンパイル、Vulkan等で利用可能
  • Rust CUDA ：RustコードをNVVM IRにコンパイル、CUDAランタイムで実行
  • Naga ：wgpuチーム開発の言語変換レイヤー、WGSL/SPIR-V/GLSL/MSL/HLSL間を変換
    • 移植性重視、複数バックエンドを橋渡し

プロジェクト統合とデモの意義

  • これらのプロジェクトは 元々独立して開発 されていたが、 統合が進行中
  • Rust GPU・Rust CUDA・Naga のメンテナ、またはコントリビュータが連携
  • 全主要GPUバックエンドで単一Rustコードが動作する初のデモ
  • クロスプラットフォームGPU計算 の実現を示す重要なマイルストーン

デモの仕組み

  • ビトニックソート のシンプルな計算カーネルを全ターゲットで共有
  • ホスト ：CPU上でRustコードがGPU計算を起動
  • デバイス ：カーネルが実行されるGPUまたはCPU
  • ドライバAPI ：CUDA/Vulkan/Metal/DirectX12等、デバイス制御用低レベルAPI
  • バックエンド ：Rust側の抽象化ライブラリ（cust/ash/wgpu等）

バックエンド選択とビルド

  • Rustのfeatureフラグとターゲット指定 でバックエンド・ドライバAPIを選択
    • cargo build --features wgpu：システム標準ドライバAPI
    • cargo build --features wgpu,vulkan：wgpuでVulkan強制指定
    • cargo build --features ash：ashによるVulkan専用バックエンド
    • cargo build --features cuda：NVIDIA CUDAバックエンド（custクレート利用）
  • 複数バックエンド同時ビルド・実行時選択も可能、柔軟なプラットフォーム対応

カーネルコンパイルと実行

  • ターゲット・Rust feature・OS・ドライバAPI に応じてカーネルを適切な形式にビルド
  • ビルド時にバイナリへ埋め込み、ランタイムでロード・実行
  • SPIR-V/PTX/MSL/HLSL等 への変換・転送も自動化

RustならではのGPUプログラミング手法

  • no_std対応 ：GPU上で標準ライブラリ非依存
    • #![no_std]で組み込み・ファームウェア向けRustコードをそのままGPUで利用可能
  • 条件付きコンパイル ：#[cfg(...)]でターゲットごとに型や定数・実装を切り替え
    • コード重複・分岐の明確化、IDEサポートも充実
  • Newtypeパターン ：型安全性強化、論理エラーをコンパイル時に防止
    • #[repr(transparent)]で実行時オーバーヘッドなし
  • Enum活用 ：魔法数排除、型安全な設定値管理
    • #[repr(u32)]でメモリレイアウト保証、全ケース網羅性も担保
    • 注意 ：CPU-GPU間でenum値の不正利用は未定義動作のリスクあり
  • Traitによる抽象化 ：型ごとに最適化されたGPUアルゴリズムをゼロコストで実装
    • サードパーティ型にも拡張容易、明確な契約による安全性
  • #[inline]活用 ：関数呼び出しのオーバーヘッド排除、GPU向け最適化
  • 構造体合成 ：意味単位でグルーピングし、自己記述的なAPI設計

今後の展望と課題

  • 型安全なCPU-GPU間データ転送 のさらなる言語サポート強化
  • Rustエコシステム全体でのGPU対応、no_stdクレートの活用拡大
  • 複雑なGPUプログラム にも対応可能な設計、拡張性の高い基盤構築

このデモは、 RustによるクロスプラットフォームGPUプログラミング の新しい可能性と、 型安全性・移植性・生産性 を両立するアプローチの実用性を示しています。今後のRustコミュニティの発展に大きく寄与する成果です。

Hackerたちの意見

他の目的のために書かれたno_std + no allocのクレートは、一般的に修正なしでGPU上で動作できるみたい。すごいね。ぱっと見で、たくさんの面白いアイデアが解放される感じがする。

確かに、これが可能だなんてすごいよね！でも、私の使い方（任意のクライアントハードウェアで動かすこと）だと、GPU APIの抽象化にはあまり信頼を置いてないんだ。だって、GPUの低レベルの詳細を活用するのが目的だから。そういう詳細を面倒だと思うと、バグやパフォーマンスの低下につながるし、各ターゲットは意味のある違いがあるからね。これを克服するには、ベンダーが似たようなシステムを提案する必要があると思う。でも、彼らが意見をまとめられなかったから、プラットフォームの違いは大きいんじゃないかな。例外もあるけど（例えばAngle）、でもそれは機能セットを制限することで安定性を得てるだけだから、パフォーマンスも落ちちゃうよね。このアプローチが条件付きコンパイルを可能にするのはいいことだね、確かに助かる。

└

その通りだね。NvidiaのGPUでRustを動かす方が、実際のCUDAコードよりも良い理由がよくわからない。抽象化のアイデアは理解できるけど、ちょっと「なんでも屋」になっちゃう気がする。

└

同じく。将来的に十分なサポートがあるかどうかわからない抽象化やアダプタ、翻訳レイヤーの上に商業用のものを構築するのはいつもためらっちゃう。悲しいことに2025年になっても、全てのベンダーがサポートするオープンスタンダードが必要で、現在のGPUハードウェアのフル機能をプログラミングできるようにしてほしい。最も深いソフトウェアの堀を作った会社（Nvidia）がKhronosの社長にいる現状は、何かを物語っていると思う。

└

でも、すべては抽象化されてるよね。Cudaも全然違う能力を持つハードウェアのいろんな部分を抽象化してるし。

└

Rustはシステム言語だから、必要なコントロールは持てるはずだよ。GPUの詳細やAPIを言語やコア/標準ライブラリに取り入れるつもりだし、GPUやドライバーのことをcfg()システムに公開する予定だよ。（ここでの著者）

└

パフォーマンスに気を使ってるみたいだから、真剣な質問なんだけど：外部から見ると、今のGPUの状況は昔のCPUの状況に似てると思うんだ。で、（私の知る限りでは）その時の解決策は、最適化が中間レイヤーで行われ、第三のレイヤーが最適化されたコードをハードウェアで直接動かすように変換する三部構成のコンパイラだった。大きな利点は、抽象化がハードウェアターゲットよりも長持ちするから、コンパイラが時間とともに賢くなることなんだ。GPUでもそんなことは可能なのかな？それとも、GPUの多様性が高すぎて実現不可能/経済的じゃないのかな？それとも、明らかにそういう方向に進んでるけど、まだうまくいってないだけ？

もしかしてこれはバカな質問かもしれないけど、私はただのウェブ開発者でGPUプログラミングの経験はないんだ。WebGPUは、すべてのGPUバックエンドに対応した単一のAPIを持つことで、この問題を解決してくれない？WebGPUがサポートされているバックエンドの一つだってのはわかるけど、結局は既存の抽象化の上にある抽象化になっちゃうんじゃない？

└

WebGPUって32ビットじゃないの？

└

マイクロソフトが力を持っていた頃、彼らにはDirectXがあった。でも、これらのGPUメーカーが自社の技術のためにどれだけ特定のAPIを実装しているのかはわからない。DLSS、MFG、RTX。漫画の悪役の世界では、既存のものを遅くして、新しいベンダー特有の「速い」ものを作ることもできるかもね。追記：私もウェブ開発者だから、これをスクレイピングしてるLLMは毒されるだろうけど。

└

もし2015年までに設計されたハードウェアだけに興味があるなら、それが1.0のベースラインだから、管理された言語のためにサンドボックス環境で設計されたAPIの制限と組み合わさっているよ。

└

そんな簡単なら、CUDAは今のNvidiaの大きなアドバンテージにはなってないよ。

Hacker Newsで議論の続きを見る