Vulkan commands are not necessarily exposed statically on a platform. Function pointers for all Vulkan commands can be obtained with the command:
PFN_vkVoidFunction vkGetInstanceProcAddr( VkInstance instance, const char* pName);
instance
is the instance that the function pointer will be
compatible with, or NULL
for commands not dependent on any instance.
pName
is the name of the command to obtain.
vkGetInstanceProcAddr
itself is obtained in a platform- and loader-
specific manner. Typically, the loader library will export this command as a
function symbol, so applications can link against the loader library, or
load it dynamically and look up the symbol using platform-specific APIs.
Loaders are encouraged to export function symbols for all other core
Vulkan commands as well; if this is done, then applications that use only
the core Vulkan commands have no need to use vkGetInstanceProcAddr
.
The table below defines the various use cases for vkGetInstanceProcAddr
and expected return value ("fp" is function pointer) for each case.
The returned function pointer is of type PFN_vkVoidFunction
, and must
be cast to the type of the command being queried.
Table 3.1. vkGetInstanceProcAddr behavior
instance | pName | return value |
---|---|---|
* | NULL | undefined |
invalid instance | * | undefined |
NULL | fp | |
NULL | fp | |
NULL | fp | |
NULL | * (any | NULL |
instance | core Vulkan command | fp1 |
instance | enabled instance extension commands for | fp1 |
instance | available device extension commands for | fp1,2 |
instance | * (any | NULL |
instance
or a child of instance
.
e.g. VkInstance
, VkPhysicalDevice
, VkDevice
, VkQueue
, or
VkCommandBuffer
.
![]() | editing-note |
---|---|
(Jon, Bug 14886 / Gitlab issue 4) The WSI group tentatively agreed that the
WSI extensions were special, and should get static entry points in link
libraries and prototypes in However, this decision has not been fully signed off on by the entire Vulkan WG yet AFAIK. Note that implementations typically will not support many of the WSI extensions, so “static entry points” do not relieve apps of the neccessity of runtime enabling and testing of each extension before using it. |
In order to support systems with multiple Vulkan implementations
comprising heterogeneous collections of hardware and software, the function
pointers returned by vkGetInstanceProcAddr
may point to dispatch
code, which calls a different real implementation for different
VkDevice
objects (and objects created from them). The overhead of this
internal dispatch can be avoided by obtaining device-specific function
pointers for any commands that use a device or device-child object as their
dispatchable object. Such function pointers can be obtained with the
command:
PFN_vkVoidFunction vkGetDeviceProcAddr( VkDevice device, const char* pName);
The table below defines the various use cases for vkGetDeviceProcAddr
and expected return value for each case.
The returned function pointer is of type PFN_vkVoidFunction
, and must
be cast to the type of the command being queried.
Table 3.2. vkGetDeviceProcAddr behavior
device | pName | return value |
---|---|---|
NULL | * | undefined |
invalid device | * | undefined |
device | NULL | undefined |
device | core Vulkan command1 | fp |
device | enabled extension commands1 | fp |
device | * (any | NULL |
device
or a child of device
.
e.g. VkDevice
, VkQueue
, or VkCommandBuffer
.
The definition of PFN_vkVoidFunction
is:
typedef void (VKAPI_PTR *PFN_vkVoidFunction)(void);