diff --git a/docs/build.adoc b/docs/build.adoc
index b015af53c..4f817395a 100644
--- a/docs/build.adoc
+++ b/docs/build.adoc
@@ -94,12 +94,12 @@ Treat all warnings as errors
 
 === VKB_PROFILING
 
-Enable profiling using the xref:https://github.com/wolfpld/tracy[Tracy profiler].
+Enable profiling using the https://github.com/wolfpld/tracy[Tracy profiler].
 
 We currently use Tracy v0.10.0 if you do not use the correct Tracy Profiler version as the Tracy Client version used in Sample you will get a protocol mismatch error.
 
-Windows users can download the profiler from the xref:https://github.com/wolfpld/tracy/releases/tag/v0.10[Tracy v0.10.0 release page]
-Other platforms require the user to build the profiler from source see the xref:https://github.com/wolfpld/tracy/releases/tag/v0.10[Tracy.pdf documentation] for more information on how to build for your platform.
+Windows users can download the profiler from the https://github.com/wolfpld/tracy/releases/tag/v0.10[Tracy v0.10.0 release page]
+Other platforms require the user to build the profiler from source see the https://github.com/wolfpld/tracy/releases/download/v0.10/tracy.pdf[Tracy documentation (pdf)] for more information on how to build for your platform.
 
 Tracy is not currently enabled for Android builds. In the future, we may add support for this.
 
diff --git a/samples/extensions/README.adoc b/samples/extensions/README.adoc
index 196bc8652..2c682b0fc 100644
--- a/samples/extensions/README.adoc
+++ b/samples/extensions/README.adoc
@@ -36,7 +36,7 @@ Enables overestimation to generate fragments for every pixel touched instead of
 Demonstrates how to use Dynamic Rendering.
 Read the blog post here for discussion: (https://www.khronos.org/blog/streamlining-render-passes)
 
-=== xref:./extensions/dynamic_rendering_local_read/README.adoc[Dynamic Rendering local read]
+=== xref:./{extension_samplespath}dynamic_rendering_local_read/README.adoc[Dynamic Rendering local read]
 
 *Extension*: https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#VK_KHR_dynamic_rendering_local_read[`VK_KHR_dynamic_rendering_local_read`]
 
diff --git a/samples/extensions/dynamic_rendering_local_read/README.adoc b/samples/extensions/dynamic_rendering_local_read/README.adoc
index 10e816a72..bc893fc46 100644
--- a/samples/extensions/dynamic_rendering_local_read/README.adoc
+++ b/samples/extensions/dynamic_rendering_local_read/README.adoc
@@ -43,7 +43,7 @@ This is enabled by default, making the sample use dynamic rendering with local r
 
 == Comparison
 
-For a primer on the differences between renderpasses and dynamic rendering, see the readme of the xref:../dynamic_rendering/README.adoc[dynamic rendering sample].
+For a primer on the differences between renderpasses and dynamic rendering, see the readme of the xref:/samples/extensions/dynamic_rendering/README.adoc[dynamic rendering sample].
 
 Here is the comparison table from that example extended with the newly added features from `VK_KHR_dynamic_rendering_local_read` in *bold*:
 
@@ -80,7 +80,7 @@ The rendering setup for this sample looks like this:
 
 image::./images/deferred_setup.png[Deferred setup describing subpasses]
 
-A big criticism with renderpasses was how involved esp. the setup is. Getting renderpasses and subpasses incl. dependencies correct can be tricky and renderpasses are kinda hard to integrate into a dynamically changing setup, making them a hard fit for complex Vulkan projects like game engines. With dynamic rendering, setup is far less involved and moves mostly to command buffer creation. If you look at the sample you can easily spot how much code required by looking at the parts that are deactivated via the `dynamic_rendering_local_read` C++ define. More on this can be found in the xref:../dynamic_rendering/README.adoc[dynamic rendering sample] readme. For this sample we'll only look at draw time.
+A big criticism with renderpasses was how involved esp. the setup is. Getting renderpasses and subpasses incl. dependencies correct can be tricky and renderpasses are kinda hard to integrate into a dynamically changing setup, making them a hard fit for complex Vulkan projects like game engines. With dynamic rendering, setup is far less involved and moves mostly to command buffer creation. If you look at the sample you can easily spot how much code required by looking at the parts that are deactivated via the `dynamic_rendering_local_read` C++ define. More on this can be found in the xref:/samples/extensions/dynamic_rendering/README.adoc[dynamic rendering sample] readme. For this sample we'll only look at draw time.
 
 == Replacing subpasses for local reads