タイル プールにマッピングされます

リソースがストリーミング リソースとして作成された場合、そのリソースを構成するタイルはタイル プール内の位置をポイントすることによって生成されます。 タイル プールは、メモリのプールです (背後にある 1 つ以上の割り当てによってサポートされていますが、アプリケーションには見えません)。 オペレーティング システムとディスプレイ ドライバーがメモリのこのプールを管理し、メモリ使用量はアプリケーションが簡単に理解することができます。 ストリーミング リソースは、タイル プール内の位置をポイントすることで 64KB の領域をマッピングします。 この設定の 1 つの副産物として、複数のリソースが同じタイルを共有して再利用することができ、必要な場合はリソース内の異なる位置で同じタイルを再利用することもできます。

タイル プール外のリソースがタイルを柔軟に利用できる代わりに、リソースは、タイル プール内のどのタイルがリソースに必要なタイルを表しているかというマッピングを定義し、維持する必要があります。 タイル マッピングは変更することができます。 さらに、リソース内のすべてのタイルを一度にマッピングする必要はありません。リソースのマッピングを NULL にすることができます。 NULL マッピングは、タイルを、タイルにアクセスするリソースの観点から利用不可と定義します。

タイル プールは複数作成することができ、一度に任意の数のストリーミング リソースを特定のタイル プールにマッピングできます。 タイル プールは、拡大したり縮小したりすることもできます。 詳しくは、「タイル プールのサイズ変更」をご覧ください。 ディスプレイ ドライバーとランタイムの実装を簡略化するために存在する 1 つの制約として、特定のストリーミング リソースが一度にマッピングできるタイル プールは最大で 1 つだけです (複数のタイル プールへの同時マッピングとは対照的です)。

ストリーミング リソース自体 (つまり、独立したタイル プール メモリ) に関連付けられるストレージの量は、任意の時点でプールに実際にマッピングされているタイルの数にほぼ比例しています。 ハードウェアでは、この事実はつまり、ページ テーブル ストレージのメモリ使用量は、マッピングされるタイルの量にほぼ対応することになります (たとえば、必要に応じて複数レベルのページ テーブル スキームを使用)。

タイル プールは、Direct3D アプリケーションが低レベルの実装の詳細を認識していなくても (またはポインター アドレスを直接処理しなくても) グラフィックス処理装置 (GPU) でページ テーブルを効果的にプログラミングできるようにする、完全なソフトウェア抽象と考えることができます。 タイル プールは、ハードウェアに追加レベルの間接参照を適用しません。 ページ ディレクトリのようなコンストラクトを使った単一レベルのページ テーブルの最適化は、タイル プールの概念とは無関係です。

最悪のケースでページ テーブル自体に必要となるストレージについて考えてみましょう (ただし、実際の実装で必要となるストレージは、マッピングされる量にほぼ比例します)。

各ページ テーブルのエントリが 64 ビットであるとします。

単一サーフェスにおける最悪のケースのページ テーブル サイズ ヒットの場合、Direct3D 11 のリソース制限を考慮して、ストリーミング リソースが 128 ビット/要素の形式で作成されると仮定できるため (たとえば、RGBA の浮動小数点など)、64KB のタイルに含まれるのは 4096 ピクセルのみです。 Texture2DArray でサポートされる最大サイズ 16384*16384*2048 (ただし、単一のミットマップのみ使用) に必要なストレージは、64 ビットのテーブル エントリを使って完全に書き込まれた場合 (ミップマップは含まない) は約 1 GB です。 ミップマップを追加すると、完全にマッピングされた (最悪のケース) ページ テーブル ストレージが約 3 分の 1 増加し、約 1.3 GB になります。

このケースでは、約 10.6 TB のアドレス可能メモリにアクセスできます。 ただし、アドレス可能メモリの量に制限が存在することがあり、その場合これらの量は 1 TB 前後の範囲に減少する可能性があります。

考慮できる別のケースは、32 ビット/要素の形式になっている 16384*16384 の単一の Texture2D ストリーミング リソースです (ミップマップを含む)。 完全に書き込まれたページ テーブルに必要な領域は、64 ビットのテーブル エントリで約 170 KB です。

最後に、BC 形式を使った例について考えます。たとえば、128 ビット/タイルが 4x4 ピクセル存在する BC7 であるとします。 これは、ピクセルあたり 1 バイトです。 ミップマップを含めて 16384*16384*2048 の Texture2DArray の場合、ページ テーブル内のこのメモリに完全に書き込むには約 85 MB 必要です。 1 つのストリーミング リソースが 550 ギガピクセル (この場合は 512 GB のメモリ) に対応できることを考えると、これは悪くありません。

実際には、これほどの量を一度にマッピングしたり参照したりできる量の物理メモリが存在することはないため、このようなほぼフル マッピングは定義されません。 しかし、タイル プールでは、アプリケーションがタイルの再利用を選択することがあり (シンプルな例としては、イメージ内の大きい黒色の領域に "黒" のカラー タイルを再利用)、事実上タイル プール (つまり、ページ テーブル マッピング) をメモリ圧縮のツールとして使っていることになります。

ページ テーブルの初期コンテンツは、すべてのエントリで NULL です。 さらに、アプリケーションはサーフェスのメモリ コンテンツに初期データを渡しません。最初はメモリのサポートがないためです。

このセクションの内容

トピック	説明
タイル プールの作成	アプリケーションは、Direct3D デバイスごとに 1 つ以上のタイル プールを作成できます。 各タイル プールの合計サイズは、Direct3D 11 のリソース サイズ制限 (GPU RAM の約 1/4) に制限されます。
タイル プールのサイズ変更	アプリケーションに、ストリーミング リソースのマッピング先のワーキング セットがさらに必要になった場合にタイル プールを拡大したり、必要な容量が少なくなった場合にタイル プールを縮小したりするためにタイル プールのサイズを変更します。
ハザード追跡対タイル プール リソース	非ストリーミング リソースの場合、Direct3D はレンダリング時に特定のハザード条件を防止できますが、ハザード追跡はストリーミング リソースのタイル レベルで行われるため、ストリーミング リソースのレンダリング時のハザード追跡にはかなりコストがかかる可能性があります。

 

関連トピック

ストリーミング リソースの作成