search

KhronosGroup / GLSL

GLSL Shading Language Issue Tracker
324 stars 96 forks source link

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

Open n9H07 opened 1 week ago

n9H07 commented 1 week ago

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_COMPUTEBIT): 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?