Intelプラットフォームでのリソースバインディングを詳しく見てみましょう。 これは、Intel Coreファミリー（Skylake）の第6世代プロセッサーのリリースと、7月29日に行われたWindows 10オペレーティングシステムのリリースに関連して特に当てはまります。
前の記事「 Microsoft DirectX * 12でのリソースバインディングの概要 」では、DirectX 12でリソースをバインドする新しい方法について説明しました。リソースの種類と更新頻度。
この記事では、特定のIntel GPUでアプリケーションを効率的に実行するためのさまざまなリソースバインディングメカニズムの選択について説明します。

ツール

DirectX 12に基づいてゲームを開発するには、次のものが必要です。

• Windows 10
• Visual Studio * 2013以降。
• Visual Studioに含まれているDirectX 12 SDK。
• DirectX 12をサポートするGPUとドライバー。

復習

記述子は、GPU向けの「不透明な」形式で、GPUのオブジェクトを記述するデータブロックです。 DirectX 12は、以前はDirectX 11で「リソース表現」と呼ばれていた次の記述子をサポートしています。

• 定数バッファー表現（CBV）。
• シェーダーリソース表現（SRV）。
• 順序なしアクセス表現（UAV）。
• サンプラー表現（SV）。
• レンダリングターゲット表現（RTV）。
• 深度テンプレートプレゼンテーション（DSV）。
• その他。

これらの記述子またはリソースの表現は、GPUのフロントエンドによって消費される構造（ブロック）と見なすことができます。 記述子のサイズは約32〜64バイトです。 記述子には、テクスチャのサイズ、フォーマット、レイアウトに関する情報が含まれています。
記述子は記述子のヒープに格納されます。これはメモリ内の構造のシーケンスです。

記述子テーブルは、オフセット値を使用してヒープ内の記述子を指します。 この表は、連続した範囲の記述子とシェーダーセルを比較し、ルートシグネチャを使用してアクセスできるようにします。 ルート署名には、ルート定数、ルート記述子、および静的サンプラーを含めることもできます。


図1.記述子、一連の記述子、記述子テーブル、ルート署名

図1は、記述子、一連の記述子、記述子テーブル、およびルート署名の間の関係を示しています。
図1で説明するコードは次のようになります。

// the init function sets the shader registers // parameters: type of descriptor, num of descriptors, base shader register // the first descriptor table entry in the root signature in // image 1 sets shader registers t1, b1, t4, t5 // performance: order from most frequent to least frequent used D3D12_DESCRIPTOR_RANGE Param0Ranges[3]; Param0Ranges[0].Init(D3D12_DESCRIPTOR_RANGE_SRV, 1, 1); // t1 Param0Ranges[1].Init(D3D12_DESCRIPTOR_RANGE_CBV, 1, 1); // b1 Param0Ranges[2].Init(D3D12_DESCRIPTOR_RANGE_SRV, 2, 4); // t4-t5 // the second descriptor table entry in the root signature // in image 1 sets shader registers u0 and b2 D3D12_DESCRIPTOR_RANGE Param1Ranges[2]; Param1Ranges[0].Init(D3D12_DESCRIPTOR_RANGE_UAV, 1, 0); // u0 Param1Ranges[1].Init(D3D12_DESCRIPTOR_RANGE_CBV, 1, 2); // b2 // set the descriptor tables in the root signature // parameters: number of descriptor ranges, descriptor ranges, visibility // visibility to all stages allows sharing binding tables // with all types of shaders D3D12_ROOT_PARAMETER Param[4]; Param[0].InitAsDescriptorTable(3, Param0Ranges, D3D12_SHADER_VISIBILITY_ALL); Param[1].InitAsDescriptorTable(2, Param1Ranges, D3D12_SHADER_VISIBILITY_ALL); // root descriptor Param[2].InitAsShaderResourceView(1, 0); // t0 // root constants Param[3].InitAsConstants(4, 0); // b0 (4x32-bit constants) // writing into the command list cmdList->SetGraphicsRootDescriptorTable(0, [srvGPUHandle]); cmdList->SetGraphicsRootDescriptorTable(1, [uavGPUHandle]); cmdList->SetGraphicsRootConstantBufferView(2, [srvCPUHandle]); cmdList->SetGraphicsRoot32BitConstants(3, {1,3,3,7}, 0, 4); 

上記のソースコードは、2つの記述子テーブル、1つのルート記述子と1つのルート定数を持つようにルート署名を設定します。 また、このコードは、ルート定数には間接的なアクセス権がないことを示しており、 SetGraphicsRoot32bitConstantsを呼び出すことで直接提供されます。 これらはシェーダーレジスタに直接関連しています。 定数バッファ自体も、定数バッファ記述子も、バインディングもありません。 ルート記述子は、メモリへのポインタを保存するため（記述子->メモリ）、1レベルの間接アクセスのみを持ち、記述子テーブルには2レベルの間接アクセス（記述子テーブル->記述子->メモリ）があります。

記述子は、SVやCBV / SRV / UAVなど、タイプに応じて異なるヒープにあります。 これは、ハードウェアプラットフォームが異なるとタイプの異なる記述子のサイズが非常に大きく異なるためです。 ヒープの変更は非常にリソースを消費する操作になる可能性があるため、記述子ヒープのタイプごとに1つのヒープのみを割り当てる必要があります。

一般に、DirectX 12は、100万を超える記述子の早期割り当てをサポートします。これは、ゲームレベル全体に十分な量です。 DirectXの以前のバージョンでは、ドライバーが独自の「条件」で実行されている間にリソース割り当てが発生し、DirectX 12では、リソース割り当てをまったく回避できました。 これは、記述子の割り当てがパフォーマンスに影響を与えなくなったことを意味します。

ご注意 第3世代（Ivy Bridge）および第4世代（Haswell）Intel®Core™プロセッサーで、DirectX 11およびWindowsディスプレイドライバーモデル（WDDM）アーキテクチャバージョン1.xを使用して、リソースはリソース参照に基づいてメモリに動的にマッピングされました一致するページテーブルの操作を含むコマンドバッファ内。 このため、データのコピーを避けることができました。 これらのアーキテクチャはGPUに2 GBのメモリしか割り当てなかったため、動的マッチングが重要でした（Intel®Xeon®プロセッサーE3-1200 v4（Broadwell）ファミリーではさらに多くが割り当てられました）。
DirectX 12およびWDDMバージョン2.xでは、作成時にリソースに静的仮想アドレスを割り当てる必要があり、この仮想アドレスは作成後に変更できないため、必要に応じてリソースをGPUの仮想アドレス空間に再割り当てすることはできなくなりました。 リソースがGPUメモリから排出された場合でも、リソースが再び常駐するようになると、後でその仮想アドレスが保持されます。
したがって、Ivy Bridge / HaswellファミリのGPUに割り当てられた2 GBの合計メモリ容量が制限要因になる可能性があります。

前の記事で述べたように、完全にバランスのとれたアプリケーションは、すべてのタイプのバインディングの組み合わせを使用できます：ルート定数、ルート記述子、レンダリング呼び出しの発行時にオンザフライで受信される記述子の記述子テーブル、および大きな記述子テーブルの動的なインデックス付け。
記述子テーブルを使用する場合と比較して、ルート定数とルート記述子の大きなセットを使用する場合、さまざまなアーキテクチャのパフォーマンスは異なる場合があります。 このため、ターゲットハードウェアプラットフォームに応じて、ルートパラメーターと記述子テーブルの関係を最適に構成する必要がある場合があります。

予想される変更

どの変更が追加のリソースを必要とするかを理解するには、まずゲームエンジンが通常どのようにデータ、記述子、記述子テーブル、およびルート署名を変更するかを正確に知る必要があります。

いわゆる定数（定数）データから始めましょう。 ほとんどのゲームでは、すべての永続データは通常「システムメモリ」に保存されます。 ゲームエンジンは、CPUで使用可能なメモリ内のデータを変更してから、フレーム内のデータを変更します。 永続データのブロック全体がGPUメモリにコピーまたはマップされ、定数バッファー表現またはルート記述子を使用してGPUによって読み取られます。

SetGraphicsRoot32BitConstants（）をルート定数として使用して永続データが提供される場合、ルート記述子のエントリは変更されませんが、データは変更できます。 CBV ==記述子および記述子テーブルを使用して提供される場合、記述子は変更されませんが、データは変更される場合があります。

定数バッファの複数の表現が必要な場合（たとえば、レンダリング中のダブルまたはトリプルバッファリングの場合）、CBVまたは記述子はルート署名の各フレームで変更できます。

これらのテクスチャでは、GPUメモリが起動時に割り当てられると想定されています。 次に、SV ==記述子が作成され、記述子テーブルまたは静的サンプラーに保存され、ルート記述子のリンクがそれを指します。 その後、データと記述子または静的サンプラーは変更されません。

テクスチャやバッファデータの変更などの動的データ（たとえば、ローカライズされたテキストが表示されたテクスチャ、アニメーション化された頂点や作成されたモデルのバッファ）の場合、レンダリングターゲットまたはバッファを割り当て、RTVまたはUAV、つまり記述子を提供します。その後、これらの記述子変更されない可能性があります。 レンダーターゲットまたはバッファ内のデータが変更される場合があります。
複数のレンダリング目標またはバッファが必要な場合（たとえば、レンダリング中のダブルまたはトリプルバッファリングの場合）、ルートシグネチャの各フレームの記述子を変更できます。

さらなる議論では、変更が次のものに関連付けられている場合、リソースバインディングにとって重要であると見なされます。

• CBV、RTV、UAVなどの記述子テーブル内の記述子を変更または置換します。
• ルート署名のエントリを変更します。

Haswell / Broadwellプロセッサフ​​ァミリのディスクリプタテーブルのディスクリプタ

Haswell / Broadwellプラットフォームでは、ルートシグネチャの1つの記述子テーブルを変更すると、すべての記述子テーブルを変更するのと同じくらいのリソースが消費されます。 1つの引数を変更すると、機器は現在のすべての引数のコピー（バージョン）を作成する必要があるという事実につながります。 ルート署名のルートパラメータの数は、サブセットを変更するときに、機器が新しいバージョン（つまり、完全なコピー）を作成する必要があるデータの量です。

ご注意 記述子ヒープ、バッファリソースなど、DirectX 12の他のすべてのタイプのメモリでは、機器は新しいバージョンを作成しません。

つまり、すべてのパラメーターを変更するのに、ほぼ同じリソースが費やされます（[Loritzen]および[MSDN]を参照）。 もちろん、何も変更されていない場合、最も少ないリソースが消費されますが、それは役に立たないです。

ご注意 メモリが高速と低速に分割されている他の機器では、ルート引数ストアは、引数が変更された新しいバージョンのメモリ領域、つまり高速領域または低速領域のみを作成します。

Haswell / Broadwellプラットフォームでは、機器バインドテーブルのサイズが制限されているため、記述子テーブルを変更するための追加コストが発生する場合があります。

これらのハードウェアプラットフォームの記述子テーブルは、ハードウェア「バインディングテーブル」を使用します。 各バインドテーブルエントリは、記述子ヒープ内のオフセットと見なすことができる単一のDWORD値です。 64 KBのリングには、バインディングテーブルの16,384レコードを保存できます。

つまり、各描画呼び出しで消費されるメモリの量は、記述子テーブルでインデックスが付けられ、ルート署名で参照される記述子の総数に依存します。
テーブルエントリのバインドに64 KBのメモリが不足すると、ドライバーは別の64 KBのメモリバインドテーブルを割り当てます。 これらのテーブルを切り替えると、図2に示すように、コンベアが停止します。


図2.コンベヤーの停止（Andrew Loritzenによる描画）

ルート署名は、記述子テーブル内の64個の記述子を参照すると仮定します。 16 384/64 = 256の描画呼び出しごとに停止します。

ルート署名を変更するにはいくつかのリソースが必要なため、記述子テーブル内の記述子の数が多いルート署名よりも、記述子テーブル内の記述子の数が少ない多くのルート署名を使用することをお勧めします。

したがって、Haswell / Broadwellプラットフォームでは、記述子への参照をできるだけ少なくすることが望ましいです。
レンダリングに関してこれはどういう意味ですか？ 各テーブルでより少ない記述子で（したがって、より多くのルート署名で）より多くの記述子テーブルを使用する場合、パイプライン状態オブジェクト（PSO）の数は、そのようなオブジェクトとルート署名の間で1対1の関係が維持されるため増加します。
パイプライン状態オブジェクトの数の増加は、シェーダーの数の増加につながる可能性があります。この場合、一般的な推奨に従って、より広い範囲の機能を備えたより長いシェーダーの代わりに、より特化できます。

Haswell / Broadwellプロセッサフ​​ァミリのルーティング定数と記述子

上記のように、消費されるリソースの観点から、1つの記述子テーブルを変更することは、すべての記述子テーブルを変更することと同等です。 同様に、1つのルート定数またはルート記述子の変更は、すべての変更と同等です（[Loritzen]を参照）。

ルート定数は、「ブロードキャスト定数」を使用して実装されます。これは、機器がオペレーティングユニットレジスタ（EU）に事前入力するために使用するバッファーです。 値はEUストリームの開始直後に利用できるため、記述子テーブルではなくルート定数として永続データを保存することにより、パフォーマンスを向上させることができます。
ルート記述子も、ブロードキャスト定数を使用して実装されます。 これらは、通常のメモリアクセスパスを介してデータを読み取るシェーダーに定数の形式で渡されるポインターです。

記述子テーブルとルート定数/ Haswell / Broadwellプロセッサフ​​ァミリの記述子

記述子テーブル、ルート定数、および記述子の実装を調べました。 これで、この記事の主な質問「答えは何ですか？」に答えることができます。 ハードウェアバインディングテーブルのサイズが制限されており、この制限を超えることに関連して停止する可能性があるため、ルート定数とルート記述子の変更は、ハードウェアバインディングテーブルを必要としないため、Haswell / Broadwellプラットフォームでの要求が少ない操作のようです。 この原則に従う場合、描画の呼び出しごとにデータが変更されると、最大の効果が得られます。

Haswell / Broadwellプロセッサフ​​ァミリのスタティックサンプラ

前の記事で説明したように、ルート署名でサンプラーを定義するか、HLSLルート署名言語を使用してシェーダーで直接サンプラーを定義できます。 このようなサンプラーは静的と呼ばれます。

Haswell / Broadwellプラットフォームでは、ドライバーは静的サンプラーをサンプラーの定期的なヒープに配置します。 これは、記述子に手動で配置するのと同じです。 他のハードウェアプラットフォームでは、サンプラーがシェーダーレジスタに配置されるため、静的サンプルをシェーダーに直接コンパイルできます。

一般に、静的サンプラーはどのプラットフォームでも高いパフォーマンスを提供するため、予約なしで使用できます。 それでも、Haswell / Broadwellプラットフォームでは、記述子テーブル内の記述子の数が増えると、ハードウェア記述子テーブルに含まれるセルが16,384セルだけになるため、パイプラインが停止する可能性が高くなります。
HLSLの静的サンプラーの構文は次のとおりです。

 StaticSampler( sReg, [ filter = FILTER_ANISOTROPIC, addressU = TEXTURE_ADDRESS_WRAP, addressV = TEXTURE_ADDRESS_WRAP, addressW = TEXTURE_ADDRESS_WRAP, mipLODBias = 0.f, maxAnisotropy = 16, comparisonFunc = COMPARISON_LESS_EQUAL, borderColor = STATIC_BORDER_COLOR_OPAQUE_WHITE, minLOD = 0.f, maxLOD = 3.402823466e+38f, space = 0, visibility = SHADER_VISIBILITY_ALL ]) 

ほとんどのパラメーターは、C ++レベルで使用されるパラメーターと類似しているため、説明を必要としません。 主な違いは境界線の色です。C++レベルでは全色範囲がサポートされますが、HLSLレベルでは不透明な白、不透明な黒、透明な黒のみが使用可能です。 静的シェーダーの例。

 StaticSampler(s4, filter=FILTER_MIN_MAG_MIP_LINEAR) 

スカイレイク

Skylakeは、1つの記述子テーブルで記述子のヒープ全体（約100万のリソース）の動的なインデックス作成をサポートしています。 これは、記述子ヒープの利用可能なメモリ全体をインデックス化するには、単一の記述子テーブルで十分な場合があることを意味します。
以前のアーキテクチャと比較すると、ルート署名の記述子テーブルエントリを頻繁に変更する必要はありません。 さらに、ルート署名の数を減らすこともできます。 もちろん、異なる素材には異なるシェーダーが必要になるため、異なるコンベヤー状態オブジェクト（PSO）が必要になります。 ただし、これらのPSOは同じルート署名を参照できます。
最新のグラフィックエンジンは、DirectX 9およびDirectX 11の以前のバージョンよりも少ないシェーダーを使用するため、シェーダーおよび関連する状態の変更にリソースを費やすことを避け、ルートシグネチャおよび（したがって）PSOオブジェクトの数を減らして、ハードウェアプラットフォームのパフォーマンスを向上させることができます。

おわりに

Haswell / BroadwellおよびSkylakeプラットフォームについて言えば、DirectX 12アプリケーションのパフォーマンスを向上させるための推奨事項は、使用するプラットフォームによって異なります。 Haswell / Broadwellの場合、記述子テーブル内の記述子の数は少ないことが望ましいのに対し、Skylakeの場合、記述子テーブルにはできるだけ多くの記述子を含めることをお勧めしますが、テーブル自体は少なくする必要があります。
最適なパフォーマンスを得るために、アプリケーション開発者は起動時にハードウェアプラットフォームのタイプを確認し、それに応じてリソースバインド方法を選択できます。 （Intel®ハードウェアのさまざまなアーキテクチャを検出する方法を示すGPU定義の例は、 こちらから入手できます 。）リソースバインド方法の選択により、システムシェーダーの記述方法が決まります。

リンクと有用な資料

1. [Loritzen] Andrew Loritzenほか、「Intel GraphicsでのDirectX 12による効果的なレンダリング」、GDC、2015年
2. [MSDN] MSDN、「記述子テーブルの使用の強化」 。
3. Microsoft DirectXブログ
4. TwitterのDirectX 12： @ DirectX12
5. Direct3D * 12-PCでのコンソールAPIの効率とパフォーマンス
6. Microsoft DirectX 12グラフィックスに関するトレーニング資料（YouTubeチャンネル） 。