GPU virtual memory in WDDM 2.0
这部分提供了关于GPU虚拟内存的细节。包括了为什么会有2.0中的一些变化，以及驱动怎么使用这些新特性。这些功能从win10以后就可以开始使用。
Introduction
在WDDM1.X下，DDI被建立在GPU引擎期望通过Segment PA来引用内存的前提下。因为Segments会被在应用间共享以及会被重复提交，资源也会在其神明周期中重新分配并且资源被赋予的物理地址也会被改变。这导致了在CB内部引用的内存需要被分配以及Patch地址列表，并且在Submite到GPU引擎之前会Patch这些Buffer到正确的物理地址。这个跟踪(Tracking)和Patching的过程，在VMM提交到GPU引擎之前，检查Packet的时候非常关键开销也非常大。
因此更多的硬件厂商开始转向基于硬件的调度模型，这个模型可以让用户模式代码直接提交资源到GPU中，GPU也能能够控制自己的各种工作队列。对于消消除在提交GPU引擎之前让VMM检查以及Patch每一个CB这个过程是很有必要的。
对于达成这个目的，我们在WDDM2.0中引进了GPU VA的支持。在这个模型中，每个进程都被赋予了块唯一的GPU VA空间，每一个GPU上下文也执行在这个VA空间中。所有的Allocation被一个进程创建或者打开时就被赋予了一个GPUVA。在这个进程的GPU VA空间中这个地址是静态的并且在Allocation的生命周期中都是唯一的。这个特性就让UMD通过GPU VA来引用Allocation而不需要担心在Allocation生命周期中物理地址会改变的问题。
每一个GPU引擎都能工作在物理模式或是虚拟模式下。在物理模式中，调度仍然和WDDM v1.x一致。在物理模式中UMD继续生成Allocation和Patch location List. Patch Location List 和Commond Buffer一起提交到GPU引擎，被用作在提交到GPU引擎之前Patch CB到实际的物理地址。
在虚拟模式中，引擎通过GPU虚拟地址来引用内存。在这个模式中，UMD直接在用户态下直接生成CB，并且UMD使用一些新的服务将这些CMD提交到内核中。在这种模式下UMD并不生成Allocation或者Patch Location List.虽然UMD仍然负责管理Allocation的residency.
GPU memory models
WDDM v2 对于GPU VA支持两种不同的模式，GpuMmu和IoMmu.驱动程序需要选择支持其中一种或者两种模式都支持。单个GPU node就能同时支持这两种模式。
GpuMmu 模式
在GpuMmu模式中，视频内存管理器(VMM)管理着GPU内存管理单元(MMU)和隐藏在背后的页表。VMM还暴露一些服务给UMD，允许UMD管理映射到Allocation的GPU VA。
IoMmu 模式
在IoMmu中，CPU和GPU共享同一个地址空间和一些页表。
