7. Render Pass
A render pass represents a collection of attachments, subpasses, and dependencies between the subpasses, and describes how the attachments are used over the course of the subpasses. The use of a render pass in a command buffer is a render pass instance.
Render passes are represented by VkRenderPass
handles:
// Provided by VK_VERSION_1_0
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkRenderPass)
An attachment description describes the properties of an attachment including its format, sample count, and how its contents are treated at the beginning and end of each render pass instance.
A subpass represents a phase of rendering that reads and writes a subset of the attachments in a render pass. Rendering commands are recorded into a particular subpass of a render pass instance.
A subpass description describes the subset of attachments that is involved in the execution of a subpass. Each subpass can read from some attachments as input attachments, write to some as color attachments or depth/stencil attachments, perform shader resolve operations to color_attachments or depth/stencil_attachments, and perform multisample resolve operations to resolve attachments. A subpass description can also include a set of preserve attachments, which are attachments that are not read or written by the subpass but whose contents must be preserved throughout the subpass.
A subpass uses an attachment if the attachment is a color, depth/stencil,
resolve,
depth/stencil resolve,
or input attachment for that subpass (as determined by the
pColorAttachments
, pDepthStencilAttachment
,
pResolveAttachments
,
VkSubpassDescriptionDepthStencilResolve::pDepthStencilResolveAttachment
,
and pInputAttachments
members of VkSubpassDescription,
respectively).
A subpass does not use an attachment if that attachment is preserved by the
subpass.
The first use of an attachment is in the lowest numbered subpass that uses
that attachment.
Similarly, the last use of an attachment is in the highest numbered
subpass that uses that attachment.
The subpasses in a render pass all render to the same dimensions, and fragments for pixel (x,y,layer) in one subpass can only read attachment contents written by previous subpasses at that same (x,y,layer) location.
Note
By describing a complete set of subpasses in advance, render passes provide the implementation an opportunity to optimize the storage and transfer of attachment data between subpasses. In practice, this means that subpasses with a simple framebuffer-space dependency may be merged into a single tiled rendering pass, keeping the attachment data on-chip for the duration of a render pass instance. However, it is also quite common for a render pass to only contain a single subpass. |
Subpass dependencies describe execution and memory dependencies between subpasses.
A subpass dependency chain is a sequence of subpass dependencies in a render pass, where the source subpass of each subpass dependency (after the first) equals the destination subpass of the previous dependency.
Execution of subpasses may overlap or execute out of order with regards to other subpasses, unless otherwise enforced by an execution dependency. Each subpass only respects submission order for commands recorded in the same subpass, and the vkCmdBeginRenderPass and vkCmdEndRenderPass commands that delimit the render pass - commands within other subpasses are not included. This affects most other implicit ordering guarantees.
A render pass describes the structure of subpasses and attachments
independent of any specific image views for the attachments.
The specific image views that will be used for the attachments, and their
dimensions, are specified in VkFramebuffer
objects.
Framebuffers are created with respect to a specific render pass that the
framebuffer is compatible with (see Render Pass
Compatibility).
Collectively, a render pass and a framebuffer define the complete render
target state for one or more subpasses as well as the algorithmic
dependencies between the subpasses.
The various pipeline stages of the drawing commands for a given subpass may execute concurrently and/or out of order, both within and across drawing commands, whilst still respecting pipeline order. However for a given (x,y,layer,sample) sample location, certain per-sample operations are performed in rasterization order.
7.1. Render Pass Creation
To create a render pass, call:
// Provided by VK_VERSION_1_0
VkResult vkCreateRenderPass(
VkDevice device,
const VkRenderPassCreateInfo* pCreateInfo,
const VkAllocationCallbacks* pAllocator,
VkRenderPass* pRenderPass);
-
device
is the logical device that creates the render pass. -
pCreateInfo
is a pointer to a VkRenderPassCreateInfo structure describing the parameters of the render pass. -
pAllocator
controls host memory allocation as described in the Memory Allocation chapter. -
pRenderPass
is a pointer to a VkRenderPass handle in which the resulting render pass object is returned.
The VkRenderPassCreateInfo
structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkRenderPassCreateInfo {
VkStructureType sType;
const void* pNext;
VkRenderPassCreateFlags flags;
uint32_t attachmentCount;
const VkAttachmentDescription* pAttachments;
uint32_t subpassCount;
const VkSubpassDescription* pSubpasses;
uint32_t dependencyCount;
const VkSubpassDependency* pDependencies;
} VkRenderPassCreateInfo;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
flags
is a bitmask of VkRenderPassCreateFlagBits -
attachmentCount
is the number of attachments used by this render pass. -
pAttachments
is a pointer to an array ofattachmentCount
VkAttachmentDescription structures describing the attachments used by the render pass. -
subpassCount
is the number of subpasses to create. -
pSubpasses
is a pointer to an array ofsubpassCount
VkSubpassDescription structures describing each subpass. -
dependencyCount
is the number of memory dependencies between pairs of subpasses. -
pDependencies
is a pointer to an array ofdependencyCount
VkSubpassDependency structures describing dependencies between pairs of subpasses.
Note
Care should be taken to avoid a data race here; if any subpasses access attachments with overlapping memory locations, and one of those accesses is a write, a subpass dependency needs to be included between them. |
Bits which can be set in VkRenderPassCreateInfo::flags
describing additional properties of the render pass are:
// Provided by VK_VERSION_1_0
typedef enum VkRenderPassCreateFlagBits {
// Provided by VK_QCOM_render_pass_transform
VK_RENDER_PASS_CREATE_TRANSFORM_BIT_QCOM = 0x00000002,
} VkRenderPassCreateFlagBits;
-
VK_RENDER_PASS_CREATE_TRANSFORM_BIT_QCOM
specifies that the created renderpass is compatible with render pass transform.
// Provided by VK_VERSION_1_0
typedef VkFlags VkRenderPassCreateFlags;
VkRenderPassCreateFlags
is a bitmask type for setting a mask of zero
or more VkRenderPassCreateFlagBits.
If the VkRenderPassCreateInfo::pNext
chain includes a
VkRenderPassMultiviewCreateInfo
structure, then that structure
includes an array of view masks, view offsets, and correlation masks for the
render pass.
The VkRenderPassMultiviewCreateInfo
structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkRenderPassMultiviewCreateInfo {
VkStructureType sType;
const void* pNext;
uint32_t subpassCount;
const uint32_t* pViewMasks;
uint32_t dependencyCount;
const int32_t* pViewOffsets;
uint32_t correlationMaskCount;
const uint32_t* pCorrelationMasks;
} VkRenderPassMultiviewCreateInfo;
or the equivalent
// Provided by VK_KHR_multiview
typedef VkRenderPassMultiviewCreateInfo VkRenderPassMultiviewCreateInfoKHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
subpassCount
is zero or the number of subpasses in the render pass. -
pViewMasks
is a pointer to an array ofsubpassCount
view masks, where each mask is a bitfield of view indices describing which views rendering is broadcast to in each subpass, when multiview is enabled. IfsubpassCount
is zero, each view mask is treated as zero. -
dependencyCount
is zero or the number of dependencies in the render pass. -
pViewOffsets
is a pointer to an array ofdependencyCount
view offsets, one for each dependency. IfdependencyCount
is zero, each dependency’s view offset is treated as zero. Each view offset controls which views in the source subpass the views in the destination subpass depend on. -
correlationMaskCount
is zero or the number of correlation masks. -
pCorrelationMasks
is a pointer to an array ofcorrelationMaskCount
view masks indicating sets of views that may be more efficient to render concurrently.
When a subpass uses a non-zero view mask, multiview functionality is
considered to be enabled.
Multiview is all-or-nothing for a render pass - that is, either all
subpasses must have a non-zero view mask (though some subpasses may have
only one view) or all must be zero.
Multiview causes all drawing and clear commands in the subpass to behave as
if they were broadcast to each view, where a view is represented by one
layer of the framebuffer attachments.
All draws and clears are broadcast to each view index whose bit is set in
the view mask.
The view index is provided in the ViewIndex
shader input variable, and
color, depth/stencil, and input attachments all read/write the layer of the
framebuffer corresponding to the view index.
If the view mask is zero for all subpasses, multiview is considered to be disabled and all drawing commands execute normally, without this additional broadcasting.
Some implementations may not support multiview in conjunction with geometry shaders or tessellation shaders.
When multiview is enabled, the VK_DEPENDENCY_VIEW_LOCAL_BIT
bit in a
dependency can be used to express a view-local dependency, meaning that
each view in the destination subpass depends on a single view in the source
subpass.
Unlike pipeline barriers, a subpass dependency can potentially have a
different view mask in the source subpass and the destination subpass.
If the dependency is view-local, then each view (dstView) in the
destination subpass depends on the view dstView +
pViewOffsets
[dependency] in the source subpass.
If there is not such a view in the source subpass, then this dependency does
not affect that view in the destination subpass.
If the dependency is not view-local, then all views in the destination
subpass depend on all views in the source subpass, and the view offset is
ignored.
A non-zero view offset is not allowed in a self-dependency.
The elements of pCorrelationMasks
are a set of masks of views
indicating that views in the same mask may exhibit spatial coherency
between the views, making it more efficient to render them concurrently.
Correlation masks must not have a functional effect on the results of the
multiview rendering.
When multiview is enabled, at the beginning of each subpass all non-render pass state is undefined. In particular, each time vkCmdBeginRenderPass or vkCmdNextSubpass is called the graphics pipeline must be bound, any relevant descriptor sets or vertex/index buffers must be bound, and any relevant dynamic state or push constants must be set before they are used.
A multiview subpass can declare that its shaders will write per-view
attributes for all views in a single invocation, by setting the
VK_SUBPASS_DESCRIPTION_PER_VIEW_ATTRIBUTES_BIT_NVX
bit in the subpass
description.
The only supported per-view attributes are position and viewport mask, and
per-view position and viewport masks are written to output array variables
decorated with PositionPerViewNV
and ViewportMaskPerViewNV
,
respectively.
If VK_NV_viewport_array2
is not supported and enabled,
ViewportMaskPerViewNV
must not be used.
Values written to elements of PositionPerViewNV
and
ViewportMaskPerViewNV
must not depend on the ViewIndex
.
The shader must also write to an output variable decorated with
Position
, and the value written to Position
must equal the value
written to PositionPerViewNV
[ViewIndex
].
Similarly, if ViewportMaskPerViewNV
is written to then the shader must
also write to an output variable decorated with ViewportMaskNV
, and the
value written to ViewportMaskNV
must equal the value written to
ViewportMaskPerViewNV
[ViewIndex
].
Implementations will either use values taken from Position
and
ViewportMaskNV
and invoke the shader once for each view, or will use
values taken from PositionPerViewNV
and ViewportMaskPerViewNV
and
invoke the shader fewer times.
The values written to Position
and ViewportMaskNV
must not depend
on the values written to PositionPerViewNV
and
ViewportMaskPerViewNV
, or vice versa (to allow compilers to eliminate
the unused outputs).
All attributes that do not have *PerViewNV
counterparts must not depend
on ViewIndex
.
Per-view attributes are all-or-nothing for a subpass.
That is, all pipelines compiled against a subpass that includes the
VK_SUBPASS_DESCRIPTION_PER_VIEW_ATTRIBUTES_BIT_NVX
bit must write
per-view attributes to the *PerViewNV[]
shader outputs, in addition to the
non-per-view (e.g. Position
) outputs.
Pipelines compiled against a subpass that does not include this bit must
not include the *PerViewNV[]
outputs in their interfaces.
If the VkRenderPassCreateInfo::pNext
chain includes a
VkRenderPassFragmentDensityMapCreateInfoEXT
structure, then that
structure includes a fragment density map attachment for the render pass.
The VkRenderPassFragmentDensityMapCreateInfoEXT
structure is defined
as:
// Provided by VK_EXT_fragment_density_map
typedef struct VkRenderPassFragmentDensityMapCreateInfoEXT {
VkStructureType sType;
const void* pNext;
VkAttachmentReference fragmentDensityMapAttachment;
} VkRenderPassFragmentDensityMapCreateInfoEXT;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
fragmentDensityMapAttachment
is the fragment density map to use for the render pass.
The fragment density map is read at an implementation-dependent time with
the following constraints determined by the attachment’s image view
flags
:
-
VK_IMAGE_VIEW_CREATE_FRAGMENT_DENSITY_MAP_DYNAMIC_BIT_EXT
specifies that the fragment density map will be read by the device duringVK_PIPELINE_STAGE_FRAGMENT_DENSITY_PROCESS_BIT_EXT
-
VK_IMAGE_VIEW_CREATE_FRAGMENT_DENSITY_MAP_DEFERRED_BIT_EXT
specifies that the fragment density map will be read by the host during vkEndCommandBuffer of the primary command buffer that the render pass is recorded into -
Otherwise the fragment density map will be read by the host during vkCmdBeginRenderPass
The fragment density map may additionally be read by the device during
VK_PIPELINE_STAGE_FRAGMENT_DENSITY_PROCESS_BIT_EXT
for any mode.
If this structure is not present, it is as if
fragmentDensityMapAttachment
was given as VK_ATTACHMENT_UNUSED
.
The VkAttachmentDescription
structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkAttachmentDescription {
VkAttachmentDescriptionFlags flags;
VkFormat format;
VkSampleCountFlagBits samples;
VkAttachmentLoadOp loadOp;
VkAttachmentStoreOp storeOp;
VkAttachmentLoadOp stencilLoadOp;
VkAttachmentStoreOp stencilStoreOp;
VkImageLayout initialLayout;
VkImageLayout finalLayout;
} VkAttachmentDescription;
-
flags
is a bitmask of VkAttachmentDescriptionFlagBits specifying additional properties of the attachment. -
format
is a VkFormat value specifying the format of the image view that will be used for the attachment. -
samples
is the number of samples of the image as defined in VkSampleCountFlagBits. -
loadOp
is a VkAttachmentLoadOp value specifying how the contents of color and depth components of the attachment are treated at the beginning of the subpass where it is first used. -
storeOp
is a VkAttachmentStoreOp value specifying how the contents of color and depth components of the attachment are treated at the end of the subpass where it is last used. -
stencilLoadOp
is a VkAttachmentLoadOp value specifying how the contents of stencil components of the attachment are treated at the beginning of the subpass where it is first used. -
stencilStoreOp
is a VkAttachmentStoreOp value specifying how the contents of stencil components of the attachment are treated at the end of the last subpass where it is used. -
initialLayout
is the layout the attachment image subresource will be in when a render pass instance begins. -
finalLayout
is the layout the attachment image subresource will be transitioned to when a render pass instance ends.
If the attachment uses a color format, then loadOp
and storeOp
are used, and stencilLoadOp
and stencilStoreOp
are ignored.
If the format has depth and/or stencil components, loadOp
and
storeOp
apply only to the depth data, while stencilLoadOp
and
stencilStoreOp
define how the stencil data is handled.
loadOp
and stencilLoadOp
define the load operations that
execute as part of the first subpass that uses the attachment.
storeOp
and stencilStoreOp
define the store operations that
execute as part of the last subpass that uses the attachment.
The load operation for each sample in an attachment happens-before any
recorded command which accesses the sample in the first subpass where the
attachment is used.
Load operations for attachments with a depth/stencil format execute in the
VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT
pipeline stage.
Load operations for attachments with a color format execute in the
VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT
pipeline stage.
The store operation for each sample in an attachment happens-after any
recorded command which accesses the sample in the last subpass where the
attachment is used.
Store operations for attachments with a depth/stencil format execute in the
VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT
pipeline stage.
Store operations for attachments with a color format execute in the
VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT
pipeline stage.
If an attachment is not used by any subpass, then loadOp
,
storeOp
, stencilStoreOp
, and stencilLoadOp
are ignored,
and the attachment’s memory contents will not be modified by execution of a
render pass instance.
The load and store operations apply on the first and last use of each view in the render pass, respectively. If a view index of an attachment is not included in the view mask in any subpass that uses it, then the load and store operations are ignored, and the attachment’s memory contents will not be modified by execution of a render pass instance.
During a render pass instance, input/color attachments with color formats
that have a component size of 8, 16, or 32 bits must be represented in the
attachment’s format throughout the instance.
Attachments with other floating- or fixed-point color formats, or with depth
components may be represented in a format with a precision higher than the
attachment format, but must be represented with the same range.
When such a component is loaded via the loadOp
, it will be converted
into an implementation-dependent format used by the render pass.
Such components must be converted from the render pass format, to the
format of the attachment, before they are resolved or stored at the end of a
render pass instance via storeOp
.
Conversions occur as described in Numeric
Representation and Computation and Fixed-Point
Data Conversions.
If flags
includes VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT
, then
the attachment is treated as if it shares physical memory with another
attachment in the same render pass.
This information limits the ability of the implementation to reorder certain
operations (like layout transitions and the loadOp
) such that it is
not improperly reordered against other uses of the same physical memory via
a different attachment.
This is described in more detail below.
If a render pass uses multiple attachments that alias the same device
memory, those attachments must each include the
VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT
bit in their attachment
description flags.
Attachments aliasing the same memory occurs in multiple ways:
-
Multiple attachments being assigned the same image view as part of framebuffer creation.
-
Attachments using distinct image views that correspond to the same image subresource of an image.
-
Attachments using views of distinct image subresources which are bound to overlapping memory ranges.
Note
Render passes must include subpass dependencies (either directly or via a
subpass dependency chain) between any two subpasses that operate on the same
attachment or aliasing attachments and those subpass dependencies must
include execution and memory dependencies separating uses of the aliases, if
at least one of those subpasses writes to one of the aliases.
These dependencies must not include the |
Multiple attachments that alias the same memory must not be used in a single subpass. A given attachment index must not be used multiple times in a single subpass, with one exception: two subpass attachments can use the same attachment index if at least one use is as an input attachment and neither use is as a resolve or preserve attachment. In other words, the same view can be used simultaneously as an input and color or depth/stencil attachment, but must not be used as multiple color or depth/stencil attachments nor as resolve or preserve attachments. The precise set of valid scenarios is described in more detail below.
If a set of attachments alias each other, then all except the first to be
used in the render pass must use an initialLayout
of
VK_IMAGE_LAYOUT_UNDEFINED
, since the earlier uses of the other aliases
make their contents undefined.
Once an alias has been used and a different alias has been used after it,
the first alias must not be used in any later subpasses.
However, an application can assign the same image view to multiple aliasing
attachment indices, which allows that image view to be used multiple times
even if other aliases are used in between.
Note
Once an attachment needs the |
Bits which can be set in VkAttachmentDescription::flags
describing additional properties of the attachment are:
// Provided by VK_VERSION_1_0
typedef enum VkAttachmentDescriptionFlagBits {
VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT = 0x00000001,
} VkAttachmentDescriptionFlagBits;
-
VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT
specifies that the attachment aliases the same device memory as other attachments.
// Provided by VK_VERSION_1_0
typedef VkFlags VkAttachmentDescriptionFlags;
VkAttachmentDescriptionFlags
is a bitmask type for setting a mask of
zero or more VkAttachmentDescriptionFlagBits.
Possible values of VkAttachmentDescription::loadOp
and
stencilLoadOp
, specifying how the contents of the attachment are
treated, are:
// Provided by VK_VERSION_1_0
typedef enum VkAttachmentLoadOp {
VK_ATTACHMENT_LOAD_OP_LOAD = 0,
VK_ATTACHMENT_LOAD_OP_CLEAR = 1,
VK_ATTACHMENT_LOAD_OP_DONT_CARE = 2,
} VkAttachmentLoadOp;
-
VK_ATTACHMENT_LOAD_OP_LOAD
specifies that the previous contents of the image within the render area will be preserved. For attachments with a depth/stencil format, this uses the access typeVK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT
. For attachments with a color format, this uses the access typeVK_ACCESS_COLOR_ATTACHMENT_READ_BIT
. -
VK_ATTACHMENT_LOAD_OP_CLEAR
specifies that the contents within the render area will be cleared to a uniform value, which is specified when a render pass instance is begun. For attachments with a depth/stencil format, this uses the access typeVK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT
. For attachments with a color format, this uses the access typeVK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT
. -
VK_ATTACHMENT_LOAD_OP_DONT_CARE
specifies that the previous contents within the area need not be preserved; the contents of the attachment will be undefined inside the render area. For attachments with a depth/stencil format, this uses the access typeVK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT
. For attachments with a color format, this uses the access typeVK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT
.
Possible values of VkAttachmentDescription::storeOp
and
stencilStoreOp
, specifying how the contents of the attachment are
treated, are:
// Provided by VK_VERSION_1_0
typedef enum VkAttachmentStoreOp {
VK_ATTACHMENT_STORE_OP_STORE = 0,
VK_ATTACHMENT_STORE_OP_DONT_CARE = 1,
// Provided by VK_QCOM_render_pass_store_ops
VK_ATTACHMENT_STORE_OP_NONE_QCOM = 1000301000,
} VkAttachmentStoreOp;
-
VK_ATTACHMENT_STORE_OP_STORE
specifies the contents generated during the render pass and within the render area are written to memory. For attachments with a depth/stencil format, this uses the access typeVK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT
. For attachments with a color format, this uses the access typeVK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT
. -
VK_ATTACHMENT_STORE_OP_DONT_CARE
specifies the contents within the render area are not needed after rendering, and may be discarded; the contents of the attachment will be undefined inside the render area. For attachments with a depth/stencil format, this uses the access typeVK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT
. For attachments with a color format, this uses the access typeVK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT
. -
VK_ATTACHMENT_STORE_OP_NONE_QCOM
specifies that the contents within the render area were not written during rendering, and may not be written to memory. If the attachment was written to during the renderpass, the contents of the attachment will be undefined inside the render area.
Note
|
To specify which aspects of an input attachment can be read, add a
VkRenderPassInputAttachmentAspectCreateInfo structure to the
pNext
chain of the VkRenderPassCreateInfo structure:
The VkRenderPassInputAttachmentAspectCreateInfo
structure is defined
as:
// Provided by VK_VERSION_1_1
typedef struct VkRenderPassInputAttachmentAspectCreateInfo {
VkStructureType sType;
const void* pNext;
uint32_t aspectReferenceCount;
const VkInputAttachmentAspectReference* pAspectReferences;
} VkRenderPassInputAttachmentAspectCreateInfo;
or the equivalent
// Provided by VK_KHR_maintenance2
typedef VkRenderPassInputAttachmentAspectCreateInfo VkRenderPassInputAttachmentAspectCreateInfoKHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
aspectReferenceCount
is the number of elements in thepAspectReferences
array. -
pAspectReferences
is a pointer to an array ofaspectReferenceCount
VkInputAttachmentAspectReference structures containing a mask describing which aspect(s) can be accessed for a given input attachment within a given subpass.
An application can access any aspect of an input attachment that does not
have a specified aspect mask in the pAspectReferences
array.
Otherwise, an application must not access aspect(s) of an input attachment
other than those in its specified aspect mask.
The VkInputAttachmentAspectReference
structure specifies an aspect
mask for a specific input attachment of a specific subpass in the render
pass.
subpass
and inputAttachmentIndex
index into the render pass as:
pCreateInfo->pSubpasses
[subpass].pInputAttachments[inputAttachmentIndex]
// Provided by VK_VERSION_1_1
typedef struct VkInputAttachmentAspectReference {
uint32_t subpass;
uint32_t inputAttachmentIndex;
VkImageAspectFlags aspectMask;
} VkInputAttachmentAspectReference;
or the equivalent
// Provided by VK_KHR_maintenance2
typedef VkInputAttachmentAspectReference VkInputAttachmentAspectReferenceKHR;
-
subpass
is an index into thepSubpasses
array of the parentVkRenderPassCreateInfo
structure. -
inputAttachmentIndex
is an index into thepInputAttachments
of the specified subpass. -
aspectMask
is a mask of which aspect(s) can be accessed within the specified subpass.
The VkSubpassDescription
structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkSubpassDescription {
VkSubpassDescriptionFlags flags;
VkPipelineBindPoint pipelineBindPoint;
uint32_t inputAttachmentCount;
const VkAttachmentReference* pInputAttachments;
uint32_t colorAttachmentCount;
const VkAttachmentReference* pColorAttachments;
const VkAttachmentReference* pResolveAttachments;
const VkAttachmentReference* pDepthStencilAttachment;
uint32_t preserveAttachmentCount;
const uint32_t* pPreserveAttachments;
} VkSubpassDescription;
-
flags
is a bitmask of VkSubpassDescriptionFlagBits specifying usage of the subpass. -
pipelineBindPoint
is a VkPipelineBindPoint value specifying the pipeline type supported for this subpass. -
inputAttachmentCount
is the number of input attachments. -
pInputAttachments
is a pointer to an array of VkAttachmentReference structures defining the input attachments for this subpass and their layouts. -
colorAttachmentCount
is the number of color attachments. -
pColorAttachments
is a pointer to an array of VkAttachmentReference structures defining the color attachments for this subpass and their layouts. -
pResolveAttachments
is an optional array ofcolorAttachmentCount
VkAttachmentReference structures defining the resolve attachments for this subpass and their layouts. -
pDepthStencilAttachment
is a pointer to a VkAttachmentReference structure specifying the depth/stencil attachment for this subpass and its layout. -
preserveAttachmentCount
is the number of preserved attachments. -
pPreserveAttachments
is a pointer to an array ofpreserveAttachmentCount
render pass attachment indices identifying attachments that are not used by this subpass, but whose contents must be preserved throughout the subpass.
Each element of the pInputAttachments
array corresponds to an input
attachment index in a fragment shader, i.e. if a shader declares an image
variable decorated with a InputAttachmentIndex
value of X, then it
uses the attachment provided in pInputAttachments
[X].
Input attachments must also be bound to the pipeline in a descriptor set.
If the attachment
member of any element of pInputAttachments
is
VK_ATTACHMENT_UNUSED
, the application must not read from the
corresponding input attachment index.
Fragment shaders can use subpass input variables to access the contents of
an input attachment at the fragment’s (x, y, layer) framebuffer coordinates.
Input attachments must not be used by any subpasses within a renderpass
that enables render pass transform.
Each element of the pColorAttachments
array corresponds to an output
location in the shader, i.e. if the shader declares an output variable
decorated with a Location
value of X, then it uses the attachment
provided in pColorAttachments
[X].
If the attachment
member of any element of pColorAttachments
is
VK_ATTACHMENT_UNUSED
, writes to the corresponding location by a
fragment are discarded.
If
flags
does not include
VK_SUBPASS_DESCRIPTION_SHADER_RESOLVE_BIT_QCOM
, and if
pResolveAttachments
is not NULL
, each of its elements corresponds to
a color attachment (the element in pColorAttachments
at the same
index), and a multisample resolve operation is defined for each attachment.
At the end of each subpass, multisample resolve operations read the
subpass’s color attachments, and resolve the samples for each pixel within
the render area to the same pixel location in the corresponding resolve
attachments, unless the resolve attachment index is
VK_ATTACHMENT_UNUSED
.
Similarly, if
flags
does not include
VK_SUBPASS_DESCRIPTION_SHADER_RESOLVE_BIT_QCOM
, and
VkSubpassDescriptionDepthStencilResolve::pDepthStencilResolveAttachment
is not NULL
and does not have the value VK_ATTACHMENT_UNUSED
, it
corresponds to the depth/stencil attachment in
pDepthStencilAttachment
, and multisample resolve operations for depth
and stencil are defined by
VkSubpassDescriptionDepthStencilResolve::depthResolveMode
and
VkSubpassDescriptionDepthStencilResolve::stencilResolveMode
,
respectively.
At the end of each subpass, multisample resolve operations read the
subpass’s depth/stencil attachment, and resolve the samples for each pixel
to the same pixel location in the corresponding resolve attachment.
If VkSubpassDescriptionDepthStencilResolve::depthResolveMode
is
VK_RESOLVE_MODE_NONE
, then the depth component of the resolve
attachment is not written to and its contents are preserved.
Similarly, if
VkSubpassDescriptionDepthStencilResolve::stencilResolveMode
is
VK_RESOLVE_MODE_NONE
, then the stencil component of the resolve
attachment is not written to and its contents are preserved.
VkSubpassDescriptionDepthStencilResolve::depthResolveMode
is
ignored if the VkFormat of the pDepthStencilResolveAttachment
does not have a depth component.
Similarly,
VkSubpassDescriptionDepthStencilResolve::stencilResolveMode
is
ignored if the VkFormat of the pDepthStencilResolveAttachment
does not have a stencil component.
If the image subresource range referenced by the depth/stencil attachment is
created with
VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT
, then the
multisample resolve operation uses the sample locations state specified in
the sampleLocationsInfo
member of the element of the
VkRenderPassSampleLocationsBeginInfoEXT
::pPostSubpassSampleLocations
for the subpass.
If pDepthStencilAttachment
is NULL
, or if its attachment index is
VK_ATTACHMENT_UNUSED
, it indicates that no depth/stencil attachment
will be used in the subpass.
The contents of an attachment within the render area become undefined at the start of a subpass S if all of the following conditions are true:
-
The attachment is used as a color, depth/stencil, or resolve attachment in any subpass in the render pass.
-
There is a subpass S1 that uses or preserves the attachment, and a subpass dependency from S1 to S.
-
The attachment is not used or preserved in subpass S.
In addition, the contents of an attachment within the render area become undefined at the start of a subpass S if all of the following conditions are true:
-
VK_SUBPASS_DESCRIPTION_SHADER_RESOLVE_BIT_QCOM
is set. -
The attachment is used as a color or depth/stencil in the subpass.
Once the contents of an attachment become undefined in subpass S, they remain undefined for subpasses in subpass dependency chains starting with subpass S until they are written again. However, they remain valid for subpasses in other subpass dependency chains starting with subpass S1 if those subpasses use or preserve the attachment.
Bits which can be set in VkSubpassDescription::flags
,
specifying usage of the subpass, are:
// Provided by VK_VERSION_1_0
typedef enum VkSubpassDescriptionFlagBits {
// Provided by VK_NVX_multiview_per_view_attributes
VK_SUBPASS_DESCRIPTION_PER_VIEW_ATTRIBUTES_BIT_NVX = 0x00000001,
// Provided by VK_NVX_multiview_per_view_attributes
VK_SUBPASS_DESCRIPTION_PER_VIEW_POSITION_X_ONLY_BIT_NVX = 0x00000002,
// Provided by VK_QCOM_render_pass_shader_resolve
VK_SUBPASS_DESCRIPTION_FRAGMENT_REGION_BIT_QCOM = 0x00000004,
// Provided by VK_QCOM_render_pass_shader_resolve
VK_SUBPASS_DESCRIPTION_SHADER_RESOLVE_BIT_QCOM = 0x00000008,
} VkSubpassDescriptionFlagBits;
-
VK_SUBPASS_DESCRIPTION_PER_VIEW_ATTRIBUTES_BIT_NVX
specifies that shaders compiled for this subpass write the attributes for all views in a single invocation of each vertex processing stage. All pipelines compiled against a subpass that includes this bit must write per-view attributes to the*PerViewNV[]
shader outputs, in addition to the non-per-view (e.g.Position
) outputs. -
VK_SUBPASS_DESCRIPTION_PER_VIEW_POSITION_X_ONLY_BIT_NVX
specifies that shaders compiled for this subpass use per-view positions which only differ in value in the x component. Per-view viewport mask can also be used. -
VK_SUBPASS_DESCRIPTION_FRAGMENT_REGION_BIT_QCOM
specifies that the framebuffer region is the fragment region, that is, the minimum region dependencies are by pixel rather than by sample, such that any fragment shader invocation can access any sample associated with that fragment shader invocation. -
VK_SUBPASS_DESCRIPTION_SHADER_RESOLVE_BIT_QCOM
specifies that the subpass performs shader resolve operations.
Note
Shader resolve operations allow for custom resolve operations, but overdrawing pixels may have a performance and/or power cost. Furthermore, since the content of any depth stencil attachment or color attachment is undefined at the begining of a shader resolve subpass, any depth testing, stencil testing, or blending operation which sources these undefined values also has undefined result value. |
// Provided by VK_VERSION_1_0
typedef VkFlags VkSubpassDescriptionFlags;
VkSubpassDescriptionFlags
is a bitmask type for setting a mask of zero
or more VkSubpassDescriptionFlagBits.
The VkAttachmentReference
structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkAttachmentReference {
uint32_t attachment;
VkImageLayout layout;
} VkAttachmentReference;
-
attachment
is either an integer value identifying an attachment at the corresponding index in VkRenderPassCreateInfo::pAttachments
, orVK_ATTACHMENT_UNUSED
to signify that this attachment is not used. -
layout
is a VkImageLayout value specifying the layout the attachment uses during the subpass.
The VkSubpassDependency
structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkSubpassDependency {
uint32_t srcSubpass;
uint32_t dstSubpass;
VkPipelineStageFlags srcStageMask;
VkPipelineStageFlags dstStageMask;
VkAccessFlags srcAccessMask;
VkAccessFlags dstAccessMask;
VkDependencyFlags dependencyFlags;
} VkSubpassDependency;
-
srcSubpass
is the subpass index of the first subpass in the dependency, orVK_SUBPASS_EXTERNAL
. -
dstSubpass
is the subpass index of the second subpass in the dependency, orVK_SUBPASS_EXTERNAL
. -
srcStageMask
is a bitmask of VkPipelineStageFlagBits specifying the source stage mask. -
dstStageMask
is a bitmask of VkPipelineStageFlagBits specifying the destination stage mask -
srcAccessMask
is a bitmask of VkAccessFlagBits specifying a source access mask. -
dstAccessMask
is a bitmask of VkAccessFlagBits specifying a destination access mask. -
dependencyFlags
is a bitmask of VkDependencyFlagBits.
If srcSubpass
is equal to dstSubpass
then the
VkSubpassDependency describes a
subpass
self-dependency, and only constrains the pipeline barriers allowed within
a subpass instance.
Otherwise, when a render pass instance which includes a subpass dependency
is submitted to a queue, it defines a memory dependency between the
subpasses identified by srcSubpass
and dstSubpass
.
If srcSubpass
is equal to VK_SUBPASS_EXTERNAL
, the first
synchronization scope includes
commands that occur earlier in submission
order than the vkCmdBeginRenderPass used to begin the render pass
instance.
Otherwise, the first set of commands includes all commands submitted as part
of the subpass instance identified by srcSubpass
and any load, store
or multisample resolve operations on attachments used in srcSubpass
.
In either case, the first synchronization scope is limited to operations on
the pipeline stages determined by the
source stage mask specified by
srcStageMask
.
If dstSubpass
is equal to VK_SUBPASS_EXTERNAL
, the second
synchronization scope includes
commands that occur later in submission
order than the vkCmdEndRenderPass used to end the render pass
instance.
Otherwise, the second set of commands includes all commands submitted as
part of the subpass instance identified by dstSubpass
and any load,
store or multisample resolve operations on attachments used in
dstSubpass
.
In either case, the second synchronization scope is limited to operations on
the pipeline stages determined by the
destination stage mask specified
by dstStageMask
.
The first access scope is
limited to access in the pipeline stages determined by the
source stage mask specified by
srcStageMask
.
It is also limited to access types in the source access mask specified by srcAccessMask
.
The second access scope is
limited to access in the pipeline stages determined by the
destination stage mask specified
by dstStageMask
.
It is also limited to access types in the destination access mask specified by dstAccessMask
.
The availability and visibility operations defined by a subpass dependency affect the execution of image layout transitions within the render pass.
Note
For non-attachment resources, the memory dependency expressed by subpass
dependency is nearly identical to that of a VkMemoryBarrier (with
matching For attachments however, subpass dependencies work more like a
VkImageMemoryBarrier defined similarly to the VkMemoryBarrier
above, the queue family indices set to
|
When multiview is enabled, the execution of the multiple views of one
subpass may not occur simultaneously or even back-to-back, and rather may
be interleaved with the execution of other subpasses.
The load and store operations apply to attachments on a per-view basis.
For example, an attachment using VK_ATTACHMENT_LOAD_OP_CLEAR
will have
each view cleared on first use, but the first use of one view may be
temporally distant from the first use of another view.
Note
A good mental model for multiview is to think of a multiview subpass as if it were a collection of individual (per-view) subpasses that are logically grouped together and described as a single multiview subpass in the API. Similarly, a multiview attachment can be thought of like several individual attachments that happen to be layers in a single image. A view-local dependency between two multiview subpasses acts like a set of one-to-one dependencies between corresponding pairs of per-view subpasses. A view-global dependency between two multiview subpasses acts like a set of N × M dependencies between all pairs of per-view subpasses in the source and destination. Thus, it is a more compact representation which also makes clear the commonality and reuse that is present between views in a subpass. This interpretation motivates the answers to questions like “when does the load op apply” - it is on the first use of each view of an attachment, as if each view were a separate attachment. |
If any two subpasses of a render pass activate transform feedback to the same bound transform feedback buffers, a subpass dependency must be included (either directly or via some intermediate subpasses) between them.
editing-note
The following two alleged implicit dependencies are practically no-ops, as the operations they describe are already guaranteed by semaphores and submission order (so they are almost entirely no-ops on their own). The only reason they exist is because it simplifies reasoning about where automatic layout transitions happen. Further rewrites of this chapter could potentially remove the need for these. |
If there is no subpass dependency from VK_SUBPASS_EXTERNAL
to the
first subpass that uses an attachment, then an implicit subpass dependency
exists from VK_SUBPASS_EXTERNAL
to the first subpass it is used in.
The implicit subpass dependency only exists if there exists an automatic
layout transition away from initialLayout
.
The subpass dependency operates as if defined with the following parameters:
VkSubpassDependency implicitDependency = {
.srcSubpass = VK_SUBPASS_EXTERNAL;
.dstSubpass = firstSubpass; // First subpass attachment is used in
.srcStageMask = VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT;
.dstStageMask = VK_PIPELINE_STAGE_ALL_COMMANDS_BIT;
.srcAccessMask = 0;
.dstAccessMask = VK_ACCESS_INPUT_ATTACHMENT_READ_BIT |
VK_ACCESS_COLOR_ATTACHMENT_READ_BIT |
VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT |
VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT |
VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT;
.dependencyFlags = 0;
};
Similarly, if there is no subpass dependency from the last subpass that uses
an attachment to VK_SUBPASS_EXTERNAL
, then an implicit subpass
dependency exists from the last subpass it is used in to
VK_SUBPASS_EXTERNAL
.
The implicit subpass dependency only exists if there exists an automatic
layout transition into finalLayout
.
The subpass dependency operates as if defined with the following parameters:
VkSubpassDependency implicitDependency = {
.srcSubpass = lastSubpass; // Last subpass attachment is used in
.dstSubpass = VK_SUBPASS_EXTERNAL;
.srcStageMask = VK_PIPELINE_STAGE_ALL_COMMANDS_BIT;
.dstStageMask = VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT;
.srcAccessMask = VK_ACCESS_INPUT_ATTACHMENT_READ_BIT |
VK_ACCESS_COLOR_ATTACHMENT_READ_BIT |
VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT |
VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT |
VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT;
.dstAccessMask = 0;
.dependencyFlags = 0;
};
As subpasses may overlap or execute out of order with regards to other subpasses unless a subpass dependency chain describes otherwise, the layout transitions required between subpasses cannot be known to an application. Instead, an application provides the layout that each attachment must be in at the start and end of a render pass, and the layout it must be in during each subpass it is used in. The implementation then must execute layout transitions between subpasses in order to guarantee that the images are in the layouts required by each subpass, and in the final layout at the end of the render pass.
Automatic layout transitions apply to the entire image subresource attached to the framebuffer. If the attachment view is a 2D or 2D array view of a 3D image, even if the attachment view only refers to a subset of the slices of the selected mip level of the 3D image, automatic layout transitions apply to the entire subresource referenced which is the entire mip level in this case.
Automatic layout transitions away from the layout used in a subpass
happen-after the availability operations for all dependencies with that
subpass as the srcSubpass
.
Automatic layout transitions into the layout used in a subpass happen-before
the visibility operations for all dependencies with that subpass as the
dstSubpass
.
Automatic layout transitions away from initialLayout
happens-after the
availability operations for all dependencies with a srcSubpass
equal
to VK_SUBPASS_EXTERNAL
, where dstSubpass
uses the attachment
that will be transitioned.
For attachments created with VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT
,
automatic layout transitions away from initialLayout
happen-after the
availability operations for all dependencies with a srcSubpass
equal
to VK_SUBPASS_EXTERNAL
, where dstSubpass
uses any aliased
attachment.
Automatic layout transitions into finalLayout
happens-before the
visibility operations for all dependencies with a dstSubpass
equal to
VK_SUBPASS_EXTERNAL
, where srcSubpass
uses the attachment that
will be transitioned.
For attachments created with VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT
,
automatic layout transitions into finalLayout
happen-before the
visibility operations for all dependencies with a dstSubpass
equal to
VK_SUBPASS_EXTERNAL
, where srcSubpass
uses any aliased
attachment.
The image layout of the depth aspect of a depth/stencil attachment referring
to an image created with
VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT
is dependent
on the last sample locations used to render to the attachment, thus
automatic layout transitions use the sample locations state specified in
VkRenderPassSampleLocationsBeginInfoEXT.
Automatic layout transitions of an attachment referring to a depth/stencil
image created with
VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT
use the
sample locations the image subresource range referenced by the attachment
was last rendered with.
If the current render pass does not use the attachment as a depth/stencil
attachment in any subpass that happens-before, the automatic layout
transition uses the sample locations state specified in the
sampleLocationsInfo
member of the element of the
VkRenderPassSampleLocationsBeginInfoEXT
::pAttachmentInitialSampleLocations
array for which the attachmentIndex
member equals the attachment index
of the attachment, if one is specified.
Otherwise, the automatic layout transition uses the sample locations state
specified in the sampleLocationsInfo
member of the element of the
VkRenderPassSampleLocationsBeginInfoEXT
::pPostSubpassSampleLocations
array for which the subpassIndex
member equals the index of the
subpass that last used the attachment as a depth/stencil attachment, if one
is specified.
If no sample locations state has been specified for an automatic layout
transition performed on an attachment referring to a depth/stencil image
created with VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT
the contents of the depth aspect of the depth/stencil attachment become
undefined as if the layout of the attachment was transitioned from the
VK_IMAGE_LAYOUT_UNDEFINED
layout.
If two subpasses use the same attachment, and both subpasses use the attachment in a read-only layout, no subpass dependency needs to be specified between those subpasses. If an implementation treats those layouts separately, it must insert an implicit subpass dependency between those subpasses to separate the uses in each layout. The subpass dependency operates as if defined with the following parameters:
// Used for input attachments
VkPipelineStageFlags inputAttachmentStages = VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT;
VkAccessFlags inputAttachmentAccess = VK_ACCESS_INPUT_ATTACHMENT_READ_BIT;
// Used for depth/stencil attachments
VkPipelineStageFlags depthStencilAttachmentStages = VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT | VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT;
VkAccessFlags depthStencilAttachmentAccess = VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT;
VkSubpassDependency implicitDependency = {
.srcSubpass = firstSubpass;
.dstSubpass = secondSubpass;
.srcStageMask = inputAttachmentStages | depthStencilAttachmentStages;
.dstStageMask = inputAttachmentStages | depthStencilAttachmentStages;
.srcAccessMask = inputAttachmentAccess | depthStencilAttachmentAccess;
.dstAccessMask = inputAttachmentAccess | depthStencilAttachmentAccess;
.dependencyFlags = 0;
};
If a subpass uses the same attachment as both an input attachment and either a color attachment or a depth/stencil attachment, writes via the color or depth/stencil attachment are not automatically made visible to reads via the input attachment, causing a feedback loop, except in any of the following conditions:
-
If the color components or depth/stencil components read by the input attachment are mutually exclusive with the components written by the color or depth/stencil attachments, then there is no feedback loop. This requires the graphics pipelines used by the subpass to disable writes to color components that are read as inputs via the
colorWriteMask
, and to disable writes to depth/stencil components that are read as inputs viadepthWriteEnable
orstencilTestEnable
. -
If the attachment is used as an input attachment and depth/stencil attachment only, and the depth/stencil attachment is not written to.
-
If a memory dependency is inserted between when the attachment is written and when it is subsequently read by later fragments. Pipeline barriers expressing a subpass self-dependency are the only way to achieve this, and one must be inserted every time a fragment will read values at a particular sample (x, y, layer, sample) coordinate, if those values have been written since the most recent pipeline barrier; or the since start of the subpass if there have been no pipeline barriers since the start of the subpass.
An attachment used as both an input attachment and a color attachment must
be in the
VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR
or
VK_IMAGE_LAYOUT_GENERAL
layout.
An attachment used as an input attachment and depth/stencil attachment must
be in the
VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR
,
VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL
,
VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL
,
VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL
, or
VK_IMAGE_LAYOUT_GENERAL
layout.
An attachment must not be used as both a depth/stencil attachment and a
color attachment.
A more extensible version of render pass creation is also defined below.
To create a render pass, call:
// Provided by VK_VERSION_1_2
VkResult vkCreateRenderPass2(
VkDevice device,
const VkRenderPassCreateInfo2* pCreateInfo,
const VkAllocationCallbacks* pAllocator,
VkRenderPass* pRenderPass);
or the equivalent command
// Provided by VK_KHR_create_renderpass2
VkResult vkCreateRenderPass2KHR(
VkDevice device,
const VkRenderPassCreateInfo2* pCreateInfo,
const VkAllocationCallbacks* pAllocator,
VkRenderPass* pRenderPass);
-
device
is the logical device that creates the render pass. -
pCreateInfo
is a pointer to a VkRenderPassCreateInfo2 structure describing the parameters of the render pass. -
pAllocator
controls host memory allocation as described in the Memory Allocation chapter. -
pRenderPass
is a pointer to a VkRenderPass handle in which the resulting render pass object is returned.
This command is functionally identical to vkCreateRenderPass, but
includes extensible sub-structures that include sType
and pNext
parameters, allowing them to be more easily extended.
The VkRenderPassCreateInfo2
structure is defined as:
// Provided by VK_VERSION_1_2
typedef struct VkRenderPassCreateInfo2 {
VkStructureType sType;
const void* pNext;
VkRenderPassCreateFlags flags;
uint32_t attachmentCount;
const VkAttachmentDescription2* pAttachments;
uint32_t subpassCount;
const VkSubpassDescription2* pSubpasses;
uint32_t dependencyCount;
const VkSubpassDependency2* pDependencies;
uint32_t correlatedViewMaskCount;
const uint32_t* pCorrelatedViewMasks;
} VkRenderPassCreateInfo2;
or the equivalent
// Provided by VK_KHR_create_renderpass2
typedef VkRenderPassCreateInfo2 VkRenderPassCreateInfo2KHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
flags
is reserved for future use. -
attachmentCount
is the number of attachments used by this render pass. -
pAttachments
is a pointer to an array ofattachmentCount
VkAttachmentDescription2 structures describing the attachments used by the render pass. -
subpassCount
is the number of subpasses to create. -
pSubpasses
is a pointer to an array ofsubpassCount
VkSubpassDescription2 structures describing each subpass. -
dependencyCount
is the number of dependencies between pairs of subpasses. -
pDependencies
is a pointer to an array ofdependencyCount
VkSubpassDependency structures describing dependencies between pairs of subpasses. -
correlatedViewMaskCount
is the number of correlation masks. -
pCorrelatedViewMasks
is a pointer to an array of view masks indicating sets of views that may be more efficient to render concurrently.
Parameters defined by this structure with the same name as those in
VkRenderPassCreateInfo have the identical effect to those parameters;
the child structures are variants of those used in
VkRenderPassCreateInfo which add sType
and pNext
parameters, allowing them to be extended.
If the VkSubpassDescription2::viewMask
member of any element of
pSubpasses
is not zero, multiview functionality is considered to be
enabled for this render pass.
correlatedViewMaskCount
and pCorrelatedViewMasks
have the same
effect as VkRenderPassMultiviewCreateInfo::correlationMaskCount
and VkRenderPassMultiviewCreateInfo::pCorrelationMasks
,
respectively.
The VkAttachmentDescription2
structure is defined as:
// Provided by VK_VERSION_1_2
typedef struct VkAttachmentDescription2 {
VkStructureType sType;
const void* pNext;
VkAttachmentDescriptionFlags flags;
VkFormat format;
VkSampleCountFlagBits samples;
VkAttachmentLoadOp loadOp;
VkAttachmentStoreOp storeOp;
VkAttachmentLoadOp stencilLoadOp;
VkAttachmentStoreOp stencilStoreOp;
VkImageLayout initialLayout;
VkImageLayout finalLayout;
} VkAttachmentDescription2;
or the equivalent
// Provided by VK_KHR_create_renderpass2
typedef VkAttachmentDescription2 VkAttachmentDescription2KHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
flags
is a bitmask of VkAttachmentDescriptionFlagBits specifying additional properties of the attachment. -
format
is a VkFormat value specifying the format of the image that will be used for the attachment. -
samples
is the number of samples of the image as defined in VkSampleCountFlagBits. -
loadOp
is a VkAttachmentLoadOp value specifying how the contents of color and depth components of the attachment are treated at the beginning of the subpass where it is first used. -
storeOp
is a VkAttachmentStoreOp value specifying how the contents of color and depth components of the attachment are treated at the end of the subpass where it is last used. -
stencilLoadOp
is a VkAttachmentLoadOp value specifying how the contents of stencil components of the attachment are treated at the beginning of the subpass where it is first used. -
stencilStoreOp
is a VkAttachmentStoreOp value specifying how the contents of stencil components of the attachment are treated at the end of the last subpass where it is used. -
initialLayout
is the layout the attachment image subresource will be in when a render pass instance begins. -
finalLayout
is the layout the attachment image subresource will be transitioned to when a render pass instance ends.
Parameters defined by this structure with the same name as those in VkAttachmentDescription have the identical effect to those parameters.
If the separateDepthStencilLayouts
feature is enabled, and format
is
a depth/stencil format, initialLayout
and finalLayout
can be
set to a layout that only specifies the layout of the depth aspect.
If format
is a depth/stencil format, and initialLayout
only
specifies the initial layout of the depth aspect of the attachment, the
initial layout of the stencil aspect is specified by the
stencilInitialLayout
member of a
VkAttachmentDescriptionStencilLayout structure included in the
pNext
chain.
Otherwise, initialLayout
describes the initial layout for all relevant
image aspects.
If format
is a depth/stencil format, and finalLayout
only
specifies the final layout of the depth aspect of the attachment, the final
layout of the stencil aspect is specified by the stencilFinalLayout
member of a VkAttachmentDescriptionStencilLayout structure included in
the pNext
chain.
Otherwise, finalLayout
describes the final layout for all relevant
image aspects.
The VkAttachmentDescriptionStencilLayout
structure is defined as:
// Provided by VK_VERSION_1_2
typedef struct VkAttachmentDescriptionStencilLayout {
VkStructureType sType;
void* pNext;
VkImageLayout stencilInitialLayout;
VkImageLayout stencilFinalLayout;
} VkAttachmentDescriptionStencilLayout;
or the equivalent
// Provided by VK_KHR_separate_depth_stencil_layouts
typedef VkAttachmentDescriptionStencilLayout VkAttachmentDescriptionStencilLayoutKHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
stencilInitialLayout
is the layout the stencil aspect of the attachment image subresource will be in when a render pass instance begins. -
stencilFinalLayout
is the layout the stencil aspect of the attachment image subresource will be transitioned to when a render pass instance ends.
The VkSubpassDescription2
structure is defined as:
// Provided by VK_VERSION_1_2
typedef struct VkSubpassDescription2 {
VkStructureType sType;
const void* pNext;
VkSubpassDescriptionFlags flags;
VkPipelineBindPoint pipelineBindPoint;
uint32_t viewMask;
uint32_t inputAttachmentCount;
const VkAttachmentReference2* pInputAttachments;
uint32_t colorAttachmentCount;
const VkAttachmentReference2* pColorAttachments;
const VkAttachmentReference2* pResolveAttachments;
const VkAttachmentReference2* pDepthStencilAttachment;
uint32_t preserveAttachmentCount;
const uint32_t* pPreserveAttachments;
} VkSubpassDescription2;
or the equivalent
// Provided by VK_KHR_create_renderpass2
typedef VkSubpassDescription2 VkSubpassDescription2KHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
flags
is a bitmask of VkSubpassDescriptionFlagBits specifying usage of the subpass. -
pipelineBindPoint
is a VkPipelineBindPoint value specifying the pipeline type supported for this subpass. -
viewMask
is a bitfield of view indices describing which views rendering is broadcast to in this subpass, when multiview is enabled. -
inputAttachmentCount
is the number of input attachments. -
pInputAttachments
is a pointer to an array of VkAttachmentReference2 structures defining the input attachments for this subpass and their layouts. -
colorAttachmentCount
is the number of color attachments. -
pColorAttachments
is a pointer to an array of VkAttachmentReference2 structures defining the color attachments for this subpass and their layouts. -
pResolveAttachments
is an optional array ofcolorAttachmentCount
VkAttachmentReference2 structures defining the resolve attachments for this subpass and their layouts. -
pDepthStencilAttachment
is a pointer to a VkAttachmentReference2 structure specifying the depth/stencil attachment for this subpass and its layout. -
preserveAttachmentCount
is the number of preserved attachments. -
pPreserveAttachments
is a pointer to an array ofpreserveAttachmentCount
render pass attachment indices identifying attachments that are not used by this subpass, but whose contents must be preserved throughout the subpass.
Parameters defined by this structure with the same name as those in VkSubpassDescription have the identical effect to those parameters.
viewMask
has the same effect for the described subpass as
VkRenderPassMultiviewCreateInfo::pViewMasks
has on each
corresponding subpass.
If the pNext
list of VkSubpassDescription2
includes a
VkSubpassDescriptionDepthStencilResolve
structure, then that structure
describes multisample resolve operations for the depth/stencil attachment in
a subpass.
The VkSubpassDescriptionDepthStencilResolve
structure is defined as:
// Provided by VK_VERSION_1_2
typedef struct VkSubpassDescriptionDepthStencilResolve {
VkStructureType sType;
const void* pNext;
VkResolveModeFlagBits depthResolveMode;
VkResolveModeFlagBits stencilResolveMode;
const VkAttachmentReference2* pDepthStencilResolveAttachment;
} VkSubpassDescriptionDepthStencilResolve;
or the equivalent
// Provided by VK_KHR_depth_stencil_resolve
typedef VkSubpassDescriptionDepthStencilResolve VkSubpassDescriptionDepthStencilResolveKHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
depthResolveMode
is a bitmask of VkResolveModeFlagBits describing the depth resolve mode. -
stencilResolveMode
is a bitmask of VkResolveModeFlagBits describing the stencil resolve mode. -
pDepthStencilResolveAttachment
is an optional VkAttachmentReference structure defining the depth/stencil resolve attachment for this subpass and its layout.
Possible values of
VkSubpassDescriptionDepthStencilResolve::depthResolveMode
and
stencilResolveMode
, specifying the depth and stencil resolve modes,
are:
// Provided by VK_VERSION_1_2
typedef enum VkResolveModeFlagBits {
VK_RESOLVE_MODE_NONE = 0,
VK_RESOLVE_MODE_SAMPLE_ZERO_BIT = 0x00000001,
VK_RESOLVE_MODE_AVERAGE_BIT = 0x00000002,
VK_RESOLVE_MODE_MIN_BIT = 0x00000004,
VK_RESOLVE_MODE_MAX_BIT = 0x00000008,
// Provided by VK_KHR_depth_stencil_resolve
VK_RESOLVE_MODE_NONE_KHR = VK_RESOLVE_MODE_NONE,
// Provided by VK_KHR_depth_stencil_resolve
VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR = VK_RESOLVE_MODE_SAMPLE_ZERO_BIT,
// Provided by VK_KHR_depth_stencil_resolve
VK_RESOLVE_MODE_AVERAGE_BIT_KHR = VK_RESOLVE_MODE_AVERAGE_BIT,
// Provided by VK_KHR_depth_stencil_resolve
VK_RESOLVE_MODE_MIN_BIT_KHR = VK_RESOLVE_MODE_MIN_BIT,
// Provided by VK_KHR_depth_stencil_resolve
VK_RESOLVE_MODE_MAX_BIT_KHR = VK_RESOLVE_MODE_MAX_BIT,
} VkResolveModeFlagBits;
or the equivalent
// Provided by VK_KHR_depth_stencil_resolve
typedef VkResolveModeFlagBits VkResolveModeFlagBitsKHR;
-
VK_RESOLVE_MODE_NONE
indicates that no resolve operation is done. -
VK_RESOLVE_MODE_SAMPLE_ZERO_BIT
indicates that result of the resolve operation is equal to the value of sample 0. -
VK_RESOLVE_MODE_AVERAGE_BIT
indicates that result of the resolve operation is the average of the sample values. -
VK_RESOLVE_MODE_MIN_BIT
indicates that result of the resolve operation is the minimum of the sample values. -
VK_RESOLVE_MODE_MAX_BIT
indicates that result of the resolve operation is the maximum of the sample values.
// Provided by VK_VERSION_1_2
typedef VkFlags VkResolveModeFlags;
or the equivalent
// Provided by VK_KHR_depth_stencil_resolve
typedef VkResolveModeFlags VkResolveModeFlagsKHR;
VkResolveModeFlags
is a bitmask type for setting a mask of zero or
more VkResolveModeFlagBits.
The VkAttachmentReference2
structure is defined as:
// Provided by VK_VERSION_1_2
typedef struct VkAttachmentReference2 {
VkStructureType sType;
const void* pNext;
uint32_t attachment;
VkImageLayout layout;
VkImageAspectFlags aspectMask;
} VkAttachmentReference2;
or the equivalent
// Provided by VK_KHR_create_renderpass2
typedef VkAttachmentReference2 VkAttachmentReference2KHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
attachment
is either an integer value identifying an attachment at the corresponding index in VkRenderPassCreateInfo::pAttachments
, orVK_ATTACHMENT_UNUSED
to signify that this attachment is not used. -
layout
is a VkImageLayout value specifying the layout the attachment uses during the subpass. -
aspectMask
is a mask of which aspect(s) can be accessed within the specified subpass as an input attachment.
Parameters defined by this structure with the same name as those in VkAttachmentReference have the identical effect to those parameters.
aspectMask
is ignored when this structure is used to describe anything
other than an input attachment reference.
If the separateDepthStencilLayouts
feature is enabled, and attachment
has a depth/stencil format, layout
can be set to a layout that only
specifies the layout of the depth aspect.
If layout
only specifies the layout of the depth aspect of the
attachment, the layout of the stencil aspect is specified by the
stencilLayout
member of a VkAttachmentReferenceStencilLayout
structure included in the pNext
chain.
Otherwise, layout
describes the layout for all relevant image aspects.
The VkAttachmentReferenceStencilLayout
structure is defined as:
// Provided by VK_VERSION_1_2
typedef struct VkAttachmentReferenceStencilLayout {
VkStructureType sType;
void* pNext;
VkImageLayout stencilLayout;
} VkAttachmentReferenceStencilLayout;
or the equivalent
// Provided by VK_KHR_separate_depth_stencil_layouts
typedef VkAttachmentReferenceStencilLayout VkAttachmentReferenceStencilLayoutKHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
stencilLayout
is a VkImageLayout value specifying the layout the stencil aspect of the attachment uses during the subpass.
The VkSubpassDependency2
structure is defined as:
// Provided by VK_VERSION_1_2
typedef struct VkSubpassDependency2 {
VkStructureType sType;
const void* pNext;
uint32_t srcSubpass;
uint32_t dstSubpass;
VkPipelineStageFlags srcStageMask;
VkPipelineStageFlags dstStageMask;
VkAccessFlags srcAccessMask;
VkAccessFlags dstAccessMask;
VkDependencyFlags dependencyFlags;
int32_t viewOffset;
} VkSubpassDependency2;
or the equivalent
// Provided by VK_KHR_create_renderpass2
typedef VkSubpassDependency2 VkSubpassDependency2KHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
srcSubpass
is the subpass index of the first subpass in the dependency, orVK_SUBPASS_EXTERNAL
. -
dstSubpass
is the subpass index of the second subpass in the dependency, orVK_SUBPASS_EXTERNAL
. -
srcStageMask
is a bitmask of VkPipelineStageFlagBits specifying the source stage mask. -
dstStageMask
is a bitmask of VkPipelineStageFlagBits specifying the destination stage mask -
srcAccessMask
is a bitmask of VkAccessFlagBits specifying a source access mask. -
dstAccessMask
is a bitmask of VkAccessFlagBits specifying a destination access mask. -
dependencyFlags
is a bitmask of VkDependencyFlagBits. -
viewOffset
controls which views in the source subpass the views in the destination subpass depend on.
Parameters defined by this structure with the same name as those in VkSubpassDependency have the identical effect to those parameters.
viewOffset
has the same effect for the described subpass dependency as
VkRenderPassMultiviewCreateInfo::pViewOffsets
has on each
corresponding subpass dependency.
To destroy a render pass, call:
// Provided by VK_VERSION_1_0
void vkDestroyRenderPass(
VkDevice device,
VkRenderPass renderPass,
const VkAllocationCallbacks* pAllocator);
-
device
is the logical device that destroys the render pass. -
renderPass
is the handle of the render pass to destroy. -
pAllocator
controls host memory allocation as described in the Memory Allocation chapter.
7.2. Render Pass Compatibility
Framebuffers and graphics pipelines are created based on a specific render pass object. They must only be used with that render pass object, or one compatible with it.
Two attachment references are compatible if they have matching format and
sample count, or are both VK_ATTACHMENT_UNUSED
or the pointer that
would contain the reference is NULL
.
Two arrays of attachment references are compatible if all corresponding
pairs of attachments are compatible.
If the arrays are of different lengths, attachment references not present in
the smaller array are treated as VK_ATTACHMENT_UNUSED
.
Two render passes are compatible if their corresponding color, input, resolve, and depth/stencil attachment references are compatible and if they are otherwise identical except for:
-
Initial and final image layout in attachment descriptions
-
Load and store operations in attachment descriptions
-
Image layout in attachment references
As an additional special case, if two render passes have a single subpass, the resolve attachment reference and depth/stencil resolve mode compatibility requirements are ignored.
A framebuffer is compatible with a render pass if it was created using the same render pass or a compatible render pass.
7.3. Framebuffers
Render passes operate in conjunction with framebuffers. Framebuffers represent a collection of specific memory attachments that a render pass instance uses.
Framebuffers are represented by VkFramebuffer
handles:
// Provided by VK_VERSION_1_0
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkFramebuffer)
To create a framebuffer, call:
// Provided by VK_VERSION_1_0
VkResult vkCreateFramebuffer(
VkDevice device,
const VkFramebufferCreateInfo* pCreateInfo,
const VkAllocationCallbacks* pAllocator,
VkFramebuffer* pFramebuffer);
-
device
is the logical device that creates the framebuffer. -
pCreateInfo
is a pointer to a VkFramebufferCreateInfo structure describing additional information about framebuffer creation. -
pAllocator
controls host memory allocation as described in the Memory Allocation chapter. -
pFramebuffer
is a pointer to a VkFramebuffer handle in which the resulting framebuffer object is returned.
The VkFramebufferCreateInfo
structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkFramebufferCreateInfo {
VkStructureType sType;
const void* pNext;
VkFramebufferCreateFlags flags;
VkRenderPass renderPass;
uint32_t attachmentCount;
const VkImageView* pAttachments;
uint32_t width;
uint32_t height;
uint32_t layers;
} VkFramebufferCreateInfo;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
flags
is a bitmask of VkFramebufferCreateFlagBits -
renderPass
is a render pass defining what render passes the framebuffer will be compatible with. See Render Pass Compatibility for details. -
attachmentCount
is the number of attachments. -
pAttachments
is a pointer to an array of VkImageView handles, each of which will be used as the corresponding attachment in a render pass instance. Ifflags
includesVK_FRAMEBUFFER_CREATE_IMAGELESS_BIT
, this parameter is ignored. -
width
,height
andlayers
define the dimensions of the framebuffer. If the render pass uses multiview, thenlayers
must be one and each attachment requires a number of layers that is greater than the maximum bit index set in the view mask in the subpasses in which it is used.
Applications must ensure that all accesses to memory that backs image subresources used as attachments in a given renderpass instance either happen-before the load operations for those attachments, or happen-after the store operations for those attachments.
For depth/stencil attachments, each aspect can be used separately as
attachments and non-attachments as long as the non-attachment accesses are
also via an image subresource in either the
VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL
layout or
the VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL
layout,
and the attachment resource uses whichever of those two layouts the image
accesses do not.
Use of non-attachment aspects in this case is only well defined if the
attachment is used in the subpass where the non-attachment access is being
made, or the layout of the image subresource is constant throughout the
entire render pass instance, including the initialLayout
and
finalLayout
.
Note
These restrictions mean that the render pass has full knowledge of all uses of all of the attachments, so that the implementation is able to make correct decisions about when and how to perform layout transitions, when to overlap execution of subpasses, etc. |
It is legal for a subpass to use no color or depth/stencil attachments,
either because it has no attachment references or because all of them are
VK_ATTACHMENT_UNUSED
.
This kind of subpass can use shader side effects such as image stores and
atomics to produce an output.
In this case, the subpass continues to use the width
, height
,
and layers
of the framebuffer to define the dimensions of the
rendering area, and the rasterizationSamples
from each pipeline’s
VkPipelineMultisampleStateCreateInfo to define the number of samples
used in rasterization; however, if
VkPhysicalDeviceFeatures::variableMultisampleRate
is
VK_FALSE
, then all pipelines to be bound with the subpass must have
the same value for
VkPipelineMultisampleStateCreateInfo::rasterizationSamples
.
The VkFramebufferAttachmentsCreateInfo
structure is defined as:
// Provided by VK_VERSION_1_2
typedef struct VkFramebufferAttachmentsCreateInfo {
VkStructureType sType;
const void* pNext;
uint32_t attachmentImageInfoCount;
const VkFramebufferAttachmentImageInfo* pAttachmentImageInfos;
} VkFramebufferAttachmentsCreateInfo;
or the equivalent
// Provided by VK_KHR_imageless_framebuffer
typedef VkFramebufferAttachmentsCreateInfo VkFramebufferAttachmentsCreateInfoKHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
attachmentImageInfoCount
is the number of attachments being described. -
pAttachmentImageInfos
is a pointer to an array of VkFramebufferAttachmentImageInfo instances, each of which describes a number of parameters of the corresponding attachment in a render pass instance.
The VkFramebufferAttachmentImageInfo
structure is defined as:
// Provided by VK_VERSION_1_2
typedef struct VkFramebufferAttachmentImageInfo {
VkStructureType sType;
const void* pNext;
VkImageCreateFlags flags;
VkImageUsageFlags usage;
uint32_t width;
uint32_t height;
uint32_t layerCount;
uint32_t viewFormatCount;
const VkFormat* pViewFormats;
} VkFramebufferAttachmentImageInfo;
or the equivalent
// Provided by VK_KHR_imageless_framebuffer
typedef VkFramebufferAttachmentImageInfo VkFramebufferAttachmentImageInfoKHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
flags
is a bitmask of VkImageCreateFlagBits, matching the value of VkImageCreateInfo::flags
used to create an image that will be used with this framebuffer. -
usage
is a bitmask of VkImageUsageFlagBits, matching the value of VkImageCreateInfo::usage
used to create an image used with this framebuffer. -
width
is the width of the image view used for rendering. -
height
is the height of the image view used for rendering. -
viewFormatCount
is the number of entries in thepViewFormats
array, matching the value of VkImageFormatListCreateInfo::viewFormatCount
used to create an image used with this framebuffer. -
pViewFormats
is an array which lists of all formats which can be used when creating views of the image, matching the value of VkImageFormatListCreateInfo::pViewFormats used to create an image used with this framebuffer.
Images that can be used with the framebuffer when beginning a render pass, as specified by VkRenderPassAttachmentBeginInfo, must be created with parameters that are identical to those specified here.
Bits which can be set in VkFramebufferCreateInfo::flags
to
specify options for framebuffers are:
// Provided by VK_VERSION_1_0
typedef enum VkFramebufferCreateFlagBits {
// Provided by VK_VERSION_1_2
VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT = 0x00000001,
// Provided by VK_KHR_imageless_framebuffer
VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT_KHR = VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT,
} VkFramebufferCreateFlagBits;
-
VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT
specifies that image views are not specified, and only attachment compatibility information will be provided via a VkFramebufferAttachmentImageInfo structure.
// Provided by VK_VERSION_1_0
typedef VkFlags VkFramebufferCreateFlags;
VkFramebufferCreateFlags
is a bitmask type for setting a mask of zero
or more VkFramebufferCreateFlagBits.
To destroy a framebuffer, call:
// Provided by VK_VERSION_1_0
void vkDestroyFramebuffer(
VkDevice device,
VkFramebuffer framebuffer,
const VkAllocationCallbacks* pAllocator);
-
device
is the logical device that destroys the framebuffer. -
framebuffer
is the handle of the framebuffer to destroy. -
pAllocator
controls host memory allocation as described in the Memory Allocation chapter.
7.4. Render Pass Commands
An application records the commands for a render pass instance one subpass at a time, by beginning a render pass instance, iterating over the subpasses to record commands for that subpass, and then ending the render pass instance.
To begin a render pass instance, call:
// Provided by VK_VERSION_1_0
void vkCmdBeginRenderPass(
VkCommandBuffer commandBuffer,
const VkRenderPassBeginInfo* pRenderPassBegin,
VkSubpassContents contents);
-
commandBuffer
is the command buffer in which to record the command. -
pRenderPassBegin
is a pointer to a VkRenderPassBeginInfo structure specifying the render pass to begin an instance of, and the framebuffer the instance uses. -
contents
is a VkSubpassContents value specifying how the commands in the first subpass will be provided.
After beginning a render pass instance, the command buffer is ready to record the commands for the first subpass of that render pass.
Alternatively to begin a render pass, call:
// Provided by VK_VERSION_1_2
void vkCmdBeginRenderPass2(
VkCommandBuffer commandBuffer,
const VkRenderPassBeginInfo* pRenderPassBegin,
const VkSubpassBeginInfo* pSubpassBeginInfo);
or the equivalent command
// Provided by VK_KHR_create_renderpass2
void vkCmdBeginRenderPass2KHR(
VkCommandBuffer commandBuffer,
const VkRenderPassBeginInfo* pRenderPassBegin,
const VkSubpassBeginInfo* pSubpassBeginInfo);
-
commandBuffer
is the command buffer in which to record the command. -
pRenderPassBegin
is a pointer to a VkRenderPassBeginInfo structure specifying the render pass to begin an instance of, and the framebuffer the instance uses. -
pSubpassBeginInfo
is a pointer to a VkSubpassBeginInfo structure containing information about the subpass which is about to begin rendering.
After beginning a render pass instance, the command buffer is ready to record the commands for the first subpass of that render pass.
The VkRenderPassBeginInfo
structure is defined as:
// Provided by VK_VERSION_1_0
typedef struct VkRenderPassBeginInfo {
VkStructureType sType;
const void* pNext;
VkRenderPass renderPass;
VkFramebuffer framebuffer;
VkRect2D renderArea;
uint32_t clearValueCount;
const VkClearValue* pClearValues;
} VkRenderPassBeginInfo;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
renderPass
is the render pass to begin an instance of. -
framebuffer
is the framebuffer containing the attachments that are used with the render pass. -
renderArea
is the render area that is affected by the render pass instance, and is described in more detail below. -
clearValueCount
is the number of elements inpClearValues
. -
pClearValues
is a pointer to an array ofclearValueCount
VkClearValue structures that contains clear values for each attachment, if the attachment uses aloadOp
value ofVK_ATTACHMENT_LOAD_OP_CLEAR
or if the attachment has a depth/stencil format and uses astencilLoadOp
value ofVK_ATTACHMENT_LOAD_OP_CLEAR
. The array is indexed by attachment number. Only elements corresponding to cleared attachments are used. Other elements ofpClearValues
are ignored.
renderArea
is the render area that is affected by the render pass
instance.
The effects of attachment load, store and multisample resolve operations are
restricted to the pixels whose x and y coordinates fall within the render
area on all attachments.
The render area extends to all layers of framebuffer
.
The application must ensure (using scissor if necessary) that all rendering
is contained within the render area.
The render area, after any transform specified by
VkRenderPassTransformBeginInfoQCOM::transform
is applied, must
be contained within the framebuffer dimensions.
If render pass transform is
enabled, then renderArea
must equal the framebuffer pre-transformed
dimensions.
After renderArea
has been transformed by
VkRenderPassTransformBeginInfoQCOM::transform
, the resulting
render area must be equal to the framebuffer dimensions.
When multiview is enabled, the resolve operation at the end of a subpass applies to all views in the view mask.
Note
There may be a performance cost for using a render area smaller than the framebuffer, unless it matches the render area granularity for the render pass. |
The image layout of the depth aspect of a depth/stencil attachment referring
to an image created with
VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT
is dependent
on the last sample locations used to render to the image subresource, thus
preserving the contents of such depth/stencil attachments across subpass
boundaries requires the application to specify these sample locations
whenever a layout transition of the attachment may occur.
This information can be provided by adding a
VkRenderPassSampleLocationsBeginInfoEXT
structure to the pNext
chain of VkRenderPassBeginInfo
.
The VkRenderPassSampleLocationsBeginInfoEXT
structure is defined as:
// Provided by VK_EXT_sample_locations
typedef struct VkRenderPassSampleLocationsBeginInfoEXT {
VkStructureType sType;
const void* pNext;
uint32_t attachmentInitialSampleLocationsCount;
const VkAttachmentSampleLocationsEXT* pAttachmentInitialSampleLocations;
uint32_t postSubpassSampleLocationsCount;
const VkSubpassSampleLocationsEXT* pPostSubpassSampleLocations;
} VkRenderPassSampleLocationsBeginInfoEXT;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
attachmentInitialSampleLocationsCount
is the number of elements in thepAttachmentInitialSampleLocations
array. -
pAttachmentInitialSampleLocations
is a pointer to an array ofattachmentInitialSampleLocationsCount
VkAttachmentSampleLocationsEXT structures specifying the attachment indices and their corresponding sample location state. Each element ofpAttachmentInitialSampleLocations
can specify the sample location state to use in the automatic layout transition performed to transition a depth/stencil attachment from the initial layout of the attachment to the image layout specified for the attachment in the first subpass using it. -
postSubpassSampleLocationsCount
is the number of elements in thepPostSubpassSampleLocations
array. -
pPostSubpassSampleLocations
is a pointer to an array ofpostSubpassSampleLocationsCount
VkSubpassSampleLocationsEXT structures specifying the subpass indices and their corresponding sample location state. Each element ofpPostSubpassSampleLocations
can specify the sample location state to use in the automatic layout transition performed to transition the depth/stencil attachment used by the specified subpass to the image layout specified in a dependent subpass or to the final layout of the attachment in case the specified subpass is the last subpass using that attachment. In addition, if VkPhysicalDeviceSampleLocationsPropertiesEXT::variableSampleLocations
isVK_FALSE
, each element ofpPostSubpassSampleLocations
must specify the sample location state that matches the sample locations used by all pipelines that will be bound to a command buffer during the specified subpass. IfvariableSampleLocations
isVK_TRUE
, the sample locations used for rasterization do not depend onpPostSubpassSampleLocations
.
The VkAttachmentSampleLocationsEXT
structure is defined as:
// Provided by VK_EXT_sample_locations
typedef struct VkAttachmentSampleLocationsEXT {
uint32_t attachmentIndex;
VkSampleLocationsInfoEXT sampleLocationsInfo;
} VkAttachmentSampleLocationsEXT;
-
attachmentIndex
is the index of the attachment for which the sample locations state is provided. -
sampleLocationsInfo
is the sample locations state to use for the layout transition of the given attachment from the initial layout of the attachment to the image layout specified for the attachment in the first subpass using it.
If the image referenced by the framebuffer attachment at index
attachmentIndex
was not created with
VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT
then the
values specified in sampleLocationsInfo
are ignored.
The VkSubpassSampleLocationsEXT
structure is defined as:
// Provided by VK_EXT_sample_locations
typedef struct VkSubpassSampleLocationsEXT {
uint32_t subpassIndex;
VkSampleLocationsInfoEXT sampleLocationsInfo;
} VkSubpassSampleLocationsEXT;
-
subpassIndex
is the index of the subpass for which the sample locations state is provided. -
sampleLocationsInfo
is the sample locations state to use for the layout transition of the depth/stencil attachment away from the image layout the attachment is used with in the subpass specified insubpassIndex
.
If the image referenced by the depth/stencil attachment used in the subpass
identified by subpassIndex
was not created with
VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT
or if the
subpass does not use a depth/stencil attachment, and
VkPhysicalDeviceSampleLocationsPropertiesEXT::variableSampleLocations
is VK_TRUE
then the values specified in sampleLocationsInfo
are
ignored.
To begin a renderpass instance with render pass transform enabled, add the
VkRenderPassTransformBeginInfoQCOM to the pNext
chain of
VkRenderPassBeginInfo structure passed to the
vkCmdBeginRenderPass command specifying the renderpass transform.
The VkRenderPassTransformBeginInfoQCOM
structure is defined as:
// Provided by VK_QCOM_render_pass_transform
typedef struct VkRenderPassTransformBeginInfoQCOM {
VkStructureType sType;
void* pNext;
VkSurfaceTransformFlagBitsKHR transform;
} VkRenderPassTransformBeginInfoQCOM;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
transform
is a VkSurfaceTransformFlagBitsKHR value describing the transform to be applied to rasterization.
The VkSubpassBeginInfo
structure is defined as:
// Provided by VK_VERSION_1_2
typedef struct VkSubpassBeginInfo {
VkStructureType sType;
const void* pNext;
VkSubpassContents contents;
} VkSubpassBeginInfo;
or the equivalent
// Provided by VK_KHR_create_renderpass2
typedef VkSubpassBeginInfo VkSubpassBeginInfoKHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
contents
is a VkSubpassContents value specifying how the commands in the next subpass will be provided.
Possible values of vkCmdBeginRenderPass::contents
, specifying
how the commands in the first subpass will be provided, are:
// Provided by VK_VERSION_1_0
typedef enum VkSubpassContents {
VK_SUBPASS_CONTENTS_INLINE = 0,
VK_SUBPASS_CONTENTS_SECONDARY_COMMAND_BUFFERS = 1,
} VkSubpassContents;
-
VK_SUBPASS_CONTENTS_INLINE
specifies that the contents of the subpass will be recorded inline in the primary command buffer, and secondary command buffers must not be executed within the subpass. -
VK_SUBPASS_CONTENTS_SECONDARY_COMMAND_BUFFERS
specifies that the contents are recorded in secondary command buffers that will be called from the primary command buffer, and vkCmdExecuteCommands is the only valid command on the command buffer until vkCmdNextSubpass or vkCmdEndRenderPass.
If the pNext
chain of VkRenderPassBeginInfo includes a
VkDeviceGroupRenderPassBeginInfo
structure, then that structure
includes a device mask and set of render areas for the render pass instance.
The VkDeviceGroupRenderPassBeginInfo
structure is defined as:
// Provided by VK_VERSION_1_1
typedef struct VkDeviceGroupRenderPassBeginInfo {
VkStructureType sType;
const void* pNext;
uint32_t deviceMask;
uint32_t deviceRenderAreaCount;
const VkRect2D* pDeviceRenderAreas;
} VkDeviceGroupRenderPassBeginInfo;
or the equivalent
// Provided by VK_KHR_device_group
typedef VkDeviceGroupRenderPassBeginInfo VkDeviceGroupRenderPassBeginInfoKHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
deviceMask
is the device mask for the render pass instance. -
deviceRenderAreaCount
is the number of elements in thepDeviceRenderAreas
array. -
pDeviceRenderAreas
is a pointer to an array of VkRect2D structures defining the render area for each physical device.
The deviceMask
serves several purposes.
It is an upper bound on the set of physical devices that can be used during
the render pass instance, and the initial device mask when the render pass
instance begins.
In addition, commands transitioning to the next subpass in the render pass
instance and commands ending the render pass instance, and, accordingly
render pass attachment load, store, and resolve operations and subpass
dependencies corresponding to the render pass instance, are executed on the
physical devices included in the device mask provided here.
If deviceRenderAreaCount
is not zero, then the elements of
pDeviceRenderAreas
override the value of
VkRenderPassBeginInfo::renderArea
, and provide a render area
specific to each physical device.
These render areas serve the same purpose as
VkRenderPassBeginInfo::renderArea
, including controlling the
region of attachments that are cleared by VK_ATTACHMENT_LOAD_OP_CLEAR
and that are resolved into resolve attachments.
If this structure is not present, the render pass instance’s device mask is
the value of VkDeviceGroupCommandBufferBeginInfo::deviceMask
.
If this structure is not present or if deviceRenderAreaCount
is zero,
VkRenderPassBeginInfo::renderArea
is used for all physical
devices.
The VkRenderPassAttachmentBeginInfo
structure is defined as:
// Provided by VK_VERSION_1_2
typedef struct VkRenderPassAttachmentBeginInfo {
VkStructureType sType;
const void* pNext;
uint32_t attachmentCount;
const VkImageView* pAttachments;
} VkRenderPassAttachmentBeginInfo;
or the equivalent
// Provided by VK_KHR_imageless_framebuffer
typedef VkRenderPassAttachmentBeginInfo VkRenderPassAttachmentBeginInfoKHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure. -
attachmentCount
is the number of attachments. -
pAttachments
is a pointer to an array ofVkImageView
handles, each of which will be used as the corresponding attachment in the render pass instance.
To query the render area granularity, call:
// Provided by VK_VERSION_1_0
void vkGetRenderAreaGranularity(
VkDevice device,
VkRenderPass renderPass,
VkExtent2D* pGranularity);
-
device
is the logical device that owns the render pass. -
renderPass
is a handle to a render pass. -
pGranularity
is a pointer to a VkExtent2D structure in which the granularity is returned.
The conditions leading to an optimal renderArea
are:
-
the
offset.x
member inrenderArea
is a multiple of thewidth
member of the returned VkExtent2D (the horizontal granularity). -
the
offset.y
member inrenderArea
is a multiple of theheight
of the returned VkExtent2D (the vertical granularity). -
either the
offset.width
member inrenderArea
is a multiple of the horizontal granularity oroffset.x
+offset.width
is equal to thewidth
of theframebuffer
in the VkRenderPassBeginInfo. -
either the
offset.height
member inrenderArea
is a multiple of the vertical granularity oroffset.y
+offset.height
is equal to theheight
of theframebuffer
in the VkRenderPassBeginInfo.
Subpass dependencies are not affected by the render area, and apply to the entire image subresources attached to the framebuffer as specified in the description of automatic layout transitions. Similarly, pipeline barriers are valid even if their effect extends outside the render area.
To transition to the next subpass in the render pass instance after recording the commands for a subpass, call:
// Provided by VK_VERSION_1_0
void vkCmdNextSubpass(
VkCommandBuffer commandBuffer,
VkSubpassContents contents);
-
commandBuffer
is the command buffer in which to record the command. -
contents
specifies how the commands in the next subpass will be provided, in the same fashion as the corresponding parameter of vkCmdBeginRenderPass.
The subpass index for a render pass begins at zero when
vkCmdBeginRenderPass
is recorded, and increments each time
vkCmdNextSubpass
is recorded.
Moving to the next subpass automatically performs any multisample resolve
operations in the subpass being ended.
End-of-subpass multisample resolves are treated as color attachment writes
for the purposes of synchronization.
This applies to resolve operations for both color and depth/stencil
attachments.
That is, they are considered to execute in the
VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT
pipeline stage and their
writes are synchronized with VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT
.
Synchronization between rendering within a subpass and any resolve
operations at the end of the subpass occurs automatically, without need for
explicit dependencies or pipeline barriers.
However, if the resolve attachment is also used in a different subpass, an
explicit dependency is needed.
After transitioning to the next subpass, the application can record the commands for that subpass.
To transition to the next subpass in the render pass instance after recording the commands for a subpass, call:
// Provided by VK_VERSION_1_2
void vkCmdNextSubpass2(
VkCommandBuffer commandBuffer,
const VkSubpassBeginInfo* pSubpassBeginInfo,
const VkSubpassEndInfo* pSubpassEndInfo);
or the equivalent command
// Provided by VK_KHR_create_renderpass2
void vkCmdNextSubpass2KHR(
VkCommandBuffer commandBuffer,
const VkSubpassBeginInfo* pSubpassBeginInfo,
const VkSubpassEndInfo* pSubpassEndInfo);
-
commandBuffer
is the command buffer in which to record the command. -
pSubpassBeginInfo
is a pointer to a VkSubpassBeginInfo structure containing information about the subpass which is about to begin rendering. -
pSubpassEndInfo
is a pointer to a VkSubpassEndInfo structure containing information about how the previous subpass will be ended.
vkCmdNextSubpass2
is semantically identical to vkCmdNextSubpass,
except that it is extensible, and that contents
is provided as part of
an extensible structure instead of as a flat parameter.
To record a command to end a render pass instance after recording the commands for the last subpass, call:
// Provided by VK_VERSION_1_0
void vkCmdEndRenderPass(
VkCommandBuffer commandBuffer);
-
commandBuffer
is the command buffer in which to end the current render pass instance.
Ending a render pass instance performs any multisample resolve operations on the final subpass.
To record a command to end a render pass instance after recording the commands for the last subpass, call:
// Provided by VK_VERSION_1_2
void vkCmdEndRenderPass2(
VkCommandBuffer commandBuffer,
const VkSubpassEndInfo* pSubpassEndInfo);
or the equivalent command
// Provided by VK_KHR_create_renderpass2
void vkCmdEndRenderPass2KHR(
VkCommandBuffer commandBuffer,
const VkSubpassEndInfo* pSubpassEndInfo);
-
commandBuffer
is the command buffer in which to end the current render pass instance. -
pSubpassEndInfo
is a pointer to a VkSubpassEndInfo structure containing information about how the previous subpass will be ended.
vkCmdEndRenderPass2
is semantically identical to
vkCmdEndRenderPass, except that it is extensible.
The VkSubpassEndInfo
structure is defined as:
// Provided by VK_VERSION_1_2
typedef struct VkSubpassEndInfo {
VkStructureType sType;
const void* pNext;
} VkSubpassEndInfo;
or the equivalent
// Provided by VK_KHR_create_renderpass2
typedef VkSubpassEndInfo VkSubpassEndInfoKHR;
-
sType
is the type of this structure. -
pNext
isNULL
or a pointer to a structure extending this structure.