Define std430 layout of struct referenced by pointer in push constant

[SeanOMik]

I'm wondering if there's a way to set the layout of a struct. I have the following in my shader:

struct Light {
    float4 position_enabled_packed;
    float4 direction_light_type_packed;
    float4 color;
    float range;
    float intensity;
    float smoothness;
    float spot_cutoff;
    float spot_outer_cutoff;
    int light_shadow_uniform_index[6];
}

struct Lights {
    uint light_count;
    Light data[];
}

struct PushConstants {
    Lights *lights;
}

[vk::push_constant] PushConstants pcs;

I believe that the Lights struct is using std140 after some debugging. I also found out on google that 140 is the default for things other than the storage buffers.

I attempted to add layout(std430) on PushConstants definition:

[vk::push_constant] layout(std430) PushConstants pcs

But that made no change, so I'm assuming it only applies to the PushConstants struct.

Is there a way to set the Lights struct to be std430? I couldn't find anything online about it

[expipiplus1]

mm, for the spirv backend push constants should use the glsl430 layout by default. I assume you're using the glsl backend? The SPIRV backend is recommended, however you might want to try -fvk-use-gl-layout or -force-glsl-scalar-layout?

[SeanOMik]

I do have the compile target set to SPIRV, but I did notice that my profile for the session was glsl_450. I switched it to spirv_1_6 which I found here, but now I think its using scalar, even though I do not have -force-glsl-scalar-layout set.

I checked the buffer in renderdoc, and set the layout to std430, and all the data looks good. When I change the code to send data in scalar layout to the gpu it does look fine. I tried to enable -fvk-use-gl-layout, but it also doesn't appear to have any effect on the format the GPU uses. I also saw these validation errors:

(VALIDATION) vkCreateShaderModule(): pCreateInfo->pCode (spirv-val produced an error):
Structure id 15 decorated as Block for variable in PhysicalStorageBuffer storage class must follow relaxed storage buffer layout rules: member 0 contains an array with stride 12 not satisfying alignment to 16
This is may be allowed if you enable the scalarBlockLayoutfeature feature (or use the --scalar-block-layout command line flag)
  %_MatrixStorage_float3x3_ColMajornatural = OpTypeStruct %_arr_v3float_int_3
The Vulkan spec states: If pCode is a pointer to SPIR-V code, pCode must adhere to the validation rules described by the Validation Rules within a Module section of the SPIR-V Environment appendix (https://docs.vulkan.org/spec/latest/chapters/shaders.html#VUID-VkShaderModuleCreateInfo-pCode-08737)

I would prefer to use std430 since it plays nicer with my host language. I'm using rust, so when I pack the struct to make its memory layout the exact same as C (with repr(C, packed)), it makes it impossible to reference fields of a struct.

[expipiplus1]

mm, in this case I suggest you open an issue with a minimal reproducer for what you expect and we can work on fixing this, or at least improving documentation to improve expectations

[SeanOMik]

Okay, when I have the time I will make a minimal reproducible example. I haven't used C++ in a while, so it will take a bit of time

[juliusikkala]

I've recently worked on code related to layouts in the compiler; I think the issue is that in the SPIR-V emitter, when accessing a structure through a pointer (Lights *lights;), the layout is just pretty much always the "natural layout" (= scalar layout). There's not many ways to change that on a per-buffer basis, AFAIK only the global flags (-fvk-use-*-layout) affect this.

This is a difficult problem because the layout cannot be inherited from the buffer to the pointer:

struct Data {
    Lights *lights;
}

StructuredBuffer<Data, ScalarDataLayout> b1;
StructuredBuffer<Data, Std430DataLayout> b2;

void main()
{
    Lights* lights;

    if(foo) lights = b1[0].lights;
    else lights = b2[0].lights;
    
    // Which layout should be used here?
    lights->light_count;
}

So the options I can see for "fixing" this are:

• Allow controlling pointer layout with compiler parameters (current situation, IMO not great)
• Allow setting a default layout per-struct (probably doesn't mesh well with current per-buffer layouts, may lead to confusion)
• Add yet another parameter to the Ptr<T> type that denotes the layout (clean but probably annoyingly verbose)