［Gamefest 08＃07］DirectX 11でデータ並列コンピューティングをサポートする演算シェーダとは

ついにDirectXがGPGPUサポートに動く！

　前回のレポートではDirectX 11（以下，Direct3D 11）のグラフィックスパイプラインについて紹介したが，Direct3D 11の目玉は，テッセレーションの仕組みが実装されたことだけではない。実はもう一つ，重大な機能拡張が施されることで業界から大いに注目されている。それは「GPGPUのサポート」だ。
　本稿ではDirect3D 11のGPGPUサポートについての話を中心にレポートする。

Direct3D 11はGPGPUを公式サポートする！

　GPUの浮動小数点演算能力は膨大なものになっており，例えば今年AMDが発表したRADEON HD4870は1TFLOPSを超えている。そして，今後も，この演算能力は爆発的に上がり続けると予測されている。
　また，DirectX 10世代のGPU（Shader Model 4.0）は，CPUに迫るプログラマビリティを備えている。シェーダ中で分岐が行えるようになったShader Model 3.0が登場したあたりから「膨大な演算パワーを3Dグラフィックス処理だけに用いているのはもったいない」という考えが生まれ，GPUを汎用の演算用途に用いようというアイデアが提唱されるようになった。これがGPGPU（Genral Purpose GPU）という概念の発祥だ。
　GPGPUの有効性については，近年，各方面から認められてきたところだが，その手法の標準化については紆余曲折があり，実際のところ，混沌としている。Brrok，Rapidmind（Sh），NVIDIA CUDA，Microsoft Accelerator，Close to Metal（CTM）などなど，各社，各研究機関からさまざまなGPGPUを実現する仕組みが提唱されてきたが，いまもってどれもメインストリームにはなりきれていない。
　NVIDIAは，リーダーシップを取って「CUDA」（Compute unified device architecture）と呼ばれるGPGPUプラットフォームを立ち上げ，「デスクトップHPC」の分野を開拓して一定の成功を収めてはいるが，同社のGPU，GeForce（Tesla）専用のものであり，現存するすべてのGPUでサポートされるものではない。
　ただ，CUDAの成功は，GPGPUの潜在能力の高さを裏付けることに貢献し，なおいっそうのGPGPU標準化への気運を高めたことは間違いない。

DirectX演算シェーダは3Dグラフィックスパイプラインとの統合が成されているのが特長

　そんな状況を反映してか，マイクロソフトはこのGPGPUをDirectX 11（Direct3D 11）でサポートすることを決定した。
　それが「DirectX 11演算シェーダ」（DirectX 11 Compute Shader）だ。

　演算シェーダはDirect3D 11に統合される形で実装され，Direct3D 11で取り扱えるリソース類はすべて透過的に演算シェーダでも取り扱えるようになっている。機能的な側面でいうとDirect3D 11に，GPGPU関連のAPIの追加とシェーダ言語のHLSLが拡張される……というイメージになる。
　それでは，CPUの代わりみたいに使えてしまうのか……というと，そういうことではない。演算シェーダの活用は，一つのプログラムで大量のデータを処理するような，SIMDならぬSPMD（Single Program Multiple Data）モデルの処理の実装に向いているとされる。例えば，群集シミュレーションのAI，大局的な物理シミュレーション処理，映像のエンコード処理，3Dグラフィックスのポストプロセスなどには向いているといえる。
　使い方としては，GPU用の処理プログラムと処理したいデータ群を用意して，「このデータをこのプログラムで処理してね」という感じでDirect3D 11に受け渡して実行させてその結果を得る……という感じになる。そのため，少量のデータ処理ではCPUとGPU間の受け渡しのオーバーヘッドが大きいため，あまり向いていない。
　重要なのはATI，NVIDIA，Intelなどのメーカーの区別なくGPUのGPGPU活用がサポートされる点だ。この演算シェーダの仕組みによって，単一のGPGPUソフトウェアをメーカー不問のGPU環境下で透過的に動作できるようになる。これにより，これまでGPUの種類ごとに個別開発が必要でなにかと敷居の高かったGPGPUソリューションがグッと身近なものとなるはずだ。
　GPGPU関連のニュースとして，最近ではビデオエンコーダソフトウェア「TMEGEnc」がNVIDIAのGPGPUプラットフォーム「CUDA」に対応したことが話題となったが，ああいったビデオエンコーダのようなアプリケーションも，Direct3D 11登場後は演算シェーダにも積極対応してくるようになることだろう。

DirectX 11演算シェーダはDirect3D 11に統合実装される

演算シェーダはメーカー不問のGPGPUソリューションの標準仕様として期待される

　演算シェーダがDirect3D 11のリソースを透過的に取り扱えるという点も，重要な特徴だ。
　これにより，Direct3D 11でレンダリングした3Dグラフィックスに対しての後処理や相互連携処理の仕組みとして演算シェーダが利用できる。
　例えば，3Dグラフィックスとしてレンダリングした複数の映像フレームを演算シェーダを使って適応型の処理で1フレームに合成するといったことが実現できる。かねてから実装が検討されている，半透明オブジェクトの描画の順不同実行を容認する「A-BUFFER」の仕組みも，演算シェーダの活用で実装できるのではないか，とセッションを行ったマイクロソフトXNAデベロッパーコネクションの松尾晃氏は語っていた。
　また，3Dグラフィックスパイプラインで用いているアニメーション処理適用済みの基本3Dモデルを，演算シェーダで実装している物理シミュレーションの衝突判定用に流用したり……といったことも実現できるはずだ。これはGPUリソースの有効利用，余分なデータ転送の削減，パフォーマンスの向上などに繋がる。

演算シェーダでGPU実装が可能と思われるソフトウェアのテーマ

3Dグラフィックスのポストプロセスに演算シェーダを活用するのもアリ

Direct3D 11，その他の拡張点は?

　ここまでが，DirectX 11関連のビッグニュースになるが，これ以外にも時代が要求してきたさまざまな新機能を実装している。ここからはそういった話題を紹介していこう。
　現在はノートPCにもマルチコアCPUが実装されており，完全にマルチコアCPUの主流時代が到来したといえる。これを踏まえ，DirectX 11（Direct3D 11）では，内部動作の仕組みを本格的なマルチスレッド実行に対応させる。
　具体的には，3Dゲームエンジンをはじめとしたアプリケーションプログラム，Direct3D 11ランタイム，Direct3D 11ドライバ，そして新版のDirect3D 10.xドライバをそれぞれ異なるスレッドで実行させることが可能となる。例えばアプリケーション起動時にシェーダプログラムをコンパイルする実装ケースでは多少の起動時間の短縮などが期待できる。劇的なパフォーマンスアップとはいかないまでも，Direct3D 11時代にはクアッドコアCPUなどが積極活用されるのは歓迎すべき改良だといえる。
　Direct3D 10.x対応GPUの環境でもDirect3D 11の導入でドライバがマルチスレッド対応となるので，導入するだけでも多少なりの恩恵が受けられる。これは覚えておいて損はないだろう。

Direct3D 11はマルチスレッドに本格対応する

　また，シェーダプログラムのダイナミックリンクの仕組みがやっとサポートされる。シェーダプログラムの長さ制限が事実上撤廃されたのがDirect3D9時代。これは大いに歓迎されたのだが，シェーダプログラムの管理の難しさが開発現場で強く叫ばれるようにもなった。例えば，同じアルゴリズムでもシェーダで取り扱う光源の数が異なると，別のシェーダプログラムとして用意しなければならなかった。条件分岐などを駆使して長いシェーダを構築するのも一つの手とされたが，これだと往々にしてレジスタの使用効率がワーストケースに陥りやすい。
　そこで，この状況を改善すべく導入されるのが，実行時にシェーダプログラムのモジュールを動的にリンクできる仕組みだ。クラスやインタフェースの概念が導入され，いわばHLSLプログラミング環境のオブジェクト指向対応化……ということになる。
　これによりシェーダプログラムをモジュール化して効率よく管理して利用できるようになる。具体的には，モジュール化したシェーダアルゴリズムをサブルーチン化して置くことができ，メイン側から必要なモジュールとして適宜呼び出せるようになる。

基本的には開発者のための改善要項ではあるが，この仕組みはシェーダプログラムの切換頻度の低減にも貢献するので，アプリケーションのパフォーマンス向上に結びつくこともありうる。よってエンドユーザーにも多少なりとも恩恵はあるといえなくもない（リンクのオーバーヘッド次第だろうが）

　Direct3D 11ではテクスチャ関連の機能も強化されるが，強化というよりは改善，要望への対応といった側面が強いものとなっている。
　具体的には，まず，長らく要望されてきたHDRテクスチャ圧縮の標準技法が初めて導入される。それは「BC6」（block-compressed Texture TYPE-6）と呼ばれる形式で，1ピクセルあたり16ビットのRGBから成るHDRテクスチャの圧縮に対応する。圧縮アルゴリズムは基本的には従来のS3TC（DXTC）方式と同じブロック圧縮方式となり，圧縮率は1/6固定でロッシー（劣化する）になる。
　さらにもう一つ，高品位なαチャネル付きテクスチャ圧縮フォーマットの新形式として「BC7」も追加される。従来のS3TC方式ではグラデーション表現やディテール表現にブロックノイズが乗ることがよく指摘されたが，これを改善するものになる。圧縮率はRGBで1/3，αチャネル付きRGBAで1/4となる。
　なお，ATIが考案した2要素DXTともいわれる法線マップ向きのテクスチャ圧縮方式の3DcがDirect3D 10で「BC5」としてサポートされたが，BC7は法線マップ向けの圧縮技法にも向いているとされる。

Direct3D 11では新しいテクスチャ圧縮メソッドが二つ追加される

従来のBC3（DXT5）との比較。BC7ではエッジ部のブロックノイズが圧倒的に少ない

　これらの基本的な圧縮アルゴリズムは，S3TCと同じく4×4ピクセル単位を基本としたブロック圧縮だ。これまでのDXTCでは単一のブロックタイプを持つことしか許されていなかったが，BC6，BC7の採用にあたって，複数のブロックタイプを持てるように拡張された。これによりデコード時の再現精度が上がり，グラデーションやディテール表現（高周波表現）も従来より高品位に再現される。
　高品位テクスチャのBC7はともかく，HDRテクスチャの取り扱いにはDirect3D 9時代から苦労してきたので，開発者からすれば「やっと対応してくれたか」という印象だろう。
　こうした新しいテクスチャフォーマットがDirectX 11導入後のDirect3D 10.x世代GPUで利用できるかは不明だ。

左：法線マップをBC7で圧縮した例。エラーがほとんど見られない点に注目　右：オリジナルとBC6圧縮したHDRテクスチャの比較。誤差がないわけではないが許容レベル

演算シェーダはGPGPUのメインストリームになりうるのか

Direct3D 11に実装されるその他の新機能

　Direct3D 11の注目点はテッセレーションのレンダリングパイプラインへの組み込みと，演算シェーダの実装によるGPGPUの公式サポートになることは，2回にわたってのレポートで分かっていただけと思う。

　少し気になるのはこの演算シェーダがGPGPUのメインストリームになりうるのか……という部分だろう。
　一点気になるのは，マイクロソフトはDirect3D 11とは別に「Accelerator」と呼ばれるGPGPU標準化プロジェクトをVisual Studio関連チームを中心として推し進めており，これが演算シェーダとズバリ競合してしまうこと。同じマイクロソフト社内で似たようなものが競合するのは芳しくないし，ハードウェアベンダやユーザーにも不安を与えるので，早めに明確な舵取りを示してほしいものだ。
　実は，DirectX（Direct3D）のライバル（?）ともいえるKhronosグループが統括しているオープンソースなグラフィックスAPI「OpenGL」のほうでもGPGPUに関連した大きな発表が2008年6月に行われた。ちょうどDirectX 11演算シェーダに相当するようなGPGPUソリューション向けの仕組みとして「OpenCL」（Open Computing Language）が発表され，これも3DグラフィックスAPIのOpenGLに統合されることが明らかにされたのだ。OpenCLはApple主導で始まったプロジェクトであるため，少なくともMac系プラットフォームではスタンダードとなることは間違いないだろう。

　DirectX 11で実装される演算シェーダのポテンシャルは，まだ，どの程度のものとなるのか不明点も多いが，少なからず，NVIDIA CUDAなどに競合する部分もある。このためNVIDIAがこの演算シェーダを真剣にサポートするかの動向は注目されるところだ。しかし，ATIとインテルは本格サポートを表明しているので演算シェーダがマイナリズムに落ち込む可能性は低いとは思う。
　なにしろ，これまでの多様なGPGPUソリューションとは異なり，Direct3D 11と完全に統合されている点でゲームからの利用は扱いやすく，パフォーマンスの面でも有利だ。例えばCUDAなどでは同じGPUでGPGPUと3Dグラフィックスを処理するにしても，Direct3Dとは論理的に別個なものであるため排他的な活用をしなければならず，CUDAで実行したGPGPUの結果をDirect3Dで利用する場合には，Direct3D側へその結果を転送するような工程が必要になる。CUDAに限定するなら，GPU自体のリセットも必要だ。演算シェーダであればそういったものは不要である。ゲーム開発向けのGPGPUソリューションとしてはむしろ本命といっていいだろう。