Use of `gl_PrimitiveID` in fragment shader should not always imply "Geometry" capability

[DDoS]

According to the SPIR-V specification, gl_PrimitiveID  is available with capabilities

Geometry, Tessellation, RayTracingNV, RayTracingKHR, MeshShadingNV, MeshShadingEXT

But glslang always uses "Geometry".

That means if you driver supports tessellation (or mesh or ray-tracing), but not geometry shaders, you always get a validation error.

vkCreateShaderModule(): SPIR-V Capability Geometry was declared, but one of the following requirements is required (VkPhysicalDeviceFeatures::geometryShader).
The Vulkan spec states: If pCode is a pointer to SPIR-V code, and 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.4.321.0/mac/antora/spec/latest/chapters/shaders.html#VUID-VkShaderModuleCreateInfo-pCode-08740)

Notably this is the case with MoltenVK, which has tessellation but not geometry shaders.

I believe glslang should instead use the "Tessellation" capability by default for fragment shaders, since it's a lot more likely that you have tessellation shaders but not geometry shaders, than of the opposite. Obviously being able to choose would be the best option.

[arcady-lunarg]

Hm, this also seems like a spec question because it does seem perfectly reasonable that a driver not support geometry shaders but does have tessellation or potentially the other way around too so there's no real most general capability here. Since it's possible to use this builtin in a fragment shader, and not all implementations will support it, you definitely need to have some capability here so those shaders can be rejected when not supported. And while maybe it should have been its own capability, doing that now would introduce its own compatibility problems.

[DDoS]

Could this at least be configurable by the user? Maybe a flag set of stage capabilities for the target device, so glslang can pick most appropriate SPIR-V capability?

[arcady-lunarg]

Yeah being able to specify the available stages would be a reasonable option while the SPIR-V working group decides what, if anything, to do with the spec. I will need to think a bit about the best way to accomplish that.

[arcady-lunarg]

@DDoS What are your thoughts on the best way to pass this information into glslang? A compiler pragma in the shader source? A new command line flag?