Vulkan中SSBO传递VS计算的光源位置至FS遇读写hazard的问题

问题背景 #

使用Vulkan开发时，在顶点着色器（VS）中计算了数百个经TBN矩阵变换的全向光源位置vec3[] positions，希望传递给片元着色器（FS）读取。为避免CPU上传数据，创建了带有VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT标志的SSBO缓冲区，但运行时出现读写 hazard。着色器中SSBO的定义如下：

//ssbo for TS omni
layout(set=0, binding=11) coherent buffer OmniPositionsTS
{
    vec3 mOmniPositionsTS[];
};

此前尝试用array[16]类型的VS输出变量传递，FS以输入变量接收，效果正常，但这类varying输入输出属性的数量限制在32以内，因此回到SSBO方案，存在以下疑问：

• 片元着色器是否不会等待顶点着色器完成SSBO写入？为何普通shader varying的out/in变量不会出现此类竞态条件？
• 是否需要在顶点着色器中调用memoryBarrier？
• 传递经TBN变换的光源位置的首选方式是什么？

问题解答 #

1. SSBO读写 hazard与普通varying的差异 #

• 普通VS输出/FS输入的varying变量，Vulkan管线会自动处理同步：VS完成每个顶点的输出写入后，才会进入光栅化阶段，FS拿到的是经过合法插值的数据，管线内置的同步机制完全规避了竞态风险。
• SSBO属于通用存储资源，Vulkan默认不会为跨着色器阶段的SSBO访问自动插入同步逻辑。VS对SSBO的写入操作和FS对SSBO的读取操作，可能被管线重排或并行执行，导致FS读取到未完成写入的数据，进而出现读写 hazard。

2. 是否需要在VS中调用memoryBarrier？ #

需要，但仅在VS中调用memoryBarrier()并不足够，还需配合Vulkan API层面的同步配置：

• 在VS的代码末尾调用memoryBarrierBuffer()（比通用memoryBarrier()更精准，性能损耗更低），确保VS对SSBO的所有写入操作完成后再执行后续流程。
• 在API层面，需在绘制命令之间或子通道中设置管线内存屏障或子通道依赖：明确指定VS的VK_ACCESS_SHADER_WRITE_BIT操作必须在FS的VK_ACCESS_SHADER_READ_BIT操作前完成，管线阶段需设置VK_PIPELINE_STAGE_VERTEX_SHADER_BIT在VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT之前执行。
• 注意：SSBO上的coherent限定符仅保证着色器对SSBO的访问是连贯的，但无法替代跨阶段的同步屏障。

3. 传递变换后光源位置的首选方案 #

根据场景不同，推荐以下几种常用方案：

• 优化SSBO同步（修正当前方案）
  按照上述同步要求配置内存屏障和子通道依赖，适合需要传递大量数据的场景。需注意SSBO的内存布局对齐（GLSL中vec3会自动对齐到vec4的字节大小，分配缓冲区时要考虑这一点）。
• Push Constants（数据量较小时）
  如果光源数量在几十个以内，Push Constants是轻量高效的选择：无需额外创建缓冲区，直接将变换后的光源位置打包到Push Constants中，FS直接读取。但Push Constants的大小有硬件限制（通常最大64KB）。
• CPU预计算+UBO/SSBO
  若TBN矩阵为静态（如静态模型），可在CPU端提前完成所有光源位置的TBN变换，再上传到UBO或SSBO中，VS和FS直接读取即可。该方案避免了VS中的大量计算，也无需跨着色器阶段的SSBO同步，性能最优。
• 任务/网格着色器（支持Vulkan 1.2+）
  若GPU支持任务着色器（Task Shader）和网格着色器（Mesh Shader），可在任务着色器中完成所有光源的TBN变换，再将数据传递给网格着色器，最终传递给FS。这种方式能更好地利用GPU并行性，且内置同步机制更友好，适合大规模场景。

内容的提问来源于stack exchange，提问作者Avi