Skip to content

Commit

Permalink
Remove xref from external links, fix link to tracy pdf (KhronosGroup#…
Browse files Browse the repository at this point in the history
…1221)

* Remove xref from external links, fix link to tracy pdf

* Fix sample linkage

* Fix link
  • Loading branch information
SaschaWillems authored Nov 7, 2024
1 parent 6f99ebe commit e86a1e1
Show file tree
Hide file tree
Showing 3 changed files with 6 additions and 6 deletions.
6 changes: 3 additions & 3 deletions docs/build.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
2 changes: 1 addition & 1 deletion samples/extensions/README.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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`]

Expand Down
4 changes: 2 additions & 2 deletions samples/extensions/dynamic_rendering_local_read/README.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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*:

Expand Down Expand Up @@ -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

Expand Down

0 comments on commit e86a1e1

Please sign in to comment.