Does the Vulkan SPIR-V and API version need to match?

[bashbaug]

From a review comment, see: #2536 (review)

I don't have a very strong opinion about this, but I think it should be fine to invoke glslang and target the older SPIR-V environment, and it would only be a problem to target a newer SPIR-V environment.

Is a validation layer complaining about a mismatch, or is there something else that prompted this change?

Basically, does the Vulkan SPIR-V version need to match the Vulkan API version? If not, is the PR masking some other issue?

[bashbaug]

CC @dcrawleyqti , who created PR #2536.

[dcrawleyqti]

Thanks for opening this Ben. My cursory knowledge of Vulkan led me to believe that the issue was as simple as test env and api versioning needing to match. I'm in internal conversations with our Vulkan folks to dive deeper and will share my findings here once I get more info.

[dcrawleyqti]

I believe the issue boils down to the SPIRV capabilities used in the test. If you generate buffer.spv with a target env of vulkan 1.0, and then disassemble the shader file, it uses OpCapability Int8 and UniformAndStorageBuffer8BitAccess. Those capabilities are not standard Vulkan 1.0 features (https://vulkan.lunarg.com/doc/view/1.4.304.1/windows/antora/spec/latest/appendices/spirvenv.html)

When I instead generate buffer.spv with a target env of vulkan 1.1, it uses Int8 and StorageBuffer8BitAccess. They are also not standard Vulkan 1.1 features, but happen to be supported by our target device via optional extensions (VkKhrShaderFloat16Int8 and VkKhr8BitStorage).

Ideally, the vulkan test should be checking physical device features before creating these shaders, to confirm support. Alternatively we could stick to using capabilities that are standard for Vulkan 1.0 or 1.1.