C.14. Accessing Extension Functions from Programs

vkGetInstanceProcAddr and vkGetDeviceProcAddr can be used in order to obtain function pointer addresses for core and extension commands (per the description in Command Function Pointers). Different Vulkan API loaders can choose to statically export functions for some or all of the core Vulkan API commands, and can statically export functions for some or all extension commands. If a loader statically exports a function, an application can link against that function without needing to call one of the vkGet*ProcAddr commands.

[Note]Note

The Vulkan API loader for Android, Linux, and Windows exports functions for all core Vulkan API commands, and for a set of WSI extension commands that are applicable to those operating systems (see Vulkan loader documentation for the relevant platform/OS for details). The WSI functions are considered special, because they are required for many applications.

C.14.1. Reserving Bitfield Values

Enumerants which define bitfield values are a special case, since there are only a small number of unused bits available for extensions. For core Vulkan API and KHR extension bitfield types, reservations must be approved by a vote of the Vulkan Working Group. For EXT and vendor extension bitfield types, reservations must be approved by the listed contact of the extension. Bits are not reserved, and must not be used in a published implementation or specification until the reservation is merged into vk.xml by the registry maintainer.

[Note]Note

In reality the approving authority for EXT and vendor extension bitfield additions will probably be the owner of the github branch containing the specification of that extension; however, until the github process is fully defined and locked down, it’s safest to refer to the listed contact.