You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
vk.xml currently models which types, enums and commands (functions) a particular extension pulls in (provides?) by a <require> element inside <extension>. It also has support for nested extension and Vulkan version dependencies through <require extension="XXX"> / <require feature="XXX">.
Currently our generator globs them all under the name of the top-level <extension> into a single loadable struct, whereas we'd like to preserve a strict feature/extension -> struct mapping. With #629/#631 the helpers are now also clobbered with functions that are only available when two extensions are available (mixed in with functions that are available when the "root" extension is enabled.
One of the options is to glue these names together, resulting in something potentially odd to read like KhrSwapchainPlusVulkan11Fn, but at least makes the dependency clear. This becomes more complicated for the functions added in #629 which have multiple mixed (disjoint) dependencies on for example VK_KHR_swapchain + Vulkan 1.1, but also VK_KHR_device_group + VK_KHR_surface or VK_KHR_device_group + VK_KHR_swapchain. Having two loader structs containing the same doesn't seem too outrageous here.
A list of all <require extension="XXX"> blocks containing one or more command elements, generated on v1.3.211 using:
xmlstarlet sel -t -c "//extension/require[(@extension or @feature) and command]" generator/Vulkan-Headers/registry/vk.xml
Sparked from the discussion in #629:
vk.xml
currently models which types, enums and commands (functions) a particular extension pulls in (provides?) by a<require>
element inside<extension>
. It also has support for nested extension and Vulkan version dependencies through<require extension="XXX">
/<require feature="XXX">
.Currently our generator globs them all under the name of the top-level
<extension>
into a single loadablestruct
, whereas we'd like to preserve a strict feature/extension ->struct
mapping. With #629/#631 the helpers are now also clobbered with functions that are only available when two extensions are available (mixed in with functions that are available when the "root" extension is enabled.One of the options is to glue these names together, resulting in something potentially odd to read like
KhrSwapchainPlusVulkan11Fn
, but at least makes the dependency clear. This becomes more complicated for the functions added in #629 which have multiple mixed (disjoint) dependencies on for exampleVK_KHR_swapchain + Vulkan 1.1
, but alsoVK_KHR_device_group + VK_KHR_surface
orVK_KHR_device_group + VK_KHR_swapchain
. Having two loaderstructs
containing the same doesn't seem too outrageous here.A list of all
<require extension="XXX">
blocks containing one or morecommand
elements, generated onv1.3.211
using:xmlstarlet sel -t -c "//extension/require[(@extension or @feature) and command]" generator/Vulkan-Headers/registry/vk.xml
The text was updated successfully, but these errors were encountered: