Merge pull request #227 from KhronosGroup/update_spec_links

marty-johnson59 · web-flow · commit 28e5c15dc7c9 · 2025-11-17T09:19:53.000-08:00
Update spec links to point at docs site instead
diff --git a/en/03_Drawing_a_triangle/00_Setup/02_Validation_layers.adoc b/en/03_Drawing_a_triangle/00_Setup/02_Validation_layers.adoc
@@ -323,7 +323,7 @@ class, for example.
 
 Note that there are many more ways to configure validation layer messages
 and debug callbacks, but this is a good setup to get started with for this
-tutorial. See the https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap50.html#VK_EXT_debug_utils[extension specification]
+tutorial. See the https://docs.vulkan.org/spec/latest/chapters/debugging.html#VK_EXT_debug_utils[extension specification]
 for more info about the possibilities.
 
 We can now re-use this in the `createInstance` function:
diff --git a/en/03_Drawing_a_triangle/00_Setup/04_Logical_device_and_queues.adoc b/en/03_Drawing_a_triangle/00_Setup/04_Logical_device_and_queues.adoc
@@ -165,7 +165,7 @@ extension in the swap chain chapter.
 
 Previous implementations of Vulkan made a distinction between instance and
 device-specific validation layers, but this is
-link:https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap40.html#extendingvulkan-layers-devicelayerdeprecation[no longer the case].
+link:https://docs.vulkan.org/spec/latest/chapters/raytracing.html#extendingvulkan-layers-devicelayerdeprecation[no longer the case].
 That means that the `enabledLayerCount` and `ppEnabledLayerNames` fields of
 `VkDeviceCreateInfo` are ignored by up-to-date implementations.
 
diff --git a/en/04_Vertex_buffers/01_Vertex_buffer_creation.adoc b/en/04_Vertex_buffers/01_Vertex_buffer_creation.adoc
@@ -221,7 +221,7 @@ We went for the first approach, which ensures that the mapped memory always matc
 Do keep in mind that this may lead to slightly worse performance than explicit flushing, but we'll see why that doesn't matter in the next chapter.
 
 Flushing memory ranges or using a coherent memory heap means that the driver will be aware of our writings to the buffer, but it doesn't mean that they are actually visible on the GPU yet.
-The transfer of data to the GPU is an operation that happens in the background, and the specification simply https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap7.html#synchronization-submission-host-writes[tells us] that it is guaranteed to be complete as of the next call to `vkQueueSubmit`.
+The transfer of data to the GPU is an operation that happens in the background, and the specification simply https://docs.vulkan.org/spec/latest/chapters/synchronization.html#synchronization-submission-host-writes[tells us] that it is guaranteed to be complete as of the next call to `vkQueueSubmit`.
 
 == Binding the vertex buffer
 
diff --git a/en/05_Uniform_buffers/01_Descriptor_pool_and_sets.adoc b/en/05_Uniform_buffers/01_Descriptor_pool_and_sets.adoc
@@ -248,7 +248,7 @@ Vulkan expects the data in your structure to be aligned in memory in a specific
 * A nested structure must be aligned by the base alignment of its members rounded up to a multiple of 16.
 * A `float4x4` matrix must have the same alignment as a `float4`.
 
-You can find the full list of alignment requirements in https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap15.html#interfaces-resources-layout[the specification].
+You can find the full list of alignment requirements in https://docs.vulkan.org/spec/latest/chapters/interfaces.html#interfaces-resources-layout[the specification].
 
 Our original shader with just three `mat4` fields already met the alignment requirements.
 As each `mat4` is 4 x 4 x 4 = 64 bytes in size, `model` has an offset of `0`, `view` has an offset of 64 and `proj` has an offset of 128.
diff --git a/en/06_Texture_mapping/00_Images.adoc b/en/06_Texture_mapping/00_Images.adoc
@@ -364,7 +364,7 @@ All types of pipeline barriers are submitted using the same function.
 The first parameter after the command buffer specifies in which pipeline stage the operations occur that should happen before the barrier.
 The second parameter specifies the pipeline stage in which operations will wait on the barrier.
 The pipeline stages that you are allowed to specify before and after the barrier depend on how you use the resource before and after the barrier.
-The allowed values are listed in https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap7.html#synchronization-access-types-supported[this table] of the specification.
+The allowed values are listed in https://docs.vulkan.org/spec/latest/chapters/synchronization.html#synchronization-access-types-supported[this table] of the specification.
 For example, if you're going to read from a uniform after the barrier, you would specify a usage of `VK_ACCESS_UNIFORM_READ_BIT` and the earliest shader that will read from the uniform as pipeline stage, for example `VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT`.
 It would not make sense to specify a non-shader pipeline stage for this type of usage and the validation layers will warn you when you specify a pipeline stage that does not match the type of usage.
 
@@ -483,7 +483,7 @@ As you can see in the aforementioned table, transfer writes must occur in the pi
 Since the writings don't have to wait on anything, you may specify an empty access mask and the earliest possible pipeline stage `VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT` for the pre-barrier operations.
 It should be noted that `VK_PIPELINE_STAGE_TRANSFER_BIT` is not a _real_ stage within the graphics and compute pipelines.
 It is more of a pseudo-stage where transfers happen.
-See https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap7.html#VkPipelineStageFlagBits[the documentation] for more information and other examples of pseudo-stages.
+See https://docs.vulkan.org/spec/latest/chapters/synchronization.html#VkPipelineStageFlagBits[the documentation] for more information and other examples of pseudo-stages.
 
 The image will be written in the same pipeline stage and subsequently read by the fragment shader, which is why we specify shader reading access in the fragment shader pipeline stage.
 
diff --git a/en/10_Multisampling.adoc b/en/10_Multisampling.adoc
@@ -284,7 +284,7 @@ There are certain limitations of our current MSAA implementation that may impact
 For example, we're currently not solving potential problems caused by shader aliasing, i.e.
 MSAA only smoothens out the edges of geometry but not the interior filling.
 This may lead to a situation when you get a smooth polygon rendered on screen, but the applied texture will still look aliased if it contains high contrasting colors.
-One way to approach this problem is to enable https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap27.html#primsrast-sampleshading[Sample Shading] which will improve the image quality even further, though at an additional performance cost:
+One way to approach this problem is to enable https://docs.vulkan.org/spec/latest/chapters/vertexpostproc.html#primsrast-sampleshading[Sample Shading] which will improve the image quality even further, though at an additional performance cost:
 
 [,c++]
 ----
