当前位置：首页 > news >正文

Windows 图形显示驱动开发-驱动驻留的供应和回收更改

news 来源：原创 2025/9/19 18:09:35

访问非用户分配

对于 Windows 显示驱动程序模型 (WDDM) v2，有关套餐和回收的要求正在放宽。用户模式驱动程序不再需要在内部分配上使用套餐和回收。空闲/挂起的应用程序将使用 Microsoft DirectX 11.1 中引入的 TrimAPI 删除驱动程序内部资源。

API 级别将继续支持套餐和回收，并且需要用户模式驱动程序将应用程序请求转发到内核，以便将资源提供或回收到内核。在 WDDM v2 下，不再通过分配列表支持产品/服务分配，因此用户模式驱动程序需要更改其实现套餐和回收的方式。

如果资源在直接内存访问 (DMA) 缓冲区中没有引用，则用户模式驱动程序应立即通过调用 OfferCb 来提供应用程序提供的资源。如果资源在正在生成的 DMA 缓冲区中具有挂起的引用，则用户模式驱动程序应延迟对 OfferCb 的调用，直到通过 RenderCb 提交依赖的 DMA 缓冲区之后。图形内核将负责以非阻塞的方式延迟操作，直到提供资源是安全的，因此用户模式驱动程序无需担心必须延迟对 OfferCb 的调用，直到图形处理单元上的依赖操作完成， (GPU) 。

如果呼叫回收位于驻留要求列表中， (即用户或驱动程序已通过 MakeResidentCb 调用) 请求分配驻留，则调用回收将自动在分配中分页。对于 ReclaimAllocations2Cb，此操作是异步的，并且返回分页围栏，处理方式应与从 MakeResidentCb 返回的围栏相同。当发出围栏信号时，保证分配在 GPU 上驻留和可用。

从 ReclaimAllocationsCb/ReclaimAllocations2Cb 返回后，立即保证分配的后备存储有效，并且可以通过 Lock2Cb 将分配置于 CPU 访问权限下。驱动程序无需等待分页围栏即可执行此操作。

访问非用户分配

GPU 对非驻留分配的访问是非法的。此类访问会导致为生成错误的应用程序删除设备。

有两种不同的模型来处理此类无效访问，具体取决于故障引擎是否支持 GPU 虚拟寻址：

对于不支持 GPU 虚拟寻址并使用分配和修补位置列表来修补内存引用的引擎：

当用户模式驱动程序提交引用不驻留在设备上的分配的分配列表 (即用户模式驱动程序未在该分配) 上调用 MakeResidentCb 时，将发生无效访问。发生此无效访问时，图形内核会将错误的上下文/设备置于错误状态。

对于支持 GPU 虚拟寻址但访问 GPU 虚拟地址 (VA) 无效的引擎：

GPU 预期会以中断的形式引发不可恢复的页面错误。发生页面错误中断时，内核模式驱动程序需要通过新的页面错误通知将错误转发到图形内核。当图形内核收到此通知时，它会在出错的引擎上启动引擎重置，并使错误的上下文/设备出错。如果引擎重置失败，图形内核会将错误提升为完整的适配器范围的超时检测和恢复 (TDR) 。

访问无效的 VA 可能是因为 VA 后面没有分配，或者存在有效的分配，但它不是驻留的。

进程驻留预算

在 Windows 显示驱动程序模型 (WDDM) v2 中，将为进程分配预算，用于保留其驻留的内存量。此预算可能会随时间而变化，但通常仅在系统面临内存压力时才施加。在 Microsoft Direct3D 12 之前，预算由用户模式驱动程序以剪裁通知和 MakeResident 故障的形式处理STATUS_NO_MEMORY。 TrimToBudget 通知、 Evict 和失败的 MakeResident 调用均以整数 NumBytesToTrim 值的形式返回最新预算，该值指示需要剪裁多少才能适应新预算。

对于 Direct3D 12 应用程序，预算完全由应用程序处理。预算大小旨在提供提示，让应用程序知道要调整自己的大小。通过使用预算大小作为提示，应用程序可以决定保留驻留的资源数、要保留的分辨率和资源质量。

若要正确管理这些预算，内核需要知道哪些内存应参与预算。 DXGK_SEGMENTFLAGS2 结构中有一个新的 ApplicationTarget 位，需要在内核模式驱动程序希望包含在预算逻辑中的段上设置。例如，在一个离散图形处理单元上， (GPU) 具有 1 段适合应用程序使用的 VRAM，以及 1 段自动用于特殊用途资源的 VRAM，驱动程序可能只会将主要 VRAM 段标记为 ApplicationTarget。对于集成 GPU，main内存调节段通常是标记的。可以标记为 ApplicationTarget 的段数没有限制。内核会将这些聚合在一起，并使用统一大小呈现应用程序。

访问非用户分配

访问非用户分配

进程驻留预算

相关文章：