C Specification
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;Members
-
sTypeis the type of this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
flagsis a bitmask of VkFramebufferCreateFlagBits -
renderPassis a render pass defining what render passes the framebuffer will be compatible with. See Render Pass Compatibility for details. -
attachmentCountis the number of attachments. -
pAttachmentsis a pointer to an array of VkImageView handles, each of which will be used as the corresponding attachment in a render pass instance. IfflagsincludesVK_FRAMEBUFFER_CREATE_IMAGELESS_BIT, this parameter is ignored. -
width,heightandlayersdefine the dimensions of the framebuffer. If the render pass uses multiview, thenlayersmust 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.
Description
Other than the exceptions listed below, 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.
The exceptions to the general rule are:
-
For depth/stencil attachments, an aspect can be used separately as attachment and non-attachment if both accesses are read-only.
-
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_OPTIMALlayout or theVK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMALlayout, and the attachment resource uses whichever of those two layouts the image accesses do not.
Use of non-attachment aspects in these cases 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.
Document Notes
For more information, see the Vulkan Specification
This page is extracted from the Vulkan Specification. Fixes and changes should be made to the Specification, not directly.