1.1 subgroup validation?

[mikes-lunarg]

Issue migrated from https://gitlab.khronos.org/vulkan/LoaderAndValidationLayers/issues/204

So I've been looking at the 1.1 branch and I think there aren't any checks for subgroup support?

So I've got a bunch of queries:

• How do I get the VkPhysicalDeviceSubgroupProperties via VkPhysicalDeviceProperties2? (there seems to be some layer_data struct that has some of the features in it, but not all? Also I don't want to break 1.0 support or that!)
• Do I have to re-validate the SPIR-V uses the correct OpCapability's for the added subgroup opcodes?
• Meta question - why doesn't shader_validation.cpp run the lib passes from spirv-val? I think the validation above would be done by spirv-val s'all.

Thanks!

Mike:

Hi Neil, I can take a stab at these:

• Right now we call vkGetPhysicalDeviceProperties at device creation time to populate the layer_data. There is a change in flight that will use vkGetPhysicalDeviceProperties2 to get some data for push descriptor validation. Subgroup and any other extension that needs GPDP2 should be able to piggyback on that mechanism and add the appropriate validation state to layer_data.
• shader_validation.cpp uses spvValidate from libspirv at shader module creation time. I did a little digging in the spirv-tools source and I this does appear to do the opcode/capability check you are asking about.
• It does

The Vulkan API side of subgroup is relatively small which is probably why you don't see any checks aside from the capability-extension check in shader_validation.cpp. For spec VU statements I only see the 2 under VkPhysicalDeviceSubgroupProperties This actually raises an interesting question about how much validation is appropriate for subgroup because only sType and pNext are referenced in VUs.

Our primary focus for the 1.1 extensions was getting them compatible. Several of the other extensions broke validation state tracking or caused it to emit incorrect errors, but subgroup coexists peacefully. We can use this issue to track incomplete subgroup validation and move it to Github once 1.1 is public.

Neil:

So yeah - the only thing that I think needs done in shader_validation.cpp is to add to the table in capabilities in validate_shader_capabilities the following rows:

• Match spv::CapabilityGroupNonUniform against the VkPhysicalDeviceSubgroupProperties::supportedOperations & VK_SUBGROUP_FEATURE_BASIC_BIT
• Match spv::CapabilityGroupNonUniformVote against the VkPhysicalDeviceSubgroupProperties::supportedOperations & VK_SUBGROUP_FEATURE_VOTE_BIT
• Match spv::CapabilityGroupNonUniformArithmetic against the VkPhysicalDeviceSubgroupProperties::supportedOperations & VK_SUBGROUP_FEATURE_ARITHMETIC_BIT
• Match spv::CapabilityGroupNonUniformBallot against the VkPhysicalDeviceSubgroupProperties::supportedOperations & VK_SUBGROUP_FEATURE_BALLOT_BIT
• Match spv::CapabilityGroupNonUniformShuffle against the VkPhysicalDeviceSubgroupProperties::supportedOperations & VK_SUBGROUP_FEATURE_SHUFFLE_BIT
• Match spv::CapabilityGroupNonUniformShuffleRelative against the VkPhysicalDeviceSubgroupProperties::supportedOperations & VK_SUBGROUP_FEATURE_SHUFFLE_RELATIVE_BIT
• Match spv::CapabilityGroupNonUniformClustered against the VkPhysicalDeviceSubgroupProperties::supportedOperations & VK_SUBGROUP_FEATURE_CLUSTERED_BIT
• Match spv::CapabilityGroupNonUniformQuad against the VkPhysicalDeviceSubgroupProperties::supportedOperations & VK_SUBGROUP_FEATURE_QUAD_BIT

We also need to check that the above capabilities are only used in the correct shader stages:

• Use VkPhysicalDeviceSubgroupProperties::supportedStages and check if the current shader type is contained in this member and only allow the above Capabilities if the shader is supported.
• Also need to check that VkPhysicalDeviceSubgroupProperties::quadOperationsInAllStages, and:
  • If false, don't allow spv::CapabilityGroupNonUniformQuad in anything but the compute & fragment stages.

I hope this is it - and thanks for the help!