Rmove outdated comments and code for device level validation layers

Author: SaschaWillems

en/03_Drawing_a_triangle/00_Setup/02_Validation_layers.adoc

@@ -44,14 +44,7 @@ Vulkan does not come with any validation layers built-in, but the LunarG Vulkan
 They're also completely https://github.com/KhronosGroup/Vulkan-ValidationLayers[open source], so you can check which kind of mistakes they check for and contribute.
 Using the validation layers is the best way to avoid your application breaking on different drivers by accidentally relying on undefined behavior.
 
-Validation layers can only be used if they have been installed onto the system.
-For example, the LunarG validation layers are only available on PCs with the Vulkan SDK installed.
-
-There were formerly two different types of validation layers in Vulkan: instance and device specific.
-The idea was that instance layers would only check calls related to global Vulkan objects like instances, and device specific layers would only check calls related to a specific GPU.
-Device specific layers have now been deprecated, which means that instance validation layers apply to all Vulkan calls.
-The specification document still recommends that you enable validation layers at device level as well for compatibility, which is required by some implementations.
-We'll simply specify the same layers as the instance at logical device level, which we'll see link:./04_Logical_device_and_queues.adoc[later on].
+Validation layers can only be used if they have been installed onto the system. One way to get those layers is through the LunarG SDK.
 
 == Using validation layers
 

en/03_Drawing_a_triangle/00_Setup/04_Logical_device_and_queues.adoc

@@ -92,27 +92,15 @@ createInfo.queueCreateInfoCount = 1;
 createInfo.pEnabledFeatures = &deviceFeatures;
 ----
 
-The remainder of the information bears a resemblance to the `VkInstanceCreateInfo` struct and requires you to specify extensions and validation layers.
-The difference is that these are device specific this time.
+The remainder of the information bears a resemblance to the `VkInstanceCreateInfo` struct and lets you to specify extensions. The difference is that these are device specific this time.
 
 An example of a device specific extension is `VK_KHR_swapchain`, which allows you to present rendered images from that device to windows.
 It is possible that 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 https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap40.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.
-However, it is still a good idea to set them anyway to be compatible with older implementations:
-
 [,c++]
 ----
 createInfo.enabledExtensionCount = 0;
-
-if (enableValidationLayers) {
-    createInfo.enabledLayerCount = static_cast<uint32_t>(validationLayers.size());
-    createInfo.ppEnabledLayerNames = validationLayers.data();
-} else {
-    createInfo.enabledLayerCount = 0;
-}
 ----
 
 We won't need any device specific extensions for now.