6.2 信号量、事件与管线屏障

6.2 信号量、事件与管线屏障

本节摘要：GPU 侧的同步有三档粒度：信号量管队列之间的整批交接，管线屏障管队列内部阶段间的读写可见性，事件提供命令中间的细粒度锚点。本节讲清三者的语法与适用边界，重点拆解管线屏障的完整参数——阶段掩码、访问掩码、布局迁移——并用一桩上传竞态案演示因果推理。

别以为提交顺序等于执行顺序——GPU 会把不同命令缓冲的片段交错执行，同一缓冲内的相邻命令之间也不存在「先写完再读」的默认保证。这个反直觉的事实是本节全部内容的存在理由：GPU 内部的读写次序必须由开发者逐处声明，而声明工具就是本节的三个原语。

一、四种工具的分工表

先立全景，再逐个展开：

二值信号量在 2.5 与 5.2 已经上手，这里补一条边界的精确表述：它只能在 vkQueueSubmit 与 vkQueuePresentKHR 的参数里出现，没有「CPU 等信号量」的接口——那不是遗漏而是设计：CPU 侧等待用栅栏，GPU 侧接力用信号量，语义不混用。

时间线信号量（1.2 核心化）是二值的升级：携带一个单调递增的 64 位值，等待可以指定「到达某值」，发信号可以「推进到某值」，还支持 host 侧的等待与发信号。它的杀手级用途是合并链路——过去「采集等上传、渲染等采集、读回等渲染」要三条二值信号量各配收发两端，现在一条时间线按值段串完，且 host 可以在任意节点参与。

二、管线屏障：可见性合同的正本

管线屏障（vkCmdPipelineBarrier）是使用频率最高、参数最容易被填错的原语。它的语义是一份五栏合同：内存依赖标志、源阶段与源访问（「谁写完」）、目的阶段与目的访问（「谁要读」）、可选的图像布局迁移。以 3.3 节的纹理上传为例，把合同填全：

VkImageMemoryBarrier b = {VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER};
b.srcAccessMask    = VK_ACCESS_TRANSFER_WRITE_BIT;    // 拷贝写过的数据
b.dstAccessMask    = VK_ACCESS_SHADER_READ_BIT;       // 即将被着色器读
b.oldLayout        = VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL;
b.newLayout        = VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL;
b.srcQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED;
b.dstQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED;
b.image            = texImage;
b.subresourceRange = { VK_IMAGE_ASPECT_COLOR_BIT, 0, 1, 0, 1 };

vkCmdPipelineBarrier(cmd,
    VK_PIPELINE_STAGE_TRANSFER_BIT,          // 源阶段：拷贝
    VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT,   // 目的阶段：片段采样
    0,
    0, NULL,                                 // 全局内存屏障条数
    0, NULL,                                 // 缓冲屏障条数
    1, &b);                                  // 图像屏障条数
​

填合同的推理顺序值得练成肌肉记忆：先问「数据刚被谁写」（定源阶段与源访问），再问「即将被谁读」（定目的阶段与目的访问），布局若变则 old、new 两栏照实填。三对掩码的宽严把握：阶段掩码宁窄勿宽——宽掩码（比如全阶段）会打断驱动并行，是「能跑但慢」的隐形税；访问掩码必须与阶段匹配——TRANSFER 阶段配 SHADER_READ 位属于张冠李戴，验证层会点名单独报。缓冲屏障与全局内存屏障结构类似，只是没有布局栏，用于普通缓冲数据的读写交接。

三、事件：命令中间的锚点

事件（VkEvent）最细的一档：可以被命令缓冲中的 vkCmdSetEvent 在某个阶段边界置位，被后续 vkCmdWaitEvents 等待；也可以由 CPU 用 vkSetEvent 直接置位。经典用途是条件渲染的开关切换，以及「同队列内两段命令缓冲之间」的轻量握手（跨提交的握手，事件比屏障省去重复声明）。要注意事件的等待是阶段锚定语义——它不做布局迁移，也不跨队列，超出这两条边界就该换工具。

四、案例：上传后立刻采样的竞态

背景：运行时生成的小纹理（字体图集）每帧增量上传，偶发「新字符采样成旧颜色」，且难以稳定复现。团队先怀疑描述符更新时序（3.4 的老朋友），排查一晚未果。

操作：换因果推理重审。描述符指向的是图像，图像的状态链是「拷贝写入、布局迁移、着色器采样」三段；逐段核对合同，发现迁移屏障的目的阶段填的是 VERTEX_SHADER_BIT，而真正采样发生在片段阶段——源与目的都「合法」，但目的侧签错了人：片段阶段的采样不受这份合同保护，读到旧内容全凭运气。

结果：目的阶段改为 FRAGMENT_SHADER_BIT，配合拷贝阶段的真实掩码（TRANSFER_WRITE 对 SHADER_READ），问题归零。团队顺势把「屏障推理三问」写进代码评审清单。

解读：这桩案子的教训是屏障错误的最狡猾形态——不非法、不报错，只是「保护了错误的对象」。阶段掩码填错等于合同签给旁听席，一切照常运转直到时序翻转。同步类故障的排查习惯应当是「先读合同再怀疑数据」，与直觉相反但效率高得多。

变式：上传与采样跨队列时（上传在传输队列、采样在图形队列），屏障退场、二值信号量进场：上传提交发出信号、渲染提交等待同一信号，布局迁移合并在渲染提交的开头屏障里完成。工具随管辖边界切换，因果链不变。

五、要点回顾

• 分工不混用：队列间接力用信号量、队列内可见性用屏障、命令间锚点用事件、CPU 等待只认栅栏。
• 时间线合并链路：按值等待与发信号，host 可参与，一条顶多条二值。
• 屏障五栏合同：源阶段访问、目的阶段访问、布局迁移，推理按「谁写、谁读、状态怎么变」进行。
• 掩码宁窄勿宽：全阶段掩码是并行性杀手，阶段与访问的搭配要成对出现。
• 静默错误形态：签错目的阶段的屏障不报错只失效，同步排查先读合同再怀疑数据。