Microsoft DirectX 12のリソースバインディング

2014年3月20日に、MicrosoftはGame Developers ConferenceでDirectX * 12のリリースを発表しました。リソースの過剰な処理を削減することにより、DirectX 12はより効率的なアプリケーションパフォーマンスと低消費電力に貢献するため、充電せずにモバイルデバイスで長時間プレイできます。

SIGGRAPH 2014では、Intelの専門家がMicrosoft Surface * Pro 3タブレットで小惑星を使用した簡単なデモを開始する際のCPUの消費電力を測定しました 。ボタンを押すと、デモアプリケーションをDirectX 11 APIからDirectX 12 APIに切り替えることができます このデモアプリケーションは、固定フレームレートで宇宙に膨大な数の小惑星を描画します。 DirectX 12 APIを使用する場合、CPUの消費電力はDirectX 11 **に比べて半分以上になります。 デバイスは低強度のサーマルモードで動作し、バッテリー電力でより長く動作することができます。 典型的なゲームシナリオでは、未使用のCPUパワーはすべて、物理学、人工知能、経路探索アルゴリズム、またはCPU負荷が高いその他のタスクの改善に費やすことができます。 したがって、ゲームは機能がより強力になり、電力消費の観点からより経済的になります。

ツール

DirectX 12ベースのゲームには次のものが必要です。

• Windows * 10
• DirectX 12 SDK
• Visual Studio * 2013
• DirectX 12をサポートするGPUドライバー

ゲーム開発者の方は、Microsoft DirectX Early Access Programに参加してみてください。

DirectX Early Access Programに同意すると、SDKのインストール手順とGP用ドライバーが届きます。

復習

高レベルの観点から、DirectX 10およびDirectX 11と比較して、DirectX 12アーキテクチャはメモリ内の状態管理、追跡、およびリソース管理の分野が異なります。

DirectX 10は、実行時に状態のグループを構成する状態オブジェクトを導入しました。 DirectX 12では、状態パイプラインオブジェクト（PSO）が導入され、シェーダーと共にさらに大きな状態オブジェクトとして機能します。 この記事では、リソースの操作における変更について説明します。 PSOの状態のグループ化については、今後の記事で説明します。

DirectX 11では、システムがリソース使用量の予測と追跡を担当していました。これにより、DirectX 11の大規模な使用のためにアプリケーションを作成する機能が制限されました。DirectX12では、



1.リソースバインディング

不完全なGP操作がこれらのリソースを参照する可能性があるため、DirectX 10および11は、アプリケーションによって既にリリースされたリソースを維持するために、グラフィックスパイプラインへのリソースのバインドを追跡しました。 DirectX 12では、システムはリソースバインディングを追跡しません。 アプリケーション、つまりプログラマは、オブジェクトのライフサイクルの管理に関与する必要があります。



2.リソースバインディング分析

DirectX 12は、リソースバインディングを追跡して、リソース切り替えが発生したかどうかを判断しません。 たとえば、アプリケーションは、レンダーターゲット（RTV）表現を使用してレンダーターゲットに書き込み、シェーダーリソースビュー（SRV）を使用してそのレンダーターゲットをテクスチャとして読み取ることができます。 DirectX 11 APIでは、GPUドライバーは、データの読み取り、変更、およびメモリへの書き込み時の競合を回避するために、リソースの切り替えがいつ行われたかを「知る」必要がありました。 DirectX 12では、個別のAPI呼び出しを使用してすべてのリソース転送を識別および追跡する必要があります。



3.マップされたメモリの同期

DirectX 11では、ドライバーはCPUとGPU間のマップされたメモリの同期を処理します。 CPUアクセス用にマッピングされたリソースのマッピングがまだキャンセルされていないため、システムはリソースバインディングを分析してレンダリング遅延が必要かどうかを確認しました。 DirectX 12では、アプリケーションはリソースへのCPUおよびGPUアクセスの同期を処理する必要があります。 メモリアクセスを同期するための単一のメカニズムは、GPUで処理が完了したときにスレッドを起動するイベントを要求します。

これらのリソース使用パターンをアプリケーションに移行するには、広範なGPUアーキテクチャをサポートできる新しいプログラミングインターフェイスのセットが必要です。

この記事の残りの部分では、新しいリソースバインディングメカニズムについて説明します。最初のメカニズムは記述子です。

記述子

記述子は、メモリに格納されているリソースを記述します。 記述子は、GP用の「不透明な」形式でGPのオブジェクトを記述するデータブロックです。 わずかに伸びた記述子は、DirectX 11の「表現」の古いシステムの代替と見なすことができます。シェーダーリソース表現（SRV）や無秩序なアクセス表現（UAV）などのさまざまな種類のDirectX 11記述子に加えて、他の種類の記述子がDirectX 12に登場しましたたとえば、サンプラーおよび永続的バッファ表現（CBV）。

たとえば、SRVは、使用するベースリソース、バンプマップとアレイのスライスのセット、およびメモリを解釈する形式を選択します。 SRV記述子には、GPUのDirect3D *リソース（テクスチャの場合があります）の仮想アドレスが含まれている必要があります。 アプリケーションは、基礎となるリソースが破壊されず、非居住者のためにアクセスできないことを確認する必要があります。

図 1は、テクスチャの「表現」へのハンドルを示しています。





図1.記述子内のシェーダーリソースの表現[許可を得て使用©Microsoft Corporation]



DirectX 12でシェーダーリソース表現を作成するには、次のDirect3Dデバイス構造とメソッドを使用します。

typedef struct D3D12_SHADER_RESOURCE_VIEW_DESC { DXGI_FORMAT Format; D3D12_SRV_DIMENSION ViewDimension; union { D3D12_BUFFER_SRV Buffer; D3D12_TEX1D_SRV Texture1D; D3D12_TEX1D_ARRAY_SRV Texture1DArray; D3D12_TEX2D_SRV Texture2D; D3D12_TEX2D_ARRAY_SRV Texture2DArray; D3D12_TEX2DMS_SRV Texture2DMS; D3D12_TEX2DMS_ARRAY_SRV Texture2DMSArray; D3D12_TEX3D_SRV Texture3D; D3D12_TEXCUBE_SRV TextureCube; D3D12_TEXCUBE_ARRAY_SRV TextureCubeArray; D3D12_BUFFEREX_SRV BufferEx; }; } D3D12_SHADER_RESOURCE_VIEW_DESC; interface ID3D12Device { ... void CreateShaderResourceView ( _In_opt_ ID3D12Resource* pResource, _In_opt_ const D3D12_SHADER_RESOURCE_VIEW_DESC* pDesc, _In_ D3D12_CPU_DESCRIPTOR_HANDLE DestDescriptor); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SRVコードの例は次のようになります。

 // create SRV D3D12_SHADER_RESOURCE_VIEW_DESC srvDesc; ZeroMemory(&srvDesc, sizeof(D3D12_SHADER_RESOURCE_VIEW_DESC)); srvDesc.Format = mTexture->Format; srvDesc.ViewDimension = D3D12_SRV_DIMENSION_TEXTURE2D; srvDesc.Texture2D.MipLevels = 1; mDevice->CreateShaderResourceView(mTexture.Get(), &srvDesc, mCbvSrvDescriptorHeap->GetCPUDescriptorHandleForHeapStart());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは、2次元テクスチャのSRVを作成し、その形式と仮想GPUアドレスを示します。 CreateShaderResourceViewの最後の引数は、このメソッドを呼び出す前に割り当てられたハンドルのハンドルへのハンドルです。 記述子は通常、記述子のヒープに格納されます。詳細については、次のセクションで説明します。

ご注意 いわゆるルートパラメーターを使用して、いくつかのタイプの記述子をGPUに転送することもできます（ドライバーのバージョンを考慮に入れて）。 詳細については、以下を参照してください。

記述子のヒープ

記述子の束は、複数の記述子に割り当てられた1つのメモリ量と考えることができます。 異なるタイプのヒープには、1つ以上のタイプの記述子が含まれる場合があります。 現在、次のタイプがサポートされています。

 Typedef enum D3D12_DESCRIPTOR_HEAP_TYPE { D3D12_CBV_SRV_UAV_DESCRIPTOR_HEAP = 0, D3D12_SAMPLER_DESCRIPTOR_HEAP = (D3D12_CBV_SRV_UAV_DESCRIPTOR_HEAP + 1) , D3D12_RTV_DESCRIPTOR_HEAP = ( D3D12_SAMPLER_DESCRIPTOR_HEAP + 1 ) , D3D12_DSV_DESCRIPTOR_HEAP = ( D3D12_RTV_DESCRIPTOR_HEAP + 1 ) , D3D12_NUM_DESCRIPTOR_HEAP_TYPES = ( D3D12_DSV_DESCRIPTOR_HEAP + 1 ) } D3D12_DESCRIPTOR_HEAP_TYPE;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CBV、SRV、およびUAV記述子にはヒープタイプがあります。 レンダリングターゲットビュー（RTV）および深度フォーマットビュー（DSV）を操作するためのタイプもあります。

次のコードは、9つの記述子の記述子の束を作成します。各記述子は、CBV、SRV、またはUAVです。

 // create shader resource view and constant buffer view descriptor heap D3D12_DESCRIPTOR_HEAP_DESC descHeapCbvSrv = {}; descHeapCbvSrv.NumDescriptors = 9; descHeapCbvSrv.Type = D3D12_CBV_SRV_UAV_DESCRIPTOR_HEAP; descHeapCbvSrv.Flags = D3D12_DESCRIPTOR_HEAP_SHADER_VISIBLE; ThrowIfFailed(mDevice->CreateDescriptorHeap(&descHeapCbvSrv, __uuidof(ID3D12DescriptorHeap), (void**)&mCbvSrvDescriptorHeap));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ヒープ記述の最初の2つのエントリは、このヒープ内に存在する可能性のある記述子の数と記述子のタイプです。 3番目のパラメーターD3D12_DESCRIPTOR_HEAP_SHADER_VISIBLEは 、シェーダーから見える記述子のこの束を記述します。 たとえば、CPU内の記述子の中間ストレージ、またはシェーダー内からアクセスできないRTVに、シェーダーからは見えないヒープ記述子を使用できます。

このコードはフラグを設定します。これにより、多くの記述子がシェーダーから見えるようになりますが、間接アドレス指定には別のレベルがあります。 シェーダーは、記述子テーブルを通して記述子の束を「見る」ことができます（テーブルを使用しないルート記述子もあります。詳細については以下を参照してください）。

記述子テーブル

記述子ヒープの主な目標は、レンダリングに必要なすべての記述子を格納するために必要な量のメモリを割り当てることです。たとえば、1フレーム以上

ご注意 記述子のヒープを切り替えるとき、使用する機器に応じてGPパイプラインをクリーニングできます。 したがって、記述子のヒープ間の切り替えの操作を最小限に抑えるか、パイプラインがまだクリーンアップされている他の操作と組み合わせる必要があります。



記述子テーブルは、オフセットを使用する記述子の束を指します。 グラフィックパイプラインに常に束全体を強制的に表示させる代わりに、記述子テーブルを切り替えることで、このシェーダーで使用されるリソースのセットを大幅なコストなしで変更できます。 この場合、シェーダーはヒープスペースでリソースを見つける必要はありません。

言い換えると、図7に示すように、アプリケーションは同じヒープを指すさまざまなシェーダーに対して複数の記述子テーブルを使用できます。 2。





図2.さまざまなシェーダーが、複数の記述子テーブルを使用した一連の記述子を指している



次のコード例では、ピクセルシェーダーから見えるSRVとサンプラーの記述子テーブルを作成します。

 // define descriptor tables for a SRV and a sampler for pixel shaders D3D12_DESCRIPTOR_RANGE descRange[2]; descRange[0].Init(D3D12_DESCRIPTOR_RANGE_SRV, 1, 0); descRange[1].Init(D3D12_DESCRIPTOR_RANGE_SAMPLER, 1, 0); D3D12_ROOT_PARAMETER rootParameters[2]; rootParameters[0].InitAsDescriptorTable(1, &descRange[0], D3D12_SHADER_VISIBILITY_PIXEL); rootParameters[1].InitAsDescriptorTable(1, &descRange[1], D3D12_SHADER_VISIBILITY_PIXEL);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同時に、記述子テーブルはピクセルシェーダーのみに表示されます。 この制限は、 D3D12_SHADER_VISIBILITY_PIXELフラグを使用して設定されます。 次のリストは、記述子テーブルの可視性のさまざまなレベルを定義しています。

 typedef enum D3D12_SHADER_VISIBILITY { D3D12_SHADER_VISIBILITY_ALL = 0, D3D12_SHADER_VISIBILITY_VERTEX = 1, D3D12_SHADER_VISIBILITY_HULL = 2, D3D12_SHADER_VISIBILITY_DOMAIN = 3, D3D12_SHADER_VISIBILITY_GEOMETRY = 4, D3D12_SHADER_VISIBILITY_PIXEL = 5 } D3D12_SHADER_VISIBILITY;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべての可視性を設定するフラグを指定すると、可視性は1回だけ設定されますが、引数はシェーダーのすべてのステージに渡されます。

シェーダーは記述子テーブルを使用してリソースを検出できますが、最初に、シェーダーはルート署名のルートパラメーターを使用してこれらの記述子テーブルについて「学習」する必要があります。

ルート署名とパラメーター

ルートシグネチャには、シェーダーがアクセスを必要とするリソースを見つけるために使用するルートパラメーターが格納されます。 これらのパラメーターは、アプリケーションがシェーダーで利用できるようにする必要がある一連のリソースのコマンドのリストにバインディングスペースの形式で存在します。

ルート引数は次のようになります。

• 記述子テーブル。 前述のように、それらにはヒープ内のオフセットと記述子の数が含まれます。
• ルート記述子。 ルートパラメータに直接格納できる記述子はごく少数です。 この場合、アプリケーションはこれらの記述子を記述子のヒープに配置する必要がなくなり、間接的なアドレス指定がなくなります。
• ルート定数。 これらはシェーダーに直接提供される定数であり、ルート記述子と記述子テーブルを操作する必要はありません。

最適なパフォーマンスを実現するために、アプリケーションは通常、ルートパラメーターを頻度の降順で並べ替えます。

記述子テーブル、ルート記述子、ルート定数などのすべてのルートパラメーターは、コマンドのリストに結合され、ドライバーはアプリケーションに代わってバージョンを制御します。 つまり、レンダーコールまたは送信コール間でルートパラメーターが変更されるたびに、機器はルート署名のバージョン番号を更新します。 引数が変更されると、各レンダーコールまたは送信コールは、ルートパラメーター状態の一意の完全なセットを受け取ります。

ルート記述子とルート定数は、アクセス時の間接GPアドレス指定のレベルを下げます。 記述子テーブルを使用すると、より大量のデータにアクセスできますが、間接アドレス指定のレベルが上がります。 間接アドレス指定のレベルが高いため、記述子テーブルを使用する場合、コマンドのリストが実行のために送信されるまで、アプリケーションはコンテンツを初期化できます。 さらに、すべてのDirectX 12ハードウェアでサポートされる5.1シェーダーモデルにより、シェーダーは指定されたすべての記述子テーブルに動的にインデックスを付けることができます。 したがって、シェーダーはシェーダーの実行中に記述子テーブルから目的の記述子を選択できます。 アプリケーションは単純に1つの大きな記述子テーブルを作成し、常にインデックスを使用して（たとえば、材料識別子を使用して）必要な記述子を取得できます。



記述子テーブルを使用する場合と比較して、ルート定数とルート記述子の大きなセットを使用する場合、異なるアーキテクチャのパフォーマンスは異なる場合があります。 このため、ターゲットハードウェアプラットフォームに応じて、ルートパラメーターと記述子テーブルの関係を最適に構成する必要があります。

完全にバランスのとれたアプリケーションは、すべてのタイプのバインディングの組み合わせを使用できます。ルート定数、ルート記述子、レンダリング呼び出しの発行時にオンザフライで受信される記述子の記述子テーブル、および大きな記述子テーブルの動的インデックス付け。



次のコードでは、上記の2つの記述子テーブルがルート署名のルートパラメーターとして保存されます。

 // define descriptor tables for a SRV and a sampler for pixel shaders D3D12_DESCRIPTOR_RANGE descRange[2]; descRange[0].Init(D3D12_DESCRIPTOR_RANGE_SRV, 1, 0); descRange[1].Init(D3D12_DESCRIPTOR_RANGE_SAMPLER, 1, 0); D3D12_ROOT_PARAMETER rootParameters[2]; rootParameters[0].InitAsDescriptorTable(1, &descRange[0], D3D12_SHADER_VISIBILITY_PIXEL); rootParameters[1].InitAsDescriptorTable(1, &descRange[1], D3D12_SHADER_VISIBILITY_PIXEL); // store the descriptor tables int the root signature D3D12_ROOT_SIGNATURE descRootSignature; descRootSignature.Init(2, rootParameters, 0); ComPtr<ID3DBlob> pOutBlob; ComPtr<ID3DBlob> pErrorBlob; ThrowIfFailed(D3D12SerializeRootSignature(&descRootSignature, D3D_ROOT_SIGNATURE_V1, pOutBlob.GetAddressOf(), pErrorBlob.GetAddressOf())); ThrowIfFailed(mDevice->CreateRootSignature(pOutBlob->GetBufferPointer(), pOutBlob->GetBufferSize(), __uuidof(ID3D12RootSignature), (void**)&mRootSignature));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PSOのすべてのシェーダーは、このPSOで指定されたルートシグネチャと互換性がある必要があります。 そうしないと、PSOは作成されません。

ルート署名は、コマンドまたはパッケージのリストに指定する必要があります。 これを行うには、次を呼び出します。



1 commandList-> SetGraphicsRootSignature（mRootSignature）;

ルート署名を設定した後、一連のバインディングを定義する必要があります。 上記の例では、これは次のコードを使用して行われます。

 // set the two descriptor tables to index into the descriptor heap // for the SRV and the sampler commandList->SetGraphicsRootDescriptorTable(0, mCbvSrvDescriptorHeap->GetGPUDescriptorHandleForHeapStart()); commandList->SetGraphicsRootDescriptorTable(1, mSamplerDescriptorHeap->GetGPUDescriptorHandleForHeapStart());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションは、レンダーコールまたは送信コールを発行する前に、ルート署名の2つのセルのそれぞれに適切なパラメーターを設定する必要があります。 たとえば、最初のセルには、記述子のヒープをインデックス内のSRV記述子と一致させる記述子マーカーがあり、2番目のセルには、記述子のヒープをインデックス内の記述子サンプラと一致させる記述子テーブルがあります。

たとえば、アプリケーションは、呼び出しのレンダリングの間隔で2番目のセルのバインドを変更できます。 これは、2回目のレンダリング呼び出しでは、2番目のセルバインディングのみが必要であることを意味します。

コンポーネントをまとめる

以下の大きなコードスニペットは、リソースのバインドに使用されるすべてのメカニズムを示しています。 このアプリケーションは1つのテクスチャのみを使用し、このコードはこのテクスチャのサンプラーとSRVを提供します。

 // define descriptor tables for a SRV and a sampler for pixel shaders D3D12_DESCRIPTOR_RANGE descRange[2]; descRange[0].Init(D3D12_DESCRIPTOR_RANGE_SRV, 1, 0); descRange[1].Init(D3D12_DESCRIPTOR_RANGE_SAMPLER, 1, 0); D3D12_ROOT_PARAMETER rootParameters[2]; rootParameters[0].InitAsDescriptorTable(1, &descRange[0], D3D12_SHADER_VISIBILITY_PIXEL); rootParameters[1].InitAsDescriptorTable(1, &descRange[1], D3D12_SHADER_VISIBILITY_PIXEL); // store the descriptor tables in the root signature D3D12_ROOT_SIGNATURE descRootSignature; descRootSignature.Init(2, rootParameters, 0); ComPtr<ID3DBlob> pOutBlob; ComPtr<ID3DBlob> pErrorBlob; ThrowIfFailed(D3D12SerializeRootSignature(&descRootSignature, D3D_ROOT_SIGNATURE_V1, pOutBlob.GetAddressOf(), pErrorBlob.GetAddressOf())); ThrowIfFailed(mDevice->CreateRootSignature(pOutBlob->GetBufferPointer(), pOutBlob->GetBufferSize(), __uuidof(ID3D12RootSignature), (void**)&mRootSignature)); // create descriptor heap for shader resource view D3D12_DESCRIPTOR_HEAP_DESC descHeapCbvSrv = {}; descHeapCbvSrv.NumDescriptors = 1; // for SRV descHeapCbvSrv.Type = D3D12_CBV_SRV_UAV_DESCRIPTOR_HEAP; descHeapCbvSrv.Flags = D3D12_DESCRIPTOR_HEAP_SHADER_VISIBLE; ThrowIfFailed(mDevice->CreateDescriptorHeap(&descHeapCbvSrv, __uuidof(ID3D12DescriptorHeap), (void**)&mCbvSrvDescriptorHeap)); // create sampler descriptor heap D3D12_DESCRIPTOR_HEAP_DESC descHeapSampler = {}; descHeapSampler.NumDescriptors = 1; descHeapSampler.Type = D3D12_SAMPLER_DESCRIPTOR_HEAP; descHeapSampler.Flags = D3D12_DESCRIPTOR_HEAP_SHADER_VISIBLE; ThrowIfFailed(mDevice->CreateDescriptorHeap(&descHeapSampler, __uuidof(ID3D12DescriptorHeap), (void**)&mSamplerDescriptorHeap)); // skip the code that uploads the texture data into heap // create sampler descriptor in the sample descriptor heap D3D12_SAMPLER_DESC samplerDesc; ZeroMemory(&samplerDesc, sizeof(D3D12_SAMPLER_DESC)); samplerDesc.Filter = D3D12_FILTER_MIN_MAG_MIP_LINEAR; samplerDesc.AddressU = D3D12_TEXTURE_ADDRESS_WRAP; samplerDesc.AddressV = D3D12_TEXTURE_ADDRESS_WRAP; samplerDesc.AddressW = D3D12_TEXTURE_ADDRESS_WRAP; samplerDesc.MinLOD = 0; samplerDesc.MaxLOD = D3D11_FLOAT32_MAX; samplerDesc.MipLODBias = 0.0f; samplerDesc.MaxAnisotropy = 1; samplerDesc.ComparisonFunc = D3D12_COMPARISON_ALWAYS; mDevice->CreateSampler(&samplerDesc, mSamplerDescriptorHeap->GetCPUDescriptorHandleForHeapStart()); // create SRV descriptor in the SRV descriptor heap D3D12_SHADER_RESOURCE_VIEW_DESC srvDesc; ZeroMemory(&srvDesc, sizeof(D3D12_SHADER_RESOURCE_VIEW_DESC)); srvDesc.Format = SampleAssets::Textures->Format; srvDesc.ViewDimension = D3D12_SRV_DIMENSION_TEXTURE2D; srvDesc.Texture2D.MipLevels = 1; mDevice->CreateShaderResourceView(mTexture.Get(), &srvDesc, mCbvSrvDescriptorHeap->GetCPUDescriptorHandleForHeapStart()); // writing into the command list // set the root signature commandList->SetGraphicsRootSignature(mRootSignature); // other commands here ... // set the two descriptor tables to index into the descriptor heap // for the SRV and the sampler commandList->SetGraphicsRootDescriptorTable(0, mCbvSrvDescriptorHeap->GetGPUDescriptorHandleForHeapStart()); commandList->SetGraphicsRootDescriptorTable(1, mSamplerDescriptorHeap->GetGPUDescriptorHandleForHeapStart());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

静的サンプラー

そのため、記述子の束と記述子テーブルを使用してサンプラーを作成する方法を見ました。 しかし、アプリケーションでサンプラーを使用する別の方法があります。 多くのアプリケーションで必要なサンプラーのセットは限られているため、静的サンプラーをルート引数として使用できます。

現在、ルート署名は次のとおりです。

 typedef struct D3D12_ROOT_SIGNATURE { UINT NumParameters; const D3D12_ROOT_PARAMETER* pParameters; UINT NumStaticSamplers; const D3D12_STATIC_SAMPLER* pStaticSamplers; D3D12_ROOT_SIGNATURE_FLAGS Flags; // Initialize struct void Init( UINT numParameters, const D3D12_ROOT_PARAMETER* _pParameters, UINT numStaticSamplers = 0, const D3D12_STATIC_SAMPLER* _pStaticSamplers = NULL, D3D12_ROOT_SIGNATURE_FLAGS flags = D3D12_ROOT_SIGNATURE_NONE) { NumParameters = numParameters; pParameters = _pParameters; NumStaticSamplers = numStaticSamplers; pStaticSamplers = _pStaticSamplers; Flags = flags; } D3D12_ROOT_SIGNATURE() { Init(0,NULL,0,NULL,D3D12_ROOT_SIGNATURE_NONE);} D3D12_ROOT_SIGNATURE( UINT numParameters, const D3D12_ROOT_PARAMETER* _pParameters, UINT numStaticSamplers = 0, const D3D12_STATIC_SAMPLER* _pStaticSamplers = NULL, D3D12_ROOT_SIGNATURE_FLAGS flags = D3D12_ROOT_SIGNATURE_NONE) { Init(numParameters, _pParameters, numStaticSamplers, _pStaticSamplers, flags); } } D3D12_ROOT_SIGNATURE;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

静的サンプラーのセットは、ルート署名のルートパラメーターとは無関係に定義できます。 前述のように、ルートパラメーターは、実行時に引数を提供できるバインディングスペースを定義しますが、静的サンプラーは定義によって変更されません。

ルート署名はHLSLで作成できるため、同じ場所に静的サンプラーを作成できます。 現在、アプリケーションには2032個までの一意の静的サンプラーを含めることができます。 これは、次の2のべき乗よりもわずかに少なく、ドライバーが内部使用のためにスペースを使用できるようにします。

ルートシグネチャで定義された静的サンプラーは、アプリケーションがヒープ記述子に配置するために選択したサンプラーから独立しているため、両方のメカニズムを同時に使用できます。



サンプラーの選択が完全に動的であり、シェーダーのコンパイル時に不明である場合、アプリケーションは記述子のヒープ内でサンプラーを管理する必要があります。

おわりに

DirectX 12は、リソース使用パターンの完全な制御をサポートします。 アプリケーション開発者は、記述子ヒープ内のメモリの割り当て、記述子内のリソースの記述、および記述子テーブルを介したヒープ記述子へのインデックス内のシェーダーのアドレス指定を担当します。これは、ルート署名を使用してシェーダー用に「拡張」されます。

さらに、ルートシグネチャを使用して、次の4つのタイプのコンポーネントを任意の組み合わせで使用して、シェーダーのカスタムパラメータスペースを定義できます。

• ルート定数。
• 静的サンプラー
• ルート記述子。
• 記述子テーブル。

タスクは、対応するタイプのリソースとその更新の頻度に必要なバインディングの形式を選択することです。

リンクと有用な資料

• Microsoft DirectXブログ
• TwitterのDirectX 12
• Direct3D * 12-PCでのコンソールAPIの効率とパフォーマンス