重複するマッピングを含むタイルのアクセス制限

このセクションでは、重複するマッピングに関するタイル アクセスの制限事項について説明します。

コピー元とコピー先が重複するタイル リソースのコピー

コピー* 操作のコピー元とコピー先の領域のタイルに、両方のリソースがタイル化されていない場合でも重複するマッピングがコピー領域に存在し、Copy* 操作で重複するコピーがサポートされている場合、コピー* 操作は正常に動作します (コピー先に移動する前にソースが一時的な場所にコピーされる場合と同様)。 しかし、重なりが明白でない場合 (コピー元とコピー先のリソースは異なるが、それらがマッピング共有しているか、特定のサーフェイス上でマッピングが重複している場合など)、共有されるタイルでのコピー操作の結果は定義されていません。

コピー先領域のタイルが重複しているタイル リソースへのコピー

コピー先の領域でタイルが重複するタイルを含むタイル リソースにコピーすると、データ自体が同一でない限り、これらのタイルで未定義の結果が生成されます。タイルが異なると、タイルが異なる順序で書き込まれる場合があります。

重複するタイル マッピングへの UAV アクセス

タイル リソースの順序なしアクセス ビュー (UAV) が、その領域またはパイプラインにバインドされている他のリソースとのタイル マッピングが重複しているとします。 一般に UAV へのメモリ アクセスの順序が指定されていないように、異なるスレッドによって実行された場合、これらの重複するタイルへのアクセスの順序指定は定義されていません。

タイル マッピングの変更後、または外部マッピングからのコンテンツ更新後のレンダリング

タイル リソースのタイル マッピングが変更された場合、またはマップされたタイル プール タイル内のコンテンツが別のタイル リソースのマッピングを介して変更され、タイル リソースがレンダー ターゲット ビューまたは深度ステンシル ビューを介してレンダリングされる場合は、アプリケーションで Clear (固定関数 Clear API を使用) するか、Copy*/Update* API を使用して完全にコピーする必要があります。また、レンダリングされる領域内で変更されたタイル (マップされているかどうかは問いません) を使用して完全にコピーする必要があります。 このような場合にアプリケーションをクリアまたはコピーしないと、特定のレンダー ターゲット ビューまたは深度ステンシル ビューのハードウェア最適化構造が古くなり、ハードウェアによってはガベージ レンダリングの結果が発生し、異なるハードウェア間で不整合が発生します。 ハードウェアで使われるこれらの非表示の最適化データ構造は、個々のマッピングにローカルで、同じメモリへの他のマッピングには表示されないことがあります。

ID3D11DeviceContext1::ClearView 操作では、四角形を使用したレンダー ターゲット ビューのクリアがサポートされています。 タイル化されたリソースをサポートするハードウェアの場合、 ClearView では、深度のみのサーフェス (ステンシルなし) に対して、四角形を使用した深度ステンシル ビューのクリアもサポートする必要があります。 この操作により、アプリケーションはサーフェスの必要領域だけをクリアできます。

マッピングが変更されたタイル リソース内の領域の既存のメモリコンテンツをアプリケーションで保持する必要がある場合、そのアプリケーションは明確な要件を回避する必要があります。 この回避策を実現するには、まずタイル マッピングが変更されたコンテンツを保存し (たとえば 、ID3D11DeviceContext2::CopyTiles を使用して一時的なサーフェスにコピーして)、必要な clear コマンドを発行してから、内容をコピーし直します。 これで、段階的なレンダリング用にサーフェスの内容を維持するタスクは達成されますが、欠点は、レンダリングの最適化が失われる可能性があるため、そのサーフェス上での後続のレンダリングのパフォーマンスが低下する可能性があることです。

タイルが複数のタイルリソースに同時にマップされ、タイルコンテンツがタイルリソースの1つを介して何らかの方法(レンダリング、コピーなど)によって操作される場合、同じタイルが他のタイルリソースを介してレンダリングされる場合は、前に説明したように最初にタイルをクリアする必要があります。

レンダー領域の外部で共有されるタイルへのレンダリング

タイル リソース内の領域が にレンダリングされ、レンダリング領域によって参照されるタイル プール タイルも、(他のタイルリソースを介して同時に、またはそうでない場合を含む) レンダリング領域の外部からにマップされているとします。 これらのタイルにレンダリングされるデータは、他のマッピングを通じて表示されると、基になるメモリ レイアウトに互換性がある場合でも正しく表示される保証はありません。 これは、ハードウェアで使われるこれらの非表示の最適化データ構造は、レンダリング可能なサーフェスの個々のマッピングにローカルなことがあり、同じメモリ位置への他のマッピングには表示されないことがあるためです。 レンダリングされたマッピングから、アクセス可能な同じメモリへの他のすべてのマッピングにコピーして (または、そのメモリをクリアするか、不要な古い内容の場合は他のデータをコピーして)、この制限を回避することができます。 この回避策は冗長に思えますが、同じメモリへの他のすべてのマッピングがその内容にアクセスする方法を正しく理解でき、少なくとも 1 つの物理メモリだけにバックアップすることによるメモリの節約はそのまま残ります。 また、マッピングを共有する別のタイル リソースの使用を切り替える場合 (読み取りのみを除く)、スイッチ間で ID3D11DeviceContext2::TiledResourceBarrier API を呼び出す必要があります。

レンダー領域の内部で共有されるタイルへのレンダリング

タイル リソース内の領域が、レンダリング領域内とレンダリング領域内でレンダリングされている場合、複数のタイルが同じタイル プールの場所にマップされ、それらのタイルでレンダリング結果が未定義になります。

タイルを共有するタイル リソース間のデータの互換性

複数のタイル リソースが同じタイル プールの場所にマッピングされていて、各リソースを使用して同じデータにアクセスするとします。 このシナリオは、ハードウェア最適化構造に関する問題の回避に関する他の規則が回避され、 ID3D11DeviceContext2::TiledResourceBarrier への 適切な呼び出しが行われ、タイル化されたリソースが相互に互換性がある場合にのみ有効です。 後者は、タイルを共有するタイルリソースが互換性を持たれないという意味の観点から、ここで説明します。 重複するタイル マッピング全体で同じデータにアクセスすることに互換性がない条件は、異なるサーフェスのサイズや形式を使用していること、またはリソースに関するレンダー ターゲットまたは深度ステンシル バインド フラグの存在に違いがあることです。 1 種類のマッピングでメモリに書き込み、互換性のないリソースからのマッピングを使って続けて読み込んだりレンダリングしたりすると、定義されていない結果になります。 マッピングを共有する他のリソースが最初に新しい値で初期化された場合は (さまざまな目的でメモリをリサイクル)、データが互換性のない解釈で乱されないため、それに続く読み取りまたはレンダリング操作では問題が発生しません。 ただし、このような互換性のないマッピングへのアクセスを切り替える場合は、 TiledResourceBarrier API を呼び出す必要があります。

レンダー ターゲットまたは深度ステンシル バインド フラグが、互いにマッピングを共有するリソースのいずれにも設定されていない場合、制限ははるかに少なくなります。 形式とサーフェスの種類 (Texture2D など) が同じであれば、タイルを共有することができます。 異なる形式に互換性があるのは、BC6H と R32G32B32A32 のように、BC* サーフェスと同等サイズのコンポーネントあたり非圧縮 32 ビットまたは 16 ビットの形式などの場合です。 要素形式ごとに 32 ビットの多くは、R32_* と共にエイリアス化できます (R10G10B10A2_*、R8G8B8A8_*、B8G8R8A8_*、B8G8R8X8_*、R16G16_*)。この操作は、タイル化されていないリソースに対して常に許可されています。

形式に互換性があり、タイルが単色で塗りつぶされている場合は、パックされたタイルとパックされていないタイルの間で共有することができます。

最後に、レンダー ターゲットまたは深度ステンシル バインド フラグがあるリソースがないこと以外、タイル マッピングを共有するリソースに関して何も共通していない場合、0 で満たされたメモリのみが安全に共有できます。マッピングは、特定のリソース形式の定義に関して 0 のデコード結果として表示されます (通常は 0 だけ)。

関連トピック

タイル化されたリソースへのパイプライン アクセス