window 显示驱动开发-使用有保证的协定 DMA 缓冲区模型
Windows Vista 的显示驱动程序模型保证呈现设备的 DMA 缓冲区和修补程序位置列表的大小。 修补程序位置列表包含 DMA 缓冲区中命令引用的资源的物理内存地址。
在有保证的协定模式下，用户模式显示驱动程序知道 DMA 缓冲区和修补程序位置列表的确切大小，当用户模式显示驱动程序填充命令缓冲区并调用 pfnRenderCb 将它们提交到显示微型端口驱动程序时，这些 DMA 缓冲区和修补程序位置列表可供转换。 每次调用 pfnRenderCb 后，用户模式显示驱动程序将收到可用于以下转换 (即对 pfnRenderCb 的以下调用) 的 DMA 缓冲区和修补程序位置列表的大小。
视频内存管理器保证在下一次转换完成之前不会剪裁该设备的 DMA 缓冲区和修补程序位置列表。 显示微型端口驱动程序必须能够将一个命令缓冲区转换为恰好一个 DMA 缓冲区和一个修补程序位置列表。 如果无法进行此转换，则根据定义，用户模式命令缓冲区无效。 显示微型端口驱动程序无法返回状态，指示转换期间它已超过 DMA 缓冲区空间和修补程序位置列表;这样做会导致视频内存管理器错误检查系统，因为内存管理器无法满足保证的 DMA 协定的要求。
1. 核心概念解析
(1) DMA 缓冲区与修补程序位置列表(Patch Location List)
- DMA 缓冲区：包含 GPU 可执行的硬件指令序列，由内核模式驱动(KMD)从用户模式命令转换而来。
- 修补程序位置列表：记录 DMA 缓冲区中引用的资源（如纹理、顶点缓冲区）的 物理内存地址，用于运行时重定位（如内存被 VidMm 迁移时）。
(2) 有保证的协定(Guaranteed Contract)
- 关键保证：VidMm 承诺在每次 pfnRenderCb 调用后，为设备提供 固定大小的 DMA 缓冲区+修补列表空间，直到下次提交完成。
- 违反后果：若 KMD 无法在给定空间内完成转换，系统会触发 bugcheck（蓝屏），因为协定被破坏。
2. 工作流程与责任划分
sequenceDiagramparticipant UMD as 用户模式驱动(UMD)participant VidMm as 视频内存管理器participant KMD as 内核模式驱动(KMD)participant GPU as GPU硬件UMD->>VidMm: 1. 初始化时获取DMA缓冲区大小VidMm-->>UMD: 返回保证的DMA缓冲区/修补列表大小loop 每帧渲染UMD->>UMD: 2. 生成命令缓冲区(用户空间)UMD->>KMD: 3. 调用pfnRenderCb提交KMD->>KMD: 4. 验证并转换命令alt 转换成功KMD->>GPU: 5. 提交DMA缓冲区+修补列表KMD->>VidMm: 6. 返回执行状态VidMm->>UMD: 7. 更新下次可用缓冲区大小else 转换失败(空间不足)KMD->>System: 触发bugcheckendend
3. 开发者视角的实现要求
用户模式驱动(UMD)责任
// 示例：UMD提交命令的典型流程
void UmdSubmitCommands() {// 1. 从VidMm获取当前可用空间D3DDDICB_RENDER renderCB = {0};pfnGetCaps(D3DDDICAPS_GET_DMA_BUFFER_SIZE, &renderCB);// 2. 生成不超过限制的命令BYTE* cmdBuffer = AllocCommandBuffer(renderCB.DmaBufferSize);GenerateCommands(cmdBuffer, renderCB.DmaBufferSize);// 3. 提交并获取下次空间HRESULT hr = pfnRenderCb(&renderCB);if (SUCCEEDED(hr)) {UINT nextBufferSize = renderCB.NextDmaBufferSize; // 更新下次可用大小}
}内核模式驱动(KMD)责任
// 在DxgkDdiRender回调中的处理
NTSTATUS DxgkDdiRender(IN_CONST_HANDLE hContext,INOUT_PDXGKARG_RENDER pRender)
{// 1. 必须在保证空间内完成转换if (pRender->DmaBufferSize < RequiredSpace()) {return STATUS_GRAPHICS_INSUFFICIENT_DMA_BUFFER; // 实际上会触发bugcheck}// 2. 转换命令到DMA格式ConvertToDmaBuffer(pRender->pCommand, pRender->DmaBuffer, pRender->DmaBufferSize);// 3. 填充修补位置列表GeneratePatchList(pRender->PatchLocationList,pRender->PatchLocationListSize);return STATUS_SUCCESS;
}4. 关键设计原理
(1) 为什么需要固定大小保证？
- 确定性执行：避免动态内存分配导致的不确定性延迟。
- 安全隔离：防止用户模式驱动通过故意溢出引发内核内存损坏。
- 性能优化：固定大小便于预分配内存池，减少运行时开销。
(2) 修补列表的物理地址重定位
当 VidMm 迁移资源内存时（如显存不足时逐出到系统内存），只需更新修补列表中的物理地址，无需修改 DMA 缓冲区本身：
// VidMm 的迁移处理示例
void VidMmRelocateResource(RESOURCE* res, PHYSICAL_ADDRESS newAddr) {foreach (PatchEntry* entry in res->PatchLocations) {*entry->DmaBufferPtr = newAddr; // 更新GPU指令中的地址}
}5. 违反协定的典型场景
| 错误类型 | 后果 | 调试方法 |
|---|---|---|
| DMA 缓冲区溢出 | 立即触发 VIDEO_TDR_FAILURE bugcheck | 检查 KMD 的转换逻辑大小计算 |
| 修补列表溢出 | 同上 | 验证资源引用计数 |
| 无效命令引用 | 可能延迟触发 GPU 挂起 | 使用 PIX 捕获命令缓冲区 |
| 未处理的页面错误 | GPU 访问违例 | 检查修补列表是否覆盖所有资源引用 |
6. 现代演进（Windows 10+）
- 弹性内存管理：Windows 10 引入部分弹性分配，但核心协定仍保留。
- 直接提交(Direct Submission)：允许绕过部分验证，但需驱动显式声明能力。
- GPU 虚拟内存：物理地址重定位需求减少，但修补列表机制仍存在以兼容旧硬件。
总结
WDDM 的 DMA 保证协定通过：
- 固定大小预分配 确保确定性
- 严格空间强制 维护系统稳定性
- 物理地址重定向 实现内存虚拟化
开发者必须：
- UMD 严格遵守大小限制
- KMD 确保转换绝不溢出
- 利用修补列表处理资源迁移
这种设计平衡了性能、安全与灵活性，是 Windows 图形栈稳定性的基石。