| Safe Haskell | None |
|---|---|
| Language | Haskell2010 |
Vulkan.Extensions.VK_KHR_maintenance10
Description
Name
VK_KHR_maintenance10 - device extension
VK_KHR_maintenance10
- Name String
VK_KHR_maintenance10
- Extension Type
- Device extension
- Registered Extension Number
- 631
- Revision
- 1
- Ratification Status
- Ratified
- Extension and Version Dependencies
- VK_KHR_get_physical_device_properties2 or Vulkan Version 1.1
- API Interactions
- Interacts with VK_VERSION_1_3
- Interacts with VK_VERSION_1_4
- Interacts with VK_KHR_copy_commands2
- Interacts with VK_KHR_dynamic_rendering
- Interacts with VK_KHR_dynamic_rendering_local_read
- Interacts with VK_KHR_format_feature_flags2
- Contact
- Extension Proposal
- VK_KHR_maintenance10
Other Extension Metadata
- Last Modified Date
- 2025-05-13
- Interactions and External Dependencies
- This extension interacts with
VK_KHR_format_feature_flags2 - This extension interacts with
VK_EXT_extended_dynamic_state3 - This extension interacts with
VK_KHR_dynamic_rendering_local_read - This extension interacts with
VK_KHR_depth_stencil_resolve
- This extension interacts with
- Contributors
- Mike Blumenkrantz, Valve
- Piers Daniell, NVIDIA
- Hans-Kristian Arntzen, Valve
Description
VK_KHR_maintenance10 adds a collection of minor features, none of which would warrant an entire extension of their own.
The new features are as follows:
- New image format feature bits that indicate support for copying depth or stencil aspects using non-graphics queue families
- If
cmdSetSampleMaskEXTis called withpSampleMaskset toNULL, it is treated as if the mask has all bits set to1. - Add vkCmdEndRendering2KHR as an extensible version of vkCmdEndRendering
- Add input attachment information to dynamic rendering
- Require that vertex inputs follow sRGB encoding when those formats are used, instead of being underspecified.
- Add a query to determine if sRGB images are resolved in nonlinear or linear space by default
- Add an optional feature to allow applications to override the default sRGB resolve behavior
- Add resolve mode and depth-stencil resolve support to
cmdResolveImage2to bring it in-line with render pass attachment resolves
New Commands
New Structures
Extending
PhysicalDeviceFeatures2,DeviceCreateInfo:Extending
PhysicalDeviceProperties2:Extending
RenderingAttachmentInfo:Extending
ResolveImageInfo2:
New Enums
New Bitmasks
New Enum Constants
KHR_MAINTENANCE_10_SPEC_VERSIONExtending
AttachmentDescriptionFlagBits:Extending
StructureType:
If Vulkan Version 1.4 or VK_KHR_dynamic_rendering_local_read and Vulkan Version 1.3 or VK_KHR_dynamic_rendering is supported:
Extending
RenderingAttachmentFlagBitsKHR:Extending
RenderingFlagBits:
If VK_KHR_format_feature_flags2 or Vulkan Version 1.3 is supported:
Extending
FormatFeatureFlagBits2:
If Vulkan Version 1.3 or VK_KHR_copy_commands2 is supported:
Extending
ResolveImageFlagBitsKHR:
If Vulkan Version 1.3 or VK_KHR_dynamic_rendering is supported:
Extending
RenderingAttachmentFlagBitsKHR:
Issues
None.
Version History
Revision 1, 2025-05-13 (Mike Blumenkrantz)
- Initial revision
See Also
No cross-references are available
Document Notes
For more information, see the Vulkan Specification.
This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.
Synopsis
- cmdEndRendering2KHR :: forall (a :: [Type]) io. (Extendss RenderingEndInfoKHR a, PokeChain a, MonadIO io) => CommandBuffer -> ("renderingEndInfo" ::: Maybe (RenderingEndInfoKHR a)) -> io ()
- data PhysicalDeviceMaintenance10PropertiesKHR = PhysicalDeviceMaintenance10PropertiesKHR {}
- data PhysicalDeviceMaintenance10FeaturesKHR = PhysicalDeviceMaintenance10FeaturesKHR {}
- data RenderingEndInfoKHR (es :: [Type]) = RenderingEndInfoKHR {}
- data RenderingAttachmentFlagsInfoKHR = RenderingAttachmentFlagsInfoKHR {}
- data ResolveImageModeInfoKHR = ResolveImageModeInfoKHR {}
- type RenderingAttachmentFlagsKHR = RenderingAttachmentFlagBitsKHR
- newtype RenderingAttachmentFlagBitsKHR where
- RenderingAttachmentFlagBitsKHR Flags
- pattern RENDERING_ATTACHMENT_RESOLVE_ENABLE_TRANSFER_FUNCTION_BIT_KHR :: RenderingAttachmentFlagBitsKHR
- pattern RENDERING_ATTACHMENT_RESOLVE_SKIP_TRANSFER_FUNCTION_BIT_KHR :: RenderingAttachmentFlagBitsKHR
- pattern RENDERING_ATTACHMENT_INPUT_ATTACHMENT_FEEDBACK_BIT_KHR :: RenderingAttachmentFlagBitsKHR
- type ResolveImageFlagsKHR = ResolveImageFlagBitsKHR
- newtype ResolveImageFlagBitsKHR where
- type KHR_MAINTENANCE_10_SPEC_VERSION = 1
- pattern KHR_MAINTENANCE_10_SPEC_VERSION :: Integral a => a
- type KHR_MAINTENANCE_10_EXTENSION_NAME = "VK_KHR_maintenance10"
- pattern KHR_MAINTENANCE_10_EXTENSION_NAME :: (Eq a, IsString a) => a
Documentation
Arguments
| :: forall (a :: [Type]) io. (Extendss RenderingEndInfoKHR a, PokeChain a, MonadIO io) | |
| => CommandBuffer |
|
| -> ("renderingEndInfo" ::: Maybe (RenderingEndInfoKHR a)) |
|
| -> io () |
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 correspondingcmdEndQuery* must have been called subsequently within the same subpass
Valid Usage (Implicit)
-
commandBuffermust be a validCommandBufferhandle
- If
pRenderingEndInfois notNULL,pRenderingEndInfomust be a valid pointer to a validRenderingEndInfoKHRstructure -
commandBuffermust be in the recording state - The
CommandPoolthatcommandBufferwas allocated from must supportQUEUE_GRAPHICS_BIToperations - 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
commandBuffermust be externally synchronized
- Host access to the
CommandPoolthatcommandBufferwas allocated from must be externally synchronized
Command Properties
'
| Command Buffer Levels | Render Pass Scope | Video Coding Scope | Supported Queue Types | Command Type |
|---|---|---|---|---|
| Primary Secondary | Inside | Outside | VK_QUEUE_GRAPHICS_BIT | Action State |
Conditional Rendering
vkCmdEndRendering2KHR is not affected by conditional rendering
See Also
VK_EXT_fragment_density_map_offset,
VK_KHR_maintenance10,
CommandBuffer, RenderingEndInfoKHR
data PhysicalDeviceMaintenance10PropertiesKHR Source #
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.
Valid Usage (Implicit)
See Also
Constructors
| PhysicalDeviceMaintenance10PropertiesKHR | |
Fields
| |
Instances
data PhysicalDeviceMaintenance10FeaturesKHR Source #
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.
Valid Usage (Implicit)
See Also
Constructors
| PhysicalDeviceMaintenance10FeaturesKHR | |
Fields
| |
Instances
data RenderingEndInfoKHR (es :: [Type]) Source #
VkRenderingEndInfoKHR - Structure specifying render pass end information
Valid Usage (Implicit)
-
sTypemust beSTRUCTURE_TYPE_RENDERING_END_INFO_KHR
-
pNextmust beNULLor a pointer to a valid instance ofRenderPassFragmentDensityMapOffsetEndInfoEXT - The
sTypevalue of each structure in thepNextchain must be unique
See Also
VK_EXT_fragment_density_map_offset,
VK_KHR_maintenance10,
StructureType,
cmdEndRendering2KHR, cmdEndRendering2KHR
Constructors
| RenderingEndInfoKHR | |
Instances
data RenderingAttachmentFlagsInfoKHR Source #
VkRenderingAttachmentFlagsInfoKHR - Structure specifying flags extending a rendering attachment
Valid Usage
-
flagsmust not includeRENDERING_ATTACHMENT_INPUT_ATTACHMENT_FEEDBACK_BIT_KHRif the dynamicRenderingLocalRead feature is not enabled
- If
flagsincludesRENDERING_ATTACHMENT_RESOLVE_SKIP_TRANSFER_FUNCTION_BIT_KHR,flagsmust not includeRENDERING_ATTACHMENT_RESOLVE_ENABLE_TRANSFER_FUNCTION_BIT_KHR - If
flagsincludesRENDERING_ATTACHMENT_RESOLVE_SKIP_TRANSFER_FUNCTION_BIT_KHRorRENDERING_ATTACHMENT_RESOLVE_ENABLE_TRANSFER_FUNCTION_BIT_KHR, resolveSrgbFormatSupportsTransferFunctionControl must beTRUE
Valid Usage (Implicit)
-
sTypemust beSTRUCTURE_TYPE_RENDERING_ATTACHMENT_FLAGS_INFO_KHR
-
flagsmust be a valid combination ofRenderingAttachmentFlagBitsKHRvalues
See Also
VK_KHR_maintenance10,
RenderingAttachmentFlagsKHR,
StructureType
Constructors
| RenderingAttachmentFlagsInfoKHR | |
Fields
| |
Instances
data ResolveImageModeInfoKHR Source #
VkResolveImageModeInfoKHR - Structure specifying additional control for VkResolveImageInfo2
Valid Usage
- If
flagsincludesRESOLVE_IMAGE_SKIP_TRANSFER_FUNCTION_BIT_KHR,flagsmust not includeRESOLVE_IMAGE_ENABLE_TRANSFER_FUNCTION_BIT_KHR
- If
flagsincludesRESOLVE_IMAGE_SKIP_TRANSFER_FUNCTION_BIT_KHRorRESOLVE_IMAGE_ENABLE_TRANSFER_FUNCTION_BIT_KHR, resolveSrgbFormatSupportsTransferFunctionControl must beTRUE - If
flagsincludesRESOLVE_IMAGE_SKIP_TRANSFER_FUNCTION_BIT_KHRorRESOLVE_IMAGE_ENABLE_TRANSFER_FUNCTION_BIT_KHR,resolveModemust be equal toRESOLVE_MODE_AVERAGE_BIT
Valid Usage (Implicit)
-
sTypemust beSTRUCTURE_TYPE_RESOLVE_IMAGE_MODE_INFO_KHR
-
flagsmust be a valid combination ofResolveImageFlagBitsKHRvalues - If
resolveModeis not0,resolveModemust be a validResolveModeFlagBitsvalue - If
stencilResolveModeis not0,stencilResolveModemust be a validResolveModeFlagBitsvalue
See Also
VK_KHR_maintenance10,
ResolveImageFlagsKHR,
ResolveModeFlagBits,
StructureType
Constructors
| ResolveImageModeInfoKHR | |
Fields
| |
Instances
newtype RenderingAttachmentFlagBitsKHR Source #
VkRenderingAttachmentFlagBitsKHR - Bitmask specifying additional properties of a rendering attachment
Description
RENDERING_ATTACHMENT_INPUT_ATTACHMENT_FEEDBACK_BIT_KHRspecifies 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 aDEPENDENCY_BY_REGION_BITbarrier separating the write attachment and input attachment usage. Using this flag does not remove the general requirement to use aDEPENDENCY_BY_REGION_BITbarrier 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. IfRENDERING_LOCAL_READ_CONCURRENT_ACCESS_CONTROL_BIT_KHRis 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. IfRENDERING_LOCAL_READ_CONCURRENT_ACCESS_CONTROL_BIT_KHRis 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_KHRspecifies 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_KHRspecifies 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
Constructors
| RenderingAttachmentFlagBitsKHR Flags |
Bundled Patterns
Instances
newtype ResolveImageFlagBitsKHR Source #
VkResolveImageFlagBitsKHR - Bitmask specifying additional properties of a resolve image operation
Description
RESOLVE_IMAGE_SKIP_TRANSFER_FUNCTION_BIT_KHRspecifies 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_KHRspecifies that resolve operations happening to an sRGB encoded image must convert samples from nonlinear to linear before averaging.
See Also
Constructors
| ResolveImageFlagBitsKHR Flags |
Bundled Patterns
| pattern RESOLVE_IMAGE_ENABLE_TRANSFER_FUNCTION_BIT_KHR :: ResolveImageFlagBitsKHR | |
| pattern RESOLVE_IMAGE_SKIP_TRANSFER_FUNCTION_BIT_KHR :: ResolveImageFlagBitsKHR |
Instances
type KHR_MAINTENANCE_10_SPEC_VERSION = 1 Source #
pattern KHR_MAINTENANCE_10_SPEC_VERSION :: Integral a => a Source #
type KHR_MAINTENANCE_10_EXTENSION_NAME = "VK_KHR_maintenance10" Source #
pattern KHR_MAINTENANCE_10_EXTENSION_NAME :: (Eq a, IsString a) => a Source #