指示 KMD 更新一批值
引入了以下接口，以指示 KMD 更新一批当前值或受监视值：
DxgkDdiUpdateCurrentValuesFromCpu / DXGKARG_UPDATECURRENTVALUESFROMCPU
DxgkDdiUpdateMonitoredValues / DXGKARG_UPDATEMONITOREDVALUES
跨适配器本机围栏
- OS 必须支持创建跨适配器本机围栏，因为现有的 DX12 应用创建和使用跨适配器监视的围栏。 如果这些应用的基础队列和计划切换到用户模式提交，则受监视的围栏也必须切换到本机围栏（用户模式队列不支持受监视的围栏）。
- 必须使用类型 D3DDDI_NATIVEFENCE_TYPE_DEFAULT 创建跨适配器围栏。 否则，D3DKMTCreateNativeFence 会失败。
- 所有 GPU 共享 CurrentValue 存储的相同副本，该副本始终在系统内存中分配。 当运行时在 GPU1 上创建跨适配器本机围栏并在 GPU2 上打开它时，两个 GPU 上的 GPU VA 映射都指向同一 CurrentValue 物理存储。
- 每个 GPU 都有自己的 MonitoredValue 副本。 因此，可以在系统内存或本地内存中分配 MonitoredValue 存储。
- 跨适配器本机围栏必须解决 GPU1 正在等待 GPU2 发出信号的本机围栏的条件。 目前，没有 GPU 到 GPU 信号的概念；因此，OS 通过从 CPU 发信号通知 GPU1 来明确地解决该条件。 通过将跨适配器围栏的 MonitoredValue 设置为 0，以延长其使用寿命，可以完成此信号发送。 然后，当 GPU2 向本机围栏发出信号时，它也会引发 CPU 中断，从而允许 Dxgkrnl 更新 GPU1 上的 CurrentValue（使用 DxgkDdiUpdateCurrentValuesFromCpu，NotificationOnly 标志设置为 TRUE），并取消阻止该 GPU 的任何挂起的 CPU/GPU 等待程序。
- 尽管 MonitoredValue 对于跨适配器的本机围栏始终为 0，但在同一 GPU 上提交的等待和信号仍受益于 GPU 同步速度更快。 但是，减少 CPU 中断的电源优势会丧失，因为即使在另一个 GPU 上没有 CPU 等待程序，CPU 中断也会无条件地增加。 进行这种权衡是为了使跨适配器本机围栏的设计和实现成本保持简单。
- OS 支持在 GPU1 上创建本机围栏对象并在 GPU2 上打开的方案，其中 GPU1 支持该功能，而 GPU2 不支持。 围栏对象在 GPU2 上以常规 MonitoredFence 的形式打开。
- OS 支持在 GPU1 上创建常规受监视的围栏对象，并在支持该功能的 GPU2 上作为本地围栏打开的方案。 围栏对象将作为 GPU2 上的本地围栏打开。
跨适配器等待/信号组合
以下各子部分中的表以 iGPU 和 dGPU 系统为例，列出了可能用于 CPU/GPU 的本机围栏等待/信号的各种配置。 考虑以下两种情况：
- 这两个 GPU 都支持本机围栏。
- iGPU 不支持本机围栏，但 dGPU 支持本机围栏。
第二种方案也类似于两个 GPU 都支持本机围栏的情况，但本机围栏等待/信号提交到 iGPU 上的内核模式队列。
应通过从列中选择一对等待和信号来读取表，例如 WaitFromGPU - SignalFromGPU 或 WaitFromGPU - SignalFromCPU 等。
方案 1
在方案 1 中，dGPU 和 iGPU 都支持本机围栏。
方案 2a
在方案 2a 中，iGPU 不支持本机围栏，但 dGPU 支持。 在 iGPU 上提交等待，并在 dGPU 上提交信号。
方案 2b
在方案 2b 中，本机围栏支持保持不变（iGPU 不支持，dGPU 支持）。 这一次，在 iGPU 上提交信号，并在 dGPU 上提交等待。
未来的 GPU 到 GPU 跨适配器信号
如同步问题中所述，对于跨适配器本机围栏，由于无条件引发 CPU 中断，因此无法节省电源。
在将来的版本中，OS 将开发一个基础结构，允许一个 GPU 上的 GPU 信号通过写入公共门铃内存来中断其他 GPU，从而允许其他 GPU 唤醒、处理其运行列表并取消阻止就绪的 HW 队列。
这项工作面临的挑战是设计：
常用门铃内存。
GPU 可以写入门铃的智能有效负载或句柄，该门铃允许其他 GPU 确定已发出信号的围栏，以便它只能扫描 HWQueues 子集。
使用此类跨适配器信号，GPU 甚至可能共享本机围栏存储的相同副本（一种线性格式的跨适配器分配，类似于跨适配器扫描分配），所有 GPU 都可以从中读写。
本机围栏日志缓冲区设计
对于本机围栏和用户模式提交，Dxgkrnl 不知道本机 GPU 何时等待，以及从 UMD 排队的信号何时在 GPU 上为特定 HWQueue 取消阻止。 对于本机围栏，可以为给定的围栏抑制受监视的围栏信号中断。
:
需要一种方法来重新创建围栏操作，如该 GPUView 图所示。 深粉红色的框是信号，浅粉红色的框是等待。 当操作在 CPU 上提交给 Dxgkrnl 时，每个框开始；当 Dxgkrnl 在 CPU 上完成操作时结束。 通过这种方式，我们可以研究命令的整个生命周期。
因此，在较高级别上，需要记录的每个 HWQueue 条件为：
| 条件 | 含义 |
|---|---|
| FENCE_WAIT_QUEUED | UMD 在命令队列中插入 GPU 等待指令时的 CPU 时间戳 |
| FENCE_SIGNAL_QUEUED | UMD 在命令队列中插入 GPU 信号指令时的 CPU 时间戳 |
| FENCE_SIGNAL_EXECUTED | 在 GPU 上为 HWQueue 执行信号命令时的 GPU 时间戳 |
| FENCE_WAIT_UNBLOCKED | GPU 上满足等待条件且 HWQueue 未被阻止时的 GPU 时间戳 |
