Vulkan: add comments explaining layout strategy.

filament/backend/src/vulkan/VulkanDriver.cpp

@@ -1512,7 +1512,8 @@ void VulkanDriver::readPixels(Handle<HwRenderTarget> src, uint32_t x, uint32_t y
             VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL, stagingImage, VK_IMAGE_LAYOUT_GENERAL,
             1, &imageCopyRegion);
 
-    // Restore the source image layout.
+    // Restore the source image layout. Between driver API calls, color images are always kept in
+    // UNDEFINED layout or in their "usage default" layout (see comment for getDefaultImageLayout).
 
     srcTexture->transitionLayout(cmdbuffer, srcRange,
             getDefaultImageLayout(TextureUsage::COLOR_ATTACHMENT));

filament/backend/src/vulkan/VulkanUtility.cpp

@@ -514,6 +514,11 @@ VkImageViewType getImageViewType(SamplerType target) {
     }
 }
 
+// Between Driver API calls, non-presentable texture images are generally kept either in the
+// UNDEFINED layout, or in the usage-specific layout specified by this function. This simple
+// convention allows the use of a bitfield to represent layout in RenderPassKey. However there are
+// exceptions for depth and for transient use of specialized layouts, which is why VulkanTexture
+// tracks actual layout at the subresource level.
 VkImageLayout getDefaultImageLayout(TextureUsage usage) {
     // Filament sometimes samples from depth while it is bound to the current render target, (e.g.
     // SSAO does this while depth writes are disabled) so let's keep it simple and use GENERAL for