// Copyright 2015-2024 The Khronos Group Inc. // // SPDX-License-Identifier: CC-BY-4.0 [[naming]] = API Naming Conventions Identifiers in the Vulkan API (e.g. types, parameters, constants, etc.) all follow a set of naming rules, providing a consistent scheme for developers. The Vulkan C API uses prefixes as an implicit namespace control mechanism. Bindings to other languages can choose not to use these prefixes if the language provides an explicit namespace mechanism. == General Naming Rules Names of identifiers should generally be written with full words, as a concise description of what that identifier is. For example, the type of a structure containing information about how to create an instance is stext:VkInstanceCreateInfo. Abbreviations and prefixes are sometimes used in the API when they do not impede clarity. All abbreviations and prefixes used in the API must be approved by the Vulkan working group, and be added to the <> and <> sections, respectively. Whenever an approved abbreviation exists for a particular word, it should be used in place of the full word unless there is good reason not to. When a number is part of an identifier, it is treated as a word if it is a standalone number, such as the extension name token ename:VK_KHR_GET_MEMORY_REQUIREMENTS_2_EXTENSION_NAME for the `VK_KHR_get_memory_requirements2` extension. For uses where the number is part of a common abbreviation such as etext:2D or etext:R8B8`, the entire abbreviation is treated as a word. ifdef::editing-notes[] [NOTE] .editing-note ==== Unfortunately, there is an internal inconsistency here between extension name strings, such as VK_KHR_get_memory_requirements2, and tokens encoding those names, such as ename:VK_KHR_GET_MEMORY_REQUIREMENTS_2_EXTENSION_NAME. ==== endif::editing-notes[] [[naming-preprocessor]] == Preprocessor Defines Preprocessor definitions include an underscore `_` as a delimiter between words, with every character in upper case. Each definition is prefixed with `VK_`, followed by the name. This rule applies to most declarations with the C Preprocessor's `#define` token, including macros and constants. There are however a few exceptions: * The header guard for each header includes an additional underscore `_` at the end of the identifier. ** Example: `VULKAN_H_` * Definitions that denote the presence of an extension follow the <>. ** Example: `VK_KHR_sampler_mirror_clamp_to_edge` * Three `VKAPI_*` definitions are defined by the platform header to alias certain platform-specific identifiers related to calling conventions. ** Examples: `VKAPI_ATTR`, `VKAPI_CALL` and `VKAPI_PTR` * Preprocessor defines are occasionally used to create aliases between other Vulkan identifiers, which usually happens when something was originally misnamed. In these cases, the fixed name is added to the API, and the old name is made into an alias of that. In these cases, the name will be whatever the original misnamed identifier was. [source, c] .Example ---- // VK_VERSION_MAJOR (Macro) #define VK_VERSION_MAJOR(version) ((uint32_t)(version) >> 22) // VK_HEADER_VERSION (Base type) #define VK_HEADER_VERSION 10 ---- == Type Names Type names are declared with no separator between words. Each word starts with a capital letter, and every other character in each word is lower case. Each type name is prefixed with `Vk`. This rule applies to all type definitions except <>, including struct and union types, handles, base typedefs, and enumerant types. [source, c] .Example ---- // VkImage (Handle) VK_NONDISP_HANDLE(VkImage) // VkFlags (Base type) typedef uint32_t VkFlags; // VkResult (Enum type) typedef enum VkResult { ... }; // VkApplicationInfo (Struct) typedef struct VkApplicationInfo { ... } VkApplicationInfo; // VkClearColorValue (Union) typedef union VkClearColorValue { ... } VkClearColorValue; ---- [[naming-extension-structures]] === Extending Structure Names Structures which extend a base structures through its pname:pNext chain should reflect the name of the base structure. Currently there are two examples of such naming schemes. New structures which add extended object creation parameters to a base structure should use this naming scheme: .Extended Object Information Structures [width="60%",options="header"] |==== | Base Structure Name | Extending Structure Name | `Vk__Object__CreateInfo` | `Vk__ObjectName__CreateInfo__Author__` |==== `_Object_` is the name of the object being created. `_Name_` is a short name for the extension or the new information added by that extension. `_Author_` is the author ID of the extension. New structures which extend API queries, such as the `vkGetPhysicalDeviceFeatures2KHR` and `vkGetPhysicalDeviceProperties2KHR` commands defined by the `VK_KHR_get_physical_device_properties2` extension, should use this naming scheme: .Extended Query Structures [width="60%",options="header"] |==== | Base Structure Name | Extending Structure Name | `vkGetPhysicalDeviceFeatures2KHR` | `VkPhysicalDevice__Name__Features__Author__` | `vkGetPhysicalDeviceProperties2KHR` | `VkPhysicalDevice__Name__Properties__Author__` |==== `_Name_` is a short name for the extension, or for the new feature or property being queried, such as `Multiview` or `DiscardRectangle`. `_Author_` is the author ID of the extension. == Enumerant Names Enumerants include an underscore `_` as a delimiter between words, with every character in upper case. Each enumerant name is prefixed with `VK_`. Enumerants are prefixed with the exact name of the type it belongs to, converted to the correct case (e.g. `VkStructureType` -> `VK_STRUCTURE_TYPE_*`). This rule applies to all enumerants, with one exception. * The `VkResult` enumerants are split into two sub types: error and success codes. ** Success codes are not prefixed with anything other than `VK_`. ** Error codes are prefixed with `VK_ERROR_`. [source, c] .Example ---- // VK_FORMAT_UNDEFINED, VK_FORMAT_R4G4_UNORM_PACK8 (Enumerants) typedef enum VkFormat { VK_FORMAT_UNDEFINED = 0, VK_FORMAT_R4G4_UNORM_PACK8 = 1, ... }; // VkResult codes (Exception) typedef enum VkResult { VK_SUCCESS = 0, ... VK_ERROR_OUT_OF_HOST_MEMORY = -1, ... } VkResult; ---- == Command Names Command names are declared with no separator between words. Each word starts with a capital letter, and every other character in each word is lower case. The structure of a command name should be as follows: `__prefix Verb Object Property__` `_prefix_`:: This is usually "vk", but will be "vkCmd" if it is a command used to record into a command buffer, or "vkQueue" if it directly affects a queue. `_Verb_`:: The verb describing the action being performed. A list of most verbs used in Vulkan is available <>. `_Object_`:: The name of the object being acted upon by the command. `_Property_`:: The property of the object which is being acted upon by the command, and is omitted in cases where the whole object is being acted upon (e.g. creation commands). These rules apply to all command declarations. [source, c] .Example ---- // Creation command VKAPI_ATTR VkResult VKAPI_CALL vkCreateInstance( ... ); // Command buffer recording command VKAPI_ATTR VkResult VKAPI_CALL vkCmdBindPipeline( ... ); // Get command VKAPI_ATTR VkResult VKAPI_CALL vkGetQueryPoolResults( ... ); ---- .Note [NOTE] ==== There are three exceptions to the above rule in the core Vulkan API: * vkDeviceWaitIdle * vkCmdNextSubpass * vkCmdPipelineBarrier These names are left as-is to maintain compatibility. There are additionally a number of exceptions in a few existing extensions. ==== === Query Commands A number of commands in the API are used to determine the properties of some object in the implementation. The queried properties may either be invariant, or they may: change based on application behavior. If the results are not invariant, the lifetime of the results should be clearly described in the command description. See link:html/vkspec.html#fundamentals-commandsyntax-results-lifetime[Lifetime of Retrieved Results] in the specification for more information. These commands fall into two categories from a naming perspective: Capability Queries:: These are commands which query capabilities of objects that an implementation can provide. Such commands use the verb "Enumerate" to identify themselves. + e.g. `vkEnumeratePhysicalDeviceProperties` + Whilst these commands describe properties of the named object, they do not accept a parameter of that object type - though they usually have a parameter for the parent type. Object State Queries:: These commands are used to query the current properties of an object that has been created. Such commands use the verb "Get" to identify themselves. + e.g. `vkGetPhysicalDeviceQueueFamilyProperties` + These commands always have a parameter of the object type. [[command-names-verbs]] === Command Verbs Below is a list of many of the verbs currently in use in core Vulkan and KHR extensions, along with their meanings. The list is not guaranteed to be up to date, but covers all core and KHR verbs at the time of writing. [%autowidth,options="header"] |=== | Verb | Meaning | Acquire | Acquire ownership of an object from an external source | Allocate | Allocates memory in a pool or memory heap and creates object - paired with "Free" | Begin | Start of a range of command buffer commands with different behavior than those outside the range - "End" marks the end of the range | Bind | Binds an object to another object | Blit | Performs a filtered and scaled copy of pixels from one image to another | Clear | Sets all pixels in an image to the same value | Copy | A raw copy of data from one object to another with no transformation of the data | Create | Creates an object - paired with "Destroy" | Destroy | Destroys an object - paired with "Create" | Dispatch | Kicks off a set of compute tasks | Draw | Kicks off a set of rasterization tasks | End | End of a range of command buffer commands with different behavior than those outside the range - "Begin" marks the start of the range | Enumerate | Queries the capabilities of objects that could be created, before creating them | Execute | Executes commands recorded in another command buffer | Fill | Sets all data units in a buffer to the same value | Flush | Flushes data from the host to the device | Free | Destroys an object and then frees memory back to a pool or memory heap - paired with "Allocate" | Get | Queries the state of an existing object | Import | Imports the payload from an external object into a Vulkan object | Invalidate | Invalidates data on the host, forcing newer data on the device to be read | Map | Maps an allocation into host memory - paired with "Unmap" | Merge | Merges two objects | Present | Presents an image to a surface | Push | Pushes data to the device as part of a command stream | Release | Releases ownership of an object to an external source | Reset | Resets the state of an object to an initial state | Resolve | Resolves multiple samples in a multisampled image to an image with one sample per pixel | Set | Sets the state of an object | Submit | Submits a set of commands to a queue | Unmap | Unmaps an allocation from host memory - paired with "Map" | Update | Updates entries in a descriptor set | Wait | Waits for some signal | Write | Writes values to an object |=== [[naming-funcpointers]] === Function Pointer Type Names Function pointer names are declared exactly as the equivalent statically declared command would be declared, but prefixed with `PFN_`, standing for "Pointer to FunctioN". [source, c] .Example ---- // PFN_vkCreateInstance (Function Pointer) typedef VkResult (VKAPI_PTR *PFN_vkCreateInstance)( ... ); ---- == Function Parameter and Struct/Union Member Names Function parameter names are declared with no separator between words. Each new word, *except* for the first, starts with a capital letter. All other characters in the parameter name are in lower case. Members/parameters of a type that is not a base type should generally be named in a similar way to the type itself, with additional context added for clarity when necessary. Pointer members/parameters are prefixed with a number of `p` characters, with one `p` for each level of indirection. Function pointer members/parameters are prefixed with `pfn`. Any member describing the size of a memory allocation should be suffixed with `Size`. If the context is self-evident from the structure name, then it may simply be named `size`. Any member describing the number of something, such as an array length or number of internal allocations, should be suffixed with `Count`. The `size` rule overrides this rule, though it is possible to have multiple sizes (e.g. `sizeCount`). If the member is an array length, then the name of length should correspond to the name of the array member, usually `XYZCount` for an array named `pXYZs`. If a structure in a pname:pNext chain is an array whose length must match the length of an array of the base structure, then that extending structure should include an array length member with the same name as the length in the base structure. These rules apply to all function parameters and struct/union members, with a single exception: * The `sType` member of structures is abbreviated as it is used in almost every structure. ** The slightly odd naming prevents it clashing with any future variables. ** The `s` stands for "`structure`", referring to its enumerant type. [source, c] .Example ---- // Function parameters, including a twice indirected pointer. VKAPI_ATTR VkResult VKAPI_CALL vkMapMemory( VkDevice device, VkDeviceMemory memory, VkDeviceSize offset, VkDeviceSize size, VkMemoryMapFlags flags, void** ppData); // Structure members, including the sType exception and a single indirected // pointer. typedef struct VkMemoryBarrier { VkStructureType sType; const void* pNext; VkAccessFlags srcAccessMask; VkAccessFlags dstAccessMask; } VkMemoryBarrier; // Function pointer members typedef struct VkAllocationCallbacks { void* pUserData; PFN_vkAllocationFunction pfnAllocation; PFN_vkReallocationFunction pfnReallocation; PFN_vkFreeFunction pfnFree; PFN_vkInternalAllocationNotification pfnInternalAllocation; PFN_vkInternalFreeNotification pfnInternalFree; } VkAllocationCallbacks; // Size member (pCode is not a specific array of anything, it is just a // pointer to memory) typedef struct VkShaderModuleCreateInfo { VkStructureType sType; const void* pNext; VkShaderModuleCreateFlags flags; size_t codeSize; const uint32_t* pCode; } VkShaderModuleCreateInfo; // Count member typedef struct VkSparseImageMemoryBindInfo { VkImage image; uint32_t bindCount; const VkSparseImageMemoryBind* pBinds; } VkSparseImageMemoryBindInfo; ---- [[naming-extension-identifiers]] == Extension Identifier Naming Conventions Identifiers defined by an extension are modified by appending the extension's author ID to the end of the identifier, as described below. Author IDs are obtained as described in the <> section. If an extension becomes part of core, a new version of the extension's identifiers should be created, that do not contain the author ID at the end of the identifier. The original identifiers should be kept in order to maintain source-level compatibility with existing applications making use of the earlier extension's identifiers. === Extension Type Names Types defined by extensions have the author ID appended to the end of the type name. [source, c] .Example ---- // VkSurfaceFormatKHR (structure type with KHR appended) typedef struct VkSurfaceFormatKHR { VkFormat format; VkColorSpaceKHR colorSpace; } VkSurfaceFormatKHR; ---- [[naming-extension-enumerant-names]] === Extension Enumerant Names Enumerants defined by extensions have the author ID appended to the end of the enumerant name, separated by an underscore. This includes the begin, end, range and max values added to enumeranted type definitions by the generator scripts. [NOTE] ==== There is one exception to this rule in the `VK_KHR_sampler_mirror_clamp_to_edge` extension. This functionality was included in the original specification, but quickly separated out at release. Due to this late change, the single enum exposed has retained its original identifier to avoid compatibility issues: ename:VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE ==== [source, c] .Example ---- // VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR (enumerant with _KHR appended) typedef enum VkCompositeAlphaFlagBitsKHR { VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR = 0x00000001, ... } VkCompositeAlphaFlagBitsKHR; ---- === Extension Function Names Function and function pointer type names defined by extensions have the author ID appended to the end of the name. [source, c] .Example ---- // vkDestroySurfaceKHR (function with KHR appended) VKAPI_ATTR void VKAPI_CALL vkDestroySurfaceKHR( VkInstance instance, VkSurfaceKHR surface, const VkAllocationCallbacks* pAllocator); typedef void (VKAPI_PTR *PFN_vkDestroySurfaceKHR)( VkInstance instance, VkSurfaceKHR surface, const VkAllocationCallbacks* pAllocator); ---- [[naming-abbreviations]] == Common Abbreviations Abbreviations and acronyms are sometimes used in the <> and the Vulkan API where they are considered clear and commonplace. All such abbreviations used in the core API are defined here. Extensions should also use these abbreviations where appropriate. Src:: Source Dst:: Destination Min:: Minimum Max:: Maximum Rect:: Rectangle Info:: Information Lod:: Level of Detail Mip:: Related to a mipmap. Use "`mipmap`" in full only when it is a standalone term. If referred to some associating with a mipmap, such as levels, sampling mode, size, tail images, etc., use "`mip`" as a standalone prefix word, e.g. pname:maxMipLevels, ename:VK_MIP_MODE, etc. This is analogous to the <> [NOTE] ==== The names pname:mipmapMode, pname:mipmapPrecisionBits, sname:VkSamplerMipmapMode, and ename:VK_SPARSE_IMAGE_FORMAT_SINGLE_MIPTAIL_BIT are exceptions to this general usage guideline, for historical reasons. ==== ID:: Identifier UUID:: Universally Unique Identifier Op:: Operation R:: Red color component G:: Green color component B:: Blue color component A:: Alpha color component [[naming-prefixes]] == Standard Prefixes Prefixes are used in the API to denote specific semantic meaning of Vulkan names, or as a label to avoid name clashes, and are explained here: VK/Vk/vk:: Vulkan namespace + All types, commands, enumerants and C macro definitions in the Vulkan specification are prefixed with these two characters, according to the rules defined above. PFN/pfn:: Function Pointer + Denotes that a type is a function pointer, or that a variable is of a pointer type. p:: Pointer + Variable is a pointer. vkCmd:: Commands that record commands in command buffers + These API commands do not result in immediate processing on the device. Instead, they record the requested action in a command buffer for execution when the command buffer is submitted to a queue. s:: Structure + Used to denote the etext:VK_STRUCTURE_TYPE* member of each structure in pname:sType. [[format-types]] == Format Types Formats naming conventions Numeric Format:: Describes the suffix found on formats ex. SFLOAT, SINT, SNORM, SRGB, UINT, USCALED, etc Numeric Type:: describes float, signed int, or unsigned int SPIR-V Type:: The combination of the type (ex OpTypeInt), width, and signedness