Safe Haskell | None |
---|---|
Language | Haskell2010 |
Name
VK_KHR_swapchain - device extension
VK_KHR_swapchain
- Name String
VK_KHR_swapchain
- Extension Type
- Device extension
- Registered Extension Number
- 2
- Revision
- 70
- Extension and Version Dependencies
- Requires Vulkan 1.0
- Requires
VK_KHR_surface
- Contact
Other Extension Metadata
- 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
Description
The VK_KHR_swapchain
extension is the device-level companion to the
VK_KHR_surface
extension. It introduces
SwapchainKHR
objects, which provide the
ability to present rendering results to a surface.
New Object Types
New Commands
If Version 1.1 is supported:
acquireNextImage2KHR
getDeviceGroupPresentCapabilitiesKHR
getDeviceGroupSurfacePresentModesKHR
getPhysicalDevicePresentRectanglesKHR
New Structures
If Version 1.1 is supported:
AcquireNextImageInfoKHR
DeviceGroupPresentCapabilitiesKHR
Extending
BindImageMemoryInfo
:Extending
ImageCreateInfo
:Extending
PresentInfoKHR
:Extending
SwapchainCreateInfoKHR
:
New Enums
If Version 1.1 is supported:
New Bitmasks
If Version 1.1 is supported:
New Enum Constants
KHR_SWAPCHAIN_SPEC_VERSION
Extending
ImageLayout
:Extending
ObjectType
:Extending
Result
:Extending
StructureType
:
If Version 1.1 is supported:
Extending
StructureType
:Extending
SwapchainCreateFlagBitsKHR
:
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 acquireNextImageKHR
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 queuePresentKHR
call?
RESOLVED: Yes. PresentInfoKHR
contains a list of swapchains and
corresponding image indices that will be presented. When supported, all
presentations queued with a single queuePresentKHR
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:
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.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 acquireNextImageKHR
and
queuePresentKHR
.
10) Does the acquireNextImageKHR
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 reused for other operations
once it is received from acquireNextImageKHR
.
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 reuse 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 information 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 PRESENT_MODE_MAILBOX_KHR
provide non-blocking guarantees for acquireNextImageKHR
? 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 acquireNextImageKHR
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 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
SurfaceCapabilitiesKHR
::maxImageCount
to indicate there are no practical limits on the number of images in a
swapchain?
RESOLVED: Yes. There will 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
SurfaceCapabilitiesKHR
::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
SurfaceCapabilitiesKHR
::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
indicate 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:
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
SurfaceCapabilitiesKHR
.
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 efficient 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
ColorSpaceKHR
along with
Format
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
getPhysicalDeviceSurfaceFormatsKHR
.
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
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 those formats. Still, it is
unlikely that a swapchain will expose a *_SRGB
format along with any
color space other than
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 lifetimes of surfaces and swapchains targeting them related?
RESOLVED: A surface must outlive any swapchains targeting it. A
SurfaceKHR
owns the binding of the native
window to the Vulkan driver.
26) How can the client control the way the alpha component 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
COMPOSITE_ALPHA_INHERIT_BIT_KHR
is
provided like for surface transforms.
27) Is createSwapchainKHR
the right function to return
ERROR_NATIVE_WINDOW_IN_USE_KHR
, or should
the various platform-specific SurfaceKHR
factory functions catch this error earlier?
RESOLVED: For most platforms, the
SurfaceKHR
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 SurfaceKHR
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 information 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 specification’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).
- Updated to work with version 138 of the
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 reused 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
See Also
PresentInfoKHR
, SwapchainCreateFlagBitsKHR
,
SwapchainCreateFlagsKHR
, SwapchainCreateInfoKHR
,
SwapchainKHR
, acquireNextImageKHR
,
createSwapchainKHR
, destroySwapchainKHR
, getSwapchainImagesKHR
,
queuePresentKHR
Document Notes
For more information, see the Vulkan Specification
This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.
Synopsis
- createSwapchainKHR :: forall a io. (Extendss SwapchainCreateInfoKHR a, PokeChain a, MonadIO io) => Device -> SwapchainCreateInfoKHR a -> ("allocator" ::: Maybe AllocationCallbacks) -> io SwapchainKHR
- withSwapchainKHR :: forall a io r. (Extendss SwapchainCreateInfoKHR a, PokeChain a, MonadIO io) => Device -> SwapchainCreateInfoKHR a -> Maybe AllocationCallbacks -> (io SwapchainKHR -> (SwapchainKHR -> io ()) -> r) -> r
- destroySwapchainKHR :: forall io. MonadIO io => Device -> SwapchainKHR -> ("allocator" ::: Maybe AllocationCallbacks) -> io ()
- getSwapchainImagesKHR :: forall io. MonadIO io => Device -> SwapchainKHR -> io (Result, "swapchainImages" ::: Vector Image)
- acquireNextImageKHR :: forall io. MonadIO io => Device -> SwapchainKHR -> ("timeout" ::: Word64) -> Semaphore -> Fence -> io (Result, "imageIndex" ::: Word32)
- acquireNextImageKHRSafe :: forall io. MonadIO io => Device -> SwapchainKHR -> ("timeout" ::: Word64) -> Semaphore -> Fence -> io (Result, "imageIndex" ::: Word32)
- queuePresentKHR :: forall a io. (Extendss PresentInfoKHR a, PokeChain a, MonadIO io) => Queue -> PresentInfoKHR a -> io Result
- getDeviceGroupPresentCapabilitiesKHR :: forall io. MonadIO io => Device -> io DeviceGroupPresentCapabilitiesKHR
- getDeviceGroupSurfacePresentModesKHR :: forall io. MonadIO io => Device -> SurfaceKHR -> io ("modes" ::: DeviceGroupPresentModeFlagsKHR)
- acquireNextImage2KHR :: forall io. MonadIO io => Device -> ("acquireInfo" ::: AcquireNextImageInfoKHR) -> io (Result, "imageIndex" ::: Word32)
- acquireNextImage2KHRSafe :: forall io. MonadIO io => Device -> ("acquireInfo" ::: AcquireNextImageInfoKHR) -> io (Result, "imageIndex" ::: Word32)
- getPhysicalDevicePresentRectanglesKHR :: forall io. MonadIO io => PhysicalDevice -> SurfaceKHR -> io (Result, "rects" ::: Vector Rect2D)
- data SwapchainCreateInfoKHR (es :: [Type]) = SwapchainCreateInfoKHR {
- next :: Chain es
- flags :: SwapchainCreateFlagsKHR
- surface :: SurfaceKHR
- minImageCount :: Word32
- imageFormat :: Format
- imageColorSpace :: ColorSpaceKHR
- imageExtent :: Extent2D
- imageArrayLayers :: Word32
- imageUsage :: ImageUsageFlags
- imageSharingMode :: SharingMode
- queueFamilyIndices :: Vector Word32
- preTransform :: SurfaceTransformFlagBitsKHR
- compositeAlpha :: CompositeAlphaFlagBitsKHR
- presentMode :: PresentModeKHR
- clipped :: Bool
- oldSwapchain :: SwapchainKHR
- data PresentInfoKHR (es :: [Type]) = PresentInfoKHR {
- next :: Chain es
- waitSemaphores :: Vector Semaphore
- swapchains :: Vector SwapchainKHR
- imageIndices :: Vector Word32
- results :: Ptr Result
- data DeviceGroupPresentCapabilitiesKHR = DeviceGroupPresentCapabilitiesKHR {}
- data ImageSwapchainCreateInfoKHR = ImageSwapchainCreateInfoKHR {}
- data BindImageMemorySwapchainInfoKHR = BindImageMemorySwapchainInfoKHR {}
- data AcquireNextImageInfoKHR = AcquireNextImageInfoKHR {
- swapchain :: SwapchainKHR
- timeout :: Word64
- semaphore :: Semaphore
- fence :: Fence
- deviceMask :: Word32
- data DeviceGroupPresentInfoKHR = DeviceGroupPresentInfoKHR {}
- data DeviceGroupSwapchainCreateInfoKHR = DeviceGroupSwapchainCreateInfoKHR {}
- type DeviceGroupPresentModeFlagsKHR = DeviceGroupPresentModeFlagBitsKHR
- newtype DeviceGroupPresentModeFlagBitsKHR where
- DeviceGroupPresentModeFlagBitsKHR Flags
- pattern DEVICE_GROUP_PRESENT_MODE_LOCAL_BIT_KHR :: DeviceGroupPresentModeFlagBitsKHR
- pattern DEVICE_GROUP_PRESENT_MODE_REMOTE_BIT_KHR :: DeviceGroupPresentModeFlagBitsKHR
- pattern DEVICE_GROUP_PRESENT_MODE_SUM_BIT_KHR :: DeviceGroupPresentModeFlagBitsKHR
- pattern DEVICE_GROUP_PRESENT_MODE_LOCAL_MULTI_DEVICE_BIT_KHR :: DeviceGroupPresentModeFlagBitsKHR
- type SwapchainCreateFlagsKHR = SwapchainCreateFlagBitsKHR
- newtype SwapchainCreateFlagBitsKHR where
- type KHR_SWAPCHAIN_SPEC_VERSION = 70
- pattern KHR_SWAPCHAIN_SPEC_VERSION :: forall a. Integral a => a
- type KHR_SWAPCHAIN_EXTENSION_NAME = "VK_KHR_swapchain"
- pattern KHR_SWAPCHAIN_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a
- newtype SurfaceKHR = SurfaceKHR Word64
- newtype SwapchainKHR = SwapchainKHR Word64
- newtype PresentModeKHR where
- PresentModeKHR Int32
- pattern PRESENT_MODE_IMMEDIATE_KHR :: PresentModeKHR
- pattern PRESENT_MODE_MAILBOX_KHR :: PresentModeKHR
- pattern PRESENT_MODE_FIFO_KHR :: PresentModeKHR
- pattern PRESENT_MODE_FIFO_RELAXED_KHR :: PresentModeKHR
- pattern PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR :: PresentModeKHR
- pattern PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR :: PresentModeKHR
- newtype ColorSpaceKHR where
- ColorSpaceKHR Int32
- pattern COLOR_SPACE_DISPLAY_P3_LINEAR_EXT :: ColorSpaceKHR
- pattern COLOR_SPACE_SRGB_NONLINEAR_KHR :: ColorSpaceKHR
- pattern COLOR_SPACE_DISPLAY_NATIVE_AMD :: ColorSpaceKHR
- pattern COLOR_SPACE_EXTENDED_SRGB_NONLINEAR_EXT :: ColorSpaceKHR
- pattern COLOR_SPACE_PASS_THROUGH_EXT :: ColorSpaceKHR
- pattern COLOR_SPACE_ADOBERGB_NONLINEAR_EXT :: ColorSpaceKHR
- pattern COLOR_SPACE_ADOBERGB_LINEAR_EXT :: ColorSpaceKHR
- pattern COLOR_SPACE_HDR10_HLG_EXT :: ColorSpaceKHR
- pattern COLOR_SPACE_DOLBYVISION_EXT :: ColorSpaceKHR
- pattern COLOR_SPACE_HDR10_ST2084_EXT :: ColorSpaceKHR
- pattern COLOR_SPACE_BT2020_LINEAR_EXT :: ColorSpaceKHR
- pattern COLOR_SPACE_BT709_NONLINEAR_EXT :: ColorSpaceKHR
- pattern COLOR_SPACE_BT709_LINEAR_EXT :: ColorSpaceKHR
- pattern COLOR_SPACE_DCI_P3_NONLINEAR_EXT :: ColorSpaceKHR
- pattern COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT :: ColorSpaceKHR
- pattern COLOR_SPACE_DISPLAY_P3_NONLINEAR_EXT :: ColorSpaceKHR
- newtype CompositeAlphaFlagBitsKHR where
- CompositeAlphaFlagBitsKHR Flags
- pattern COMPOSITE_ALPHA_OPAQUE_BIT_KHR :: CompositeAlphaFlagBitsKHR
- pattern COMPOSITE_ALPHA_PRE_MULTIPLIED_BIT_KHR :: CompositeAlphaFlagBitsKHR
- pattern COMPOSITE_ALPHA_POST_MULTIPLIED_BIT_KHR :: CompositeAlphaFlagBitsKHR
- pattern COMPOSITE_ALPHA_INHERIT_BIT_KHR :: CompositeAlphaFlagBitsKHR
- type CompositeAlphaFlagsKHR = CompositeAlphaFlagBitsKHR
- newtype SurfaceTransformFlagBitsKHR where
- SurfaceTransformFlagBitsKHR Flags
- pattern SURFACE_TRANSFORM_IDENTITY_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_ROTATE_90_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_ROTATE_180_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_ROTATE_270_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_HORIZONTAL_MIRROR_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_HORIZONTAL_MIRROR_ROTATE_90_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_HORIZONTAL_MIRROR_ROTATE_180_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_HORIZONTAL_MIRROR_ROTATE_270_BIT_KHR :: SurfaceTransformFlagBitsKHR
- pattern SURFACE_TRANSFORM_INHERIT_BIT_KHR :: SurfaceTransformFlagBitsKHR
- type SurfaceTransformFlagsKHR = SurfaceTransformFlagBitsKHR
Documentation
:: forall a io. (Extendss SwapchainCreateInfoKHR a, PokeChain a, MonadIO io) | |
=> Device |
|
-> SwapchainCreateInfoKHR a |
|
-> ("allocator" ::: Maybe AllocationCallbacks) |
|
-> io SwapchainKHR |
vkCreateSwapchainKHR - Create a swapchain
Description
If the oldSwapchain
parameter of pCreateInfo
is a valid swapchain,
which has exclusive full-screen access, that access is released from
oldSwapchain
. If the command succeeds in this case, the newly created
swapchain will automatically acquire exclusive full-screen access from
oldSwapchain
.
Note
This implicit transfer is intended to avoid exiting and entering full-screen exclusive mode, which may otherwise cause unwanted visual updates to the display.
In some cases, swapchain creation may fail if exclusive full-screen
mode is requested for application control, but for some
implementation-specific reason exclusive full-screen access is
unavailable for the particular combination of parameters provided. If
this occurs, ERROR_INITIALIZATION_FAILED
will be returned.
Note
In particular, it will fail if the imageExtent
member of pCreateInfo
does not match the extents of the monitor. Other reasons for failure may
include the app not being set as high-dpi aware, or if the physical
device and monitor are not compatible in this mode.
When the SurfaceKHR
in
SwapchainCreateInfoKHR
is a display surface, then the
DisplayModeKHR
in display surface’s
DisplaySurfaceCreateInfoKHR
is
associated with a particular DisplayKHR
.
Swapchain creation may fail if that
DisplayKHR
is not acquired by the
application. In this scenario
ERROR_INITIALIZATION_FAILED
is returned.
Valid Usage (Implicit)
-
device
must be a validDevice
handle
-
pCreateInfo
must be a valid pointer to a validSwapchainCreateInfoKHR
structure - If
pAllocator
is notNULL
,pAllocator
must be a valid pointer to a validAllocationCallbacks
structure -
pSwapchain
must be a valid pointer to aSwapchainKHR
handle
Host Synchronization
- Host access to
pCreateInfo->surface
must be externally synchronized
- Host access to
pCreateInfo->oldSwapchain
must be externally synchronized
Return Codes
See Also
VK_KHR_swapchain,
AllocationCallbacks
,
Device
, SwapchainCreateInfoKHR
,
SwapchainKHR
withSwapchainKHR :: forall a io r. (Extendss SwapchainCreateInfoKHR a, PokeChain a, MonadIO io) => Device -> SwapchainCreateInfoKHR a -> Maybe AllocationCallbacks -> (io SwapchainKHR -> (SwapchainKHR -> io ()) -> r) -> r Source #
A convenience wrapper to make a compatible pair of calls to
createSwapchainKHR
and destroySwapchainKHR
To ensure that destroySwapchainKHR
is always called: pass
bracket
(or the allocate function from your
favourite resource management library) as the last argument.
To just extract the pair pass (,)
as the last argument.
:: forall io. MonadIO io | |
=> Device |
|
-> SwapchainKHR |
|
-> ("allocator" ::: Maybe AllocationCallbacks) |
|
-> io () |
vkDestroySwapchainKHR - Destroy a swapchain object
Description
The application must not destroy a swapchain until after completion of
all outstanding operations on images that were acquired from the
swapchain. swapchain
and all associated Image
handles are destroyed, and must not be acquired or used any more by
the application. The memory of each Image
will
only be freed after that image is no longer used by the presentation
engine. For example, if one image of the swapchain is being displayed in
a window, the memory for that image may not be freed until the window
is destroyed, or another swapchain is created for the window. Destroying
the swapchain does not invalidate the parent
SurfaceKHR
, and a new swapchain can be
created with it.
When a swapchain associated with a display surface is destroyed, if the image most recently presented to the display surface is from the swapchain being destroyed, then either any display resources modified by presenting images from any swapchain associated with the display surface must be reverted by the implementation to their state prior to the first present performed on one of these swapchains, or such resources must be left in their current state.
If swapchain
has exclusive full-screen access, it is released before
the swapchain is destroyed.
Valid Usage
- If
AllocationCallbacks
were provided whenswapchain
was created, a compatible set of callbacks must be provided here - If no
AllocationCallbacks
were provided whenswapchain
was created,pAllocator
must beNULL
Valid Usage (Implicit)
-
device
must be a validDevice
handle
- If
swapchain
is notNULL_HANDLE
,swapchain
must be a validSwapchainKHR
handle - If
pAllocator
is notNULL
,pAllocator
must be a valid pointer to a validAllocationCallbacks
structure - Both of
device
, andswapchain
that are valid handles of non-ignored parameters must have been created, allocated, or retrieved from the sameInstance
Host Synchronization
- Host access to
swapchain
must be externally synchronized
See Also
getSwapchainImagesKHR Source #
:: forall io. MonadIO io | |
=> Device |
|
-> SwapchainKHR |
|
-> io (Result, "swapchainImages" ::: Vector Image) |
vkGetSwapchainImagesKHR - Obtain the array of presentable images associated with a swapchain
Description
If pSwapchainImages
is NULL
, then the number of presentable images
for swapchain
is returned in pSwapchainImageCount
. Otherwise,
pSwapchainImageCount
must point to a variable set by the user to the
number of elements in the pSwapchainImages
array, and on return the
variable is overwritten with the number of structures actually written
to pSwapchainImages
. If the value of pSwapchainImageCount
is less
than the number of presentable images for swapchain
, at most
pSwapchainImageCount
structures will be written, and
INCOMPLETE
will be returned instead of
SUCCESS
, to indicate that not all the
available presentable images were returned.
Valid Usage (Implicit)
-
device
must be a validDevice
handle
-
swapchain
must be a validSwapchainKHR
handle -
pSwapchainImageCount
must be a valid pointer to auint32_t
value - If the
value referenced by
pSwapchainImageCount
is not0
, andpSwapchainImages
is notNULL
,pSwapchainImages
must be a valid pointer to an array ofpSwapchainImageCount
Image
handles - Both of
device
, andswapchain
must have been created, allocated, or retrieved from the sameInstance
Return Codes
See Also
:: forall io. MonadIO io | |
=> Device |
|
-> SwapchainKHR |
|
-> ("timeout" ::: Word64) |
|
-> Semaphore |
|
-> Fence |
|
-> io (Result, "imageIndex" ::: Word32) |
vkAcquireNextImageKHR - Retrieve the index of the next available presentable image
Valid Usage
- If
semaphore
is notNULL_HANDLE
it must be unsignaled - If
semaphore
is notNULL_HANDLE
it must not have any uncompleted signal or wait operations pending - If
fence
is notNULL_HANDLE
it must be unsignaled and must not be associated with any other queue command that has not yet completed execution on that queue -
semaphore
andfence
must not both be equal toNULL_HANDLE
- If the number of
currently acquired images is greater than the difference between the
number of images in
swapchain
and the value ofSurfaceCapabilitiesKHR
::minImageCount
as returned by a call togetPhysicalDeviceSurfaceCapabilities2KHR
with thesurface
used to createswapchain
,timeout
must not beUINT64_MAX
-
semaphore
must have aSemaphoreType
ofSEMAPHORE_TYPE_BINARY
Valid Usage (Implicit)
-
device
must be a validDevice
handle
-
swapchain
must be a validSwapchainKHR
handle - If
semaphore
is notNULL_HANDLE
,semaphore
must be a validSemaphore
handle - If
fence
is notNULL_HANDLE
,fence
must be a validFence
handle -
pImageIndex
must be a valid pointer to auint32_t
value - If
semaphore
is a valid handle, it must have been created, allocated, or retrieved fromdevice
- If
fence
is a valid handle, it must have been created, allocated, or retrieved fromdevice
- Both of
device
, andswapchain
that are valid handles of non-ignored parameters must have been created, allocated, or retrieved from the sameInstance
Host Synchronization
- Host access to
swapchain
must be externally synchronized
- Host access to
semaphore
must be externally synchronized - Host access to
fence
must be externally synchronized
Return Codes
See Also
acquireNextImageKHRSafe Source #
:: forall io. MonadIO io | |
=> Device |
|
-> SwapchainKHR |
|
-> ("timeout" ::: Word64) |
|
-> Semaphore |
|
-> Fence |
|
-> io (Result, "imageIndex" ::: Word32) |
A variant of acquireNextImageKHR
which makes a *safe* FFI call
:: forall a io. (Extendss PresentInfoKHR a, PokeChain a, MonadIO io) | |
=> Queue |
|
-> PresentInfoKHR a |
|
-> io Result |
vkQueuePresentKHR - Queue an image for presentation
Description
Note
There is no requirement for an application to present images in the same order that they were acquired - applications can arbitrarily present any image that is currently acquired.
Valid Usage
- Each element of
pSwapchains
member ofpPresentInfo
must be a swapchain that is created for a surface for which presentation is supported fromqueue
as determined using a call togetPhysicalDeviceSurfaceSupportKHR
- If more than one member
of
pSwapchains
was created from a display surface, all display surfaces referenced that refer to the same display must use the same display mode - When a semaphore wait
operation referring to a binary semaphore defined by the elements of
the
pWaitSemaphores
member ofpPresentInfo
executes onqueue
, there must be no other queues waiting on the same semaphore - All elements of the
pWaitSemaphores
member ofpPresentInfo
must be semaphores that are signaled, or have semaphore signal operations previously submitted for execution - All elements of the
pWaitSemaphores
member ofpPresentInfo
must be created with aSemaphoreType
ofSEMAPHORE_TYPE_BINARY
- All elements of the
pWaitSemaphores
member ofpPresentInfo
must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends (if any) must have also been submitted for execution
Any writes to memory backing the images referenced by the
pImageIndices
and pSwapchains
members of pPresentInfo
, that are
available before queuePresentKHR
is executed, are automatically made
visible to the read access performed by the presentation engine. This
automatic visibility operation for an image happens-after the semaphore
signal operation, and happens-before the presentation engine accesses
the image.
Queueing an image for presentation defines a set of queue operations, including waiting on the semaphores and submitting a presentation request to the presentation engine. However, the scope of this set of queue operations does not include the actual processing of the image by the presentation engine.
Note
The origin of the native orientation of the surface coordinate system is
not specified in the Vulkan specification; it depends on the platform.
For most platforms the origin is by default upper-left, meaning the
pixel of the presented Image
at coordinates
(0,0) would appear at the upper left pixel of the platform surface
(assuming
SURFACE_TRANSFORM_IDENTITY_BIT_KHR
,
and the display standing the right way up).
If queuePresentKHR
fails to enqueue the corresponding set of queue
operations, it may return
ERROR_OUT_OF_HOST_MEMORY
or
ERROR_OUT_OF_DEVICE_MEMORY
. If it does, the
implementation must ensure that the state and contents of any
resources or synchronization primitives referenced is unaffected by the
call or its failure.
If queuePresentKHR
fails in such a way that the implementation is
unable to make that guarantee, the implementation must return
ERROR_DEVICE_LOST
.
However, if the presentation request is rejected by the presentation
engine with an error ERROR_OUT_OF_DATE_KHR
,
ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT
,
or ERROR_SURFACE_LOST_KHR
, the set of queue
operations are still considered to be enqueued and thus any semaphore
wait operation specified in PresentInfoKHR
will execute when the
corresponding queue operation is complete.
Calls to queuePresentKHR
may block, but must return in finite
time.
If any swapchain
member of pPresentInfo
was created with
FULL_SCREEN_EXCLUSIVE_APPLICATION_CONTROLLED_EXT
,
ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT
will be returned if that swapchain does not have exclusive full-screen
access, possibly for implementation-specific reasons outside of the
application’s control.
Valid Usage (Implicit)
-
queue
must be a validQueue
handle
-
pPresentInfo
must be a valid pointer to a validPresentInfoKHR
structure
Host Synchronization
- Host access to
queue
must be externally synchronized
- Host access to
pPresentInfo->pWaitSemaphores
[] must be externally synchronized - Host access to
pPresentInfo->pSwapchains
[] must be externally synchronized
Command Properties
'
Command Buffer Levels | Render Pass Scope | Supported Queue Types |
---|---|---|
- | - | Any |
Return Codes
See Also
getDeviceGroupPresentCapabilitiesKHR Source #
:: forall io. MonadIO io | |
=> Device |
|
-> io DeviceGroupPresentCapabilitiesKHR |
vkGetDeviceGroupPresentCapabilitiesKHR - Query present capabilities from other physical devices
Return Codes
See Also
VK_KHR_device_group,
VK_KHR_surface,
VK_KHR_swapchain,
VK_VERSION_1_1,
Device
, DeviceGroupPresentCapabilitiesKHR
getDeviceGroupSurfacePresentModesKHR Source #
:: forall io. MonadIO io | |
=> Device |
|
-> SurfaceKHR |
|
-> io ("modes" ::: DeviceGroupPresentModeFlagsKHR) |
vkGetDeviceGroupSurfacePresentModesKHR - Query present capabilities for a surface
Description
The modes returned by this command are not invariant, and may change
in response to the surface being moved, resized, or occluded. These
modes must be a subset of the modes returned by
getDeviceGroupPresentCapabilitiesKHR
.
Valid Usage
-
surface
must be supported by all physical devices associated withdevice
, as reported bygetPhysicalDeviceSurfaceSupportKHR
or an equivalent platform-specific mechanism
Valid Usage (Implicit)
-
device
must be a validDevice
handle
-
surface
must be a validSurfaceKHR
handle -
pModes
must be a valid pointer to aDeviceGroupPresentModeFlagsKHR
value - Both of
device
, andsurface
must have been created, allocated, or retrieved from the sameInstance
Host Synchronization
- Host access to
surface
must be externally synchronized
Return Codes
See Also
VK_KHR_device_group,
VK_KHR_surface,
VK_KHR_swapchain,
VK_VERSION_1_1,
Device
, DeviceGroupPresentModeFlagsKHR
,
SurfaceKHR
:: forall io. MonadIO io | |
=> Device |
|
-> ("acquireInfo" ::: AcquireNextImageInfoKHR) |
|
-> io (Result, "imageIndex" ::: Word32) |
vkAcquireNextImage2KHR - Retrieve the index of the next available presentable image
Valid Usage
- If the number of
currently acquired images is greater than the difference between the
number of images in the
swapchain
member ofpAcquireInfo
and the value ofSurfaceCapabilitiesKHR
::minImageCount
as returned by a call togetPhysicalDeviceSurfaceCapabilities2KHR
with thesurface
used to createswapchain
, thetimeout
member ofpAcquireInfo
must not beUINT64_MAX
Valid Usage (Implicit)
-
device
must be a validDevice
handle
-
pAcquireInfo
must be a valid pointer to a validAcquireNextImageInfoKHR
structure -
pImageIndex
must be a valid pointer to auint32_t
value
Return Codes
See Also
VK_KHR_device_group,
VK_KHR_swapchain,
VK_VERSION_1_1,
AcquireNextImageInfoKHR
, Device
acquireNextImage2KHRSafe Source #
:: forall io. MonadIO io | |
=> Device |
|
-> ("acquireInfo" ::: AcquireNextImageInfoKHR) |
|
-> io (Result, "imageIndex" ::: Word32) |
A variant of acquireNextImage2KHR
which makes a *safe* FFI call
getPhysicalDevicePresentRectanglesKHR Source #
:: forall io. MonadIO io | |
=> PhysicalDevice |
|
-> SurfaceKHR |
|
-> io (Result, "rects" ::: Vector Rect2D) |
vkGetPhysicalDevicePresentRectanglesKHR - Query present rectangles for a surface on a physical device
Description
If pRects
is NULL
, then the number of rectangles used when
presenting the given surface
is returned in pRectCount
. Otherwise,
pRectCount
must point to a variable set by the user to the number of
elements in the pRects
array, and on return the variable is
overwritten with the number of structures actually written to pRects
.
If the value of pRectCount
is less than the number of rectangles, at
most pRectCount
structures will be written, and
INCOMPLETE
will be returned instead of
SUCCESS
, to indicate that not all the
available rectangles were returned.
The values returned by this command are not invariant, and may change in response to the surface being moved, resized, or occluded.
The rectangles returned by this command must not overlap.
Valid Usage
-
surface
must be supported byphysicalDevice
, as reported bygetPhysicalDeviceSurfaceSupportKHR
or an equivalent platform-specific mechanism
Valid Usage (Implicit)
-
physicalDevice
must be a validPhysicalDevice
handle
-
surface
must be a validSurfaceKHR
handle -
pRectCount
must be a valid pointer to auint32_t
value - If
the value referenced by
pRectCount
is not0
, andpRects
is notNULL
,pRects
must be a valid pointer to an array ofpRectCount
Rect2D
structures - Both of
physicalDevice
, andsurface
must have been created, allocated, or retrieved from the sameInstance
Host Synchronization
- Host access to
surface
must be externally synchronized
Return Codes
See Also
VK_KHR_device_group,
VK_KHR_surface,
VK_KHR_swapchain,
VK_VERSION_1_1,
PhysicalDevice
,
Rect2D
,
SurfaceKHR
data SwapchainCreateInfoKHR (es :: [Type]) Source #
VkSwapchainCreateInfoKHR - Structure specifying parameters of a newly created swapchain object
Description
Upon calling createSwapchainKHR
with an oldSwapchain
that is not
NULL_HANDLE
, oldSwapchain
is
retired — even if creation of the new swapchain fails. The new swapchain
is created in the non-retired state whether or not oldSwapchain
is
NULL_HANDLE
.
Upon calling createSwapchainKHR
with an oldSwapchain
that is not
NULL_HANDLE
, any images from oldSwapchain
that are not acquired by the application may be freed by the
implementation, which may occur even if creation of the new swapchain
fails. The application can destroy oldSwapchain
to free all memory
associated with oldSwapchain
.
Note
Multiple retired swapchains can be associated with the same
SurfaceKHR
through multiple uses of
oldSwapchain
that outnumber calls to destroySwapchainKHR
.
After oldSwapchain
is retired, the application can pass to
queuePresentKHR
any images it had already acquired from
oldSwapchain
. E.g., an application may present an image from the old
swapchain before an image from the new swapchain is ready to be
presented. As usual, queuePresentKHR
may fail if oldSwapchain
has
entered a state that causes
ERROR_OUT_OF_DATE_KHR
to be returned.
The application can continue to use a shared presentable image
obtained from oldSwapchain
until a presentable image is acquired from
the new swapchain, as long as it has not entered a state that causes it
to return ERROR_OUT_OF_DATE_KHR
.
Valid Usage
-
surface
must be a surface that is supported by the device as determined usinggetPhysicalDeviceSurfaceSupportKHR
-
minImageCount
must be less than or equal to the value returned in themaxImageCount
member of theSurfaceCapabilitiesKHR
structure returned bygetPhysicalDeviceSurfaceCapabilitiesKHR
for the surface if the returnedmaxImageCount
is not zero - If
presentMode
is notPRESENT_MODE_SHARED_DEMAND_REFRESH_KHR
norPRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR
, thenminImageCount
must be greater than or equal to the value returned in theminImageCount
member of theSurfaceCapabilitiesKHR
structure returned bygetPhysicalDeviceSurfaceCapabilitiesKHR
for the surface -
minImageCount
must be1
ifpresentMode
is eitherPRESENT_MODE_SHARED_DEMAND_REFRESH_KHR
orPRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR
-
imageFormat
andimageColorSpace
must match theformat
andcolorSpace
members, respectively, of one of theSurfaceFormatKHR
structures returned bygetPhysicalDeviceSurfaceFormatsKHR
for the surface -
imageExtent
must be betweenminImageExtent
andmaxImageExtent
, inclusive, whereminImageExtent
andmaxImageExtent
are members of theSurfaceCapabilitiesKHR
structure returned bygetPhysicalDeviceSurfaceCapabilitiesKHR
for the surface -
imageExtent
memberswidth
andheight
must both be non-zero -
imageArrayLayers
must be greater than0
and less than or equal to themaxImageArrayLayers
member of theSurfaceCapabilitiesKHR
structure returned bygetPhysicalDeviceSurfaceCapabilitiesKHR
for the surface - If
presentMode
isPRESENT_MODE_IMMEDIATE_KHR
,PRESENT_MODE_MAILBOX_KHR
,PRESENT_MODE_FIFO_KHR
orPRESENT_MODE_FIFO_RELAXED_KHR
,imageUsage
must be a subset of the supported usage flags present in thesupportedUsageFlags
member of theSurfaceCapabilitiesKHR
structure returned bygetPhysicalDeviceSurfaceCapabilitiesKHR
forsurface
- If
presentMode
isPRESENT_MODE_SHARED_DEMAND_REFRESH_KHR
orPRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR
,imageUsage
must be a subset of the supported usage flags present in thesharedPresentSupportedUsageFlags
member of theSharedPresentSurfaceCapabilitiesKHR
structure returned bygetPhysicalDeviceSurfaceCapabilities2KHR
forsurface
- If
imageSharingMode
isSHARING_MODE_CONCURRENT
,pQueueFamilyIndices
must be a valid pointer to an array ofqueueFamilyIndexCount
uint32_t
values - If
imageSharingMode
isSHARING_MODE_CONCURRENT
,queueFamilyIndexCount
must be greater than1
- If
imageSharingMode
isSHARING_MODE_CONCURRENT
, each element ofpQueueFamilyIndices
must be unique and must be less thanpQueueFamilyPropertyCount
returned by eithergetPhysicalDeviceQueueFamilyProperties
orgetPhysicalDeviceQueueFamilyProperties2
for thephysicalDevice
that was used to createdevice
-
preTransform
must be one of the bits present in thesupportedTransforms
member of theSurfaceCapabilitiesKHR
structure returned bygetPhysicalDeviceSurfaceCapabilitiesKHR
for the surface -
compositeAlpha
must be one of the bits present in thesupportedCompositeAlpha
member of theSurfaceCapabilitiesKHR
structure returned bygetPhysicalDeviceSurfaceCapabilitiesKHR
for the surface -
presentMode
must be one of thePresentModeKHR
values returned bygetPhysicalDeviceSurfacePresentModesKHR
for the surface - If the
logical device was created with
DeviceGroupDeviceCreateInfo
::physicalDeviceCount
equal to 1,flags
must not containSWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR
- If
oldSwapchain
is notNULL_HANDLE
,oldSwapchain
must be a non-retired swapchain associated with native window referred to bysurface
- The
implied image creation parameters
of the swapchain must be supported as reported by
getPhysicalDeviceImageFormatProperties
- If
flags
containsSWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR
then thepNext
chain must include aImageFormatListCreateInfo
structure with aviewFormatCount
greater than zero andpViewFormats
must have an element equal toimageFormat
- If a
ImageFormatListCreateInfo
structure was included in thepNext
chain andImageFormatListCreateInfo
::viewFormatCount
is not zero then all of the formats inImageFormatListCreateInfo
::pViewFormats
must be compatible with theformat
as described in the compatibility table - If
flags
does not containSWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR
and thepNext
chain include aImageFormatListCreateInfo
structure thenImageFormatListCreateInfo
::viewFormatCount
must be0
or1
- If
flags
containsSWAPCHAIN_CREATE_PROTECTED_BIT_KHR
, thenSurfaceProtectedCapabilitiesKHR
::supportsProtected
must beTRUE
in theSurfaceProtectedCapabilitiesKHR
structure returned bygetPhysicalDeviceSurfaceCapabilities2KHR
forsurface
- If the
pNext
chain includes aSurfaceFullScreenExclusiveInfoEXT
structure with itsfullScreenExclusive
member set toFULL_SCREEN_EXCLUSIVE_APPLICATION_CONTROLLED_EXT
, andsurface
was created usingcreateWin32SurfaceKHR
, aSurfaceFullScreenExclusiveWin32InfoEXT
structure must be included in thepNext
chain
Valid Usage (Implicit)
-
sType
must beSTRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR
- Each
pNext
member of any structure (including this one) in thepNext
chain must be eitherNULL
or a pointer to a valid instance ofDeviceGroupSwapchainCreateInfoKHR
,ImageFormatListCreateInfo
,SurfaceFullScreenExclusiveInfoEXT
,SurfaceFullScreenExclusiveWin32InfoEXT
,SwapchainCounterCreateInfoEXT
, orSwapchainDisplayNativeHdrCreateInfoAMD
- The
sType
value of each struct in thepNext
chain must be unique -
flags
must be a valid combination ofSwapchainCreateFlagBitsKHR
values -
surface
must be a validSurfaceKHR
handle -
imageFormat
must be a validFormat
value -
imageColorSpace
must be a validColorSpaceKHR
value -
imageUsage
must be a valid combination ofImageUsageFlagBits
values -
imageUsage
must not be0
-
imageSharingMode
must be a validSharingMode
value -
preTransform
must be a validSurfaceTransformFlagBitsKHR
value -
compositeAlpha
must be a validCompositeAlphaFlagBitsKHR
value -
presentMode
must be a validPresentModeKHR
value - If
oldSwapchain
is notNULL_HANDLE
,oldSwapchain
must be a validSwapchainKHR
handle - If
oldSwapchain
is a valid handle, it must have been created, allocated, or retrieved fromsurface
- Both of
oldSwapchain
, andsurface
that are valid handles of non-ignored parameters must have been created, allocated, or retrieved from the sameInstance
See Also
VK_KHR_swapchain,
Bool32
,
ColorSpaceKHR
,
CompositeAlphaFlagBitsKHR
,
Extent2D
,
Format
,
ImageUsageFlags
,
PresentModeKHR
,
SharingMode
,
StructureType
,
SurfaceKHR
,
SurfaceTransformFlagBitsKHR
,
SwapchainCreateFlagsKHR
, SwapchainKHR
,
createSharedSwapchainsKHR
,
createSwapchainKHR
SwapchainCreateInfoKHR | |
|
Instances
data PresentInfoKHR (es :: [Type]) Source #
VkPresentInfoKHR - Structure describing parameters of a queue presentation
Description
Before an application can present an image, the image’s layout must
be transitioned to the
IMAGE_LAYOUT_PRESENT_SRC_KHR
layout,
or for a shared presentable image the
IMAGE_LAYOUT_SHARED_PRESENT_KHR
layout.
Note
When transitioning the image to
IMAGE_LAYOUT_SHARED_PRESENT_KHR
or
IMAGE_LAYOUT_PRESENT_SRC_KHR
, there is
no need to delay subsequent processing, or perform any visibility
operations (as queuePresentKHR
performs automatic visibility
operations). To achieve this, the dstAccessMask
member of the
ImageMemoryBarrier
should be set to 0
,
and the dstStageMask
parameter should be set to
PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT
.
Valid Usage
- Each element of
pImageIndices
must be the index of a presentable image acquired from the swapchain specified by the corresponding element of thepSwapchains
array, and the presented image subresource must be in theIMAGE_LAYOUT_PRESENT_SRC_KHR
orIMAGE_LAYOUT_SHARED_PRESENT_KHR
layout at the time the operation is executed on aDevice
- If a
PresentIdKHR
structure is included in thepNext
chain, and the presentId feature is not enabled, eachpresentIds
entry in that structure must be NULL
Valid Usage (Implicit)
-
sType
must beSTRUCTURE_TYPE_PRESENT_INFO_KHR
- Each
pNext
member of any structure (including this one) in thepNext
chain must be eitherNULL
or a pointer to a valid instance ofDeviceGroupPresentInfoKHR
,DisplayPresentInfoKHR
,PresentFrameTokenGGP
,PresentIdKHR
,PresentRegionsKHR
, orPresentTimesInfoGOOGLE
- The
sType
value of each struct in thepNext
chain must be unique - If
waitSemaphoreCount
is not0
,pWaitSemaphores
must be a valid pointer to an array ofwaitSemaphoreCount
validSemaphore
handles -
pSwapchains
must be a valid pointer to an array ofswapchainCount
validSwapchainKHR
handles -
pImageIndices
must be a valid pointer to an array ofswapchainCount
uint32_t
values - If
pResults
is notNULL
,pResults
must be a valid pointer to an array ofswapchainCount
Result
values -
swapchainCount
must be greater than0
- Both of the elements of
pSwapchains
, and the elements ofpWaitSemaphores
that are valid handles of non-ignored parameters must have been created, allocated, or retrieved from the sameInstance
See Also
VK_KHR_swapchain,
Result
, Semaphore
,
StructureType
,
SwapchainKHR
, queuePresentKHR
PresentInfoKHR | |
|
Instances
data DeviceGroupPresentCapabilitiesKHR Source #
VkDeviceGroupPresentCapabilitiesKHR - Present capabilities from other physical devices
Description
modes
always has DEVICE_GROUP_PRESENT_MODE_LOCAL_BIT_KHR
set.
The present mode flags are also used when presenting an image, in
DeviceGroupPresentInfoKHR
::mode
.
If a device group only includes a single physical device, then modes
must equal DEVICE_GROUP_PRESENT_MODE_LOCAL_BIT_KHR
.
Valid Usage (Implicit)
See Also
VK_KHR_device_group,
VK_KHR_surface,
VK_KHR_swapchain,
VK_VERSION_1_1,
DeviceGroupPresentModeFlagsKHR
,
StructureType
,
getDeviceGroupPresentCapabilitiesKHR
DeviceGroupPresentCapabilitiesKHR | |
|
Instances
data ImageSwapchainCreateInfoKHR Source #
VkImageSwapchainCreateInfoKHR - Specify that an image will be bound to swapchain memory
Valid Usage
- If
swapchain
is notNULL_HANDLE
, the fields ofImageCreateInfo
must match the implied image creation parameters of the swapchain
Valid Usage (Implicit)
-
sType
must beSTRUCTURE_TYPE_IMAGE_SWAPCHAIN_CREATE_INFO_KHR
- If
swapchain
is notNULL_HANDLE
,swapchain
must be a validSwapchainKHR
handle
See Also
VK_KHR_device_group,
VK_KHR_swapchain,
VK_VERSION_1_1,
StructureType
,
SwapchainKHR
ImageSwapchainCreateInfoKHR | |
|
Instances
data BindImageMemorySwapchainInfoKHR Source #
VkBindImageMemorySwapchainInfoKHR - Structure specifying swapchain image memory to bind to
Description
If swapchain
is not NULL
, the swapchain
and imageIndex
are used
to determine the memory that the image is bound to, instead of memory
and memoryOffset
.
Memory can be bound to a swapchain and use the pDeviceIndices
or
pSplitInstanceBindRegions
members of
BindImageMemoryDeviceGroupInfo
.
Valid Usage
Valid Usage (Implicit)
-
sType
must beSTRUCTURE_TYPE_BIND_IMAGE_MEMORY_SWAPCHAIN_INFO_KHR
-
swapchain
must be a validSwapchainKHR
handle
Host Synchronization
- Host access to
swapchain
must be externally synchronized
See Also
VK_KHR_device_group,
VK_KHR_swapchain,
VK_VERSION_1_1,
StructureType
,
SwapchainKHR
BindImageMemorySwapchainInfoKHR | |
|
Instances
data AcquireNextImageInfoKHR Source #
VkAcquireNextImageInfoKHR - Structure specifying parameters of the acquire
Description
If acquireNextImageKHR
is used, the device mask is considered to
include all physical devices in the logical device.
Note
acquireNextImage2KHR
signals at most one semaphore, even if the
application requests waiting for multiple physical devices to be ready
via the deviceMask
. However, only a single physical device can wait
on that semaphore, since the semaphore becomes unsignaled when the wait
succeeds. For other physical devices to wait for the image to be ready,
it is necessary for the application to submit semaphore signal
operation(s) to that first physical device to signal additional
semaphore(s) after the wait succeeds, which the other physical device(s)
can wait upon.
Valid Usage
- If
semaphore
is notNULL_HANDLE
it must be unsignaled - If
semaphore
is notNULL_HANDLE
it must not have any uncompleted signal or wait operations pending - If
fence
is notNULL_HANDLE
it must be unsignaled and must not be associated with any other queue command that has not yet completed execution on that queue -
semaphore
andfence
must not both be equal toNULL_HANDLE
-
deviceMask
must be a valid device mask -
deviceMask
must not be zero -
semaphore
must have aSemaphoreType
ofSEMAPHORE_TYPE_BINARY
Valid Usage (Implicit)
-
sType
must beSTRUCTURE_TYPE_ACQUIRE_NEXT_IMAGE_INFO_KHR
-
pNext
must beNULL
-
swapchain
must be a validSwapchainKHR
handle - If
semaphore
is notNULL_HANDLE
,semaphore
must be a validSemaphore
handle - If
fence
is notNULL_HANDLE
,fence
must be a validFence
handle - Each of
fence
,semaphore
, andswapchain
that are valid handles of non-ignored parameters must have been created, allocated, or retrieved from the sameInstance
Host Synchronization
- Host access to
swapchain
must be externally synchronized
- Host access to
semaphore
must be externally synchronized - Host access to
fence
must be externally synchronized
See Also
VK_KHR_device_group,
VK_KHR_swapchain,
VK_VERSION_1_1,
Fence
, Semaphore
,
StructureType
,
SwapchainKHR
, acquireNextImage2KHR
AcquireNextImageInfoKHR | |
|
Instances
data DeviceGroupPresentInfoKHR Source #
VkDeviceGroupPresentInfoKHR - Mode and mask controlling which physical devices' images are presented
Description
If mode
is DEVICE_GROUP_PRESENT_MODE_LOCAL_BIT_KHR
, then each
element of pDeviceMasks
selects which instance of the swapchain image
is presented. Each element of pDeviceMasks
must have exactly one bit
set, and the corresponding physical device must have a presentation
engine as reported by DeviceGroupPresentCapabilitiesKHR
.
If mode
is DEVICE_GROUP_PRESENT_MODE_REMOTE_BIT_KHR
, then each
element of pDeviceMasks
selects which instance of the swapchain image
is presented. Each element of pDeviceMasks
must have exactly one bit
set, and some physical device in the logical device must include that
bit in its DeviceGroupPresentCapabilitiesKHR
::presentMask
.
If mode
is DEVICE_GROUP_PRESENT_MODE_SUM_BIT_KHR
, then each element
of pDeviceMasks
selects which instances of the swapchain image are
component-wise summed and the sum of those images is presented. If the
sum in any component is outside the representable range, the value of
that component is undefined. Each element of pDeviceMasks
must have
a value for which all set bits are set in one of the elements of
DeviceGroupPresentCapabilitiesKHR
::presentMask
.
If mode
is DEVICE_GROUP_PRESENT_MODE_LOCAL_MULTI_DEVICE_BIT_KHR
,
then each element of pDeviceMasks
selects which instance(s) of the
swapchain images are presented. For each bit set in each element of
pDeviceMasks
, the corresponding physical device must have a
presentation engine as reported by DeviceGroupPresentCapabilitiesKHR
.
If DeviceGroupPresentInfoKHR
is not provided or swapchainCount
is
zero then the masks are considered to be 1
. If
DeviceGroupPresentInfoKHR
is not provided, mode
is considered to be
DEVICE_GROUP_PRESENT_MODE_LOCAL_BIT_KHR
.
Valid Usage
-
swapchainCount
must equal0
orPresentInfoKHR
::swapchainCount
- If
mode
isDEVICE_GROUP_PRESENT_MODE_LOCAL_BIT_KHR
, then each element ofpDeviceMasks
must have exactly one bit set, and the corresponding element ofDeviceGroupPresentCapabilitiesKHR
::presentMask
must be non-zero - If
mode
isDEVICE_GROUP_PRESENT_MODE_REMOTE_BIT_KHR
, then each element ofpDeviceMasks
must have exactly one bit set, and some physical device in the logical device must include that bit in itsDeviceGroupPresentCapabilitiesKHR
::presentMask
- If
mode
isDEVICE_GROUP_PRESENT_MODE_SUM_BIT_KHR
, then each element ofpDeviceMasks
must have a value for which all set bits are set in one of the elements ofDeviceGroupPresentCapabilitiesKHR
::presentMask
- If
mode
isDEVICE_GROUP_PRESENT_MODE_LOCAL_MULTI_DEVICE_BIT_KHR
, then for each bit set in each element ofpDeviceMasks
, the corresponding element ofDeviceGroupPresentCapabilitiesKHR
::presentMask
must be non-zero - The value of
each element of
pDeviceMasks
must be equal to the device mask passed inAcquireNextImageInfoKHR
::deviceMask
when the image index was last acquired -
mode
must have exactly one bit set, and that bit must have been included inDeviceGroupSwapchainCreateInfoKHR
::modes
Valid Usage (Implicit)
-
sType
must beSTRUCTURE_TYPE_DEVICE_GROUP_PRESENT_INFO_KHR
- If
swapchainCount
is not0
,pDeviceMasks
must be a valid pointer to an array ofswapchainCount
uint32_t
values -
mode
must be a validDeviceGroupPresentModeFlagBitsKHR
value
See Also
VK_KHR_device_group,
VK_KHR_swapchain,
VK_VERSION_1_1,
DeviceGroupPresentModeFlagBitsKHR
,
StructureType
DeviceGroupPresentInfoKHR | |
|
Instances
Show DeviceGroupPresentInfoKHR Source # | |
Defined in Vulkan.Extensions.VK_KHR_swapchain showsPrec :: Int -> DeviceGroupPresentInfoKHR -> ShowS # show :: DeviceGroupPresentInfoKHR -> String # showList :: [DeviceGroupPresentInfoKHR] -> ShowS # | |
FromCStruct DeviceGroupPresentInfoKHR Source # | |
ToCStruct DeviceGroupPresentInfoKHR Source # | |
Defined in Vulkan.Extensions.VK_KHR_swapchain withCStruct :: DeviceGroupPresentInfoKHR -> (Ptr DeviceGroupPresentInfoKHR -> IO b) -> IO b Source # pokeCStruct :: Ptr DeviceGroupPresentInfoKHR -> DeviceGroupPresentInfoKHR -> IO b -> IO b Source # withZeroCStruct :: (Ptr DeviceGroupPresentInfoKHR -> IO b) -> IO b Source # pokeZeroCStruct :: Ptr DeviceGroupPresentInfoKHR -> IO b -> IO b Source # cStructSize :: Int Source # | |
Zero DeviceGroupPresentInfoKHR Source # | |
Defined in Vulkan.Extensions.VK_KHR_swapchain |
data DeviceGroupSwapchainCreateInfoKHR Source #
VkDeviceGroupSwapchainCreateInfoKHR - Structure specifying parameters of a newly created swapchain object
Description
If this structure is not present, modes
is considered to be
DEVICE_GROUP_PRESENT_MODE_LOCAL_BIT_KHR
.
Valid Usage (Implicit)
See Also
VK_KHR_device_group,
VK_KHR_swapchain,
VK_VERSION_1_1,
DeviceGroupPresentModeFlagsKHR
,
StructureType
DeviceGroupSwapchainCreateInfoKHR | |
|
Instances
newtype DeviceGroupPresentModeFlagBitsKHR Source #
VkDeviceGroupPresentModeFlagBitsKHR - Bitmask specifying supported device group present modes
See Also
VK_KHR_device_group,
VK_KHR_surface,
VK_KHR_swapchain,
VK_VERSION_1_1,
DeviceGroupPresentInfoKHR
, DeviceGroupPresentModeFlagsKHR
pattern DEVICE_GROUP_PRESENT_MODE_LOCAL_BIT_KHR :: DeviceGroupPresentModeFlagBitsKHR |
|
pattern DEVICE_GROUP_PRESENT_MODE_REMOTE_BIT_KHR :: DeviceGroupPresentModeFlagBitsKHR |
|
pattern DEVICE_GROUP_PRESENT_MODE_SUM_BIT_KHR :: DeviceGroupPresentModeFlagBitsKHR |
|
pattern DEVICE_GROUP_PRESENT_MODE_LOCAL_MULTI_DEVICE_BIT_KHR :: DeviceGroupPresentModeFlagBitsKHR |
|
Instances
newtype SwapchainCreateFlagBitsKHR Source #
VkSwapchainCreateFlagBitsKHR - Bitmask controlling swapchain creation
See Also
pattern SWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR :: SwapchainCreateFlagBitsKHR |
|
pattern SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR :: SwapchainCreateFlagBitsKHR |
|
pattern SWAPCHAIN_CREATE_PROTECTED_BIT_KHR :: SwapchainCreateFlagBitsKHR |
|
Instances
type KHR_SWAPCHAIN_SPEC_VERSION = 70 Source #
pattern KHR_SWAPCHAIN_SPEC_VERSION :: forall a. Integral a => a Source #
type KHR_SWAPCHAIN_EXTENSION_NAME = "VK_KHR_swapchain" Source #
pattern KHR_SWAPCHAIN_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a Source #
newtype SurfaceKHR Source #
VkSurfaceKHR - Opaque handle to a surface object
Description
The VK_KHR_surface
extension declares the SurfaceKHR
object, and
provides a function for destroying SurfaceKHR
objects. Separate
platform-specific extensions each provide a function for creating a
SurfaceKHR
object for the respective platform. From the application’s
perspective this is an opaque handle, just like the handles of other
Vulkan objects.
See Also
VK_KHR_surface,
PhysicalDeviceSurfaceInfo2KHR
,
SwapchainCreateInfoKHR
,
createAndroidSurfaceKHR
,
createDirectFBSurfaceEXT
,
createDisplayPlaneSurfaceKHR
,
createHeadlessSurfaceEXT
,
createIOSSurfaceMVK
,
createImagePipeSurfaceFUCHSIA
,
createMacOSSurfaceMVK
,
createMetalSurfaceEXT
,
createScreenSurfaceQNX
,
createStreamDescriptorSurfaceGGP
,
createViSurfaceNN
,
createWaylandSurfaceKHR
,
createWin32SurfaceKHR
,
createXcbSurfaceKHR
,
createXlibSurfaceKHR
,
destroySurfaceKHR
,
getDeviceGroupSurfacePresentModesKHR
,
getPhysicalDevicePresentRectanglesKHR
,
getPhysicalDeviceSurfaceCapabilities2EXT
,
getPhysicalDeviceSurfaceCapabilitiesKHR
,
getPhysicalDeviceSurfaceFormatsKHR
,
getPhysicalDeviceSurfacePresentModesKHR
,
getPhysicalDeviceSurfaceSupportKHR
Instances
newtype SwapchainKHR Source #
VkSwapchainKHR - Opaque handle to a swapchain object
Description
A swapchain is an abstraction for an array of presentable images that
are associated with a surface. The presentable images are represented by
Image
objects created by the platform. One image
(which can be an array image for multiview/stereoscopic-3D surfaces)
is displayed at a time, but multiple images can be queued for
presentation. An application renders to the image, and then queues the
image for presentation to the surface.
A native window cannot be associated with more than one non-retired swapchain at a time. Further, swapchains cannot be created for native windows that have a non-Vulkan graphics API surface associated with them.
Note
The presentation engine is an abstraction for the platform’s compositor or display engine.
The presentation engine may be synchronous or asynchronous with respect to the application and/or logical device.
Some implementations may use the device’s graphics queue or dedicated presentation hardware to perform presentation.
The presentable images of a swapchain are owned by the presentation
engine. An application can acquire use of a presentable image from the
presentation engine. Use of a presentable image must occur only after
the image is returned by
acquireNextImageKHR
, and before it
is released by queuePresentKHR
.
This includes transitioning the image layout and rendering commands.
An application can acquire use of a presentable image with
acquireNextImageKHR
. After
acquiring a presentable image and before modifying it, the application
must use a synchronization primitive to ensure that the presentation
engine has finished reading from the image. The application can then
transition the image’s layout, queue rendering commands to it, etc.
Finally, the application presents the image with
queuePresentKHR
, which releases the
acquisition of the image.
The presentation engine controls the order in which presentable images are acquired for use by the application.
Note
This allows the platform to handle situations which require out-of-order return of images after presentation. At the same time, it allows the application to generate command buffers referencing all of the images in the swapchain at initialization time, rather than in its main loop.
See Also
VK_KHR_swapchain,
AcquireNextImageInfoKHR
,
BindImageMemorySwapchainInfoKHR
,
ImageSwapchainCreateInfoKHR
,
PresentInfoKHR
,
SwapchainCreateInfoKHR
,
acquireFullScreenExclusiveModeEXT
,
acquireNextImageKHR
,
createSharedSwapchainsKHR
,
createSwapchainKHR
,
destroySwapchainKHR
,
getPastPresentationTimingGOOGLE
,
getRefreshCycleDurationGOOGLE
,
getSwapchainCounterEXT
,
getSwapchainImagesKHR
,
getSwapchainStatusKHR
,
queuePresentKHR
,
releaseFullScreenExclusiveModeEXT
,
setHdrMetadataEXT
,
setLocalDimmingAMD
,
waitForPresentKHR
Instances
newtype PresentModeKHR Source #
VkPresentModeKHR - Presentation mode supported for a surface
Description
The supported
ImageUsageFlagBits
of the
presentable images of a swapchain created for a surface may differ
depending on the presentation mode, and can be determined as per the
table below:
Presentation mode | Image usage flags |
---|---|
PRESENT_MODE_IMMEDIATE_KHR | SurfaceCapabilitiesKHR ::supportedUsageFlags |
PRESENT_MODE_MAILBOX_KHR | SurfaceCapabilitiesKHR ::supportedUsageFlags |
PRESENT_MODE_FIFO_KHR | SurfaceCapabilitiesKHR ::supportedUsageFlags |
PRESENT_MODE_FIFO_RELAXED_KHR | SurfaceCapabilitiesKHR ::supportedUsageFlags |
PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR | SharedPresentSurfaceCapabilitiesKHR ::sharedPresentSupportedUsageFlags |
PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR | SharedPresentSurfaceCapabilitiesKHR ::sharedPresentSupportedUsageFlags |
Presentable image usage queries
Note
For reference, the mode indicated by PRESENT_MODE_FIFO_KHR
is
equivalent to the behavior of {wgl|glX|egl}SwapBuffers with a swap
interval of 1, while the mode indicated by
PRESENT_MODE_FIFO_RELAXED_KHR
is equivalent to the behavior of
{wgl|glX}SwapBuffers with a swap interval of -1 (from the
{WGL|GLX}_EXT_swap_control_tear extensions).
See Also
VK_KHR_surface,
SwapchainCreateInfoKHR
,
getPhysicalDeviceSurfacePresentModes2EXT
,
getPhysicalDeviceSurfacePresentModesKHR
pattern PRESENT_MODE_IMMEDIATE_KHR :: PresentModeKHR |
|
pattern PRESENT_MODE_MAILBOX_KHR :: PresentModeKHR |
|
pattern PRESENT_MODE_FIFO_KHR :: PresentModeKHR |
|
pattern PRESENT_MODE_FIFO_RELAXED_KHR :: PresentModeKHR |
|
pattern PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR :: PresentModeKHR |
|
pattern PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR :: PresentModeKHR |
|
Instances
newtype ColorSpaceKHR Source #
VkColorSpaceKHR - Supported color space of the presentation engine
Description
Note
In the initial release of the VK_KHR_surface
and VK_KHR_swapchain
extensions, the token COLORSPACE_SRGB_NONLINEAR_KHR
was used. Starting
in the 2016-05-13 updates to the extension branches, matching release
1.0.13 of the core API specification, COLOR_SPACE_SRGB_NONLINEAR_KHR
is used instead for consistency with Vulkan naming rules. The older enum
is still available for backwards compatibility.
Note
In older versions of this extension COLOR_SPACE_DISPLAY_P3_LINEAR_EXT
was misnamed
COLOR_SPACE_DCI_P3_LINEAR_EXT
.
This has been updated to indicate that it uses RGB color encoding, not
XYZ. The old name is deprecated but is maintained for backwards
compatibility.
The color components of non-linear color space swap chain images must
have had the appropriate transfer function applied. The color space
selected for the swap chain image will not affect the processing of data
written into the image by the implementation. Vulkan requires that all
implementations support the sRGB transfer function by use of an SRGB
pixel format. Other transfer functions, such as SMPTE 170M or SMPTE2084,
can be performed by the application shader. This extension defines
enums for ColorSpaceKHR
that correspond to the following color spaces:
Name | Red Primary | Green Primary | Blue Primary | White-point | Transfer function |
---|---|---|---|---|---|
DCI-P3 | 1.000, 0.000 | 0.000, 1.000 | 0.000, 0.000 | 0.3333, 0.3333 | DCI P3 |
Display-P3 | 0.680, 0.320 | 0.265, 0.690 | 0.150, 0.060 | 0.3127, 0.3290 (D65) | Display-P3 |
BT709 | 0.640, 0.330 | 0.300, 0.600 | 0.150, 0.060 | 0.3127, 0.3290 (D65) | ITU (SMPTE 170M) |
sRGB | 0.640, 0.330 | 0.300, 0.600 | 0.150, 0.060 | 0.3127, 0.3290 (D65) | sRGB |
extended sRGB | 0.640, 0.330 | 0.300, 0.600 | 0.150, 0.060 | 0.3127, 0.3290 (D65) | extended sRGB |
HDR10_ST2084 | 0.708, 0.292 | 0.170, 0.797 | 0.131, 0.046 | 0.3127, 0.3290 (D65) | ST2084 PQ |
DOLBYVISION | 0.708, 0.292 | 0.170, 0.797 | 0.131, 0.046 | 0.3127, 0.3290 (D65) | ST2084 PQ |
HDR10_HLG | 0.708, 0.292 | 0.170, 0.797 | 0.131, 0.046 | 0.3127, 0.3290 (D65) | HLG |
AdobeRGB | 0.640, 0.330 | 0.210, 0.710 | 0.150, 0.060 | 0.3127, 0.3290 (D65) | AdobeRGB |
Color Spaces and Attributes
The transfer functions are described in the “Transfer Functions” chapter of the Khronos Data Format Specification.
Except Display-P3 OETF, which is:
[begin{aligned} E & = begin{cases} 1.055 times L^{1 over 2.4} - 0.055 & text{for} 0.0030186 leq L leq 1 -- 12.92 times L & text{for} 0 leq L < 0.0030186
pattern COLOR_SPACE_DISPLAY_P3_LINEAR_EXT :: ColorSpaceKHR |
|
pattern COLOR_SPACE_SRGB_NONLINEAR_KHR :: ColorSpaceKHR |
|
pattern COLOR_SPACE_DISPLAY_NATIVE_AMD :: ColorSpaceKHR |
|
pattern COLOR_SPACE_EXTENDED_SRGB_NONLINEAR_EXT :: ColorSpaceKHR |
|
pattern COLOR_SPACE_PASS_THROUGH_EXT :: ColorSpaceKHR |
|
pattern COLOR_SPACE_ADOBERGB_NONLINEAR_EXT :: ColorSpaceKHR |
|
pattern COLOR_SPACE_ADOBERGB_LINEAR_EXT :: ColorSpaceKHR |
|
pattern COLOR_SPACE_HDR10_HLG_EXT :: ColorSpaceKHR |
|
pattern COLOR_SPACE_DOLBYVISION_EXT :: ColorSpaceKHR |
|
pattern COLOR_SPACE_HDR10_ST2084_EXT :: ColorSpaceKHR |
|
pattern COLOR_SPACE_BT2020_LINEAR_EXT :: ColorSpaceKHR |
|
pattern COLOR_SPACE_BT709_NONLINEAR_EXT :: ColorSpaceKHR |
|
pattern COLOR_SPACE_BT709_LINEAR_EXT :: ColorSpaceKHR |
|
pattern COLOR_SPACE_DCI_P3_NONLINEAR_EXT :: ColorSpaceKHR |
|
pattern COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT :: ColorSpaceKHR |
|
pattern COLOR_SPACE_DISPLAY_P3_NONLINEAR_EXT :: ColorSpaceKHR |
|
Instances
newtype CompositeAlphaFlagBitsKHR Source #
VkCompositeAlphaFlagBitsKHR - Alpha compositing modes supported on a device
Description
These values are described as follows:
See Also
VK_KHR_surface,
CompositeAlphaFlagsKHR
,
SwapchainCreateInfoKHR
pattern COMPOSITE_ALPHA_OPAQUE_BIT_KHR :: CompositeAlphaFlagBitsKHR |
|
pattern COMPOSITE_ALPHA_PRE_MULTIPLIED_BIT_KHR :: CompositeAlphaFlagBitsKHR |
|
pattern COMPOSITE_ALPHA_POST_MULTIPLIED_BIT_KHR :: CompositeAlphaFlagBitsKHR |
|
pattern COMPOSITE_ALPHA_INHERIT_BIT_KHR :: CompositeAlphaFlagBitsKHR |
|
Instances
newtype SurfaceTransformFlagBitsKHR Source #
VkSurfaceTransformFlagBitsKHR - Presentation transforms supported on a device
See Also
VK_KHR_surface,
CommandBufferInheritanceRenderPassTransformInfoQCOM
,
CopyCommandTransformInfoQCOM
,
DisplaySurfaceCreateInfoKHR
,
RenderPassTransformBeginInfoQCOM
,
SurfaceCapabilities2EXT
,
SurfaceCapabilitiesKHR
, SurfaceTransformFlagsKHR
,
SwapchainCreateInfoKHR