Vulkan-Docs/appendices/VK_KHR_incremental_present.txt
Jon Leech f1a7c4b4f3 Change log for January 13, 2019 Vulkan 1.1.98 spec update:
* Update release number to 98.

Public Issues:

  * Fix missing markup in flink:vkDestroyPipelineLayout valid usage
    statement (pull request 882).
  * Add missing contributors for `<<VK_EXT_buffer_device_address>>` (public
    pull request 891).

Internal Issues:

  * Detect nested bullet points in valid usage blocks and warn about them
    during VUID assignment (internal issue 1382).
  * Update the style guide to document the process for reserving new bits in
    bitmask types (internal issue 1411).
  * Clarify for slink:VkApplicationInfo::pname:apiVersion and in the
    <<fundamentals-validusage-versions, Valid Usage for Newer Core
    Versions>> section when it is valid for an application to use a certain
    version of Vulkan API functionality (for an instance and for a
    device/physical device); and when the validation layers must generate an
    error (internal issue 1412).
  * Add optional <<memory-model-availability-visibility, transitive
    availability/visibility operations to the memory model, including a new
    pname:vulkanMemoryModelAvailabilityVisibilityChains feature for
    slink:VkPhysicalDeviceVulkanMemoryModelFeaturesKHR (internal issue
    1460).
  * Add the code:StorageBuffer storage class to those in the
    <<interfaces-resources-descset, Descriptor Set Interface>> (internal
    issue 1480).
  * Add missing `returnedonly` tags for a number of returned extension
    structures that can be passed in pname:pNext chains (internal issue
    1515).
  * Clean up and rearrange some spec language for
    slink:VkRenderPassCreateInfo and slink:VkAttachmentReference.txt
    (internal issue 1522).
  * Correctly round the code:OpVectorTimesScalar and
    code:OpMatrixTimesScalar SPIR-V operations in the <<Precision of core
    SPIR-V Instructions>> table (internal merge request 2996).
  * Work around cases in flink:vkCmdBeginTransformFeedbackEXT,
    flink:vkCmdEndTransformFeedbackEXT, and
    slink:VkPipelineCoverageModulationStateCreateInfoNV where an array
    parameter is `optional` but the length is not in `vk.xml`. This is an
    interim fix using `noautovalidity` + handcoded VU replacing those that
    should be autogenerated (internal issue 2944 and
    https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/480).
  * Remove redundant capability validation of the code:float16 and code:int8
    SPIR-V capabilities from the <<spirvenv-capabilities, Capabilities>>
    section, since they are already covered in the preceding table.
  * Update check_spec_links script, including validation for reference page
    open blocks. Fix errors identified by the script.
2019-01-13 05:53:27 -08:00

104 lines
3.0 KiB
Plaintext

// Copyright (c) 2014-2019 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
include::meta/VK_KHR_incremental_present.txt[]
*Last Modified Date*::
2016-11-02
*IP Status*::
No known IP claims.
*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
This device extension extends flink: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, ptext:pRectangles and
ptext:pLayers, where ptext:pRectangles[i] and ptext: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