Vulkan-Docs/doc/specs/vulkan/appendices/VK_KHR_incremental_present.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

117 lines
3.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_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 elink: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