KhronosGroup / SPIRV-Tools

Apache License 2.0
1.05k stars 549 forks source link

spirv-opt: VK_EXT_scalar_block_layout is not supported properly #3153

Open tomilov opened 4 years ago

tomilov commented 4 years ago

The following shader pathtrace.rchit.glsl

#extension GL_EXT_scalar_block_layout : require

layout(scalar, set=DSRender, binding=BindingRdSeqBuffer) uniform UBO {
  uint rd_seq[1056];
} ubo;

void main() {
  if (ubo.rd_seq[1] != 2447445414u) {
    return;
  }
  if (ubo.rd_seq[1055] != 2159022709u) {
    return;
  }
}

compiled by glslangValidator -g -V pathtrace.rchit.glsl -o pathtrace.rchit.debug.spv. Output is to be optimized as spirv-opt -O pathtrace.rchit.debug.spv -o pathtrace.rchit.spv, but the following error is occured:

/home/user/Projects/render/shaders/pathtrace.rchit.glsl
error: line 1046: Structure id 2601 decorated as Block for variable in Uniform storage class must follow standard uniform buffer layout rules: member 0 contains an array with stride 4 not satisfying alignment to 16
  %UBO = OpTypeStruct %_arr_uint_uint_1056

As I can see --scalar-block-layout is the option of spirv-val, not spirv-opt. So I can't tell to spirv-opt that extension is enabled.

tomilov commented 4 years ago

My workaround is to replace spirv-opt invocation to spirv-opt --skip-validation then spirv-val --scalar-block-layout. But now I see noisy warning from validation layers:

vkDebug: Validation: 0:  [ UNASSIGNED-CoreValidation-Shader-InconsistentSpirv ] Object: VK_NULL_HANDLE (Type = 0) | SPIR-V module not valid: Structure id 2601 decorated as Block for variable in Uniform storage class must follow relaxed uniform buffer layout rules: member 0 contains an array with stride 4 not satisfying alignment to 16
  %_struct_2601 = OpTypeStruct %_arr_uint_uint_1056
sfricke-samsung commented 4 years ago

I was looking into the --scalar-block-layout stuff right now, my question is why can't the core SPIR-V tools just detect the present of #extension GL_EXT_scalar_block_layout and enabled it then, why is there even a need for a flag as other extensions don't need to be opt'ed in like this

fu5ha commented 3 years ago

I was looking into the --scalar-block-layout stuff right now, my question is why can't the core SPIR-V tools just detect the present of #extension GL_EXT_scalar_block_layout and enabled it then, why is there even a need for a flag as other extensions don't need to be opt'ed in like this

AFAICT, it's because this extension doesn't make any modification to the spir-v itself, the limitation being lifted is within the vulkan implementation. Sure would be nice to have an extension flag to set in the spirv to indicate that we want to make use of that though.

khyperia commented 3 years ago

I believe this issue was fixed by https://github.com/KhronosGroup/SPIRV-Tools/pull/3314, which added the --scalar-block-layout flag to spirv-opt