I am currently working on adding support for different structure decorators in SPIRV dialect, while doing so I noticed that the current test set includes cases where there is not offset attached to the structure member, something like that:
// CHECK: !spv.ptr<!spv.struct<f32 [NonWritable], i32 [NonWritable, NonReadable]>, StorageBuffer>
spv.globalVariable @var5 : !spv.ptr<!spv.struct<f32 [NonWritable], i32 [NonWritable, NonReadable]>, StorageBuffer>
My understanding from the SPIRV specification Validation Rules is that every structure member should have an offset decorator.
Can someone explain to me why such a behavior (no offset) is acceptable as shown in the aforementioned test case?
Hey @hazem, I explained a bit in SPIRV binary to MLIR hello world example. For non-external storage classes, the struct does not need to be explicitly laid out. But here we are having an interface storage class, so they should be laid out… if thinking about
Shader capability (which is Vulkan’s environment). This is another nuanced point here: if you read the spec, the requirements to have the layout is under “2.16.2. Validation Rules for Shader Capabilities”. In other words, if the module is for
Kernel capability (which is OpenCL), there is no such requirements. The SPIR-V dialect is intended to support both by design (although we only cover
Shader side for now). So we are not enforcing the layout rules on the type itself because that will exclude the case for
Kernels. So techically this is okay. But if you’d like to make it laid out that’s fine too. We are lacking a verification for this rule. I think it makes sense to have this check on
spv.module if the module declares
Shader capability and then we can check all interface struct types are laid out.
I see. This makes the change I intended less straightforward than I imagined I will think about it and get back to you if I have any questions, I appreciate your help!