-
Notifications
You must be signed in to change notification settings - Fork 569
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.
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
Add EXT_mesh_shader validation support #5640
Add EXT_mesh_shader validation support #5640
Conversation
fdd61c9
to
7e583d0
Compare
@spencer-lunarg kindly review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try to do a deep review soon, but some small nits from a quick scan
The existing logic from VK_NV_mesh_shader was incorrectly adapted for the VK_EXT_mesh_shader implementation when it comes to the handling of mesh payloads as in/out variables. Because TaskPayloadWorkgroupEXT must be applied to a single global OpVariable for each Task/Mesh shader, the struct should not be flattened. Further, as far as I can tell, Location assignment is not necessary for these input and output variables, so the usual reason for flattening structs does not apply. This change now removes the inner struct member global variables and ensures the parent payload is decorated with TaskPayloadWorkgroupEXT. Note that for amplification/task shaders, the payload variable is created with the groupshared decl, and then it's storage class needs to be updated when that variable is used as a parameter to the DispatchMesh call, as described in: https://docs.vulkan.org/spec/latest/proposals/proposals/VK_EXT_mesh_shader.html#_hlsl_changes Tested with updated spirv-val from: KhronosGroup/SPIRV-Tools#5640 Fixes microsoft#5981
) The existing logic from `VK_NV_mesh_shader` was incorrectly adapted for the `VK_EXT_mesh_shader` implementation when it comes to the handling of payloads as in/out variables. Because `TaskPayloadWorkgroupEXT` must be applied to a single global `OpVariable` for each task/mesh shader, the struct should not be flattened. Further, Location assignment is not necessary for these input and output variables, so the usual reason for flattening structs does not apply. This change now removes the inner struct member global variables and ensures the parent payload is decorated with `TaskPayloadWorkgroupEXT`. Note that for amplification/task shaders, the payload variable is created with the `groupshared` decl, and then its storage class needs to be updated when that variable is used as a parameter to the `DispatchMesh` call, as described in: https://docs.vulkan.org/spec/latest/proposals/proposals/VK_EXT_mesh_shader.html#_hlsl_changes Tested with new validation checks from: KhronosGroup/SPIRV-Tools#5640 Fixes #5981
@pmistryNV any update on the changes for this PR? |
Any updates on when this might be completed? I'm adding VK_EXT_mesh_shader support to our engine and would like to make sure validation is hooked up properly. |
It would be good to know when this will be completed. I have had people from the ecosystem complain about lack of validation support for this extension |
b45cd0d
to
d46e54b
Compare
d46e54b
to
1bdf304
Compare
1bdf304
to
da790d9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@spencer-lunarg any outstanding issue from your POV?
No - will there are the 3 VUs todo yet, but will update the issue afterward, this PR as is good IMO |
@pmistryNV Can you please rebase and fix the formatting issues? |
Doing it right now |
da790d9
to
0d398a4
Compare
There are still some formatting errors. |
1. Each OpEntryPoint with the MeshEXT Execution Model can have at most one global OpVariable of storage class TaskPayloadWorkgroupEXT. 2. PerPrimitiveEXT only be used on a memory object declaration or a member of a structure type 3. PerPrimitiveEXT only Input in Fragment and Output in MeshEXT 4. Added Mesh vulkan validation support for following rules: VUID-Layer-Layer-07039 VUID-PrimitiveId-PrimitiveId-07040 VUID-PrimitivePointIndicesEXT-PrimitivePointIndicesEXT-07042 VUID-PrimitivePointIndicesEXT-PrimitivePointIndicesEXT-07046 VUID-PrimitiveLineIndicesEXT-PrimitiveLineIndicesEXT-07048 VUID-PrimitiveLineIndicesEXT-PrimitiveLineIndicesEXT-07052 VUID-PrimitiveTriangleIndicesEXT-PrimitiveTriangleIndicesEXT-07054 VUID-PrimitiveTriangleIndicesEXT-PrimitiveTriangleIndicesEXT-07058 VUID-ViewportIndex-ViewportIndex-07060 VUID-StandaloneSpirv-ExecutionModel-07330 VUID-StandaloneSpirv-ExecutionModel-07331 VUID-PrimitiveId-PrimitiveId-04336 VUID-Layer-Layer-07039 VUID-ViewportIndex-ViewportIndex-07060 VUID-CullPrimitiveEXT-CullPrimitiveEXT-07034 VUID-CullPrimitiveEXT-CullPrimitiveEXT-07035 VUID-CullPrimitiveEXT-CullPrimitiveEXT-07036
0d398a4
to
c7f3a1e
Compare
For bug #4919