Skip to content

Commit 860bb38

Browse files
committed
fixed links on the compute shader page (tested locally)
1 parent 1c18195 commit 860bb38

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

en/11_Compute_Shader.adoc

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -199,7 +199,7 @@ outputImage[int2(gl_GlobalInvocationID.xy)] = pixel;
199199

200200
== Compute queue families
201201

202-
In the link:03_Drawing_a_triangle/00_Setup/03_Physical_devices_and_queue_families.adoc[physical device and queue families chapter],
202+
In the xref:03_Drawing_a_triangle/00_Setup/03_Physical_devices_and_queue_families.adoc[physical device and queue families chapter],
203203
we have already learned about queue families and how to select a graphics queue family.
204204
Compute uses the queue family properties flag bit `vk::QueueFlagBits::eCompute`.
205205
So if we want to do compute work, we need to get a queue from a queue family that supports compute.
@@ -589,8 +589,8 @@ Wrong or lacking synchronization may result in the vertex stage starting to draw
589589
So we must make sure that those cases don't happen by properly synchronizing the graphics and the compute load.
590590
There are different ways of doing so, depending on how you submit your
591591
compute workload, but in our case with two separate submits, we'll be using
592-
link:03_Drawing_a_triangle/03_Drawing/02_Rendering_and_presentation.adoc[semaphores] and
593-
link:03_Drawing_a_triangle/03_Drawing/02_Rendering_and_presentation.adoc[fences] to ensure that the vertex shader won't start fetching
592+
xref:03_Drawing_a_triangle/03_Drawing/02_Rendering_and_presentation.adoc[semaphores] and
593+
xref:03_Drawing_a_triangle/03_Drawing/02_Rendering_and_presentation.adoc[fences] to ensure that the vertex shader won't start fetching
594594
vertices until the compute shader has finished updating them.
595595

596596
This is necessary as even though the two submits are ordered one-after-another, there is no guarantee that they execute on the GPU in this order.
@@ -600,7 +600,7 @@ So we first add a new set of synchronization primitives for the compute work in
600600
The compute fences, just like the graphics fences, are created in the
601601
signaled state because otherwise, the first draw would time out while waiting
602602
for the fences to be signaled as detailed
603-
link:03_Drawing_a_triangle/03_Drawing/02_Rendering_and_presentation.adoc[here]:
603+
xref:03_Drawing_a_triangle/03_Drawing/02_Rendering_and_presentation.adoc[here]:
604604

605605
[,c++]
606606
----
@@ -650,7 +650,7 @@ We then use these to synchronize the compute buffer submission with the graphics
650650
----
651651

652652
Similar to the sample in the
653-
link:03_Drawing_a_triangle/03_Drawing/02_Rendering_and_presentation.adoc[semaphore chapter], this setup will immediately run the
653+
xref:03_Drawing_a_triangle/03_Drawing/02_Rendering_and_presentation.adoc[semaphore chapter], this setup will immediately run the
654654
compute shader as we haven't specified any wait semaphores.
655655
Note that we're using scoping braces above to ensure that the RAII temporary
656656
variables we use get a chance to clean themselves up between the compute and

0 commit comments

Comments
 (0)