• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1// Copyright 2014-2021 The Khronos Group, Inc.
2//
3// SPDX-License-Identifier: CC-BY-4.0
4
5include::{generated}/meta/{refprefix}VK_KHR_incremental_present.txt[]
6
7=== Other Extension Metadata
8
9*Last Modified Date*::
10    2016-11-02
11*IP Status*::
12    No known IP claims.
13*Contributors*::
14  - Ian Elliott, Google
15  - Jesse Hall, Google
16  - Alon Or-bach, Samsung
17  - James Jones, NVIDIA
18  - Daniel Rakos, AMD
19  - Ray Smith, ARM
20  - Mika Isojarvi, Google
21  - Jeff Juliano, NVIDIA
22  - Jeff Bolz, NVIDIA
23
24=== Description
25
26This device extension extends flink:vkQueuePresentKHR, from the
27`apiext:VK_KHR_swapchain` extension, allowing an application to specify a
28list of rectangular, modified regions of each image to present.
29This should be used in situations where an application is only changing a
30small portion of the presentable images within a swapchain, since it enables
31the presentation engine to avoid wasting time presenting parts of the
32surface that have not changed.
33
34This extension is leveraged from the `EGL_KHR_swap_buffers_with_damage`
35extension.
36
37include::{generated}/interfaces/VK_KHR_incremental_present.txt[]
38
39=== Issues
40
411) How should we handle steroescopic-3D swapchains? We need to add a layer
42for each rectangle.
43One approach is to create another struct containing the slink:VkRect2D plus
44layer, and have slink:VkPresentRegionsKHR point to an array of that struct.
45Another approach is to have two parallel arrays, ptext:pRectangles and
46ptext:pLayers, where ptext:pRectangles[i] and ptext:pLayers[i] must be used
47together.
48Which approach should we use, and if the array of a new structure, what
49should that be called?
50
51*RESOLVED*: Create a new structure, which is a slink:VkRect2D plus a layer,
52and will be called slink:VkRectLayerKHR.
53
542) Where is the origin of the slink:VkRectLayerKHR?
55
56*RESOLVED*: The upper left corner of the presentable image(s) of the
57swapchain, per the definition of framebuffer coordinates.
58
593) Does the rectangular region, slink:VkRectLayerKHR, specify pixels of the
60swapchain's image(s), or of the surface?
61
62*RESOLVED*: Of the image(s).
63Some presentation engines may scale the pixels of a swapchain's image(s) to
64the size of the surface.
65The size of the swapchain's image(s) will be consistent, where the size of
66the surface may vary over time.
67
684) What if all of the rectangles for a given swapchain contain a width
69and/or height of zero?
70
71*RESOLVED*: The application is indicating that no pixels changed since the
72last present.
73The presentation engine may use such a hint and not update any pixels for
74the swapchain.
75However, all other semantics of flink:vkQueuePresentKHR must still be
76honored, including waiting for semaphores to signal.
77
785) When the swapchain is created with
79sname:VkSwapchainCreateInfoKHR::pname:preTransform set to a value other than
80ename:VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR, should the rectangular region,
81slink:VkRectLayerKHR, be transformed to align with the pname:preTransform?
82
83*RESOLVED*: No.
84The rectangular region in slink:VkRectLayerKHR should not be tranformed.
85As such, it may not align with the extents of the swapchain's image(s).
86It is the responsibility of the presentation engine to transform the
87rectangular region.
88This matches the behavior of the Android presentation engine, which set the
89precedent.
90
91=== Version History
92
93 * Revision 1, 2016-11-02 (Ian Elliott)
94   - Internal revisions
95 * Revision 2, 2021-03-18 (Ian Elliott)
96   - Clarified alignment of rectangles for presentation engines that support
97     transformed swapchains.
98