Changed links according to QA

SaschaWillems · SaschaWillems · commit 0b7627b4586b · 2022-02-06T14:21:27.000+01:00
Use Vulkan 1.3 spec
diff --git a/en/05_Uniform_buffers/01_Descriptor_pool_and_sets.md b/en/05_Uniform_buffers/01_Descriptor_pool_and_sets.md
@@ -319,7 +319,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 `mat4` matrix must have the same alignment as a `vec4`.
 
-You can find the full list of alignment requirements in [the specification](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/chap7.html#synchronization-pipeline-stages).
+You can find the full list of alignment requirements in [the specification](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap15.html#interfaces-resources-layout).
 
 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. All of these are multiples of 16 and that's why it worked fine.
 
diff --git a/en/06_Texture_mapping/00_Images.md b/en/06_Texture_mapping/00_Images.md
@@ -534,7 +534,7 @@ 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 [this table](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/chap7.html#synchronization-access-types)
+values are listed in [this table](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap7.html#synchronization-access-types-supported)
 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
@@ -700,7 +700,7 @@ 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 [the documentation](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/chap7.html#synchronization-pipeline-stages)
+happen. See [the documentation](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap7.html#VkPipelineStageFlagBits)
 for more information and other examples of pseudo-stages.
 
 The image will be written in the same pipeline stage and subsequently read by
diff --git a/en/10_Multisampling.md b/en/10_Multisampling.md
@@ -242,7 +242,7 @@ The difference is more noticable when looking up close at one of the edges:
 
 ## Quality improvements
 
-There are certain limitations of our current MSAA implementation which may impact the quality of the output image in more detailed scenes. 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 [Sample Shading](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/chap27.html#primsrast-sampleshading) which will improve the image quality even further, though at an additional performance cost:
+There are certain limitations of our current MSAA implementation which may impact the quality of the output image in more detailed scenes. 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 [Sample Shading](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap27.html#primsrast-sampleshading) which will improve the image quality even further, though at an additional performance cost:
 
 ```c++
 
diff --git a/fr/10_Multisampling.md b/fr/10_Multisampling.md
@@ -276,7 +276,7 @@ Notre implémentation du MSAA est limitée, et ces limitations impactent la qual
 d'aliasing dû aux shaders qui n'est pas résolu par le MSAA. En effet cette technique ne permet que de lisser les bords
 de la géométrie, mais pas les lignes contenus dans les textures. Ces bords internes sont particulièrement visibles dans
 le cas de couleurs qui contrastent beaucoup. Pour résoudre ce problème nous pouvons activer le
-[sample shading](hhttps://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/chap27.html#primsrast-sampleshading), qui
+[sample shading](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap27.html#primsrast-sampleshading), qui
 améliore encore la qualité de l'image au prix de performances encore réduites.
 
 ```c++
