驻留概述

概述

目前，用户模式驱动程序会生成分配和修补位置列表信息以及它生成的每个命令缓冲区。 视频内存管理器将此信息用于两个目的：

• 分配列表和修补程序位置列表用于在将命令缓冲区提交到图形处理单元 (GPU) 引擎之前，使用实际段地址修补命令缓冲区。 Windows Display Driver Model (WDDM) v2 中的 GPU 虚拟地址支持无需进行此修补。
• 视频内存管理器使用分配列表和修补程序位置列表来控制分配的驻留。 视频内存管理器确保在将命令缓冲区发送到特定引擎的执行之前，命令缓冲区引用的任何分配都驻留在一起。

随着新驻留模型的引入，驻留将移动到设备上的显式列表，而不是每个命令的缓冲区列表。 视频内存管理器将确保在计划执行属于该设备的任何上下文之前，特定设备驻留要求列表上的所有分配都是驻留的。

若要管理驻留，用户模式驱动程序将有权访问两个新设备驱动程序接口 (DDI) MakeResident 和 Evict，并且需要实现新的 TrimResidency 回调。 MakeResident 会将一个或多个分配添加到设备驻留要求列表。 逐出 将从该列表中删除更多分配之一。 当视频内存管理器需要用户模式驱动程序来降低其驻留要求时， 将调用 TrimResidency 回调。

MakeResident 和 Evict 也已更新，以保留内部引用计数，这意味着对 MakeResident 的多次调用将需要相同数量的 Evict 调用才能实际逐出分配。

在新的驻留模式下，每个命令的缓冲区分配和修补程序位置列表正在逐步淘汰。虽然这些列表将在某些情况下存在，但它们将不再对驻留具有任何控制权。

重要 WDDM v2 中的驻留完全由设备驻留要求列表控制。 这在 GPU 的所有引擎和每个 API 中都是如此。

逐步淘汰分配和修补程序位置列表

随着新驻留模型的引入，分配和修补程序位置列表的作用将显著减少，实际上将完全脱离硬件辅助计划的引入。

在基于数据包的计划模型中，分配列表将继续存在，如下所示：

• 对于不支持 GPU 虚拟寻址的引擎，分配列表和修补程序位置列表将继续存在，但是，它们将仅用于修补目的，并且不再对驻留具有任何控制权。 分配列表和修补程序位置列表将同时提供给各种常用 DDI 中的用户模式驱动程序和内核模式驱动程序，但对非驻留的分配的任何引用都将导致 GPU 计划程序拒绝提交，并使设备出错 (丢失) 。 此操作模式被视为旧模式，我们希望所有 GPU 引擎在未来的硬件版本中都支持 GPU 虚拟寻址。 预期此操作模式将在 WDDM 的未来版本中被删除。
• 对于支持 GPU 虚拟寻址的引擎，会添加新的上下文创建标志 (DXGK_CONTEXTINFO_NO_PATCHING_REQUIRED) ，以指示特定上下文不需要任何修补。 指定此标志时，不会分配修补程序位置列表，并且仅分配一个非常小的分配列表 (16 个条目) 。 分配列表将用于跟踪对主图面的写入引用，不用于其他目的。 GPU 计划程序需要知道特定命令缓冲区何时写入主图面，以便它可以正确同步该缓冲区的执行，以便可能会翻转到主图面。

同样，分配列表在内核模式驱动程序“当前 ” 路径中使用，以便将有关 “当前 ”操作的源和目标的信息传递给驱动程序。 在此上下文中，分配列表将继续存在以传递参数，但是，分配列表将不用于驻留。 在需要修补的 GPU 上 ，“当前 分配”列表将包含修补前信息，就像现在一样，如果任何资源在排入计划程序的时间和计划在 GPU 上执行的时间之间在内存中移动，则会在计划 当前数据包之前 重新修补。

下表汇总了 WDDM v2 驱动程序应何时应接收各种用户模式驱动程序和内核模式驱动程序 DDI 中的分配和修补程序位置列表。

GPU 引擎	分配列表？	修补程序位置列表？
无 GPU 虚拟地址支持 (需要修补，默认)	是的，完整大小，但仅用于修补目的。 对非驻留分配的任何引用都将导致提交设备出错， (丢失) 并且提交被计划程序拒绝。	是的，完整大小。
GPU 虚拟地址支持 (DXGK_CONTEXTINFO_NO_PATCHING_REQUIRED 标志集)	是，16 个条目。 引用由命令缓冲区写入的主图面（如果有）。 由 GPU 计划程序用于与显示控制器上发生的嘴唇同步。 主表面必须已位于设备驻留要求列表中，否则引用将被拒绝。	否
GPU 虚拟地址支持 + 硬件计划	否	否