Synchronization Validation is implemented in the VK_LAYER_KHRONOS_validation layer
. When enabled, the Synchronization Object is intended to identify resource access conflicts due to missing or incorrect synchronization operations between actions (Draw, Copy, Dispatch, Blit) reading or writing the same regions of memory.
Synchronization will ideally be run periodically after resolving any outstanding validation checks from all other validation objects, so that issues may be addressed in early stages of development.
The specific areas covered by this layer are currently tracked in the Synchronization Validation Project. Requests for additional checks can be requested by creating a Github issue.
For an overview of how to configure layers, refer to the Layers Overview and Configuration document.
Synchronization Validation settings are managed by configuring the Validation Layer. These settings are described in the VK_LAYER_KHRONOS_validation document.
Synchronization Validation settings can also be enabled and configured using the Vulkan Configurator included with the Vulkan SDK.
The pipelined and multi-threaded nature of Vulkan makes it particularly important for applications to correctly insert needed synchronization primitives, and for validation to diagnose unprotected memory access hazards. Synchronization reports the presence of access hazards including information to identify the Vulkan operations which are in conflict. The reported hazards are:
VK_KHR_synchronization2
extensionTo debug synchronization validation issues (all platforms):
vkCreateDebugUtilsMessengerEXT
with the VK_DEBUG_REPORT_ERROR_BIT_EXT
set.vkCmd
... command with a hazard is recorded.On Windows, Synchronization Validation can be run using just vkconfig and the debugger without defining a callback:
vkCmd
... command with a hazard is recorded.All synchronization error messages begin with SYNC-<hazard name>. The message body is constructed:
<cmd name>: Hazard <hazard name> <command specific details> Access info (<...>)
Command specific details typically include the specifics of the access within the current command. The Access info is common to all Synchronization Validation error messages.
VK_SUBPASS_EXTERNAL
when memory barriers are needed.Access info read_barrier
and write_barrier
values of 0, reflect the absence of any barrier, and can indicate an insufficient or incorrect source mask (first scope).VK_PIPELINE_STAGE_ALL_COMMANDS_BIT
, VK_ACCESS_MEMORY_READ_BIT
|VK_ACCESS_MEMORY_WRITE_BIT
for both src*Mask
and dst*Mask
fields to locate missing barriers. If the inserted barrier resolves a hazard, the conflicting access happens-before the inserted barrier. (Be sure to delete later.)Synchronization Examples https://github.com/KhronosGroup/Vulkan-Docs/wiki/Synchronization-Examples
Keeping your GPU fed without getting bitten https://www.youtube.com/watch?v=oF7vOTTaAh4
Yet another blog explaining Vulkan synchronization http://themaister.net/blog/2019/08/14/yet-another-blog-explaining-vulkan-synchronization/
A Guide to Vulkan Synchronization Validation https://www.khronos.org/news/permalink/blog-a-guide-to-vulkan-synchronization-validation