Overv · Krenodeno · Jun 14, 2019 · Jun 14, 2019 · Jun 14, 2019 · Jun 14, 2019
diff --git a/config.json b/config.json
@@ -19,10 +19,10 @@
         "links": {
             "GitHub Repository": "https://github.com/Overv/VulkanTutorial",
             "Support the website": "https://www.paypal.me/AOvervoorde",
-            "Vulkan Specification": "https://www.khronos.org/registry/vulkan/specs/1.0-wsi_extensions/pdf/vkspec.pdf",
-            "Vulkan Quick Reference": "https://www.khronos.org/files/vulkan10-reference-guide.pdf",
+            "Vulkan Specification": "https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/",
             "LunarG Vulkan SDK": "https://lunarg.com/vulkan-sdk/",
-            "Vulkan Hardware Database": "http://vulkan.gpuinfo.org/",
+            "Vulkan Guide": "https://github.com/KhronosGroup/Vulkan-Guide",
+            "Vulkan Hardware Database": "https://vulkan.gpuinfo.org/",
             "Tutorial for Rust": "https://github.com/bwasty/vulkan-tutorial-rs",
             "Tutorial for Java": "https://github.com/Naitsirc98/Vulkan-Tutorial-Java",
             "Visual Studio 2019 samples": "https://github.com/jjYBdx4IL/VulkanTutorial-VisualStudioProjectFiles"

diff --git a/en/03_Drawing_a_triangle/00_Setup/02_Validation_layers.md b/en/03_Drawing_a_triangle/00_Setup/02_Validation_layers.md
@@ -298,7 +298,7 @@ Similarly the `messageType` field lets you filter which types of messages your c
 
 Finally, the `pfnUserCallback` field specifies the pointer to the callback function. You can optionally pass a pointer to the `pUserData` field which will be passed along to the callback function via the `pUserData` parameter. You could use this to pass a pointer to the `HelloTriangleApplication` 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 [extension specification](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VK_EXT_debug_utils) for more info about the possibilities.
+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 [extension specification](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap50.html#VK_EXT_debug_utils) for more info about the possibilities.
 
 This struct should be passed to the `vkCreateDebugUtilsMessengerEXT` function to
 create the `VkDebugUtilsMessengerEXT` object. Unfortunately, because this

diff --git a/en/03_Drawing_a_triangle/00_Setup/04_Logical_device_and_queues.md b/en/03_Drawing_a_triangle/00_Setup/04_Logical_device_and_queues.md
@@ -100,7 +100,7 @@ there are Vulkan devices in the system that lack this ability, for example
 because they only support compute operations. We will come back to this
 extension in the swap chain chapter.
 
-Previous implementations of Vulkan made a distinction between instance and device specific validation layers, but this is [no longer the case](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#extendingvulkan-layers-devicelayerdeprecation). That means that the `enabledLayerCount` and `ppEnabledLayerNames` fields of `VkDeviceCreateInfo` are ignored by up-to-date implementations. However, it is still a good idea to set them anyway to be compatible with older implementations:
+Previous implementations of Vulkan made a distinction between instance and device specific validation layers, but this is [no longer the case](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap40.html#extendingvulkan-layers-devicelayerdeprecation). That means that the `enabledLayerCount` and `ppEnabledLayerNames` fields of `VkDeviceCreateInfo` are ignored by up-to-date implementations. However, it is still a good idea to set them anyway to be compatible with older implementations:
 
 ```c++
 createInfo.enabledExtensionCount = 0;

diff --git a/en/03_Drawing_a_triangle/02_Graphics_pipeline_basics/04_Conclusion.md b/en/03_Drawing_a_triangle/02_Graphics_pipeline_basics/04_Conclusion.md
@@ -54,7 +54,7 @@ And finally we have the reference to the render pass and the index of the sub
 pass where this graphics pipeline will be used. It is also possible to use other
 render passes with this pipeline instead of this specific instance, but they
 have to be *compatible* with `renderPass`. The requirements for compatibility
-are described [here](https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#renderpass-compatibility),
+are described [here](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap8.html#renderpass-compatibility),
 but we won't be using that feature in this tutorial.
 
 ```c++

diff --git a/en/04_Vertex_buffers/01_Vertex_buffer_creation.md b/en/04_Vertex_buffers/01_Vertex_buffer_creation.md
@@ -290,7 +290,7 @@ matches the contents of the allocated memory. 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 writes 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 [tells us](https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#synchronization-submission-host-writes) that it is guaranteed to be complete as of the next call to `vkQueueSubmit`.
+Flushing memory ranges or using a coherent memory heap means that the driver will be aware of our writes 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 [tells us](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap7.html#synchronization-submission-host-writes) 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.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.1-extensions/html/chap14.html#interfaces-resources-layout).
+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.0/html/vkspec.html#synchronization-access-types-supported)
+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.1-extensions/man/html/VkPipelineStageFlagBits.html)
+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.0/html/vkspec.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/03_Dessiner_un_triangle/00_Mise_en_place/02_Validation_layers.md b/fr/03_Dessiner_un_triangle/00_Mise_en_place/02_Validation_layers.md
@@ -294,7 +294,7 @@ fait partie des paramètres de la fonction de rappel.
 
 Notez qu'il existe de nombreuses autres manières de configurer des messagers auprès des validation layers, mais nous
 avons ici une bonne base pour ce tutoriel. Référez-vous à la
-[spécification de l'extension](www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VK_EXT_debug_utils)
+[spécification de l'extension](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap50.html#VK_EXT_debug_utils)
 pour plus d'informations sur ces possibilités.
 
 Cette structure doit maintenant être passée à la fonction `vkCreateDebugUtilsMessengerEXT` afin de créer l'objet

diff --git a/fr/03_Dessiner_un_triangle/02_Pipeline_graphique_basique/04_Conclusion.md b/fr/03_Dessiner_un_triangle/02_Pipeline_graphique_basique/04_Conclusion.md
@@ -43,7 +43,7 @@ pipelineInfo.layout = pipelineLayout;
 Finalement nous devons fournir les références à la render pass et aux indices des subpasses. Il est aussi possible
 d'utiliser d'autres render passes avec cette pipeline mais elles doivent être compatibles avec `renderPass`. La 
 signification de compatible est donnée
-[ici](https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#renderpass-compatibility), mais nous 
+[ici](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap8.html#renderpass-compatibility), mais nous 
 n'utiliserons pas cette possibilité dans ce tutoriel.
 
 ```c++

diff --git a/fr/05_Uniform_buffers/01_Descriptor_pool_et_sets.md b/fr/05_Uniform_buffers/01_Descriptor_pool_et_sets.md
@@ -295,7 +295,7 @@ Vulkan s'attend à un certain alignement des données en mémoire pour chaque ty
 * Une `mat4` doit avoir le même alignement qu'un `vec4`
 
 Les alignemenents imposés peuvent être trouvés dans
-[la spécification](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/chap14.html#interfaces-resources-layout)
+[la spécification](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap15.html#interfaces-resources-layout)
 
 Notre shader original et ses trois `mat4` était bien aligné. `model` a un décalage de 0, `view` de 64 et `proj` de 128,
 ce qui sont des multiples de 16.

diff --git a/fr/06_Texture_mapping/00_Images.md b/fr/06_Texture_mapping/00_Images.md
@@ -480,7 +480,7 @@ indique une étape de la pipeline. Durant celle-ci seront réalisées les opéra
 paramètre d'après indique également une étape de la pipeline. Cette fois les opérations exécutées durant cette étape
 attendront la barrière. Les étapes que vous pouvez fournir comme avant- et après-barrière dépendent de l'utilisation
 des ressources qui y sont utilisées. Les valeurs autorisées sont listées
-[dans ce tableau](https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#synchronization-access-types-supported).
+[dans ce tableau](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap7.html#synchronization-access-types-supported).
 Par exemple, si vous voulez lire des données présentes dans un UBO après une barrière qui s'applique au buffer, vous 
 devrez indiquer `VK_ACCESS_UNIFORM_READ_BIT` comme usage, et si le premier shader à utiliser l'uniform est le fragment
 shader il vous faudra indiquer `VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT` comme étape. Dans ce cas de figure, spécifier 
@@ -625,7 +625,7 @@ pipeline de transfert. Mais cette opération d'écriture ne dépend d'aucune aut
 une condition d'accès nulle et `VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT` comme opération pré-barrière. Cette valeur correspond
 au début de la pipeline, mais ne représente pas vraiment une étape. Elle désigne plutôt le moment où la pipeline se
 prépare, et donc sert communément aux transferts. Voyez
-[la documentation](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkPipelineStageFlagBits.html)
+[la documentation](https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap7.html#VkPipelineStageFlagBits)
 pour de plus amples informations sur les pseudo-étapes.
 
 L'image sera écrite puis lue dans la même passe, c'est pourquoi nous devons indiquer que le fragment shader aura accès à

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](https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.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++
-Original file line number
+Diff line change
@@ Expand Up @@
     ## 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.0/html/vkspec.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++
@@ Expand Down @@