通过

分配用法跟踪

  • 项目

随着分配列表的消失，视频内存管理器 (VidMm) 不再能够查看特定命令缓冲区中引用的分配。 因此，VidMm 不再能够跟踪分配使用情况和处理相关同步。 此责任现在由用户模式驱动程序 (UMD) 承担。 具体而言，UMD 需要处理与直接 CPU 访问分配和重命名相关的同步。

VidMm 以一种安全的方式异步延迟分配销毁，该方式既不阻止调用线程又能执行。 因此，UMD 不必担心必须延迟分配销毁。 当 VidMm 收到分配销毁请求时，它默认假定在销毁请求之前排队的命令可能会访问正在销毁的分配。 因此，VidMm 会延迟销毁操作，直到排队的命令完成。 如果 UMD 知道挂起的命令不会访问正在销毁的分配，它可以指示 VidMm 在调用 Deallocate2 或 DestroyAllocation2 时设置 AssumeNotInUse 标志来处理请求，而无需等待。

Lock2

UMD 负责处理与直接 CPU 访问相关的正确同步。 具体而言，需要 UMD 才能：

  1. 支持不覆盖和放弃锁语义，这意味着 UMD 需要实现自己的重命名方案。

  2. 对于需要同步 (的映射操作，即，不是上述不覆盖或放弃) ：

    • 如果尝试访问当前正忙的分配，并且调用方已请求锁定操作不阻止调用线程 (D3D11_MAP_FLAG_DO_NOT_WAIT) ，则返回 WasStillDrawing。
    • 或者，如果未设置 D3D11_MAP_FLAG_DO_NOT_WAIT 标志，请等待分配可用于 CPU 访问。 UMD 需要实现非污染等待。 UMD 将使用新的上下文监视机制。

目前，UMD 仍需要调用 LockCb/UnlockCb ，以要求 VidMm 为 CPU 访问设置分配。 在大多数情况下，UMD 能够在整个生存期内保持分配映射。 但是，将来将弃用 LockCb 和 UnlockCb ，转而使用新的 Lock2Cb 和 Unlock2Cb 调用。 这些较新的回调的目标是使用一组新的参数和标志提供全新的全新实现。

将从 WDDM 版本 2 中删除重排范围。 驱动程序开发人员有责任在对 LockCb 的调用转向基于 Lock2Cb 的实现时删除对重排范围的依赖。

Lock2Cb 公开为一种简单方法，用于获取分配的虚拟地址。 根据分配类型和当前驻留的当前段，存在一些限制。

驱动程序指示某个段是否可通过 CpuVisible 标志（位于 DXGK_SEGMENTDESCRIPTOR 结构的 Flags 成员中）访问 CPU 。

对于可访问 CPU 的分配：

  • 缓存的 CPU 可访问分配必须驻留在光圈段内，或者不驻留，才能锁定。 我们无法保证 CPU 与图形处理单元上的内存段之间的缓存一致性， (GPU) 。
  • 位于完全可访问 CPU 的内存段中的 CPU 可访问分配， (使用可调整大小的 BAR) 调整大小，保证可锁定并能够返回虚拟地址。 此方案不需要特殊约束。
  • 位于无法访问 CpuHostAperture) 的不可访问 CPU 内存段 (的 CPU 可访问的分配可能会因各种原因而无法映射到 CPU 虚拟地址。 如果 CpuHostAperture 空间不足或分配未指定光圈段，则无法获取虚拟地址。 因此，不可访问 CPU 的内存段中的所有 CPU 可访问分配都必须在其支持的段集中包含一个光圈段。 此要求保证 VidMm 能够在系统内存中放置分配并提供虚拟地址。
  • 已位于系统内存 (和/或映射到光圈段) 的 CPU 可访问的分配保证正常工作。

对于不可访问 CPU 的分配：

  • CPU 可访问的分配由无法直接指向 GPU 帧缓冲区的节对象提供支持。 为了锁定无法访问 CPU 的分配，该分配必须支持支持的段集中的光圈段，或者已位于系统内存中， (不得驻留在设备) 。

如果分配未驻留在设备上时成功锁定，但不支持光圈段，则分配在锁定期间不得提交到内存段。

Lock2 当前不包含任何标志， 保留 标志位必须全部为 0。

CpuHostAperture

为了在调整 BAR 大小失败时更好地支持锁定不可访问 CPU 的内存段，PCI 光圈中提供了 CpuHostAperture 。 CpuHostAperture 充当基于页面的管理器，然后可以通过 DxgkDdiMapCpuHostAperture设备驱动程序接口 (DDI) 函数直接映射到视频内存区域。 然后，VidMm 可以将一系列虚拟地址空间直接映射到 CpuHostAperture 的非连续范围，然后让 CpuHostAperture 映射到视频内存，而无需重排范围。

CPU 在不可访问 CPU 的内存段中可以引用的最大可锁定内存量限制为 CpuHostAperture 的大小。 有关向 DirectX 图形内核公开 CpuHostAperture 的详细信息，请参阅 CPU 主机光圈。

I/O 一致性

在 x86/x64 上，所有 GPU 都必须支持通过 PCIe 实现 I/O 一致性，以便 GPU 能够读取或写入可缓存的系统内存图面，并保持与 CPU 的一致性。 从 GPU 的角度来看，当图面映射为缓存一致时，GPU 需要在访问该图面时窥探 CPU 缓存。 这种一致性形式通常用于 CPU 应从中读取的资源，例如某些暂存图面。

在某些 Arm 平台上，硬件中不支持直接支持 I/O 一致性。 在这些平台上，需要通过手动使 CPU 缓存层次结构失效来模拟 I/O 一致性。 VidMm 通过跟踪来自 GPU (分配列表读/写操作) 和 CPU (映射操作、读/写) 的分配的操作来执行此操作。 VidMm 在确定缓存可能包含以下任一内容时发出缓存失效：

  • 需要写回的数据 (CPU 写入、GPU 读取)
  • 需要失效的过时数据 (GPU 写入、CPU 读取) 。

在没有 I/O 一致性的平台上，跟踪 CPU 和 GPU 对分配的访问的责任由 UMD 负责。 图形内核公开了一个新的 无效缓存DDI，UMD 可以使用该缓存来写回与可缓存分配关联的虚拟地址范围并失效。 在不支持 I/O 一致性的平台上，UMD 需要在 CPU 写入后、GPU 读取之前以及写入后和 CPU 读取之前调用此函数。 后者起初可能看起来不合时宜。 但是，由于 CPU 可能在 GPU 写入到内存之前以推理方式读取数据，因此有必要使所有 CPU 缓存失效，以确保 CPU 从 RAM 重新读取数据。