Name
VK_KHR_incremental_present - device extension
VK_KHR_incremental_present
- Name String
VK_KHR_incremental_present
- Extension Type
Device extension
- Registered Extension Number
85
- Revision
2
- Ratification Status
Ratified
- Extension and Version Dependencies
VK_KHR_swapchain
- Contact
Other Extension Metadata
- 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
Description
This device extension extends
queuePresentKHR, 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 have not changed.
This extension is leveraged from the EGL_KHR_swap_buffers_with_damage
extension.
New Structures
New Enum Constants
Issues
1) How should we handle steroescopic-3D swapchains? We need to add a
layer for each rectangle. One approach is to create another structure
containing the Rect2D plus layer, and
have PresentRegionsKHR 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
Rect2D plus a layer, and will be called
RectLayerKHR.
2) Where is the origin of the RectLayerKHR?
RESOLVED: The upper left corner of the presentable image(s) of the
swapchain, per the definition of framebuffer coordinates.
3) Does the rectangular region, RectLayerKHR, 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
queuePresentKHR must still be
honored, including waiting for semaphores to signal.
5) When the swapchain is created with
SwapchainCreateInfoKHR::preTransform
set to a value other than
SURFACE_TRANSFORM_IDENTITY_BIT_KHR,
should the rectangular region, RectLayerKHR, be transformed to align
with the preTransform?
RESOLVED: No. The rectangular region in RectLayerKHR should not be
transformed. As such, it may not align with the extents of the
swapchain’s image(s). It is the responsibility of the presentation
engine to transform the rectangular region. This matches the behavior of
the Android presentation engine, which set the precedent.
Version History
See Also
No cross-references are available
Document Notes
For more information, see the
Vulkan Specification.
This page is a generated document. Fixes and changes should be made to
the generator scripts, not directly.