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 index ce98a468..f7b10ef3 100644 --- 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 index 18dec5f4..d9309e27 100644 --- 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 index e3eba4c9..acf6a1ac 100644 --- 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 index 0e67ed74..fb66ecf1 100644 --- 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 index 51d67175..ce7ccd01 100644 --- 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 index 1aa0c685..e33c2af8 100644 --- 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++] ----