次の方法で共有

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

  • [アーティクル]

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

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

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

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

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

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

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

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

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

考慮すべきもう 1 つのケースは、ミップマップを含む 32 ビット/要素形式の 16384*16384 の単一の Texture2D タイル リソースです。 完全に書き込まれたページ テーブルに必要な領域は、64 ビットのテーブル エントリで約 170 KB です。

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

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

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

このセクションの内容

トピック 説明
タイル プールの作成
 タイル プールは、pDesc パラメーターが指すD3D11_BUFFER_DESC構造体の MiscFlags メンバーにD3D11_RESOURCE_MISC_TILE_POOL フラグを渡すことによって、ID3D11Device::CreateBuffer API を介して作成されます。
タイル プールのサイズ変更
 ID3D11DeviceContext2::ResizeTilePool API を使用して、タイル プールにタイル プールを拡張します。タイル リソースへのマッピングに対してアプリケーションにさらに作業セットが必要な場合は、または必要な領域が少ない場合は縮小します。
ハザード追跡対タイル プール リソース
 タイル化されていないリソースの場合、Direct3D はレンダリング中に特定の危険な状態を防ぐことができますが、タイル化されたリソースの危険度の追跡はタイル リソースのタイル レベルになるため、タイル化されたリソースのレンダリング中の危険状況の追跡にはコストがかかりすぎる可能性があります。

タイル化されたリソースの作成