Weird Storage Buffer Data Issues

Vulkan
1

So im making an openXR vulkan app, followed official OpenXR tutorial, then started extending it. I started by adding a storage buffer and doing some vkDrawInstancedIndirect work. It worked fine and everything was as expected. This was on Quest Pro, then I tried on Quest 3 and it the shader seemed completely broken, nothing using that shader rendered. Eventually from a lot of trial and error, I found that in c++ when i put data in element 2 of the buffer, it would end up in element 1 in the shader’s buffer - it’s as if when it got to the shader it changed everything from uint32_t to 64. So for every 2 elements i inserted in the c++ side, they would get combined into a single 64 bit element in the shader.

I checked all extensions i was using and the quest 3 supported them all, my shader didnt use any extension to enable 64 bit variables or anything like that… worked on one device and not the other - cant for the life of me work out why… anyone got any idea…?

2

You need to layout the data correctly in C++ side. And that must match the layout on the shader side.

Considering you’re using GLSL to write shaders. Shader Storage buffer uses std430 by default when targeting SPIR-V (vulkan). So, you must layout the data in std430 on the C++ side.

May I see the definition of your buffer interface in GLSL?

3

Thats one of the things i tried, testing the device limit said the minimum alignment was 64, so i did:

struct AlignedData {
    uint element[16];
};

layout (std430, binding = 0) readonly buffer BufferBlock {//readonly
    AlignedData data[];
};

and I accessed it with

(data[gl_InstanceIndex / 16]).element[gl_InstanceIndex % 16];
4

I think more context is needed such as the host code highlighting how you’re laying out the data to the GPU side SSBO. That is more likely to cause such bugs.