Windows 10 开始引入了 WDDM 2.0。 它包括几个新功能和增强功能，旨在提高 Windows 显示驱动程序模型(WDDM)的性能和功能，例如：
GPU 虚拟寻址，其中每个进程分配有一个唯一的 GPU 虚拟地址(GPUVA)空间，每个 GPU 上下文都可以在其中执行。
驱动程序驻留，其中驻留被移至设备上的显式列表，而不再是每个命令的缓冲区列表。 视频内存管理器 (VidMm) 确保在计划执行属于该设备的任何上下文之前，特定设备驻留要求清单上的所有分配项已经驻留。
上下文监控，这允许在 GPU 引擎之间或 CPU 核心和 GPU 引擎之间灵活同步。 受监视的围栏对象是隔离同步的高级形式，允许 CPU 核心或 GPU 引擎向特定围栏对象发出信号或等待。
GPU 虚拟寻址
在 Windows 显示驱动程序模型 (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 不会生成分配或修补位置列表，尽管它仍负责管理分配的驻留。
GPU 内存模型
WDDM v2 支持两个不同的 GPU 虚拟寻址模型， GpuMmu 和 IoMmu。 驱动程序必须 选择加入 以支持任一模型或两种模型。 单个 GPU 节点可以同时支持这两种模式。
GpuMmu 模型：在 GpuMmu 模型中，VidMm 管理 GPU 内存管理单元和基础页表。 VidMm 还会向 UMD 公开服务，以允许它管理 GPU 虚拟地址映射到分配的服务。 GpuMmu 表示 GPU 使用 GPU 页表访问数据。 页表可能指向系统内存或本地设备内存。
IoMmu 模型：在 IoMmu 模型中，CPU 和 GPU 共享公共地址空间和 CPU 页表。 在这种情况下，只能访问系统内存，因此 IoMmu 适用于集成 GPU。 IoMmu 提供了更简单的编程模型，GPU 和 CPU 可以使用同一指针来访问内存。 无需在 GPU 可访问的内存中管理一组单独的页表。 也就是说，IoMmu 模型可能会导致性能下降，因为地址转换和管理的开销。