WDDM 2.0 の GPU 仮想メモリ

この記事では、Windows 10 (WDDM 2.0) 以降の GPU 仮想メモリ管理について詳しく説明します。 GPU 仮想アドレス指定をサポートするように WDDM が変更された理由と、ドライバーによる使用方法について説明します。

はじめに

Windows ディスプレイ ドライバー モデル (WDDM) 2.0 より前は、GPU エンジンがセグメントの物理アドレスを介してメモリを参照することが期待されるように、デバイス ドライバー インターフェイス (DDI) が構築されていました。 セグメントがアプリケーション間で共有され、過剰にコミットされると、リソースは有効期間を通じて再配置され、割り当てられた物理アドレスが変更されました。 このプロセスでは、割り当てとパッチの場所リストを使用して、コマンド バッファー内でメモリ参照を追跡する必要がありました。 その後、GPU エンジンに送信する前に、これらのバッファーに正しい物理メモリ参照のパッチを適用する必要がありました。 この追跡と修正プログラムの適用は高価でした。 基本的に、ビデオ メモリ マネージャー (VidMm) は、エンジンに送信する前にすべてのパケットを検査する必要があるスケジューリング モデルを課しました。

時間の経過と同時に、ハードウェア ベースのスケジューリング モデルに移行するハードウェア ベンダーが増えています。 このモデルでは、作業はユーザー モードから直接 GPU に送信され、GPU は作業自体のさまざまなキューを管理します。 この進化により、GPU エンジンに送信する前に、VidMm がすべてのコマンド バッファーを検査してパッチを適用する必要がなくなります。

これを行うために、WDDM では、WDDM 2.0 以降の GPU 仮想アドレス指定がサポートされます。 このモデルでは、各プロセスに、すべての GPU コンテキストを実行できる一意の GPU 仮想アドレス (GPUVA) 領域が割り当てられます。 プロセスによって作成または開かれた割り当てには、そのプロセスの GPU 仮想アドレス空間内に一意の GPUVA が割り当てられます。 この割り当てられた GPUVA は、割り当ての有効期間中、一定で一意のままになります。 したがって、ユーザー モード ディスプレイ ドライバー (UMD) は、GPU 仮想アドレスを介して割り当てを参照できるため、その有効期間を通じて基になる物理メモリの変化を心配する必要はありません。

GPU の個々のエンジンは、物理モードまたは仮想モードのいずれかで動作できます。

• 物理モードでは、スケジュール モデルは WDDM v1.x と同じままです。 UMD は引き続き割り当てとパッチの場所リストを生成します。 これらの割り当てリストはコマンド バッファーと共に送信され、エンジンに送信する前にコマンド バッファーを実際の物理アドレスにパッチを適用するために使用されます。

• 仮想モードでは、エンジンは GPU 仮想アドレスを介してメモリを参照します。 UMD はユーザー モードから直接コマンド バッファーを生成し、新しいサービスを使用してそれらのコマンドをカーネルに送信します。 UMD は割り当てまたはパッチの場所リストを生成しませんが、割り当ての所在地の管理は引き続き行います。 ドライバーの所在地の詳細については、「WDDM 2.0 のドライバー所在地」を参照してください。

GPU メモリ モデル

WDDM v2 では、GPU 仮想アドレス指定用に GpuMmu と IoMmu の 2 つの異なるモデルがサポートされています。 ドライバーは、いずれかのモデルまたは両方のモデルをサポートするためにオプトインする必要があります。 1 つの GPU ノードで両方のモードを同時にサポートできます。

GpuMmu モデル

GpuMmu モデルでは、VidMm は GPU メモリ管理ユニットと基になるページ テーブルを管理します。 VidMm では、割り当てに対する GPU 仮想アドレス マッピングを管理できるサービスも UMD に公開されます。 GpuMmu は、GPU が GPU ページ テーブルを使用してデータにアクセスすることを意味します。 ページテーブルは、システムメモリまたはローカルデバイスメモリを指す場合があります。

詳細については、次を参照してください GpuMmu モデル

IoMmu モデル

IoMmu モデルでは、CPU と GPU は共通のアドレス空間と CPU ページ テーブルを共有します。 この場合、システムメモリにのみアクセスできるため、IoMmuは統合GPUに適しています。 IoMmu には、GPU と CPU の両方が同じポインターを使用してメモリにアクセスできる、より単純なプログラミング モデルが用意されています。 GPU でアクセス可能なメモリ内のページ テーブルの個別のセットを管理する必要はありません。 ただし、IoMmu モデルでは、アドレス変換と管理のオーバーヘッドにより、パフォーマンスが低下する可能性があります。

詳細については、次を参照してください IoMmu モデル。