Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — リリースノートの見出しに載らなかった一行
nvptx64 ターゲットとは何か
何が変わったか — 正確な数字
なぜ切り落としたか — 三つの具体的な欠陥
カットラインはなぜ CUDA 11 なのか
誰が壊れて、何をすべきか
それで、これを実際に使っている人はいるのか — 2026年の Rust-on-GPU の地形
正直なトレードオフ — そして、いつ使うべきでないか
おわりに
参考資料

はじめに — リリースノートの見出しに載らなかった一行

Rust 1.97.0 は2026年7月9日に出ました。リリースノートの見出しは三つでした — v0 シンボルマングリングの stable デフォルト昇格、Cargo の build.warnings 設定、これまで隠れていたリンカー出力の可視化。この三つは数日前の記事ですでに整理しています。

ところが、同じリリースの Platform Support セクションには、見出しに載らなかったもう一行がありました。

nvptx64-nvidia-cuda: drop support for old architectures and old ISAs   (PR #152443)

面白いのはここです。三つの見出しはすべて後方互換を保つ変更でした。シンボルマングリングが変わってもコードはそのままビルドでき、警告設定はオプトインで、リンカー出力はただ見えるようになっただけです。それに対してこの一行は、1.97で唯一何かを実際に壊す変更です。ただ、壊れる人がごくわずかというだけです。

そしてこの変更の背景には、「Rust で GPU カーネルを書く」という、2026年に入って急に静かではなくなった話が横たわっています。

nvptx64 ターゲットとは何か

nvptx64-nvidia-cuda は、rustc が NVIDIA GPU 向けのコードを吐き出すターゲットです。ここから出てくるのは機械語ではなくPTXです — NVIDIA の仮想 ISA で、CUDA ドライバーが実行時に実際の GPU の SASS へ JIT コンパイルします。rustc は LLVM の NVPTX バックエンドを通じてこの PTX を生成します。

rustc プラットフォームサポート文書によれば、このターゲットの性格はこうです。

Tier 2 ターゲットで、メンテナーは @kjetilkjeka 一人です。
no_std ターゲットです。デフォルトのリンカーは llvm-bitcode-linker で、PTX を得るには crate-type を cdylib にしてビルドします。
カーネル関数は extern "ptx-kernel" で宣言します。
文書のビルド例は nightly を使っています。

$ RUSTFLAGS='-Ctarget-cpu=sm_89' cargo +nightly rustc \
    --target=nvptx64-nvidia-cuda -Zbuild-std=core --crate-type=cdylib

Tier 2 が何を保証するかは、ターゲットティアポリシーに正確に書かれています — "Rust's continuous integration checks that tier 2 targets will always build, but they may or may not pass tests."。つまりビルドは保証するが、テストの通過は保証しません。Tier 1 が「ビルド + テスト通過」の両方を保証するのとの違いはここです。この一文を覚えておいてください。なぜ欠陥が積み重なったのかを説明する鍵になります。

何が変わったか — 正確な数字

2026年5月1日、ターゲットメンテナーの Kjetil Kjeka が予告記事を投稿しました。記事の言葉どおり、新しい最小要件はこうです。

"The new minimum supported versions will be: PTX ISA 7.0 (requires a CUDA 11 driver or newer) SM 7.0 (GPUs with compute capability below 7.0 are no longer supported)"

rustc 文書の表に置き換えると、変化の大きさが一目でわかります。

Rust バージョン	SM 最小	PTX ISA 最小
~ 1.96	2.0	3.2
1.97 ~	7.0(Volta+)	7.0(CUDA 11+)

SM 2.0 から 7.0 へ。これは段階的な調整ではなく、一度に一世代まるごと取り払ったものです。予告記事の表現では "Until now, Rust has supported emitting PTX for a wide range of GPU architectures and PTX ISA versions." であり、その "wide range" が今や Volta 以降に絞られました。

コンピュート能力の番号とアーキテクチャ名の対応は、5.x が Maxwell、6.x が Pascal、7.0 が Volta です。つまり切り落とされたのはMaxwell と Pascal 全体です — NVIDIA のレガシー GPU リストによれば、GTX 1080(6.1)、Tesla P100(6.0)、Jetson TX2(6.2)といったものです。Tesla V100 と TITAN V が 7.0 で生き残る最初の世代になります。

参考までに、NVIDIA の現行 GPU リストはすでに 7.5 から始まっており、それより下はレガシーページに移されています。Rust が引いた 7.0 のラインは、NVIDIA 自身が「現行」と呼ぶラインよりもむしろ一段下です。

なぜ切り落としたか — 三つの具体的な欠陥

ここがこの変更の本当の中身です。予告記事は理由をこうまとめています。

"In practice, several defects existed that could cause valid Rust code to trigger compiler crashes or miscompilations."

有効な Rust コードがコンパイラのクラッシュや誤ったコンパイルを引き起こしていたという意味です。miscompilation は静かに間違ったコードを吐き出すので、クラッシュより悪いものです。

「several defects」が何かは予告記事には書かれていませんが、この変更を通したコンパイラチーム MCP #965に具体的に記されています。2026年2月1日に開かれ major-change-accepted として処理された提案で、根拠として三つのイシューが挙げられています。

rust-lang/rust#147672 — PTX ISA 7.0 未満では、デバッグシンボル生成に LLVM 側の制約があります。
rust-lang/rust#150515 — SM 7.0 より古いアーキテクチャでは、アトミック順序(atomic ordering)が十分にサポートされていません。
rust-lang/rust#141468 — PTX ISA のバージョン体系が Rust の target-feature メカニズムと噛み合っていません。

三番目から見ると、問題の性格が浮かび上がります。Rust の -C target-feature は「この機能がある/ない」という集合モデルです。ところが PTX ISA のバージョンは集合ではなく線形なバージョン番号です。二つのモデルはそもそもずれており、サポート範囲が広いほど、このずれが生む組み合わせ爆発も大きくなります。

しかし核心は二番目です。MCP の根拠をそのまま移すと、SM 7.0 未満ではアトミック順序が十分にサポートされておらず — SM 7.0 以上は公式に保証されるが、それ以前は best-effortだということです。これが Rust にとってなぜ致命的かというと、Rust のメモリモデルにおいて core::sync::atomic の acquire/release セマンティクスはオプションではないからです。C++ であれば「その GPU ではアトミックを使わないでください」で済ませられる問題が、言語レベルで順序保証を約束している Rust では、言語自身の約束が破られる問題になります。誤ったコンパイルが出るというのはまさにこの意味です。(ちなみに Volta はワープ内の独立スレッドスケジューリングを導入した世代でもあります — SM 7.0 がカットラインになったのは偶然ではありません。)

つまりこれは「古いハードウェアの整理」ではなく、守れない約束を取り除いたものです。予告記事の文章もそう読めます — "Raising the baseline addresses these issues and enables more complete support for the remaining supported hardware."。広くて壊れたサポートより、狭くて完全なサポートを選んだわけです。

そしてこれは先に見た Tier 2 の定義と正確につながっています。ビルドは CI が守るがテスト通過は保証しないターゲットで、実際にハードウェアを持って回してみることのなかった古いアーキテクチャの欠陥が、何年も静かに積み重なっていたのです。

カットラインはなぜ CUDA 11 なのか

MCP がバージョン選択の根拠として挙げた文はこうです — "CUDA versions older than 12 are end-of-life, and PTX ISA 7.0 is supported starting with CUDA 11.0."

読んでみると、二つの文が異なる線を指しています。EOL の論理だけに従えばカットラインは CUDA 12 であるべきですが、実際に設定されたのはCUDA 11(PTX ISA 7.0)です。つまり EOL の論理が許すよりも一段保守的に設定されています。欠陥をなくすのに十分なだけ引き上げつつ、必要以上には切らなかった選択に見えます。

MCP は NVIDIA 側の現状も根拠として併記しています — CUDA 13 は SM 7.5〜12.1 を、CUDA 12.9 は SM 5.0〜12.1 をサポートします。興味深い点です。Rust が設定した SM 7.0 のカットラインは、最新の CUDA 13 がすでに切り落としたライン(7.5)よりもむしろ寛容です。

誰が壊れて、何をすべきか

予告記事はこう案内しています。

"If you do not specify -C target-cpu, the new default will be sm_70, and your build should continue to work (but will no longer be compatible with pre-Volta GPUs)."

"If you currently specify an older -C target-cpu (for example, sm_60), you will need to either: remove that flag and let it default to sm_70, or update it to sm_70 or a newer architecture."

まとめるとこうなります。

-C target-cpu を指定しない       -> デフォルトが sm_70 に変わる。ビルドは通る。
                                    ただし成果物が pre-Volta GPU 上では動かない。
-C target-cpu=sm_60 を指定する   -> フラグを外すか sm_70 以上に上げる必要がある。
CUDA 10 以下のドライバー         -> 対象外。
Maxwell / Pascal GPU            -> 対象外。オプトアウトなし。

注目すべき点は、オプトアウトがないことです。予告記事にも「以前の挙動に戻すフラグ」はありません。Pascal 向けに PTX を吐く必要があるなら、方法は 1.96 以下のツールチェーンを固定することだけであり、それは欠陥を抱えたまま使うということでもあります。

影響範囲についての予告記事の判断は淡々としています。

"In this case, the most recent affected GPU architectures date back to 2017 and are no longer actively supported by NVIDIA."

"We therefore expect the overall impact of this change to be limited."

著者本人の推定であることは踏まえつつも、根拠には納得できます — 影響を受ける GPU の中で最新の世代が2017年のもので、NVIDIA 自身ももはや積極的にはサポートしていません。

それで、これを実際に使っている人はいるのか — 2026年の Rust-on-GPU の地形

正直になる場面です。Tier 2 でメンテナー一人、nightly 必須、no_std。このターゲットを生で使う人は多くありません。ではなぜこの変更が意味を持つのでしょうか。

2026年に入って、Rust で GPU を扱う場が急に賑わったからです。Rust CUDA プロジェクトがまとめたエコシステム地図を見ると、アプローチはこう分かれます。

cuda-oxide — rustc のコード生成バックエンドとして NVIDIA PTX/SASS を狙う。設計の中心は「CUDA を Rust に持ち込む」こと(カーネル記述、デバイスイントリンシック、SIMT 実行モデル)。
rust-cuda — rustc_codegen_nvvm を通じて rustc → NVVM IR → PTX。設計の中心は「Rust を GPU に持ち込む」こと — デバイス上での async/.await のような Rust の利便性。
Rust-GPU — SPIR-V へ向かうグラフィックス指向。Vulkan/Metal/DirectX。ベンダー間の移植性が中心。
CubeCL — 組み込み DSL + JIT ランタイム。CUDA/ROCm/WGPU を一つのカーネルで。proc-macro 方式なので rustc バックエンドではない。
std::offload — nightly の言語機能。LLVM offload ランタイムで CPU ループをアクセラレーターへ暗黙的に渡す。
cudarc — 安全な CUDA ドライバーバインディング。カーネルは別の場所で書き、ホスト側だけ Rust。
wgpu — WebGPU API の Rust 実装。スタックの層そのものが違う。

この中で最大のニュースはcuda-oxideです。NVIDIA Labs が直接出した Rust→CUDA コンパイラで、リポジトリの説明そのままに "an experimental Rust-to-CUDA compiler that lets you write (SIMT) GPU kernels in safe(ish), idiomatic Rust" です。DSL でもバインディングでもなく、標準の Rust を直接 PTX にコンパイルします。パイプラインは Rust → MIR → Pliron IR → LLVM IR → PTX で、ライセンスは Apache-2.0 です。

GPU 企業が自社プラットフォーム向けの Rust コンパイラを自ら出す — これが2026年のシグナルです。そしてこうしたツールが実際に動くためには、その下にある PTX 生成が正確でなければなりません。ベースラインの引き上げは、まさにその土台を固める作業です。

土台が脆弱だったという証拠は、Rust CUDA プロジェクト自身の文書にあります。これまで「唯一使える選択肢は LLVM PTX バックエンドを使うことだった」が、それが「多くのありふれた Rust の演算で無効な PTX を生成していた」と、このプロジェクトが存在する理由をそう説明しています。別の経路を掘らざるを得ないほど、既定の経路が信頼できなかったということです。1.97の整理は、その既定の経路を狭める代わりに信頼できるものにする方向です。

正直なトレードオフ — そして、いつ使うべきでないか

この変更自体は良い取引です。 誰もハードウェアを持って検証しなくなった古いアーキテクチャに対して、守れないアトミック保証を約束して静かに間違ったコードを吐くくらいなら、サポート範囲を狭めて残ったハードウェアで正しく動く方がましです。互換性より正確性を選んだのであり、正確性が実際に壊れていたのだから正当です。

だからといって今すぐ Rust で GPU カーネルを書くべきという意味ではありません。 正直に書くとこうです。

nvptx64 ターゲットは Tier 2 です — ビルドだけが保証され、テスト通過は保証されません。文書のビルド例からして nightly です。
no_std であり、ターゲット固有の制約もあります。たとえば static 初期化式が循環をなすとコンパイラが拒否します(static A: Foo = Foo(&A); はエラーです)。
NVIDIA が出した cuda-oxide ですら自らをこう規定しています — "in an early stage (alpha) and under active development: you should expect bugs, incomplete features, and API breakage."。しかも特定の nightly(nightly-2026-04-03)に固定されており、CUDA 12.x 以上と Linux を要求します。

だから大半のケースでは答えはこうです。 GPU を Rust から使いたいだけなら、カーネルは CUDA C++ で書き、ホスト側だけ cudarc のような安全なドライバーバインディングでつないでください。これは今プロダクションで動いている組み合わせです。カーネルまで Rust で書くのは、まだ研究・実験、あるいは単一ソースのコードベースでホストとデバイスが型を共有することで得られる利益が大きいときの選択肢です。

Maxwell や Pascal がまだ現役なら — 判断は二つに一つです。ツールチェーンを 1.96 以下に固定するか(欠陥を抱えたまま使う)、Rust でカーネルを書かないか。実のところ、後者は大半の場合すでに答えでした。

一つ付け加えると、cuda-oxide がそもそも CUDA 12.x 以上を要求している点が、この変更の性格をよく表しています。エコシステムはすでに CUDA 11 より先を行っており、コンパイラのベースラインが遅れてその位置に追いついたに近いのです。

おわりに

Rust 1.97 の nvptx64 ベースライン引き上げは、リリースノート一行の変更です。実際の中身はこうです — SM 2.0/PTX 3.2 から SM 7.0/PTX 7.0 へ、Maxwell と Pascal を取り払い、代わりに残ったハードウェアでアトミック順序とデバッグシンボルがきちんと動くようにする。オプトアウトはなく、影響は著者の判断で限定的とされています。

この静かな整理をあえて長く読む価値がある理由は、その背景にあります。何年も誰も見ていなかった Tier 2 ターゲットに欠陥が積み重なっており、2026年に入ってそのターゲットの上に本物のツールが — NVIDIA 自身が出したコンパイラを含めて — 乗り始めたことで、土台を見る理由が生まれました。サポート範囲を広げるのではなく狭めて正確にする方を選んだのは、その上に何かを載せるつもりのある人たちの決定のように見えます。

ただし結論は淡々としています。Rust-on-GPU は「不可能」から「管理され始めた」に移っただけで、「プロダクション準備完了」ではありません。アルファと書かれた文書はそのまま信じてください。そして大半の人にとって、1.97 でやるべきことは依然として rustup update stable の一つだけです。