次の方法で共有

バインディング モデルにおける Direct3D 11 との違い

  • [アーティクル]

DirectX12 でのバインドに関する主な設計上の決定事項の 1 つは、それを他の管理タスクから分離することです。 これにより、特定の潜在的な危険を管理するいくつかの要件がアプリに課せられます。

D3D12 バインド モデルの主な利点は、アプリがテクスチャ バインドを頻繁に変更しても CPU のパフォーマンスに大きな影響が出ないことです。 ほかにも、シェーダーが大量のリソースにアクセスできる、バインドされるリソースの数をシェーダーが事前に把握する必要がない、統合リソース バインド モデルをハードウェアやアプリのコンテンツ フローに関係なく使用できるなどの利点があります。

パフォーマンスを高めるために、このバインド モデルではアプリが GPU に使用を要求したバインドをシステムで追跡する必要がないほか、バインドとマルチスレッド コマンド リストが完全に統合されています。

次のセクションでは、D3D11 以降に行われたリソース バインド モデルへの変更について説明します。

メモリ常駐管理をバインドから分離

アプリケーションは、GPU が直接使用できるようにしておく ("常駐" 状態にする) 必要があるサーフェスを明示的に制御できます。 その一方で、リソースにその他の状態を適用できます。たとえば、常駐しない状態にしたり、必要なメモリ フットプリントが最小限である一部のクラスのアプリケーションを OS が選択できるようにしたりすることが可能です。 ここでの重要なポイントは、アプリケーションにおいて、常駐の対象を管理することと、シェーダーにリソースへのアクセスを許可することが完全に分離されている点です。

シェーダーにリソースへのアクセスを許可するメカニズムを常駐管理から分離すると、OS が常駐の対象を確認するためにローカル バインドの状態を絶えず検査する必要がなくなるため、レンダリングでのシステム/ハードウェアのコストが削減されます。 さらに、アクセスされる可能性のあるすべてのリソースが事前に常駐状態となっていれば、シェーダーは参照が必要なサーフェスを把握しておく必要がなくなります。

オブジェクトの有効期間管理をバインドから分離

以前の API とは異なり、パイプラインへのリソースのバインドを追跡する処理がシステムで行われなくなりました。 以前は、アプリケーションが解放したリソースを、それが未処理の GPU 作業でまだ参照されている場合にシステムが保持しておくことができました。

現在は、テクスチャなどのリソースを解放する前に、GPU がその参照を完了したことをアプリケーションで確認する必要があります。 つまり、アプリケーションがリソースを安全に解放するには、リソースを参照するコマンド リストの実行を GPU が完了している必要があります。

ドライバー リソースの状態追跡をバインドから分離

追加のドライバー作業や GPU 作業を必要とするリソース遷移が発生したことを確認するためにリソース バインドを検査する処理が、システムで行われなくなりました。 多くの GPU とドライバーに共通する例として、サーフェスの用途がレンダー ターゲット ビュー (RTV) からシェーダー リソース ビュー (SRV) に遷移したことを把握する必要があります。 システムが監視していたリソース遷移の発生を、アプリケーションが専用の API を使用して確認しなければならなくなりました。

CPU GPU のマップされたメモリの同期をバインドから分離

CPU アクセス用にマップされてまだマップ解除されていないリソースに依存している場合に、レンダリングの遅延が必要かどうかを確認するためのリソース バインドの検査が、システムで行われなくなりました。 現在は、アプリケーションが CPU と GPU のメモリ アクセスを同期する必要があります。 これを支援するために、作業が完了するまでアプリケーションが CPU スレッドのスリープを要求するためのメカニズムが提供されています。 ポーリングを行うこともできますが、効率は低下します。

リソース バインディング