次の方法で共有

ダーティ ビット トラッキング

  • [アーティクル]

この記事では、Windows 11 バージョン 24H2 (WDDM 3.2) 以降でサポートされているダーティ ビット トラッキング機能について説明します。 GPU 並列化デバイスでのライブ マイグレーションをサポートするドライバーは、ダーティ ビット トラッキングもサポートする必要があります。

はじめに

クラウド シナリオでの GPU の普及に伴い、仮想マシンを物理ホスト間で移行する必要性が高まっており、適切なパフォーマンスが維持されます。 このニーズによって、ユーザーへの影響が軽減されるだけでなく、VM の移行時の TCP 要求タイムアウトなどの問題を回避することもできます。

物理ホスト間でのメモリ コンテンツの転送は、次の 2 つの全体的なパスで行われます。

  1. ブラウンアウト: ブラウンアウト期間中、仮想マシンは引き続き実行されますが、システムはダーティ データを反復的に保存します。 目標は、各イテレーション中に汚れるデータの量が減り、すばやくコピーできるデータの小さなサブセットに収束することです。 このデータ量はコンピューターのワークロードによって異なり、特定のサイズに収束することは保証されません。

  2. ブラックアウト: ブラックアウト期間中、仮想マシンは一時停止され、残っているすべてのダーティ データがコピーされます。 このコピーにより、コピー先コンピューター上の結果のデータがソースと同じ状態になります。

ダーティ ビット トラッキングを使用しない場合、システムはブラックアウト期間中に GPU のフレーム バッファー (VRAM) の完全なコピーを 1 つ使用する必要があります。 ブラウンアウト パスをサポートするには、ハードウェアが汚れたメモリ ページをアクティブに追跡し、OS に報告して、コピーするメモリのみが OS に認識されるようにする必要があります。

詳細な設計

レポート機能

アダプターの初期化時、Dxgkrnl はドライバーに対して、ハードウェアで使用されるダーティ ビット プレーンの形式、つまり各ビットで表されるページ サイズ (またはデータ量) に関する情報を求めます。

ダーティ キャプチャの開始と停止

ダーティ情報の追跡がハードウェアのパフォーマンスを大きく犠牲にする場合、ブラウンアウト期間中のみダーティ トラッキングを有効にするのが理にかなっています。 この間、移行のコストを最小限に抑えることが、トラッキングの潜在的なパフォーマンスへの影響よりも重要です。

ただし、パフォーマンスに影響を与える可能性がごくわずかかまったくない場合、常にこの動作を有効にすることに利点があります。 VM で大量の GPU ワークロードを実行しないユーザーもいるため、メモリが最初から大きく汚れているとは限りません。 起動時にダーティ ビット トラッキングを有効にすると、ブラウンアウトの最初のイテレーションで、フレーム バッファーの完全なコピーを必要とせずに、ダーティ データをすぐに使用することができます。 ユーザーによって汚されたメモリの量が少ない場合 (たとえば、ユーザーが主に CPU ワークロードを実行している場合)、移行のコスト削減は非常に大きくなる可能性があります。

ダーティ ビットの照会

ダーティ情報は、ダーティ ページのビットプレーンとして表されます。 ビット プレーン内の各ビットは、メモリの 1 つの "ページ" を表します。 ダーティ データのページ サイズは、GPU 上の仮想アドレス指定の自然なページ サイズ (たとえば、4 KB/64 KB) に合わせる必要はありません。 特定のハードウェアに最適であれば何でもかまいません。 ドライバーは、初期化時にこのページ サイズを報告します。

ブラウンアウト期間中、Dxgkrnl はハードウェアに対して、各イテレーション間のダーティ データを照会します。 現時点では、ドライバーがアトミックに照会し、ビットプレーン データをリセットできる必要があります。 つまり、ハードウェアは値を照会し、1 回のアトミック操作でゼロにリセットして、ダーティ情報内のデータの損失を防ぐ必要があります。

仮想マシンがすべて同じ宛先に移行されるとは限らないため、フレーム バッファーの移行は仮想 GPU インスタンスごとに行われます。 そのため、ドライバーは、その特定の仮想 GPU インスタンスを表すフレーム バッファー全体の指定されたサブ範囲のビットプレーン情報を照会できる必要があります。 たとえば、8 GB GPU 分割では、4 つの方法で、他のダーティ ビット データに影響を与えることなく、VRAM の 2 GB 範囲ごとにビットプレーンのビットを個別に照会およびリセットできる必要があります。

DDI の変更

機能

次の上限が DXGK_QUERYADAPTERINFOTYPE に追加されました。

  • DXGKQAITYPE_DIRTYBITTRACKINGCAPS

    システムは、アダプターの初期化時に DXGKQAITYPE_DIRTYBITTRACKINGCAPS の DXGK_QUERYADAPTERINFOTYPE を使用して、KMD の DxgkDdiQueryAdapterInfo 関数を呼び出し、ダーティ ビット トラッキングのドライバーとハードウェアの機能を決定するようになりました。

    KMD は、pOutputData がポイントする指定された DXGK_DIRTY_BIT_TRACKING_CAPS 構造を入力する必要があります。

  • DXGKQAITYPE_DIRTYBITTRACKINGSEGMENTCAPS

    KMD で DirtyBitTrackingSupported が TRUE に設定されている場合、システムはシステム上の各メモリ セグメントに対して DXGKQAITYPE_DIRTYBITTRACKINGSEGMENTCAPS の DXGK_QUERYADAPTERINFOTYPE を使用して、KMD の DxgkDdiQueryAdapterInfo 関数を呼び出し、ダーティ ビット トラッキングのサポートに関する情報を照会します。

    KMD は、pOutputData がポイントする指定された DXGK_DIRTY_BIT_TRACKING_SEGMENT_CAPS 構造を入力する必要があります。

メモリ ベースの DDI

VRAM での変更操作のトラッキングは、連続してバックアップされない可能性がある割り当てを対象としています。 たとえば、ライブ マイグレーションでの最初の使用は、仮想関数のフレームバッファー予約の追跡に適用されます。 したがって、ダーティ ビット トラッキングで表される物理アドレスは、操作対象の割り当てを表す範囲のコレクションで構成されます。

操作が同じ範囲に一致していることを確認することが重要です。 多くの場合、この照合は、状態を適切に追跡するため、インターフェイスの強制的な不変性でなければなりません。 KMD でこのトラッキングを支援するため、以下のインターフェイスが導入されています。