本文提供從 Windows 10 開始的 GPU 虛擬記憶體管理詳細資料（WDDM 2.0）。 它描述 WDDM 2.0 為何已變更以支援 GPU 虛擬尋址，以及驅動程式如何使用它。
簡介
在 WDDM 2.0 之前，會建置設備驅動器介面 （DDI），讓 GPU 引擎預期會透過區段實體地址參考記憶體。 當區段在跨應用程式共用且超量分配時，資源會在其生命周期內重新配置，並變更其指派的實體位址。 此過程需要透過配置與修補位置清單在命令緩衝區內追蹤記憶體參考。 然後，這些緩衝區必須先使用正確的物理記憶體參考進行修補，再提交至 GPU 引擎。 此追蹤和修補花費昂貴。 它基本上會強加排程模型，其中視訊記憶體管理員 （VidMm） 必須先檢查每個封包，才能提交至引擎。
經過一段時間，更多的硬體廠商會轉向硬體型排程模型。 在此模型中，工作會直接從使用者模式提交至 GPU，而 GPU 會管理工作本身的各種佇列。 這種演進使得有必要在提交至 GPU 引擎之前，消除對 VidMm 檢查和修補每個命令緩衝區的需求。
若要這樣做，WDDM 支援從 WDDM 2.0 開始的 GPU 虛擬尋址。 在此模型中，每個進程都會獲指派唯一的 GPU 虛擬位址 （GPUVA） 空間，讓每個 GPU 內容都能在 中執行。 進程所建立或開啟的配置會獲指派該進程 GPU 虛擬位址空間內的唯一 GPUVA。 此指派的 GPUVA 在分配期間會保持不變且是唯一的。 因此，使用者模式顯示驅動程式 （UMD） 能夠透過其 GPU 虛擬地址參考配置，而不必擔心基礎物理記憶體在其存留期內變更。
GPU 的個別引擎可以在實體或虛擬模式中運作：
在實體模式中，排程模型會維持與 WDDM v1.x 相同。 UMD 會繼續生成資源分配和修補位置清單。 這些分配清單會隨命令緩衝區提交，並在提交至引擎之前用於將命令緩衝區更新到實際的實體位址。
在虛擬模式中，引擎會透過 GPU 虛擬地址參考記憶體。 UMD 會直接從使用者模式產生命令緩衝區，並使用新的服務將這些命令提交至核心。 UMD 不會產生配置或修補程式位置清單，不過仍須負責管理配置落地。 如需驅動程式駐留的詳細資訊，請參閱 WDDM 2.0 中的驅動程式駐留。
GPU 記憶體模型
WDDM v2 支援兩個不同的 GPU 虛擬尋址模型 GpuMmu 和 IoMmu。 驅動程式必須 選擇參加 以支援其中一個或兩個模型。 單一 GPU 節點可以同時支援這兩種模式。
GpuMmu 模型
在 GpuMmu 模型中，VidMm 會管理 GPU 記憶體管理單位和基礎頁面數據表。 VidMm 亦提供服務給 UMD，使其能夠管理 GPU 虛擬位址映射到資源分配。 GpuMmu 表示 GPU 使用 GPU 頁面數據表來存取數據。 分頁表可以指向系統記憶體或本機裝置記憶體。
如需詳細資訊，請參閱 GpuMmu 模型。
IoMmu 模型
在 IoMmu 模型中，CPU和 GPU 都會共用通用位址空間和CPU分頁表。 在此情況下，只能存取系統記憶體，因此IoMmu適用於整合式 GPU。 IoMmu 提供更簡單的程序設計模型，其中 GPU 和 CPU 都可以使用相同的指標來存取記憶體。 不需要在 GPU 可存取的記憶體中管理一組個別的頁面數據表。 也就是說，IoMmu 模型可能會導致效能降低，因為地址轉譯和管理的額外負荷。
如需詳細資訊，請參閱 IoMmu模型。