メモリ管理戦略
Direct3D 12 のメモリ マネージャーは、UMA またはディスクリート (非 UMA) アダプターの場合、および GPU アダプター間のアーキテクチャの大きな違いにより、さまざまなレベルのサポートを使用して、非常に複雑になる可能性があります。
このセクションで説明する Direct3D 12 メモリ管理の推奨戦略は、"分類、予算、ストリーム" です。
リソースの種類
"コミットされたリソース" の基本的な概念 (マネージド物理メモリで初期化された仮想アドレス空間と物理アドレス空間の両方を作成する) は Direct3D 9 以降で行われていますが、Direct3D 12 では仮想アドレス指定 (VA) と物理アドレス指定を区別して、アプリで物理メモリを慎重に管理できます。
コミットされたリソースに加えて、Direct3D 12 のヒープ コンストラクトにより、"配置" と "予約済み" の 2 種類のリソースが有効になります。 Direct3D 11 では、"予約済み" リソースは "タイル リソース" と呼ばれていました。
予約済みリソースは、予約済みリソースに固有の GPU 仮想アドレス空間がある点で、配置されたリソースとは異なります。 これにより、VA 領域を前もって大量に割り当て、後で VA ページをヒープの特定のセクションにマッピングでき、アプリケーションはその場で配置を再構成します。 VA 空間は連続しており、疎にマップできます。
UpdateTileMappings などの API 呼び出しを使用してヒープ内の領域を参照するために予約済みリソースを作成できます。また、ページ テーブルをその場で更新することで、アプリによって常駐させることができます。 VA 範囲が NULL または非常駐ヒープにマップされている場合、リソースのその部分は非常駐と見なされます。 VA 範囲が常駐ヒープにマップされている場合、リソースのその部分は常駐と見なされます。 ヒープは作成時に常駐します。
配置されたリソースは、ヒープの特定の領域 (たとえば、5 Mb ヒープ内のテクスチャの 1 Mb 領域) へのポインターである、はるかにシンプルな設計です。 エイリアシング バリアを使用すると、配置されたリソースの重複を使用できます (「CreatePlacedResourceと ResourceBarrier参照)。
予約済みリソースはすべての Direct3D 12 ハードウェアで使用できるわけではありません。配置されたリソースは適切なフォールバックですが、配置されたリソースは連続している必要があり、部分的に常駐することはできません。
メモリの予算
Direct3D 12 では、ヒープを割り当てるときに、コミットされたリソースの物理メモリの側面を作成します。 Direct3D 12 では、より明示的なメモリ セグメントの選択が可能です (ビデオとシステム メモリの選択)。 UMA アダプターには、1 つのメモリ セグメント (システム メモリ) しかありません。
GPU はページフォールトをサポートしていないため、開発者はコミットを超えないことを意識する必要があります。特に、システムでは 1 Gb のシステム メモリしか使用できません。 アプリがコミットを超える場合、OS は物理メモリに対する要求に応じて、プロセスのより粗いスケジュール設定を使用します。 スケジューラはフォアグラウンド プロセスを固定し、実行するバックグラウンド プロセスをページインするために、基本的にその一部をページアウトします。 使用可能な物理メモリは、ユーザーがバックグラウンドで何をしているか (ブラウザーの実行やビデオの視聴など) によって大きく異なる場合があります。
メモリ予算の API は QueryVideoMemoryInfoです。 ディスクリート アダプター "local" はビデオ メモリの場合、"non-local" はシステム メモリです。 UMA アダプターの場合、非ローカルは常にゼロです。 設計上の問題の 1 つは、エンジンが予算とローカル予算の両方を管理するかどうかです。 ローカル予算のみを管理する方が簡単ですが、いくつかの注意事項があります。たとえば、1Gbの最大ローカル予算があり、すべてのヒープはUMAシステムのその1Gbから取得され、システムメモリへのオーバーフローはありません(明らかに、何もありません)。
アプリケーション用の Direct3D11 マネージド メモリのため、使用されていないリソースは基本的にページ アウトされます。
最も適切なリソース ディメンションを選択します。 リソースのサイズが、アプリケーションが実際に実行されている状況に適しているかどうかを検討します。 一部のユーザーは、ウィンドウまたは画面解像度が 800 x 600 のアプリケーションを実行できます。
分類戦略
メモリにバインドされたシナリオでリソースを効果的に管理するには、リソースを次のように分類することを検討してください。
| 分類 | 例 | オブジェクトと API の機能 | 管理に関する注意事項 |
|---|---|---|---|
| 危うい | ゲーム UI | コマンド アロケーター、コマンド キュー、クエリ ヒープ、リソース、リソース ヒープ。 | これらの要素は、ページング不可能/常にコミットされたメモリ内に配置する必要があります。 |
| Scaled/Optional | レベル固有のモデルとテクスチャ、スワップ チェーン、スカイ ボックス、一人称プレイヤーキャラクター モデル | リソースとヒープ。 コミットされたリソースだけでなく、配置済みリソースと予約済みリソースも同様に機能する場合があります。 | メモリ所在地の予算をレンダリング アルゴリズムに統合します。 使用可能な詳細の適切なレベルを選択し、フレームごとに 1 回未満で再評価します。 手法には、可変サイズのリソースの使用やスワップ チェーンのスケーリングが含まれます。 |
| 再利用されたリソース | シャドウ バッファー、遅延レンダリング リソース、後処理リソース、照明データ キャッシュ | リソースとヒープ。 ヒープ上に配置されたリソースの重複と、バリアのエイリアシング。 | フレーム内の大きなリソースまたはヒープ領域を再利用して、フレーム全体の要件を削減します。 フレーム内メモリ再利用の手法を使用します。 Direct3D 11 では、アプリケーションは同じ種類で十分な大きさのリソースのみを再利用できました。 Direct3D 12 ヒープを使用すると、リソースの重複を大幅に簡素化して再利用できます。 |
| ストリーミング リソース | 地形、オープンワールドテクスチャ、ジオメトリ | リソースとヒープ。 フリー スレッドの作成、バックグラウンド CPU スレッド、およびバックグラウンド コピー コマンドのキューとリスト。 | 一般的に可視性に基づく部分常駐 (ビューフラスタムまたは距離ベースの評価を使用) と再評価の常駐には、すべてのフレームが必要です。 タイルごとの部分常駐管理とフレーム間再利用を使用する手法は、GPU アダプターがヒープ内の予約済みリソースをサポートしている場合に使用できます。 フレーム間メモリの再利用を使用する手法を使用すると、部分サブリソースの常駐を実現できますが、最適ではありません。 ヒープを含む配置されたリソースは、より高速なリサイクルを可能にする必要がありますが、コミットされたリソースはフォールバックとして使用できます。 |
ほとんどの作業でストリーミング リソースに負荷を掛けるアプリケーションが多いほど、配置されたリソースと予約済みのリソースを活用し、これら 4 つの分類の間でメモリの再利用を最大化します。 ストリームするアプリケーションが多いほど、帯域幅の予算と優先順位が高くなります。
通常、Direct3D 12 グラフィックス エンジンでは、より多様で動的な予算を尊重し、以前よりも厳密に行う必要があります。 最適なアプリケーションは、プロセスに与えられた予算に 4 つのカテゴリをすべて配置し、バックグラウンド モバイル アプリから全画面表示の個別の予算にゲームプレイをスケーリングします。 しかし、多くのアプリケーションは、重要なカテゴリの種類のリソースが多すぎるため、苦労する可能性があります。 Direct3D 11 では、リソースを匿名で作成し、パフォーマンスに影響を与えずに重大な状態を占めるようになりました。 ただし、Direct3D 12 の場合、開発者はエンジンとミドルウェア全体でランダムに作成されたリソースを熱心に検索し、他のカテゴリのいずれかに再割り当てする必要があります。
その他の問題領域は、ミドルウェア コンポーネント、ユーザー コントロール、フレーム内ストリーミングです。 ミドルウェア コンポーネントは予算に公開されず、緊密に連携する必要もありません。 ミドルウェア コンポーネントは、レンダリング手法として機能を公開する可能性があります。アプリケーションはミドルウェアとエンジンの設定を公開することに依存できます。 開発者は Direct3D 11 に依存してページングを行い、適切なフレーム レートを実現できます。 場合によっては、Direct3D 11 アプリケーションがフレームごとにリソースの内容をページングしている可能性があります。その結果、ユーザーに許容されるフレーム レートが得られます。 ほとんどのエンジンは、リソース データをバックグラウンド アクティビティとしてのみストリーミングします。このアクティビティでは、優先度の高いフレーム内ストリーミングへのグレースフル フォールバックはありません。 Direct3D 12 に移行することで、探している CPU オーバーヘッドの向上の一部を損なう実装をエンジンに依頼します。 エンジン開発者は、再使用可能なリソースの機会を増やすために、フレームを段階的にからかうことについて検討できます。ミドルウェア ベンダーと連携して、フレーム内メモリの再利用のために配置されたリソースとヒープをサポートする可能性があります。