Vulkan-Docs/doc/specs/vulkan/appendices/VK_KHR_display_swapchain.txt
Jon Leech b9e9296cd8 Change log for June 24, 2017 Vulkan 1.0.53 spec update:
* Bump API patch number and header version number to 53 for this update.

Github Issues:

Internal Issues:

  * Clarify mappings of coordinates for mutable, compatible image views in
    slink:VkImageViewCreateInfo (internal issue 815).
  * Make ename:VK_BIND_SFR_BIT require a logical device with multiple
    physical devices, so that standard sparse image block dimensions are
    only required on systems that support multi-GPU (internal issue 835).
  * Convert all files from use of // refBegin .. // refEnd comments to
    delimit ref pages, to use of open blocks, and update style guide
    accordingly (internal issue 839).
  * Add valid usage for slink:VkWriteDescriptorSet when performing updates
    to a ename:VK_STORAGE_IMAGE descriptor with layout
    ename:VK_IMAGE_LAYOUT_GENERAL.
  * Add a hack to the validity generator script to support an odd
    interaction between flink:vkCmdFillBuffer and an extension (internal
    issue 853).
  * Remove redundant text describing slink:VkBufferCreateInfo::pname:usage,
    which was already covered by implicit valid usage (internal issue 854).
  * Update implicit validity generator script to properly handle the
    pname:sType and pname:pNext members of "returnedonly" structures
    (internal issue 874).
  * Note that slink:VkApplicationInfo::pname:pApplicationName &
    slink:VkApplicationInfo::pname:pEngineName are optional, and add missing
    implicit valid usage statements for flink:vkDestroyInstance.
  * Added missing valid usage for flink:vkCmdWriteTimestamp to require a
    timestamp query pool.
  * Simplify and/or split "`non-atomic`" valid usage statements.

New Extensions:

  * `VK_AMD_gpu_shader_int16`
  * `VK_EXT_blend_operation_advanced`
  * `VK_EXT_sampler_filter_minmax`
  * `VK_NV_framebuffer_mixed_samples`

-----------------------------------------------------
Note: the 1.0.52 spec wasn't published on github, so the 1.0.53 release
combines both change sets.
-----------------------------------------------------

Change log for June 13, 2017 Vulkan 1.0.52 spec update:

  * Bump API patch number and header version number to 52 for this update.

Github Issues:

Internal Issues:

  * Clarify behavior when non-coherent memory has
    <<memory-device-unmap-does-not-flush, not been flushed before being
    unmapped>> (internal issue 819).
  * Fix description of code:WorkgroupSize builtin to note it decorates an
    object, not a variable (internal issue 836).
  * Fix asciidoc attributes so that trailing '{plus}' symbols in [eq] style
    equations are rendered properly (internal issue 845).
  * Add language to the "`Extension Handles, Objects, Enums, and Typedefs`"
    section of the Procedures and Conventions document stating that any new
    handle type requires a corresponding entry in the elink:VkObjectType
    enumerated type (internal issue 856).
  * Update style guide to use slink macro for Vulkan handle type names, and
    define narrow conditions under which to use the *name and *text macros
    instead of *link (internal issue 886).
  * Add a dependency of the <<VK_KHX_device_group,VK_KHX_device_group>>
    extension on VK_KHX_device_group_creation to +vk.xml+ and the extension
    appendix.
  * Change the copyright on Vulkan specification asciidoc *source* files to
    CC-BY 4.0, and update the proprietary Khronos copyright applied to the
    generated *output* formats (internal issue 327). This enables broader
    re-use and modification of the Vulkan specification sources, while not
    affecting the Reciprocal IP License between Vulkan Adopters and Working
    Group Members.

New Extensions:

  * `VK_NV_fill_rectangle`
  * `VK_NV_fragment_coverage_to_color`
2017-06-26 19:32:10 -07:00

161 lines
5.3 KiB
Plaintext

// Copyright (c) 2014-2017 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
[[VK_KHR_display_swapchain]]
== VK_KHR_display_swapchain
*Name String*::
+VK_KHR_display_swapchain+
*Extension Type*::
Device extension
*Registered Extension Number*::
4
*Status*::
Draft.
*Last Modified Date*::
2017-03-13
*Revision*::
10
*IP Status*::
No known IP claims.
*Dependencies*::
- This extension is written against version 1.0 of the Vulkan API.
- Requires +VK_KHR_swapchain+.
- Requires +VK_KHR_display+.
*Contributors*::
- James Jones, NVIDIA
- Jeff Vigil, Qualcomm
- Jesse Hall, Google
*Contacts*::
- James Jones (jajones 'at' nvidia.com)
This extension provides an API to create a swapchain directly on a device's
display without any underlying window system.
=== New Object Types
None
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_DISPLAY_PRESENT_INFO_KHR
* Extending elink:VkResult:
** ename:VK_ERROR_INCOMPATIBLE_DISPLAY_KHR
=== New Enums
None
=== New Structures
* slink:VkDisplayPresentInfoKHR
=== New Functions
* flink:vkCreateSharedSwapchainsKHR
=== Issues
1) Should swapchains sharing images each hold a reference to the images, or
should it be up to the application to destroy the swapchains and images in
an order that avoids the need for reference counting?
*RESOLVED*: Take a reference.
The lifetime of presentable images is already complex enough.
2) Should the srcRect/dstRect parameters be specified as part of the present
command, or at swapchain creation time?
*RESOLVED*: As part of the presentation command.
This allows moving and scaling the image on the screen without the need to
respecify the mode or create a new swapchain and presentable images.
3) Should srcRect/dstRect be specified as rects, or separate offset/extent
values?
*RESOLVED*: As rects.
Specifying them separately might make it easier for hardware to expose
support for one but not the other, but in such cases applications must just
take care to obey the reported capabilities and not use non-zero offsets or
extents that require scaling, as appropriate.
4) How can applications create multiple swapchains that use the same images?
*RESOLVED*: By calling flink:vkCreateSharedSwapchainsKHR.
An earlier resolution used flink:vkCreateSwapchainKHR, chaining multiple
slink:VkSwapchainCreateInfoKHR structures through pname:pNext.
In order to allow each swapchain to also allow other extension structs, a
level of indirection was used: slink:VkSwapchainCreateInfoKHR::pname:pNext
pointed to a different structure, which had both an pname:sType/pname:pNext
for additional extensions, and also had a pointer to the next
slink: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 slink:VkSwapchainKHR handles.
Another option considered was a method to specify a "`shared`" swapchain
when creating a new swapchain, such that groups of swapchains using the same
images could be built up one at a time.
This was deemed unusable because drivers need to know all of the displays an
image will be used on when determining which internal formats and layouts to
use for that image.
=== Examples
[NOTE]
.Note
====
The example code for the +VK_KHR_display+ and +VK_KHR_display_swapchain+
extensions was removed from the appendix after revision 1.0.43.
The display swapchain creation example code was ported to the cube demo that
is shipped with the official Khronos SDK, and is being kept up-to-date in
that location (see:
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/demos/cube.c).
====
=== Version History
* Revision 1, 2015-07-29 (James Jones)
- Initial draft
* Revision 2, 2015-08-21 (Ian Elliott)
- Renamed this extension and all of its enumerations, types, functions,
etc.
This makes it compliant with the proposed standard for Vulkan
extensions.
- Switched from "revision" to "version", including use of the
VK_MAKE_VERSION macro in the header file.
* Revision 3, 2015-09-01 (James Jones)
- Restore single-field revision number.
* Revision 4, 2015-09-08 (James Jones)
- Allow creating multiple swap chains that share the same images using a
single call to vkCreateSwapChainKHR().
* Revision 5, 2015-09-10 (Alon Or-bach)
- Removed underscores from SWAP_CHAIN in two enums.
* Revision 6, 2015-10-02 (James Jones)
- Added support for smart panels/buffered displays.
* Revision 7, 2015-10-26 (Ian Elliott)
- Renamed from VK_EXT_KHR_display_swapchain to VK_KHR_display_swapchain.
* Revision 8, 2015-11-03 (Daniel Rakos)
- Updated sample code based on the changes to VK_KHR_swapchain.
* Revision 9, 2015-11-10 (Jesse Hall)
- Replaced ftext:VkDisplaySwapchainCreateInfoKHR with
vkCreateSharedSwapchainsKHR, changing resolution of issue #4.
* Revision 10, 2017-03-13 (James Jones)
- Closed all remaining issues.
The specification and implementations have been shipping with the
proposed resolutions for some time now.
- Removed the sample code and noted it has been integrated into the
official Vulkan SDK cube demo.