Fix cross-reference paths in Synchronization tutorial chapters

gpx1000 · gpx1000 · commit b3d1d124fdac · 2026-03-20T23:38:06.000-07:00
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.
diff --git a/en/Synchronization/Anatomy_of_a_Dependency/01_introduction.adoc b/en/Synchronization/Anatomy_of_a_Dependency/01_introduction.adoc
@@ -5,7 +5,7 @@
 
 Every Vulkan operation, from a simple color clear to a complex ray-traced reflections pass, lives and breathes by the dependencies we define. In this chapter, we take a deep dive into the core mechanics of how data actually moves through the Vulkan pipeline and why synchronization is about much more than just "setting a bitmask."
 
-image::../../../images/rendering_pipeline_flowchart.png[Rendering Pipeline Flowchart, width=600, alt="Flowchart showing the stages of a modern Vulkan rendering pipeline"]
+image::/images/rendering_pipeline_flowchart.png[Rendering Pipeline Flowchart, width=600, alt="Flowchart showing the stages of a modern Vulkan rendering pipeline"]
 
 To truly master synchronization, we first need to break down what happens when the GPU processes your commands. We often talk about the GPU as a "massive parallel processor," but what does that mean for data integrity? We'll start by deconstructing the fundamental differences between **Execution Dependencies** (the "when" of GPU work) and **Memory Dependencies** (the "where" and "visibility" of data).
 
@@ -22,4 +22,4 @@ By the end of this chapter, you’ll have a clear understanding of the "handshak
 
 == Navigation
 
-Previous: xref:../introduction.adoc[Introduction] | Next: xref:02_execution_vs_memory.adoc[Execution vs. Memory Dependencies]
+Previous: xref:Synchronization/introduction.adoc[Introduction] | Next: xref:Synchronization/Anatomy_of_a_Dependency/02_execution_vs_memory.adoc[Execution vs. Memory Dependencies]
diff --git a/en/Synchronization/Anatomy_of_a_Dependency/02_execution_vs_memory.adoc b/en/Synchronization/Anatomy_of_a_Dependency/02_execution_vs_memory.adoc
@@ -58,4 +58,4 @@ For our textures and vertex buffers, we use `DeviceLocal` memory for maximum per
 
 == Navigation
 
-Previous: xref:01_introduction.adoc[Introduction] | Next: xref:03_sync2_advantage.adoc[The Synchronization 2 Advantage]
+Previous: xref:Synchronization/Anatomy_of_a_Dependency/01_introduction.adoc[Introduction] | Next: xref:Synchronization/Anatomy_of_a_Dependency/03_sync2_advantage.adoc[The Synchronization 2 Advantage]
diff --git a/en/Synchronization/Anatomy_of_a_Dependency/03_sync2_advantage.adoc b/en/Synchronization/Anatomy_of_a_Dependency/03_sync2_advantage.adoc
@@ -29,7 +29,7 @@ Notice the problem? The `srcStageMask` and `dstStageMask` were passed as argumen
 
 This led to "over-synchronization." By merging the stages at the function level, you were inadvertently telling the GPU to wait for *all* the source stages to finish before *any* of the destination stages could start. You were creating a bottleneck where one didn't need to exist.
 
-image::{imagesdir}/sync2_problem_over_sync.svg[Legacy Synchronization Log Jam, width=600, align="center"]
+image::/images/sync2_problem_over_sync.svg[Legacy Synchronization Log Jam, width=600, align="center"]
 
 == The "Chain of Intent": Unification with vk::DependencyInfo
 
@@ -56,7 +56,7 @@ vk::DependencyInfo dependencyInfo{
 commandBuffer.pipelineBarrier2(dependencyInfo);
 ----
 
-image::{imagesdir}/sync2_solution_granular.svg[Synchronization 2 Granular Control, width=600, align="center"]
+image::/images/sync2_solution_granular.svg[Synchronization 2 Granular Control, width=600, align="center"]
 
 This is a massive win for human readability. When you look at that `imageBarrier` block, you see a complete "handshake." You know exactly what work is finishing (`src`) and exactly what work is waiting (`dst`). There's no need to hunt through function arguments or global variables to find the other half of the dependency.
 
@@ -192,4 +192,4 @@ In the next section, we'll dive deeper into how to pick the right stages and fla
 
 == Navigation
 
-Previous: xref:02_execution_vs_memory.adoc[Execution vs. Memory Dependencies] | Next: xref:04_refined_pipeline_stages.adoc[Refined Pipeline Stages]
+Previous: xref:Synchronization/Anatomy_of_a_Dependency/02_execution_vs_memory.adoc[Execution vs. Memory Dependencies] | Next: xref:Synchronization/Anatomy_of_a_Dependency/04_refined_pipeline_stages.adoc[Refined Pipeline Stages]
diff --git a/en/Synchronization/Anatomy_of_a_Dependency/04_refined_pipeline_stages.adoc b/en/Synchronization/Anatomy_of_a_Dependency/04_refined_pipeline_stages.adoc
@@ -9,7 +9,7 @@ In the previous sections, we saw how Synchronization 2 unifies the API. But the
 
 When you use an overly broad stage mask, you create what’s known as a **Pipeline Bubble**. Modern GPUs are designed to keep as many specialized hardware units—the rasterizers, the compute cores, the fixed-function blit engines—busy as possible. If you tell the GPU to wait at `eAllCommands`, you are essentially draining the entire pipeline. The GPU must wait until every previous operation is completely finished before it can start even the smallest part of the next operation.
 
-image::../../../images/vulkan_pipeline_block_diagram.png[Vulkan Pipeline Block Diagram, width=800, alt="A block diagram of the Vulkan graphics pipeline showing its various stages"]
+image::/images/vulkan_pipeline_block_diagram.png[Vulkan Pipeline Block Diagram, width=800, alt="A block diagram of the Vulkan graphics pipeline showing its various stages"]
 
 With Synchronization 2, we can be far more surgical. If you're only interested in ensuring that a compute shader has finished writing to a storage buffer before a fragment shader reads it, you can target `eComputeShader` and `eFragmentShader` specifically. This allows other parts of the GPU, like the geometry engine or the rasterizer, to keep working on independent tasks.
 
@@ -56,4 +56,4 @@ Next, we'll take these foundational concepts and apply them to the most common s
 
 == Navigation
 
-Previous: xref:03_sync2_advantage.adoc[The Synchronization 2 Advantage] | Next: xref:../Pipeline_Barriers_Transitions/01_introduction.adoc[Pipeline Barriers and Transitions - Introduction]
+Previous: xref:Synchronization/Anatomy_of_a_Dependency/03_sync2_advantage.adoc[The Synchronization 2 Advantage] | Next: xref:Synchronization/Pipeline_Barriers_Transitions/01_introduction.adoc[Pipeline Barriers and Transitions - Introduction]
diff --git a/en/Synchronization/Async_Compute_Overlap/01_introduction.adoc b/en/Synchronization/Async_Compute_Overlap/01_introduction.adoc
@@ -25,4 +25,4 @@ By the end of this chapter, you'll be able to move your engine from a serial seq
 
 == Navigation
 
-Previous: xref:../Frame_in_Flight/03_resource_lifetimes.adoc[Resource Lifetimes] | Next: xref:02_maximizing_throughput.adoc[Maximizing Throughput]
+Previous: xref:Synchronization/Frame_in_Flight/03_resource_lifetimes.adoc[Resource Lifetimes] | Next: xref:Synchronization/Async_Compute_Overlap/02_maximizing_throughput.adoc[Maximizing Throughput]
diff --git a/en/Synchronization/Async_Compute_Overlap/02_maximizing_throughput.adoc b/en/Synchronization/Async_Compute_Overlap/02_maximizing_throughput.adoc
@@ -65,4 +65,4 @@ In the next section, we'll see a concrete implementation of this pattern: async
 
 == Navigation
 
-Previous: xref:01_introduction.adoc[Introduction] | Next: xref:03_async_post_processing.adoc[Async Post-Processing]
+Previous: xref:Synchronization/Async_Compute_Overlap/01_introduction.adoc[Introduction] | Next: xref:Synchronization/Async_Compute_Overlap/03_async_post_processing.adoc[Async Post-Processing]
diff --git a/en/Synchronization/Async_Compute_Overlap/03_async_post_processing.adoc b/en/Synchronization/Async_Compute_Overlap/03_async_post_processing.adoc
@@ -67,4 +67,4 @@ In the final section of this chapter, we'll look at how to identify and eliminat
 
 == Navigation
 
-Previous: xref:02_maximizing_throughput.adoc[Maximizing Throughput] | Next: xref:04_bubble_problem.adoc[The Bubble Problem]
+Previous: xref:Synchronization/Async_Compute_Overlap/02_maximizing_throughput.adoc[Maximizing Throughput] | Next: xref:Synchronization/Async_Compute_Overlap/04_bubble_problem.adoc[The Bubble Problem]
diff --git a/en/Synchronization/Async_Compute_Overlap/04_bubble_problem.adoc b/en/Synchronization/Async_Compute_Overlap/04_bubble_problem.adoc
@@ -7,7 +7,7 @@ A "bubble" in the GPU timeline is a period where some units are idle because the
 
 To find these, we use hardware profilers like **NVIDIA Nsight Graphics**, **AMD Radeon GPU Profiler**, or even the **LunarG Synchronization Validation** layer. In a profiler, a bubble looks like a gap in the timeline where the Graphics or Compute rows are empty while the other is busy.
 
-image::../../../images/vulkan_simplified_pipeline.svg[Vulkan Simplified Pipeline, width=400, alt="Simplified diagram of the Vulkan pipeline used to illustrate where bubbles can occur"]
+image::/images/vulkan_simplified_pipeline.svg[Vulkan Simplified Pipeline, width=400, alt="Simplified diagram of the Vulkan pipeline used to illustrate where bubbles can occur"]
 
 == Common Causes of Bubbles
 
@@ -27,4 +27,4 @@ By systematically finding and eliminating these bubbles, you move from a rendere
 
 == Navigation
 
-Previous: xref:03_async_post_processing.adoc[Async Post-Processing] | Next: xref:../Transfer_Queues_Streaming/01_introduction.adoc[Transfer Queues & Asset Streaming Sync]
+Previous: xref:Synchronization/Async_Compute_Overlap/03_async_post_processing.adoc[Async Post-Processing] | Next: xref:Synchronization/Transfer_Queues_Streaming/01_introduction.adoc[Transfer Queues & Asset Streaming Sync]
diff --git a/en/Synchronization/Dynamic_Rendering_Sync/01_introduction.adoc b/en/Synchronization/Dynamic_Rendering_Sync/01_introduction.adoc
@@ -24,4 +24,4 @@ By the end of this chapter, you'll be able to confidently architect a high-perfo
 
 == Navigation
 
-Previous: xref:../Transfer_Queues_Streaming/03_staging_sync.adoc[Staging Synchronization] | Next: xref:02_subpass_replacement.adoc[Subpass Replacement]
+Previous: xref:Synchronization/Transfer_Queues_Streaming/03_staging_sync.adoc[Staging Synchronization] | Next: xref:Synchronization/Dynamic_Rendering_Sync/02_subpass_replacement.adoc[Subpass Replacement]
diff --git a/en/Synchronization/Dynamic_Rendering_Sync/02_subpass_replacement.adoc b/en/Synchronization/Dynamic_Rendering_Sync/02_subpass_replacement.adoc
@@ -60,4 +60,4 @@ This explicit approach is what allowed us to easily add **Forward+ Lighting** to
 
 == Navigation
 
-Previous: xref:01_introduction.adoc[Introduction] | Next: xref:03_local_read_sync.adoc[Local Read Sync]
+Previous: xref:Synchronization/Dynamic_Rendering_Sync/01_introduction.adoc[Introduction] | Next: xref:Synchronization/Dynamic_Rendering_Sync/03_local_read_sync.adoc[Local Read Sync]
diff --git a/en/Synchronization/Dynamic_Rendering_Sync/03_local_read_sync.adoc b/en/Synchronization/Dynamic_Rendering_Sync/03_local_read_sync.adoc
@@ -64,4 +64,4 @@ By mastering local read synchronization, you can build a modern deferred rendere
 
 == Navigation
 
-Previous: xref:02_subpass_replacement.adoc[Subpass Replacement] | Next: xref:../Host_Image_Copies_Memory_Sync/01_introduction.adoc[Host Image Copies & Memory Mapped Sync]
+Previous: xref:Synchronization/Dynamic_Rendering_Sync/02_subpass_replacement.adoc[Subpass Replacement] | Next: xref:Synchronization/Host_Image_Copies_Memory_Sync/01_introduction.adoc[Host Image Copies & Memory Mapped Sync]
diff --git a/en/Synchronization/Frame_in_Flight/01_introduction.adoc b/en/Synchronization/Frame_in_Flight/01_introduction.adoc
@@ -27,4 +27,4 @@ Let's begin by looking at how to rebuild the heartbeat of our engine: the main r
 
 == Navigation
 
-Previous: xref:../Timeline_Semaphores/04_wait_before_signal.adoc[Wait-Before-Signal Submission] | Next: xref:02_managing_concurrent_frames.adoc[Managing Concurrent Frames]
+Previous: xref:Synchronization/Timeline_Semaphores/04_wait_before_signal.adoc[Wait-Before-Signal Submission] | Next: xref:Synchronization/Frame_in_Flight/02_managing_concurrent_frames.adoc[Managing Concurrent Frames]
diff --git a/en/Synchronization/Frame_in_Flight/02_managing_concurrent_frames.adoc b/en/Synchronization/Frame_in_Flight/02_managing_concurrent_frames.adoc
@@ -103,4 +103,4 @@ This refactor will allow us to remove the `inFlightFences` array entirely, simpl
 
 == Navigation
 
-Previous: xref:01_introduction.adoc[Introduction] | Next: xref:03_resource_lifetimes.adoc[Resource Lifetimes]
+Previous: xref:Synchronization/Frame_in_Flight/01_introduction.adoc[Introduction] | Next: xref:Synchronization/Frame_in_Flight/03_resource_lifetimes.adoc[Resource Lifetimes]
diff --git a/en/Synchronization/Frame_in_Flight/03_resource_lifetimes.adoc b/en/Synchronization/Frame_in_Flight/03_resource_lifetimes.adoc
@@ -58,4 +58,4 @@ By moving to a timeline-based **Garbage Collection (GC)** system, we can be much
 
 == Navigation
 
-Previous: xref:02_managing_concurrent_frames.adoc[Managing Concurrent Frames] | Next: xref:../Async_Compute_Overlap/01_introduction.adoc[Asynchronous Compute & Execution Overlap - Introduction]
+Previous: xref:Synchronization/Frame_in_Flight/02_managing_concurrent_frames.adoc[Managing Concurrent Frames] | Next: xref:Synchronization/Async_Compute_Overlap/01_introduction.adoc[Asynchronous Compute & Execution Overlap - Introduction]
diff --git a/en/Synchronization/Host_Image_Copies_Memory_Sync/01_introduction.adoc b/en/Synchronization/Host_Image_Copies_Memory_Sync/01_introduction.adoc
@@ -25,4 +25,4 @@ By the end of this chapter, you'll have a complete understanding of how to manag
 
 == Navigation
 
-Previous: xref:../Dynamic_Rendering_Sync/03_local_read_sync.adoc[Local Read Sync] | Next: xref:02_cpu_to_image_access.adoc[Direct CPU-to-Image Access]
+Previous: xref:Synchronization/Dynamic_Rendering_Sync/03_local_read_sync.adoc[Local Read Sync] | Next: xref:Synchronization/Host_Image_Copies_Memory_Sync/02_cpu_to_image_access.adoc[Direct CPU-to-Image Access]
diff --git a/en/Synchronization/Host_Image_Copies_Memory_Sync/02_cpu_to_image_access.adoc b/en/Synchronization/Host_Image_Copies_Memory_Sync/02_cpu_to_image_access.adoc
@@ -53,4 +53,4 @@ In the next section, we'll see how to handle the synchronization required to ens
 
 == Navigation
 
-Previous: xref:01_introduction.adoc[Introduction] | Next: xref:03_visibility_flushes.adoc[Visibility & Flushes]
+Previous: xref:Synchronization/Host_Image_Copies_Memory_Sync/01_introduction.adoc[Introduction] | Next: xref:Synchronization/Host_Image_Copies_Memory_Sync/03_visibility_flushes.adoc[Visibility & Flushes]
diff --git a/en/Synchronization/Host_Image_Copies_Memory_Sync/03_visibility_flushes.adoc b/en/Synchronization/Host_Image_Copies_Memory_Sync/03_visibility_flushes.adoc
@@ -55,4 +55,4 @@ By mastering these host-device handshakes, you can build a renderer that is both
 
 == Navigation
 
-Previous: xref:02_cpu_to_image_access.adoc[Direct CPU-to-Image Access] | Next: xref:../Synchronization_Validation/01_introduction.adoc[Debugging with Synchronization Validation]
+Previous: xref:Synchronization/Host_Image_Copies_Memory_Sync/02_cpu_to_image_access.adoc[Direct CPU-to-Image Access] | Next: xref:Synchronization/Synchronization_Validation/01_introduction.adoc[Debugging with Synchronization Validation]
diff --git a/en/Synchronization/Pipeline_Barriers_Transitions/01_introduction.adoc b/en/Synchronization/Pipeline_Barriers_Transitions/01_introduction.adoc
@@ -15,4 +15,4 @@ Let's begin by looking at the workhorse of modern Vulkan synchronization: the Im
 
 == Navigation
 
-Previous: xref:../Anatomy_of_a_Dependency/04_refined_pipeline_stages.adoc[Refined Pipeline Stages] | Next: xref:02_image_barrier.adoc[The Image Barrier]
+Previous: xref:Synchronization/Anatomy_of_a_Dependency/04_refined_pipeline_stages.adoc[Refined Pipeline Stages] | Next: xref:Synchronization/Pipeline_Barriers_Transitions/02_image_barrier.adoc[The Image Barrier]
diff --git a/en/Synchronization/Pipeline_Barriers_Transitions/02_image_barrier.adoc b/en/Synchronization/Pipeline_Barriers_Transitions/02_image_barrier.adoc
@@ -7,7 +7,7 @@ In the world of modern Vulkan, the image memory barrier is the definitive tool f
 
 If we want to write to an image as a color attachment, the GPU hardware expects it to be in `VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL`. If we later want to sample that same image in a shader, it must be transitioned to `VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL`. This is not just a driver-side "flag"—on some hardware, this transition might trigger a physical reorganization of the data or a cache flush.
 
-image::../../../images/image_barrier_anatomy.svg[Anatomy of an Image Barrier]
+image::/images/image_barrier_anatomy.svg[Anatomy of an Image Barrier]
 
 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.
 
@@ -117,4 +117,4 @@ One specific trick we use in `Simple Engine` is the **Layout Tracking** system.
 
 == Navigation
 
-Previous: xref:01_introduction.adoc[Introduction] | Next: xref:03_queue_family_ownership.adoc[Queue Family Ownership]
+Previous: xref:Synchronization/Pipeline_Barriers_Transitions/01_introduction.adoc[Introduction] | Next: xref:Synchronization/Pipeline_Barriers_Transitions/03_queue_family_ownership.adoc[Queue Family Ownership]
diff --git a/en/Synchronization/Pipeline_Barriers_Transitions/03_queue_family_ownership.adoc b/en/Synchronization/Pipeline_Barriers_Transitions/03_queue_family_ownership.adoc
@@ -71,4 +71,4 @@ However, even with `eConcurrent`, you still need to synchronize the *execution*
 
 == Navigation
 
-Previous: xref:02_image_barrier.adoc[The Image Barrier] | Next: xref:04_global_vs_local_barriers.adoc[Global vs. Local Barriers]
+Previous: xref:Synchronization/Pipeline_Barriers_Transitions/02_image_barrier.adoc[The Image Barrier] | Next: xref:Synchronization/Pipeline_Barriers_Transitions/04_global_vs_local_barriers.adoc[Global vs. Local Barriers]
diff --git a/en/Synchronization/Pipeline_Barriers_Transitions/04_global_vs_local_barriers.adoc b/en/Synchronization/Pipeline_Barriers_Transitions/04_global_vs_local_barriers.adoc
@@ -62,4 +62,4 @@ One area where `Simple Engine` could be further optimized is in the consolidatio
 
 == Navigation
 
-Previous: xref:03_queue_family_ownership.adoc[Queue Family Ownership] | Next: xref:../Timeline_Semaphores/01_introduction.adoc[Timeline Semaphores: The Master Clock]
+Previous: xref:Synchronization/Pipeline_Barriers_Transitions/03_queue_family_ownership.adoc[Queue Family Ownership] | Next: xref:Synchronization/Timeline_Semaphores/01_introduction.adoc[Timeline Semaphores: The Master Clock]
diff --git a/en/Synchronization/Profiling_Optimization/01_introduction.adoc b/en/Synchronization/Profiling_Optimization/01_introduction.adoc
@@ -27,4 +27,4 @@ By the end of this chapter, you'll have the knowledge and the tools to take your
 
 == Navigation
 
-Previous: xref:../Synchronization_Validation/03_interpreting_vuids.adoc[Interpreting VUIDs] | Next: xref:02_barrier_batching.adoc[Barrier Batching]
+Previous: xref:Synchronization/Synchronization_Validation/03_interpreting_vuids.adoc[Interpreting VUIDs] | Next: xref:Synchronization/Profiling_Optimization/02_barrier_batching.adoc[Barrier Batching]
diff --git a/en/Synchronization/Profiling_Optimization/02_barrier_batching.adoc b/en/Synchronization/Profiling_Optimization/02_barrier_batching.adoc
@@ -49,4 +49,4 @@ One optimization we plan for a future version of `Simple Engine` is to centraliz
 
 == Navigation
 
-Previous: xref:01_introduction.adoc[Introduction] | Next: xref:03_visualizing_stalls.adoc[Visualizing Stalls]
+Previous: xref:Synchronization/Profiling_Optimization/01_introduction.adoc[Introduction] | Next: xref:Synchronization/Profiling_Optimization/03_visualizing_stalls.adoc[Visualizing Stalls]
diff --git a/en/Synchronization/Profiling_Optimization/03_visualizing_stalls.adoc b/en/Synchronization/Profiling_Optimization/03_visualizing_stalls.adoc
@@ -32,4 +32,4 @@ Keep profiling, keep refining, and keep building!
 
 == Navigation
 
-Previous: xref:02_barrier_batching.adoc[Barrier Batching] | Next: xref:../introduction.adoc[Back to Introduction]
+Previous: xref:Synchronization/Profiling_Optimization/02_barrier_batching.adoc[Barrier Batching] | Next: xref:Synchronization/introduction.adoc[Back to Introduction]
diff --git a/en/Synchronization/Synchronization_Validation/01_introduction.adoc b/en/Synchronization/Synchronization_Validation/01_introduction.adoc
@@ -27,4 +27,4 @@ By the end of this chapter, you'll have the tools and the knowledge to ensure th
 
 == Navigation
 
-Previous: xref:../Host_Image_Copies_Memory_Sync/03_visibility_flushes.adoc[Visibility & Flushes] | Next: xref:02_validation_layer.adoc[The Validation Layer]
+Previous: xref:Synchronization/Host_Image_Copies_Memory_Sync/03_visibility_flushes.adoc[Visibility & Flushes] | Next: xref:Synchronization/Synchronization_Validation/02_validation_layer.adoc[The Validation Layer]
diff --git a/en/Synchronization/Synchronization_Validation/02_validation_layer.adoc b/en/Synchronization/Synchronization_Validation/02_validation_layer.adoc
@@ -50,4 +50,4 @@ In the next section, we'll see how to decipher the error messages this layer pro
 
 == Navigation
 
-Previous: xref:01_introduction.adoc[Introduction] | Next: xref:03_interpreting_vuids.adoc[Interpreting VUIDs]
+Previous: xref:Synchronization/Synchronization_Validation/01_introduction.adoc[Introduction] | Next: xref:Synchronization/Synchronization_Validation/03_interpreting_vuids.adoc[Interpreting VUIDs]
diff --git a/en/Synchronization/Synchronization_Validation/03_interpreting_vuids.adoc b/en/Synchronization/Synchronization_Validation/03_interpreting_vuids.adoc
@@ -37,4 +37,4 @@ By treating every VUID as a learning opportunity, you can systematically improve
 
 == Navigation
 
-Previous: xref:02_validation_layer.adoc[The Validation Layer] | Next: xref:../Profiling_Optimization/01_introduction.adoc[Profiling, Batching, and Optimization]
+Previous: xref:Synchronization/Synchronization_Validation/02_validation_layer.adoc[The Validation Layer] | Next: xref:Synchronization/Profiling_Optimization/01_introduction.adoc[Profiling, Batching, and Optimization]
diff --git a/en/Synchronization/Timeline_Semaphores/01_introduction.adoc b/en/Synchronization/Timeline_Semaphores/01_introduction.adoc
@@ -25,4 +25,4 @@ Let's begin by unifying our synchronization primitives.
 
 == Navigation
 
-Previous: xref:../Pipeline_Barriers_Transitions/04_global_vs_local_barriers.adoc[Global vs. Local Barriers] | Next: xref:02_unifying_sync.adoc[Unifying Synchronization]
+Previous: xref:Synchronization/Pipeline_Barriers_Transitions/04_global_vs_local_barriers.adoc[Global vs. Local Barriers] | Next: xref:Synchronization/Timeline_Semaphores/02_unifying_sync.adoc[Unifying Synchronization]
diff --git a/en/Synchronization/Timeline_Semaphores/02_unifying_sync.adoc b/en/Synchronization/Timeline_Semaphores/02_unifying_sync.adoc
@@ -70,4 +70,4 @@ Our next major architectural update will replace these with a single `Renderer::
 
 == Navigation
 
-Previous: xref:01_introduction.adoc[Introduction] | Next: xref:03_monotonic_counter.adoc[The Monotonic Counter]
+Previous: xref:Synchronization/Timeline_Semaphores/01_introduction.adoc[Introduction] | Next: xref:Synchronization/Timeline_Semaphores/03_monotonic_counter.adoc[The Monotonic Counter]
diff --git a/en/Synchronization/Timeline_Semaphores/03_monotonic_counter.adoc b/en/Synchronization/Timeline_Semaphores/03_monotonic_counter.adoc
@@ -47,4 +47,4 @@ This becomes incredibly powerful when paired with our `MemoryPool`. Instead of u
 
 == Navigation
 
-Previous: xref:02_unifying_sync.adoc[Unifying Synchronization] | Next: xref:04_wait_before_signal.adoc[Wait-Before-Signal Submission]
+Previous: xref:Synchronization/Timeline_Semaphores/02_unifying_sync.adoc[Unifying Synchronization] | Next: xref:Synchronization/Timeline_Semaphores/04_wait_before_signal.adoc[Wait-Before-Signal Submission]
diff --git a/en/Synchronization/Timeline_Semaphores/04_wait_before_signal.adoc b/en/Synchronization/Timeline_Semaphores/04_wait_before_signal.adoc
@@ -66,4 +66,4 @@ With wait-before-signal, our `Renderer` will simply record its commands to wait
 
 == Navigation
 
-Previous: xref:03_monotonic_counter.adoc[The Monotonic Counter] | Next: xref:../Frame_in_Flight/01_introduction.adoc[Frame-in-Flight Architecture]
+Previous: xref:Synchronization/Timeline_Semaphores/03_monotonic_counter.adoc[The Monotonic Counter] | Next: xref:Synchronization/Frame_in_Flight/01_introduction.adoc[Frame-in-Flight Architecture]
diff --git a/en/Synchronization/Transfer_Queues_Streaming/01_introduction.adoc b/en/Synchronization/Transfer_Queues_Streaming/01_introduction.adoc
diff --git a/en/Synchronization/Transfer_Queues_Streaming/02_non_blocking_uploads.adoc b/en/Synchronization/Transfer_Queues_Streaming/02_non_blocking_uploads.adoc
diff --git a/en/Synchronization/Transfer_Queues_Streaming/03_staging_sync.adoc b/en/Synchronization/Transfer_Queues_Streaming/03_staging_sync.adoc
diff --git a/en/Synchronization/introduction.adoc b/en/Synchronization/introduction.adoc

Original file line number	Diff line number	Diff line change
@@ -58,4 +58,4 @@ For our textures and vertex buffers, we use `DeviceLocal` memory for maximum per
`58`	`58`
`59`	`59`	`== Navigation`
`60`	`60`
`61`		`-Previous: xref:01_introduction.adoc[Introduction] \| Next: xref:03_sync2_advantage.adoc[The Synchronization 2 Advantage]`
	`61`	`+Previous: xref:Synchronization/Anatomy_of_a_Dependency/01_introduction.adoc[Introduction] \| Next: xref:Synchronization/Anatomy_of_a_Dependency/03_sync2_advantage.adoc[The Synchronization 2 Advantage]`
Original file line number	Diff line number	Diff line change
`@@ -25,4 +25,4 @@ By the end of this chapter, you'll be able to move your engine from a serial seq`
`25`	`25`
`26`	`26`	`== Navigation`
`27`	`27`
`28`		`-Previous: xref:../Frame_in_Flight/03_resource_lifetimes.adoc[Resource Lifetimes] \| Next: xref:02_maximizing_throughput.adoc[Maximizing Throughput]`
	`28`	`+Previous: xref:Synchronization/Frame_in_Flight/03_resource_lifetimes.adoc[Resource Lifetimes] \| Next: xref:Synchronization/Async_Compute_Overlap/02_maximizing_throughput.adoc[Maximizing Throughput]`
Original file line number	Diff line number	Diff line change
`@@ -65,4 +65,4 @@ In the next section, we'll see a concrete implementation of this pattern: async`
`65`	`65`
`66`	`66`	`== Navigation`
`67`	`67`
`68`		`-Previous: xref:01_introduction.adoc[Introduction] \| Next: xref:03_async_post_processing.adoc[Async Post-Processing]`
	`68`	`+Previous: xref:Synchronization/Async_Compute_Overlap/01_introduction.adoc[Introduction] \| Next: xref:Synchronization/Async_Compute_Overlap/03_async_post_processing.adoc[Async Post-Processing]`
Original file line number	Diff line number	Diff line change
`@@ -67,4 +67,4 @@ In the final section of this chapter, we'll look at how to identify and eliminat`
`67`	`67`
`68`	`68`	`== Navigation`
`69`	`69`
`70`		`-Previous: xref:02_maximizing_throughput.adoc[Maximizing Throughput] \| Next: xref:04_bubble_problem.adoc[The Bubble Problem]`
	`70`	`+Previous: xref:Synchronization/Async_Compute_Overlap/02_maximizing_throughput.adoc[Maximizing Throughput] \| Next: xref:Synchronization/Async_Compute_Overlap/04_bubble_problem.adoc[The Bubble Problem]`
Original file line number	Diff line number	Diff line change
`@@ -24,4 +24,4 @@ By the end of this chapter, you'll be able to confidently architect a high-perfo`
`24`	`24`
`25`	`25`	`== Navigation`
`26`	`26`
`27`		`-Previous: xref:../Transfer_Queues_Streaming/03_staging_sync.adoc[Staging Synchronization] \| Next: xref:02_subpass_replacement.adoc[Subpass Replacement]`
	`27`	`+Previous: xref:Synchronization/Transfer_Queues_Streaming/03_staging_sync.adoc[Staging Synchronization] \| Next: xref:Synchronization/Dynamic_Rendering_Sync/02_subpass_replacement.adoc[Subpass Replacement]`
Original file line number	Diff line number	Diff line change
`@@ -60,4 +60,4 @@ This explicit approach is what allowed us to easily add Forward+ Lighting to`
`60`	`60`
`61`	`61`	`== Navigation`
`62`	`62`
`63`		`-Previous: xref:01_introduction.adoc[Introduction] \| Next: xref:03_local_read_sync.adoc[Local Read Sync]`
	`63`	`+Previous: xref:Synchronization/Dynamic_Rendering_Sync/01_introduction.adoc[Introduction] \| Next: xref:Synchronization/Dynamic_Rendering_Sync/03_local_read_sync.adoc[Local Read Sync]`