File: renderpass.rst

package info (click to toggle)
mesa 25.2.7-1
  • links: PTS, VCS
  • area: main
  • in suites: sid
  • size: 311,960 kB
  • sloc: ansic: 2,185,172; xml: 1,028,239; cpp: 512,159; python: 76,146; asm: 38,329; yacc: 12,198; lisp: 4,114; lex: 3,429; sh: 855; makefile: 237
file content (111 lines) | stat: -rw-r--r-- 4,252 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
Render Passes
=============

The Vulkan runtime code in Mesa provides several helpful utilities to make
managing render passes easier.


:ext:`VK_KHR_create_renderpass2`
--------------------------------

It is strongly recommended that drivers implement
:ext:`VK_KHR_create_renderpass2` directly and not bother implementing the
old Vulkan 1.0 entrypoints.  If a driver does not implement them, the
following will be implemented in common code in terms of their
:ext:`VK_KHR_create_renderpass2` counterparts:

 - :c:func:`vkCreateRenderPass`
 - :c:func:`vkCmdBeginRenderPass`
 - :c:func:`vkCmdNextSubpass`
 - :c:func:`vkCmdEndRenderPass`


Common VkRenderPass implementation
----------------------------------

The Vulkan runtime code in Mesa provides a common implementation of
:c:type:`VkRenderPass` called :c:struct:`vk_render_pass` which drivers
can optionally use.  Unlike most Vulkan runtime structs, it's not really
designed to be used as a base for a driver-specific struct.  It does,
however, contain all the information passed to
:c:func:`vkCreateRenderPass2` so it can be used in a driver so long as
that driver doesn't need to do any additional compilation at
:c:func:`vkCreateRenderPass2` time.  If a driver chooses to use
:c:struct:`vk_render_pass`, the Vulkan runtime provides implementations
of :c:func:`vkCreateRenderPass2` and :c:func:`vkDestroyRenderPass`.


:ext:`VK_KHR_dynamic_rendering`
-------------------------------

For drivers which don't need to do subpass combining, it is recommended
that they skip implementing render passes entirely and implement
:ext:`VK_KHR_dynamic_rendering` instead.  If they choose to do so, the runtime
will provide the following, implemented in terms of
:c:func:`vkCmdBeginRendering` and :c:func:`vkCmdEndRendering`:

 - :c:func:`vkCmdBeginRenderPass2`
 - :c:func:`vkCmdNextSubpass2`
 - :c:func:`vkCmdEndRenderPass2`

We also provide a no-op implementation of
:c:func:`vkGetRenderAreaGranularity` which returns a render area
granularity of 1x1.

Drivers which wish to use the common render pass implementation in this way
**must** also support a Mesa-specific pseudo-extension which optionally
provides an initial image layout for each attachment at
:c:func:`vkCmdBeginRendering` time.  This is required for us to combine
render pass clears with layout transitions, often from
:c:enum:`VK_IMAGE_LAYOUT_UNDEFINED`.  On at least Intel and AMD,
combining these transitions with clears is important for performance.

.. c:autostruct:: VkRenderingAttachmentInitialLayoutInfoMESA
   :file: src/vulkan/runtime/vk_render_pass.h
   :members:

Because render passes and subpass indices are also passed into
:c:func:`vkCmdCreateGraphicsPipelines` and
:c:func:`vkCmdExecuteCommands` which we can't implement on the driver's
behalf, we provide a couple of helpers for getting the render pass
information in terms of the relevant :ext:`VK_KHR_dynamic_rendering`:

.. c:autofunction:: vk_get_pipeline_rendering_create_info
   :file: src/vulkan/runtime/vk_render_pass.h

.. c:autofunction:: vk_get_command_buffer_inheritance_rendering_info
   :file: src/vulkan/runtime/vk_render_pass.h

Apart from handling layout transitions, the common render pass
implementation mostly ignores input attachments.  It is expected that the
driver call :c:func:`nir_lower_input_attachments` to turn them into
texturing operations.  The driver **must** support texturing from an input
attachment at the same time as rendering to it in order to support Vulkan
subpass self-dependencies. ``VK_EXT_attachment_feedback_loop_layout`` provides
information on when these self dependencies are present.

vk_render_pass reference
------------------------

The following is a reference for the :c:struct:`vk_render_pass` structure
and its substructures.

.. c:autostruct:: vk_render_pass
   :file: src/vulkan/runtime/vk_render_pass.h
   :members:

.. c:autostruct:: vk_render_pass_attachment
   :file: src/vulkan/runtime/vk_render_pass.h
   :members:

.. c:autostruct:: vk_subpass
   :file: src/vulkan/runtime/vk_render_pass.h
   :members:

.. c:autostruct:: vk_subpass_attachment
   :file: src/vulkan/runtime/vk_render_pass.h
   :members:

.. c:autostruct:: vk_subpass_dependency
   :file: src/vulkan/runtime/vk_render_pass.h
   :members: