Vulkan-docs: VK_INDEX_TYPE_NONE_NV specification doc and VU issues

[krOoze]

VK_INDEX_TYPE_NONE_NV is

1) missing in-spec description below VkIndexType
2) missing in extension appendix list of added stuff
3) probably misses VU banning it in vkCmdBindIndexBuffer?

BTW VkAccelerationStructureTypeNV definition is completely missing in spec too.

[oddhack]

This should be fixed in the 1.1.93 spec update.

[JamesAMD]

Should there be <type name="VkAccelerationStructureTypeNV"/> under /registry/extensions/extension[@name="VK_NV_ray_tracing"]/require ?

I can't seem to find it in vk.xml as of commit 0e3ceb7574dacde2a10f15718ba0cbc92c9905c8.

[krOoze]

@JamesAMD I think it is optional, and commands include types by proxy. It should only be necessary to include types not referenced by the commands, such as VkDrawIndexedIndirectCommand.

[oddhack]

@krooze is correct, though there's no harm in listing those types as well.

[krOoze]

@oddhack Well, it can get confusing. Either all or none should be listed IMO.

[JamesAMD]

@krOoze @oddhack
Thank you, I didn't know it was optional.

I'm currently trying to write a little tool for myself that parses vk.xml and generates a piece of C++ code for converting Vulkan enumerant values to their corresponding names as string,
and I was under the assumption that all types introduced in an extension are listed under the corresponding extension element.

Apparently VkAccelerationStructureTypeNV is the only type for which this type of problem occurs out of the few extensions I'm currently taking into account,
and while it requires practically no effort to just add <type name="VkAccelerationStructureTypeNV"/> to vk.xml myself before having it parsed,
does there happen to be a more reliable way to know if a particular enum is introduced in an extension ?

[krOoze]

Is it? What about e.g. VkDescriptorBindingFlagsEXT?

Anyway, for purposes of conversion to string, why would you need to know?
FYI, in Validation Layers repo there's a script that makes enumerant to string conversion functions.

More reliable way would be to take the explicitly required stuff.
Then iterate over commands and structs from that list, and add member/type and param/type to the list.
Then do so recursively until no new items are added to the list.

If you want only those introduced in the particular extension, then you would do a set difference of stuff required by requiresCore Vulkan version and requires extension dependencies.

[krOoze]

PS:
@JamesAMD Alternatively PR could be submitted to vk.xml filling the omisions. Seems like there's not that many missing items. Here's a list with some false positives:

Unclaimed items (stuff not explicitly required in 1.1+ and extensions):
VkPipelineRasterizationStateCreateFlagBits
wl_surface
VkDeviceAddress
xcb_connection_t
CAMetalLayer
VkSubpassEndInfoKHR
VkFlags
LPCWSTR
VkResolveModeFlagsKHR
uint16_t
VkAccelerationStructureTypeNV
Display
VkPipelineInputAssemblyStateCreateFlagBits
VkDisplayKHR
VkDisplaySurfaceCreateFlagsKHR
VkDescriptorBindingFlagsEXT
SECURITY_ATTRIBUTES
VkDebugReportCallbackEXT
xcb_window_t
VkPipelineColorBlendStateCreateFlagBits
GgpStreamDescriptor
VK_MAX_PHYSICAL_DEVICE_NAME_SIZE
VkBufferViewCreateFlagBits
VkQueryPoolCreateFlagBits
VkColorSpaceKHR
VkDebugUtilsMessageSeverityFlagsEXT
VkFramebufferAttachmentImageInfoKHR
VkSubpassDescription2KHR
VkPresentInfoKHR
VK_MAX_DESCRIPTION_SIZE
VkValidationFeatureEnableEXT
VkDeviceCreateFlagBits
VkInstanceCreateFlagBits
VkPipelineMultisampleStateCreateFlagBits
int
VK_DEFINE_NON_DISPATCHABLE_HANDLE
VkSurfaceTransformFlagsKHR
VkSubpassBeginInfoKHR
VkDebugUtilsMessengerEXT
zx_handle_t
VkSwapchainCreateInfoKHR
VkDebugUtilsMessengerCreateFlagsEXT
AHardwareBuffer
PFN_vkDebugReportCallbackEXT
VkPipelineDynamicStateCreateFlagBits
VkDebugUtilsMessengerCallbackDataFlagsEXT
VkAttachmentDescription2KHR
VkPipelineVertexInputStateCreateFlagBits
VkPipelineDepthStencilStateCreateFlagBits
VK_DEFINE_HANDLE
VK_MAX_MEMORY_TYPES
GgpFrameToken
VK_MAKE_VERSION
RROutput
VK_MAX_EXTENSION_NAME_SIZE
HINSTANCE
VkPipelineViewportStateCreateFlagBits
VkResult
VkRenderPassCreateInfo2KHR
VK_UUID_SIZE
VkSwapchainKHR
VkPipelineTessellationStateCreateFlagBits
VkPresentModeKHR
VkValidationCheckEXT
VkSurfaceCapabilitiesKHR
HWND
wl_display
VkSwapchainCreateFlagsKHR
HANDLE
Window
PFN_vkDebugUtilsMessengerCallbackEXT
VK_MAX_MEMORY_HEAPS
VkDebugReportFlagsEXT
PFN_vkVoidFunction
VkCompositeAlphaFlagsKHR
VkDisplayModeKHR
VkSurfaceFormatKHR
VkSubpassDependency2KHR
VkAttachmentReference2KHR
HMONITOR
VkInternalAllocationType
VkSurfaceKHR
VkDisplayModeCreateFlagsKHR
VkPipelineCacheCreateFlagBits
VkValidationFeatureDisableEXT
VisualID
DWORD
VkSystemAllocationScope
xcb_visualid_t
VkPipelineLayoutCreateFlagBits
VkDebugUtilsMessageTypeFlagsEXT

[oddhack]

does there happen to be a more reliable way to know if a particular enum is introduced in an extension

Only following the dependencies, as @krOoze said. The same type or command can be introduced in multiple extensions so there's potential ambiguity.

[dgkoch]

I pushed an internal MR to explicitly list VkAccelerationStructureTypeNV under VK_NV_ray_tracing.

[JamesAMD]

@krOoze
You're right, the same problem happened with enums added in e.g. VK_EXT_debug_utils, VK_EXT_descriptor_indexing and VK_EXT_validation_features.

Anyway, for purposes of conversion to string, why would you need to know?

For enums and enumerants introduced in extensions, I wanted my generated C++ code to surround the conversion functions with #ifdef blocks so I can use compile-time flags for each extension to enable/disable them, as my Vulkan header generated using glad only includes select set of extensions, and any conversion function for enums introduced in an extension other than those would result in compilation errors.

FYI, in Validation Layers repo there's a script that makes enumerant to string conversion functions.

Oh, I think you mean helper_file_generator.py ?
I didn't know about its existence, thanks !

It seems to be able to generate conversion functions for bit flags as well (my main motivation for writing this kind of tool).
Still, mine shortens enumerant names so e.g VK_IMAGE_LAYOUT_PRESENT_SRC_KHR would yield "PRESENT_SRC_KHR", so I like to think that my effort was not completely in vain.

More reliable way would be to take the explicitly required stuff.
Then iterate over commands and structs from that list, and add member/type and param/type to the list.
Then do so recursively until no new items are added to the list.

If you want only those introduced in the particular extension, then you would do a set difference of stuff required by requiresCore Vulkan version and requires extension dependencies.

Thanks for the detailed info !
I really appreciate it.

[oddhack]

The XML fix has been pushed in the 1.1.120 spec update.