Skip to content

Using a specialization constant as a size of an array placed inside a buffer results in a runtime error #239

@ghost

Description

The following is working:

layout(binding=0)buffer _{mat4 b[52*3];V v[];};

The following compiles successfully but fails at runtime:

layout(constant_id=0)const uint n=52;
layout(binding=0)buffer _{mat4 b[n*3];V v[];};

Error message:

VUID-VkPipelineShaderStageCreateInfo-pSpecializationInfo-06849(ERROR / SPEC):
msgNum: 1132206547 - Validation Error: [ VUID-VkPipelineShaderStageCreateInfo-pSpecializationInfo-06849 ] | MessageID = 0x437c19d3 |
vkCreateComputePipelines(): pCreateInfos[0].stage After specialization was applied, VkShaderModule 0x0[] produces a spirv-val error (stage VK_SHADER_STAGE_COMPUTE_BIT):
Structure id 16 decorated as Block for variable in StorageBuffer storage class must follow relaxed storage buffer layout rules: member 1 at offset 64 overlaps previous member ending at offset 2147493631
%_ = OpTypeStruct %_arr_mat4v4float_uint_2248147100 %_runtimearr_V
The Vulkan spec states: If a shader module identifier is not specified, the shader code used by the pipeline must be valid as described by the Khronos SPIR-V Specification after applying the specializations provided in pSpecializationInfo, if any, and then converting all specialization constants into fixed constants (https://vulkan.lunarg.com/doc/view/1.3.283.0/windows/1.3-extensions/vkspec.html#VUID-VkPipelineShaderStageCreateInfo-pSpecializationInfo-06849)
Objects: 0

I have read the specification:

Changing the specialized size will not re-layout the block.

Why not? Isn't spirv meant to replace the traditional method of generating and compiling glsl during runtime?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions