VkAttachmentLoadOp - Specify how contents of an attachment are treated at the beginning of a subpass

See Also

VkAttachmentDescription

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 type VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT. For attachments with a color format, this uses the access type VK_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 type VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT. For attachments with a color format, this uses the access type VK_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 type VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT. For attachments with a color format, this uses the access type VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT.

VkAttachmentStoreOp - Specify how contents of an attachment are treated at the end of a subpass

See Also

VkAttachmentDescription

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 type VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT. For attachments with a color format, this uses the access type VK_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 type VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT. For attachments with a color format, this uses the access type VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT.

VkPipelineBindPoint - Specify the bind point of a pipeline object to a command buffer

See Also

VkDescriptorUpdateTemplateCreateInfo, VkIndirectCommandsLayoutCreateInfoNVX, VkSubpassDescription, vkCmdBindDescriptorSets, vkCmdBindPipeline, vkCmdPushDescriptorSetKHR

VK_PIPELINE_BIND_POINT_GRAPHICS specifies binding as a graphics pipeline.

VK_PIPELINE_BIND_POINT_COMPUTE specifies binding as a compute pipeline.

VkFramebufferCreateFlags - Reserved for future use

Description

VkFramebufferCreateFlags is a bitmask type for setting a mask, but is currently reserved for future use.

See Also

VkFramebufferCreateInfo

VkRenderPassCreateFlags - Reserved for future use

Description

VkRenderPassCreateFlags is a bitmask type for setting a mask, but is currently reserved for future use.

See Also

VkRenderPassCreateInfo

VkAccessFlagBits - Bitmask specifying memory access types that will participate in a memory dependency

Description

• VK_ACCESS_INDIRECT_COMMAND_READ_BIT specifies read access to an indirect command structure read as part of an indirect drawing or dispatch command.

• VK_ACCESS_INDEX_READ_BIT specifies read access to an index buffer as part of an indexed drawing command, bound by vkCmdBindIndexBuffer.
• VK_ACCESS_VERTEX_ATTRIBUTE_READ_BIT specifies read access to a vertex buffer as part of a drawing command, bound by vkCmdBindVertexBuffers.
• VK_ACCESS_UNIFORM_READ_BIT specifies read access to a uniform buffer.
• VK_ACCESS_INPUT_ATTACHMENT_READ_BIT specifies read access to an input attachment within a render pass during fragment shading.
• VK_ACCESS_SHADER_READ_BIT specifies read access to a storage buffer, uniform texel buffer, storage texel buffer, sampled image, or storage image.
• VK_ACCESS_SHADER_WRITE_BIT specifies write access to a storage buffer, storage texel buffer, or storage image.
• VK_ACCESS_COLOR_ATTACHMENT_READ_BIT specifies read access to a color attachment, such as via blending, logic operations, or via certain subpass load operations. It does not include advanced blend operations.
• VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT is similar to VK_ACCESS_COLOR_ATTACHMENT_READ_BIT, but also includes advanced blend operations.
• VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT specifies write access to a color or resolve attachment during a render pass or via certain subpass load and store operations.
• VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT specifies read access to a depth/stencil attachment, via depth or stencil operations or via certain subpass load operations.
• VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT specifies write access to a depth/stencil attachment, via depth or stencil operations or via certain subpass load and store operations.
• VK_ACCESS_TRANSFER_READ_BIT specifies read access to an image or buffer in a copy operation.
• VK_ACCESS_TRANSFER_WRITE_BIT specifies write access to an image or buffer in a clear or copy operation.
• VK_ACCESS_HOST_READ_BIT specifies read access by a host operation. Accesses of this type are not performed through a resource, but directly on memory.
• VK_ACCESS_HOST_WRITE_BIT specifies write access by a host operation. Accesses of this type are not performed through a resource, but directly on memory.
• VK_ACCESS_MEMORY_READ_BIT specifies read access via non-specific entities. These entities include the Vulkan device and host, but may also include entities external to the Vulkan device or otherwise not part of the core Vulkan pipeline. When included in a destination access mask, makes all available writes visible to all future read accesses on entities known to the Vulkan device.
• VK_ACCESS_MEMORY_WRITE_BIT specifies write access via non-specific entities. These entities include the Vulkan device and host, but may also include entities external to the Vulkan device or otherwise not part of the core Vulkan pipeline. When included in a source access mask, all writes that are performed by entities known to the Vulkan device are made available. When included in a destination access mask, makes all available writes visible to all future write accesses on entities known to the Vulkan device.
• VK_ACCESS_COMMAND_PROCESS_READ_BIT_NVX specifies reads from VkBuffer inputs to vkCmdProcessCommandsNVX.
• VK_ACCESS_COMMAND_PROCESS_WRITE_BIT_NVX specifies writes to the target command buffer in vkCmdProcessCommandsNVX.

Certain access types are only performed by a subset of pipeline stages. Any synchronization command that takes both stage masks and access masks uses both to define the access scopes - only the specified access types performed by the specified stages are included in the access scope. An application must not specify an access flag in a synchronization command if it does not include a pipeline stage in the corresponding stage mask that is able to perform accesses of that type. The following table lists, for each access flag, which pipeline stages can perform that type of access.

Supported access types

If a memory object does not have the VK_MEMORY_PROPERTY_HOST_COHERENT_BIT property, then vkFlushMappedMemoryRanges must be called in order to guarantee that writes to the memory object from the host are made visible to the VK_ACCESS_HOST_WRITE_BIT access type, where it can be further made available to the device by synchronization commands. Similarly, vkInvalidateMappedMemoryRanges must be called to guarantee that writes which are visible to the VK_ACCESS_HOST_READ_BIT access type are made visible to host operations.

If the memory object does have the VK_MEMORY_PROPERTY_HOST_COHERENT_BIT property flag, writes to the memory object from the host are automatically made visible to the VK_ACCESS_HOST_WRITE_BIT access type. Similarly, writes made visible to the VK_ACCESS_HOST_READ_BIT access type are automatically made visible to the host.

Note

The vkQueueSubmit command automatically guarantees that host writes flushed to @VK_ACCESS_HOST_WRITE_BIT@ are made available if they were flushed before the command executed, so in most cases an explicit memory barrier is not needed for this case. In the few circumstances where a submit does not occur between the host write and the device read access, writes can be made available by using an explicit memory barrier.

See Also

VkAccessFlags

VkSubpassDescriptionFlagBits - Bitmask specifying usage of a subpass

See Also

VkSubpassDescriptionFlags

VkAttachmentDescriptionFlagBits - Bitmask specifying additional properties of an attachment

See Also

VkAttachmentDescriptionFlags

VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT specifies that the attachment aliases the same device memory as other attachments.

VkDependencyFlagBits - Bitmask specifying how execution and memory dependencies are formed

See Also

VkDependencyFlags

VK_DEPENDENCY_BY_REGION_BIT specifies that dependencies will be framebuffer-local.

VkFramebuffer - Opaque handle to a framebuffer object

See Also

VkCommandBufferInheritanceInfo, VkRenderPassBeginInfo, vkCreateFramebuffer, vkDestroyFramebuffer

vkCreateFramebuffer - Create a new framebuffer object

Parameters

• device is the logical device that creates the framebuffer.

• pCreateInfo points to a VkFramebufferCreateInfo structure which describes additional information about framebuffer creation.
• pAllocator controls host memory allocation as described in the Memory Allocation chapter.
• pFramebuffer points to a VkFramebuffer handle in which the resulting framebuffer object is returned.

Valid Usage (Implicit)

• device must be a valid VkDevice handle

• pCreateInfo must be a valid pointer to a valid VkFramebufferCreateInfo structure
• If pAllocator is not NULL, pAllocator must be a valid pointer to a valid VkAllocationCallbacks structure
• pFramebuffer must be a valid pointer to a VkFramebuffer handle

Return Codes

[Success] - VK_SUCCESS

[Failure] - VK_ERROR_OUT_OF_HOST_MEMORY

• VK_ERROR_OUT_OF_DEVICE_MEMORY

See Also

VkAllocationCallbacks, VkDevice, VkFramebuffer, VkFramebufferCreateInfo

vkDestroyFramebuffer - Destroy a framebuffer object

Parameters

• 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.

Valid Usage

• All submitted commands that refer to framebuffer must have completed execution

• If VkAllocationCallbacks were provided when framebuffer was created, a compatible set of callbacks must be provided here
• If no VkAllocationCallbacks were provided when framebuffer was created, pAllocator must be NULL

Valid Usage (Implicit)

• device must be a valid VkDevice handle

• If framebuffer is not VK_NULL_HANDLE, framebuffer must be a valid VkFramebuffer handle
• If pAllocator is not NULL, pAllocator must be a valid pointer to a valid VkAllocationCallbacks structure
• If framebuffer is a valid handle, it must have been created, allocated, or retrieved from device

Host Synchronization

• Host access to framebuffer must be externally synchronized

See Also

VkAllocationCallbacks, VkDevice, VkFramebuffer

vkCreateRenderPass - Create a new render pass object

Parameters

• device is the logical device that creates the render pass.

• pCreateInfo is a pointer to an instance of the VkRenderPassCreateInfo structure that describes the parameters of the render pass.
• pAllocator controls host memory allocation as described in the Memory Allocation chapter.
• pRenderPass points to a VkRenderPass handle in which the resulting render pass object is returned.

Valid Usage (Implicit)

• device must be a valid VkDevice handle

• pCreateInfo must be a valid pointer to a valid VkRenderPassCreateInfo structure
• If pAllocator is not NULL, pAllocator must be a valid pointer to a valid VkAllocationCallbacks structure
• pRenderPass must be a valid pointer to a VkRenderPass handle

Return Codes

[Success] - VK_SUCCESS

[Failure] - VK_ERROR_OUT_OF_HOST_MEMORY

• VK_ERROR_OUT_OF_DEVICE_MEMORY

See Also

VkAllocationCallbacks, VkDevice, VkRenderPass, VkRenderPassCreateInfo

vkDestroyRenderPass - Destroy a render pass object

Parameters

• 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.

Valid Usage

• All submitted commands that refer to renderPass must have completed execution

• If VkAllocationCallbacks were provided when renderPass was created, a compatible set of callbacks must be provided here
• If no VkAllocationCallbacks were provided when renderPass was created, pAllocator must be NULL

Valid Usage (Implicit)

• device must be a valid VkDevice handle

• If renderPass is not VK_NULL_HANDLE, renderPass must be a valid VkRenderPass handle
• If pAllocator is not NULL, pAllocator must be a valid pointer to a valid VkAllocationCallbacks structure
• If renderPass is a valid handle, it must have been created, allocated, or retrieved from device

Host Synchronization

• Host access to renderPass must be externally synchronized

See Also

VkAllocationCallbacks, VkDevice, VkRenderPass

vkGetRenderAreaGranularity - Returns the granularity for optimal render area

Parameters

• device is the logical device that owns the render pass.

• renderPass is a handle to a render pass.
• pGranularity points to a VkExtent2D structure in which the granularity is returned.

Description

The conditions leading to an optimal renderArea are:

• the offset.x member in renderArea is a multiple of the width member of the returned VkExtent2D (the horizontal granularity).
• the offset.y member in renderArea is a multiple of the height of the returned VkExtent2D (the vertical granularity).
• either the offset.width member in renderArea is a multiple of the horizontal granularity or offset.x+offset.width is equal to the width of the framebuffer in the VkRenderPassBeginInfo.
• either the offset.height member in renderArea is a multiple of the vertical granularity or offset.y+offset.height is equal to the height of the framebuffer 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.

Valid Usage (Implicit)

• device must be a valid VkDevice handle

• renderPass must be a valid VkRenderPass handle
• pGranularity must be a valid pointer to a VkExtent2D structure
• renderPass must have been created, allocated, or retrieved from device

See Also

VkDevice, VkExtent2D, VkRenderPass

VkAttachmentDescription - Structure specifying an attachment description

Description

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.

Valid Usage

• finalLayout must not be VK_IMAGE_LAYOUT_UNDEFINED or VK_IMAGE_LAYOUT_PREINITIALIZED

Valid Usage (Implicit)

• flags must be a valid combination of VkAttachmentDescriptionFlagBits values

• format must be a valid VkFormat value
• samples must be a valid VkSampleCountFlagBits value
• loadOp must be a valid VkAttachmentLoadOp value
• storeOp must be a valid VkAttachmentStoreOp value
• stencilLoadOp must be a valid VkAttachmentLoadOp value
• stencilStoreOp must be a valid VkAttachmentStoreOp value
• initialLayout must be a valid VkImageLayout value
• finalLayout must be a valid VkImageLayout value

See Also

VkAttachmentDescriptionFlags, VkAttachmentLoadOp, VkAttachmentStoreOp, VkFormat, VkImageLayout, VkRenderPassCreateInfo, VkSampleCountFlagBits

VkAttachmentReference - Structure specifying an attachment reference

Valid Usage

• layout must not be VK_IMAGE_LAYOUT_UNDEFINED or VK_IMAGE_LAYOUT_PREINITIALIZED

Valid Usage (Implicit)

• layout must be a valid VkImageLayout value

See Also

VkImageLayout, VkSubpassDescription

VkSubpassDescription - Structure specifying a subpass description

Description

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.

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.

Valid Usage

• pipelineBindPoint must be VK_PIPELINE_BIND_POINT_GRAPHICS

• colorAttachmentCount must be less than or equal to VkPhysicalDeviceLimits::maxColorAttachments
• If the first use of an attachment in this render pass is as an input attachment, and the attachment is not also used as a color or depth/stencil attachment in the same subpass, then loadOp must not be VK_ATTACHMENT_LOAD_OP_CLEAR
• If pResolveAttachments is not NULL, for each resolve attachment that does not have the value VK_ATTACHMENT_UNUSED, the corresponding color attachment must not have the value VK_ATTACHMENT_UNUSED
• If pResolveAttachments is not NULL, the sample count of each element of pColorAttachments must be anything other than VK_SAMPLE_COUNT_1_BIT
• Each element of pResolveAttachments must have a sample count of VK_SAMPLE_COUNT_1_BIT
• Each element of pResolveAttachments must have the same VkFormat as its corresponding color attachment
• All attachments in pColorAttachments that are not VK_ATTACHMENT_UNUSED must have the same sample count
• All attachments in pColorAttachments that are not VK_ATTACHMENT_UNUSED must have a sample count that is smaller than or equal to the sample count of pDepthStencilAttachment if it is not VK_ATTACHMENT_UNUSED
• If any input attachments are VK_ATTACHMENT_UNUSED, then any pipelines bound during the subpass must not access those input attachments from the fragment shader
• The attachment member of each element of pPreserveAttachments must not be VK_ATTACHMENT_UNUSED
• Each element of pPreserveAttachments must not also be an element of any other member of the subpass description
• If any attachment is used as both an input attachment and a color or depth/stencil attachment, then each use must use the same layout
• If flags includes VK_SUBPASS_DESCRIPTION_PER_VIEW_POSITION_X_ONLY_BIT_NVX, it must also include VK_SUBPASS_DESCRIPTION_PER_VIEW_ATTRIBUTES_BIT_NVX.

Valid Usage (Implicit)

• flags must be a valid combination of VkSubpassDescriptionFlagBits values

• pipelineBindPoint must be a valid VkPipelineBindPoint value
• If inputAttachmentCount is not 0, pInputAttachments must be a valid pointer to an array of inputAttachmentCount valid VkAttachmentReference structures
• If colorAttachmentCount is not 0, pColorAttachments must be a valid pointer to an array of colorAttachmentCount valid VkAttachmentReference structures
• If colorAttachmentCount is not 0, and pResolveAttachments is not NULL, pResolveAttachments must be a valid pointer to an array of colorAttachmentCount valid VkAttachmentReference structures
• If pDepthStencilAttachment is not NULL, pDepthStencilAttachment must be a valid pointer to a valid VkAttachmentReference structure
• If preserveAttachmentCount is not 0, pPreserveAttachments must be a valid pointer to an array of preserveAttachmentCount uint32_t values

See Also

VkAttachmentReference, VkPipelineBindPoint, VkRenderPassCreateInfo, VkSubpassDescriptionFlags

VkSubpassDependency - Structure specifying a subpass dependency

Description

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 srcAccessMask/dstAccessMask parameters) submitted as a part of a vkCmdPipelineBarrier (with matching srcStageMask/dstStageMask parameters). The only difference being that its scopes are limited to the identified subpasses rather than potentially affecting everything before and after.

For attachments however, subpass dependencies work more like an VkImageMemoryBarrier defined similarly to the VkMemoryBarrier above, the queue family indices set to VK_QUEUE_FAMILY_IGNORED, and layouts as follows:

• The equivalent to oldLayout is the attachment’s layout according to the subpass description for srcSubpass.
• The equivalent to newLayout is the attachment’s layout according to the subpass description for dstSubpass.

Valid Usage

• If srcSubpass is not VK_SUBPASS_EXTERNAL, srcStageMask must not include VK_PIPELINE_STAGE_HOST_BIT

• If dstSubpass is not VK_SUBPASS_EXTERNAL, dstStageMask must not include VK_PIPELINE_STAGE_HOST_BIT
• If the geometry shaders feature is not enabled, srcStageMask must not contain VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT
• If the geometry shaders feature is not enabled, dstStageMask must not contain VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT
• If the tessellation shaders feature is not enabled, srcStageMask must not contain VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT or VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_BIT
• If the tessellation shaders feature is not enabled, dstStageMask must not contain VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT or VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_BIT
• srcSubpass must be less than or equal to dstSubpass, unless one of them is VK_SUBPASS_EXTERNAL, to avoid cyclic dependencies and ensure a valid execution order
• srcSubpass and dstSubpass must not both be equal to VK_SUBPASS_EXTERNAL
• If srcSubpass is equal to dstSubpass, srcStageMask and dstStageMask must only contain one of VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT, VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT, VK_PIPELINE_STAGE_VERTEX_INPUT_BIT, VK_PIPELINE_STAGE_VERTEX_SHADER_BIT, VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT, VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_BIT, VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT, VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT, VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT, VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT, or VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT
• If srcSubpass is equal to dstSubpass and not all of the stages in srcStageMask and dstStageMask are framebuffer-space stages, the logically latest pipeline stage in srcStageMask must be logically earlier than or equal to the logically earliest pipeline stage in dstStageMask
• Any access flag included in srcAccessMask must be supported by one of the pipeline stages in srcStageMask, as specified in the table of supported access types.
• Any access flag included in dstAccessMask must be supported by one of the pipeline stages in dstStageMask, as specified in the table of supported access types.
• If dependencyFlags includes VK_DEPENDENCY_VIEW_LOCAL_BIT, then both srcSubpass and dstSubpass must not equal VK_SUBPASS_EXTERNAL
• If dependencyFlags includes VK_DEPENDENCY_VIEW_LOCAL_BIT, then the render pass must have multiview enabled
• If srcSubpass equals dstSubpass and that subpass has more than one bit set in the view mask, then dependencyFlags must include VK_DEPENDENCY_VIEW_LOCAL_BIT

Valid Usage (Implicit)

• srcStageMask must be a valid combination of VkPipelineStageFlagBits values

• srcStageMask must not be 0
• dstStageMask must be a valid combination of VkPipelineStageFlagBits values
• dstStageMask must not be 0
• srcAccessMask must be a valid combination of VkAccessFlagBits values
• dstAccessMask must be a valid combination of VkAccessFlagBits values
• dependencyFlags must be a valid combination of VkDependencyFlagBits values

See Also

VkAccessFlags, VkDependencyFlags, VkPipelineStageFlags, VkRenderPassCreateInfo

VkRenderPassCreateInfo - Structure specifying parameters of a newly created render pass

Valid Usage

• If any two subpasses operate on attachments with overlapping ranges of the same VkDeviceMemory object, and at least one subpass writes to that area of VkDeviceMemory, a subpass dependency must be included (either directly or via some intermediate subpasses) between them

• If the attachment member of any element of pInputAttachments, pColorAttachments, pResolveAttachments or pDepthStencilAttachment, or the attachment indexed by any element of pPreserveAttachments in any element of pSubpasses is bound to a range of a VkDeviceMemory object that overlaps with any other attachment in any subpass (including the same subpass), the VkAttachmentDescription structures describing them must include VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT in flags
• If the attachment member of any element of pInputAttachments, pColorAttachments, pResolveAttachments or pDepthStencilAttachment, or any element of pPreserveAttachments in any element of pSubpasses is not VK_ATTACHMENT_UNUSED, it must be less than attachmentCount
• The value of each element of the pPreserveAttachments member in each element of pSubpasses must not be VK_ATTACHMENT_UNUSED
• For any member of pAttachments with a loadOp equal to VK_ATTACHMENT_LOAD_OP_CLEAR, the first use of that attachment must not specify a layout equal to VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL or VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL.
• For any member of pAttachments with a loadOp equal to VK_ATTACHMENT_LOAD_OP_CLEAR, the first use of that attachment must not specify a layout equal to VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL.
• For any member of pAttachments with a stencilLoadOp equal to VK_ATTACHMENT_LOAD_OP_CLEAR, the first use of that attachment must not specify a layout equal to VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL.
• For any element of pDependencies, if the srcSubpass is not VK_SUBPASS_EXTERNAL, all stage flags included in the srcStageMask member of that dependency must be a pipeline stage supported by the pipeline identified by the pipelineBindPoint member of the source subpass.
• For any element of pDependencies, if the dstSubpass is not VK_SUBPASS_EXTERNAL, all stage flags included in the dstStageMask member of that dependency must be a pipeline stage supported by the pipeline identified by the pipelineBindPoint member of the source subpass.

Valid Usage (Implicit)

• sType must be VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO

• Each pNext member of any structure (including this one) in the pNext chain must be either NULL or a pointer to a valid instance of VkRenderPassInputAttachmentAspectCreateInfo or VkRenderPassMultiviewCreateInfo
• Each sType member in the pNext chain must be unique
• flags must be 0
• If attachmentCount is not 0, pAttachments must be a valid pointer to an array of attachmentCount valid VkAttachmentDescription structures
• pSubpasses must be a valid pointer to an array of subpassCount valid VkSubpassDescription structures
• If dependencyCount is not 0, pDependencies must be a valid pointer to an array of dependencyCount valid VkSubpassDependency structures
• subpassCount must be greater than 0

See Also

VkAttachmentDescription, VkRenderPassCreateFlags, VkStructureType, VkSubpassDependency, VkSubpassDescription, vkCreateRenderPass

VkFramebufferCreateInfo - Structure specifying parameters of a newly created framebuffer

Description

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, and rather 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 a given zero-attachment subpass must have the same value for VkPipelineMultisampleStateCreateInfo::rasterizationSamples.

Valid Usage

• attachmentCount must be equal to the attachment count specified in renderPass

• Each element of pAttachments that is used as a color attachment or resolve attachment by renderPass must have been created with a usage value including VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT
• Each element of pAttachments that is used as a depth/stencil attachment by renderPass must have been created with a usage value including VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT
• Each element of pAttachments that is used as an input attachment by renderPass must have been created with a usage value including VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT
• Each element of pAttachments must have been created with an VkFormat value that matches the VkFormat specified by the corresponding VkAttachmentDescription in renderPass
• Each element of pAttachments must have been created with a samples value that matches the samples value specified by the corresponding VkAttachmentDescription in renderPass
• Each element of pAttachments must have dimensions at least as large as the corresponding framebuffer dimension
• Each element of pAttachments must only specify a single mip level
• Each element of pAttachments must have been created with the identity swizzle
• width must be greater than 0.
• width must be less than or equal to VkPhysicalDeviceLimits::maxFramebufferWidth
• height must be greater than 0.
• height must be less than or equal to VkPhysicalDeviceLimits::maxFramebufferHeight
• layers must be greater than 0.
• layers must be less than or equal to VkPhysicalDeviceLimits::maxFramebufferLayers
• Each element of pAttachments that is a 2D or 2D array image view taken from a 3D image must not be a depth/stencil format

Valid Usage (Implicit)

• sType must be VK_STRUCTURE_TYPE_FRAMEBUFFER_CREATE_INFO

• pNext must be NULL
• flags must be 0
• renderPass must be a valid VkRenderPass handle
• If attachmentCount is not 0, pAttachments must be a valid pointer to an array of attachmentCount valid VkImageView handles
• Both of renderPass, and the elements of pAttachments that are valid handles must have been created, allocated, or retrieved from the same VkDevice

See Also

VkFramebufferCreateFlags, VkImageView, VkRenderPass, VkStructureType, vkCreateFramebuffer

VkAccessFlags - Bitmask of VkAccessFlagBits

Description

VkAccessFlags is a bitmask type for setting a mask of zero or more VkAccessFlagBits.

See Also

VkAccessFlagBits, VkBufferMemoryBarrier, VkImageMemoryBarrier, VkMemoryBarrier, VkSubpassDependency

VkSubpassDescriptionFlags - Bitmask of VkSubpassDescriptionFlagBits

Description

VkSubpassDescriptionFlags is a bitmask type for setting a mask of zero or more VkSubpassDescriptionFlagBits.

See Also

VkSubpassDescription, VkSubpassDescriptionFlagBits

VkAttachmentDescriptionFlags - Bitmask of VkAttachmentDescriptionFlagBits

Description

VkAttachmentDescriptionFlags is a bitmask type for setting a mask of zero or more VkAttachmentDescriptionFlagBits.

See Also

VkAttachmentDescription, VkAttachmentDescriptionFlagBits

VkDependencyFlags - Bitmask of VkDependencyFlagBits

Description

VkDependencyFlags is a bitmask type for setting a mask of zero or more VkDependencyFlagBits.

See Also

VkDependencyFlagBits, VkSubpassDependency, vkCmdPipelineBarrier