Add Synchronization 2 tutorial series #339
Add Synchronization 2 tutorial series #339gpx1000 wants to merge 2 commits intoKhronosGroup:mainfrom
Conversation
…pics Introduce comprehensive Synchronization 2 tutorial covering modern Vulkan synchronization patterns. Add chapters on dependency anatomy, pipeline barriers, timeline semaphores, frame-in-flight architecture, async compute, transfer queues, dynamic rendering sync, host image copies, and synchronization validation. Include practical examples from Simple Engine and guidance on debugging with validation layers and interpreting VUIDs.
Update all xref links to use absolute paths prefixed with 'Synchronization/' instead of relative paths. Correct image references to use absolute paths starting with '/images/'. This ensures proper navigation between chapters and correct image rendering across the Synchronization tutorial series.
There was a problem hiding this comment.
Did a first review run and added comments to the documentation where possible.
The information presented here is great, I'm just not sure if it's the best idea to have this as a separate part of the tutorial.
Here are some random additional thoughts that we could discuss:
- This duplicates some information we already have in the tutorial and/or the guide
- https://docs.vulkan.org/guide/latest/extensions/VK_KHR_synchronization2.html
- https://docs.vulkan.org/guide/latest/synchronization_examples.html
- Dynamic rendering, frames in flight and others are already used in the base tutorial
- This is actually an issue (I see with this), as it might also make maintaining the tutorial hard(er)
- It's heavily based on the simple game engine part of the tutorial
- So it at least should come after that part of the tutorial (in the navigation)
- It should have a few more links to existing resources, esp. the spec
- It could use some more images, some chapters are text only and feel like walls of text
So my thought after reading this was "Why a separate chapter, why not integrate this into the tutorial right away?"
| * Synchronization 2 | ||
| ** xref:Synchronization/introduction.adoc[Introduction] | ||
| ** Anatomy of a Dependency | ||
| *** xref:Synchronization/Anatomy_of_a_Dependency/01_introduction.adoc[Introduction] |
There was a problem hiding this comment.
Navigation is missing a lot of the new chapters. There's only links to the introduction chapters.
|
|
||
| * **The Hardware Perspective**: Understanding why execution barriers alone are not enough to prevent data corruption on modern, multi-cache GPUs. | ||
| * **Execution vs. Memory Dependencies**: Learning how to distinguish between stopping a stage and ensuring its data is actually readable by the next one. | ||
| * **The Synchronization 2 Advantage**: Why the new `vk::DependencyInfo` and `vkCmdPipelineBarrier2` are more than just a syntax cleanup—they are a fundamental shift in how we express intent to the driver. |
There was a problem hiding this comment.
Should be vk::CmdPipelineBarrier2 instead of vkCmdPipelineBarrier2.
| ** xref:courses/18_Ray_tracing/05_Shadow_transparency.adoc[Shadow transparency] | ||
| ** xref:courses/18_Ray_tracing/06_Reflections.adoc[Reflections] | ||
| ** xref:courses/18_Ray_tracing/07_Conclusion.adoc[Conclusion] | ||
| * Synchronization 2 |
There was a problem hiding this comment.
As this is heavily referencing the simple game engine, we should put this after the SGE chapter.
|
|
||
| == Implementation: Modernizing Simple Engine | ||
|
|
||
| While `Simple Engine`'s renderer has been largely modernized to use the `pipelineBarrier2` calls we've discussed, the codebase still contains "legacy islands" that we are in the process of refactoring. A prime example is the `PhysicsSystem` (`physics_system.cpp`), which still uses the old-style `pipelineBarrier` for synchronizing its compute dispatches. |
There was a problem hiding this comment.
One of the apostrophes caused the first line to be rendered as code instead of text.
|
|
||
| When we talk about "physical reorganization," we're referring to how different hardware units see the same bits. For instance, a Rasterizer might use a specialized tiled compression format (like Delta Color Compression) to save bandwidth. However, a Compute shader sampling that same image might not understand that compression. The layout transition ensures the data is "decompressed" or moved into a format that the next stage can consume. | ||
|
|
||
| == Anatomizing the Image Barrier |
There was a problem hiding this comment.
Very minor and mostly a language barrier issue: But I had to look up what "Anatomizing" actually means ^^
|
|
||
| In a simple Vulkan application, we might use the same queue for graphics, compute, and transfer work. This is easy to implement, but it's not efficient. Every time we submit a large transfer, the graphics queue has to stop what it's doing and wait for the transfer engine to finish. This creates a "stutter" in our frame rate. | ||
|
|
||
| By using a **Dedicated Transfer Queue**, we can perform these uploads in the background. The transfer engine is a specialized piece of hardware that can move data between memory locations without using the GPU's compute or graphics cores. By offloading these tasks, we can keep our main rendering pipeline running at full speed. |
There was a problem hiding this comment.
Should show how to actually get/identify a dedicated transfer queue.
|
|
||
| For most of Vulkan's history, if you wanted to move data into an image, you had to follow a very specific ritual: create a staging buffer, map it, write your data, record a `copyBufferToImage` command, and then submit that command buffer to a queue. While this is efficient for large, asynchronous uploads, it's a lot of overhead for simple, direct updates—like updating a small UI texture or a single mip level. | ||
|
|
||
| With the arrival of **Vulkan 1.4**, we have a powerful new tool: **Host Image Copies** (`VK_EXT_host_image_copy`). This feature allows the CPU to copy data directly into a GPU-optimal image without recording or submitting a single command buffer. It's the most direct way to move data between CPU and GPU memory. |
There was a problem hiding this comment.
Should have a note that support for host image copies is still optional in 1.4.
|
|
||
| == Enabling Sync Validation | ||
|
|
||
| The **LunarG Synchronization Validation** layer is not part of the standard `VK_LAYER_KHRONOS_validation` by default on all platforms. In many environments, you must explicitly enable it through the `vk_layer_settings.txt` file or through your engine's `vk::InstanceCreateInfo`. |
There was a problem hiding this comment.
Could also have a note on using vkconfig instead, which lets you easily toggle sync validation.
|
|
||
| ---- | ||
| VALIDATION [SYNC-HAZARD-READ-AFTER-WRITE] (0x01234567) | ||
| VUID: VUID-vkCmdDraw-None-07888 |
There was a problem hiding this comment.
I think this is the wrong VUID for this message. That VUID refers to texel buffers and atomic usage? https://docs.vulkan.org/refpages/latest/refpages/source/vkCmdDraw.html#VUID-vkCmdDraw-None-07888
|
|
||
| == Hardware Profilers | ||
|
|
||
| The most effective way to optimize your synchronization code is to see what the GPU is actually doing. We use hardware profilers like **NVIDIA Nsight Graphics**, **AMD Radeon GPU Profiler**, or **Intel Graphics Performance Analyzers** to visualize the pipeline. |
There was a problem hiding this comment.
Intel Graphics Performance Analyzers has been discontinued in 2025.
2 participants
with validation and advanced topics.
Introduce comprehensive Synchronization 2 tutorial covering modern Vulkan synchronization patterns. Add chapters on dependency anatomy, pipeline barriers, timeline semaphores, frame-in-flight architecture, async compute, transfer queues, dynamic rendering sync, host image copies, and synchronization validation. Include practical examples from Simple Engine and guidance on debugging with validation layers and interpreting VUIDs.