［CEDEC 2009］テッセレーションやDirect Computeだけじゃない，NVIDIAが語る「DirectX 11の魅力」とは

NVIDIA,デベロッパーテクノロジー エンジニアの風間隆行氏

　Microsoft XNA関連のセッションで，最新GPUのデモを行ったAMDに続くセッションでAMDとはまったく別のアプローチからDirectX 11を解説したのがNVIDIAの風間隆行氏だ。なんと，テッセレーションとDirect Computeを除いた部分のDirectX 11が話の中心である。これら二つの目玉機能以外でもDirectX 11は非常に魅力的で，DirectX 10世代をすっ飛ばして移行する価値があると風間氏は語る。

　そのDirectX 11「その他の魅力」の主なものをざっと紹介してみよう。


●フィーチャーレベル（Feature Level）
　DirectX 10になったときに，それまであったCaps（そのハードウェアでなにができるか）のチェックをなくし，DirectX 10ハードウェアは統一した機能を保証されるようになった話を覚えている人はいるだろうか。その後，DirectX 10.1などが出てくると，当然，DirectX 10世代以降だからといって全部同じ機能を持っているなどということは期待できなくなる。
　DirectX 11世代では，Capsの再来ではないが，ある程度のハードウェアのレベルを規定して，それぞれのレベルにあわせたプログラムを書ける仕組みが用意された。それがフィーチャーレベル（Feature Level）だ。個々のCapsをすべて調べる必要はなく，どのレベルのハードウェアかだけ調べればよい
　ここで重要なのは，DirectX 9世代のハードウェア用のレベルも規定されたということだ。DirectX 11の作法でDirectX 9世代のGPU用のプログラムが書けるのである。DirectX 10世代ではサポートされていなかったため，DirectX 9とDirectX 10では，かなり異なったプログラムを別個に作らなければならなかったのだが，DirectX 11の管理下では，どちらもDirectX 11の一環として扱われるため，より多くの環境で動くゲームを作りやすくなっているという。
　DirectX 9用には9.1，9.2，9.3と3種類のレベルが用意されているようで，DirectX 9a，9b，9cと対応するものと思われる。

●マルチスレッディング（Multi Threading）
　これまでは，プログラマブルなプロセッシングユニット自体は豊富にあっても，分散処理を行うのが難しかったらしい（ディスプレイリスト関連の問題のようだが，単にDrawコールが増えるのを嫌っているだけ？）。DirectX 11では，デバイスコンテキストをイミディエイトコンテキストにコピーし，通常の描画処理を行っていく傍ら，ディファードコンテキストというものを複数定義できるようになり，そちらで独自にディスプレイリストを作ることができるようになった。複数のディファードコンテキストで作られたディスプレイリストは，イミディエイトコンテキストに渡され，まとめて実行されるようになっている。完全に独立して描画処理を行えるわけではないが，下請け処理などを分散できればプロセッサを無駄なく使えるうえ，実行速度向上ももちろん期待できる。これはDirectX 9世代のGPUでも適用できるため，覚えておいて損はなさそうだ。
　なお，風間氏の経験では，ディファードコンテキストの数はプロセッサコア数までにしておくのが無難とのこと。DirectX 11世代になるとようやくCPUコア数がゲームの性能に大きく影響してくることになるのかもしれない。

●ダイナミックシェーダリンク（Dynamic Shader Link）
　ダイナミックシェーダリンク（Dynamic Shader Link）はちょっと面白いアプローチだ。シェーダのダイナミックリンクというから，OSぽい処理を入れて実行時にライブラリをかき集めてくるものかと思っていたら，オブジェクト指向でいうオーバーロードというか多態性の処理を実装したものというのが正解だった。
　分かる人には「オーバーロード」「多態性」というだけで説明は必要ないだろうが，分からない人にはまったく分からない話なので，簡単に説明しておこう。
　
　大きなシェーダを1個作るのと，細かいシェーダを無数に作るののどっちがいいかというのは，かなり以前から議論されていた問題である。大きなシェーダだと扱いやすいが，内部でいろんな判定が必要になるのでパフォーマンスが落ちる。細かいシェーダだけで作れば実行効率はよいが，管理しきれなくなる。パフォーマンスと管理性の両方を実現するのがダイナミックシェーダリンクであるといえる。
　例えば，シェーダで光源処理する際に，適用される光源の種類が
環境光なのか，有向光線なのか，点光源なのかで処理が大きく変わることもある。従来であれば，光源の種類を識別して，点光源ならこの処理といった分岐を書いていかなければならなかった。これが，ダイナミックシェーダリンクだと，適用される光源の種類によって自動的にそれぞれの処理が行われるようになる。


　しかし，それってかえって重くなるんじゃ？　と，誰しも思うだろう。私も思ったし，風間氏も思ったらしい。講演では，氏が実際にコードを書いて，コンパイル後に出力されたコードが示されていた。該当部分に処理の重いIF文は使われておらず，間接関数コールが埋め込まれていた。これは，IF文による分岐より遥かに軽いとのこと。
　それぞれのデータ型用のクラスとインタフェース（オブジェクト指向用語。込み入った話になるので説明は割愛）を記述しておくと実行時にデータ型ごとに適切な処理がされるようになる。適用されるインタフェースの数なども指定しないといけないようで，指定はやや面倒そうではあったが，クラスの継承などもできるためシェーダの記述が一気に楽になる可能性はある。
　この処理は，Shader Model3.0の範囲で行けそうな気はするのだが，現状のSDKだとDirectX 9世代のGPUでは動かないとのこと。

●コンサバティブ オーデプス（Conservative oDepth）
　コンサバティブ オーデプス（Conservative oDepth）という処理も面白い。GPUにはいろいろなボトルネックが考えられるが，なかでもROP処理は，フレームバッファとZバッファに多大なアクセスが発生するため，とりわけ要注意の個所のようだ。通常は，裏に隠れた面の処理を省略するようなZ Cullingの処理が行われ，ROPへの負荷を下げている。
　ところが，シェーダでZ値をいじりたくなった場合にそこが破綻し，適切な最適化が働かず，ROP処理が非常に重くなる。それで，Z値を処理する際に，「これまでの点より手前」か「これまでの点より向こう」かを明示的に指定してやれることができればROPでのZ参照を大幅に減らせる場合が出てくる。こうした処理を可能にするのがコンサバティブ オーデプスであるという。


　そのほか，DirectX 11で新しく追加されたバッファや新しいテクスチャ圧縮法など，DirectX 11を使うことのメリットは非常にたくさんあり，これまでよりも使いやすいものになっているという。Windows 7世代になると，PC用のゲームも一段と作りやすくなってくるようなので，タイトルの充実にも期待したいところだ。