Direct3D 11 とのバインド モデルの違いDifferences in the Binding Model from Direct3D 11

DirectX12 でのバインドに関する主な設計上の決定事項の 1 つは、それを他の管理タスクから分離することです。One of the main design decisions behind DirectX12 binding is to separate it from other management tasks. これにより、特定の潜在的な危険を管理するいくつかの要件がアプリに課せられます。This places some requirements on the app to manage certain potential hazards.

D3D12 バインド モデルの主な利点は、アプリがテクスチャ バインドを頻繁に変更しても CPU のパフォーマンスに大きな影響が出ないことです。The main advantage of the D3D12 Binding Model is that it enables apps to change texture bindings frequently, without a huge CPU performance cost. ほかにも、シェーダーが大量のリソースにアクセスできる、バインドされるリソースの数をシェーダーが事前に把握する必要がない、統合リソース バインド モデルをハードウェアやアプリのコンテンツ フローに関係なく使用できるなどの利点があります。Other benefits are that shaders have access to a very large number of resources, shaders need not know in advance how many resources will be bound, and that a unified resource binding model can be used regardless of hardware or the apps content flow.

パフォーマンスを高めるために、このバインド モデルではアプリが GPU に使用を要求したバインドをシステムで追跡する必要がないほか、バインドとマルチスレッド コマンド リストが完全に統合されています。To improve performance, the binding model does not require the system to keep track of what bindings an app has requested the GPU to use, and there is a clean integration between binding and multi-threaded command lists.

次のセクションでは、D3D11 以降に行われたリソース バインド モデルへの変更について説明します。The following sections list some of the changes to the resource binding model since D3D11.

メモリ常駐管理をバインドから分離Memory Residency Management Separated From Binding

アプリケーションは、GPU が直接使用できるようにしておく ("常駐" 状態にする) 必要があるサーフェスを明示的に制御できます。Applications have explicit control over which surfaces they need to be available for the GPU to use directly (called being "resident"). その一方で、リソースにその他の状態を適用できます。たとえば、常駐しない状態にしたり、必要なメモリ フットプリントが最小限である一部のクラスのアプリケーションを OS が選択できるようにしたりすることが可能です。Conversely, they can apply other states on resources such as explicitly making them not resident, or letting the OS choose for certain classes of applications that require a minimal memory footprint. ここでの重要なポイントは、アプリケーションにおいて、常駐の対象を管理することと、シェーダーにリソースへのアクセスを許可することが完全に分離されている点です。The important point here is that the application's management of what is resident is completely decoupled from how it gives access to resources to shaders.

シェーダーにリソースへのアクセスを許可するメカニズムを常駐管理から分離すると、OS が常駐の対象を確認するためにローカル バインドの状態を絶えず検査する必要がなくなるため、レンダリングでのシステム/ハードウェアのコストが削減されます。The decoupling of residency management from the mechanism for giving shaders access to resources reduces the system/hardware cost for rendering since the OS doesn't have to constantly inspect the local binding state to know what to make resident. さらに、アクセスされる可能性のあるすべてのリソースが事前に常駐状態となっていれば、シェーダーは参照が必要なサーフェスを把握しておく必要がなくなります。Furthermore, shaders no longer have to know which exact surfaces they may need to reference, as long as the entire set of possibly accessible resources has been made resident ahead of time.

オブジェクトの有効期間管理をバインドから分離Object Lifetime Management Separated From Binding

以前の API とは異なり、パイプラインへのリソースのバインドを追跡する処理がシステムで行われなくなりました。Unlike previous APIs, the system no longer tracks bindings of resources to the pipeline. 以前は、アプリケーションが解放したリソースを、それが未処理の GPU 作業でまだ参照されている場合にシステムが保持しておくことができました。This used to enable the system to keep alive resources that the application has released because they are still referenced by outstanding GPU work.

現在は、テクスチャなどのリソースを解放する前に、GPU がその参照を完了したことをアプリケーションで確認する必要があります。Before freeing any resource, such as a texture, applications now must make sure the GPU has completed referencing it. つまり、アプリケーションがリソースを安全に解放するには、リソースを参照するコマンド リストの実行を GPU が完了している必要があります。This means before an application can safely free a resource the GPU must have completed execution of the command list referencing the resource.

ドライバー リソースの状態追跡をバインドから分離Driver Resource State Tracking Separated From Binding

追加のドライバー作業や GPU 作業を必要とするリソース遷移が発生したことを確認するためにリソース バインドを検査する処理が、システムで行われなくなりました。The system no longer inspects resource bindings to understand when resource transitions have occurred which require additional driver or GPU work. 多くの GPU とドライバーに共通する例として、サーフェスの用途がレンダー ターゲット ビュー (RTV) からシェーダー リソース ビュー (SRV) に遷移したことを把握する必要があります。A common example for many GPUs and drivers is having to know when a surface transitions from being used as a Render Target View (RTV) to Shader Resource View (SRV). システムが監視していたリソース遷移の発生を、アプリケーションが専用の API を使用して確認しなければならなくなりました。Applications themselves must now identify when any resource transitions that the system might care about are happening via dedicated APIs.

CPU GPU のマップされたメモリの同期をバインドから分離CPU GPU Mapped Memory Synchronization Separated From Binding

CPU アクセス用にマップされてまだマップ解除されていないリソースに依存している場合に、レンダリングの遅延が必要かどうかを確認するためのリソース バインドの検査が、システムで行われなくなりました。The system no longer inspects resource bindings to understand if rendering needs to be delayed because it depends on a resource that has been mapped for CPU access but has not been unmapped yet. 現在は、アプリケーションが CPU と GPU のメモリ アクセスを同期する必要があります。Applications now have the responsibility to synchronize CPU and GPU memory accesses. これを支援するために、作業が完了するまでアプリケーションが CPU スレッドのスリープを要求するためのメカニズムが提供されています。To help with this, the system provides mechanisms for the application to request the sleeping of a CPU thread until work completes. ポーリングを行うこともできますが、効率は低下します。Polling could also be done, but can be less efficient.

リソース バインディングResource Binding