HORIZON HASKELLDocslts/ghc-10.0.xfc4e5982026-10-11Search names, modules, packages, or :: a typeCtrl K

GHC 10.0.0.20260917 · lts/ghc-10.0.x · fc4e598 · 2026-10-11

Modulevulkan-3.27GHC2021

Vulkan.Extensions.VK_KHR_synchronization2

Name

VK_KHR_synchronization2 - device extension

VK_KHR_synchronization2

Name String

VK_KHR_synchronization2

Extension Type

Device extension

Registered Extension Number

315

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_EXT_blend_operation_advanced

  • Interacts with VK_EXT_conditional_rendering

  • Interacts with VK_EXT_device_generated_commands

  • Interacts with VK_EXT_fragment_density_map

  • Interacts with VK_EXT_mesh_shader

  • Interacts with VK_EXT_transform_feedback

  • Interacts with VK_KHR_acceleration_structure

  • Interacts with VK_KHR_fragment_shading_rate

  • Interacts with VK_KHR_ray_tracing_pipeline

  • Interacts with VK_NV_device_generated_commands

  • Interacts with VK_NV_mesh_shader

  • Interacts with VK_NV_ray_tracing

  • Interacts with VK_NV_shading_rate_image

Deprecation State
Contact

Other Extension Metadata

Last Modified Date

2020-12-03

Interactions and External Dependencies

  • Interacts with VK_KHR_create_renderpass2

Contributors

  • Tobias Hector

Description

This extension modifies the original core synchronization APIs to simplify the interface and improve usability of these APIs. It also adds new pipeline stage and access flag types that extend into the 64-bit range, as we have run out within the 32-bit range. The new flags are identical to the old values within the 32-bit range, with new stages and bits beyond that.

Pipeline stages and access flags are now specified together in memory barrier structures, making the connection between the two more obvious. Additionally, scoping the pipeline stages into the barrier structs allows the use of the MEMORY_READ and MEMORY_WRITE flags without sacrificing precision. The per-stage access flags should be used to disambiguate specific accesses in a given stage or set of stages - for instance, between uniform reads and sampling operations.

Layout transitions have been simplified as well; rather than requiring a different set of layouts for depth/stencil/color attachments, there are generic IMAGE_LAYOUT_ATTACHMENT_OPTIMAL_KHR and IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR layouts which are contextually applied based on the image format. For example, for a depth format image, IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR is equivalent to IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL_KHR. IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR also functionally replaces IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL.

Events are now more efficient, because they include memory dependency information when you set them on the device. Previously, this information was only known when waiting on an event, so the dependencies could not be satisfied until the wait occurred. That sometimes meant stalling the pipeline when the wait occurred. The new API provides enough information for implementations to satisfy these dependencies in parallel with other tasks.

Queue submission has been changed to wrap command buffers and semaphores in extensible structures, which incorporate changes from Vulkan 1.1, VK_KHR_device_group, and VK_KHR_timeline_semaphore. This also adds a pipeline stage to the semaphore signal operation, mirroring the existing pipeline stage specification for wait operations.

Other miscellaneous changes include:

  • Events can now be specified as interacting only with the device, allowing more efficient access to the underlying object.

  • Image memory barriers that do not perform an image layout transition can be specified by setting oldLayout equal to newLayout.

  • Queue family ownership transfer parameters are simplified in some cases.

  • Extensions with commands or functions with a PipelineStageFlags or PipelineStageFlagBits parameter have had those APIs replaced with equivalents using PipelineStageFlags2KHR.

  • The new event and barrier interfaces are now more extensible for future changes.

  • Relevant pipeline stage masks can now be specified as empty with the new PIPELINE_STAGE_NONE_KHR and PIPELINE_STAGE_2_NONE_KHR values.

  • MemoryBarrier2KHR can be chained to SubpassDependency2, overriding the original 32-bit stage and access masks.

New Base Types

New Commands

New Structures

New Enums

New Bitmasks

New Enum Constants

If VK_EXT_blend_operation_advanced is supported:

If VK_EXT_conditional_rendering is supported:

If VK_EXT_device_generated_commands is supported:

If VK_EXT_fragment_density_map is supported:

If VK_EXT_mesh_shader is supported:

If VK_EXT_transform_feedback is supported:

If VK_KHR_acceleration_structure is supported:

If VK_KHR_fragment_shading_rate is supported:

If VK_KHR_ray_tracing_pipeline is supported:

If VK_NV_device_generated_commands is supported:

If VK_NV_mesh_shader is supported:

If VK_NV_ray_tracing is supported:

If VK_NV_shading_rate_image is supported:

Promotion to Vulkan 1.3

Vulkan APIs in this extension are included in core Vulkan 1.3, with the KHR suffix omitted. External interactions defined by this extension, such as SPIR-V token names, retain their original names. The original Vulkan API names are still available as aliases of the core functionality.

Examples

See https://github.com/KhronosGroup/Vulkan-Docs/wiki/Synchronization-Examples

Version History

  • Revision 1, 2020-12-03 (Tobias Hector)

    • Internal revisions

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.

  • 16 types
  • 6 values
  • Packagevulkan-3.27
  • Exports96
  • LanguageGHC2021
  • LicenceBSD-3-Clause
  • SourceVK_KHR_synchronization2.hs