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
Change log for June 4, 2017 Vulkan 1.0.51 spec update: * Bump API patch number and header version number to 51 for this update. Github Issues: * Add Valid Usage statement to flink:vkCmdResolveImage to require that source and destination image formats match (public issue 492). * Specify that a code:char* parameter must: be a valid null-terminated string in the <<fundamentals-implicit-validity, implicit valid usage>> section (public issue 494). * Removed unnecessary VU for slink:VkPhysicalDeviceFeatures which is covered by ename:VK_ERROR_FEATURE_NOT_PRESENT already (public issue 496). * Clarify valid usage of pname:pQueueFamilyIndices in slink:VkBufferCreateInfo, slink:VkImageCreateInfo, and slink:VkSwapchainCreateInfoKHR (public issue 501). * Document that dependencies of enabled extensions must also be enabled in the <<extended-functionality-extensions-dependencies, Extension Dependencies>> section (public issue 507). Internal Issues: * Change slink:VkMappedMemoryRange valid usage to allow pname:offset + pname:size == size of the allocation. Also, if ename:VK_WHOLE_SIZE is used, require the end of the mapping to be aligned to a multiple of pname:nonCoherentAtomSize (internal issue 611). * Add issue to `VK_KHR_win32_surface` about reusing window objects from a different graphics API or Vulkan ICD (internal issue 639). * Require locations on user in/out in `GL_KHR_vulkan_glsl` (internal issue 783). * Added version info to the json validation output, and updated the schema to match (internal issue 838). * Restructure enumerated type descriptions separately from the command or structure they are used in, allowing better reference page generation (internal issue 841). * Re-sort extension appendices to be in alphabetical order within each author ID section. * Fix enum naming and clarify behavior for `VK_NVX_device_generated_commands` extension. New Extensions:
2017-06-05 03:48:43 +00:00
* Extending elink:VkStructureType:
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
** 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