WDDM 2.0 中的 GPU 虚拟内存

本部分提供有关 GPU 虚拟内存的详细信息，包括更改的原因以及驱动程序如何使用它。 此功能从Windows 10开始可用。

简介

在 Windows 显示驱动程序模型 (WDDM) v1.x 下，构建了设备驱动程序接口 (DDI) ，以便图形处理单元 (GPU) 引擎应通过段物理地址引用内存。 当段在应用程序之间共享和过度提交时，资源在其生存期内被重新定位，分配的物理地址会发生变化。 这导致需要通过分配和修补位置列表跟踪命令缓冲区内的内存引用，并在提交到 GPU 引擎之前使用正确的物理内存引用修补这些缓冲区。 这种跟踪和修补成本高昂，实质上是强制实施的计划模型，其中视频内存管理器 (VidMm) 必须先检查每个数据包，然后才能将其提交到引擎。

随着越来越多的硬件供应商转向基于硬件的计划模型，即直接从用户模式将工作提交到 GPU，GPU 本身管理各种工作队列，因此在提交到 GPU 引擎之前，就不再需要 VidMm 检查和修补每个命令缓冲区。

为此，WDDM v2 支持 GPU 虚拟寻址。 在此模型中，每个进程都分配有一个唯一的 GPU 虚拟地址空间，在其中执行每个 GPU 上下文。 进程创建或打开的分配在进程 GPU 虚拟地址空间中分配唯一的 GPU 虚拟地址，该地址在分配的生存期内保持不变且唯一。 这样，用户模式驱动程序就可以通过其 GPU 虚拟地址引用分配，而无需担心基础物理内存在其生存期内会发生变化。

GPU 的各个引擎可以在物理或虚拟模式下运行：

• 在物理模式下，计划模型与 WDDM v1.x 相同。 在物理模式下，用户模式驱动程序继续生成分配和修补程序位置列表。 它们沿命令缓冲区提交，用于在提交到引擎之前将命令缓冲区修补到实际物理地址。

• 在虚拟模式下，引擎通过 GPU 虚拟地址引用内存。 在此模式下，用户模式驱动程序直接从用户模式生成命令缓冲区，并使用新服务将这些命令提交到内核。 用户模式驱动程序不会生成分配或修补程序位置列表，尽管它仍负责管理分配的驻留。 有关驱动程序驻留的详细信息，请参阅 WDDM 2.0 中的驱动程序驻留。

GPU 内存模型

WDDM v2 支持 GPU 虚拟寻址的两种不同的模型： GpuMmu 和 IoMmu。 驱动程序必须 选择加入 才能支持其中一个或两个模型。 单个 GPU 节点可以同时支持这两种模式。

GpuMmu 模型

在 GpuMmu 模型中，VidMm 管理 GPU 内存管理单元和基础页表，并将服务公开给用户模式驱动程序，该驱动程序允许它管理 GPU 虚拟地址到分配的映射。 GpuMmu 意味着 GPU 使用 GPU 页表来访问数据。 页表可以指向系统内存或本地设备内存。

有关详细信息，请参阅 GpuMmu 模型。

IoMmu 模型

在 IoMmu 模型中，CPU 和 GPU 共享公用地址空间和 CPU 页表。 在这种情况下，只能访问系统内存，因此 IoMmu 适用于集成 GPU。 IoMmu 提供了一个更简单的编程模型，GPU 和 CPU 可以使用同一指针来访问内存。 无需在 GPU 可访问的内存中管理一组单独的页表。 也就是说，由于地址转换和管理的开销，IoMmu 模型可能会导致性能下降。

有关详细信息，请参阅 IoMmu 模型。