Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Usage of any fields of gl_MeshPrimitivesEXT is enabling capability FragmentShadingRateKHR even if gl_PrimitiveShadingRateEXT is not used #3103

Closed
zeux opened this issue Jan 3, 2023 · 2 comments · Fixed by #3298
Closed

Usage of any fields of gl_MeshPrimitivesEXT is enabling capability FragmentShadingRateKHR even if gl_PrimitiveShadingRateEXT is not used #3103

zeux opened this issue Jan 3, 2023 · 2 comments · Fixed by #3298
Assignees
@greg-lunarg
Labels
bug GLSL/ESSL SPIR-V

Comments

@zeux
Copy link
Contributor

zeux commented Jan 3, 2023

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)
@greg-lunarg greg-lunarg self-assigned this Jan 5, 2023
@greg-lunarg
Copy link
Contributor

@pmistryNV Can you please take a look?

@pmistryNV
Copy link
Contributor

@pmistryNV Can you please take a look?

I will look into it next week. Sorry for the delay.

@zeux zeux mentioned this issue Aug 6, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@greg-lunarg greg-lunarg

Labels
bug GLSL/ESSL SPIR-V
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix interaction between GL_EXT_mesh_shader and GL_EXT_fragment_shading_rate
3 participants
@zeux @greg-lunarg @pmistryNV