Remove reference to nonexistent validation layer warning (fixes #250)

Overv · Overv · commit 4ed54ab92ebc · 2021-09-19T15:41:19.000+02:00
diff --git a/en/03_Drawing_a_triangle/03_Drawing/02_Rendering_and_presentation.md b/en/03_Drawing_a_triangle/03_Drawing/02_Rendering_and_presentation.md
@@ -524,11 +524,12 @@ void drawFrame() {
 
 The `vkWaitForFences` function takes an array of fences and waits for either any or all of them to be signaled before returning. The `VK_TRUE` we pass here indicates that we want to wait for all fences, but in the case of a single one it obviously doesn't matter. Just like `vkAcquireNextImageKHR` this function also takes a timeout. Unlike the semaphores, we manually need to restore the fence to the unsignaled state by resetting it with the `vkResetFences` call.
 
-If you run the program now, you'll notice something something strange. The application no longer seems to be rendering anything. With validation layers enabled, you'll see the following message:
-
-![](/images/unsubmitted_fence.png)
-
-That means that we're waiting for a fence that has not been submitted. The problem here is that, by default, fences are created in the unsignaled state. That means that `vkWaitForFences` will wait forever if we haven't used the fence before. To solve that, we can change the fence creation to initialize it in the signaled state as if we had rendered an initial frame that finished:
+If you run the program now, you'll notice something something strange. The application
+no longer seems to be rendering anything. The problem is that we're waiting for a fence
+that has not been submitted. Fences are created in the unsignaled state by default,
+which means that `vkWaitForFences` will wait forever if we haven't used the fence
+before. To solve that, we can change the fence creation to initialize it in the
+signaled state as if we had rendered an initial frame that finished:
 
 ```c++
 void createSyncObjects() {
diff --git a/fr/03_Dessiner_un_triangle/03_Effectuer_le_rendu/02_Rendu_et_présentation.md b/fr/03_Dessiner_un_triangle/03_Effectuer_le_rendu/02_Rendu_et_présentation.md
@@ -36,7 +36,7 @@ permettent d'attendre qu'une opération se termine en relayant un signal émis p
 l'origine du lancement de l'opération.
 
 Ils ont cependant une différence : l'état d'une fence peut être accédé depuis le programme à l'aide de fonctions telles
-que `vkWaitForFences` alors que les sémaphores ne le permettent pas. Les fences sont généralement utilisées pour 
+que `vkWaitForFences` alors que les sémaphores ne le permettent pas. Les fences sont généralement utilisées pour
 synchroniser votre programme avec les opérations alors que les sémaphores synchronisent les opérations entre elles. Nous
 voulons synchroniser les queues, les commandes d'affichage et la présentation, donc les sémaphores nous conviennent le
 mieux.
@@ -191,7 +191,7 @@ subpasses implicites.
 Il existe deux dépendances préexistantes capables de gérer les transitions au début et à la fin de la render pass. Le
 problème est que cette première dépendance ne s'exécute pas au bon moment. Elle part du principe que la transition de
 l'organisation de l'image doit être réalisée au début de la pipeline, mais dans notre programme l'image n'est pas encore
-acquise à ce moment! Il existe deux manières de régler ce problème. Nous pourrions changer `waitStages` pour 
+acquise à ce moment! Il existe deux manières de régler ce problème. Nous pourrions changer `waitStages` pour
 `imageAvailableSemaphore` à `VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT` pour être sûrs que la pipeline ne commence pas avant
 que l'image ne soit acquise, mais nous perdrions en performance car les shaders travaillant sur les vertices n'ont pas
 besoin de l'image. Il faudrait faire quelque chose de plus subtil. Nous allons donc plutôt faire attendre la render
@@ -209,7 +209,7 @@ dependency.dstSubpass = 0;
 
 Les deux premiers champs permettent de fournir l'indice de la subpasse d'origine et de la subpasse d'arrivée. La valeur
 particulière `VK_SUBPASS_EXTERNAL` réfère à la subpass implicite soit avant soit après la render pass, selon que
-cette valeur est indiquée dans respectivement `srcSubpass` ou `dstSubpass`. L'indice `0` correspond à notre 
+cette valeur est indiquée dans respectivement `srcSubpass` ou `dstSubpass`. L'indice `0` correspond à notre
 seule et unique subpasse. La valeur fournie à `dstSubpass` doit toujours être supérieure à `srcSubpass` car sinon une
 boucle infinie peut apparaître (sauf si une des subpasse est `VK_SUBPASS_EXTERNAL`).
 
@@ -311,7 +311,7 @@ void mainLoop() {
 }
 ```
 
-Vous pouvez également attendre la fin d'une opération quelconque depuis une queue spécifique à l'aide de la fonction 
+Vous pouvez également attendre la fin d'une opération quelconque depuis une queue spécifique à l'aide de la fonction
 `vkQueueWaitIdle`. Ces fonction peuvent par ailleurs être utilisées pour réaliser une synchronisation très basique,
 mais très inefficace. Le programme devrait maintenant se terminer sans problème quand vous fermez la fenêtre.
 
@@ -445,7 +445,7 @@ std::vector<VkFence> inFlightFences;
 size_t currentFrame = 0;
 ```
 
-J'ai choisi de créer les fences avec les sémaphores et de renommer la fonction `createSemaphores` en 
+J'ai choisi de créer les fences avec les sémaphores et de renommer la fonction `createSemaphores` en
 `createSyncObjects` :
 
 ```c++
@@ -519,15 +519,11 @@ différence vu que nous n'avons qu'une seule fence. Comme la fonction `vkAcquire
 durée en argument, que nous ignorons. Nous devons ensuite réinitialiser les fences manuellement à l'aide d'un appel à
 la fonction `vkResetFences`.
 
-Si vous lancez le programme maintenant vous allez constater un comportement étrange. Plus rien ne se passe. Encore 
-une fois regardez ce que les validation layers vous fournissent comme informations :
-
-![](/images/unsubmitted_fence.png)
-
-Nous attendons qu'une fence soit signalée alors qu'elle n'a jamais été envoyée à aucune fonction. En effet les fences
-sont par défaut crées dans le mode non signalé. Comme nous appelons `vkWaitForFences` avant `vkQueueSubmit` notre
-première fence va créer une pause infinie. Pour empêcher cela nous devons initialiser les fences dans le mode signalé,
-et ce dès leur création :
+Si vous lancez le programme maintenant vous allez constater un comportement étrange. Plus rien ne se passe. Nous attendons qu'une fence soit signalée alors qu'elle n'a
+jamais été envoyée à aucune fonction. En effet les fences sont par défaut crées dans le
+mode non signalé. Comme nous appelons `vkWaitForFences` avant `vkQueueSubmit` notre
+première fence va créer une pause infinie. Pour empêcher cela nous devons initialiser
+les fences dans le mode signalé, et ce dès leur création :
 
 ```c++
 void createSyncObjects() {
@@ -569,7 +565,7 @@ void createSyncObjects() {
 }
 ```
 
-Initialement aucune frame n'utilise d'image, donc on peut explicitement l'initialiser à *pas de fence*. Maintenant, nous allons modifier 
+Initialement aucune frame n'utilise d'image, donc on peut explicitement l'initialiser à *pas de fence*. Maintenant, nous allons modifier
 `drawFrame` pour attendre la fin de n'importe quelle frame qui serait en train d'utiliser l'image qu'on nous assigné pour la nouvelle frame.
 
 ```c++
diff --git a/images/unsubmitted_fence.png b/images/unsubmitted_fence.png
