Vulkan-Docs/doc/specs/vulkan/appendices/VK_KHR_incremental_present.txt

116 lines
3.2 KiB
Plaintext
Raw Normal View History

Change log for March 31, 2017 Vulkan 1.0.46 spec update: * Bump API patch number and header version number to 46 for this update. Github Issues: * Add language to the <<fundamentals-validusage-enums, Valid Usage for Enumerated Types>> section allowing values to be returned from Vulkan that are not present in extensions explicitly enabled by the application, similar to existing language for bit flags in the <<fundamentals-validusage-flags, Valid Usage for Flags>> section (public issue 442). * *Important*: run `gem update --pre asciidoctor-pdf` before trying to build this version of the spec - 1.5.0.alpha15 is required for this change. Removes the monkey patch currently used to draw valid usage blocks across multiple pages which had numerous issues. A fixed version was incorporated into Asciidoctor-PDF for the latest release, so the monkey patch or any variant thereof is no longer required (public issue 465). Internal Issues: * Add ename:VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR_EXT to `VK_EXT_debug_report` extension * Fix ptext:pNext member of slink:VkPhysicalDeviceDiscardRectanglePropertiesEXT to be a non-const pointer. Properties structures return values, so the chain should be non-const. * Explicitly remove gl_NumSamples from the `GL_KHR_vulkan_glsl` extension, against 1.0 (internal issue 612). * Add Valid Usage statements requiring that each structure type valid in a ptext:pNext chain must: not appear more than once in a chain (internal issue 752). * Use ename:VK_USE_PLATFORM_WIN32_KHX in the `VK_KHX_external_memory_win32` extension, rather than etext:_KHR (internal issue 754). New Extensions: * `VK_KHR_incremental_present`
2017-03-31 23:06:31 +00:00
// Copyright (c) 2014-2017 The Khronos Group Inc.
// Copyright notice at https://www.khronos.org/registry/speccopyright.html
[[VK_KHR_incremental_present]]
== VK_KHR_incremental_present
*Name String*::
+VK_KHR_incremental_present+
*Extension Type*::
Device extension
*Registered Extension Number*::
85
*Last Modified Date*::
2016-11-02
*Revision*::
1
*IP Status*::
No known IP claims.
*Dependencies*::
- This extension is written against version 1.0 of the Vulkan API.
- Requires +VK_KHR_swapchain+ (revision 68).
*Contributors*::
- Ian Elliott, Google
- Jesse Hall, Google
- Alon Or-bach, Samsung
- James Jones, NVIDIA
- Daniel Rakos, AMD
- Ray Smith, ARM
- Mika Isojarvi, Google
- Jeff Juliano, NVIDIA
- Jeff Bolz, NVIDIA
*Contacts*::
- Ian Elliott, Google
This device extension extends slink:vkQueuePresentKHR, from the
+VK_KHR_swapchain+ extension, allowing an application to specify a list of
rectangular, modified regions of each image to present.
This should be used in situations where an application is only changing a
small portion of the presentable images within a swapchain, since it enables
the presentation engine to avoid wasting time presenting parts of the
surface that haven't changed.
This extension is leveraged from the +EGL_KHR_swap_buffers_with_damage+
extension.
=== New Object Types
None.
=== New Enum Constants
* Extending ename:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PRESENT_REGIONS_KHR
=== New Enums
None.
=== New Structures
* slink:VkRectLayerKHR
* slink:VkPresentRegionKHR
* slink:VkPresentRegionsKHR
=== New Functions
None.
=== Examples
None.
=== Issues
1) How should we handle steroescopic-3D swapchains? We need to add a layer
for each rectangle.
One approach is to create another struct that contains the slink:VkRect2D
plus layer, and have slink:VkPresentRegionsKHR point to an array of that
struct.
Another approach is to have two parallel arrays, pRectangles and pLayers,
where pRectangles[i] and pLayers[i] must be used together.
Which approach should we use, and if the array of a new structure, what
should that be called?
*RESOLVED*: Create a new structure, which is a slink:VkRect2D plus a layer,
and will be called slink:VkRectLayerKHR.
2) Where is the origin of the slink:VkRectLayerKHR?
*RESOLVED*: The upper left corner of the presentable image(s) of the
swapchain, per the definition of framebuffer coordinates.
3) Does the rectangular region, slink:VkRectLayerKHR, specify pixels of the
swapchain's image(s), or of the surface?
*RESOLVED*: Of the image(s).
Some presentation engines may scale the pixels of a swapchain's image(s) to
the size of the surface.
The size of the swapchain's image(s) will be consistent, where the size of
the surface may vary over time.
4) What if all of the rectangles for a given swapchain contain a width
and/or height of zero?
*RESOLVED*: The application is indicating that no pixels changed since the
last present.
The presentation engine may use such a hint and not update any pixels for
the swapchain.
However, all other semantics of flink:vkQueuePresentKHR must still be
honored, including waiting for semaphores to signal.
=== Version History
* Revision 1, 2016-11-02 (Ian Elliott)
- Internal revisions