Direct3D11 シェーダーの動的リンクやテクスチャ

●シェーダーの動的リンク

もともと Shader はマテリアルやライティング、アニメーションなど、組み合わせに
応じてすぐに数が増加する傾向があります。
加えて SM2.0~4.0 と徐々に固定機能が廃止され、有効な RenderState が減ると
さらに必要なシェーダー数が増えています。

シェーダー内の分岐もできますが、やはり大規模な並列実行でクリティカルな部分
なので、速度への影響が大きいマテリアルでは慎重になります。

もう1つ心配なのがコンパイル速度です。
シェーダーのコード量が増えるに従って、急激にコンパイルに時間がかかるように
なってきた印象があります。
シェーダーは CPU のコンパイラよりも比較的大胆な最適化が行われているので、
総当たりで比較しているのではないかとたまに思う時があります。

Direct3D11 ではこのような問題を解決するため、動的にシェーダーの Link が
できるようになるとのことです。
SetShader() 時に参照が解決されますが、HW native に変換されたコードで処理が
行われるため、リンクの操作も軽く、実行時の動作も速いそうです。
詳しい仕組みやパフォーマンスへの影響はまだわかりませんが、
分割コンパイルできるし組み合わせによる数の増加が抑えられるので、
管理はかなり便利になると思われます。

逆に、すでにシェーダー管理の仕組みを構築している場合は、D3D10→D3D11 への
移行時にいろいろと修正が必要になるかもしれません。
またいろいろ考えることが増えそうです。

●圧縮テクスチャ BC6/BC7

新しい圧縮テクスチャ BC6 は、HDR テクスチャの圧縮に使われるようです。
16 bpc RGB、つまり R16G16B16 相当を 1/6 = 1byte に圧縮するものと考えられます。

圧縮率 1/6 と書かれていますが、DXGI のフォーマットには 6byte = 48bit
の形式はないため、R16G16B16A16 との対比では alpha が無くなるものの
実質 1/8 のメモリ効率が得られそうです。

圧縮方法は従来の BC1~BC5 (DXT) によく似ています。
4×4 のブロックを単位にエンコードしますが、その手法はより複雑になっているようです。
格納するベースカラーに Alpha が無い代わりに HDR なこと、
ブロック毎にアルゴリズムを柔軟に変更できること、
エリアを分割して複数のパーティションとし、それぞれが異なるカラー補間テーブルを
参照できること、などなど。
これ以上の詳細はわからないので、DirectX11 SDK のリリースを待つ必要があるでしょう。

同じように BC7 は、HDR ではないカラー値の圧縮をより改良したものです。
BC6 同様にブロック毎にアルゴリズムを変更でき、RGB や RGBA の両方に対応できます。
RGB 比 1/3、RGBA で 1/4 とのことなので、やはり 1byte/texel となるようです。
これは BC2~3 (DXT3/DXT5) 等と同じです。

BC7 で完全に置き換えられるなら、BC2/3 は使われなくなるかもしれません。

テクスチャの最大サイズは 16384×16384 まで拡張されるようです。
16384×16384 32bit RGBA 相当で 1GByte
BC1(DXT1)/BC4 で 128MByte
BC2~3(DXT3/5),BC5~7 で 256MByte

関連エントリ
Direct3D11 マルチスレッドのための機能
Direct3D11 テセレータとシェーダー
Direct3D11 のパイプライン
Direct3D11 Compute Shader など
Gamefest2008 と Direct3D 11