Appendix D: Layers & Extensions (Informative)

Extensions to the Vulkan API can be defined by authors, groups of authors, and the Khronos Vulkan Working Group. In order not to compromise the readability of the Vulkan Specification, the core Specification does not incorporate most extensions. The online Registry of extensions is available at URL

and allows generating versions of the Specification incorporating different extensions.

Most of the content previously in this appendix does not specify use of specific Vulkan extensions and layers, but rather specifies the processes by which extensions and layers are created. As of version 1.0.21 of the Vulkan Specification, this content has been migrated to the Vulkan Documentation and Extensions document. Authors creating extensions and layers must follow the mandatory procedures in that document.

The remainder of this appendix documents a set of extensions chosen when this document was built. Versions of the Specification published in the Registry include:

  • Core API + mandatory extensions required of all Vulkan implementations.

  • Core API + all registered and published Khronos (KHR) extensions.

  • Core API + all registered and published extensions.

Extensions are grouped as Khronos KHR, multivendor EXT, and then alphabetically by author ID. Within each group, extensions are listed in alphabetical order by their name.

Note

As of the initial Vulkan 1.1 public release, the KHX author ID is no longer used. All KHX extensions have been promoted to KHR status. Previously, this author ID was used to indicate that an extension was experimental, and is being considered for standardization in future KHR or core Vulkan API versions. We no longer use this mechanism for exposing experimental functionality.

Some vendors may use an alternate author ID ending in X for some of their extensions. The exact meaning of such an author ID is defined by each vendor, and may not be equivalent to KHX, but it is likely to indicate a lesser degree of interface stability than a non-X extension from the same vendor.

List of Extensions

VK_KHR_16bit_storage

Name String

VK_KHR_16bit_storage

Extension Type

Device extension

Registered Extension Number

84

Revision

1

Extension and Version Dependencies
Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Alexander Galazin, ARM

  • Jan-Harald Fredriksen, ARM

  • Joerg Wagner, ARM

  • Neil Henning, Codeplay

  • Jeff Bolz, Nvidia

  • Daniel Koch, Nvidia

  • David Neto, Google

  • John Kessenich, Google

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.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES_KHR

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

Version History

  • Revision 1, 2017-03-23 (Alexander Galazin)

    • Initial draft

VK_KHR_8bit_storage

Name String

VK_KHR_8bit_storage

Extension Type

Device extension

Registered Extension Number

178

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2018-02-05

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Alexander Galazin, Arm

The VK_KHR_8bit_storage extension allows use of 8-bit types in uniform and storage buffers, and push constant blocks. This extension introduces several new optional features which map to SPIR-V capabilities and allow access to 8-bit data in Block-decorated objects in the Uniform and the StorageBuffer storage classes, and objects in the PushConstant storage class.

The StorageBuffer8BitAccess capability must be supported by all implementations of this extension. The other capabilities are optional.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_8BIT_STORAGE_FEATURES_KHR

Issues

Version History

  • Revision 1, 2018-02-05 (Alexander Galazin)

    • Initial draft

VK_KHR_android_surface

Name String

VK_KHR_android_surface

Extension Type

Instance extension

Registered Extension Number

9

Revision

6

Extension and Version Dependencies
Contact
Last Modified Date

2016-01-14

IP Status

No known IP claims.

Contributors
  • Patrick Doane, Blizzard

  • Jason Ekstrand, Intel

  • Ian Elliott, LunarG

  • Courtney Goeltzenleuchter, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Antoine Labour, Google

  • Jon Leech, Khronos

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Ray Smith, ARM

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

The VK_KHR_android_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) that refers to an ANativeWindow, Android’s native surface type. The ANativeWindow represents the producer endpoint of any buffer queue, regardless of consumer endpoint. Common consumer endpoints for ANativeWindows are the system window compositor, video encoders, and application-specific compositors importing the images through a SurfaceTexture.

New Object Types

None

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ANDROID_SURFACE_CREATE_INFO_KHR

New Enums

None

Issues

1) Does Android need a way to query for compatibility between a particular physical device (and queue family?) and a specific Android display?

RESOLVED: No. Currently on Android, any physical device is expected to be able to present to the system compositor, and all queue families must support the necessary image layout transitions and synchronization operations.

Version History

  • Revision 1, 2015-09-23 (Jesse Hall)

    • Initial draft.

  • Revision 2, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_android_surface to VK_KHR_android_surface.

  • Revision 3, 2015-11-03 (Daniel Rakos)

    • Added allocation callbacks to surface creation function.

  • Revision 4, 2015-11-10 (Jesse Hall)

    • Removed VK_ERROR_INVALID_ANDROID_WINDOW_KHR.

  • Revision 5, 2015-11-28 (Daniel Rakos)

    • Updated the surface create function to take a pCreateInfo structure.

  • Revision 6, 2016-01-14 (James Jones)

    • Moved VK_ERROR_NATIVE_WINDOW_IN_USE_KHR from the VK_KHR_android_surface to the VK_KHR_surface extension.

VK_KHR_bind_memory2

Name String

VK_KHR_bind_memory2

Extension Type

Device extension

Registered Extension Number

158

Revision

1

Extension and Version Dependencies
  • Requires Vulkan 1.0

Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jeff Bolz, NVIDIA

  • Tobias Hector, Imagination Technologies

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.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BIND_BUFFER_MEMORY_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_INFO_KHR

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_ALIAS_BIT_KHR

New Enums

None.

New Built-In Variables

None.

New SPIR-V Capabilities

None.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

None.

Version History

  • Revision 1, 2017-05-19 (Tobias Hector)

    • Pulled bind memory functions into their own extension

VK_KHR_create_renderpass2

Name String

VK_KHR_create_renderpass2

Extension Type

Device extension

Registered Extension Number

110

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2018-02-07

Contributors
  • Tobias Hector

  • Jeff Bolz

This extension provides a new entry point to create render passes in a way that can be easily extended by other extensions through the substructures of render pass creation. The Vulkan 1.0 render pass creation sub-structures do not include sType/pNext members. Additionally, the renderpass begin/next/end commands have been augmented with new extensible structures for passing additional subpass information.

The VkRenderPassMultiviewCreateInfo and VkInputAttachmentAspectReference structures that extended the original VkRenderPassCreateInfo are not accepted into the new creation functions, and instead their parameters are folded into this extension as follows:

The details of these mappings are explained fully in the new structures.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2_KHR

    • VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_2_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_DEPENDENCY_2_KHR

    • VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_BEGIN_INFO_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_END_INFO_KHR

Version History

  • Revision 1, 2018-02-07 (Tobias Hector)

    • Internal revisions

VK_KHR_dedicated_allocation

Name String

VK_KHR_dedicated_allocation

Extension Type

Device extension

Registered Extension Number

128

Revision

3

Extension and Version Dependencies
Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jeff Bolz, NVIDIA

  • Jason Ekstrand, Intel

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 VkMemoryRequirements2 structure passed as the pMemoryRequirements parameter to a call to vkGetBufferMemoryRequirements2 or vkGetImageMemoryRequirements2. 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.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR

    • VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR

New Enums

None.

New Functions

None.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

None.

Examples

    // Create an image with a dedicated allocation based on the
    // implementation's preference

    VkImageCreateInfo imageCreateInfo =
    {
        // Image creation parameters
    };

    VkImage image;
    VkResult result = vkCreateImage(
        device,
        &imageCreateInfo,
        NULL,                               // pAllocator
        &image);

    VkMemoryDedicatedRequirementsKHR dedicatedRequirements =
    {
        VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR,
        NULL,                               // pNext
    };

    VkMemoryRequirements2 memoryRequirements =
    {
        VK_STRUCTURE_TYPE_MEMORY_REQUIREMENTS_2,
        &dedicatedRequirements,             // pNext
    };

    const VkImageMemoryRequirementsInfo2 imageRequirementsInfo =
    {
        VK_STRUCTURE_TYPE_IMAGE_MEMORY_REQUIREMENTS_INFO_2,
        NULL,                               // pNext
        image
    };

    vkGetImageMemoryRequirements2(
        device,
        &imageRequirementsInfo,
        &memoryRequirements);

    if (dedicatedRequirements.prefersDedicatedAllocation) {
        // Allocate memory with VkMemoryDedicatedAllocateInfoKHR::image
        // pointing to the image we are allocating the memory for

        VkMemoryDedicatedAllocateInfoKHR dedicatedInfo =
        {
            VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR,   // sType
            NULL,                                                   // pNext
            image,                                                  // image
            VK_NULL_HANDLE,                                         // buffer
        };

        VkMemoryAllocateInfo memoryAllocateInfo =
        {
            VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO,                 // sType
            &dedicatedInfo,                                         // pNext
            memoryRequirements.size,                                // allocationSize
            FindMemoryTypeIndex(memoryRequirements.memoryTypeBits), // memoryTypeIndex
        };

        VkDeviceMemory memory;
        vkAllocateMemory(
            device,
            &memoryAllocateInfo,
            NULL,                       // pAllocator
            &memory);

        // Bind the image to the memory

        vkBindImageMemory(
            device,
            image,
            memory,
            0);
    } else {
        // Take the normal memory sub-allocation path
    }

Version History

  • Revision 1, 2017-02-27 (James Jones)

    • Copy content from VK_NV_dedicated_allocation

    • Add some references to external object interactions to the overview.

  • Revision 2, 2017-03-27 (Jason Ekstrand)

    • Rework the extension to be query-based

  • Revision 3, 2017-07-31 (Jason Ekstrand)

    • Clarify that memory objects created with VkMemoryDedicatedAllocateInfoKHR can only have the specified resource bound and no others.

VK_KHR_depth_stencil_resolve

Name String

VK_KHR_depth_stencil_resolve

Extension Type

Device extension

Registered Extension Number

200

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2018-04-09

Contributors
  • Jan-Harald Fredriksen, Arm

  • Andrew Garrard, Samsung Electronics

  • Soowan Park, Samsung Electronics

  • Jeff Bolz, NVIDIA

  • Daniel Rakos, AMD

This extension adds support for automatically resolving multisampled depth/stencil attachments in a subpass in a similar manner as for color attachments.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_STENCIL_RESOLVE_PROPERTIES_KHR

New Functions

None.

Version History

  • Revision 1, 2018-04-09 (Jan-Harald Fredriksen)

    • Initial revision

VK_KHR_descriptor_update_template

Name String

VK_KHR_descriptor_update_template

Extension Type

Device extension

Registered Extension Number

86

Revision

1

Extension and Version Dependencies
  • Requires Vulkan 1.0

Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Michael Worcester, Imagination Technologies

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 is required to rebuild descriptor sets for each frame. For those cases it is 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.

New Object Types

  • VkDescriptorUpdateTemplateKHR

New Enum Constants

Extending VkStructureType:

  • VK_STRUCTURE_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_CREATE_INFO_KHR

Promotion to Vulkan 1.1

vkCmdPushDescriptorSetWithTemplateKHR is included as an interaction with VK_KHR_push_descriptor. If Vulkan 1.1 and VK_KHR_push_descriptor are supported, this is included by VK_KHR_push_descriptor.

The base functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2016-01-11 (Markus Tavenrath)

    • Initial draft

VK_KHR_device_group

Name String

VK_KHR_device_group

Extension Type

Device extension

Registered Extension Number

61

Revision

3

Extension and Version Dependencies
Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-10-06

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jeff Bolz, NVIDIA

  • Tobias Hector, Imagination Technologies

This extension provides functionality to use a logical device that consists of multiple physical devices, as created with the VK_KHR_device_group_creation extension. A device group can allocate memory across the subdevices, bind memory from one subdevice to a resource on another subdevice, record command buffers where some work executes on an arbitrary subset of the subdevices, and potentially present a swapchain image from one or more subdevices.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_FLAGS_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_RENDER_PASS_BEGIN_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_COMMAND_BUFFER_BEGIN_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_SUBMIT_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_BIND_SPARSE_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_IMAGE_SWAPCHAIN_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_SWAPCHAIN_INFO_KHR

    • VK_STRUCTURE_TYPE_ACQUIRE_NEXT_IMAGE_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_SWAPCHAIN_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_BUFFER_MEMORY_DEVICE_GROUP_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_DEVICE_GROUP_INFO_KHR

  • Extending VkImageCreateFlagBits

    • VK_IMAGE_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR

  • Extending VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_VIEW_INDEX_FROM_DEVICE_INDEX_BIT_KHR

    • VK_PIPELINE_CREATE_DISPATCH_BASE_KHR

  • Extending VkDependencyFlagBits

    • VK_DEPENDENCY_DEVICE_GROUP_BIT_KHR

  • Extending VkSwapchainCreateFlagBitsKHR

    • VK_SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR

New Built-In Variables

New SPIR-V Capabilities

Promotion to Vulkan 1.1

The following enums, types and commands are included as interactions with VK_KHR_swapchain:

If Vulkan 1.1 and VK_KHR_swapchain are supported, these are included by VK_KHR_swapchain.

The base functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

None.

Examples

TODO

Version History

  • Revision 1, 2016-10-19 (Jeff Bolz)

    • Internal revisions

  • Revision 2, 2017-05-19 (Tobias Hector)

    • Removed extended memory bind functions to VK_KHR_bind_memory2, added dependency on that extension, and device-group-specific structs for those functions.

  • Revision 3, 2017-10-06 (Ian Elliott)

    • Corrected Vulkan 1.1 interactions with the WSI extensions. All Vulkan 1.1 WSI interactions are with the VK_KHR_swapchain extension.

  • Revision 4, 2017-10-10 (Jeff Bolz)

    • Rename "SFR" bits and structure members to use the phrase "split instance bind regions".

VK_KHR_device_group_creation

Name String

VK_KHR_device_group_creation

Extension Type

Instance extension

Registered Extension Number

71

Revision

1

Extension and Version Dependencies
  • Requires Vulkan 1.0

Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2016-10-19

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jeff Bolz, NVIDIA

This extension provides instance-level commands to enumerate groups of physical devices, and to create a logical device from a subset of one of those groups. Such a logical device can then be used with new features in the VK_KHR_device_group extension.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_DEVICE_CREATE_INFO_KHR

  • Extending VkMemoryHeapFlagBits

    • VK_MEMORY_HEAP_MULTI_INSTANCE_BIT_KHR

New Enums

None.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

None.

Examples

    VkDeviceCreateInfo devCreateInfo = { VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO };
    // (not shown) fill out devCreateInfo as usual.
    uint32_t deviceGroupCount = 0;
    VkPhysicalDeviceGroupPropertiesKHR *props = NULL;

    // Query the number of device groups
    vkEnumeratePhysicalDeviceGroupsKHR(g_vkInstance, &deviceGroupCount, NULL);

    // Allocate and initialize structures to query the device groups
    props = (VkPhysicalDeviceGroupPropertiesKHR *)malloc(deviceGroupCount*sizeof(VkPhysicalDeviceGroupPropertiesKHR));
    for (i = 0; i < deviceGroupCount; ++i) {
        props[i].sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES_KHR;
        props[i].pNext = NULL;
    }
    vkEnumeratePhysicalDeviceGroupsKHR(g_vkInstance, &deviceGroupCount, props);

    // If the first device group has more than one physical device. create
    // a logical device using all of the physical devices.
    VkDeviceGroupDeviceCreateInfoKHR deviceGroupInfo = { VK_STRUCTURE_TYPE_DEVICE_GROUP_DEVICE_CREATE_INFO_KHR };
    if (props[0].physicalDeviceCount > 1) {
        deviceGroupInfo.physicalDeviceCount = props[0].physicalDeviceCount;
        deviceGroupInfo.pPhysicalDevices = props[0].physicalDevices;
        devCreateInfo.pNext = &deviceGroupInfo;
    }

    vkCreateDevice(props[0].physicalDevices[0], &devCreateInfo, NULL, &g_vkDevice);
    free(props);

Version History

  • Revision 1, 2016-10-19 (Jeff Bolz)

    • Internal revisions

VK_KHR_display

Name String

VK_KHR_display

Extension Type

Instance extension

Registered Extension Number

3

Revision

21

Extension and Version Dependencies
Contact
Last Modified Date

2017-03-13

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Norbert Nopper, Freescale

  • Jeff Vigil, Qualcomm

  • Daniel Rakos, AMD

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

New Object Types

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DISPLAY_MODE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_SURFACE_CREATE_INFO_KHR

Issues

1) Which properties of a mode should be fixed in the mode info vs. settable in some other function when setting the mode? E.g., do we need to double the size of the mode pool to include both stereo and non-stereo modes? YUV and RGB scanout even if they both take RGB input images? BGR vs. RGB input? etc.

PROPOSED RESOLUTION: Many modern displays support at most a handful of resolutions and timings natively. Other “modes” are expected to be supported using scaling hardware on the display engine or GPU. Other properties, such as rotation and mirroring should not require duplicating hardware modes just to express all combinations. Further, these properties may be implemented on a per-display or per-overlay granularity.

To avoid the exponential growth of modes as mutable properties are added, as was the case with EGLConfig/WGL pixel formats/GLXFBConfig, this specification should separate out hardware properties and configurable state into separate objects. Modes and overlay planes will express capabilities of the hardware, while a separate structure will allow applications to configure scaling, rotation, mirroring, color keys, LUT values, alpha masks, etc. for a given swapchain independent of the mode in use. Constraints on these settings will be established by properties of the immutable objects.

Note the resolution of this issue may affect issue 5 as well.

2) What properties of a display itself are useful?

PROPOSED RESOLUTION: This issue is too broad. It was meant to prompt general discussion, but resolving this issue amounts to completing this specification. All interesting properties should be included. The issue will remain as a placeholder since removing it would make it hard to parse existing discussion notes that refer to issues by number.

3) How are multiple overlay planes within a display or mode enumerated?

PROPOSED RESOLUTION: They are referred to by an index. Each display will report the number of overlay planes it contains.

4) Should swapchains be created relative to a mode or a display?

PROPOSED RESOLUTION: When using this extension, swapchains are created relative to a mode and a plane. The mode implies the display object the swapchain will present to. If the specified mode is not the display’s current mode, the new mode will be applied when the first image is presented to the swapchain, and the default operating system mode, if any, will be restored when the swapchain is destroyed.

5) Should users query generic ranges from displays and construct their own modes explicitly using those constraints rather than querying a fixed set of modes (Most monitors only have one real “mode” these days, even though many support relatively arbitrary scaling, either on the monitor side or in the GPU display engine, making “modes” something of a relic/compatibility construct).

PROPOSED RESOLUTION: Expose both. Display info structures will expose a set of predefined modes, as well as any attributes necessary to construct a customized mode.

6) Is it fine if we return the display and display mode handles in the structure used to query their properties?

PROPOSED RESOLUTION: Yes.

7) Is there a possibility that not all displays of a device work with all of the present queues of a device? If yes, how do we determine which displays work with which present queues?

PROPOSED RESOLUTION: No known hardware has such limitations, but determining such limitations is supported automatically using the existing VK_KHR_surface and VK_KHR_swapchain query mechanisms.

8) Should all presentation need to be done relative to an overlay plane, or can a display mode + display be used alone to target an output?

PROPOSED RESOLUTION: Require specifying a plane explicitly.

9) Should displays have an associated window system display, such as an HDC or Display*?

PROPOSED RESOLUTION: No. Displays are independent of any windowing system in use on the system. Further, neither HDC nor Display* refer to a physical display object.

10) Are displays queried from a physical GPU or from a device instance?

PROPOSED RESOLUTION: Developers prefer to query modes directly from the physical GPU so they can use display information as an input to their device selection algorithms prior to device creation. This avoids the need to create dummy device instances to enumerate displays.

This preference must be weighed against the extra initialization that must be done by driver vendors prior to device instance creation to support this usage.

11) Should displays and/or modes be dispatchable objects? If functions are to take displays, overlays, or modes as their first parameter, they must be dispatchable objects as defined in Khronos bug 13529. If they are not added to the list of dispatchable objects, functions operating on them must take some higher-level object as their first parameter. There is no performance case against making them dispatchable objects, but they would be the first extension objects to be dispatchable.

PROPOSED RESOLUTION: Do not make displays or modes dispatchable. They will dispatch based on their associated physical device.

12) Should hardware cursor capabilities be exposed?

PROPOSED RESOLUTION: Defer. This could be a separate extension on top of the base WSI specs.

if they are one physical display device to an end user, but may internally be implemented as two side-by-side displays using the same display engine (and sometimes cabling) resources as two physically separate display devices.

RESOLVED: Tiled displays will appear as a single display object in this API.

14) Should the raw EDID data be included in the display information?

RESOLVED: No. A future extension could be added which reports the EDID if necessary. This may be complicated by the outcome of issue 13.

15) Should min and max scaling factor capabilities of overlays be exposed?

RESOLVED: Yes. This is exposed indirectly by allowing applications to query the min/max position and extent of the source and destination regions from which image contents are fetched by the display engine when using a particular mode and overlay pair.

16) Should devices be able to expose planes that can be moved between displays? If so, how?

RESOLVED: Yes. Applications can determine which displays a given plane supports using vkGetDisplayPlaneSupportedDisplaysKHR.

17) Should there be a way to destroy display modes? If so, does it support destroying “built in” modes?

RESOLVED: Not in this extension. A future extension could add this functionality.

18) What should the lifetime of display and built-in display mode objects be?

RESOLVED: The lifetime of the instance. These objects cannot be destroyed. A future extension may be added to expose a way to destroy these objects and/or support display hotplug.

19) Should persistent mode for smart panels be enabled/disabled at swapchain creation time, or on a per-present basis.

RESOLVED: On a per-present basis.

Examples

Note

The example code for the VK_KHR_display and VK_KHR_display_swapchain extensions was removed from the appendix after revision 1.0.43. The display enumeration example code was ported to the cube demo that is shipped with the official Khronos SDK, and is being kept up-to-date in that location (see: https://github.com/KhronosGroup/Vulkan-Tools/blob/master/cube/cube.c).

Version History

  • Revision 1, 2015-02-24 (James Jones)

    • Initial draft

  • Revision 2, 2015-03-12 (Norbert Nopper)

    • Added overlay enumeration for a display.

  • Revision 3, 2015-03-17 (Norbert Nopper)

    • Fixed typos and namings as discussed in Bugzilla.

    • Reordered and grouped functions.

    • Added functions to query count of display, mode and overlay.

    • Added native display handle, which is maybe needed on some platforms to create a native Window.

  • Revision 4, 2015-03-18 (Norbert Nopper)

    • Removed primary and virtualPostion members (see comment of James Jones in Bugzilla).

    • Added native overlay handle to info structure.

    • Replaced , with ; in struct.

  • Revision 6, 2015-03-18 (Daniel Rakos)

    • Added WSI extension suffix to all items.

    • Made the whole API more "Vulkanish".

    • Replaced all functions with a single vkGetDisplayInfoKHR function to better match the rest of the API.

    • Made the display, display mode, and overlay objects be first class objects, not subclasses of VkBaseObject as they do not support the common functions anyways.

    • Renamed *Info structures to *Properties.

    • Removed overlayIndex field from VkOverlayProperties as there is an implicit index already as a result of moving to a "Vulkanish" API.

    • Displays are not get through device, but through physical GPU to match the rest of the Vulkan API. Also this is something ISVs explicitly requested.

    • Added issue (6) and (7).

  • Revision 7, 2015-03-25 (James Jones)

    • Added an issues section

    • Added rotation and mirroring flags

  • Revision 8, 2015-03-25 (James Jones)

    • Combined the duplicate issues sections introduced in last change.

    • Added proposed resolutions to several issues.

  • Revision 9, 2015-04-01 (Daniel Rakos)

    • Rebased extension against Vulkan 0.82.0

  • Revision 10, 2015-04-01 (James Jones)

    • Added issues (10) and (11).

    • Added more straw-man issue resolutions, and cleaned up the proposed resolution for issue (4).

    • Updated the rotation and mirroring enums to have proper bitmask semantics.

  • Revision 11, 2015-04-15 (James Jones)

    • Added proposed resolution for issues (1) and (2).

    • Added issues (12), (13), (14), and (15)

    • Removed pNativeHandle field from overlay structure.

    • Fixed small compilation errors in example code.

  • Revision 12, 2015-07-29 (James Jones)

    • Rewrote the guts of the extension against the latest WSI swapchain specifications and the latest Vulkan API.

    • Address overlay planes by their index rather than an object handle and refer to them as "planes" rather than "overlays" to make it slightly clearer that even a display with no "overlays" still has at least one base "plane" that images can be displayed on.

    • Updated most of the issues.

    • Added an "extension type" section to the specification header.

    • Re-used the VK_EXT_KHR_surface surface transform enumerations rather than redefining them here.

    • Updated the example code to use the new semantics.

  • Revision 13, 2015-08-21 (Ian Elliott)

    • Renamed this extension and all of its enumerations, types, functions, etc. This makes it compliant with the proposed standard for Vulkan extensions.

    • Switched from "revision" to "version", including use of the VK_MAKE_VERSION macro in the header file.

  • Revision 14, 2015-09-01 (James Jones)

    • Restore single-field revision number.

  • Revision 15, 2015-09-08 (James Jones)

    • Added alpha flags enum.

    • Added premultiplied alpha support.

  • Revision 16, 2015-09-08 (James Jones)

    • Added description section to the spec.

    • Added issues 16 - 18.

  • Revision 17, 2015-10-02 (James Jones)

    • Planes are now a property of the entire device rather than individual displays. This allows planes to be moved between multiple displays on devices that support it.

    • Added a function to create a VkSurfaceKHR object describing a display plane and mode to align with the new per-platform surface creation conventions.

    • Removed detailed mode timing data. It was agreed that the mode extents and refresh rate are sufficient for current use cases. Other information could be added back2 in as an extension if it is needed in the future.

    • Added support for smart/persistent/buffered display devices.

  • Revision 18, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_display to VK_KHR_display.

  • Revision 19, 2015-11-02 (James Jones)

    • Updated example code to match revision 17 changes.

  • Revision 20, 2015-11-03 (Daniel Rakos)

    • Added allocation callbacks to creation functions.

  • Revision 21, 2015-11-10 (Jesse Hall)

    • Added VK_DISPLAY_PLANE_ALPHA_OPAQUE_BIT_KHR, and use VkDisplayPlaneAlphaFlagBitsKHR for VkDisplayPlanePropertiesKHR::alphaMode instead of VkDisplayPlaneAlphaFlagsKHR, since it only represents one mode.

    • Added reserved flags bitmask to VkDisplayPlanePropertiesKHR.

    • Use VkSurfaceTransformFlagBitsKHR instead of obsolete VkSurfaceTransformKHR.

    • Renamed vkGetDisplayPlaneSupportedDisplaysKHR parameters for clarity.

  • Revision 22, 2015-12-18 (James Jones)

    • Added missing "planeIndex" parameter to vkGetDisplayPlaneSupportedDisplaysKHR()

  • Revision 23, 2017-03-13 (James Jones)

    • Closed all remaining issues. The specification and implementations have been shipping with the proposed resolutions for some time now.

    • Removed the sample code and noted it has been integrated into the official Vulkan SDK cube demo.

VK_KHR_display_swapchain

Name String

VK_KHR_display_swapchain

Extension Type

Device extension

Registered Extension Number

4

Revision

9

Extension and Version Dependencies
Contact
Last Modified Date

2017-03-13

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Jeff Vigil, Qualcomm

  • Jesse Hall, Google

This extension provides an API to create a swapchain directly on a device’s display without any underlying window system.

New Object Types

None

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DISPLAY_PRESENT_INFO_KHR

  • Extending VkResult:

    • VK_ERROR_INCOMPATIBLE_DISPLAY_KHR

New Enums

None

New Structures

Issues

1) Should swapchains sharing images each hold a reference to the images, or should it be up to the application to destroy the swapchains and images in an order that avoids the need for reference counting?

RESOLVED: Take a reference. The lifetime of presentable images is already complex enough.

2) Should the srcRect/dstRect parameters be specified as part of the present command, or at swapchain creation time?

RESOLVED: As part of the presentation command. This allows moving and scaling the image on the screen without the need to respecify the mode or create a new swapchain and presentable images.

3) Should srcRect/dstRect be specified as rects, or separate offset/extent values?

RESOLVED: As rects. Specifying them separately might make it easier for hardware to expose support for one but not the other, but in such cases applications must just take care to obey the reported capabilities and not use non-zero offsets or extents that require scaling, as appropriate.

4) How can applications create multiple swapchains that use the same images?

RESOLVED: By calling vkCreateSharedSwapchainsKHR.

An earlier resolution used vkCreateSwapchainKHR, chaining multiple VkSwapchainCreateInfoKHR structures through pNext. In order to allow each swapchain to also allow other extension structs, a level of indirection was used: VkSwapchainCreateInfoKHR::pNext pointed to a different structure, which had both an sType/pNext for additional extensions, and also had a pointer to the next VkSwapchainCreateInfoKHR structure. The number of swapchains to be created could only be found by walking this linked list of alternating structures, and the pSwapchains out parameter was reinterpreted to be an array of VkSwapchainKHR handles.

Another option considered was a method to specify a “shared” swapchain when creating a new swapchain, such that groups of swapchains using the same images could be built up one at a time. This was deemed unusable because drivers need to know all of the displays an image will be used on when determining which internal formats and layouts to use for that image.

Examples

Note

The example code for the VK_KHR_display and VK_KHR_display_swapchain extensions was removed from the appendix after revision 1.0.43. The display swapchain creation example code was ported to the cube demo that is shipped with the official Khronos SDK, and is being kept up-to-date in that location (see: https://github.com/KhronosGroup/Vulkan-Tools/blob/master/cube/cube.c).

Version History

  • Revision 1, 2015-07-29 (James Jones)

    • Initial draft

  • Revision 2, 2015-08-21 (Ian Elliott)

    • Renamed this extension and all of its enumerations, types, functions, etc. This makes it compliant with the proposed standard for Vulkan extensions.

    • Switched from "revision" to "version", including use of the VK_MAKE_VERSION macro in the header file.

  • Revision 3, 2015-09-01 (James Jones)

    • Restore single-field revision number.

  • Revision 4, 2015-09-08 (James Jones)

    • Allow creating multiple swap chains that share the same images using a single call to vkCreateSwapChainKHR().

  • Revision 5, 2015-09-10 (Alon Or-bach)

    • Removed underscores from SWAP_CHAIN in two enums.

  • Revision 6, 2015-10-02 (James Jones)

    • Added support for smart panels/buffered displays.

  • Revision 7, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_display_swapchain to VK_KHR_display_swapchain.

  • Revision 8, 2015-11-03 (Daniel Rakos)

    • Updated sample code based on the changes to VK_KHR_swapchain.

  • Revision 9, 2015-11-10 (Jesse Hall)

    • Replaced VkDisplaySwapchainCreateInfoKHR with vkCreateSharedSwapchainsKHR, changing resolution of issue #4.

  • Revision 10, 2017-03-13 (James Jones)

    • Closed all remaining issues. The specification and implementations have been shipping with the proposed resolutions for some time now.

    • Removed the sample code and noted it has been integrated into the official Vulkan SDK cube demo.

VK_KHR_draw_indirect_count

Name String

VK_KHR_draw_indirect_count

Extension Type

Device extension

Registered Extension Number

170

Revision

1

Extension and Version Dependencies
  • Requires Vulkan 1.0

Contact
Status

Draft

Last Modified Date

2017-08-25

IP Status

No known IP claims.

Contributors
  • Matthaeus G. Chajdas, AMD

  • Derrick Owens, AMD

  • Graham Sellers, AMD

  • Daniel Rakos, AMD

  • Dominik Witczak, AMD

  • Piers Daniell, NVIDIA

This extension is based off the VK_AMD_draw_indirect_count extension. This extension allows an application to source the number of draw calls for indirect draw calls from a buffer. This enables applications to generate arbitrary amounts of draw commands and execute them without host intervention.

Version History

  • Revision 1, 2017-08-25 (Piers Daniell)

    • Initial draft based off VK_AMD_draw_indirect_count

VK_KHR_driver_properties

Name String

VK_KHR_driver_properties

Extension Type

Device extension

Registered Extension Number

197

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2018-04-11

IP Status

No known IP claims.

Contributors
  • Baldur Karlsson

  • Matthaeus G. Chajdas, AMD

  • Piers Daniell, NVIDIA

  • Alexander Galazin, Arm

  • Jesse Hall, Google

  • Daniel Rakos, AMD

This extension provides a new physical device query which allows retrieving information about the driver implementation, allowing applications to determine which physical device corresponds to which particular vendor’s driver, and which conformance test suite version the driver implementation is compliant with.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR

  • VK_MAX_DRIVER_NAME_SIZE_KHR

  • VK_MAX_DRIVER_INFO_SIZE_KHR

New Enums

None.

New Functions

None.

Issues

None.

Examples

None.

Version History

  • Revision 1, 2018-04-11 (Daniel Rakos)

    • Internal revisions

VK_KHR_external_fence

Name String

VK_KHR_external_fence

Extension Type

Device extension

Registered Extension Number

114

Revision

1

Extension and Version Dependencies
Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-05-08

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors

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.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_EXPORT_FENCE_CREATE_INFO_KHR

New Functions

None.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

This extension borrows concepts, semantics, and language from VK_KHR_external_semaphore. That extension’s issues apply equally to this extension.

VK_KHR_external_fence_capabilities

Name String

VK_KHR_external_fence_capabilities

Extension Type

Instance extension

Registered Extension Number

113

Revision

1

Extension and Version Dependencies
Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-05-08

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors

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.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FENCE_INFO_KHR

  • VK_STRUCTURE_TYPE_EXTERNAL_FENCE_PROPERTIES_KHR

  • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR

  • VK_LUID_SIZE_KHR

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

None.

VK_KHR_external_fence_fd

Name String

VK_KHR_external_fence_fd

Extension Type

Device extension

Registered Extension Number

116

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2017-05-08

IP Status

No known IP claims.

Contributors

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.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_IMPORT_FENCE_FD_INFO_KHR

  • VK_STRUCTURE_TYPE_FENCE_GET_FD_INFO_KHR

New Enums

None.

Issues

This extension borrows concepts, semantics, and language from VK_KHR_external_semaphore_fd. That extension’s issues apply equally to this extension.

VK_KHR_external_fence_win32

Name String

VK_KHR_external_fence_win32

Extension Type

Device extension

Registered Extension Number

115

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2017-05-08

IP Status

No known IP claims.

Contributors

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 Windows handles.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_IMPORT_FENCE_WIN32_HANDLE_INFO_KHR

  • VK_STRUCTURE_TYPE_EXPORT_FENCE_WIN32_HANDLE_INFO_KHR

  • VK_STRUCTURE_TYPE_FENCE_GET_WIN32_HANDLE_INFO_KHR

New Enums

None.

Issues

This extension borrows concepts, semantics, and language from VK_KHR_external_semaphore_win32. That extension’s issues apply equally to this extension.

1) Should D3D12 fence handle types be supported, like they are for semaphores?

RESOLVED: No. Doing so would require extending the fence signal and wait operations to provide values to signal / wait for, like VkD3D12FenceSubmitInfoKHR does. A D3D12 fence can be signaled by importing it into a VkSemaphore instead of a VkFence, and applications can check status or wait on the D3D12 fence using non-Vulkan APIs. The convenience of being able to do these operations on VkFence objects doesn’t justify the extra API complexity.

VK_KHR_external_memory

Name String

VK_KHR_external_memory

Extension Type

Device extension

Registered Extension Number

73

Revision

1

Extension and Version Dependencies
Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2016-10-20

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jason Ekstrand, Intel

  • Ian Elliot, Google

  • Jesse Hall, Google

  • Tobias Hector, Imagination Technologies

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Matthew Netsch, Qualcomm Technologies, Inc.

  • Daniel Rakos, AMD

  • Carsten Rohde, NVIDIA

  • Ray Smith, ARM

  • Chad Versace, Google

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.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_BUFFER_CREATE_INFO_KHR

  • VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_KHR

  • VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_KHR

  • VK_QUEUE_FAMILY_EXTERNAL_KHR

  • VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR

New Enums

None.

New Functions

None.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

1) How do applications correlate two physical devices across process or Vulkan instance boundaries?

RESOLVED: New device ID fields have been introduced by VK_KHR_external_memory_capabilities. These fields, combined with the existing VkPhysicalDeviceProperties::driverVersion field can be used to identify compatible devices across processes, drivers, and APIs. VkPhysicalDeviceProperties::pipelineCacheUUID is not sufficient for this purpose because despite its description in the specification, it need only identify a unique pipeline cache format in practice. Multiple devices may be able to use the same pipeline cache data, and hence it would be desirable for all of them to have the same pipeline cache UUID. However, only the same concrete physical device can be used when sharing memory, so an actual unique device ID was introduced. Further, the pipeline cache UUID was specific to Vulkan, but correlation with other, non-extensible APIs is required to enable interoperation with those APIs.

2) If memory objects are shared between processes and APIs, is this considered aliasing according to the rules outlined in the Memory Aliasing section?

RESOLVED: Yes. Applications must take care to obey all restrictions imposed on aliased resources when using memory across multiple Vulkan instances or other APIs.

3) Are new image layouts or metadata required to specify image layouts and layout transitions compatible with non-Vulkan APIs, or with other instances of the same Vulkan driver?

RESOLVED: Separate instances of the same Vulkan driver running on the same GPU should have identical internal layout semantics, so applications have the tools they need to ensure views of images are consistent between the two instances. Other APIs will fall into two categories: Those that are Vulkan- compatible, and those that are Vulkan-incompatible. Vulkan-incompatible APIs will require the image to be in the GENERAL layout whenever they are accessing them.

Note this does not attempt to address cross-device transitions, nor transitions to engines on the same device which are not visible within the Vulkan API. Both of these are beyond the scope of this extension.

4) Is a new barrier flag or operation of some type needed to prepare external memory for handoff to another Vulkan instance or API and/or receive it from another instance or API?

RESOLVED: Yes. Some implementations need to perform additional cache management when transitioning memory between address spaces, and other APIs, instances, or processes may operate in a separate address space. Options for defining this transition include:

A new structure has the advantage that the type of external transition can be described in as much detail as necessary. However, there is not currently a known need for anything beyond differentiating external vs. internal accesses, so this is likely an over-engineered solution. The access flag bit has the advantage that it can be applied at buffer, image, or global granularity, and semantically it maps pretty well to the operation being described. Additionally, the API already includes VK_ACCESS_MEMORY_READ_BIT and VK_ACCESS_MEMORY_WRITE_BIT which appear to be intended for this purpose. However, there is no obvious pipeline stage that would correspond to an external access, and therefore no clear way to use VK_ACCESS_MEMORY_READ_BIT or VK_ACCESS_MEMORY_WRITE_BIT. VkDependencyFlags and VkPipelineStageFlags operate at command granularity rather than image or buffer granularity, which would make an entire pipeline barrier an internal→external or external→internal barrier. This may not be a problem in practice, but seems like the wrong scope. Another downside of VkDependencyFlags is that it lacks inherent directionality: There are not src and dst variants of it in the barrier or dependency description semantics, so two bits might need to be added to describe both internal→external and external→internal transitions. Transitioning a resource to a special queue family corresponds well with the operation of transitioning to a separate Vulkan instance, in that both operations ideally include scheduling a barrier on both sides of the transition: Both the releasing and the acquiring queue or process. Using a special queue family requires adding an additional reserved queue family index. Re-using VK_QUEUE_FAMILY_IGNORED would have left it unclear how to transition a concurrent usage resource from one process to another, since the semantics would have likely been equivalent to the currently-ignored transition of VK_QUEUE_FAMILY_IGNORED → VK_QUEUE_FAMILY_IGNORED. Fortunately, creating a new reserved queue family index is not invasive.

Based on the above analysis, the approach of transitioning to a special “external” queue family was chosen.

5) Do internal driver memory arrangements and/or other internal driver image properties need to be exported and imported when sharing images across processes or APIs.

RESOLVED: Some vendors claim this is necessary on their implementations, but it was determined that the security risks of allowing opaque meta data to be passed from applications to the driver were too high. Therefore, implementations which require metadata will need to associate it with the objects represented by the external handles, and rely on the dedicated allocation mechanism to associate the exported and imported memory objects with a single image or buffer.

6) Most prior interoperation and cross-process sharing APIs have been based on image-level sharing. Should Vulkan sharing be based on memory-object sharing or image sharing?

RESOLVED: These extensions have assumed memory-level sharing is the correct granularity. Vulkan is a lower-level API than most prior APIs, and as such attempts to closely align with to the underlying primitives of the hardware and system-level drivers it abstracts. In general, the resource that holds the backing store for both images and buffers of various types is memory. Images and buffers are merely metadata containing brief descriptions of the layout of bits within that memory.

Because memory object-based sharing is aligned with the overall Vulkan API design, it exposes the full power of Vulkan on external objects. External memory can be used as backing for sparse images, for example, whereas such usage would be awkward at best with a sharing mechanism based on higher-level primitives such as images. Further, aligning the mechanism with the API in this way provides some hope of trivial compatibility with future API enhancements. If new objects backed by memory objects are added to the API, they too can be used across processes with minimal additions to the base external memory APIs.

Earlier APIs implemented interop at a higher level, and this necessitated entirely separate sharing APIs for images and buffers. To co-exist and interoperate with those APIs, the Vulkan external sharing mechanism must accommodate their model. However, if it can be agreed that memory-based sharing is the more desirable and forward-looking design, legacy interoperation considerations can be considered another reason to favor memory-based sharing: While native and legacy driver primitives that may be used to implement sharing may not be as low-level as the API here suggests, raw memory is still the least common denominator among the types. Image-based sharing can be cleanly derived from a set of base memory- object sharing APIs with minimal effort, whereas image-based sharing does not generalize well to buffer or raw-memory sharing. Therefore, following the general Vulkan design principle of minimalism, it is better to expose even interopability with image-based native and external primitives via the memory sharing API, and place sufficient limits on their usage to ensure they can be used only as backing for equivalent Vulkan images. This provides a consistent API for applications regardless of which platform or external API they are targeting, which makes development of multi-API and multi-platform applications simpler.

7) Should Vulkan define a common external handle type and provide Vulkan functions to facilitate cross-process sharing of such handles rather than relying on native handles to define the external objects?

RESOLVED: No. Cross-process sharing of resources is best left to native platforms. There are myriad security and extensibility issues with such a mechanism, and attempting to re-solve all those issues within Vulkan does not align with Vulkan’s purpose as a graphics API. If desired, such a mechanism could be built as a layer or helper library on top of the opaque native handle defined in this family of extensions.

8) Must implementations provide additional guarantees about state implicitly included in memory objects for those memory objects that may be exported?

RESOLVED: Implementations must ensure that sharing memory objects does not transfer any information between the exporting and importing instances and APIs other than that required to share the data contained in the memory objects explicitly shared. As specific examples, data from previously freed memory objects that used the same underlying physical memory, and data from memory obects using adjacent physical memory must not be visible to applications importing an exported memory object.

9) Must implementations validate external handles the application provides as input to memory import operations?

RESOLVED: Implementations must return an error to the application if the provided memory handle cannot be used to complete the requested import operation. However, implementations need not validate handles are of the exact type specified by the application.

VK_KHR_external_memory_capabilities

Name String

VK_KHR_external_memory_capabilities

Extension Type

Instance extension

Registered Extension Number

72

Revision

1

Extension and Version Dependencies
Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2016-10-17

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Ian Elliot, Google

  • Jesse Hall, Google

  • James Jones, NVIDIA

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.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_IMAGE_FORMAT_INFO_KHR

  • VK_STRUCTURE_TYPE_EXTERNAL_IMAGE_FORMAT_PROPERTIES_KHR

  • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_BUFFER_INFO_KHR

  • VK_STRUCTURE_TYPE_EXTERNAL_BUFFER_PROPERTIES_KHR

  • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR

  • VK_LUID_SIZE_KHR

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

1) Why do so many external memory capabilities need to be queried on a per-memory-handle-type basis?

PROPOSED RESOLUTION: This is because some handle types are based on OS-native objects that have far more limited capabilities than the very generic Vulkan memory objects. Not all memory handle types can name memory objects that support 3D images, for example. Some handle types cannot even support the deferred image and memory binding behavior of Vulkan and require specifying the image when allocating or importing the memory object.

2) Do the VkExternalImageFormatPropertiesKHR and VkExternalBufferPropertiesKHR structs need to include a list of memory type bits that support the given handle type?

PROPOSED RESOLUTION: No. The memory types that don’t support the handle types will simply be filtered out of the results returned by vkGetImageMemoryRequirements and vkGetBufferMemoryRequirements when a set of handle types was specified at image or buffer creation time.

3) Should the non-opaque handle types be moved to their own extension?

PROPOSED RESOLUTION: Perhaps. However, defining the handle type bits does very little and does not require any platform-specific types on its own, and it’s easier to maintain the bitfield values in a single extension for now. Presumably more handle types could be added by separate extensions though, and it would be midly weird to have some platform-specific ones defined in the core spec and some in extensions

4) Do we need a D3D11_TILEPOOL type?

PROPOSED RESOLUTION: No. This is technically possible, but the synchronization is awkward. D3D11 surfaces must be synchronized using shared mutexes, and these synchronization primitives are shared by the entire memory object, so D3D11 shared allocations divided among multiple buffer and image bindings may be difficult to synchronize.

5) Should the Windows 7-compatible handle types be named “KMT” handles or “GLOBAL_SHARE” handles?

PROPOSED RESOLUTION: KMT, simply because it is more concise.

6) How do applications identify compatible devices and drivers across instance, process, and API boundaries when sharing memory?

PROPOSED RESOLUTION: New device properties are exposed that allow applications to correctly correlate devices and drivers. A device and driver UUID that must both match to ensure sharing compatibility between two Vulkan instances, or a Vulkan instance and an extensible external API are added. To allow correlating with Direct3D devices, a device LUID is added that corresponds to a DXGI adapter LUID. A driver ID is not needed for Direct3D because mismatched driver component versions are not a currently supported configuration on the Windows OS. Should support for such configurations be introduced at the OS level, further Vulkan extensions would be needed to correlate userspace component builds.

VK_KHR_external_memory_fd

Name String

VK_KHR_external_memory_fd

Extension Type

Device extension

Registered Extension Number

75

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2016-10-21

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

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.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_IMPORT_MEMORY_FD_INFO_KHR

  • VK_STRUCTURE_TYPE_MEMORY_FD_PROPERTIES_KHR

  • VK_STRUCTURE_TYPE_MEMORY_GET_FD_INFO_KHR

New Enums

None.

Issues

1) Does the application need to close the file descriptor returned by vkGetMemoryFdKHR?

RESOLVED: Yes, unless it is passed back in to a driver instance to import the memory. A successful get call transfers ownership of the file descriptor to the application, and a successful import transfers it back to the driver. Destroying the original memory object will not close the file descriptor or remove its reference to the underlying memory resource associated with it.

2) Do drivers ever need to expose multiple file descriptors per memory object?

RESOLVED: No. This would indicate there are actually multiple memory objects, rather than a single memory object.

3) How should the valid size and memory type for POSIX file descriptor memory handles created outside of Vulkan be specified?

RESOLVED: The valid memory types are queried directly from the external handle. The size will be specified by future extensions that introduce such external memory handle types.

VK_KHR_external_memory_win32

Name String

VK_KHR_external_memory_win32

Extension Type

Device extension

Registered Extension Number

74

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2016-10-21

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Carsten Rohde, NVIDIA

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 Windows handles from Vulkan memory objects and to import Vulkan memory objects from Windows handles exported from other Vulkan memory objects or from similar resources in other APIs.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR

  • VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_KHR

  • VK_STRUCTURE_TYPE_MEMORY_WIN32_HANDLE_PROPERTIES_KHR

  • VK_STRUCTURE_TYPE_MEMORY_GET_WIN32_HANDLE_INFO_KHR

New Enums

None.

Issues

1) Do applications need to call CloseHandle() on the values returned from vkGetMemoryWin32HandleKHR when handleType is VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR?

RESOLVED: Yes, unless it is passed back in to another driver instance to import the object. A successful get call transfers ownership of the handle to the application. Destroying the memory object will not destroy the handle or the handle’s reference to the underlying memory resource.

2) Should the language regarding KMT/Windows 7 handles be moved to a separate extension so that it can be deprecated over time?

RESOLVED: No. Support for them can be deprecated by drivers if they choose, by no longer returning them in the supported handle types of the instance level queries.

3) How should the valid size and memory type for windows memory handles created outside of Vulkan be specified?

RESOLVED: The valid memory types are queried directly from the external handle. The size is determined by the associated image or buffer memory requirements for external handle types that require dedicated allocations, and by the size specified when creating the object from which the handle was exported for other external handle types.

VK_KHR_external_semaphore

Name String

VK_KHR_external_semaphore

Extension Type

Device extension

Registered Extension Number

78

Revision

1

Extension and Version Dependencies
Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2016-10-21

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jason Ekstrand, Intel

  • Jesse Hall, Google

  • Tobias Hector, Imagination Technologies

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Matthew Netsch, Qualcomm Technologies, Inc.

  • Ray Smith, ARM

  • Chad Versace, Google

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.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO_KHR

  • VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR

New Functions

None.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

1) Should there be restrictions on what side effects can occur when waiting on imported semaphores that are in an invalid state?

RESOLVED: Yes. Normally, validating such state would be the responsibility of the application, and the implementation would be free to enter an undefined state if valid usage rules were violated. However, this could cause security concerns when using imported semaphores, as it would require the importing application to trust the exporting application to ensure the state is valid. Requiring this level of trust is undesirable for many potential use cases.

2) Must implementations validate external handles the application provides as input to semaphore state import operations?

RESOLVED: Implementations must return an error to the application if the provided semaphore state handle cannot be used to complete the requested import operation. However, implementations need not validate handles are of the exact type specified by the application.

VK_KHR_external_semaphore_capabilities

Name String

VK_KHR_external_semaphore_capabilities

Extension Type

Instance extension

Registered Extension Number

77

Revision

1

Extension and Version Dependencies
Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2016-10-20

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

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.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_SEMAPHORE_INFO_KHR

  • VK_STRUCTURE_TYPE_EXTERNAL_SEMAPHORE_PROPERTIES_KHR

  • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR

  • VK_LUID_SIZE_KHR

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

VK_KHR_external_semaphore_fd

Name String

VK_KHR_external_semaphore_fd

Extension Type

Device extension

Registered Extension Number

80

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2016-10-21

IP Status

No known IP claims.

Contributors
  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Carsten Rohde, NVIDIA

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.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_FD_INFO_KHR

  • VK_STRUCTURE_TYPE_SEMAPHORE_GET_FD_INFO_KHR

New Enums

None.

Issues

1) Does the application need to close the file descriptor returned by vkGetSemaphoreFdKHR?

RESOLVED: Yes, unless it is passed back in to a driver instance to import the semaphore. A successful get call transfers ownership of the file descriptor to the application, and a successful import transfers it back to the driver. Destroying the original semaphore object will not close the file descriptor or remove its reference to the underlying semaphore resource associated with it.

VK_KHR_external_semaphore_win32

Name String

VK_KHR_external_semaphore_win32

Extension Type

Device extension

Registered Extension Number

79

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2016-10-21

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Carsten Rohde, NVIDIA

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 Windows handles.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_WIN32_HANDLE_INFO_KHR

  • VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_WIN32_HANDLE_INFO_KHR

  • VK_STRUCTURE_TYPE_D3D12_FENCE_SUBMIT_INFO_KHR

  • VK_STRUCTURE_TYPE_SEMAPHORE_GET_WIN32_HANDLE_INFO_KHR

New Enums

None.

Issues

1) Do applications need to call CloseHandle() on the values returned from vkGetSemaphoreWin32HandleKHR when handleType is VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR?

RESOLVED: Yes, unless it is passed back in to another driver instance to import the object. A successful get call transfers ownership of the handle to the application. Destroying the semaphore object will not destroy the handle or the handle’s reference to the underlying semaphore resource.

2) Should the language regarding KMT/Windows 7 handles be moved to a separate extension so that it can be deprecated over time?

RESOLVED: No. Support for them can be deprecated by drivers if they choose, by no longer returning them in the supported handle types of the instance level queries.

3) Should applications be allowed to specify additional object attributes for shared handles?

RESOLVED: Yes. Applications will be allowed to provide similar attributes to those they would to any other handle creation API.

4) How do applications communicate the desired fence values to use with D3D12_FENCE-based Vulkan semaphores?

RESOLVED: There are a couple of options. The values for the signaled and reset states could be communicated up front when creating the object and remain static for the life of the Vulkan semaphore, or they could be specified using auxiliary structures when submitting semaphore signal and wait operations, similar to what is done with the keyed mutex extensions. The latter is more flexible and consistent with the keyed mutex usage, but the former is a much simpler API.

Since Vulkan tends to favor flexibility and consistency over simplicity, a new structure specifying D3D12 fence acquire and release values is added to the vkQueueSubmit function.

VK_KHR_get_display_properties2

Name String

VK_KHR_get_display_properties2

Extension Type

Instance extension

Registered Extension Number

122

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2017-02-21

IP Status

No known IP claims.

Contributors
  • Ian Elliott, Google

  • James Jones, NVIDIA

This extension provides new entry points to query device display properties and 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_display equivalent of the VK_KHR_get_physical_device_properties2 extension.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DISPLAY_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_PLANE_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_MODE_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_PLANE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_PLANE_CAPABILITIES_2_KHR

New Enums

None.

Issues

1) What should this extension be named?

RESOLVED: VK_KHR_get_display_properties2. Other alternatives:

  • VK_KHR_display2

  • One extension, combined with VK_KHR_surface_capabilites2.

2) Should extensible input structs be added for these new functions:

RESOLVED:

3) Should additional display query functions be extended?

RESOLVED:

Version History

  • Revision 1, 2017-02-21 (James Jones)

    • Initial draft.

VK_KHR_get_memory_requirements2

Name String

VK_KHR_get_memory_requirements2

Extension Type

Device extension

Registered Extension Number

147

Revision

1

Extension and Version Dependencies
  • Requires Vulkan 1.0

Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jason Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Jesse Hall, Google

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.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BUFFER_MEMORY_REQUIREMENTS_INFO_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_MEMORY_REQUIREMENTS_INFO_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_SPARSE_MEMORY_REQUIREMENTS_INFO_2_KHR

    • VK_STRUCTURE_TYPE_MEMORY_REQUIREMENTS_2_KHR

    • VK_STRUCTURE_TYPE_SPARSE_IMAGE_MEMORY_REQUIREMENTS_2_KHR

New Enums

None.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

None.

Version History

  • Revision 1, 2017-03-23 (Jason Ekstrand)

    • Internal revisions

VK_KHR_get_physical_device_properties2

Name String

VK_KHR_get_physical_device_properties2

Extension Type

Instance extension

Registered Extension Number

60

Revision

1

Extension and Version Dependencies
  • Requires Vulkan 1.0

Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jeff Bolz, NVIDIA

  • Ian Elliott, Google

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.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHR

    • VK_STRUCTURE_TYPE_QUEUE_FAMILY_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_SPARSE_IMAGE_FORMAT_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SPARSE_IMAGE_FORMAT_INFO_2_KHR

New Enums

None.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

None.

Examples

    // Get features with a hypothetical future extension.
    VkHypotheticalExtensionFeaturesKHR hypotheticalFeatures =
    {
        VK_STRUCTURE_TYPE_HYPOTHETICAL_FEATURES_KHR,                            // sType
        NULL,                                                                   // pNext
    };

    VkPhysicalDeviceFeatures2KHR features =
    {
        VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR,                       // sType
        &hypotheticalFeatures,                                                  // pNext
    };

    // After this call, features and hypotheticalFeatures have been filled out.
    vkGetPhysicalDeviceFeatures2KHR(physicalDevice, &features);

    // Properties/limits can be chained and queried similarly.

    // Enable some features:
    VkHypotheticalExtensionFeaturesKHR enabledHypotheticalFeatures =
    {
        VK_STRUCTURE_TYPE_HYPOTHETICAL_FEATURES_KHR,                            // sType
        NULL,                                                                   // pNext
    };

    VkPhysicalDeviceFeatures2KHR enabledFeatures =
    {
        VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR,                       // sType
        &enabledHypotheticalFeatures,                                           // pNext
    };

    enabledFeatures.features.xyz = VK_TRUE;
    enabledHypotheticalFeatures.abc = VK_TRUE;

    VkDeviceCreateInfo deviceCreateInfo =
    {
        VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,                                   // sType
        &enabledFeatures,                                                       // pNext
        ...
        NULL,                                                                   // pEnabledFeatures
    }

    VkDevice device;
    vkCreateDevice(physicalDevice, &deviceCreateInfo, NULL, &device);

Version History

  • Revision 1, 2016-09-12 (Jeff Bolz)

    • Internal revisions

  • Revision 2, 2016-11-02 (Ian Elliott)

    • Added ability for applications to use the physical-device components of device extensions before vkCreateDevice is called.

VK_KHR_get_surface_capabilities2

Name String

VK_KHR_get_surface_capabilities2

Extension Type

Instance extension

Registered Extension Number

120

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2017-02-27

IP Status

No known IP claims.

Contributors
  • Ian Elliott, Google

  • James Jones, NVIDIA

  • Alon Or-bach, Samsung

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.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SURFACE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_KHR

    • VK_STRUCTURE_TYPE_SURFACE_FORMAT_2_KHR

New Enums

None.

Issues

1) What should this extension be named?

RESOLVED: VK_KHR_get_surface_capabilities2. Other alternatives:

  • VK_KHR_surface2

  • One extension, combining a separate display-specific query extension.

2) Should additional WSI query functions be extended?

RESOLVED:

Version History

  • Revision 1, 2017-02-27 (James Jones)

    • Initial draft.

VK_KHR_image_format_list

Name String

VK_KHR_image_format_list

Extension Type

Device extension

Registered Extension Number

148

Revision

1

Extension and Version Dependencies
  • Requires Vulkan 1.0

Contact
Last Modified Date

2017-03-20

IP Status

No known IP claims.

Contributors
  • Jason Ekstrand, Intel

  • Jan-Harald Fredriksen, ARM

  • Jeff Bolz, NVIDIA

  • Jeff Leger, Qualcomm

  • Neil Henning, Codeplay

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.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_IMAGE_FORMAT_LIST_CREATE_INFO_KHR

New Enums

None.

New Functions

None.

Issues

VK_KHR_incremental_present

Name String

VK_KHR_incremental_present

Extension Type

Device extension

Registered Extension Number

85

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2016-11-02

IP Status

No known IP claims.

Contributors
  • Ian Elliott, Google

  • Jesse Hall, Google

  • Alon Or-bach, Samsung

  • James Jones, NVIDIA

  • Daniel Rakos, AMD

  • Ray Smith, ARM

  • Mika Isojarvi, Google

  • Jeff Juliano, NVIDIA

  • Jeff Bolz, NVIDIA

This device extension extends vkQueuePresentKHR, from the VK_KHR_swapchain extension, allowing an application to specify a list of rectangular, modified regions of each image to present. This should be used in situations where an application is only changing a small portion of the presentable images within a swapchain, since it enables the presentation engine to avoid wasting time presenting parts of the surface that have not changed.

This extension is leveraged from the EGL_KHR_swap_buffers_with_damage extension.

New Object Types

None.

New Enum Constants

New Enums

None.

New Functions

None.

Examples

None.

Issues

1) How should we handle steroescopic-3D swapchains? We need to add a layer for each rectangle. One approach is to create another struct that contains the VkRect2D plus layer, and have VkPresentRegionsKHR point to an array of that struct. Another approach is to have two parallel arrays, pRectangles and pLayers, where pRectangles[i] and pLayers[i] must be used together. Which approach should we use, and if the array of a new structure, what should that be called?

RESOLVED: Create a new structure, which is a VkRect2D plus a layer, and will be called VkRectLayerKHR.

2) Where is the origin of the VkRectLayerKHR?

RESOLVED: The upper left corner of the presentable image(s) of the swapchain, per the definition of framebuffer coordinates.

3) Does the rectangular region, VkRectLayerKHR, specify pixels of the swapchain’s image(s), or of the surface?

RESOLVED: Of the image(s). Some presentation engines may scale the pixels of a swapchain’s image(s) to the size of the surface. The size of the swapchain’s image(s) will be consistent, where the size of the surface may vary over time.

4) What if all of the rectangles for a given swapchain contain a width and/or height of zero?

RESOLVED: The application is indicating that no pixels changed since the last present. The presentation engine may use such a hint and not update any pixels for the swapchain. However, all other semantics of vkQueuePresentKHR must still be honored, including waiting for semaphores to signal.

Version History

  • Revision 1, 2016-11-02 (Ian Elliott)

    • Internal revisions

VK_KHR_maintenance1

Name String

VK_KHR_maintenance1

Extension Type

Device extension

Registered Extension Number

70

Revision

2

Extension and Version Dependencies
  • Requires Vulkan 1.0

Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2018-03-13

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Dan Ginsburg, Valve

  • Daniel Koch, NVIDIA

  • Daniel Rakos, AMD

  • Jan-Harald Fredriksen, ARM

  • Jason Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Jesse Hall, Google

  • John Kessenich, Google

  • Michael Worcester, Imagination Technologies

  • Neil Henning, Codeplay Software Ltd.

  • Piers Daniell, NVIDIA

  • Slawomir Grajewski, Intel

  • Tobias Hector, Imagination Technologies

  • Tom Olson, ARM

VK_KHR_maintenance1 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 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.

New Object Types

None.

New Enum Constants

  • VK_ERROR_OUT_OF_POOL_MEMORY_KHR

  • VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR

  • VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

  • VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT_KHR

New Enums

None.

New Structures

None.

New Functions

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

  1. Are viewports with zero height allowed?

    RESOLVED: Yes, although they have low utility.

Version History

  • Revision 1, 2016-10-26 (Piers Daniell)

    • Internal revisions

  • Revision 2, 2018-03-13 (Jon Leech)

    • Add issue for zero-height viewports

VK_KHR_maintenance2

Name String

VK_KHR_maintenance2

Extension Type

Device extension

Registered Extension Number

118

Revision

1

Extension and Version Dependencies
  • Requires Vulkan 1.0

Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-09-05

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Michael Worcester, Imagination Technologies

  • Stuart Smith, Imagination Technologies

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

  • Jan-Harald Fredriksen, ARM

  • Daniel Rakos, AMD

  • Neil Henning, Codeplay

  • Piers Daniell, NVIDIA

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.

Input Attachment Specification

Input attachment specification allows an application to specify which aspect of a multi-aspect image (e.g. a combined depth stencil format) will be accessed via a subpassLoad operation.

On some implementations there may be a performance penalty if the implementation does not know (at vkCreateRenderPass time) which aspect(s) of multi-aspect images can be accessed as input attachments.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_RENDER_PASS_INPUT_ATTACHMENT_ASPECT_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_POINT_CLIPPING_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_USAGE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_TESSELLATION_DOMAIN_ORIGIN_STATE_CREATE_INFO_KHR

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT_KHR

    • VK_IMAGE_CREATE_EXTENDED_USAGE_BIT_KHR

  • Extending VkImageLayout

    • VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL_KHR

    • VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL_KHR

  • VK_POINT_CLIPPING_BEHAVIOR_ALL_CLIP_PLANES_KHR

  • VK_POINT_CLIPPING_BEHAVIOR_USER_CLIP_PLANES_ONLY_KHR

New Functions

None.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Input Attachment Specification Example

Consider the case where a render pass has two subpasses and two attachments.

Attachment 0 has the format VK_FORMAT_D24_UNORM_S8_UINT, attachment 1 has some color format.

Subpass 0 writes to attachment 0, subpass 1 reads only the depth information from attachment 0 (using inputAttachmentRead) and writes to attachment 1.

    VkInputAttachmentAspectReferenceKHR references[] = {
        {
            .subpass = 1,
            .inputAttachmentIndex = 0,
            .aspectMask = VK_IMAGE_ASPECT_DEPTH_BIT
        }
    };

    VkRenderPassInputAttachmentAspectCreateInfoKHR specifyAspects = {
        .sType = VK_STRUCTURE_TYPE_RENDER_PASS_INPUT_ATTACHMENT_ASPECT_CREATE_INFO_KHR,
        .pNext = NULL,
        .aspectReferenceCount = 1,
        .pAspectReferences = references
    };


    VkRenderPassCreateInfo createInfo = {
        ...
        .pNext = &specifyAspects,
        ...
    }

    vkCreateRenderPass(...);

Issues

1) What is the default tessellation domain origin?

RESOLVED: Vulkan 1.0 originally inadvertently documented a lower-left origin, but the conformance tests and all implementations implemented an upper-left origin. This extension adds a control to select between lower-left (for compatibility with OpenGL) and upper-left, and we retroactively fix unextended Vulkan to have a default of an upper-left origin.

Version History

  • Revision 1, 2017-04-28

VK_KHR_maintenance3

Name String

VK_KHR_maintenance3

Extension Type

Device extension

Registered Extension Number

169

Revision

1

Extension and Version Dependencies
Deprecation state
  • Promoted to Vulkan 1.1

Contact
Status

Draft

Last Modified Date

2017-09-05

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jeff Bolz, NVIDIA

VK_KHR_maintenance3 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:

  • A limit on the maximum number of descriptors that are supported in a single descriptor set layout. Some implementations have a limit on the total size of descriptors in a set, which cannot be expressed in terms of the limits in Vulkan 1.0.

  • A limit on the maximum size of a single memory allocation. Some platforms have kernel interfaces that limit the maximum size of an allocation.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_3_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_SUPPORT_KHR

New Enums

None.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

None.

Version History

  • Revision 1, 2017-08-22

VK_KHR_multiview

Name String

VK_KHR_multiview

Extension Type

Device extension

Registered Extension Number

54

Revision

1

Extension and Version Dependencies
Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2016-10-28

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jeff Bolz, NVIDIA

This extension has the same goal as the OpenGL ES GL_OVR_multiview extension - it enables rendering to multiple “views” by recording a single set of commands to be executed with slightly different behavior for each view. It includes a concise way to declare a render pass with multiple views, and gives implementations freedom to render the views in the most efficient way possible.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PROPERTIES_KHR

  • Extending VkDependencyFlagBits

    • VK_DEPENDENCY_VIEW_LOCAL_BIT_KHR

New Enums

None.

New Functions

None.

New Built-In Variables

New SPIR-V Capabilities

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

None.

Examples

None.

Version History

  • Revision 1, 2016-10-28 (Jeff Bolz)

    • Internal revisions

VK_KHR_push_descriptor

Name String

VK_KHR_push_descriptor

Extension Type

Device extension

Registered Extension Number

81

Revision

2

Extension and Version Dependencies
Contact
Last Modified Date

2017-09-12

IP Status

No known IP claims.

Contributors
  • Jeff Bolz, NVIDIA

  • Michael Worcester, Imagination Technologies

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.

New Object Types

None.

New Enum Constants

New Enums

None.

Issues

None.

Examples

None.

Version History

  • Revision 1, 2016-10-15 (Jeff Bolz)

    • Internal revisions

  • Revision 2, 2017-09-12 (Tobias Hector)

    • Added interactions with Vulkan 1.1

VK_KHR_relaxed_block_layout

Name String

VK_KHR_relaxed_block_layout

Extension Type

Device extension

Registered Extension Number

145

Revision

1

Extension and Version Dependencies
  • Requires Vulkan 1.0

Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-03-26

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • John Kessenich, Google

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.

See Offset and Stride Assignment for details.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2017-03-26 (JohnK)

VK_KHR_sampler_mirror_clamp_to_edge

Name String

VK_KHR_sampler_mirror_clamp_to_edge

Extension Type

Device extension

Registered Extension Number

15

Revision

1

Extension and Version Dependencies
  • Requires Vulkan 1.0

Contact
Last Modified Date

2016-02-16

Contributors
  • Tobias Hector, Imagination Technologies

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.

New Enum Constants

Example

Creating a sampler with the new address mode in each dimension

    VkSamplerCreateInfo createInfo =
    {
        VK_STRUCTURE_TYPE_SAMPLER_CREATE_INFO // sType
        // Other members set to application-desired values
    };

    createInfo.addressModeU = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;
    createInfo.addressModeV = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;
    createInfo.addressModeW = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;

    VkSampler sampler;
    VkResult result = vkCreateSampler(
        device,
        &createInfo,
        &sampler);

Version History

  • Revision 1, 2016-02-16 (Tobias Hector)

    • Initial draft

VK_KHR_sampler_ycbcr_conversion

Name String

VK_KHR_sampler_ycbcr_conversion

Extension Type

Device extension

Registered Extension Number

157

Revision

1

Extension and Version Dependencies
Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-08-11

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Andrew Garrard, Samsung Electronics

  • Tobias Hector, Imagination Technologies

  • James Jones, NVIDIA

  • Daniel Koch, NVIDIA

  • Daniel Rakos, AMD

  • Romain Guy, Google

  • Jesse Hall, Google

  • Tom Cooksey, ARM Ltd

  • Jeff Leger, Qualcomm Technologies, Inc

  • Jan-Harald Fredriksen, ARM Ltd

  • Jan Outters, Samsung Electronics

  • Alon Or-bach, Samsung Electronics

  • Michael Worcester, Imagination Technologies

  • Jeff Bolz, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Matthew Netsch, Qualcomm Technologies, Inc

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.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_PLANE_MEMORY_INFO_KHR

    • VK_STRUCTURE_TYPE_IMAGE_PLANE_MEMORY_REQUIREMENTS_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_YCBCR_CONVERSION_FEATURES_KHR

  • Extending VkFormat:

    • VK_FORMAT_G8B8G8R8_422_UNORM_KHR

    • VK_FORMAT_B8G8R8G8_422_UNORM_KHR

    • VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM_KHR

    • VK_FORMAT_G8_B8R8_2PLANE_420_UNORM_KHR

    • VK_FORMAT_G8_B8_R8_3PLANE_422_UNORM_KHR

    • VK_FORMAT_G8_B8R8_2PLANE_422_UNORM_KHR

    • VK_FORMAT_G8_B8_R8_3PLANE_444_UNORM_KHR

    • VK_FORMAT_R10X6_UNORM_PACK16_KHR

    • VK_FORMAT_R10X6G10X6_UNORM_2PACK16_KHR

    • VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16_KHR

    • VK_FORMAT_G10X6B10X6G10X6R10X6_422_UNORM_4PACK16_KHR

    • VK_FORMAT_B10X6G10X6R10X6G10X6_422_UNORM_4PACK16_KHR

    • VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16_KHR

    • VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16_KHR

    • VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_422_UNORM_3PACK16_KHR

    • VK_FORMAT_G10X6_B10X6R10X6_2PLANE_422_UNORM_3PACK16_KHR

    • VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_444_UNORM_3PACK16_KHR

    • VK_FORMAT_R12X4_UNORM_PACK16_KHR

    • VK_FORMAT_R12X4G12X4_UNORM_2PACK16_KHR

    • VK_FORMAT_R12X4G12X4B12X4A12X4_UNORM_4PACK16_KHR

    • VK_FORMAT_G12X4B12X4G12X4R12X4_422_UNORM_4PACK16_KHR

    • VK_FORMAT_B12X4G12X4R12X4G12X4_422_UNORM_4PACK16_KHR

    • VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_420_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4_B12X4R12X4_2PLANE_420_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_422_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4_B12X4R12X4_2PLANE_422_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_444_UNORM_3PACK16_KHR

    • VK_FORMAT_G16B16G16R16_422_UNORM_KHR

    • VK_FORMAT_B16G16R16G16_422_UNORM_KHR

    • VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM_KHR

    • VK_FORMAT_G16_B16R16_2PLANE_420_UNORM_KHR

    • VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM_KHR

    • VK_FORMAT_G16_B16R16_2PLANE_422_UNORM_KHR

    • VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM_KHR

  • Extending VkImageAspectFlagBits:

    • VK_IMAGE_ASPECT_PLANE_0_BIT_KHR

    • VK_IMAGE_ASPECT_PLANE_1_BIT_KHR

    • VK_IMAGE_ASPECT_PLANE_2_BIT_KHR

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_DISJOINT_BIT_KHR

  • Extending VkFormatFeatureFlagBits:

    • VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT_KHR

    • VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT_KHR

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT_KHR

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT_KHR

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT_KHR

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT_KHR

    • VK_FORMAT_FEATURE_DISJOINT_BIT_KHR

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2017-01-24 (Andrew Garrard)

    • Initial draft

  • Revision 2, 2017-01-25 (Andrew Garrard)

    • After initial feedback

  • Revision 3, 2017-01-27 (Andrew Garrard)

    • Higher bit depth formats, renaming, swizzle

  • Revision 4, 2017-02-22 (Andrew Garrard)

    • Added query function, formats as RGB, clarifications

  • Revision 5, 2017-04 (Andrew Garrard)

    • Simplified query and removed output conversions

  • Version 6, 2017-4-24 (Andrew Garrard)

    • Tidying, incorporated new image query, restored transfer functions

  • Version 7, 2017-04-25 (Andrew Garrard)

    • Added cosited option/midpoint requirement for formats, "bypassConversion"

  • Version 8, 2017-04-25 (Andrew Garrard)

    • Simplified further

  • Version 9, 2017-04-27 (Andrew Garrard)

    • Disjoint no more

  • Version 10, 2017-04-28 (Andrew Garrard)

    • Restored disjoint

  • Version 11, 2017-04-29 (Andrew Garrard)

    • Now Ycbcr conversion, and KHR

  • Version 12, 2017-06-06 (Andrew Garrard)

    • Added conversion to image view creation

  • Version 13, 2017-07-13 (Andrew Garrard)

    • Allowed cosited-only chroma samples for formats

  • Version 14, 2017-08-11 (Andrew Garrard)

    • Reflected quantization changes in BT.2100-1

VK_KHR_shader_atomic_int64

Name String

VK_KHR_shader_atomic_int64

Extension Type

Device extension

Registered Extension Number

181

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2018-07-05

Interactions and External Dependencies
Contributors
  • Aaron Hagan, AMD

  • Daniel Rakos, AMD

  • Jeff Bolz, NVIDIA

  • Neil Henning, Codeplay

This extension advertises the SPIR-V Int64Atomics capability for Vulkan, which allows a shader to contain 64-bit atomic operations on signed and unsigned integers. The supported operations include OpAtomicMin, OpAtomicMax, OpAtomicAnd, OpAtomicOr, OpAtomicXor, OpAtomicAdd, OpAtomicExchange, and OpAtomicCompareExchange.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_INT64_FEATURES_KHR

New SPIR-V Capabilities

Version History

  • Revision 1, 2018-07-05 (Aaron Hagan)

    • Internal revisions

VK_KHR_shader_draw_parameters

Name String

VK_KHR_shader_draw_parameters

Extension Type

Device extension

Registered Extension Number

64

Revision

1

Extension and Version Dependencies
  • Requires Vulkan 1.0

Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Daniel Koch, NVIDIA Corporation

  • Jeff Bolz, NVIDIA

  • Daniel Rakos, AMD

  • Jan-Harald Fredriksen, ARM

  • John Kessenich, Google

  • Stuart Smith, IMG

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.

New Object Types

None.

New Enum Constants

None.

New Enums

None.

New Structures

None.

New Functions

None.

New Built-In Variables

New SPIR-V Capabilities

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, however a feature bit was added to distinguish whether it is actually available or not.

Issues

1) Is this the same functionality as GL_ARB_shader_draw_parameters?

RESOLVED: It’s actually a superset as it also adds in support for arrayed drawing commands.

In GL for GL_ARB_shader_draw_parameters, gl_BaseVertexARB holds the integer value passed to the parameter to the command that resulted in the current shader invocation. In the case where the command has no baseVertex parameter, the value of gl_BaseVertexARB is zero. This means that gl_BaseVertexARB = baseVertex (for glDrawElements commands with baseVertex) or 0. In particular there are no glDrawArrays commands that take a baseVertex parameter.

Now in Vulkan, we have BaseVertex = vertexOffset (for indexed drawing commands) or firstVertex (for arrayed drawing commands), and so Vulkan’s version is really a superset of GL functionality.

Version History

  • Revision 1, 2016-10-05 (Daniel Koch)

    • Internal revisions

VK_KHR_shader_float16_int8

Name String

VK_KHR_shader_float16_int8

Extension Type

Device extension

Registered Extension Number

83

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2018-03-07

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Alexander Galazin, Arm

  • Jan-Harald Fredriksen, Arm

  • Jeff Bolz, NVIDIA

  • Graeme Leese, Broadcom

  • Daniel Rakos, AMD

Description

The VK_KHR_shader_float16_int8 extension allows use of 16-bit floating-point types and 8-bit integer types in shaders for arithmetic operations.

It introduces two new optional features shaderFloat16 and shaderInt8 which directly map to the Float16 and the Int8 SPIR-V capabilities. The VK_KHR_shader_float16_int8 extension also specifies precision requirements for half-precision floating-point SPIR-V operations. This extension does not enable use of 8-bit integer types or 16-bit floating-point types in any shader input and output interfaces and therefore does not supersede the VK_KHR_8bit_storage or VK_KHR_16bit_storage extensions.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT16_INT8_FEATURES_KHR

New Functions

  • None

Version History

  • Revision 1, 2018-03-07 (Alexander Galazin)

    • Initial draft

VK_KHR_shader_float_controls

Name String

VK_KHR_shader_float_controls

Extension Type

Device extension

Registered Extension Number

198

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2018-09-11

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Alexander Galazin, Arm

  • Jan-Harald Fredriksen, Arm

  • Jeff Bolz, NVIDIA

  • Graeme Leese, Broadcom

  • Daniel Rakos, AMD

Description

The VK_KHR_shader_float_controls extension enables efficient use of floating-point computations through the ability to query and override the implementation’s default behavior for rounding modes, denormals, signed zero, and infinity.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR

New Enums

  • None

New Functions

  • None

Issues

1) Which instructions must flush denorms?

RESOLVED: Only floating-point conversion, floating-point arithmetic, floating-point relational (except OpIsNaN, OpIsInf), and floating-point GLSL.std.450 extended instructions must flush denormals.

2) What is the denorm behavior for intermediate results?

RESOLVED: When a SPIR-V instruction is implemented as a sequence of other instructions: - in the DenormFlushToZero execution mode the intermediate instructions may flush denormals, the final result of the sequence must not be denormal. - in the DenormPreserve execution mode denormals must be preserved throughout the whole sequence.

3) Do denorm and rounding mode controls apply to OpSpecConstantOp?

RESOLVED: Yes, except when the opcode is OpQuantizeToF16.

4) The SPIR-V specification says that OpConvertFToU and OpConvertFToS unconditionally round towards zero. Do the rounding mode controls specified through the execution modes apply to them?

RESOLVED: No, these instructions unconditionally round towards zero.

5) Do any of the "Pack" GLSL.std.450 instructions count as conversion instructions and have the rounding mode apply?

RESOLVED: No, only instructions listed in the section "3.32.11. Conversion Instructions" of the SPIR-V specification count as conversion instructions.

6) When using inf/nan-ignore mode, what is expected of OpIsNan and OpIsInf?

RESOLVED: These instructions must always accurately detect inf/nan if it is passed to them.

Version History

  • Revision 3, 2018-09-11 (Alexander Galazin)

    • Minor restructuring

  • Revision 2, 2018-04-17 (Alexander Galazin)

    • Added issues and resolutions

  • Revision 1, 2018-04-11 (Alexander Galazin)

    • Initial draft

VK_KHR_shared_presentable_image

Name String

VK_KHR_shared_presentable_image

Extension Type

Device extension

Registered Extension Number

112

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2017-03-20

IP Status

No known IP claims.

Contributors
  • Alon Or-bach, Samsung Electronics

  • Ian Elliott, Google

  • Jesse Hall, Google

  • Pablo Ceballos, Google

  • Chris Forbes, Google

  • Jeff Juliano, NVIDIA

  • James Jones, NVIDIA

  • Daniel Rakos, AMD

  • Tobias Hector, Imagination Technologies

  • Graham Connor, Imagination Technologies

  • Michael Worcester, Imagination Technologies

  • Cass Everitt, Oculus

  • Johannes Van Waveren, Oculus

This extension extends VK_KHR_swapchain to enable creation of a shared presentable image. This allows the application to use the image while the presention engine is accessing it, in order to reduce the latency between rendering and presentation.

New Object Types

None.

New Enum Constants

  • Extending VkPresentModeKHR:

    • VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR

    • VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR

  • Extending VkImageLayout:

    • VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_SHARED_PRESENT_SURFACE_CAPABILITIES_KHR

New Enums

None.

New Functions

Issues

1) Should we allow a Vulkan WSI swapchain to toggle between normal usage and shared presentation usage?

RESOLVED: No. WSI swapchains are typically recreated with new properties instead of having their properties changed. This can also save resources, assuming that fewer images are needed for shared presentation, and assuming that most VR applications do not need to switch between normal and shared usage.

2) Should we have a query for determining how the presentation engine refresh is triggered?

RESOLVED: Yes. This is done via which presentation modes a surface supports.

3) Should the object representing a shared presentable image be an extension of a VkSwapchainKHR or a separate object?

RESOLVED: Extension of a swapchain due to overlap in creation properties and to allow common functionality between shared and normal presentable images and swapchains.

4) What should we call the extension and the new structures it creates?

RESOLVED: Shared presentable image / shared present.

5) Should the minImageCount and presentMode values of the VkSwapchainCreateInfoKHR be ignored, or required to be compatible values?

RESOLVED: minImageCount must be set to 1, and presentMode should be set to either VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR or VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR.

6) What should the layout of the shared presentable image be?

RESOLVED: After acquiring the shared presentable image, the application must transition it to the VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR layout prior to it being used. After this initial transition, any image usage that was requested during swapchain creation can be performed on the image without layout transitions being performed.

7) Do we need a new API for the trigger to refresh new content?

RESOLVED: vkQueuePresentKHR to act as API to trigger a refresh, as will allow combination with other compatible extensions to vkQueuePresentKHR.

8) How should an application detect a VK_ERROR_OUT_OF_DATE_KHR error on a swapchain using the VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR present mode?

RESOLVED: Introduce vkGetSwapchainStatusKHR to allow applications to query the status of a swapchain using a shared presentation mode.

9) What should subsequent calls to vkQueuePresentKHR for VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR swapchains be defined to do?

RESOLVED: State that implementations may use it as a hint for updated content.

10) Can the ownership of a shared presentable image be transferred to a different queue?

RESOLVED: No. It is not possible to transfer ownership of a shared presentable image obtained from a swapchain created using VK_SHARING_MODE_EXCLUSIVE after it has been presented.

11) How should vkQueueSubmit behave if a command buffer uses an image from an VK_ERROR_OUT_OF_DATE_KHR swapchain?

RESOLVED: vkQueueSubmit is expected to return the VK_ERROR_DEVICE_LOST error.

12) Can Vulkan provide any guarantee on the order of rendering, to enable beam chasing?

RESOLVED: This could be achieved via use of render passes to ensure strip rendering.

Version History

  • Revision 1, 2017-03-20 (Alon Or-bach)

    • Internal revisions

VK_KHR_storage_buffer_storage_class

Name String

VK_KHR_storage_buffer_storage_class

Extension Type

Device extension

Registered Extension Number

132

Revision

1

Extension and Version Dependencies
  • Requires Vulkan 1.0

Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Alexander Galazin, ARM

  • David Neto, Google

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.

New Enum Constants

None.

New Structures

None.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1.

Issues

None.

Version History

  • Revision 1, 2017-03-23 (Alexander Galazin)

    • Initial draft

VK_KHR_surface

Name String

VK_KHR_surface

Extension Type

Instance extension

Registered Extension Number

1

Revision

25

Extension and Version Dependencies
  • Requires Vulkan 1.0

Contact
Last Modified Date

2016-08-25

IP Status

No known IP claims.

Contributors
  • Patrick Doane, Blizzard

  • Ian Elliott, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

  • Jason Ekstrand, Intel

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.

New Object Types

New Enum Constants

  • Extending VkResult:

    • VK_ERROR_SURFACE_LOST_KHR

    • VK_ERROR_NATIVE_WINDOW_IN_USE_KHR

Examples

Note

The example code for the VK_KHR_surface and VK_KHR_swapchain extensions was removed from the appendix after revision 1.0.29. This WSI example code was ported to the cube demo that is shipped with the official Khronos SDK, and is being kept up-to-date in that location (see: https://github.com/KhronosGroup/Vulkan-Tools/blob/master/cube/cube.c).

Issues

1) Should this extension include a method to query whether a physical device supports presenting to a specific window or native surface on a given platform?

RESOLVED: Yes. Without this, applications would need to create a device instance to determine whether a particular window can be presented to. Knowing that a device supports presentation to a platform in general is not sufficient, as a single machine might support multiple seats, or instances of the platform that each use different underlying physical devices. Additionally, on some platforms, such as the X Window System, different drivers and devices might be used for different windows depending on which section of the desktop they exist on.

2) Should the vkGetPhysicalDeviceSurfaceCapabilitiesKHR, vkGetPhysicalDeviceSurfaceFormatsKHR, and vkGetPhysicalDeviceSurfacePresentModesKHR functions from VK_KHR_swapchain be modified to operate on physical devices and moved to this extension to implement the resolution of issue 1?

RESOLVED: No, separate query functions are needed, as the purposes served are similar but incompatible. The vkGetPhysicalDeviceSurface*KHR functions return information that could potentially depend on an initialized device. For example, the formats supported for presentation to the surface might vary depending on which device extensions are enabled. The query introduced to resolve issue 1 should be used only to query generic driver or platform properties. The physical device parameter is intended to serve only as an identifier rather than a stateful object.

3) Should Vulkan include support Xlib or XCB as the API for accessing the X Window System platform?

RESOLVED: Both. XCB is a more modern and efficient API, but Xlib usage is deeply ingrained in many applications and likely will remain in use for the foreseeable future. Not all drivers necessarily need to support both, but including both as options in the core specification will probably encourage support, which should in turn ease adoption of the Vulkan API in older codebases. Additionally, the performance improvements possible with XCB likely will not have a measurable impact on the performance of Vulkan presentation and other minimal window system interactions defined here.

4) Should the GBM platform be included in the list of platform enums?

RESOLVED: Deferred, and will be addressed with a platform-specific extension to be written in the future.

Version History

  • Revision 1, 2015-05-20 (James Jones)

    • Initial draft, based on LunarG KHR spec, other KHR specs, patches attached to bugs.

  • Revision 2, 2015-05-22 (Ian Elliott)

    • Created initial Description section.

    • Removed query for whether a platform requires the use of a queue for presentation, since it was decided that presentation will always be modeled as being part of the queue.

    • Fixed typos and other minor mistakes.

  • Revision 3, 2015-05-26 (Ian Elliott)

    • Improved the Description section.

  • Revision 4, 2015-05-27 (James Jones)

    • Fixed compilation errors in example code.

  • Revision 5, 2015-06-01 (James Jones)

    • Added issues 1 and 2 and made related spec updates.

  • Revision 6, 2015-06-01 (James Jones)

    • Merged the platform type mappings table previously removed from VK_KHR_swapchain with the platform description table in this spec.

    • Added issues 3 and 4 documenting choices made when building the initial list of native platforms supported.

  • Revision 7, 2015-06-11 (Ian Elliott)

    • Updated table 1 per input from the KHR TSG.

    • Updated issue 4 (GBM) per discussion with Daniel Stone. He will create a platform-specific extension sometime in the future.

  • Revision 8, 2015-06-17 (James Jones)

    • Updated enum-extending values using new convention.

    • Fixed the value of VK_SURFACE_PLATFORM_INFO_TYPE_SUPPORTED_KHR.

  • Revision 9, 2015-06-17 (James Jones)

    • Rebased on Vulkan API version 126.

  • Revision 10, 2015-06-18 (James Jones)

    • Marked issues 2 and 3 resolved.

  • Revision 11, 2015-06-23 (Ian Elliott)

    • Examples now show use of function pointers for extension functions.

    • Eliminated extraneous whitespace.

  • Revision 12, 2015-07-07 (Daniel Rakos)

    • Added error section describing when each error is expected to be reported.

    • Replaced the term "queue node index" with "queue family index" in the spec as that is the agreed term to be used in the latest version of the core header and spec.

    • Replaced bool32_t with VkBool32.

  • Revision 13, 2015-08-06 (Daniel Rakos)

    • Updated spec against latest core API header version.

  • Revision 14, 2015-08-20 (Ian Elliott)

    • Renamed this extension and all of its enumerations, types, functions, etc. This makes it compliant with the proposed standard for Vulkan extensions.

    • Switched from "revision" to "version", including use of the VK_MAKE_VERSION macro in the header file.

    • Did miscellaneous cleanup, etc.

  • Revision 15, 2015-08-20 (Ian Elliott—​porting a 2015-07-29 change from James Jones)

    • Moved the surface transform enums here from VK_WSI_swapchain so they could be re-used by VK_WSI_display.

  • Revision 16, 2015-09-01 (James Jones)

    • Restore single-field revision number.

  • Revision 17, 2015-09-01 (James Jones)

    • Fix example code compilation errors.

  • Revision 18, 2015-09-26 (Jesse Hall)

    • Replaced VkSurfaceDescriptionKHR with the VkSurfaceKHR object, which is created via layered extensions. Added VkDestroySurfaceKHR.

  • Revision 19, 2015-09-28 (Jesse Hall)

    • Renamed from VK_EXT_KHR_swapchain to VK_EXT_KHR_surface.

  • Revision 20, 2015-09-30 (Jeff Vigil)

    • Add error result VK_ERROR_SURFACE_LOST_KHR.

  • Revision 21, 2015-10-15 (Daniel Rakos)

    • Updated the resolution of issue #2 and include the surface capability queries in this extension.

    • Renamed SurfaceProperties to SurfaceCapabilities as it better reflects that the values returned are the capabilities of the surface on a particular device.

    • Other minor cleanup and consistency changes.

  • Revision 22, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_surface to VK_KHR_surface.

  • Revision 23, 2015-11-03 (Daniel Rakos)

    • Added allocation callbacks to vkDestroySurfaceKHR.

  • Revision 24, 2015-11-10 (Jesse Hall)

    • Removed VkSurfaceTransformKHR. Use VkSurfaceTransformFlagBitsKHR instead.

    • Rename VkSurfaceCapabilitiesKHR member maxImageArraySize to maxImageArrayLayers.

  • Revision 25, 2016-01-14 (James Jones)

    • Moved VK_ERROR_NATIVE_WINDOW_IN_USE_KHR from the VK_KHR_android_surface to the VK_KHR_surface extension.

  • 2016-08-23 (Ian Elliott)

    • Update the example code, to not have so many characters per line, and to split out a new example to show how to obtain function pointers.

  • 2016-08-25 (Ian Elliott)

    • A note was added at the beginning of the example code, stating that it will be removed from future versions of the appendix.

VK_KHR_surface_protected_capabilities

Name String

VK_KHR_surface_protected_capabilities

Extension Type

Instance extension

Registered Extension Number

240

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2018-12-18

IP Status

No known IP claims.

Contributors
  • Sandeep Shinde, NVIDIA

  • James Jones, NVIDIA

  • Daniel Koch, NVIDIA

This extension extends VkSurfaceCapabilities2KHR, providing applications a way to query whether swapchains can be created with the VK_SWAPCHAIN_CREATE_PROTECTED_BIT_KHR flag set.

Vulkan 1.1 added (optional) support for protect memory and protected resources including buffers (VK_BUFFER_CREATE_PROTECTED_BIT), images (VK_IMAGE_CREATE_PROTECTED_BIT), and swapchains (VK_SWAPCHAIN_CREATE_PROTECTED_BIT_KHR). However, on implementations which support multiple windowing systems, not all window systems may be able to provide a protected display path.

This extension provides a way to query if a protected swapchain created for a surface (and thus a specific windowing system) can be displayed on screen. It extends the existing VkSurfaceCapabilities2KHR structure with a new VkSurfaceProtectedCapabilitiesKHR structure from which the application can obtain information about support for protected swapchain creation through vkGetPhysicalDeviceSurfaceCapabilities2KHR.

New Object Types

None.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_SURFACE_PROTECTED_CAPABILITIES_KHR

New Enums

None.

New Functions

None.

Issues

None.

Version History

  • Revision 1, 2018-12-18 (Sandeep Shinde, Daniel Koch)

    • Internal revisions.

VK_KHR_swapchain

Name String

VK_KHR_swapchain

Extension Type

Device extension

Registered Extension Number

2

Revision

70

Extension and Version Dependencies
Contact
Last Modified Date

2017-10-06

IP Status

No known IP claims.

Interactions and External Dependencies
  • Interacts with Vulkan 1.1

Contributors
  • Patrick Doane, Blizzard

  • Ian Elliott, LunarG

  • Jesse Hall, Google

  • Mathias Heyer, NVIDIA

  • James Jones, NVIDIA

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

  • Jason Ekstrand, Intel

  • Matthaeus G. Chajdas, AMD

  • Ray Smith, ARM

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.

New Object Types

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PRESENT_INFO_KHR

  • Extending VkImageLayout:

    • VK_IMAGE_LAYOUT_PRESENT_SRC_KHR

  • Extending VkResult:

    • VK_SUBOPTIMAL_KHR

    • VK_ERROR_OUT_OF_DATE_KHR

New Enums

Issues

1) Does this extension allow the application to specify the memory backing of the presentable images?

RESOLVED: No. Unlike standard images, the implementation will allocate the memory backing of the presentable image.

2) What operations are allowed on presentable images?

RESOLVED: This is determined by the image usage flags specified when creating the presentable image’s swapchain.

3) Does this extension support MSAA presentable images?

RESOLVED: No. Presentable images are always single-sampled. Multi-sampled rendering must use regular images. To present the rendering results the application must manually resolve the multi- sampled image to a single-sampled presentable image prior to presentation.

4) Does this extension support stereo/multi-view presentable images?

RESOLVED: Yes. The number of views associated with a presentable image is determined by the imageArrayLayers specified when creating a swapchain. All presentable images in a given swapchain use the same array size.

5) Are the layers of stereo presentable images half-sized?

RESOLVED: No. The image extents always match those requested by the application.

6) Do the “present” and “acquire next image” commands operate on a queue? If not, do they need to include explicit semaphore objects to interlock them with queue operations?

RESOLVED: The present command operates on a queue. The image ownership operation it represents happens in order with other operations on the queue, so no explicit semaphore object is required to synchronize its actions.

Applications may want to acquire the next image in separate threads from those in which they manage their queue, or in multiple threads. To make such usage easier, the acquire next image command takes a semaphore to signal as a method of explicit synchronization. The application must later queue a wait for this semaphore before queuing execution of any commands using the image.

7) Does vkAcquireNextImageKHR block if no images are available?

RESOLVED: The command takes a timeout parameter. Special values for the timeout are 0, which makes the call a non-blocking operation, and UINT64_MAX, which blocks indefinitely. Values in between will block for up to the specified time. The call will return when an image becomes available or an error occurs. It may, but is not required to, return before the specified timeout expires if the swapchain becomes out of date.

8) Can multiple presents be queued using one vkQueuePresentKHR call?

RESOLVED: Yes. VkPresentInfoKHR contains a list of swapchains and corresponding image indices that will be presented. When supported, all presentations queued with a single vkQueuePresentKHR call will be applied atomically as one operation. The same swapchain must not appear in the list more than once. Later extensions may provide applications stronger guarantees of atomicity for such present operations, and/or allow them to query whether atomic presentation of a particular group of swapchains is possible.

9) How do the presentation and acquire next image functions notify the application the targeted surface has changed?

RESOLVED: Two new result codes are introduced for this purpose:

  • VK_SUBOPTIMAL_KHR - Presentation will still succeed, subject to the window resize behavior, but the swapchain is no longer configured optimally for the surface it targets. Applications should query updated surface information and recreate their swapchain at the next convenient opportunity.

  • VK_ERROR_OUT_OF_DATE_KHR - Failure. The swapchain is no longer compatible with the surface it targets. The application must query updated surface information and recreate the swapchain before presentation will succeed.

These can be returned by both vkAcquireNextImageKHR and vkQueuePresentKHR.

10) Does the vkAcquireNextImageKHR command return a semaphore to the application via an output parameter, or accept a semaphore to signal from the application as an object handle parameter?

RESOLVED: Accept a semaphore to signal as an object handle. This avoids the need to specify whether the application must destroy the semaphore or whether it is owned by the swapchain, and if the latter, what its lifetime is and whether it can be re-used for other operations once it is received from vkAcquireNextImageKHR.

11) What types of swapchain queuing behavior should be exposed? Options include swap interval specification, mailbox/most recent vs. FIFO queue management, targeting specific vertical blank intervals or absolute times for a given present operation, and probably others. For some of these, whether they are specified at swapchain creation time or as per-present parameters needs to be decided as well.

RESOLVED: The base swapchain extension will expose 3 possible behaviors (of which, FIFO will always be supported):

  • Immediate present: Does not wait for vertical blanking period to update the current image, likely resulting in visible tearing. No internal queue is used. Present requests are applied immediately.

  • Mailbox queue: Waits for the next vertical blanking period to update the current image. No tearing should be observed. An internal single-entry queue is used to hold pending presentation requests. If the queue is full when a new presentation request is received, the new request replaces the existing entry, and any images associated with the prior entry become available for re-use by the application.

  • FIFO queue: Waits for the next vertical blanking period to update the current image. No tearing should be observed. An internal queue containing numSwapchainImages - 1 entries is used to hold pending presentation requests. New requests are appended to the end of the queue, and one request is removed from the beginning of the queue and processed during each vertical blanking period in which the queue is non-empty

Not all surfaces will support all of these modes, so the modes supported will be returned using a surface info query. All surfaces must support the FIFO queue mode. Applications must choose one of these modes up front when creating a swapchain. Switching modes can be accomplished by recreating the swapchain.

12) Can VK_PRESENT_MODE_MAILBOX_KHR provide non-blocking guarantees for vkAcquireNextImageKHR? If so, what is the proper criteria?

RESOLVED: Yes. The difficulty is not immediately obvious here. Naively, if at least 3 images are requested, mailbox mode should always have an image available for the application if the application does not own any images when the call to vkAcquireNextImageKHR was made. However, some presentation engines may have more than one “current” image, and would still need to block in some cases. The right requirement appears to be that if the application allocates the surface’s minimum number of images + 1 then it is guaranteed non-blocking behavior when it does not currently own any images.

13) Is there a way to create and initialize a new swapchain for a surface that has generated a VK_SUBOPTIMAL_KHR return code while still using the old swapchain?

RESOLVED: Not as part of this specification. This could be useful to allow the application to create an “optimal” replacement swapchain and rebuild all its command buffers using it in a background thread at a low priority while continuing to use the “suboptimal” swapchain in the main thread. It could probably use the same “atomic replace” semantics proposed for recreating direct-to-device swapchains without incurring a mode switch. However, after discussion, it was determined some platforms probably could not support concurrent swapchains for the same surface though, so this will be left out of the base KHR extensions. A future extension could add this for platforms where it is supported.

14) Should there be a special value for VkSurfaceCapabilitiesKHR::maxImageCount to indicate there are no practical limits on the number of images in a swapchain?

RESOLVED: Yes. There where often be cases where there is no practical limit to the number of images in a swapchain other than the amount of available resources (I.e., memory) in the system. Trying to derive a hard limit from things like memory size is prone to failure. It is better in such cases to leave it to applications to figure such soft limits out via trial/failure iterations.

15) Should there be a special value for VkSurfaceCapabilitiesKHR::currentExtent to indicate the size of the platform surface is undefined?

RESOLVED: Yes. On some platforms (Wayland, for example), the surface size is defined by the images presented to it rather than the other way around.

16) Should there be a special value for VkSurfaceCapabilitiesKHR::maxImageExtent to indicate there is no practical limit on the surface size?

RESOLVED: No. It seems unlikely such a system would exist. 0 could be used to indicate the platform places no limits on the extents beyond those imposed by Vulkan for normal images, but this query could just as easily return those same limits, so a special “unlimited” value does not seem useful for this field.

17) How should surface rotation and mirroring be exposed to applications? How do they specify rotation and mirroring transforms applied prior to presentation?

RESOLVED: Applications can query both the supported and current transforms of a surface. Both are specified relative to the device’s “natural” display rotation and direction. The supported transforms indicates which orientations the presentation engine accepts images in. For example, a presentation engine that does not support transforming surfaces as part of presentation, and which is presenting to a surface that is displayed with a 90-degree rotation, would return only one supported transform bit: VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR. Applications must transform their rendering by the transform they specify when creating the swapchain in preTransform field.

18) Can surfaces ever not support VK_MIRROR_NONE? Can they support vertical and horizontal mirroring simultaneously? Relatedly, should VK_MIRROR_NONE[_BIT] be zero, or bit one, and should applications be allowed to specify multiple pre and current mirror transform bits, or exactly one?

RESOLVED: Since some platforms may not support presenting with a transform other than the native window’s current transform, and prerotation/mirroring are specified relative to the device’s natural rotation and direction, rather than relative to the surface’s current rotation and direction, it is necessary to express lack of support for no mirroring. To allow this, the MIRROR_NONE enum must occupy a bit in the flags. Since MIRROR_NONE must be a bit in the bitmask rather than a bitmask with no values set, allowing more than one bit to be set in the bitmask would make it possible to describe undefined transforms such as VK_MIRROR_NONE_BIT | VK_MIRROR_HORIZONTAL_BIT, or a transform that includes both “no mirroring” and “horizontal mirroring” simultaneously. Therefore, it is desirable to allow specifying all supported mirroring transforms using only one bit. The question then becomes, should there be a VK_MIRROR_HORIZONTAL_AND_VERTICAL_BIT to represent a simultaneous horizontal and vertical mirror transform? However, such a transform is equivalent to a 180 degree rotation, so presentation engines and applications that wish to support or use such a transform can express it through rotation instead. Therefore, 3 exclusive bits are sufficient to express all needed mirroring transforms.

19) Should support for sRGB be required?

RESOLVED: In the advent of UHD and HDR display devices, proper color space information is vital to the display pipeline represented by the swapchain. The app can discover the supported format/color-space pairs and select a pair most suited to its rendering needs. Currently only the sRGB color space is supported, future extensions may provide support for more color spaces. See issues 23 and 24.

20) Is there a mechanism to modify or replace an existing swapchain with one targeting the same surface?

RESOLVED: Yes. This is described above in the text.

21) Should there be a way to set prerotation and mirroring using native APIs when presenting using a Vulkan swapchain?

RESOLVED: Yes. The transforms that can be expressed in this extension are a subset of those possible on native platforms. If a platform exposes a method to specify the transform of presented images for a given surface using native methods and exposes more transforms or other properties for surfaces than Vulkan supports, it might be impossible, difficult, or inconvenient to set some of those properties using Vulkan KHR extensions and some using the native interfaces. To avoid overwriting properties set using native commands when presenting using a Vulkan swapchain, the application can set the pretransform to “inherit”, in which case the current native properties will be used, or if none are available, a platform-specific default will be used. Platforms that do not specify a reasonable default or do not provide native mechanisms to specify such transforms should not include the inherit bits in the supportedTransforms bitmask they return in VkSurfaceCapabilitiesKHR.

22) Should the content of presentable images be clipped by objects obscuring their target surface?

RESOLVED: Applications can choose which behavior they prefer. Allowing the content to be clipped could enable more optimal presentation methods on some platforms, but some applications might rely on the content of presentable images to perform techniques such as partial updates or motion blurs.

23) What is the purpose of specifying a VkColorSpaceKHR along with VkFormat when creating a swapchain?

RESOLVED: While Vulkan itself is color space agnostic (e.g. even the meaning of R, G, B and A can be freely defined by the rendering application), the swapchain eventually will have to present the images on a display device with specific color reproduction characteristics. If any color space transformations are necessary before an image can be displayed, the color space of the presented image must be known to the swapchain. A swapchain will only support a restricted set of color format and -space pairs. This set can be discovered via vkGetPhysicalDeviceSurfaceFormatsKHR. As it can be expected that most display devices support the sRGB color space, at least one format/color-space pair has to be exposed, where the color space is VK_COLOR_SPACE_SRGB_NONLINEAR_KHR.

24) How are sRGB formats and the sRGB color space related?

RESOLVED: While Vulkan exposes a number of SRGB texture formats, using such formats does not guarantee working in a specific color space. It merely means that the hardware can directly support applying the non-linear transfer functions defined by the sRGB standard color space when reading from or writing to images of that these formats. Still, it is unlikely that a swapchain will expose a *_SRGB format along with any color space other than VK_COLOR_SPACE_SRGB_NONLINEAR_KHR.

On the other hand, non-*_SRGB formats will be very likely exposed in pair with a SRGB color space. This means, the hardware will not apply any transfer function when reading from or writing to such images, yet they will still be presented on a device with sRGB display characteristics. In this case the application is responsible for applying the transfer function, for instance by using shader math.

25) How are the lifetime of surfaces and swapchains targeting them related?

RESOLVED: A surface must outlive any swapchains targeting it. A VkSurfaceKHR owns the binding of the native window to the Vulkan driver.

26) How can the client control the way the alpha channel of swapchain images is treated by the presentation engine during compositing?

RESOLVED: We should add new enum values to allow the client to negotiate with the presentation engine on how to treat image alpha values during the compositing process. Since not all platforms can practically control this through the Vulkan driver, a value of VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR is provided like for surface transforms.

27) Is vkCreateSwapchainKHR the right function to return VK_ERROR_NATIVE_WINDOW_IN_USE_KHR, or should the various platform-specific VkSurfaceKHR factory functions catch this error earlier?

RESOLVED: For most platforms, the VkSurfaceKHR structure is a simple container holding the data that identifies a native window or other object representing a surface on a particular platform. For the surface factory functions to return this error, they would likely need to register a reference on the native objects with the native display server somehow, and ensure no other such references exist. Surfaces were not intended to be that heavyweight.

Swapchains are intended to be the objects that directly manipulate native windows and communicate with the native presentation mechanisms. Swapchains will already need to communicate with the native display server to negotiate allocation and/or presentation of presentable images for a native surface. Therefore, it makes more sense for swapchain creation to be the point at which native object exclusivity is enforced. Platforms may choose to enforce further restrictions on the number of VkSurfaceKHR objects that may be created for the same native window if such a requirement makes sense on a particular platform, but a global requirement is only sensible at the swapchain level.

Examples

Note

The example code for the VK_KHR_surface and VK_KHR_swapchain extensions was removed from the appendix after revision 1.0.29. This WSI example code was ported to the cube demo that is shipped with the official Khronos SDK, and is being kept up-to-date in that location (see: https://github.com/KhronosGroup/Vulkan-Tools/blob/master/cube/cube.c).

Version History

  • Revision 1, 2015-05-20 (James Jones)

    • Initial draft, based on LunarG KHR spec, other KHR specs, patches attached to bugs.

  • Revision 2, 2015-05-22 (Ian Elliott)

    • Made many agreed-upon changes from 2015-05-21 KHR TSG meeting. This includes using only a queue for presentation, and having an explicit function to acquire the next image.

    • Fixed typos and other minor mistakes.

  • Revision 3, 2015-05-26 (Ian Elliott)

    • Improved the Description section.

    • Added or resolved issues that were found in improving the Description. For example, pSurfaceDescription is used consistently, instead of sometimes using pSurface.

  • Revision 4, 2015-05-27 (James Jones)

    • Fixed some grammatical errors and typos

    • Filled in the description of imageUseFlags when creating a swapchain.

    • Added a description of swapInterval.

    • Replaced the paragraph describing the order of operations on a queue for image ownership and presentation.

  • Revision 5, 2015-05-27 (James Jones)

    • Imported relevant issues from the (abandoned) vk_wsi_persistent_swapchain_images extension.

    • Added issues 6 and 7, regarding behavior of the acquire next image and present commands with respect to queues.

    • Updated spec language and examples to align with proposed resolutions to issues 6 and 7.

  • Revision 6, 2015-05-27 (James Jones)

    • Added issue 8, regarding atomic presentation of multiple swapchains

    • Updated spec language and examples to align with proposed resolution to issue 8.

  • Revision 7, 2015-05-27 (James Jones)

    • Fixed compilation errors in example code, and made related spec fixes.

  • Revision 8, 2015-05-27 (James Jones)

    • Added issue 9, and the related VK_SUBOPTIMAL_KHR result code.

    • Renamed VK_OUT_OF_DATE_KHR to VK_ERROR_OUT_OF_DATE_KHR.

  • Revision 9, 2015-05-27 (James Jones)

    • Added inline proposed resolutions (marked with [JRJ]) to some XXX questions/issues. These should be moved to the issues section in a subsequent update if the proposals are adopted.

  • Revision 10, 2015-05-28 (James Jones)

    • Converted vkAcquireNextImageKHR back to a non-queue operation that uses a VkSemaphore object for explicit synchronization.

    • Added issue 10 to determine whether vkAcquireNextImageKHR generates or returns semaphores, or whether it operates on a semaphore provided by the application.

  • Revision 11, 2015-05-28 (James Jones)

    • Marked issues 6, 7, and 8 resolved.

    • Renamed VkSurfaceCapabilityPropertiesKHR to VkSurfacePropertiesKHR to better convey the mutable nature of the info it contains.

  • Revision 12, 2015-05-28 (James Jones)

    • Added issue 11 with a proposed resolution, and the related issue 12.

    • Updated various sections of the spec to match the proposed resolution to issue 11.

  • Revision 13, 2015-06-01 (James Jones)

    • Moved some structures to VK_EXT_KHR_swap_chain to resolve the spec’s issues 1 and 2.

  • Revision 14, 2015-06-01 (James Jones)

    • Added code for example 4 demonstrating how an application might make use of the two different present and acquire next image KHR result codes.

    • Added issue 13.

  • Revision 15, 2015-06-01 (James Jones)

    • Added issues 14 - 16 and related spec language.

    • Fixed some spelling errors.

    • Added language describing the meaningful return values for vkAcquireNextImageKHR and vkQueuePresentKHR.

  • Revision 16, 2015-06-02 (James Jones)

    • Added issues 17 and 18, as well as related spec language.

    • Removed some erroneous text added by mistake in the last update.

  • Revision 17, 2015-06-15 (Ian Elliott)

    • Changed special value from "-1" to "0" so that the data types can be unsigned.

  • Revision 18, 2015-06-15 (Ian Elliott)

    • Clarified the values of VkSurfacePropertiesKHR::minImageCount and the timeout parameter of the vkAcquireNextImageKHR function.

  • Revision 19, 2015-06-17 (James Jones)

    • Misc. cleanup. Removed resolved inline issues and fixed typos.

    • Fixed clarification of VkSurfacePropertiesKHR::minImageCount made in version 18.

    • Added a brief "Image Ownership" definition to the list of terms used in the spec.

  • Revision 20, 2015-06-17 (James Jones)

    • Updated enum-extending values using new convention.

  • Revision 21, 2015-06-17 (James Jones)

    • Added language describing how to use VK_IMAGE_LAYOUT_PRESENT_SOURCE_KHR.

    • Cleaned up an XXX comment regarding the description of which queues vkQueuePresentKHR can be used on.

  • Revision 22, 2015-06-17 (James Jones)

    • Rebased on Vulkan API version 126.

  • Revision 23, 2015-06-18 (James Jones)

    • Updated language for issue 12 to read as a proposed resolution.

    • Marked issues 11, 12, 13, 16, and 17 resolved.

    • Temporarily added links to the relevant bugs under the remaining unresolved issues.

    • Added issues 19 and 20 as well as proposed resolutions.

  • Revision 24, 2015-06-19 (Ian Elliott)

    • Changed special value for VkSurfacePropertiesKHR::currentExtent back to "-1" from "0". This value will never need to be unsigned, and "0" is actually a legal value.

  • Revision 25, 2015-06-23 (Ian Elliott)

    • Examples now show use of function pointers for extension functions.

    • Eliminated extraneous whitespace.

  • Revision 26, 2015-06-25 (Ian Elliott)

    • Resolved Issues 9 & 10 per KHR TSG meeting.

  • Revision 27, 2015-06-25 (James Jones)

    • Added oldSwapchain member to VkSwapchainCreateInfoKHR.

  • Revision 28, 2015-06-25 (James Jones)

    • Added the "inherit" bits to the rotation and mirroring flags and the associated issue 21.

  • Revision 29, 2015-06-25 (James Jones)

    • Added the "clipped" flag to VkSwapchainCreateInfoKHR, and the associated issue 22.

    • Specified that presenting an image does not modify it.

  • Revision 30, 2015-06-25 (James Jones)

    • Added language to the spec that clarifies the behavior of vkCreateSwapchainKHR() when the oldSwapchain field of VkSwapchainCreateInfoKHR is not NULL.

  • Revision 31, 2015-06-26 (Ian Elliott)

    • Example of new VkSwapchainCreateInfoKHR members, "oldSwapchain" and "clipped".

    • Example of using VkSurfacePropertiesKHR::{min|max}ImageCount to set VkSwapchainCreateInfoKHR::minImageCount.

    • Rename vkGetSurfaceInfoKHR()'s 4th parameter to "pDataSize", for consistency with other functions.

    • Add macro with C-string name of extension (just to header file).

  • Revision 32, 2015-06-26 (James Jones)

    • Minor adjustments to the language describing the behavior of "oldSwapchain"

    • Fixed the version date on my previous two updates.

  • Revision 33, 2015-06-26 (Jesse Hall)

    • Add usage flags to VkSwapchainCreateInfoKHR

  • Revision 34, 2015-06-26 (Ian Elliott)

    • Rename vkQueuePresentKHR()'s 2nd parameter to "pPresentInfo", for consistency with other functions.

  • Revision 35, 2015-06-26 (Jason Ekstrand)

    • Merged the VkRotationFlagBitsKHR and VkMirrorFlagBitsKHR enums into a single VkSurfaceTransformFlagBitsKHR enum.

  • Revision 36, 2015-06-26 (Jason Ekstrand)

    • Added a VkSurfaceTransformKHR enum that is not a bitmask. Each value in VkSurfaceTransformKHR corresponds directly to one of the bits in VkSurfaceTransformFlagBitsKHR so transforming from one to the other is easy. Having a separate enum means that currentTransform and preTransform are now unambiguous by definition.

  • Revision 37, 2015-06-29 (Ian Elliott)

    • Corrected one of the signatures of vkAcquireNextImageKHR, which had the last two parameters switched from what it is elsewhere in the specification and header files.

  • Revision 38, 2015-06-30 (Ian Elliott)

    • Corrected a typo in description of the vkGetSwapchainInfoKHR() function.

    • Corrected a typo in header file comment for VkPresentInfoKHR::sType.

  • Revision 39, 2015-07-07 (Daniel Rakos)

    • Added error section describing when each error is expected to be reported.

    • Replaced bool32_t with VkBool32.

  • Revision 40, 2015-07-10 (Ian Elliott)

    • Updated to work with version 138 of the "vulkan.h" header. This includes declaring the VkSwapchainKHR type using the new VK_DEFINE_NONDISP_HANDLE macro, and no longer extending VkObjectType (which was eliminated).

  • Revision 41 2015-07-09 (Mathias Heyer)

    • Added color space language.

  • Revision 42, 2015-07-10 (Daniel Rakos)

    • Updated query mechanism to reflect the convention changes done in the core spec.

    • Removed "queue" from the name of VK_STRUCTURE_TYPE_QUEUE_PRESENT_INFO_KHR to be consistent with the established naming convention.

    • Removed reference to the no longer existing VkObjectType enum.

  • Revision 43, 2015-07-17 (Daniel Rakos)

    • Added support for concurrent sharing of swapchain images across queue families.

    • Updated sample code based on recent changes

  • Revision 44, 2015-07-27 (Ian Elliott)

    • Noted that support for VK_PRESENT_MODE_FIFO_KHR is required. That is ICDs may optionally support IMMEDIATE and MAILBOX, but must support FIFO.

  • Revision 45, 2015-08-07 (Ian Elliott)

    • Corrected a typo in spec file (type and variable name had wrong case for the imageColorSpace member of the VkSwapchainCreateInfoKHR struct).

    • Corrected a typo in header file (last parameter in PFN_vkGetSurfacePropertiesKHR was missing "KHR" at the end of type: VkSurfacePropertiesKHR).

  • Revision 46, 2015-08-20 (Ian Elliott)

    • Renamed this extension and all of its enumerations, types, functions, etc. This makes it compliant with the proposed standard for Vulkan extensions.

    • Switched from "revision" to "version", including use of the VK_MAKE_VERSION macro in the header file.

    • Made improvements to several descriptions.

    • Changed the status of several issues from PROPOSED to RESOLVED, leaving no unresolved issues.

    • Resolved several TODOs, did miscellaneous cleanup, etc.

  • Revision 47, 2015-08-20 (Ian Elliott—​porting a 2015-07-29 change from James Jones)

    • Moved the surface transform enums to VK_WSI_swapchain so they could be re-used by VK_WSI_display.

  • Revision 48, 2015-09-01 (James Jones)

    • Various minor cleanups.

  • Revision 49, 2015-09-01 (James Jones)

    • Restore single-field revision number.

  • Revision 50, 2015-09-01 (James Jones)

    • Update Example #4 to include code that illustrates how to use the oldSwapchain field.

  • Revision 51, 2015-09-01 (James Jones)

    • Fix example code compilation errors.

  • Revision 52, 2015-09-08 (Matthaeus G. Chajdas)

    • Corrected a typo.

  • Revision 53, 2015-09-10 (Alon Or-bach)

    • Removed underscore from SWAP_CHAIN left in VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR.

  • Revision 54, 2015-09-11 (Jesse Hall)

    • Described the execution and memory coherence requirements for image transitions to and from VK_IMAGE_LAYOUT_PRESENT_SOURCE_KHR.

  • Revision 55, 2015-09-11 (Ray Smith)

    • Added errors for destroying and binding memory to presentable images

  • Revision 56, 2015-09-18 (James Jones)

    • Added fence argument to vkAcquireNextImageKHR

    • Added example of how to meter a host thread based on presentation rate.

  • Revision 57, 2015-09-26 (Jesse Hall)

    • Replace VkSurfaceDescriptionKHR with VkSurfaceKHR.

    • Added issue 25 with agreed resolution.

  • Revision 58, 2015-09-28 (Jesse Hall)

    • Renamed from VK_EXT_KHR_device_swapchain to VK_EXT_KHR_swapchain.

  • Revision 59, 2015-09-29 (Ian Elliott)

    • Changed vkDestroySwapchainKHR() to return void.

  • Revision 60, 2015-10-01 (Jeff Vigil)

    • Added error result VK_ERROR_SURFACE_LOST_KHR.

  • Revision 61, 2015-10-05 (Jason Ekstrand)

    • Added the VkCompositeAlpha enum and corresponding structure fields.

  • Revision 62, 2015-10-12 (Daniel Rakos)

    • Added VK_PRESENT_MODE_FIFO_RELAXED_KHR.

  • Revision 63, 2015-10-15 (Daniel Rakos)

    • Moved surface capability queries to VK_EXT_KHR_surface.

  • Revision 64, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_swapchain to VK_KHR_swapchain.

  • Revision 65, 2015-10-28 (Ian Elliott)

    • Added optional pResult member to VkPresentInfoKHR, so that per-swapchain results can be obtained from vkQueuePresentKHR().

  • Revision 66, 2015-11-03 (Daniel Rakos)

    • Added allocation callbacks to create and destroy functions.

    • Updated resource transition language.

    • Updated sample code.

  • Revision 67, 2015-11-10 (Jesse Hall)

    • Add reserved flags bitmask to VkSwapchainCreateInfoKHR.

    • Modify naming and member ordering to match API style conventions, and so the VkSwapchainCreateInfoKHR image property members mirror corresponding VkImageCreateInfo members but with an 'image' prefix.

    • Make VkPresentInfoKHR::pResults non-const; it is an output array parameter.

    • Make pPresentInfo parameter to vkQueuePresentKHR const.

  • Revision 68, 2016-04-05 (Ian Elliott)

    • Moved the "validity" include for vkAcquireNextImage to be in its proper place, after the prototype and list of parameters.

    • Clarified language about presentable images, including how they are acquired, when applications can and cannot use them, etc. As part of this, removed language about "ownership" of presentable images, and replaced it with more-consistent language about presentable images being "acquired" by the application.

  • 2016-08-23 (Ian Elliott)

    • Update the example code, to use the final API command names, to not have so many characters per line, and to split out a new example to show how to obtain function pointers. This code is more similar to the LunarG "cube" demo program.

  • 2016-08-25 (Ian Elliott)

    • A note was added at the beginning of the example code, stating that it will be removed from future versions of the appendix.

  • Revision 69, 2017-09-07 (Tobias Hector)

    • Added interactions with Vulkan 1.1

  • Revision 70, 2017-10-06 (Ian Elliott)

    • Corrected interactions with Vulkan 1.1

VK_KHR_swapchain_mutable_format

Name String

VK_KHR_swapchain_mutable_format

Extension Type

Device extension

Registered Extension Number

201

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2018-03-28

IP Status

No known IP claims.

Contributors
  • Jason Ekstrand, Intel

  • Jan-Harald Fredriksen, ARM

  • Jesse Hall, Google

  • Daniel Rakos, AMD

  • Ray Smith, ARM

Short Description

Allows processing of swapchain images as different formats to that used by the window system, which is particularly useful for switching between sRGB and linear RGB formats.

Description

This extension adds a new swapchain creation flag that enables creating image views from presentable images with a different format than the one used to create the swapchain.

New Object Types

None.

New Enum Constants

New Enums

None.

New Structures

None.

New Functions

None.

Issues

1) Are there any new capabilities needed?

RESOLVED: No. It is expected that all implementations exposing this extension support swapchain image format mutability.

2) Do we need a separate VK_SWAPCHAIN_CREATE_EXTENDED_USAGE_BIT_KHR?

RESOLVED: No. This extension requires VK_KHR_maintenance2 and presentable images of swapchains created with VK_SWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR are created internally in a way equivalent to specifying both VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT and VK_IMAGE_CREATE_EXTENDED_USAGE_BIT_KHR.

3) Do we need a separate structure to allow specifying an image format list for swapchains?

RESOLVED: No. We simply use the same VkImageFormatListCreateInfoKHR structure introduced by VK_KHR_image_format_list. The structure is required to be included in the pNext chain of VkSwapchainCreateInfoKHR for swapchains created with VK_SWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR.

Version History

  • Revision 1, 2018-03-28 (Daniel Rakos)

    • Internal revisions.

VK_KHR_uniform_buffer_standard_layout

Name String

VK_KHR_uniform_buffer_standard_layout

Extension Type

Device extension

Registered Extension Number

254

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2019-01-25

Contributors
  • Graeme Leese, Broadcom

  • Jeff Bolz, NVIDIA

  • Tobias Hector, AMD

  • Jason Ekstrand, Intel

  • Neil Henning, AMD

Short Description

Enables tighter array and struct packing to be used with uniform buffers.

Description

This extension modifies the alignment rules for uniform buffers, allowing for tighter packing of arrays and structures. This allows, for example, the std430 layout, as defined in GLSL to be supported in uniform buffers.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_UNIFORM_BUFFER_STANDARD_LAYOUT_FEATURES_KHR

Issues

None.

Version History

  • Revision 1, 2019-01-25 (Graeme Leese)

    • Initial draft

VK_KHR_variable_pointers

Name String

VK_KHR_variable_pointers

Extension Type

Device extension

Registered Extension Number

121

Revision

1

Extension and Version Dependencies
Deprecation state
  • Promoted to Vulkan 1.1

Contact
Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • John Kessenich, Google

  • Neil Henning, Codeplay

  • David Neto, Google

  • Daniel Koch, Nvidia

  • Graeme Leese, Broadcom

  • Weifeng Zhang, Qualcomm

  • Stephen Clarke, Imagination Technologies

  • Jason Ekstrand, Intel

  • Jesse Hall, Google

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.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VARIABLE_POINTER_FEATURES_KHR

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted, however support for the variablePointersStorageBuffer feature is made optional. The original type, enum and command names are still available as aliases of the core functionality.

Issues

1) Do we need an optional property for the SPIR-V VariablePointersStorageBuffer capability or should it be mandatory when this extension is advertised?

RESOLVED: Add it as a distinct feature, but make support mandatory. Adding it as a feature makes the extension easier to include in a future core API version. In the extension, the feature is mandatory, so that presence of the extension guarantees some functionality. When included in a core API version, the feature would be optional.

2) Can support for these capabilities vary between shader stages?

RESOLVED: No, if the capability is supported in any stage it must be supported in all stages.

3) Should the capabilities be features or limits?

RESOLVED: Features, primarily for consistency with other similar extensions.

Version History

  • Revision 1, 2017-03-14 (Jesse Hall and John Kessenich)

    • Internal revisions

VK_KHR_wayland_surface

Name String

VK_KHR_wayland_surface

Extension Type

Instance extension

Registered Extension Number

7

Revision

6

Extension and Version Dependencies
Contact
Last Modified Date

2015-11-28

IP Status

No known IP claims.

Contributors
  • Patrick Doane, Blizzard

  • Jason Ekstrand, Intel

  • Ian Elliott, LunarG

  • Courtney Goeltzenleuchter, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Antoine Labour, Google

  • Jon Leech, Khronos

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Ray Smith, ARM

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

The VK_KHR_wayland_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) that refers to a Wayland wl_surface, as well as a query to determine support for rendering to a Wayland compositor.

New Object Types

None

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_WAYLAND_SURFACE_CREATE_INFO_KHR

New Enums

None

Issues

1) Does Wayland need a way to query for compatibility between a particular physical device and a specific Wayland display? This would be a more general query than vkGetPhysicalDeviceSurfaceSupportKHR: if the Wayland-specific query returned VK_TRUE for a (VkPhysicalDevice, struct wl_display*) pair, then the physical device could be assumed to support presentation to any VkSurfaceKHR for surfaces on the display.

RESOLVED: Yes. vkGetPhysicalDeviceWaylandPresentationSupportKHR was added to address this issue.

2) Should we require surfaces created with vkCreateWaylandSurfaceKHR to support the VK_PRESENT_MODE_MAILBOX_KHR present mode?

RESOLVED: Yes. Wayland is an inherently mailbox window system and mailbox support is required for some Wayland compositor interactions to work as expected. While handling these interactions may be possible with VK_PRESENT_MODE_FIFO_KHR, it is much more difficult to do without deadlock and requiring all Wayland applications to be able to support implementations which only support VK_PRESENT_MODE_FIFO_KHR would be an onerous restriction on application developers.

Version History

  • Revision 1, 2015-09-23 (Jesse Hall)

    • Initial draft, based on the previous contents of VK_EXT_KHR_swapchain (later renamed VK_EXT_KHR_surface).

  • Revision 2, 2015-10-02 (James Jones)

    • Added vkGetPhysicalDeviceWaylandPresentationSupportKHR() to resolve issue #1.

    • Adjusted wording of issue #1 to match the agreed-upon solution.

    • Renamed "window" parameters to "surface" to match Wayland conventions.

  • Revision 3, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_wayland_surface to VK_KHR_wayland_surface.

  • Revision 4, 2015-11-03 (Daniel Rakos)

    • Added allocation callbacks to vkCreateWaylandSurfaceKHR.

  • Revision 5, 2015-11-28 (Daniel Rakos)

    • Updated the surface create function to take a pCreateInfo structure.

  • Revision 6, 2017-02-08 (Jason Ekstrand)

    • Added the requirement that implementations support VK_PRESENT_MODE_MAILBOX_KHR.

    • Added wording about interactions between vkQueuePresentKHR and the Wayland requests sent to the compositor.

VK_KHR_win32_keyed_mutex

Name String

VK_KHR_win32_keyed_mutex

Extension Type

Device extension

Registered Extension Number

76

Revision

1

Extension and Version Dependencies
Contact
Last Modified Date

2016-10-21

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Carsten Rohde, NVIDIA

Applications that wish to import Direct3D 11 memory objects into the Vulkan API may wish to use the native keyed mutex mechanism to synchronize access to the memory between Vulkan and Direct3D. This extension provides a way for an application to access the keyed mutex associated with an imported Vulkan memory object when submitting command buffers to a queue.

New Object Types

None.

New Enum Constants

  • VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_KHR

New Enums

None.

New Functions

None.

Issues

None.

VK_KHR_win32_surface

Name String

VK_KHR_win32_surface

Extension Type

Instance extension

Registered Extension Number

10

Revision

6

Extension and Version Dependencies
Contact
Last Modified Date

2017-04-24

IP Status

No known IP claims.

Contributors
  • Patrick Doane, Blizzard

  • Jason Ekstrand, Intel

  • Ian Elliott, LunarG

  • Courtney Goeltzenleuchter, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Antoine Labour, Google

  • Jon Leech, Khronos

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Ray Smith, ARM

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

The VK_KHR_win32_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) that refers to a Win32 HWND, as well as a query to determine support for rendering to the windows desktop.

New Object Types

None

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR

New Enums

None

Issues

1) Does Win32 need a way to query for compatibility between a particular physical device and a specific screen? Compatibility between a physical device and a window generally only depends on what screen the window is on. However, there is not an obvious way to identify a screen without already having a window on the screen.

RESOLVED: No. While it may be useful, there is not a clear way to do this on Win32. However, a method was added to query support for presenting to the windows desktop as a whole.

2) If a native window object (HWND) is used by one graphics API, and then is later used by a different graphics API (one of which is Vulkan), can these uses interfere with each other?

RESOLVED: Yes.

Uses of a window object by multiple graphics APIs results in undefined behavior. Such behavior may succeed when using one Vulkan implementation but fail when using a different Vulkan implementation. Potential failures include:

  • Creating then destroying a flip presentation model DXGI swapchain on a window object can prevent vkCreateSwapchainKHR from succeeding on the same window object.

  • Creating then destroying a VkSwapchainKHR on a window object can prevent creation of a bitblt model DXGI swapchain on the same window object.

  • Creating then destroying a VkSwapchainKHR on a window object can effectively SetPixelFormat to a different format than the format chosen by an OpenGL application.

  • Creating then destroying a VkSwapchainKHR on a window object on one VkPhysicalDevice can prevent vkCreateSwapchainKHR from succeeding on the same window object, but on a different VkPhysicalDevice that is associated with a different Vulkan ICD.

In all cases the problem can be worked around by creating a new window object.

Technical details include:

  • Creating a DXGI swapchain over a window object can alter the object for the remainder of its lifetime. The alteration persists even after the DXGI swapchain has been destroyed. This alteration can make it impossible for a conformant Vulkan implementation to create a VkSwapchainKHR over the same window object. Mention of this alteration can be found in the remarks section of the MSDN documentation for DXGI_SWAP_EFFECT.

  • Calling GDI’s SetPixelFormat (needed by OpenGL’s WGL layer) on a window object alters the object for the remainder of its lifetime. The MSDN documentation for SetPixelFormat explains that a window object’s pixel format can be set only one time.

  • Creating a VkSwapchainKHR over a window object can alter the object for the remaining life of its lifetime. Either of the above alterations may occur as a side-effect of VkSwapchainKHR.

Version History

  • Revision 1, 2015-09-23 (Jesse Hall)

    • Initial draft, based on the previous contents of VK_EXT_KHR_swapchain (later renamed VK_EXT_KHR_surface).

  • Revision 2, 2015-10-02 (James Jones)

    • Added presentation support query for win32 desktops.

  • Revision 3, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_win32_surface to VK_KHR_win32_surface.

  • Revision 4, 2015-11-03 (Daniel Rakos)

    • Added allocation callbacks to vkCreateWin32SurfaceKHR.

  • Revision 5, 2015-11-28 (Daniel Rakos)

    • Updated the surface create function to take a pCreateInfo structure.

  • Revision 6, 2017-04-24 (Jeff Juliano)

    • Add issue 2 addressing reuse of a native window object in a different Graphics API, or by a different Vulkan ICD.

VK_KHR_xcb_surface

Name String

VK_KHR_xcb_surface

Extension Type

Instance extension

Registered Extension Number

6

Revision

6

Extension and Version Dependencies
Contact
Last Modified Date

2015-11-28

IP Status

No known IP claims.

Contributors
  • Patrick Doane, Blizzard

  • Jason Ekstrand, Intel

  • Ian Elliott, LunarG

  • Courtney Goeltzenleuchter, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Antoine Labour, Google

  • Jon Leech, Khronos

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Ray Smith, ARM

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

The VK_KHR_xcb_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) that refers to an X11 Window, using the XCB client-side library, as well as a query to determine support for rendering via XCB.

New Object Types

None

New Enum Constants

New Enums

None

New Structures

Issues

1) Does XCB need a way to query for compatibility between a particular physical device and a specific screen? This would be a more general query than vkGetPhysicalDeviceSurfaceSupportKHR: If it returned VK_TRUE, then the physical device could be assumed to support presentation to any window on that screen.

RESOLVED: Yes, this is needed for toolkits that want to create a VkDevice before creating a window. To ensure the query is reliable, it must be made against a particular X visual rather than the screen in general.

Version History

  • Revision 1, 2015-09-23 (Jesse Hall)

    • Initial draft, based on the previous contents of VK_EXT_KHR_swapchain (later renamed VK_EXT_KHR_surface).

  • Revision 2, 2015-10-02 (James Jones)

    • Added presentation support query for an (xcb_connection_t*, xcb_visualid_t) pair.

    • Removed "root" parameter from CreateXcbSurfaceKHR(), as it is redundant when a window on the same screen is specified as well.

    • Adjusted wording of issue #1 and added agreed upon resolution.

  • Revision 3, 2015-10-14 (Ian Elliott)

    • Removed "root" parameter from CreateXcbSurfaceKHR() in one more place.

  • Revision 4, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_xcb_surface to VK_KHR_xcb_surface.

  • Revision 5, 2015-10-23 (Daniel Rakos)

    • Added allocation callbacks to vkCreateXcbSurfaceKHR.

  • Revision 6, 2015-11-28 (Daniel Rakos)

    • Updated the surface create function to take a pCreateInfo structure.

VK_KHR_xlib_surface

Name String

VK_KHR_xlib_surface

Extension Type

Instance extension

Registered Extension Number

5

Revision

6

Extension and Version Dependencies
Contact
Last Modified Date

2015-11-28

IP Status

No known IP claims.

Contributors
  • Patrick Doane, Blizzard

  • Jason Ekstrand, Intel

  • Ian Elliott, LunarG

  • Courtney Goeltzenleuchter, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Antoine Labour, Google

  • Jon Leech, Khronos

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Ray Smith, ARM

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

The VK_KHR_xlib_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) that refers to an X11 Window, using the Xlib client-side library, as well as a query to determine support for rendering via Xlib.

New Object Types

None

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_XLIB_SURFACE_CREATE_INFO_KHR

New Enums

None

Issues

1) Does X11 need a way to query for compatibility between a particular physical device and a specific screen? This would be a more general query than vkGetPhysicalDeviceSurfaceSupportKHR; if it returned VK_TRUE, then the physical device could be assumed to support presentation to any window on that screen.

RESOLVED: Yes, this is needed for toolkits that want to create a VkDevice before creating a window. To ensure the query is reliable, it must be made against a particular X visual rather than the screen in general.

Version History

  • Revision 1, 2015-09-23 (Jesse Hall)

    • Initial draft, based on the previous contents of VK_EXT_KHR_swapchain (later renamed VK_EXT_KHR_surface).

  • Revision 2, 2015-10-02 (James Jones)

    • Added presentation support query for (Display*, VisualID) pair.

    • Removed "root" parameter from CreateXlibSurfaceKHR(), as it is redundant when a window on the same screen is specified as well.

    • Added appropriate X errors.

    • Adjusted wording of issue #1 and added agreed upon resolution.

  • Revision 3, 2015-10-14 (Ian Elliott)

    • Renamed this extension from VK_EXT_KHR_x11_surface to VK_EXT_KHR_xlib_surface.

  • Revision 4, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_xlib_surface to VK_KHR_xlib_surface.

  • Revision 5, 2015-11-03 (Daniel Rakos)

    • Added allocation callbacks to vkCreateXlibSurfaceKHR.

  • Revision 6, 2015-11-28 (Daniel Rakos)

    • Updated the surface create function to take a pCreateInfo structure.

List of Provisional Extensions

VK_KHR_vulkan_memory_model

Name String

VK_KHR_vulkan_memory_model

Extension Type

Device extension

Registered Extension Number

212

Revision

3

Extension and Version Dependencies
  • Requires Vulkan 1.0

Contact
Last Modified Date

2018-12-10

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Alan Baker, Google

  • Tobias Hector, AMD

  • David Neto, Google

  • Robert Simpson, Qualcomm Technologies, Inc.

  • Brian Sumner, AMD

The VK_KHR_vulkan_memory_model extension allows use of the Vulkan Memory Model, which formally defines how to synchronize memory accesses to the same memory locations performed by multiple shader invocations.

New Enum Constants

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR

New Structures

Note

Version 3 of the spec added a member (vulkanMemoryModelAvailabilityVisibilityChains) to VkPhysicalDeviceVulkanMemoryModelFeaturesKHR, which is an incompatible change from version 2.

New SPIR-V Capabilities

Issues

Version History

  • Revision 1, 2018-06-24 (Jeff Bolz)

    • Initial draft