重複するマッピングを使用したタイル アクセスの制限
このセクションでは、重複するマッピングに関するタイル アクセスの制限について説明します。
コピー元とコピー先が重複するタイル リソースのコピー
コピー* 操作のコピー元とコピー先の領域のタイルで、両方のリソースがタイル化されたリソースではなく、コピー* 操作で重複するコピーがサポートされている場合でも、コピー領域に重複するマッピングがある場合、コピー* 操作は正常に動作します (コピー元がコピー先に移動する前に一時的な場所にコピーされた場合と同様)。 ただし、重複が明確でない場合 (ソースリソースと宛先リソースが異なるが、共有マッピングやマッピングが特定のサーフェス上で重複している場合)、共有されているタイルに対するコピー操作の結果は未定義になります。
コピー先領域にタイルが重複しているタイル リソースへのコピー
コピー先の領域にタイルが重複しているタイル リソースにコピーすると、データ自体が同一でない限り、これらのタイルに未定義の結果が生成されます。異なるタイルが異なる順序でタイルを書き込む場合があります。
重複するタイル マッピングへの UAV アクセス
タイルリソース上の順序なしアクセス ビュー (UAV) に、その領域内またはパイプラインにバインドされた他のリソースとのタイル マッピングが重複しているとします。 一般的に UAV へのメモリ アクセスの順序が順序付けられていないのと同様に、異なるスレッドによって実行される場合、これらの重複タイルへのアクセスの順序は未定義です。
タイル マッピングの変更または外部マッピングからのコンテンツの更新後のレンダリング
タイル リソースのタイル マッピングが変更された場合、またはマップされたタイル プール タイル内のコンテンツが別のタイル リソースのマッピングを介して変更され、タイル化されたリソースがレンダー ターゲット ビューまたは深度ステンシル ビューを介してレンダリングされる場合、アプリケーションは (固定関数 Clear API を使用して) クリアするか、Copy*/Update* API を使用して完全にコピーする必要があります。または、レンダリング対象の領域内で変更されたタイル (マップされているかどうか) を使用して完全にコピーする必要があります。 このような場合にアプリケーションがクリアまたはコピーできないと、特定のレンダー ターゲット ビューまたは深度ステンシル ビューのハードウェア最適化構造が古くなり、一部のハードウェアでガベージ レンダリングの結果が生成され、異なるハードウェア間で不整合が発生します。 ハードウェアによって使用されるこれらの非表示の最適化データ構造は、個々のマッピングに対してローカルであり、同じメモリへの他のマッピングには表示されない可能性があります。
ID3D11DeviceContext1::ClearView 操作では、四角形でレンダー ターゲット ビューをクリアできます。 タイル 化されたリソースをサポートするハードウェアの場合、ClearView では、深度のみのサーフェス (ステンシルなし) に対して、四角形を使用した深度ステンシル ビューのクリアもサポートする必要があります。 この操作により、アプリケーションはサーフェスの必要な領域のみをクリアできます。
マッピングが変更されたタイル リソース内の領域の既存のメモリコンテンツをアプリケーションで保持する必要がある場合、そのアプリケーションは明確な要件を回避する必要があります。 この回避策を実現するには、最初にタイル マッピングが変更されたコンテンツを保存し (たとえば、ID3D11DeviceContext2::CopyTilesを使用して一時的なサーフェスにコピーして)、必要なクリア コマンドを発行してから、内容をコピーします。 これにより、増分レンダリングのためにサーフェスコンテンツを保持するタスクが実行されますが、欠点は、レンダリングの最適化が失われる可能性があるため、サーフェス上の後続のレンダリングパフォーマンスが低下する可能性があるということです。
タイルが複数のタイルリソースに同時にマップされ、タイルコンテンツがタイル化されたリソースの1つを介して何らかの方法 (レンダリング、コピーなど) によって操作される場合、同じタイルが他のタイルリソースを介してレンダリングされる場合は、前に説明したようにタイルを最初にクリアする必要があります。
レンダリング領域の外部で共有されているタイルへのレンダリング
タイル 化されたリソース内の領域がレンダリングされ、レンダリング領域によって参照されるタイル プール タイルもレンダリング領域の外側からマップされるとします (他のタイル化されたリソースを介して同時にマップされるかどうかも含まれます)。 これらのタイルにレンダリングされるデータは、基になるメモリ レイアウトに互換性がある場合でも、他のマッピングで表示された場合に正しく表示されるとは限りません。 これは、最適化データ構造の一部のハードウェア使用が、レンダリング可能なサーフェスの個々のマッピングに対してローカルであり、同じメモリ位置への他のマッピングには表示されない可能性があるためです。 この制限を回避するには、レンダリングされたマッピングから他のすべてのマッピングにアクセス可能な同じメモリにコピーします (または、そのメモリをクリアするか、古い内容が不要になった場合は他のデータをコピーします)。 この回避策は冗長に見えますが、同じメモリへの他のすべてのマッピングがその内容にアクセスする方法を正しく理解し、少なくとも 1 つの物理メモリ バッキングしか持たないというメモリ節約はそのまま残ります。 また、マッピングを共有する異なるタイル リソースの使用を切り替える場合 (読み取り専用の場合を除く)、スイッチ間で ID3D11DeviceContext2::TiledResourceBarrier API を呼び出す必要があります。
レンダリング領域内で共有されているタイルへのレンダリング
タイル化されたリソース内の領域がレンダリング領域内でレンダリングされている場合、複数のタイルが同じタイル プールの場所にマップされ、それらのタイルでレンダリング結果が未定義になります。
タイルを共有するタイル リソース間のデータ互換性
複数のタイル リソースに同じタイル プールの場所へのマッピングがあり、各リソースを使用して同じデータにアクセスするとします。 このシナリオは、ハードウェアの最適化構造に関する問題の回避に関する他の規則が回避され、ID3D11DeviceContext2::TiledResourceBarrier への適切な呼び出しが行われ、タイル化されたリソースが互いに互換性がある場合にのみ有効です。 後者は、タイルを共有するタイル リソースが互換性を持たなければ何を意味するかという点で、ここで説明します。 重複するタイル マッピング間で同じデータにアクセスする非互換性条件は、異なるサーフェス ディメンションまたは形式の使用、またはリソースにレンダー ターゲットまたは深度ステンシル バインド フラグが存在する違いです。 1 種類のマッピングを使用してメモリに書き込むと、互換性のないリソースからマッピングを介して読み取りまたはレンダリングを行うと、未定義の結果が生成されます。 他のリソース共有マッピングが最初に新しいデータで初期化される場合 (別の目的でメモリをリサイクルする)、互換性のない解釈の間でデータがブリードされないため、後続の読み取りまたはレンダリング操作は問題ありません。 ただし、このような互換性のないマッピングへのアクセスを切り替える場合は、TiledResourceBarrier API を呼び出す必要があります。
レンダー ターゲットまたは深度ステンシル バインド フラグが、互いにマッピングを共有するリソースに設定されていない場合は、制限がはるかに少なくなります。 形式とサーフェスの種類 (Texture2D など) が同じであれば、タイルを共有できます。 互換性のある形式が異なるのは、BC* サーフェスや、BC6H や R32G32B32A32 など、コンポーネント形式ごとに同等のサイズの圧縮されていない 32 ビットまたは 16 ビットです。 要素形式ごとに 32 ビットの多くは、R32_* (R10G10B10A2_*、R8G8B8A8_*、B8G8R8A8_*、B8G8R8X8_*、R16G16_*) でもエイリアス化できます。この操作は、タイル化されていないリソースに対して常に許可されています。
パックされたタイルとパックされていないタイルの間の共有は、形式に互換性があり、タイルが単色で塗りつぶされている場合に問題ありません。
最後に、レンダリング ターゲットまたは深度ステンシル バインド フラグがない点を除き、タイル マッピングを共有するリソースに共通するものがない場合は、0 で満たされたメモリのみを安全に共有できます。マッピングは、指定されたリソース形式 (通常は 0) の定義に対して 0 のデコードとして表示されます。
関連トピック