ストリーミング リソースのニーズThe need for streaming resources

ストリーミング リソースは、アクセスされないサーフェスの領域を保存して GPU メモリを無駄にしないために、また、隣接するタイルをまたいでフィルター処理する方法をハードウェアに伝えるために必要です。Streaming resources are needed so GPU memory isn't wasted storing regions of surfaces that won't be accessed, and to tell the hardware how to filter across adjacent tiles.

ストリーミング リソースまたはスパース テクスチャStreaming resources or sparse textures

ストリーミング リソース (Direct3D 11 ではタイル リソースと呼ばれます) は、少量の物理メモリを使用する大規模な論理リソースです。Streaming resources (called tiled resources in Direct3D 11), are large logical resources that use small amounts of physical memory.

ストリーミング リソースの別の名前がスパース テクスチャです。Another name for streaming resources is sparse textures. "スパース" には、リソースがタイルに分割されることと、それらすべてが一度にマップされないと予測されること (タイルに分割される主な理由) の両方の意味が含まれます。"Sparse" conveys both the tiled nature of the resources as well as perhaps the primary reason for tiling them - that not all of them are expected to be mapped at once. 実際、アプリケーションは、意図的にリソースのすべての領域およびミップス用にデータが作成されないストリーミング リソースを作成することもできます。In fact, an application could conceivably author a streaming resource in which no data is authored for all regions+mips of the resource, intentionally. そのため、コンテンツ自体がスパースである可能性があり、特定時点でのグラフィックス処理装置 (GPU) のメモリ内のコンテンツのマッピングはそれのサブセットになります (さらにスパースになります)。So, the content itself could be sparse, and the mapping of the content in graphics processing unit (GPU) memory at a given time would be a subset of that (even more sparse).

タイル表示を行わない場合、メモリ割り当てはサブリソースの詳細レベルで管理されるWithout tiling, memory allocations are managed at subresource granularity

ストリーミング リソースのサポートがないグラフィックス システム (オペレーティング システム、ディスプレイ ドライバー、およびグラフィックス ハードウェア) では、グラフィックス システムは、すべての Direct3D のメモリ割り当てをサブリソースの詳細レベルで管理します。In a graphics system (that is, the operating system, display driver, and graphics hardware) without streaming resource support, the graphics system manages all Direct3D memory allocations at subresource granularity.

バッファーの場合、バッファー全体がサブリソースです。For a buffer, the entire buffer is the subresource.

テクスチャ (Texture2D など) の場合、各ミップ レベルがサブリソースです。テクスチャ配列 (Texture2DArray など) の場合、特定の配列スライスの各ミップ レベルがサブリソースです。For a Texture, (for example, Texture2D), each mip level is a subresource; for a texture array, (for example, Texture2DArray) each mip level at a given array slice is a subresource. グラフィックス システムは、このサブリソースの詳細レベルで割り当てのマッピングを管理できることだけを公開します。The graphics system only exposes the ability to manage the mapping of allocations at this subresource granularity. ストリーミング リソースのコンテキストでは、"マッピング" はデータを GPU に見えるようにすることを指します。In the context of streaming resources, "mapping" refers to making data visible to the GPU.

タイルを使用しない場合、mipmap チェーンのごく一部にしかアクセスできませんWithout tiling, can't access only a small portion of mipmap chain

特定のレンダリング操作で、画像のミップマップ チェーンの一部 (特定のミップマップの全領域でもない) にのみアクセスする必要があることがアプリケーションにわかっているとします。Suppose an application knows that a particular rendering operation only needs to access a small portion of an image mipmap chain (perhaps not even the full area of a given mipmap). 理想的には、アプリはこの必要性についてグラフィックス システムに通知できます。Ideally, the app could inform the graphics system about this need. そして、グラフィックス システムは、大量のメモリでページングせず、必要なメモリが GPU にマップされることだけを考えればよくなります。The graphics system would then only bother to ensure that the needed memory is mapped on the GPU without paging in too much memory.

実際には、ストリーミング リソースのサポートがないと、グラフィックス システムには、サブリソースの詳細レベルで GPU にマップする必要があるメモリに関してのみ通知されます (たとえば、アクセスできる全体のミップマップ レベルの範囲)。In reality, without streaming resource support, the graphics system can only be informed about the memory that needs to be mapped on the GPU at subresource granularity (for example, a range of full mipmap levels that could be accessed). グラフィックス システムにはデマンド フォールトがないため、潜在的にはメモリのいずれかの部分を参照するレンダリング コマンドが実行される前に、サブリソースの完全なマッピングを行うために余分な GPU メモリを大量に使用することが必要になる可能性があります。There is no demand faulting in the graphics system either, so potentially a lot of excess GPU memory must be used to make full subresources mapped before a rendering command that references any part of the memory is executed. これは、ストリーミング リソースのサポートがないときに、Direct3D で大量のメモリの割り当てを使用することを難しくする問題の 1 つにすぎません。This is just one issue that makes the use of large memory allocations difficult in Direct3D without streaming resource support.

サーフェスを小さいタイルに分割するソフトウェア ページングSoftware paging to break the surface into smaller tiles

ソフトウェア ページングを使用して、サーフェスをハードウェアが処理できる小さいタイルに分割することができます。Software paging can be used to break the surface into tiles that are small enough for the hardware to handle.

Direct3D は、特定の辺で最大 16384 ピクセルある Texture2D サーフェスをサポートします。Direct3D supports Texture2D surfaces with up to 16384 pixels on a given side. 幅 16384 × 高さ 16384、1 ピクセルあたり 4 バイトの画像は、1 GB のビデオ メモリを消費します (ミップマップを追加すると、その量の倍になります)。An image that is 16384 wide by 16384 tall and 4 bytes per pixel would consume 1GB of video memory (and adding mipmaps would double that amount). 実際には、1 つのレンダリング操作で 1 GB 全体の参照が必要になることはほとんどありません。In practice, all 1GB would rarely need to be referenced in a single rendering operation.

一部のゲーム開発者は、地形のサーフェスを 128 K × 128 K の大きさでモデル化します。Some game developers model terrain surfaces as large as 128K by 128K. 彼らがこれを既存の GPU で動作させる方法は、サーフェスをハードウェアが処理できる小さいタイルに分割することです。The way they get this to work on existing GPUs is to break the surface into tiles that are small enough for hardware to handle. アプリケーションは、どのタイルが必要になるかを調べて、それらを GPU でテクスチャのキャッシュに読み込む必要があります。これがソフトウェア ページング システムです。The application must figure out which tiles might be needed and load them into a cache of textures on the GPU - a software paging system.

その方法の大きな欠点は、ハードウェアが進行中のページングについて何もわからないことから生じます。画面に表示する必要がある画像の一部がタイルをまたいでいるとき、ハードウェアにはタイルをまたいで効率的にフィルター処理する固定関数を実行する方法がわかりません。A significant downside to that approach comes from the hardware not knowing anything about the paging that is going on: When a part of an image needs to be shown on screen that straddles tiles, the hardware does not know how to perform fixed function (that is, efficient) filtering across tiles. つまり、ソフトウェアのタイル処理を管理しているアプリケーションが、シェーダー コードでテクスチャのフィルター処理を手動で行うか (これは、高品質の異方性フィルターが必要な場合に非常に高価になります)、固定関数によるハードウェア フィルター処理が補助し続けられるように、メモリを浪費して隣接するタイルのデータを格納するガターをタイルの周囲に作成する必要があります。This means the application managing its own software tiling must resort to manual texture filtering in shader code (which becomes very expensive if a good quality anisotropic filter is desired) and/or waste memory authoring gutters around tiles that contain data from neighboring tiles so that fixed function hardware filtering can continue to provide some assistance.

サーフェスの割り当てのタイル表現を最上位の機能にするMaking tiled representation of surface allocations a first-class feature

サーフェスの割り当てのタイル表現がグラフィックス システムで最上位の機能であれば、アプリケーションはどのタイルを利用できるようにするかをハードウェアに伝えることができます。If a tiled representation of surface allocations is a first-class feature in the graphics system, the application could tell the hardware which tiles to make available. この方法で、アクセスされないことがアプリケーションにわかっているサーフェイスの領域を保存するために浪費する GPU メモリが少なくなり、ハードウェアは隣接するタイルにわたってフィルター処理する方法を理解でき、ソフトウェアのタイル処理を実行している開発者が経験する問題点の一部が軽減されます。In this way, less GPU memory is wasted storing regions of surfaces that the application knows will not be accessed, and the hardware can understand how to filter across adjacent tiles, alleviating some of the pain experienced by developers who perform software tiling on their own.

しかし、完全なソリューションを提供するには、サーフェス内のタイル処理がサポートされるかどうかに関係なく、サーフェスの現在の最大サイズは既にアプリケーションが必要としている 128 K 以上にはほど遠い 16384 であることに対応するために何かをする必要があります。But to provide a complete solution, something must be done to deal with the fact that, independent of whether tiling within a surface is supported, the maximum surface dimension is currently 16384 - nowhere near the 128K+ that applications already want. ハードウェアにより大きいテクスチャ サイズをサポートするように求めることも 1 つの方法ですが、その方向に進むことには大きなコスト増やトレードオフがあります。Just requiring the hardware to support larger texture sizes is one approach, however there are significant costs and/or tradeoffs to going this route.

Direct3D のテクスチャ フィルター パスとレンダリング パスは、16 K テクスチャのサポートでの精度に関しては、レンダリング中にサーフェスから離れるビューポートの範囲のサポートや、フィルター処理中のサーフェスのエッジからのテクスチャの折り返しのサポートなど他の要求で既に飽和状態です。Direct3D's texture filter path and rendering path are already saturated in terms of precision in supporting 16K textures with the other requirements, such as supporting viewport extents falling off the surface during rendering, or supporting texture wrapping off the surface edge during filtering. 可能な方法は、テクスチャ サイズが 16K を超えて増えるにつれて、機能/精度をある程度落とすようにトレードオフを定義することです。A possibility is to define a tradeoff such that as the texture size increases beyond 16K, functionality/precision is given up in some manner. ただし、ここで譲歩しても、より大きいテクスチャ サイズに移行できるようにハードウェア システム全体にわたる能力を増強するためには、追加のハードウェア コストが必要になることがあります。Even with this concession however, additional hardware costs might be required in terms of addressing capability throughout the hardware system to go to larger texture sizes.

大きなテクスチャでの問題: サーフェイス上の場所の有効桁数Issue with large textures: precision for locations on surface

テクスチャが非常に大きくなるにつれて出てくる問題の 1 つは、単精度浮動小数点のテクスチャ座標 (およびラスター化をサポートするための関連する補間操作) では、サーフェス上の位置を正確に指定する精度が足りなくなることです。One issue that comes into play as textures get very large is that single precision floating point texture coordinates (and the associated interpolators to support rasterization) run out of precision to specify locations on the surface accurately. テクスチャのフィルター処理が不安定になります。Jittery texture filtering would ensue. 高価なオプションの 1 つは倍精度の補間操作のサポートを求めることですが、妥当な代替案としては過剰になる可能性があります。One expensive option would be to require double precision interpolator support, though that could be overkill given a reasonable alternative.

さまざまなサイズの複数のリソースがメモリを共有できるようにするEnabling multiple resources of different dimensions to share memory

ストリーミング リソースによって処理できるもう 1 つのシナリオは、さまざまなサイズ/形式の複数のリソースが同じメモリを共有できるようにすることです。Another scenario that could be served by streaming resources is enabling multiple resources of different dimensions/formats to share the same memory. アプリケーションで、同時に使用しないことがわかっている排他的なリソースのセットや、非常に短時間だけ使用するために作成されて破棄されるリソース (その後に他のリソースが作成される) を処理することがあります。Sometimes applications have exclusive sets of resources that are known not to be used at the same time, or resources that are created only for very brief use and then destroyed, followed by creation of other resources. "ストリーミング リソース" から離れることが可能な一般論として、ユーザーが同じ (重なり合う) メモリにある複数の異なるリソースを指すことを許可することができます。A form of generality that can fall out of "streaming resources" is that it is possible to allow the user to point multiple different resources at the same (overlapping) memory. つまり、"リソース" の作成と破棄 (サイズ/形式を定義するなど) は、アプリケーションの視点からリソースの基になるメモリの管理から切り離すことができます。In other words, the creation and destruction of "resources" (which define a dimension/format and so on) can be decoupled from the management of the memory underlying the resources from the application's point of view.

関連トピックRelated topics

ストリーミング リソースStreaming resources