AMDの次世代GPUアーキテクチャ「RDNA 5」をめぐり、LLVMのAMDGPUバックエンドに入った新しい変更が、同社の性能設計の重心を明確に示し始めている。焦点は演算器の数を増やす話ではなく、既存の演算器をどれだけ高い確率で埋め続けられるか、そのために命令の組み合わせ制約をどこまで緩めるかにあるようだ。
今回見えてきたのは、RDNA 3以降で備えていた「Dual Issue VALU」を、RDNA 5世代では実用域に押し上げようとする動きである。Dual Issueは、条件が合えば1クロックで2命令を並列発行できる仕組みだが、従来は対応命令の少なさやレジスタ制約、Wave32限定といった条件が重く、理論性能に対して実効性能が伸び切らない場面があった。RDNA 5向けとみられるgfx1310対応では、その詰まりをソフトウェア側からほどく準備が進んでいる。
LLVMの更新で見えてきたgfx1310向けの実装拡張
今回の話の出発点は、Coelacanth’s Dreamが3月12日に取り上げたLLVMの変更だ。そこでは、AMDの次世代GPUターゲットとされるgfx1310向けに、Dual Issue関連の定義が追加されている。ソース上ではGFX13GenDとGFX13GenD3という形で扱われ、既存のVOPDに加えて、新しい命令エンコーディングであるVOPD3も使う前提が見えている。
従来のVOPDは、2命令をX側とY側へ同時に発行するための仕組みだが、扱える命令の範囲が狭かった。今回のgfx1310向け定義では、V_MAX_I32_e32、V_MIN_I32_e32、V_SUB_U32_e32、V_LSHRREV_B32_e32、V_ASHRREV_I32_e32といった整数系やシフト系の命令が追加される一方、V_AND_B32は外されている。ここから読み取れるのは、AMDが単純に命令数を増やしているのではなく、実際に並列発行させやすい組み合わせへ命令セットを組み替えているという点だ。
さらに注目すべきはVOPD3側の変化だ。ここでは従来のV_FMAAK_F32やV_FMAMK_F32とは別に、V_FMA_F32_e64がDual Issueの対象に入っている。FMAは積和演算、つまり乗算と加算を1命令で行う形式であり、グラフィックスでもコンピュートでも出番が多い。コンパイラにとって扱いやすいFMAをDual Issueしやすくすることは、命令スケジューリングの自由度を引き上げる意味が大きい。
RDNA 3とRDNA 4で難しかったことを、RDNA 5は通しやすくする
Dual Issueそのものは新機能ではない。RDNA 3世代の時点で既にDual Issue VALUが実装されていたこと。問題は、ハードウェアの存在と、実際にその性能を引き出せることが別問題だった点にある。
従来のVOPDにはいくつかの制約があった。対応命令が限られていたことに加え、命令によってはY側にしか載せられず、Wave32モードでしか使えず、X側とY側で別のレジスタバンクを使わないと競合が起きる。これでは、コンパイラが「この2命令なら同時発行できる」と判断できる場面がかなり狭くなる。理論上は2本同時に流せる演算器でも、実際には片側しか埋まらない時間が長くなりやすい。
この制約の重さを端的に示す例として、GPUベンチマークツールvkpeakが挙げられる。従来世代ではV_FMA_F32がDual Issueの対象に入っていなかったため、ピークFP32性能を測るような条件でもDual Issueが働かず、公称値の半分程度しか出ないケースがあった。ここで重要なのは、GPU自体の理論性能が低かったのではなく、そこへ到達する命令列をソフトウェア側が組みにくかったことである。
RDNA 5向けの変更では、この部分にかなり直接的な手当てが入る。V_FMA_F32をX側とY側の両方に発行できる可能性が見え、同時に入力レジスタの指定制限も一部緩和される。Coelacanth’s Dreamは、X側とY側で同じ入力レジスタを使えるようになると説明している。これが意味するのは、Dual Issue成立条件の「形を合わせる」難しさが下がることだ。コンパイラは同じ演算資源を前提にしながら、より多くのシェーダーや計算カーネルで並列発行を選びやすくなる。
V_FMA_F32対応が象徴する変化
今回の変化を象徴しているのが、やはりV_FMA_F32の扱いである。V_FMA_F32は3つの入力レジスタを自然に扱える命令形式で、グラフィックス処理や行列演算、ニューラル系ワークロードでも現れやすい。これがDual Issueしにくいままでは、演算器のピーク値を掲げても、ソフトウェア現場では届きにくい。
V_FMAAK_F32やV_FMAMK_F32のようにリテラル定数を使う派生形で回す方法はあったが、一般的なコンパイル結果にそのまま載せやすいとは言いにくい。V_FMA_F32自体をDual Issueの流れに入れれば、コンパイラ最適化はかなり素直になる。Igor’sLABが指摘した「命令ペアリングを組みやすくする」「シェーダーユニットを遊ばせる時間を減らす」という見立ては、この点に根拠がある。
「最大2倍性能」という見出しが実際に意味するもの
一部では、「最大2倍」「ほぼ2倍」といった強い表現で報じられた物もあったが、ここで言う2倍はGPU全体の名目性能がそのまま倍になる話ではない。Coelacanth’s Dreamの記述でも、改善されるのは「これまで半分のピーク性能しか出なかったケース」であり、ピークFP32性能そのものが大きく変わるとは限らないと整理されている。
この違いは大きい。たとえばCompute Unit数やクロックが据え置きでも、命令発行の失敗率や片側レーンの遊休時間が減れば、実アプリケーションで見える演算密度は上がる。とくにシェーダー処理のように、似た演算が大量に並ぶ場面では、コンパイラの命令配置が少し通しやすくなるだけでも差は積み上がる。結果として、同じハードウェア規模でも広告上の理論値へ近づきやすくなる。
ここでAMDが狙っているのは、巨大ダイ化や消費電力上昇に依存しない伸びしろである可能性が高い。Igor’sLABが「より大きなチップや高い電力だけに頼らない効率向上」と読んだ点は、LLVMの変更内容とよく整合する。演算器の数を積む戦略は分かりやすいが、製造コスト、歩留まり、電力設計の負担が重くなる。命令発行効率の改善は地味に見えても、世代更新で積み上げやすい。
競争軸はハードウェア単体から、コンパイラと実装力へ移る
今回の一連の変更が示しているのは、GPU競争の評価軸が「何基積んだか」から「どこまで埋め切れるか」へ寄っていることだ。これはハードウェア設計だけの話では終わらない。LLVMバックエンドで先に動きが出ていること自体、AMDがコンパイラ、ドライバ、ツールチェーンを含めた形でRDNA 5を立ち上げようとしていることを示す。
この視点で見ると、RDNA 5の焦点は命令追加の数ではない。開発者が特別な手作業を増やさなくても、コンパイラが自然にDual Issue成立条件へ寄せられるかどうかにある。そこがうまく回れば、ベンチマーク向けの特殊なコードだけでなく、実際のゲームシェーダーや各種計算カーネルでも恩恵が広がる。逆に言えば、シリコンの潜在力が高くても、コンパイラ最適化が追いつかなければ広告値と体感値の差は埋まらない。
FMA系命令はニューラル処理でも出番が多いため、二次報道がアップスケーリングやフレーム生成への波及可能性に触れているのも筋は通る。ただし、そこは現時点で推測の域を出ない。今回のソースから確実に言えるのは、RDNA 5がFP32系ワークロードでDual Issueを成立させやすくする方向へ進んでいること、そのためにVOPD3やV_FMA_F32対応、レジスタ制約の緩和が用意されていることだ。
最終的な評価を決めるのは、実機のシェーダーコンパイル結果と、実アプリケーションでの命令発行効率である。LLVMの変更は設計意図をよく映しているが、そこから先はドライバ、コンパイラ実装、ゲームエンジンとの噛み合わせで差が出る。AMDがRDNA 5で問われるのは、理論値をさらに高く見せることより、既に持つ理論値をどれだけ現実のフレームと処理時間へ変換できるかである。今回の更新は、その勝負がシリコン面積ではなく、命令スケジューリングとソフトウェア実装の精度で決まることをかなり明瞭に示している。
Sources