［GDC 2024］CPUを使わずにGPUが自発的に描画するパイプライン「Work Graph」がDirectX 12に正式採用

セッションタイトルを訳すなら，「ようこそ，未来のGPUプログラミングモデル『GPU Work Graph』へ」

　米国時間2024年3月18日に行われたGDC 2024の技術セッション「Advanced Graphics Summit: GPU Work Graphs: Welcome to the Future of GPU Programming」において，AMDとMicrosoftは共同で，DirectX 12の新機能「Work Graph」を発表した（関連リンク）。本稿では，Work Graphとは何で，どのような利点をもたらすのかを解説したい。

セッションを担当したMicrosoftのShawn Hargreaves氏（Dev Manager, Direct 3D）と，AMDのMatthaus Chajdas氏（Fellow）

1年以上前から標準化を進めていたAMD

　話は約1年ほど前にさかのぼる。筆者は，AMDのDavid Wang氏（Senior Vice President，Engineering，Radeon Technologies Group）と，Rick Bergman氏（Executive Vice President，Computing and Graphics Business Group）にインタビューする機会があり，その中で「今後，グラフィックス業界で，新たに起きそうな標準化すべき3Dグラフィックスパラダイムは何でしょうか」という漠然とした質問をしたことがあった。それに対してWang氏は，以下のように答えている。

CPUの助けを借りずに，GPUだけでグラフィックス処理タスクを生成して，それをGPU自身で消費するGPU自己完結型の描画パイプライン駆動技術だ。

　そのうえで同氏は，「これについてAMDは，とあるパートナーと共同で標準化を始めている」と付け加えていた。
　このときにWang氏がほのめかしたGPU自己完結型の描画パイプラインが，まさにWork Graphである。含みを持たせて「とあるパートナー」と表現した相手は，Microsoftだったわけだ。

　AMDが推す「Primitive Shader」と，NVIDIAが推す「Mesh Shader」の次世代ジオメトリパイプラインの標準化戦争では，AMDが敗退した。しかし，新世代のGPU自己完結型パイプラインについては，AMD提唱の仕様が標準仕様として採用されたわけだ。
　とはいえNVIDIAも，Work Graphについては「賛同の意」を示しており，今回の発表に合わせて，NVIDIA製GPUも即座に対応していくと明言している（関連リンク）

Work Graphとは何か？

　さて，今回の本題であるWork Graphという用語が，ピンと来ない人もいることだろう。
　ここでいう「Graph」とは，「グラフ構造」を意味している。マスで表される「ノード」と「ノード」を連結させたフローチャートのようなネットワーク構造では，あるノードの処理系で特定の条件が成立すると，成立条件ごとにそれぞれ別の接続先ノードに処理系が移る。処理が移るときは，上流のノードが出力したデータが，下流のノードに入力されていく。
　Work Graphにおけるノードとは，GPUのタスクを表す。それは処理系の実行命令（dispatch）に相当するコマンドであったり，単一スレッドで動作するシェーダプログラムであったり，あるいは同一のシェーダを並列で動かすグループスレッドのような場合もある。

　Work Graphのメリットは，これまではGPUが処理するときに，オーケストラにおける指揮者のような役割をしていたCPUの関与が，ほとんど不要になること。GPU自身が，自発的に各処理系の実行を進められるのだ。
　具体的にいえば，GPUが実行すべき仕事を，CPUからPCI Expressインタフェースを通じて細々と描画コマンドとして送らずとも，あらかじめ構築しておいたWork Graphに従ってGPUが自発動作できる，と言ったイメージだ。もちろん，ゲームの進行によっては，まったく別のWork Graphが起動する場合もありうるので「ゲームグラフィックス処理において，CPUが不要になる」わけではない。

左は，CPUが定期的に介入する既存のGPU駆動方式で，右がWork GraphによってGPUが自発的に処理を駆動していく方式のイメージ

　たとえば，「GPUの性能は高いが，CPU性能が相対的に低い」システムにおいて，GPUでの処理が終わっているのに，CPUによる「GPUが次にすべき仕事の準備」に時間がかかり，ゲームのフレームレートが思ったほど上がらないケースはよくある。Work Graphを活用すると，そういった現象をある程度は軽減できるようになるかもしれない。

　下は，Microsoftが示した，かなり高度なWork Graphの事例だ。

かなり複雑なWork Graphの例

　シェーダプログラムとして定義された各ノードは，CPUからの起動を待つことなく実行される。各ノードにおいて実行終了条件が成立すれば，次のノードに処理が移るようなパイプライン構造となっているわけだ。もちろん，Work Graphの最上流（左上）からは，どんどん処理対象のデータが流れてくるのだが，Work Graphを構成する各ノードは，CPUからの処理を待たずに，非同期でどんどん処理を実行できる。

　これは，あくまでも「例のための例」といった図であるが，Work Graphの特性をうまく説明している点はある。それは，中央やや左にある「Node:RecursiveCull」だ。
　これは，左上から入力されたピクセルスレッドを，本当に描画すべきか，それとも破棄すべきか（Culling）を粗く判定する再帰構造になっている。ここで「描画すべき」と判定されたとしても，判定結果のレベルに応じて，判定詳細度の違う2つの「詳細破棄判定」（FineCullingShader）ノードに接続しているわけだ。
　GPUが苦手とする，動的な分岐処理系も，Work Graphを活用すれば，パフォーマンスが劇的に改善するケースもあるかもしれない。

Work Graphにおける3種類のノード

　セッションでは，Work Graphで利用できる，「代表的な3種類のノード」についての解説が行われた。

●Broadcasting Launchノード
　固定サイズのスレッドグループによって起動（Launch）されるもので，イメージ的には，一般的なCompute Shaderスレッドに近いノード。

BroadcastingLaunchノードのイメージ

●Coalescing Launchノード
　あるスレッドグループが処理できる最大入力数と，スレッドグループのサイズを宣言して活用するノード。

CoalescingLaunchノードのイメージ

　入力されたデータスレッドが，宣言された最大数を満たすと起動するが，最大数に満たない場合でも起動できる。入力された複数のデータスレッド同士に関連性がある。たとえば，互いに参照し合うことを想定した共有データがある場合に適したノードだ。
　ただし，関連性がない場合は，次のノードを使うべきであるとのこと。

●Thread Launchノード
　入力されたデータスレッドごとに，単一のスレッドを起動して処理するノード

ThreadLaunchノードのイメージ

Work Graphで一体何ができるの？

　「Work Graphを活用すれば，GPU性能の最適化につながりそう」というのが，ここまで読んでの第一印象だと思う。しかしMicrosoftとしては，これまでのGPUプログラミングでは実装できなかった（≒実装しても実用にならなかった）新しいグラフィックスアルゴリズムの開発に活用してほしい，というのが本音のようだ。
　その一例として，今回のセッション内でAMDが公開したWork Graphサンプルが，以下の動画にある「Procedural Enrichment」である。


　これは，2024年後半にWork Graphへ実装予定の新ノード「Mesh Node」を活用したものだ。
　Mesh Nodeは，新ジオメトリパイプラインのMesh Shaderを駆動できるノードで，あらかじめ定義しておいた「Graphics Pipeline State Object」（以下，Graphics PSO）を，Mesh Shaderに与えるものである。

グラフィックスパイプラインのノードとして発表となった「Mesh Node」。リリースは2024年後期

　Graphics PSOとは，DirectX 12から導入された概念で，描画したいキャラクタなどの描画プロセスの最初から最後までを，「オブジェクト」として定義したものだ。
　簡単に言うと，Mesh Nodeでは，Mesh Shaderにキャラクターや小道具，大道具といった3DモデルのGraphics PSOを描画させるために入力できるノードである。極端なことをいえば，DirectX 12ベースのゲーム画面は，無数のGraphics PSOを，実際に描画したものとも言える。

ようするに，Graphics PSOをMesh Shaderに入力できるノードである

　動画のデモでは，メインのWork Graphに地形の情報を入れてやると，その土地の大きさや傾き（高低差），障害物の配置などを考慮して，Work Graphが自動的に建物の区画を決定している。さらに，区画に合わせて道のレイアウトや植生も，Work Graphが自動で決めていく。そのうえで，区画の種類に対応した3DモデルのGraphics PSOを，Mesh Nodeにて描画する流れを動画では示している。いわゆる，プロシージャルなゲームシーン構築と描画を，Work Graphで実現しているのだ。

メインのWork Graph

　興味深いのは，メインとなるCompute ShaderベースのGraph Nodeから，グラフィックスパイプラインのMesh Nodeを呼び出せているところだろう。このデモは「デモのためのデモ」といった感じだが，ここまで高度なことが，GPUの自律描画でできるのは衝撃である。

　上の動画でも説明されているが，このデモのメインWork Graphでは，植物を描画するときに「日向（ひなた）には草木が生える」「日陰にはキノコが生える」植生となるように作られている。花は，日向に一定確率で置かれて，花の近くには，一定確率で蜂が生成される。また日向の草木の近くには，これまた一定確率で蝶を生成されるという仕組みになっているようだ。

草木生成，昆虫生成のWork Graph

　セッションの最後には，「Unreal Engine 5」の無段階LODシステムを実装した地形描画エンジンである「Nanite」を，Work Graph（※おそらくMesh Nodeも活用）で実装したデモも披露された。ただ，あくまでも実験的に実装したもので，UE5がWork Graphに対応したわけではない点に注意したい。

UE5のNaniteシステムをWork Graphで実装したデモ

　ただ，移植にはわずか一週間ほどしかかからなかったとのことなので，Work Graphが正式リリースされた暁には，UE5に正式採用されてもおかしくはない。
　そのほかにもAMDは，Work Graphで実装したラスタライズ処理系のサンプルを公開しているので，興味のある人は参照してほしい。

Work GraphはGeForceでもRadeonでも使える

　Work Graphは，DirectX 12のβ版的な位置づけである「DirectX Agility SDK」から利用できるそうだ（関連リンク）。
　Work Graphを活用するには，プログラマブルシェーダのバージョンとしては，「Shader Model 6.8」以上が必須となる。対応GPUは，AMDではRadeon RX 7000シリーズ，NVIDIAでは，GeForce RTX 40/30シリーズがあげられている。
　Intel Arcシリーズは，現時点では対応していないものの，対応へ舵を切るとのこと。また，Qualcommも同様の表明をしているので，今後のメインストリーム技術になっていく可能性は高そうだ。

　なお，現行のGPUでWork Graphをハードウェアレベルで動かせるのは，Compute Shaderのみだ。頂点シェーダやメッシュシェーダに代表されるジオメトリ系のプログラマブルシェーダや，プログラブルピクセルシェーダ，レイトレーシング関連は，今のところハードウェア対応していないが，今後，対応を拡大していく予定とのこと。まだ，いろいろな意味で「早期フェーズ」と言うことなのだろう。

　一方で，Work GraphをPlayStation 5やXbox Series X|Sといったゲーム機のGPUで利用できるかは不明だ。現状，AMDは「Work Graphは，Radeon RX 7000系（RDNA3ベース）のGPUからの対応」としているので，RDNA2系のGPUを搭載するPS5やXbox Series X|Sでは対応できない可能性がある。
　この業界には，「ゲーム機とゲームPCの両方に対応できていない新技術は，どんなに素晴らしくても積極的に活用されにくい」というジンクスがあるので，はたしてどうなるだろうか……。

4Gamer「GDC 2024」掲載記事一覧