spirv-val: Validate PhysicalStorageBuffer Stage Interface

[spencer-lunarg]

re-attempt at #5539 (which was reverted in #5575)

Going to first fix GLSL to not generate invalid SPIR-V

[spencer-lunarg]

Will rebase when KhronosGroup/glslang#3878 in pulled in

[spencer-lunarg]

@alan-baker sorry I am not able to get on the SPIRV WG calls, but not sure if this was discussed

The only reason this was reverted before is because glslang had a single test using it, but not sure if you have opinions on why this should be allowed (since it has a proper VU in the Vulkan Spec even)

[alan-baker]

I guess why it would be supported would be what's the difference between converting the pointer to 64-bit int passing it between stages and converting back vs just passing the pointer?

[spencer-lunarg]

vs just passing the pointer?

The issue is it opens up a large can of worms for how Location works and https://gitlab.khronos.org/vulkan/vulkan/-/issues/3677 we decided that we didn't want to spec it out and just ban things and that is how we got here (also it seems from talking to Baldur, this doesn't actually work everywhere and he had an issue with RenderDoc on it https://gitlab.khronos.org/spirv/SPIR-V/-/issues/779#note_517142)

[alan-baker]

vs just passing the pointer?

The issue is it opens up a large can of worms for how Location works and https://gitlab.khronos.org/vulkan/vulkan/-/issues/3677 we decided that we didn't want to spec it out and just ban things and that is how we got here (also it seems from talking to Baldur, this doesn't actually work everywhere and he had an issue with RenderDoc on it https://gitlab.khronos.org/spirv/SPIR-V/-/issues/779#note_517142)

I'm not sure what the problem for location is? Those pointers are basically 64-bit values. Vulkan can ban it, but it feels like working around implementation bugs. That may be the best choice though.

[spencer-lunarg]

I'm not sure what the problem for location is?

So can the Vertex output a Pointer and the Fragment consume a uint64_t/vec2

but it feels like working around implementation bugs.

I think it is less of a bug and just that it was never described in the spec when Buffer Device Address was added and there was one CTS test, so it really lacks coverage and goes back to my "if people want it, they should test it" but I don't see why we should encourage the use of untested features in Vulkan, ones that have been found already to cause issues elsewhere

[alan-baker]

I'm not sure what the problem for location is?

So can the Vertex output a Pointer and the Fragment consume a uint64_t/vec2

Theoretically yes, but...

but it feels like working around implementation bugs.

I think it is less of a bug and just that it was never described in the spec when Buffer Device Address was added and there was one CTS test, so it really lacks coverage and goes back to my "if people want it, they should test it" but I don't see why we should encourage the use of untested features in Vulkan, ones that have been found already to cause issues elsewhere

Yes, pragmatically speaking, banning is probably best.