Vulkan Specs and Extensions

Vulkan is a new generation graphics and compute API that provides high-efficiency, cross-platform access to modern GPUs used in a wide variety of devices from PCs and consoles to mobile phones and embedded platforms.

NVIDIA DRIVE™ Linux supports Vulkan 1.0. For the latest Vulkan 1.0 specification with extensions, see:

https://www.khronos.org/registry/vulkan/specs/1.0-wsi_extensions/html/vkspec.html

Note

Vulkan support is currently provided for evaluation purposes only and is limited to the Vulkan extensions listed in this section; however, not all listed extensions are supported in all releases. Be sure to query the driver to determine whether or not your release supports a specific extension.

Vulkan Extensions

Instance Extensions

The Vulkan driver in this release supports the following Vulkan instance extensions. You can determine exactly which Vulkan extensions your NVIDIA DRIVE™ product supports with code such as the following.

uint32_t instance_ext_count = 0;
VkExtensionProperties *instance_exts_ptr = NULL;
//Get the number of extensions
vkEnumerateInstanceExtensionProperties(NULL, &instance_ext_count, NULL);
instance_exts_ptr = (VkExtensionProperties*) malloc(instance_ext_count * sizeof(VkExtensionProperties));
//Get the list of extensions
vkEnumerateInstanceExtensionProperties(NULL, &instance_ext_count, instance_exts_ptr);

Where instance_exts_ptr is a pointer to an array of VkExtensionProperties structures that will contain extension names.

VK_EXT_debug_report — Due to the nature of the Vulkan interface, there is very little error information available to the developer and application. By enabling optional validation layers and using the VK_EXT_debug_report extension, developers can obtain much more detailed feedback on the application’s use of Vulkan. This extension defines a way for layers and the implementation to call back.

VK_KHR_display — This extension provides the API to enumerate displays and available modes on a given display device.

VK_KHR_external_fence_capabilities — An application may wish to reference device fences in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension provides a set of capability queries and handle definitions that allow an application to determine what types of “external” fence handles an implementation supports for a given set of use cases.

VK_KHR_external_memory_capabilities — An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension provides a set of capability queries and handle definitions that allow an application to determine what types of “external” memory handles an implementation supports for a given set of use cases.

VK_KHR_external_semaphore_capabilities — An application may wish to reference device semaphores in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension provides a set of capability queries and handle definitions that allow an application to determine what types of “external” semaphore handles an implementation supports for a given set of use cases.

VK_KHR_get_physical_device_properties2 — This extension provides new entry points to query device features, device properties, and format properties in a way that can be easily extended by other extensions, without introducing any further entry points. The Vulkan 1.0 feature/limit/formatproperty structures do not include sType/pNext members.

This extension wraps them in new structures with sType/pNext members, so an application can query a chain of feature/limit/formatproperty structures by constructing the chain and letting the implementation fill them in. A new command is added for each vkGetPhysicalDevice* command in core Vulkan 1.0. The new feature structure (and a chain of extension structures) can also be passed in to device creation to enable features.

This extension also allows applications to use the physical-device components of device extensions before vkCreateDevice is called.

VK_KHR_get_surface_capabilities2 — This extension provides new entry points to query device surface capabilities in a way that can be easily extended by other extensions, without introducing any further entry points. This extension can be considered the VK_KHR_surface equivalent of the VK_KHR_get_physical_device_properties2 extension.

VK_KHR_surface — The VK_KHR_surface extension is an instance extension. It introduces VkSurfaceKHR objects, which abstract native platform surface or window objects for use with Vulkan. It also provides a way to determine whether a queue family in a physical device supports presenting to particular surface. Separate extensions for each platform provide the mechanisms for creating VkSurfaceKHR objects, but once created they may be used in this and other platform-independent extensions, in particular the VK_KHR_swapchain extension.

Device Extensions

The Vulkan driver in this release supports the following Vulkan device extensions. You can determine exactly which Vulkan extensions your NVIDIA DRIVE™ product supports with code such as the following.

uint32_t device_ext_count = 0;
VkExtensionProperties *device_exts_ptr = NULL;
//Get the number of extensions
vkEnumerateDeviceExtensionProperties(physDevice, NULL, &device_ext_count, NULL);
device_exts_ptr = (VkExtensionProperties*) malloc(device_ext_count * sizeof(VkExtensionProperties));
//Get the list of extensions
vkEnumerateDeviceExtensionProperties(physDevice, NULL, &device_ext_count, device_exts_ptr);

Where physDevice is the VkPhysicalDevice that will be queried and device_exts_ptr is a pointer to an array of VkExtensionProperties structures that will contain extension names.

VK_KHR_16bit_storage — The VK_KHR_16bit_storage extension allows use of 16-bit types in shader input and output interfaces, and push constant blocks. This extension introduces several new optional features which map to SPIR-V capabilities and allow access to 16-bit data in Block-decorated objects in the Uniform and the StorageBuffer storage classes, and objects in the PushConstant storage class. This extension allows 16-bit variables to be declared and used as user-defined shader inputs and outputs but does not change location assignment and component assignment rules.

VK_KHR_bind_memory2 — This extension provides versions of vkBindBufferMemory and vkBindImageMemory that allow multiple bindings to be performed at once, and are extensible.

This extension also introduces VK_IMAGE_CREATE_ALIAS_BIT_KHR, which allows “identical” images that alias the same memory to interpret the contents consistently, even across image layout changes.

VK_KHR_dedicated_allocation — This extension enables resources to be bound to a dedicated allocation, rather than suballocated. For any particular resource, applications can query whether a dedicated allocation is recommended, in which case using a dedicated allocation may improve the performance of access to that resource. Normal device memory allocations must support multiple resources per allocation, memory aliasing and sparse binding, which could interfere with some optimizations.

Applications should query the implementation for when a dedicated allocation may be beneficial by adding VkMemoryDedicatedRequirementsKHR to the pNext chain of the VkMemoryRequirements2KHR structure passed as the pMemoryRequirements parameter to a call to vkGetBufferMemoryRequirements2KHR or vkGetImageMemoryRequirements2KHR. Certain external handle types and external images or buffers may also depend on dedicated allocations on implementations that associate image or buffer metadata with OS-level memory objects.

This extension adds a two small structures to memory requirements querying and memory allocation: a new structure that flags whether an image/buffer should have a dedicated allocation, and a structure indicating the image or buffer that an allocation will be bound to.

VK_KHR_descriptor_update_template — Applications may wish to update a fixed set of descriptors in a large number of descriptors sets very frequently, i.e. during initializaton phase or if it’s required to rebuild descriptor sets for each frame. For those cases it’s also not unlikely that all information required to update a single descriptor set is stored in a single struct. This extension provides a way to update a fixed set of descriptors in a single VkDescriptorSet with a pointer to a user defined data structure which describes the new descriptors.

VK_KHR_external_fence — An application using external memory may wish to synchronize access to that memory using fences. This extension enables an application to create fences from which non-Vulkan handles that reference the underlying synchronization primitive can be exported.

VK_KHR_external_fence_fd — An application using external memory may wish to synchronize access to that memory using fences. This extension enables an application to export fence payload to and import fence payload from POSIX file descriptors.

VK_KHR_external_memory — An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension enables an application to export non-Vulkan handles from Vulkan memory objects such that the underlying resources can be referenced outside the scope of the Vulkan logical device that created them.

VK_KHR_external_memory_fd — An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension enables an application to export POSIX file descriptor handles from Vulkan memory objects and to import Vulkan memory objects from POSIX file descriptor handles exported from other Vulkan memory objects or from similar resources in other APIs.

VK_KHR_external_semaphore — An application using external memory may wish to synchronize access to that memory using semaphores. This extension enables an application to create semaphores from which non-Vulkan handles that reference the underlying synchronization primitive can be exported.

VK_KHR_external_semaphore_fd — An application using external memory may wish to synchronize access to that memory using semaphores. This extension enables an application to export semaphore payload to and import semaphore payload from POSIX file descriptors.

VK_KHR_get_memory_requirements2 — This extension provides new entry points to query memory requirements of images and buffers in a way that can be easily extended by other extensions, without introducing any further entry points. The Vulkan 1.0 VkMemoryRequirements and VkSparseImageMemoryRequirements structures do not include a sType/pNext, this extension wraps them in new structures with sType/pNext so an application can query a chain of memory requirements structures by constructing the chain and letting the implementation fill them in. A new command is added for each vkGet*MemoryRequrements command in core Vulkan 1.0.

VK_KHR_image_format_list — On some implementations, setting the VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT on image creation can cause access to that image to perform worse than an equivalent image created without VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT because the implementation does not know what view formats will be paired with the image.

This extension allows an application to provide the list of all formats that can be used with an image when it is created. The implementation may then be able to create a more efficient image that supports the subset of formats required by the application without having to support all formats in the format compatibility class of the image format.

VK_KHR_maintenance1 — VK_KHR_maintenance1 adds a collection of minor features that were left out or overlooked from the original Vulkan 1.0 release. The new features are as follows:

• Allow 2D and 2D array image views to be created from 3D images, which can then be used as color framebuffer attachments. This allows applications to render to slices of a 3D image.
• Support vkCmdCopyImage between 2D array layers and 3D slices. This extension allows copying from layers of a 2D array image to slices of a 3D image and vice versa.
• Allow negative height to be specified in the VkViewport::height field to perform y-inversion of the clip-space to framebuffer-space transform. This allows apps to avoid having to use gl_Position.y = -gl_Position.y in shaders also targeting other APIs.
• Allow implementations to express support for doing just transfers and clears of image formats that they otherwise support no other format features for. This is done by adding new format feature flags VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR and VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR.
• Support vkCmdFillBuffer on transfer-only queues. Previously vkCmdFillBuffer was defined to only work on command buffers allocated from command pools which support graphics or compute queues. It is now allowed on queues that just support transfer operations.
• Fix the inconsistency of how error conditions are returned between the vkCreateGraphicsPipelines and vkCreateComputePipelines functions and the vkAllocateDescriptorSets and vkAllocateCommandBuffers functions.
• Add new VK_ERROR_OUT_OF_POOL_MEMORY_KHR error so implementations can give a more precise reason for vkAllocateDescriptorSets failures.
• Add a new command vkTrimCommandPoolKHR which gives the implementation an opportunity to release any unused command pool memory back to the system.
  
  

VK_KHR_maintenance2 — VK_KHR_maintenance2 adds a collection of minor features that were intentionally left out or overlooked from the original Vulkan 1.0 release. The new features are as follows:

• Allow the application to specify which aspect of an input attachment might be read for a given subpass.
• Allow implementations to express the clipping behavior of points.
• Allow creating images with usage flags that may not be supported for the base image’s format, but are supported for image views of the image that have a different but compatible format.
• Allow creating uncompressed image views of compressed images.
• Allow the application to select between an upper-left and lower-left origin for the tessellation domain space.
• Adds two new image layouts for depth stencil images to allow either the depth or stencil aspect to be read-only while the other aspect is writable.
  
  

VK_KHR_push_descriptor — This extension allows descriptors to be written into the command buffer, while the implementation is responsible for managing their memory. Push descriptors may enable easier porting from older APIs and in some cases can be more efficient than writing descriptors into descriptor sets.

VK_KHR_relaxed_block_layout — The VK_KHR_relaxed_block_layout extension allows implementations to indicate they can support more variation in block Offset decorations. For example, placing a vector of three floats at an offset of 16*N + 4.

VK_KHR_sampler_mirror_clamp_to_edge — VK_KHR_sampler_mirror_clamp_to_edge extends the set of sampler address modes to include an additional mode (VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE) that effectively uses a texture map twice as large as the original image in which the additional half of the new image is a mirror image of the original image. This new mode relaxes the need to generate images whose opposite edges match by using the original image to generate a matching “mirror image”. This mode allows the texture to be mirrored only once in the negative s, t, and r directions.

VK_KHR_sampler_ycbcr_conversion — This extension provides the ability to perform specified color space conversions during texture sampling operations. It also adds a selection of multi-planar formats, including the ability to bind memory to the planes of an image collectively or separately.

VK_KHR_shader_draw_parameters — This extension adds support for the following SPIR-V extension in Vulkan:

• SPV_KHR_shader_draw_parameters

The extension provides access to three additional built-in shader variables in Vulkan:

• BaseInstance, which contains the firstInstance parameter passed to draw commands,
• BaseVertex, which contains the firstVertex/vertexOffset parameter passed to draw commands, and
• DrawIndex, which contains the index of the draw call currently being processed from an indirect draw call.

When using GLSL source-based shader languages, the following variables from GL_ARB_shader_draw_parameters can map to these SPIR-V built-in decorations:

• in int gl_BaseInstanceARB; → BaseInstance,
• in int gl_BaseVertexARB; → BaseVertex, and
• in int gl_DrawIDARB; → DrawIndex.
  
  

VK_KHR_storage_buffer_storage_class — This extension adds support for the following SPIR-V extension in Vulkan:

• SPV_KHR_storage_buffer_storage_class

This extension provides a new SPIR-V StorageBuffer storage class. A Block-decorated object in this class is equivalent to a BufferBlock-decorated object in the Uniform storage class.

VK_KHR_swapchain — The VK_KHR_swapchain extension is the device-level companion to the VK_KHR_surface extension. It introduces VkSwapchainKHR objects, which provide the ability to present rendering results to a surface.

VK_KHR_variable_pointers — The VK_KHR_variable_pointers extension allows implementations to indicate their level of support for the SPV_KHR_variable_pointers SPIR-V extension. The SPIR-V extension allows shader modules to use invocation-private pointers into uniform and/or storage buffers, where the pointer values can be dynamic and non-uniform.

The SPV_KHR_variable_pointers extension introduces two capabilities. The first, VariablePointersStorageBuffer, must be supported by all implementations of this extension. The second, VariablePointers, is optional.