Usage of any fields of gl_MeshPrimitivesEXT is enabling capability FragmentShadingRateKHR even if gl_PrimitiveShadingRateEXT is not used #3103
Description
You can see this bug in glslang's own test suite:
./Test/spv.ext.meshShaderBuiltins.mesh source file uses gl_MeshPrimitivesEXT but does not use gl_PrimitiveShadingRateEXT field in that array of structures. Despite that, the output for that test (./Test/baseResults/spv.ext.meshShaderBuiltins.mesh.out) starts with:
spv.ext.meshShaderBuiltins.mesh
// Module Version 10400
// Generated by (magic number): 8000b
// Id's are bound by 158
Capability ClipDistance
Capability CullDistance
Capability FragmentShadingRateKHR
Capability DrawParameters
Capability MultiView
Capability MeshShadingEXT
Extension "SPV_EXT_mesh_shader"
Extension "SPV_KHR_fragment_shading_rate"
Out of these, all capabilities other than FragmentShadingRateKHR are expected, as the shader does fill them. It looks like glslang's SPV output calls TGlslangToSpvTraverser::decorateStructType whenever the variable of that type is being written to at all, but doesn't filter out members that were never used in the shader, and as such we get FragmentShadingRateKHR capability.
The reason why this is a problem is that this results in a further validation layer error when loading the shader, assuming VK_KHR_fragment_shading_rate is not used:
VUID-VkShaderModuleCreateInfo-pCode-01091(ERROR / SPEC): msgNum: -1480880714 - Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-01091 ] Object 0: handle = 0x55555606d9f0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xa7bb8db6 | vkCreateShaderModule(): The SPIR-V Capability (FragmentShadingRateKHR) was declared, but none of the requirements were met to use it. The Vulkan spec states: If pCode declares any of the capabilities listed in the SPIR-V Environment appendix, one of the corresponding requirements must be satisfied (https://vulkan.lunarg.com/doc/view/1.3.236.0/linux/1.3-extensions/vkspec.html#VUID-VkShaderModuleCreateInfo-pCode-01091)