vulkaninfo: missing structures when using --show-promoted-structs

[JamesRumble-IMG]

We've been using --show-promoted-structs since it was added (40294f2) but I've noticed a few structures seem to be missing from the output:

We're currently using vulkaninfo from the Vulkan-SDK version 1.4.321.1 but it appears like the issue is still present using the head of main.

Here are a couple of examples I noticed:

For bufferDeviceAddress (VkPhysicalDeviceVulkan12Features/VkPhysicalDeviceBufferDeviceAddressFeatures/VkPhysicalDeviceBufferDeviceAddressFeaturesKHR/VkPhysicalDeviceBufferDeviceAddressFeaturesEXT)
Oddly the output seems to be missing VkPhysicalDeviceBufferDeviceAddressFeaturesKHR

For robustBufferAccess2 (VkPhysicalDeviceRobustness2FeaturesKHR/VkPhysicalDeviceRobustness2FeaturesEXT)
The output seems to be missing VkPhysicalDeviceRobustness2FeaturesEXT.

for hostImageCopy (VkPhysicalDeviceVulkan14Features/VkPhysicalDeviceHostImageCopyProperties)
The output seems to be missing VkPhysicalDeviceHostImageCopyProperties.

Is the above expected behaviour?

[charles-lunarg]

In vk.xml, VkPhysicalDeviceBufferDeviceAddressFeaturesEXT is a distinct struct while VkPhysicalDeviceBufferDeviceAddressFeaturesKHRis an alias ofVkPhysicalDeviceBufferDeviceAddressFeatures. Similarly, VkPhysicalDeviceRobustness2FeaturesKHRis a distinct struct whileVkPhysicalDeviceRobustness2FeaturesEXTis an alias to it. BothVkPhysicalDeviceBufferDeviceAddressFeaturesKHRandVkPhysicalDeviceRobustness2FeaturesEXT` aren't generated by vulkaninfo due to this aliasing. While adding logic to force those structs to appear in the generated code is possible, it isn't nice nor easy, and would be copying the contents of the other struct only differing with the names of variables.

For the last case, did you mean features or properties? EG VkPhysicalDeviceHostImageCopyFeatures vs VkPhysicalDeviceHostImageCopyProperties. When I ran vulkaninfo from VulkanSDK, I saw all four structures (Vulkan14Features/Properties and the extension equivalents). VkPhysicalDeviceHostImageCopyFeatures/Properties are not aliases, although their EXT suffixed versions are.

So I could add the aliases to the codegen like the other structs, but maybe the better logic is to simply add the names of aliases in the output alongside the distinct name.

Example of what I mean.

VkPhysicalDeviceBufferDeviceAddressFeatures (VkPhysicalDeviceBufferDeviceAddressFeaturesKHR):
--------------------------------------------
	bufferDeviceAddress              = true
	bufferDeviceAddressCaptureReplay = true
	bufferDeviceAddressMultiDevice   = false

Makes the alias grep-able without duplicating everything.

[JamesRumble-IMG]

VkPhysicalDeviceBufferDeviceAddressFeaturesEXT is a distinct struct

Ah I totally misssed that - apologies.

For the last case, did you mean features or properties? EG VkPhysicalDeviceHostImageCopyFeatures vs VkPhysicalDeviceHostImageCopyProperties

I meant VkPhysicalDeviceHostImageCopyFeatures/VkPhysicalDeviceHostImageCopyFeaturesEXT - copy and paste mistake!

As you've suggested the VkPhysicalDeviceHostImageCopyFeaturesEXT being missing is because its an alias of VkPhysicalDeviceHostImageCopyFeatures.

So I could add the aliases to the codegen like the other structs, but maybe the better logic is to simply add the names of aliases in the output alongside the distinct name.

How would this work with --json?

For context we use vulkaninfo --json --show-promoted-structs for determining which tests can be run on a given platform in a flexible way by defining static "test requirements" for each test i.e.

• we have a test case which we know requires VK_EXT_robustness2 + VkPhysicalDeviceRobustness2FeaturesEXT-nullDescriptor.
• for a given platform we run vulkaninfo --json --show-promoted-structs
• we process the output to determine whether VkPhysicalDeviceRobustness2FeaturesEXT-nullDescriptor is supported and use this to run or skip a test.

When we updated our vulkaninfo to a version supporting VK_KHR_robustness2 VkPhysicalDeviceRobustness2FeaturesEXT-nullDescriptor is no longer present in the output whereas VkPhysicalDeviceRobustness2FeaturesKHR-nullDescriptor is.
To support the current vulkaninfo behaviour we'd need to update our "test requirements" to match the version of Vulkan used by a given vulkaninfo version which I can imagine would be a pain.
Its also a little odd as the given test case above explicitly requires VK_EXT_robustness2 + VkPhysicalDeviceRobustness2FeaturesEXT-nullDescriptor and not VK_KHR_robustness2 + VkPhysicalDeviceRobustness2FeaturesKHR-nullDescriptor. So querying for the KHR variant seems a little "off"?

[charles-lunarg]

While adding more codegen isn't ideal, I am working on rewriting the current codegen to use VulkanObject, which makes adding more features easier. Adding "all" aliases shouldn't be too hard as aliased structs more or less only differ in name, and all that needs to occur is re-printing the base struct with the name changed. In other words VkPhysicalDeviceRobustness2FeaturesKHR is printed, then VkPhysicalDeviceRobustness2FeaturesEXT is printed using the printing function for VkPhysicalDeviceRobustness2FeaturesKHR but with the name changed. Or at least that is how I envision this support working.

It certainly is annoying that 'show-promoted-structs' is showing only some of them.

[charles-lunarg]

--show-promoted-structs now shows typedef aliases as well as promotions which use different structs.

[JamesRumble-IMG]

Thanks for the changes @charles-lunarg. I've just tested the changes out locally and I don't think they're working as expected when using --json. Should

Vulkan-Tools/vulkaninfo/vulkaninfo.cpp

Line 750 in 8ebb2a6

GpuDumpFeatures(p, gpu, false);

be explicitly setting show_promoted_structs to false? Instead should it not pass parse_data.show_promoted_structs through here

Vulkan-Tools/vulkaninfo/vulkaninfo.cpp

Line 1215 in 8ebb2a6

DumpGpuProfileCapabilities(p, *(gpus.at(parse_data.selected_gpu).get()));

?

With this change hacked in locally the results look as expected (and match non-json output)

[charles-lunarg]

Whoops, you are 100% correct. I assumed that JSON already did the right thing, because its output format is somewhat different than the text & html (following the profiles JSON schema) so when I looked at the output I didn't think to add --show-promoted-structs.

Like you said, it was an easy fix.
#1167

[JamesRumble-IMG]

Whoops, you are 100% correct. I assumed that JSON already did the right thing, because its output format is somewhat different than the text & html (following the profiles JSON schema) so when I looked at the output I didn't think to add --show-promoted-structs.

Like you said, it was an easy fix. #1167

I've grabbed the latest set of changes and everything looks good to me! Thanks again for the great changes