Significant specification work was performed by the following editors:
Relevant information is now documented for each extension.
VK_KHR_surface
The VK_KHR_surface
extension is an instance extension.
It introduces VkSurfaceKHR
objects, which abstract native platform
surface or window objects for use with Vulkan.
It also provides a way to determine whether a queue family in a physical
device supports presenting to particular surface.
Separate extensions for each 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.
VkSurfaceTransformFlagBitsKHR
VkPresentModeKHR
VkColorSpaceKHR
VkCompositeAlphaFlagBitsKHR
![]() | Note |
---|---|
The example code for the |
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, some platforms, such as X windows, different drivers and devices might be used for different windows depending on which section of the desktop they exist on.
2) Should the vkGetSurfacePropertiesKHR(), vkGetSurfaceFormatsKHR(), and vkGetSurfacePresentModesKHR() 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 vkGetSurface*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 eases 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.
Revision 1, 2015-05-20 (James Jones)
Revision 2, 2015-05-22 (Ian Elliott)
Revision 3, 2015-05-26 (Ian Elliott)
Revision 4, 2015-05-27 (James Jones)
Revision 5, 2015-06-01 (James Jones)
Revision 6, 2015-06-01 (James Jones)
Revision 7, 2015-06-11 (Ian Elliott)
Revision 8, 2015-06-17 (James Jones)
Revision 9, 2015-06-17 (James Jones)
Revision 10, 2015-06-18 (James Jones)
Revision 11, 2015-06-23 (Ian Elliott)
Revision 12, 2015-07-07 (Daniel Rakos)
Revision 13, 2015-08-06 (Daniel Rakos)
Revision 14, 2015-08-20 (Ian Elliott)
Revision 15, 2015-08-20 (Ian Elliott—porting a 2015-07-29 change from James Jones)
Revision 16, 2015-09-01 (James Jones)
Revision 17, 2015-09-01 (James Jones)
Revision 18, 2015-09-26 (Jesse Hall)
Revision 19, 2015-09-28 (Jesse Hall)
Revision 20, 2015-09-30 (Jeff Vigil)
Revision 21, 2015-10-15 (Daniel Rakos)
Revision 22, 2015-10-26 (Ian Elliott)
Revision 23, 2015-11-03 (Daniel Rakos)
Revision 24, 2015-11-10 (Jesse Hall)
Revision 25, 2016-01-14 (James Jones)
2016-08-23 (Ian Elliott)
2016-08-25 (Ian Elliott)
VK_KHR_swapchain
VK_KHR_surface
.
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.
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
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 imageUsageFlags 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 imageArraySize 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 QueuePresent 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 VkSurfacePropertiesKHR::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 VkSurfacePropertiesKHR::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 VkSurfacePropertiesKHR::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_ROT90_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 supportedTransform bitmask they return in VkSurfacePropertiesKHR.
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 vkGetSurfaceInfoKHR. 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.
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.
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 swap chain 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 INHERIT 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 VkSurface factory functions catch this error earlier?
RESOLVED: For most platforms, the VkSurface 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 some how, and ensure no other such references exist. Surfaces were not intended to be that heavy- weight.
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 VkSurface 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.
![]() | Note |
---|---|
The example code for the |
Revision 1, 2015-05-20 (James Jones)
Revision 2, 2015-05-22 (Ian Elliott)
Revision 3, 2015-05-26 (Ian Elliott)
Revision 4, 2015-05-27 (James Jones)
Revision 5, 2015-05-27 (James Jones)
Revision 6, 2015-05-27 (James Jones)
Revision 7, 2015-05-27 (James Jones)
Revision 8, 2015-05-27 (James Jones)
Revision 9, 2015-05-27 (James Jones)
Revision 10, 2015-05-28 (James Jones)
Revision 11, 2015-05-28 (James Jones)
Revision 12, 2015-05-28 (James Jones)
Revision 13, 2015-06-01 (James Jones)
Revision 14, 2015-06-01 (James Jones)
Revision 15, 2015-06-01 (James Jones)
Revision 16, 2015-06-02 (James Jones)
Revision 17, 2015-06-15 (Ian Elliott)
Revision 18, 2015-06-15 (Ian Elliott)
Revision 19, 2015-06-17 (James Jones)
Revision 20, 2015-06-17 (James Jones)
Revision 21, 2015-06-17 (James Jones)
Revision 22, 2015-06-17 (James Jones)
Revision 23, 2015-06-18 (James Jones)
Revision 24, 2015-06-19 (Ian Elliott)
Revision 25, 2015-06-23 (Ian Elliott)
Revision 26, 2015-06-25 (Ian Elliott)
Revision 27, 2015-06-25 (James Jones)
Revision 28, 2015-06-25 (James Jones)
Revision 29, 2015-06-25 (James Jones)
Revision 30, 2015-06-25 (James Jones)
Revision 31, 2015-06-26 (Ian Elliott)
Revision 32, 2015-06-26 (James Jones)
Revision 33, 2015-06-26 (Jesse Hall)
Revision 34, 2015-06-26 (Ian Elliott)
Revision 35, 2015-06-26 (Jason Ekstrand)
Revision 36, 2015-06-26 (Jason Ekstrand)
Revision 37, 2015-06-29 (Ian Elliott)
Revision 38, 2015-06-30 (Ian Elliott)
Revision 39, 2015-07-07 (Daniel Rakos)
Revision 40, 2015-07-10 (Ian Elliott)
Revision 41 2015-07-09 (Mathias Heyer)
Revision 42, 2015-07-10 (Daniel Rakos)
Revision 43, 2015-07-17 (Daniel Rakos)
Revision 44, 2015-07-27 (Ian Elliott)
Revision 45, 2015-08-07 (Ian Elliott)
Revision 46, 2015-08-20 (Ian Elliott)
Revision 47, 2015-08-20 (Ian Elliott—porting a 2015-07-29 change from James Jones)
Revision 48, 2015-09-01 (James Jones)
Revision 49, 2015-09-01 (James Jones)
Revision 50, 2015-09-01 (James Jones)
Revision 51, 2015-09-01 (James Jones)
Revision 52, 2015-09-08 (Matthaeus G. Chajdas)
Revision 53, 2015-09-10 (Alon Or-bach)
Revision 54, 2015-09-11 (Jesse Hall)
Revision 55, 2015-09-11 (Ray Smith)
Revision 56, 2015-09-18 (James Jones)
Revision 57, 2015-09-26 (Jesse Hall)
Revision 58, 2015-09-28 (Jesse Hall)
Revision 59, 2015-09-29 (Ian Elliott)
Revision 60, 2015-10-01 (Jeff Vigil)
Revision 61, 2015-10-05 (Jason Ekstrand)
Revision 62, 2015-10-12 (Daniel Rakos)
Revision 63, 2015-10-15 (Daniel Rakos)
Revision 64, 2015-10-26 (Ian Elliott)
Revision 65, 2015-10-28 (Ian Elliott)
Revision 66, 2015-11-03 (Daniel Rakos)
Revision 67, 2015-11-10 (Jesse Hall)
Revision 68, 2016-04-05 (Ian Elliott)
2016-08-23 (Ian Elliott)
2016-08-25 (Ian Elliott)
VK_KHR_display
VK_KHR_surface
.
This extension provides the API to enumerate displays and available modes on a given device.
Extending VkStructureType
:
VK_STRUCTURE_TYPE_DISPLAY_MODE_CREATE_INFO_KHR
VK_STRUCTURE_TYPE_DISPLAY_SURFACE_CREATE_INFO_KHR
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_EXT_KHR_surface and VK_EXT_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.
PROPOSED RESOLUTION: Tiled displays will appear as a single display object in this API.
14) Should the raw EDID data be included in the display information?
PROPOSED RESOLUTION: None. Unclear whether this is a good idea. Provides a path for forward-compatibility as new EDID extensions are introduced, but may be complicated by the outcome of issue 13.
15) Should min and max scaling factor capabilities of overlays be exposed?
PROPOSED RESOLUTION: 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?
PROPOSED RESOLUTION: None.
17) Should there be a way to destroy display modes? If so, does it support destroying "built in" modes?
PROPOSED RESOLUTION: None.
18) What should the lifetime of display and built-in display mode objects be?
PROPOSED RESOLUTION: The lifetime of the instance. These objects can not 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 swap chain creation time, or on a per-present basis.
PROPOSED RESOLUTION: On a per-present basis.
Example 1
Enumerating displays, display modes, and planes, and creating a VkSurfaceKHR
extern VkBool32 ModeMatchesMyCriteria(const VkDisplayModePropertiesKHR *m); extern VkInstance instance; extern VkPhysicalDevice physDevice; extern VkSurfaceKHR surface; uint32_t displayCount, planeCount, i, j, k; VkDisplayPropertiesKHR* pDisplayProps; VkDisplayPlanePropertiesKHR* pPlaneProps; VkDisplayModeKHR myMode = VK_NULL_HANDLE; VkDisplayKHR myDisplay = VK_NULL_HANDLE; uint32_t bestPlane = UINT32_MAX; VkDisplayPlaneAlphaFlagBitsKHR alphaMode = 0; PFN_vkGetPhysicalDeviceDisplayPropertiesKHR pfnGetPhysicalDeviceDisplayPropertiesKHR; PFN_vkGetPhysicalDeviceDisplayPlanePropertiesKHR pfnGetPhysicalDeviceDisplayPlanePropertiesKHR; PFN_vkGetDisplayModePropertiesKHR pfnGetDisplayModePropertiesKHR; PFN_vkGetDisplayPlaneCapabilitiesKHR pfnGetDisplayPlaneCapabilitiesKHR; PFN_vkGetDisplayPlaneSupportedDisplaysKHR pfnGetDisplayPlaneSupportedDisplaysKHR; PFN_vkCreateDisplayPlaneSurfaceKHR pfnCreateDisplayPlaneSurfaceKHR; pfnGetPhysicalDeviceDisplayPropertiesKHR = (PFN_vkGetPhysicalDeviceDisplayPropertiesKHR) vkGetInstanceProcAddr(instance, "vkGetPhysicalDeviceDisplayPropertiesKHR"); pfnGetPhysicalDeviceDisplayPlanePropertiesKHR = (PFN_vkGetPhysicalDeviceDisplayPlanePropertiesKHR) vkGetInstanceProcAddr(instance, "vkGetPhysicalDeviceDisplayPlanePropertiesKHR"); pfnGetDisplayModePropertiesKHR = (PFN_vkGetDisplayModePropertiesKHR) vkGetInstanceProcAddr(instance, "vkGetDisplayModePropertiesKHR"); pfnGetDisplayPlaneCapabilitiesKHR = (PFN_vkGetDisplayPlaneCapabilitiesKHR) vkGetInstanceProcAddr(instance, "vkGetDisplayPlaneCapabilitiesKHR"); pfnGetDisplayPlaneSupportedDisplaysKHR = (PFN_vkGetDisplayPlaneSupportedDisplaysKHR) vkGetInstanceProcAddr(instance, "vkGetDisplayPlaneSupportedDisplaysKHR"); pfnCreateDisplayPlaneSurfaceKHR = (PFN_vkCreateDisplayPlaneSurfaceKHR) vkGetInstanceProcAddr(instance, "vkCreateDisplayPlaneSurfaceKHR"); // Get a list of displays on a physical device displayCount = 0; pfnGetPhysicalDeviceDisplayPropertiesKHR(physDevice, &displayCount, NULL); pDisplayProps = (VkDisplayPropertiesKHR*)malloc(sizeof(VkDisplayPropertiesKHR) * displayCount); pfnGetPhysicalDeviceDisplayPropertiesKHR(physDevice, &displayCount, pDisplayProps); // Get a list of display planes on a physical device planeCount = 0; pfnGetPhysicalDeviceDisplayPlanePropertiesKHR(physDevice, &planeCount, NULL); pPlaneProps = (VkDisplayPlanePropertiesKHR*)malloc(sizeof(VkDisplayPlanePropertiesKHR) * planeCount); pfnGetPhysicalDeviceDisplayPlanePropertiesKHR(physDevice, &planeCount, pPlaneProps); // Get the list of pModes each display supports for (i = 0; i < displayCount; ++i) { VkDisplayKHR display = pDisplayProps[i].display; VkDisplayModePropertiesKHR* pModes; uint32_t modeCount; vkGetDisplayModePropertiesKHR(physDevice, display, &modeCount, NULL); pModes = (VkDisplayModePropertiesKHR*)malloc(sizeof(VkDisplayModePropertiesKHR) * modeCount); vkGetDisplayModePropertiesKHR(physDevice, display, &modeCount, pModes); myMode = VK_NULL_HANDLE; for (j = 0; j < modeCount; ++j) { const VkDisplayModePropertiesKHR* mode = &pModes[i]; if (ModeMatchesMyCriteria(mode)) { myMode = mode->displayMode; break; } } free(pModes); // If there are no usable pModes found then check the next display. if (myMode == VK_NULL_HANDLE) continue; // Find a plane that matches these criteria, in order of preference: // -Is compatible with the chosen display + mode. // -Is not currently bound to another display. // -Supports per-pixel alpha, if possible. for (j = 0; j < planeCount; ++j) { uint32_t supportedCount = 0; VkDisplayKHR* pSupportedDisplays; VkDisplayPlaneCapabilitiesKHR planeCaps; // See if the plane is compatible with the current display. pfnGetDisplayPlaneSupportedDisplaysKHR(physDevice, j, &supportedCount, NULL); // Plane does not support any displays. This might happen on a card // that has a fixed mapping between planes and connectors when no // displays are currently attached to this plane's connector, for // example. if (supportedCount == 0) continue; pSupportedDisplays = (VkDisplayKHR*)malloc(sizeof(VkDisplayKHR) * supportedCount); pfnGetDisplayPlaneSupportedDisplaysKHR(physDevice, j, &supportedCount, pSupportedDisplays); for (k = 0; k < supportedCount; ++k) if (pSupportedDisplays[k] == display) { // If no supported plane has yet been found, this is // currently the best available plane. if (bestPlane == UINT32_MAX) bestPlane = j; break; } // If the plane cannot be used with the chosen display, keep looking. // Each display must have at least one compatible plane. if (k == supportedCount) continue; // If the plane passed the above test and is currently bound to the // desired display, or is not in use, it is the best plane found so // far. if ((pPlaneProps[j].currentDisplay == VK_NULL_HANDLE) && (pPlaneProps[j].currentDisplay == display)) bestPlane = j; else continue; pfnGetDisplayPlaneCapabilitiesKHR(physDevice, myMode, j, &planeCaps); // Prefer a plane that supports per-pixel alpha. if (planeCaps.supportedAlpha & VK_DISPLAY_PLANE_ALPHA_PER_PIXEL_BIT_KHR) { // This is the perfect plane for the given criteria. Use it. bestPlane = j; alphaMode = VK_DISPLAY_PLANE_ALPHA_PER_PIXEL_BIT_KHR; break; } } } free(pDisplayProps); if (myDisplay == VK_NULL_HANDLE || myMode == VK_NULL_HANDLE) { // No suitable display + mode could be found. Abort. abort(); } else { // Success. Create a VkSurfaceKHR object for this plane. const VkDisplaySurfaceCreateInfoKHR createInfo = { VK_STRUCTURE_TYPE_DISPLAY_SURFACE_CREATE_INFO_KHR, // sType NULL, // pNext 0, // flags myMode, // displayMode bestPlane, // planeIndex pPlaneProps[bestPlane].currentStackIndex, // planeStackIndex VK_SURFACE_TRANSFORM_IDENTITY_KHR, // transform 1.0f, // globalAlpha alphaMode, // alphaMode ... } pfnCreateDisplayPlaneSurfaceKHR(instance, &createInfo, NULL, &surface); }
Revision 1, 2015-02-24 (James Jones)
Revision 2, 2015-03-12 (Norbert Nopper)
Revision 3, 2015-03-17 (Norbert Nopper)
Revision 4, 2015-03-18 (Norbert Nopper)
Revision 6, 2015-03-18 (Daniel Rakos)
Revision 7, 2015-03-25 (James Jones)
Revision 8, 2015-03-25 (James Jones)
Revision 9, 2015-04-01 (Daniel Rakos)
Revision 10, 2015-04-01 (James Jones)
Revision 11, 2015-04-15 (James Jones)
Revision 12, 2015-07-29 (James Jones)
Revision 13, 2015-08-21 (Ian Elliott)
Revision 14, 2015-09-01 (James Jones)
Revision 15, 2015-09-08 (James Jones)
Revision 16, 2015-09-08 (James Jones)
Revision 17, 2015-10-02 (James Jones)
Revision 18, 2015-10-26 (Ian Elliott)
Revision 19, 2015-11-02 (James Jones)
Revision 20, 2015-11-03 (Daniel Rakos)
Revision 21, 2015-11-10 (Jesse Hall)
Revision 22, 2015-12-18 (James Jones)
VK_KHR_display_swapchain
VK_KHR_swapchain
and VK_KHR_display
This extension provides an API to create a swapchain directly on a device’s display without any underlying window system.
Extending VkStructureType
:
VK_STRUCTURE_TYPE_DISPLAY_PRESENT_INFO_KHR
Extending VkResult
:
VK_ERROR_INCOMPATIBLE_DISPLAY_KHR
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?
PROPOSED RESOLUTION: 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?
PROPOSED RESOLUTION: 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 presentable images.
3) Should srcRect/dstRect be specified as rects, or separate offset/extent values?
PROPOSED RESOLUTION: 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?
RESOLUTION: 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.
Example 1
Create a swapchain on a display mode and plane
// See VK_KHR_display for an example of how to pick a display, // display mode, plane, and how to create a VkSurfaceKHR for // that plane. extern VkPhysicalDevice physDevice; extern VkDisplayModePropertiesKHR myModeProps; extern VkSurfaceKHR mySurface; extern VkDevice device; uint32_t queueCount, i; uint32_t presentQueueFamilyIndex = UINT32_MAX; VkBool32 supportsPresent; // Find a queue family that supports presenting to this surface uint32_t familyCount; vkGetPhysicalDeviceQueueFamilyProperties(physDevice, &familyCount, NULL); for (i = 0; i < familyCount; ++i) { vkGetPhysicalDeviceSurfaceSupportKHR(physDevice, i, mySurface, &supportsPresent); if (supportsPresent) { // Found a queue family that supports present. See // VK_KHR_surface for an example of how to find a queue that // supports both presentation and graphics presentQueueFamilyIndex = i; break; } } // Figure out which formats and present modes this surface supports. uint32_t formatCount; vkGetPhysicalDeviceSurfaceFormatsKHR(physDevice, mySurface, &formatCount, NULL); VkSurfaceFormatKHR* formats = (VkSurfaceFormatKHR*)malloc(sizeof(VkSurfaceFormatKHR) * formatCount); vkGetPhysicalDeviceSurfaceFormatsKHR(physDevice, mySurface, &formatCount, formats); const VkSwapchainCreateInfoKHR createInfo = { VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR, // sType NULL, // pNext 0, // flags mySurface, // surface 3, // minImageCount formats[0].format, // imageFormat formats[0].colorSpace, // imageColorSpace myModeProps.parameters.visibleRegion, // imageExtent 1, // imageArrayLayers VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT, // imageUsage VK_SHARING_MODE_EXCLUSIVE, // imageSharingMode 0, // queueFamilyIndexCount NULL, // pQueueFamilyIndices VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR, // preTransform VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR, // compositeAlpha VK_PRESENT_MODE_FIFO_KHR, // presentMode VK_TRUE, // clipped VK_NULL_HANDLE // oldSwapchain }; VkSwapchainKHR swapchain; // This is equivalent to vkCreateSwapchainKHR. vkCreateSharedSwapchainsKHR(device, 1, &createInfo, NULL, &swapchain);
Revision 1, 2015-07-29 (James Jones)
Revision 2, 2015-08-21 (Ian Elliott)
Revision 3, 2015-09-01 (James Jones)
Revision 4, 2015-09-08 (James Jones)
Revision 5, 2015-09-10 (Alon Or-bach)
Revision 6, 2015-10-02 (James Jones)
Revision 7, 2015-10-26 (Ian Elliott)
Revision 8, 2015-11-03 (Daniel Rakos)
Revision 9, 2015-11-10 (Jesse Hall)
VkDisplaySwapchainCreateInfoKHR
with
vkCreateSharedSwapchainsKHR, changing resolution of issue #4.
VK_KHR_android_surface
VK_KHR_surface
.
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.
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 GPU 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.
Revision 1, 2015-09-23 (Jesse Hall)
Revision 2, 2015-10-26 (Ian Elliott)
Revision 3, 2015-11-03 (Daniel Rakos)
Revision 4, 2015-11-10 (Jesse Hall)
Revision 5, 2015-11-28 (Daniel Rakos)
Revision 6, 2016-01-14 (James Jones)
VK_KHR_mir_surface
VK_KHR_surface
.
The VK_KHR_mir_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 Mir surface, as well as a
query to determine support for rendering to the windows desktop.
1) Does Mir need a way to query for compatibility between a particular physical device (and queue family?) and a specific Mir connection, screen, window, etc.?
RESOLVED: Yes, vkGetPhysicalDeviceMirPresentationSupportKHR() was added to address this.
Revision 1, 2015-09-23 (Jesse Hall)
Revision 2, 2015-10-02 (James Jones)
Revision 3, 2015-10-26 (Ian Elliott)
Revision 4, 2015-11-28 (Daniel Rakos)
VK_KHR_wayland_surface
VK_KHR_surface
.
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 the windows desktop.
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 true for a (VkPhysicalDevice, struct wl_display*) pair, then the physical device could be assumed to support presentation to any VkSurface for surfaces on the display.
RESOLVED: Yes. vkGetPhysicalDeviceWaylandPresentationSupportKHR() was added to address this issue.
Revision 1, 2015-09-23 (Jesse Hall)
Revision 2, 2015-10-02 (James Jones)
Revision 3, 2015-10-26 (Ian Elliott)
Revision 4, 2015-11-03 (Daniel Rakos)
Revision 5, 2015-11-28 (Daniel Rakos)
VK_KHR_win32_surface
VK_KHR_surface
.
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.
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.
Revision 1, 2015-09-23 (Jesse Hall)
Revision 2, 2015-10-02 (James Jones)
Revision 3, 2015-10-26 (Ian Elliott)
Revision 4, 2015-11-03 (Daniel Rakos)
Revision 5, 2015-11-28 (Daniel Rakos)
VK_KHR_xcb_surface
VK_KHR_surface
.
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.
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 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.
Revision 1, 2015-09-23 (Jesse Hall)
Revision 2, 2015-10-02 (James Jones)
Revision 3, 2015-10-14 (Ian Elliott)
Revision 4, 2015-10-26 (Ian Elliott)
Revision 5, 2015-10-23 (Daniel Rakos)
Revision 6, 2015-11-28 (Daniel Rakos)
VK_KHR_xlib_surface
VK_KHR_surface
.
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.
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 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.
Revision 1, 2015-09-23 (Jesse Hall)
Revision 2, 2015-10-02 (James Jones)
Revision 3, 2015-10-14 (Ian Elliott)
Revision 4, 2015-10-26 (Ian Elliott)
Revision 5, 2015-11-03 (Daniel Rakos)
Revision 6, 2015-11-28 (Daniel Rakos)