WEBKT

Vulkan分帧渲染中的精细化延迟控制 深入VkEvent同步机制

22 0 0 0

在现代高并发图形API（如Vulkan、DirectX 12）中，渲染管线的吞吐量与呈现延迟（Latency）是一对天然的矛盾。为了榨干GPU的性能，引擎通常会采用多帧并行（Frame Pacing / Pipelining）技术，让CPU在录制第 $N+1$ 帧命令时，GPU正在执行第 $N$ 帧甚至第 $N-1$ 帧。

然而，传统的粗粒度同步原语（如 VkFence 和 VkSemaphore）往往会导致不必要的管线停顿（Bubbles）。Fence 用于 CPU 与 GPU 之间的同步，Semaphore 用于不同 Queue 之间的同步，它们的操作对象都是整个 Queue 或 Command Buffer。

为了在分帧渲染中精细地控制延迟、平滑帧率并减少输入响应时间，我们需要将同步粒度细化到 GPU 管线阶段（Pipeline Stages）。这正是 vkCmdSetEvent 和 vkCmdWaitEvents 的用武之地。

为什么粗粒度同步无法实现精细延迟控制？

在典型的双帧重叠渲染（Double Buffering）中，我们通常使用两个 Fence 来控制 CPU 的提交节奏。

CPU: [ Frame 0 Record ] [ Frame 1 Record ] [ Wait Fence 0 ] [ Frame 2 Record ]
GPU:                    [ Frame 0 Execute -----------------] [ Frame 1 Execute ----]

如果 Frame 0 的 GPU 执行时间较长，CPU 会在 Wait Fence 0 处彻底挂起。这种设计存在两个主要问题：

  1. CPU 挂起过早：CPU 必须等到 GPU 完全执行完整个 Frame 0 才能开始录制 Frame 2，即使 Frame 2 的前置资源准备阶段（如静态 UBO 更新、Shadow Map 渲染）根本不依赖 Frame 0 的后期呈现结果。
  2. GPU 吞吐抖动：由于同步点在帧边界，GPU 在等待 CPU 提交新命令时可能会出现短暂的空闲，导致管线无法持续打满。

如果我们使用 VkEvent，就能在同一个 Queue 内的不同 Command Buffer 之间，或者单帧的不同 Pass 之间，建立**阶段级（Stage-level）**的依赖。

VkEvent 的核心机制：执行与内存双重屏障

VkEvent 是一种可以在 GPU 命令行中设置和等待的信号量。与 Pipeline Barrier 类似，它不仅控制执行依赖（Execution Dependency），还控制内存依赖（Memory Dependency）。但不同的是，Barrier 是立即生效的（在同一个 CmdBuffer 中阻断后续阶段），而 Event 允许我们将“信号发送”与“信号等待”在时间上和空间上剥离开来。

Command Buffer A:
... 绘制 G-Buffer ...
vkCmdSetEvent(event, VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT) // 触发信号

Command Buffer B (可属于下一帧):
vkCmdWaitEvents(event, ..., VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, ...) // 满足条件后再继续
... 采样先前生成的 G-Buffer ...

1. vkCmdSetEvent

该命令向 GPU 管道中插入一个设置事件信号的操作。

  • stageMask：指定在哪个管线阶段完成之后，Event 才被设置为 Signaled 状态。例如，设置为 VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT 意味着只有当 Color Attachment 的写入操作完全结束，Event 才会亮起。

2. vkCmdWaitEvents

该命令用于阻塞后续的 GPU 指令，直到指定的 Event 变为 Signaled。

  • srcStageMask：与 SetEvent 中的 stageMask 对应，表示等待源事件的哪些阶段。
  • dstStageMask：表示当前命令流中，哪些后续管线阶段需要被阻塞。在这些阶段之前的操作（如 Vertex Input）依然可以并发执行。

利用 Event 实现分帧渲染的延迟控制方案

假设我们正在开发一个包含“阴影图渲染（Shadow Pass）”和“主渲染（Main Pass）”的渲染器。

在第 $N+1$ 帧中，Shadow Pass 的渲染其实只依赖于场景数据的更新，而不需要等待第 $N$ 帧的后处理（Post-Processing）和 Swapchain 呈现。如果我们能让第 $N+1$ 帧的 Shadow Pass 与第 $N$ 帧的 Post-Processing 在 GPU 上并发执行，就能极大压缩帧间隔，降低输入延迟。

方案设计：

  1. 第 $N$ 帧（Command Buffer N）：

    • 提交主渲染和后处理。
    • 在后处理结束前，对特定的资源（如历史帧缓存、用于 Temporal AA 的 Velocity Buffer）执行 vkCmdSetEvent。
    • 提交呈现（Present）。

  2. 第 $N+1$ 帧（Command Buffer N+1）：

    • 立即开始录制并提交。
    • 渲染 Shadow Map（无任何前帧依赖，GPU 立即执行）。
    • 在开始主渲染（需要采样第 $N$ 帧的 TAA 历史缓存）之前，调用 vkCmdWaitEvents。

这种设计使得第 $N+1$ 帧的 CPU 录制和 GPU 早期阶段完全不需要等待第 $N$ 帧的结束，只有在真正需要前帧数据的 Fragment Shader 阶段才进行精细的阻塞。

代码实现：精细化同步控制

以下是实现这一机制的核心代码片段：

// 声明一个可重用的 VkEvent
VkEventCreateInfo eventInfo{};
eventInfo.sType = VK_STRUCTURE_TYPE_EVENT_CREATE_INFO;
VkEvent frameSyncEvent;
vkCreateEvent(device, &eventInfo, nullptr, &frameSyncEvent);

// ==================== Frame N: 录制与提交 ====================
VkCommandBuffer cmdBufferN = ...;

// ... 执行 Frame N 的常规渲染 ...

// 假设我们完成了用于下一帧历史参考的 Attachment 写入
VkImageMemoryBarrier imgBarrierN{};
imgBarrierN.sType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER;
imgBarrierN.srcAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;
imgBarrierN.dstAccessMask = VK_ACCESS_SHADER_READ_BIT; // 下一帧要读取
imgBarrierN.oldLayout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;
imgBarrierN.newLayout = VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL;
imgBarrierN.image = historyImage;
imgBarrierN.subresourceRange = {VK_IMAGE_ASPECT_COLOR_BIT, 0, 1, 0, 1};

// 在 Color Output 阶段完成后，设置 Event 并应用内存屏障
vkCmdSetEvent(
    cmdBufferN,
    frameSyncEvent,
    VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT
);

// ==================== Frame N+1: 录制与提交 ====================
VkCommandBuffer cmdBufferNplus1 = ...;

// 1. 无依赖阶段：可以和 Frame N 的后期阶段完全在 GPU 上重叠执行
// 例如：更新局部 UBO，或者渲染不需要前帧历史的 Shadow Map
RecordShadowPass(cmdBufferNplus1);

// 2. 依赖阶段：在进入需要读取 Frame N 历史图像的 Pass 之前进行等待
VkImageMemoryBarrier imgBarrierNplus1{};
imgBarrierNplus1.sType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER;
imgBarrierNplus1.srcAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;
imgBarrierNplus1.dstAccessMask = VK_ACCESS_SHADER_READ_BIT;
imgBarrierNplus1.oldLayout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;
imgBarrierNplus1.newLayout = VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL;
imgBarrierNplus1.image = historyImage;
imgBarrierNplus1.subresourceRange = {VK_IMAGE_ASPECT_COLOR_BIT, 0, 1, 0, 1};

vkCmdWaitEvents(
    cmdBufferNplus1,
    1, &frameSyncEvent,
    VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, // SrcStageMask: 对应 SetEvent 的阶段
    VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT,          // DstStageMask: 阻断当前帧的 Fragment Shader 阶段
    0, nullptr,                                    // Memory Barriers
    0, nullptr,                                    // Buffer Memory Barriers
    1, &imgBarrierNplus1                           // Image Memory Barriers (处理布局过渡和缓存可见性)
);

// 执行依赖 Frame N 数据的 Fragment Shader 绘制
RecordMainDeferredPass(cmdBufferNplus1);

关键技术细节与调优建议

1. 避免过度同步（Over-synchronization）

在调用 vkCmdWaitEvents 时，dstStageMask 的选择至关重要。如果你将其设置为 VK_PIPELINE_STAGE_ALL_COMMANDS_BIT 或 VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT，那它和使用普通的 Barrier 或者 Fence 没有任何区别，甚至因为 Event 的调度开销而变得更慢。

务必将 dstStageMask 限制在真正会发生资源读取的最晚阶段（通常是 VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT 或 VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT）。

2. 内存可见性（Memory Visibility）

仅仅进行执行同步是不够的。GPU 内部有各级 Cache（L1、L2、Tiled Cache 等）。当 Frame $N$ 写入 historyImage 后，数据可能还驻留在 L2 Cache 或 Write Buffer 中。
在 vkCmdWaitEvents 中传入的 VkImageMemoryBarrier 必须正确配置 srcAccessMask（如 VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT）和 dstAccessMask（如 VK_ACCESS_SHADER_READ_BIT），强制 GPU 进行 Cache Flush 和 Cache Invalidate，否则会导致渲染画面出现随机的闪烁或花屏（读取到脏数据）。

3. 重置 Event 的时机

一个被 Signaled 的 Event 必须在下一次使用前被 Reset。

  • 可以使用 vkCmdResetEvent 在 Command Buffer 中由 GPU 异步重置。
  • 也可以在 CPU 端使用 vkResetEvent 进行同步重置。
  • 推荐做法：在每一帧开始录制、确定该 Event 对应的 GPU 执行已经完全结束（通过 Fence 确认）后，在 CPU 端或 Command Buffer 的最开始处进行 Reset。

总结

利用 vkCmdSetEvent 和 vkCmdWaitEvents 替代粗暴的帧尾 Fence 同步，能够让 Vulkan 应用的管线利用率（GPU Utilization）大幅提升。通过将相邻帧之间的依赖关系从“整帧阻断”精细化到“阶段阻断”，我们不仅消除了不必要的 GPU 空闲等待，也给予了 CPU 更宽裕的命令录制时间。

在实际的项目工程中，配合帧率限制器（Frame Rate Limiter）以及 Present 延迟探测，Event 同步机制是打造高响应、无撕裂、极低延迟渲染引擎的必经之路。

基底剪枝者 Vulkan图形学游戏引擎

评论点评