The intersection shader reads zeroes out of an SSBO

Question

My intersection shader always reads just zeroes from the SSBO I have. I tried using debugPrintEXT, but it wouldn't print out from within the intersection shader. However, when I try to output any value via the ray payload as the hit colour, all I get is black colour all the time. Initially, I thought there was a problem with how I copied the data, but no, it is all just as good as in the example code, which works (from NVIDIA). Then, the validation layer throws no warnings/errors/nothing. Then I checked in NVIDIA NSight graphics what the buffer has, and it has the data I copied to it, exactly with the layout I wanted. Then I checked the SPIRV instructions, and all of them correctly refer to the offsets of the buffer! I am completely lost now: even the NVIDIA NSight sees the correct values but not the shader!

So, here is the shader code:

// 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;
}

Here is the layout of the structure in 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],
}

The total byte size of the struct is 44 bytes. Aligning to a multiple of 16 results in 48 bytes copy when moving the data from the temporary CPU buffer to the GPU buffer. Here is the screenshot of NVIDIA NSight, which proves the shader must have the data: Here in the screenshot of NSight, the values are exactly the ones I have in Rust. And here is the shader's 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

I don't get what is wrong. I tried to play with padding, but it just didn't help, nothing helped with regard to memory alignment. Even so, if it was an alignment issue, I think the shader should have accessed the values, at least the first ones, as those are laid out properly anyway.

Update: it seems that my closest hit shader doesn't even work when the read is performed to the buffer!

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);
  }

Here, neither of the branch sections is walked into! The "payload" is not set entirely, so the colour I see is pitch black. However, if I don't try to access the "material" buffer and read values out of it, or just put an assignment to the "payload" after these if-elses, the colour I assign is visible:

  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);

Besides that, if I set the colour first to that, before the branching, the colour is black again, as if the payload wasn't set!

  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 I leave just one if and check for whatever number, it is always evaluated to true. Do I see some UB?

Another screenshot from the NSight showing that the buffer is correctly laid out, bound to the hit shader correctly as well:

My current guess is that the shader binding table isn't properly set up for the hit shader. But then I don't understand why it is even invoked then.

To whoever decided to vote for closing: The reproduction steps must be clear to everyone who knows vulkan and rust and glsl: use a GPU buffer of the desired type. The NSight proves that it is done correctly, so this of the MCVE is unnecessary. The only thing not working correctly here is the shader, and the code for it serves as MCVE. The desired behaviour is obvious - the data should be read as it is in the buffer instead of zeroes all the time. If you have any questions - ask, don't vote for closing unless it is clear to you. Even if you are sure, notify the author about that instead of silently voting. People may provide any sort of information if asked, but I have already provided all the necessary information.

Answer 1

Then I checked the SPIRV instructions, and all of them correctly refer to the offsets of the buffer!

No, they don't. Look at the SPIR-V, but this time with the corresponding members annotated:

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;

Indeed, if you just look at offset 9, you can see that it is an 80-byte structure, not 48 bytes as your Rust code suggests.

Things get off-track at color, which is at offset 32, not 28 as it is in Rust. This is because std430 layout (the default for buffer blocks) requires that vec4 is always aligned to 16 bytes. Same goes for reserved_2 relative to reserved_1.

I highly suspect that you meant to do this:

  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.

Along with the Rust equivalent. This would actually be 48 bytes in size.

Answer 2

I solved the problem. There were actually two problems. One was the alignment issue - the colour vector was expected to be indeed at the offset of 32 bytes from the beginning of the chunk, as it was pointed out by @Nicol Bolas. However, this was rather a minor problem. A much larger problem was with the shader binding table. As you can see on my last screenshot in the question, there is no hit shader assigned to the shader binding table. This was a huge problem to debug as all the data is copied out just as correctly as it may get in my code, and the problem was not in how the data is copied to the SBT buffer but rather how the shader groups are created. In the book "Ray Tracing Gems II" it is said that the order of shaders for which we create shader groups doesn't matter. Well, on my machine, it is wrong. First of all, as NVIDIA NSight showed, I had no hit shader attached. Second of all, my miss shader was with index "1" in the group "2", which certainly was odd compared to other applications where the order of indexes and groups is always the same:

• Ray generation shader group.
• Miss shader group.
• Hit shader group.

Having read in the book that the order didn't matter, I changed the order of the shader groups I created: the second was the hit shader group instead of the miss shader group as everywhere else.

As a Vulkan ray-tracing learner, I should point out that this quote from the Ray Tracing Gems II (page 251) book might be misinterpreted:

...First, there is no ordering requirement with respect to shader types in the SBT; ray generation, hit, and miss groups can come in any order.

I interpreted it so that we also don't care how to create the shader groups as well. It seems like the shader records for the shader groups are always in the order of ray generation, miss and then hit groups and the order matters when we create the groups themselves for the ray tracing pipeline.

One piece of advice for people having the same odd behaviour of shaders while using ray tracing pipeline and shader binding tables: if your shader behaves oddly (producing weird behaviour), even if it is invoked, or when you try to access any data except for the data passed between the shader stages, it is highly likely that the problem is with the shader binding table. Within the same book (Ray Tracing Gems II), it is pointed out that creating/using the SBT and the data for it is quite often done wrong and is a frequent cause of problems.