相交着色器从 SSBO 中读取零

Question

我的相交着色器总是从我拥有的 SSBO 中读取零。 我尝试使用debugPrintEXT ，但它不会从相交着色器中打印出来。 但是，当我尝试通过光线有效载荷将 output 任何值作为命中颜色时，我得到的始终是黑色。 最初，我认为我复制数据的方式有问题，但没有，它和示例代码一样好，它可以工作（来自 NVIDIA）。 然后，验证层不会抛出警告/错误/什么都没有。 然后我在 NVIDIA NSight 图形中检查缓冲区有什么，它有我复制到它的数据，完全符合我想要的布局。 然后我检查了 SPIRV 指令，它们都正确地引用了缓冲区的偏移量：我现在完全迷失了：即使是 NVIDIA NSight 也看到了正确的值，但着色器却看不到！

所以，这是着色器代码：

// Hitting a triangle.
#version 460 core
#extension GL_EXT_ray_tracing : enable

layout(location = 0) rayPayloadInEXT vec4 payload;
hitAttributeEXT vec2 attributes;
layout(push_constant) uniform rayParams {
  vec3 rayOrigin;
  vec3 rayDir;
  mat4 transformMatrix;
  float maxDistance;
};
struct PhongMaterial {
  float ambient;
  float diffuse;
  float specular;
  float shininess;
  float reflective;
  float transparency;
  float refraction;
  vec4 color;
  float reserved_1;
  vec4 reserved_2;
};

layout(set = 0, binding = 2) readonly buffer Materials {
  PhongMaterial m[];
}
materials;

void main() {
  PhongMaterial material = materials.m[0];
  payload = material.color;
}

这是 Rust 中结构的布局：

#[repr(C)]
pub struct PhongMaterial {
    pub ambient: f32,
    pub diffuse: f32,
    pub specular: f32,
    pub shininess: f32,
    pub reflective: f32,
    pub transparency: f32,
    pub refraction: f32,
    pub color: ColorRGBA,
    reserved: [u8; 20],
}

该结构的总字节大小为 44 字节。 当将数据从临时 CPU 缓冲区移动到 GPU 缓冲区时，对齐到 16 的倍数会导致复制 48 字节。 这是 NVIDIA NSight 的屏幕截图，证明着色器必须具有数据： 在 NSight 的屏幕截图中，值正是我在 Rust 中的值。这是着色器的 SPIRV：

OpName %58 "PhongMaterial"
OpMemberDecorate %58 0 Offset 0
OpMemberDecorate %58 1 Offset 4
OpMemberDecorate %58 2 Offset 8
OpMemberDecorate %58 3 Offset 12
OpMemberDecorate %58 4 Offset 16
OpMemberDecorate %58 5 Offset 20
OpMemberDecorate %58 6 Offset 24
OpMemberDecorate %58 7 Offset 32
OpMemberDecorate %58 8 Offset 48
OpMemberDecorate %58 9 Offset 64

我不明白哪里出了问题。 我试着玩填充，但它没有帮助，关于 memory alignment 没有任何帮助。即便如此，如果这是一个 alignment 问题，我认为着色器应该访问值，至少是第一个值，因为无论如何，这些都布置得很好。

更新：当对缓冲区执行读取时，我的最近命中着色器似乎甚至无法工作！

void main() {
  PhongMaterial material = materials.m[0];
  if (material.ambient <= 0.1) {
    payload = vec4(1.0, 0.0, 0.0, 1.0);
  } else if (material.ambient <= 0.5) {
    payload = vec4(0.0, 1.0, 0.0, 1.0);
  } else {
    payload = vec4(0.0, 0.0, 1.0, 1.0);
  }

在这里，没有走进任何一个分支部分，“有效载荷”没有完全设置。 所以我看到的颜色是黑色的，但是，如果我不尝试访问“材料”缓冲区并从中读取值，或者只是在这些 if-elses 之后对“有效负载”进行赋值：我的颜色分配可见：

  if (material.ambient <= 0.1) {
    payload = vec4(1.0, 0.0, 0.0, 1.0);
  } else if (material.ambient <= 0.5) {
    payload = vec4(0.0, 1.0, 0.0, 1.0);
  } else {
    payload = vec4(0.0, 0.0, 1.0, 1.0);
  }
  payload = vec4(1.0, 1.0, 0.0, 1.0);

除此之外，如果我首先将颜色设置为那个颜色，在分支之前，颜色又是黑色的，就好像没有设置有效负载一样！

  payload = vec4(1.0, 1.0, 0.0, 1.0);
  if (material.ambient <= 0.1) {
    payload = vec4(1.0, 0.0, 0.0, 1.0);
  } else if (material.ambient <= 0.5) {
    payload = vec4(0.0, 1.0, 0.0, 1.0);
  } else {
    payload = vec4(0.0, 0.0, 1.0, 1.0);
  }

如果我只留下一个 if 并检查任何数字，它总是被评估为真。 我看到一些UB了吗？

NSight 的另一个屏幕截图显示缓冲区的布局正确，也正确绑定到命中着色器：

我目前的猜测是没有为命中着色器正确设置着色器绑定表。 但后来我不明白为什么它会被调用。

对于决定投票关闭的人：每个了解 vulkan 和 rust 和 glsl 的人都必须清楚复制步骤：使用所需类型的 GPU 缓冲区。 NSight 证明它是正确完成的，所以 MCVE 的这个是不必要的。 这里唯一不能正常工作的是着色器，它的代码用作 MCVE。 所需的行为是显而易见的——数据应该按缓冲区中的原样读取，而不是始终为零。 如果您有任何问题 - 提出，除非您清楚，否则不要投票赞成结束。 即使你确定，也要通知作者而不是默默地投票。 人们可能会根据要求提供任何类型的信息，但我已经提供了所有必要的信息。

Answer 1

然后我检查了 SPIRV 指令，它们都正确地引用了缓冲区的偏移量！

不，他们没有。 查看 SPIR-V，但这次对相应的成员进行了注释：

OpName %58 "PhongMaterial"
OpMemberDecorate %58 0 Offset 0 ;  float ambient;
OpMemberDecorate %58 1 Offset 4 ;  float diffuse;
OpMemberDecorate %58 2 Offset 8 ;  float specular;
OpMemberDecorate %58 3 Offset 12 ;  float shininess;
OpMemberDecorate %58 4 Offset 16 ;  float reflective;
OpMemberDecorate %58 5 Offset 20 ;  float transparency;
OpMemberDecorate %58 6 Offset 24 ;  float refraction;
OpMemberDecorate %58 7 Offset 32 ;  vec4 color;
OpMemberDecorate %58 8 Offset 48 ;  float reserved_1;
OpMemberDecorate %58 9 Offset 64 ;  vec4 reserved_2;

事实上，如果你只看偏移量 9，你会发现它是一个80 字节的结构，而不是 Rust 代码所建议的 48 字节。

事情在color处偏离轨道，它位于偏移量 32，而不是 Rust 中的 28。这是因为std430布局（ buffer块的默认设置）要求vec4始终对齐到 16 字节。 reserved_2相对于reserved_1也是如此。

我高度怀疑你打算这样做：

  float ambient;
  float diffuse;
  float specular;
  float shininess;
  float reflective;
  float transparency;
  float refraction;
  float reserved_1; // Padding before the `vec4`
  vec4 color;
  //vec4 reserved_2; No need for this at all.

以及等效的 Rust。 这实际上是 48 个字节的大小。

Answer 2

我解决了这个问题。 实际上有两个问题。 一个是 alignment 问题——正如@Nicol Bolas 所指出的那样，颜色向量预计确实位于距块开头 32 个字节的偏移处。 然而，这是一个相当小的问题。 一个更大的问题是着色器绑定表。 正如您在问题中的最后一个屏幕截图中看到的那样，没有为着色器绑定表分配命中着色器。 这是一个调试的大问题，因为所有数据都被复制出来，就像它在我的代码中可能得到的一样正确，问题不在于如何将数据复制到 SBT 缓冲区，而是如何创建着色器组。 在“Ray Tracing Gems II”一书中说，我们为其创建着色器组的着色器顺序无关紧要。 好吧，在我的机器上，这是错误的。 首先，正如 NVIDIA NSight 显示的那样，我没有附加命中着色器。 其次，我错过的着色器在组“2”中的索引为“1”，这与索引和组的顺序始终相同的其他应用程序相比肯定很奇怪：

• 光线生成着色器组。
• 着色器组小姐。
• 命中着色器组。

在书中读到顺序无关紧要后，我更改了我创建的着色器组的顺序：第二个是命中着色器组，而不是像其他地方一样未命中着色器组。

作为 Vulkan 光线追踪学习者，我应该指出，Ray Tracing Gems II（第 251 页）书中的这句话可能会被误解：

...首先，SBT 中的着色器类型没有排序要求； 射线生成、命中和未命中组可以按任何顺序出现。

我对其进行了解释，以便我们也不关心如何创建着色器组。 似乎着色器组的着色器记录总是按照光线生成、未命中和命中组的顺序排列，当我们为光线追踪管线创建组时，顺序很重要。

对于在使用光线追踪管道和着色器绑定表时具有相同的着色器奇怪行为的人的一条建议：如果您的着色器行为奇怪（产生奇怪的行为），即使它被调用，或者当您尝试访问除以下内容之外的任何数据时着色器阶段之间传递的数据，很可能问题出在着色器绑定表上。 在同一本书（Ray Tracing Gems II）中，指出创建/使用 SBT 和它的数据经常做错并且是问题的常见原因。