Remove Block decoration from descriptor heap image wrappers

[Guang-035]

Issue: glslang#4238
Follow-up to: Guang-035@90a0756

Description

For layout(descriptor_heap) image arrays, for example:

layout(descriptor_heap, r32f) writeonly uniform image2D Writes[];
layout(descriptor_heap, r32f) readonly uniform image2D Reads[];

• glslang creates wrapper struct types to carry the NonReadable / NonWritable member decorations. This change removes the incorrect Block decoration from those wrappers because they are not shader interface blocks.
• Remove Block decorations from descriptor heap layout and payload structs

Note: This currently requires a SPIRV-Tools validation update. I opened SPIRV-Tools#6723 for that fix.

[Guang-035]

Hello @arcady-lunarg, based on an offline discussion with @Tobski, the 'Block' decoration should not be added to the heap struct layout or to any SSBO/UBO loaded from the heap.

This PR needs more time to be polished, so please do not review it yet.

[Guang-035]

Hi @Tobski, Descriptor heap layout and payload structs do not require a Block decoration, but they can still contain runtime arrays, which currently triggers VUID-StandaloneSpirv-OpTypeRuntimeArray-04680.

Do you think this validation should be relaxed for this case, or could someone help clarify the intended behavior?

[Tobski]

Hi @Tobski, Descriptor heap layout and payload structs do not require a Block decoration, but they can still contain runtime arrays, which currently triggers VUID-StandaloneSpirv-OpTypeRuntimeArray-04680.

Do you think this validation should be relaxed for this case, or could someone help clarify the intended behavior?

Ooh, I missed this VU, but yes this should be modified. I'll raise an internal MR to fix this, but please do feel free to go ahead and update spirv-val in preparation for that.

[Guang-035]

Hi @Tobski, Descriptor heap layout and payload structs do not require a Block decoration, but they can still contain runtime arrays, which currently triggers VUID-StandaloneSpirv-OpTypeRuntimeArray-04680.
Do you think this validation should be relaxed for this case, or could someone help clarify the intended behavior?

Ooh, I missed this VU, but yes this should be modified. I'll raise an internal MR to fix this, but please do feel free to go ahead and update spirv-val in preparation for that.

I’d like to fix this too, but I’m not sure how we should relax this check. Figuring out whether a struct is used through the descriptor heap path seems a bit complicated. Do you have any suggestions?

[Tobski]

I’d like to fix this too, but I’m not sure how we should relax this check. Figuring out whether a struct is used through the descriptor heap path seems a bit complicated. Do you have any suggestions?

I've put what I think has to be the correct fix in https://gitlab.khronos.org/vulkan/vulkan/-/merge_requests/8263, which is to say the struct must be the direct result of OpBufferPointer. Tracking that might be tricky with untyped pointers though.

[CLAassistant]

All committers have signed the CLA.