mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-19 17:48:23 +00:00
* 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.
104 lines
3.0 KiB
Plaintext
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
|