Inconsistent validation when using scalar struct layout (GLSL) in buffer_reference

[M2-TE]

Environment:

• OS: Fedora 40
• GPU and driver version: NVIDIA RTX 4070 Ti Super, proprietary 550.78
• SDK or header version if building from repo: vulkan-validation-layers 1.3.280.0
• Options enabled (synchronization, best practices, etc.):

Describe the Issue

Enabling GL_EXT_scalar_block_layout without enabling VK_EXT_scalar_block_layout feature in vulkan 1.2 does not consistently warn about the latter when using scalar layout for a struct in combination with GL_EXT_buffer_reference and using members with non-power-of-two alignment (mat3x3, vec3). VK_KHR_dynamic_rendering is used to construct the graphics pipeline.

Expected behavior

Upon construction of a graphics pipeline using VK_KHR_dynamic_rendering and shaders containing buffer references with scalar layout structs without power-of-two alignment in members (not total struct size), validation layers should consistently report the lack of VK_EXT_scalar_block_layout should it not be enabled for the current device.

Valid Usage ID No other validation errors

Additional context Device buffer reference used to (sometimes) trigger the validation error upon pipeline construction when VK_EXT_scalar_block_layout feature/extension is not enabled:

``` #version 460 #extension GL_EXT_buffer_reference : require #extension GL_EXT_scalar_block_layout : require ... struct Transform { mat3x3 rotScaMatrix; // 0, 36 vec3 pos; // 36, 12 vec3 pos_err; // 48, 12 float padding; // 60, 4 }; layout(scalar, buffer_reference, buffer_reference_align = 64) readonly buffer Transforms { Transform transforms[]; }; layout(std430, push_constant) uniform PushConstant { Transforms pTransforms; }; ... main() { Transform transform = pTransforms.transforms[gl_InstanceIndex]; } ```

Shader compiled using:

```sh glslangValidator -V input -o output ```

Validation Error that would sometimes appear:

``` Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-08737 ] | MessageID = 0xa5625282 | vkCreateShaderModule(): pCreateInfo->pCode (spirv-val produced an error): Structure id 14 decorated as Block for variable in PhysicalStorageBuffer storage class must follow relaxed storage buffer layout rules: member 0 is a matrix with stride 12 not satisfying alignment to 16 %Transform_0 = OpTypeStruct %mat3v3float %v3float %float %v3float . 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://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkShaderModuleCreateInfo-pCode-08737) ```

[spencer-lunarg]

so as background, this logic is all done in SPIRV-Tools (via spirv-val) and the validations layers call

    if (enabled_features.scalarBlockLayout == VK_TRUE) {
        // --scalar-block-layout
        options.SetScalarBlockLayout(true);
    }

so the --scalar-block-layout is passed into spirv-val depending if scalarBlockLayout feature was enabled or not

[spencer-lunarg]

So if I take this glsl example and run spirv-val --target-env vulkan1.0 out.spv I get the same error

but if I run with

spirv-val --target-env vulkan1.0 out.spv --scalar-block-layout

I don't get the error anymore

[spencer-lunarg]

awwww, I think I know the issue now, I was able to reproduce this behaviour because of we do shader caching, so if you go

export VK_LAYER_DISABLES=VK_VALIDATION_FEATURE_DISABLE_SHADER_VALIDATION_CACHE_EXT

it will work as expected... so we need to hashing depending on the settings such as scalarBlockLayout