重複するマッピングを含むタイルのアクセス制限Tile access limitations with duplicate mappings

コピー元とコピー先が重複しているストリーミング リソースをコピーする場合や、レンダー領域内で共有されるタイルにレンダリングする場合などでは、重複するマッピングを含むタイル アクセスに制限があります。There are limitations on tile access with duplicate mappings, such as when copying streaming resources with overlapping source and destination, or when rendering to tiles shared within the render area.

重複する元とコピー先とストリーミングのリソースのコピーCopying streaming resources with overlapping source and destination

場合のコピー元とコピー先の領域内のタイル*操作には、両方のリソースがリソースとコピーはストリーミングしない場合でも重複はコピー領域内のマッピングが重複して*操作は、重複をサポートしていますコピーをコピーします。* (ソースは、先に進む前に、一時的な場所にコピーされます) 場合、操作が問題なく動作します。If tiles in the source and destination area of a Copy* operation have duplicated mappings in the copy area that would have overlapped even if both resources were not streaming resources and the Copy* operation supports overlapping copies, the Copy* operation will behave fine (as if the source is copied to a temporary location before going to the destination). しかし、重なりが明白でない場合 (コピー元とコピー先のリソースは異なるが、それらがマッピング共有しているか、特定のサーフェイス上でマッピングが重複している場合など)、共有されるタイルでのコピー操作の結果は定義されていません。But if the overlap is not obvious (like the source and destination resources are different but share mappings or mappings are duplicated over a given surface), results of the copy operation on the tiles that are shared are undefined.

コピー先の領域で、重複したタイルをストリーミングのリソースへのコピーCopying to streaming resource with duplicated tiles in destination area

コピー先の領域に重複するタイルがあるストリーミング リソースにコピーすると、データ自体がまったく同じでない限り、それらのタイルでは未定義の結果になります。異なるタイルは異なる順序でタイルを書き込むことがあります。Copying to a streaming resource with duplicated tiles in the destination area produces undefined results in these tiles unless the data itself is identical; different tiles might write the tiles in different orders.

UAV で重複したタイルをマッピングにアクセスします。UAV accesses to duplicate tiles mappings

ストリーミング リソースの順序指定されていないアクセス ビュー (UAV) に、その領域内に重複するタイル マッピングがあるか、またはパイプラインにバインドされた他のリソースとの重複があるとします。Suppose an unordered access view (UAV) on a streaming resource has duplicate tile mappings in its area or with other resources bound to the pipeline. 一般に UAV へのメモリ アクセスの順序が指定されていないように、異なるスレッドによって実行された場合、これらの重複するタイルへのアクセスの順序指定は定義されていません。Ordering of accesses to these duplicated tiles is undefined if performed by different threads, just as any ordering of memory access to UAVs in general is unordered.

タイルのマッピングの変更または外部マッピングからのコンテンツの更新後の表示Rendering after tile mapping changes or content updates from outside mappings

ストリーミングのリソースのタイルのマッピングが変更されたか、別のストリーミング リソースのマッピング、およびストリーミングのリソースを使用してタイル化されたプールのマップ タイルのコンテンツが変更された場合を使用してレンダリングをレンダー ターゲット ビューまたは深度ステンシル ビュー、アプリケーションにする必要があります。オフ (fixed 関数クリア Api を使用) または完全コピーを使用してコピー*/update* Api、領域内で変更されたタイル表示されている (マップされるか)。If a streaming resource's tile mappings have changed or content in mapped tiled pool tiles have changed via another streaming resource's mappings, and the streaming resource is going to be rendered via render target view or depth stencil view, the application must Clear (using the fixed function Clear APIs) or fully copy over using Copy*/Update* APIs the tiles that have changed within the area being rendered (mapped or not).

これらの場合にアプリケーションがクリアまたはコピーに失敗すると、特定のレンダー ターゲット ビューまたは深度ステンシル ビューのハードウェア最適化構造が古くなり、さまざまなハードウェアにわたって一部のハードウェアと不整合に関するガベージ レンダリングの結果になります。Failure of an application to clear or copy in these cases results in hardware optimization structures for the given render target view or depth stencil view being stale, and will result in garbage rendering results on some hardware and inconsistency across different hardware. ハードウェアで使われるこれらの非表示の最適化データ構造は、個々のマッピングにローカルで、同じメモリへの他のマッピングには表示されないことがあります。These hidden optimization data structures used by hardware might be local to individual mappings and not visible to other mappings to the same memory.

リソース ビューをクリアするとき (リソース ビュー内のすべての要素を 1 つの値に設定)、レンダー ターゲット ビューを長方形でクリアできます。When you clear a resource view (setting all the elements in a resource view to one value), you can clear render target views with rectangles. ストリーミング リソースをサポートするハードウェアの場合、リソース ビューをクリアする際は、深度のみのサーフェス (ステンシルなし) のために四角形による深度ステンシル ビューのクリアもサポートする必要があります。For hardware that supports streaming resources, clearing a resource view must also support clearing of depth stencil views with rectangles, for depth only surfaces (without stencil). この操作により、アプリケーションはサーフェスの必要領域だけをクリアできます。This operation allows applications to clear only the necessary area of a surface.

アプリケーションは、マッピングが変更されているストリーミング リソース内の領域の既存のメモリ内容を維持する必要がある場合、クリアの要件を回避する必要があります。If an application needs to preserve existing memory contents of areas in a streaming resource where mappings have changed, that application must work around the clear requirement. アプリケーションは、まずタイル マッピングが変更された部分の内容を保存し (一時的なサーフェスにコピー)、必要なクリア コマンドを発行してから内容をコピーして戻すことで、この回避策を実現できます。The application can accomplish this work-around by first saving the contents where tile mappings have changed (by copying them to a temporary surface), issuing the required clear command, and then copying the contents back. これで、段階的なレンダリング用にサーフェスの内容を維持するタスクは達成されますが、欠点は、レンダリングの最適化が失われる可能性があるため、そのサーフェス上での後続のレンダリングのパフォーマンスが低下する可能性があることです。While this would accomplish the task of preserving surface contents for incremental rendering, the downside is that subsequent rendering performance on the surface might suffer because rendering optimizations might be lost.

タイルが同時に複数のストリーミング リソースにマップされ、タイルのコンテンツがストリーミング リソースの 1 つを経由して何らかの手段 (レンダー、コピー、およびその他) で操作される場合、その同じタイルが他のストリーミング リソースによってレンダリングされる場合は、まず前述のようにタイルをクリアする必要があります。If a tile is mapped into multiple streaming resources at the same time and tile contents are manipulated by any means (render, copy, and so on) via one of the streaming resources, if the same tile is to be rendered via any other streaming resource, the tile must be cleared first as previously described.

タイルの外で共有するレンダリング領域をレンダリングします。Rendering to tiles shared outside render area

ストリーミング リソース内の領域がレンダリングされていて、レンダー領域によって参照されるタイル プールのタイルもレンダー領域の外部からマップされているとします (他のストリーミング リソース経由などで同時または同時ではなく)。Suppose an area in a streaming resource is being rendered to and the tile pool tiles referenced by the render area are also mapped to from outside the render area (including via other streaming resources, at the same time or not). これらのタイルにレンダリングされるデータは、他のマッピングを通じて表示されると、基になるメモリ レイアウトに互換性がある場合でも正しく表示される保証はありません。Data rendered to these tiles isn't guaranteed to appear correctly when viewed through the other mappings, even though the underlying memory layout is compatible. これは、ハードウェアで使われるこれらの非表示の最適化データ構造は、レンダリング可能なサーフェスの個々のマッピングにローカルなことがあり、同じメモリ位置への他のマッピングには表示されないことがあるためです。This fact is due to optimization data structures some hardware use that can be local to individual mappings for renderable surfaces and not visible to other mappings to the same memory location.

レンダリングされたマッピングから、アクセス可能な同じメモリへの他のすべてのマッピングにコピーして (または、そのメモリをクリアするか、不要な古い内容の場合は他のデータをコピーして)、この制限を回避することができます。You can work around this restriction by copying from the rendered mapping to all the other mappings to the same memory that might be accessed (or clearing that memory or copying other data to it if the old contents are no longer needed). この回避策は冗長に思えますが、同じメモリへの他のすべてのマッピングがその内容にアクセスする方法を正しく理解でき、少なくとも 1 つの物理メモリだけにバックアップすることによるメモリの節約はそのまま残ります。While this work-around seems redundant, it makes all other mappings to the same memory correctly understand how to access its contents, and at least the memory savings of having only a single physical memory backing remains intact.

また、マッピングを共有するストリーミング リソースの使用を切り替えるとき (読み込みのみの場合を除く)、複数のタイル リソース間、および切り替えの間のデータ アクセスの順序の制約 (障壁) を指定する必要があります。Also, when you switch between using different streaming resources that share mappings (unless only reading), you must specify a data access ordering constraint (a barrier) between multiple tiled resources, in between the switches.

タイルのレンダリング領域内で共有の表示Rendering to tiles shared within render area

ストリーミング リソース内の領域がレンダリングされ、レンダー領域内で複数のタイルが同じタイル プールの場所にマップされている場合、それらのタイルでのレンダリングの結果は定義されていません。If an area in a streaming resource is being rendered to and within the render area multiple tiles are mapped to the same tile pool location, rendering results are undefined on those tiles.

ストリーミング タイルを共有するリソース間でデータの互換性Data compatibility across streaming resources sharing tiles

複数のストリーミング リソースに同じタイル プールの場所へのマッピングがあり、各リソースが同じデータにアクセスするために使用されるとします。Suppose multiple streaming resources have mappings to the same tile pool locations and each resource is used to access the same data. このシナリオが有効なのは、ハードウェア最適化構造の問題を回避することに関するその他の規則が避けられ、適切な障壁が指定され (複数のタイル リソース間のデータ アクセス順序の制約を指定)、ストリーミング リソースに互いに互換性がある場合だけです。This scenario is only valid if the other rules about avoiding problems with hardware optimization structures are avoided, appropriate barriers are specified (specifying a data access ordering constraint between multiple tiled resources), and the streaming resources are compatible with each other.

後者はここでは、タイルを共有するストリーミング リソースに互換性がないという意味に関して記述されています。The latter is described here in terms of what it means for streaming resources sharing tiles to be incompatible. 重複するタイル マッピング全体で同じデータにアクセスすることに互換性がない条件は、異なるサーフェスのサイズや形式を使用していること、またはリソースに関するレンダー ターゲットまたは深度ステンシル バインド フラグの存在に違いがあることです。The incompatibility conditions of accessing the same data across duplicate tile mappings are the use of different surface dimensions or format, or differences in the presence of render target or depth stencil bind flags on the resources. 1 種類のマッピングでメモリに書き込み、互換性のないリソースからのマッピングを使って続けて読み込んだりレンダリングしたりすると、定義されていない結果になります。Writing to the memory with one type of mapping produces undefined results if you subsequently read or render via a mapping from an incompatible resource.

マッピングを共有する他のリソースが最初に新しい値で初期化された場合は (さまざまな目的でメモリをリサイクル)、データが互換性のない解釈で乱されないため、それに続く読み取りまたはレンダリング操作では問題が発生しません。If the other resource sharing mappings are first initialized with new data (recycling the memory for a different purpose), the subsequent read or render operation is fine since data isn't bleeding across incompatible interpretations. しかし、上記のように互換性のないマッピングへのアクセスの間で切り替える際は、障壁を指定する必要があります (複数のタイル リソース間のデータ アクセス順序の制約を指定)。But, when you switch between accessing incompatible mappings like this, you must specify barriers (specifying a data access ordering constraint between multiple tiled resources).

レンダー ターゲットまたは深度ステンシル バインド フラグが、互いにマッピングを共有するリソースのいずれにも設定されていない場合、制限ははるかに少なくなります。If the render target or depth stencil bind flag isn't set on any of the resources sharing mappings with each other, there are far fewer restrictions. 形式とサーフェスの種類 (Texture2D など) が同じであれば、タイルを共有することができます。As long as the format and surface types (for example, Texture2D) are the same, tiles can be shared. 別の形式が互換性のあるものは、ビジネス継続性などの場合*サーフェスと圧縮されていない 32 ビットまたは BC6H R32G32B32A32 などのコンポーネントの形式ごとに 16 ビットのサイズします。Different formats being compatible are cases such as BC* surfaces and the equivalent sized uncompressed 32 bit or 16 bit per component format, like BC6H and R32G32B32A32. 1 つの要素の多くの 32 ビットの形式は R32 でエイリアスを指定できます_*も (R10G10B10A2_*、R8G8B8A8_*、B8G8R8A8_*、B8G8R8X8_ *、R16G16_*)。 この操作は、ストリーミング以外のリソースの常に許可されています。Many 32 bit per element formats can be aliased with R32_* as well (R10G10B10A2_*, R8G8B8A8_*, B8G8R8A8_*,B8G8R8X8_*,R16G16_*); this operation has always been allowed for non-streaming resources.

形式に互換性があり、タイルが単色で塗りつぶされている場合は、パックされたタイルとパックされていないタイルの間で共有することができます。Sharing between packed and non-packed tiles is fine if the formats are compatible and the tiles are filled with solid color.

最後に、レンダー ターゲットまたは深度ステンシル バインド フラグがあるリソースがないこと以外、タイル マッピングを共有するリソースに関して何も共通していない場合、0 で満たされたメモリのみが安全に共有できます。マッピングは、特定のリソース形式の定義に関して 0 のデコード結果として表示されます (通常は 0 だけ)。Finally, if nothing is common about the resources sharing tile mappings except that none have render target or depth stencil bind flags, only memory filled with 0 can be shared safely; the mapping will appear as whatever 0 decodes to for the definition of the given resource format (typically just 0).

関連トピックRelated topics

リソースのストリーミング パイプラインへのアクセスPipeline access to streaming resources