Safe Haskell | Safe-Inferred |
---|---|
Language | Haskell2010 |
Name
VK_EXT_multisampled_render_to_single_sampled - device extension
VK_EXT_multisampled_render_to_single_sampled
- Name String
VK_EXT_multisampled_render_to_single_sampled
- Extension Type
- Device extension
- Registered Extension Number
- 377
- Revision
- 1
- Extension and Version Dependencies
- Requires support for Vulkan 1.0
- Requires
VK_KHR_create_renderpass2
to be enabled for any device-level functionality - Requires
VK_KHR_depth_stencil_resolve
to be enabled for any device-level functionality
- Contact
- Extension Proposal
- VK_EXT_multisampled_render_to_single_sampled
Other Extension Metadata
- Last Modified Date
- 2021-04-16
- IP Status
- No known IP claims.
- Contributors
- Shahbaz Youssefi, Google
- Jan-Harald Fredriksen, Arm
- Jörg Wagner, Arm
- Matthew Netsch, Qualcomm Technologies, Inc.
- Jarred Davies, Imagination Technologies
Description
With careful usage of resolve attachments, multisampled image memory
allocated with
MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT
,
loadOp
not equal to
ATTACHMENT_LOAD_OP_LOAD
and
storeOp
not equal to
ATTACHMENT_STORE_OP_STORE
, a
Vulkan application is able to efficiently perform multisampled rendering
without incurring any additional memory penalty on some implementations.
Under certain circumstances however, the application may not be able to
complete its multisampled rendering within a single render pass; for
example if it does partial rasterization from frame to frame, blending
on an image from a previous frame, or in emulation of
GL_EXT_multisampled_render_to_texture. In such cases, the application
can use an initial subpass to effectively load single-sampled data from
the next subpass’s resolve attachment and fill in the multisampled
attachment which otherwise uses loadOp
equal to
ATTACHMENT_LOAD_OP_DONT_CARE
.
However, this is not always possible (for example for stencil in the
absence of VK_EXT_shader_stencil_export) and has multiple drawbacks.
Some implementations are able to perform said operation efficiently in hardware, effectively loading a multisampled attachment from the contents of a single sampled one. Together with the ability to perform a resolve operation at the end of a subpass, these implementations are able to perform multisampled rendering on single-sampled attachments with no extra memory or bandwidth overhead. This extension exposes this capability by allowing a framebuffer and render pass to include single-sampled attachments while rendering is done with a specified number of samples.
New Structures
Extending
PhysicalDeviceFeatures2
,DeviceCreateInfo
:Extending
SubpassDescription2
,RenderingInfo
:
New Enum Constants
EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_SPEC_VERSION
Extending
ImageCreateFlagBits
:Extending
StructureType
:
Issues
1) Could the multisampled attachment be initialized through some form of copy?
RESOLVED: No. Some implementations do not support copying between attachments in general, and find expressing this operation through a copy unnatural.
2) Another way to achieve this is by introducing a new loadOp
to load
the contents of the multisampled image from a single-sampled one. Why is
this extension preferred?
RESOLVED: Using this extension simplifies the application, as it
does not need to manage a secondary lazily-allocated image.
Additionally, using this extension leaves less room for error; for
example a single mistake in loadOp
or storeOp
would result in the
lazily-allocated image to actually take up memory, and remain so until
destruction.
3) There is no guarantee that multisampled data between two subpasses with the same number of samples will be retained as the implementation may be forced to split the render pass implicitly for various reasons. Should this extension require that every subpass that uses multisampled-render-to-single-sampled end in an implicit render pass split (which results in a resolve operation)?
RESOLVED: No. Not requiring this allows render passes with multiple multisampled-render-to-single-sampled subpasses to potentially execute more efficiently (though there is no guarantee).
Version History
- Revision 1, 2021-04-12 (Shahbaz Youssefi)
See Also
MultisampledRenderToSingleSampledInfoEXT
,
PhysicalDeviceMultisampledRenderToSingleSampledFeaturesEXT
,
SubpassResolvePerformanceQueryEXT
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
- data PhysicalDeviceMultisampledRenderToSingleSampledFeaturesEXT = PhysicalDeviceMultisampledRenderToSingleSampledFeaturesEXT {}
- data SubpassResolvePerformanceQueryEXT = SubpassResolvePerformanceQueryEXT {}
- data MultisampledRenderToSingleSampledInfoEXT = MultisampledRenderToSingleSampledInfoEXT {}
- type EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_SPEC_VERSION = 1
- pattern EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_SPEC_VERSION :: forall a. Integral a => a
- type EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_EXTENSION_NAME = "VK_EXT_multisampled_render_to_single_sampled"
- pattern EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a
Documentation
data PhysicalDeviceMultisampledRenderToSingleSampledFeaturesEXT Source #
VkPhysicalDeviceMultisampledRenderToSingleSampledFeaturesEXT - Structure describing whether multisampled rendering to single-sampled attachments is supported
Members
This structure describes the following features:
Description
If the PhysicalDeviceMultisampledRenderToSingleSampledFeaturesEXT
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. PhysicalDeviceMultisampledRenderToSingleSampledFeaturesEXT
can also be used in the pNext
chain of
DeviceCreateInfo
to selectively enable these
features.
Valid Usage (Implicit)
See Also
VK_EXT_multisampled_render_to_single_sampled,
Bool32
,
StructureType
Instances
data SubpassResolvePerformanceQueryEXT Source #
VkSubpassResolvePerformanceQueryEXT - Structure specifying the efficiency of subpass resolve for an attachment with a format
Description
If optimal
is FALSE
for a
Format
, using a subpass resolve operation
on a multisampled attachment with this format can incur additional
costs, including additional memory bandwidth usage and a higher memory
footprint. If an attachment with such a format is used in a
multisampled-render-to-single-sampled
subpass, the additional memory and memory bandwidth usage can nullify
the benefits of using the VK_EXT_multisampled_render_to_single_sampled
extension.
Valid Usage (Implicit)
See Also
VK_EXT_multisampled_render_to_single_sampled,
Bool32
,
StructureType
Instances
data MultisampledRenderToSingleSampledInfoEXT Source #
VkMultisampledRenderToSingleSampledInfoEXT - Structure containing info for multisampled rendering to single-sampled attachments in a subpass
Valid Usage
-
The value of
rasterizationSamples
must not beSAMPLE_COUNT_1_BIT
- If
added to the
pNext
chain ofRenderingInfo
, eachimageView
member of any element ofRenderingInfo
::pColorAttachments
,RenderingInfo
::pDepthAttachment
, orRenderingInfo
::pStencilAttachment
that is notNULL_HANDLE
must have a format that supports the sample count specified inrasterizationSamples
Valid Usage (Implicit)
-
rasterizationSamples
must be a validSampleCountFlagBits
value
See Also
VK_EXT_multisampled_render_to_single_sampled,
Bool32
,
SampleCountFlagBits
,
StructureType
MultisampledRenderToSingleSampledInfoEXT | |
|
Instances
pattern EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_SPEC_VERSION :: forall a. Integral a => a Source #
type EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_EXTENSION_NAME = "VK_EXT_multisampled_render_to_single_sampled" Source #
pattern EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a Source #