window 显示驱动开发-使用有保证的协定 DMA 缓冲区模型

news2025/5/17 15:11:41

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. 工作流程与责任划分

sequenceDiagram
    participant 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: 触发bugcheck
        end
    end

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 访问违例	检查修补列表是否覆盖所有资源引用