VkPhysicalDeviceFragmentDensityMapOffsetFeaturesEXT - Structure describing fragment density map offset features that can be supported by an implementation

Members

This structure describes the following feature:

Description

If the PhysicalDeviceFragmentDensityMapOffsetFeaturesEXT 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 PhysicalDeviceFragmentDensityMapOffsetFeaturesEXT, 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

VK_EXT_fragment_density_map_offset, VK_QCOM_fragment_density_map_offset, Bool32, StructureType

VkPhysicalDeviceFragmentDensityMapOffsetPropertiesEXT - Structure describing fragment density map offset properties that can be supported by an implementation

Description

If the PhysicalDeviceFragmentDensityMapOffsetPropertiesEXT 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

VK_EXT_fragment_density_map_offset, VK_QCOM_fragment_density_map_offset, Extent2D, StructureType

VkRenderPassFragmentDensityMapOffsetEndInfoEXT - Structure specifying fragment density map offset subpass end information

Description

The array elements are given per layer as defined by Fetch Density Value, where index = layer. Each (x,y) offset is in framebuffer pixels and shifts the fetch of the fragment density map by that amount. Offsets can be positive or negative.

If neither the SubpassEndInfo::pNext chain for the last subpass of a render pass nor the RenderingEndInfoEXT::pNext chain of a dynamic render pass include RenderPassFragmentDensityMapOffsetEndInfoEXT, or if fragmentDensityOffsetCount is zero, then the offset (0,0) is used for Fetch Density Value.

Valid Usage

• If the fragmentDensityMapOffset feature is not enabled or fragment density map is not enabled in the render pass, fragmentDensityOffsetCount must equal 0

• If RenderPassFragmentDensityMapCreateInfoEXT::fragmentDensityMapAttachment is not ATTACHMENT_UNUSED and was not created with IMAGE_CREATE_FRAGMENT_DENSITY_MAP_OFFSET_BIT_EXT, fragmentDensityOffsetCount must equal 0
• If the depth or stencil attachments for the render pass are used and were not created with IMAGE_CREATE_FRAGMENT_DENSITY_MAP_OFFSET_BIT_EXT, fragmentDensityOffsetCount must equal 0
• If any used input attachments for the render pass were not created with IMAGE_CREATE_FRAGMENT_DENSITY_MAP_OFFSET_BIT_EXT, fragmentDensityOffsetCount must equal 0
• If any used color attachments for the render pass were not created with IMAGE_CREATE_FRAGMENT_DENSITY_MAP_OFFSET_BIT_EXT, fragmentDensityOffsetCount must equal 0
• If any used resolve attachments for the render pass were not created with IMAGE_CREATE_FRAGMENT_DENSITY_MAP_OFFSET_BIT_EXT, fragmentDensityOffsetCount must equal 0
• If any used preserve attachments for the render pass were not created with IMAGE_CREATE_FRAGMENT_DENSITY_MAP_OFFSET_BIT_EXT, fragmentDensityOffsetCount must equal 0
• If fragmentDensityOffsetCount is not 0 and multiview is enabled for the render pass, fragmentDensityOffsetCount must equal the layerCount that was specified in creating the fragment density map attachment view
• If fragmentDensityOffsetCount is not 0 and multiview is not enabled for the render pass, fragmentDensityOffsetCount must equal 1
• The x component of each element of pFragmentDensityOffsets must be an integer multiple of fragmentDensityOffsetGranularity.width
• The y component of each element of pFragmentDensityOffsets must be an integer multiple of fragmentDensityOffsetGranularity.height
• Each element of pFragmentDensityOffsets must be identical for every cmdEndRendering2KHR call made in a render pass

Valid Usage (Implicit)

• sType must be STRUCTURE_TYPE_RENDER_PASS_FRAGMENT_DENSITY_MAP_OFFSET_END_INFO_EXT

• If fragmentDensityOffsetCount is not 0, pFragmentDensityOffsets must be a valid pointer to an array of fragmentDensityOffsetCount Offset2D structures

See Also

VK_EXT_fragment_density_map_offset, VK_QCOM_fragment_density_map_offset, Offset2D, 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

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