Vulkan.Extensions.VK_KHR_maintenance10

vkCmdEndRendering2KHR - End a dynamic render pass instance

Description

If the value of pRenderingInfo->flags used to begin this render pass instance included RENDERING_SUSPENDING_BIT, then this render pass is suspended and will be resumed later in submission order.

There is no implicit ordering between separate render passes, even in the same command buffer, and even when the attachments match. Some applications rely on the continuation of rasterization order between multiple render passes with attachments defined in the same way, in order to perform non-rendering operations (such as copies or compute operations) between draw calls, but this has never been required by the specification. There is also no explicit barrier currently in the API that provides the guarantee that applications rely on without additional performance penalties.

New applications should avoid relying on this ordering until an appropriate barrier is added to the API.

Implementations where applications are performing this splitting are encouraged to continue supporting this guarantee until a suitable barrier is added to the API.

Existing applications relying on this ordering should expect that it will continue working on platforms where it currently does. Once a new extension adds support for a new barrier, developers are encouraged to adapt their applications to use this when available.

Valid Usage

• The current render pass instance must have been begun with cmdBeginRendering

• The current render pass instance must have been begun in commandBuffer

• This command must not be recorded when transform feedback is active

• If cmdBeginQuery* was called within the render pass, the corresponding cmdEndQuery* must have been called subsequently within the same subpass

Valid Usage (Implicit)

• commandBuffer must be a valid CommandBuffer handle

• If pRenderingEndInfo is not NULL, pRenderingEndInfo must be a valid pointer to a valid RenderingEndInfoKHR structure

• commandBuffer must be in the recording state

• The CommandPool that commandBuffer was allocated from must support QUEUE_GRAPHICS_BIT operations

• This command must only be called inside of a render pass instance

• This command must not be called between suspended render pass instances

• This command must only be called outside of a video coding scope

Host Synchronization

• Host access to commandBuffer must be externally synchronized

• Host access to the CommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

'

Conditional Rendering

vkCmdEndRendering2KHR is not affected by conditional rendering

See Also

VK_EXT_fragment_density_map_offset, VK_KHR_maintenance10, CommandBuffer, RenderingEndInfoKHR

VkPhysicalDeviceMaintenance10PropertiesKHR - Structure describing various implementation-defined properties introduced with VK_KHR_maintenance10

Description

Implementations supporting maintenance10 should set resolveSrgbFormatAppliesTransferFunction to TRUE.

If the PhysicalDeviceMaintenance10PropertiesKHR structure is included in the pNext chain of the PhysicalDeviceProperties2 structure passed to getPhysicalDeviceProperties2, it is filled in with each corresponding implementation-dependent property.

Structure Chaining

Extends the structure

• PhysicalDeviceProperties2

See Also

VK_KHR_maintenance10, Bool32, StructureType

VkPhysicalDeviceMaintenance10FeaturesKHR - Structure describing whether the implementation supports maintenance10 functionality

Members

This structure describes the following feature:

Description

If the PhysicalDeviceMaintenance10FeaturesKHR structure is included in the pNext chain of the PhysicalDeviceFeatures2 structure passed to getPhysicalDeviceFeatures2, it is filled in to indicate whether each corresponding feature is supported. If the application wishes to use a Device with any features described by PhysicalDeviceMaintenance10FeaturesKHR, it must add an instance of the structure, with the desired feature members set to TRUE, to the pNext chain of DeviceCreateInfo when creating the Device.

Structure Chaining

Extends the structures

• DeviceCreateInfo

• PhysicalDeviceFeatures2

See Also

VK_KHR_maintenance10, Bool32, StructureType

VkRenderingEndInfoKHR - Structure specifying render pass end information

Valid Usage (Implicit)

• sType must be STRUCTURE_TYPE_RENDERING_END_INFO_KHR

• pNext must be NULL or a pointer to a valid instance of RenderPassFragmentDensityMapOffsetEndInfoEXT

• The sType value of each structure in the pNext chain must be unique

See Also

VK_EXT_fragment_density_map_offset, VK_KHR_maintenance10, StructureType, cmdEndRendering2KHR, cmdEndRendering2KHR

VkRenderingAttachmentFlagsInfoKHR - Structure specifying flags extending a rendering attachment

Valid Usage

• flags must not include RENDERING_ATTACHMENT_INPUT_ATTACHMENT_FEEDBACK_BIT_KHR if the dynamicRenderingLocalRead feature is not enabled

• If flags includes RENDERING_ATTACHMENT_RESOLVE_SKIP_TRANSFER_FUNCTION_BIT_KHR, flags must not include RENDERING_ATTACHMENT_RESOLVE_ENABLE_TRANSFER_FUNCTION_BIT_KHR

• If flags includes RENDERING_ATTACHMENT_RESOLVE_SKIP_TRANSFER_FUNCTION_BIT_KHR or RENDERING_ATTACHMENT_RESOLVE_ENABLE_TRANSFER_FUNCTION_BIT_KHR, resolveSrgbFormatSupportsTransferFunctionControl must be TRUE

Valid Usage (Implicit)

• sType must be STRUCTURE_TYPE_RENDERING_ATTACHMENT_FLAGS_INFO_KHR

• flags must be a valid combination of RenderingAttachmentFlagBitsKHR values

Structure Chaining

Extends the structure

• RenderingAttachmentInfo

See Also

VK_KHR_maintenance10, RenderingAttachmentFlagsKHR, StructureType

VkResolveImageModeInfoKHR - Structure specifying additional control for VkResolveImageInfo2

Valid Usage

• If flags includes RESOLVE_IMAGE_SKIP_TRANSFER_FUNCTION_BIT_KHR, flags must not include RESOLVE_IMAGE_ENABLE_TRANSFER_FUNCTION_BIT_KHR

• If flags includes RESOLVE_IMAGE_SKIP_TRANSFER_FUNCTION_BIT_KHR or RESOLVE_IMAGE_ENABLE_TRANSFER_FUNCTION_BIT_KHR, resolveSrgbFormatSupportsTransferFunctionControl must be TRUE

• If flags includes RESOLVE_IMAGE_SKIP_TRANSFER_FUNCTION_BIT_KHR or RESOLVE_IMAGE_ENABLE_TRANSFER_FUNCTION_BIT_KHR, resolveMode must be equal to RESOLVE_MODE_AVERAGE_BIT

Valid Usage (Implicit)

• sType must be STRUCTURE_TYPE_RESOLVE_IMAGE_MODE_INFO_KHR

• flags must be a valid combination of ResolveImageFlagBitsKHR values

• If resolveMode is not 0, resolveMode must be a valid ResolveModeFlagBits value

• If stencilResolveMode is not 0, stencilResolveMode must be a valid ResolveModeFlagBits value

Structure Chaining

Extends the structure

• ResolveImageInfo2

See Also

VK_KHR_maintenance10, ResolveImageFlagsKHR, ResolveModeFlagBits, StructureType

VkRenderingAttachmentFlagBitsKHR - Bitmask specifying additional properties of a rendering attachment

Description

• RENDERING_ATTACHMENT_INPUT_ATTACHMENT_FEEDBACK_BIT_KHR specifies that the attachment can be used concurrently as both an input attachment and a write-only attachment during the render pass, creating a feedback loop while processing a fragment, and without a DEPENDENCY_BY_REGION_BIT barrier separating the write attachment and input attachment usage. Using this flag does not remove the general requirement to use a DEPENDENCY_BY_REGION_BIT barrier to resolve hazards when two different fragments accesses a particular attachment region, where one of them performs an attachment write, and a subsequent fragment performs an input attachment read. If RENDERING_LOCAL_READ_CONCURRENT_ACCESS_CONTROL_BIT_KHR is specified in the rendering info, this flag must be set for an attachment to be used concurrently as an input attachment and a write attachment in this manner. If RENDERING_LOCAL_READ_CONCURRENT_ACCESS_CONTROL_BIT_KHR is not specified in the rendering info, this flag is implied to be set for any attachment which has a combination of image layouts and image view usage flags which support input attachment usage.

• RENDERING_ATTACHMENT_RESOLVE_SKIP_TRANSFER_FUNCTION_BIT_KHR specifies that resolve operations happening to an sRGB encoded attachment must not convert samples from nonlinear to linear before averaging.

• RENDERING_ATTACHMENT_RESOLVE_ENABLE_TRANSFER_FUNCTION_BIT_KHR specifies that resolve operations happening to an sRGB encoded attachment must convert samples from nonlinear to linear before averaging.

RENDERING_ATTACHMENT_INPUT_ATTACHMENT_FEEDBACK_BIT_KHR is intended to give implementations similar information as a subpass where an attachment could be used as both a color attachment and input attachment. Some implementations require extra work to make this scenario work beyond just considering the image layouts. Implementations which have no such considerations may treat this flag as a noop. The primary use case for this flag is to enable feedback loops inside a single shader.

Applications are encouraged to use RENDERING_LOCAL_READ_CONCURRENT_ACCESS_CONTROL_BIT_KHR if maintenance10 is available and they use feedback loops with VK_KHR_dynamic_rendering_local_read. Feedback loops are still allowed when not using the rendering flag, but the performance implication was an oversight in the original definition of VK_KHR_dynamic_rendering_local_read.

In some scenarios, resolving sRGB in nonlinear space instead of the expected linear space can improve perceptual aliasing at the cost of inaccurate color blending.

See Also

VK_KHR_maintenance10, RenderingAttachmentFlagsKHR

VkResolveImageFlagBitsKHR - Bitmask specifying additional properties of a resolve image operation

Description

• RESOLVE_IMAGE_SKIP_TRANSFER_FUNCTION_BIT_KHR specifies that resolve operations happening to an sRGB encoded image must not convert samples from nonlinear to linear before averaging.

• RESOLVE_IMAGE_ENABLE_TRANSFER_FUNCTION_BIT_KHR specifies that resolve operations happening to an sRGB encoded image must convert samples from nonlinear to linear before averaging.

See Also

VK_KHR_maintenance10, ResolveImageFlagsKHR