message: Fix incorrect Vulkan documentation wrt layouts.
diff: @@ -91,8 +91,8 @@ that are defined in `DriverBase.h`.
  Most of the handle types do not contain much logic, but they often do more than mere wrapping of
  Vk objects. Notably, `VulkanRenderTarget` does not have a straightforward mapping to any one Vk
  -object. See its class comment for details. Also, `VulkanTexture` lives in its own cpp file because
  -of complexity around layouts and subresources.
  +object. See its class comment for details. Also, `VulkanTexture` and `VulkanSwapChain` have their
  +own cpps file because of complexity around layouts and subresources.
  VulkanProgram
  : Descends from `HwProgram`, owns a pair of `VkShaderModule`.
  @@ -135,7 +135,9 @@ VulkanDisposer
  VulkanFboCache
  : Cache of VkRenderPass and VkFramebuffer. Contains weak references to VkImage handles, but does not
  - own any pixel data.
  + own any pixel data. The cache key for render passes is quite complex because it needs to include
  + image layout information in a compact way. For details see the comments in the `RenderPassKey`
  + declaration.
  VulkanStagePool
  : Pool of VkBuffer objects that can be memory mapped (shared between host and device).
  @@ -185,8 +187,7 @@ subresources, so validation should not complain.
  (2) **Writeable Color Textures**
  -These should be created in an UNDEFINED state and stay that way until the first render pass that
  -targets them, at which point they should be transitioned to GENERAL using the render pass.
  +During construction of the HwTexture, these are transitioned to GENERAL using a barrier.
  GENERAL layout is not recommended by AMD best practices but in our case we wish to avoid thrashing
  the layout between COLOR_ATTACHMENT_OPTIMAL and SHADER_READ_ONLY_OPTIMAL for post-processing
  @@ -194,18 +195,20 @@ effects. Moreover we do not have a priori knowledge about blitting and read pix
  (3) **Depth Textures**
  -These should be created in an UNDEFINED state and transitioned to GENERAL at the beginning of the
  -first render pass that targets them.
  +During construction of the HwTexture, these are transitioned to GENERAL using a barrier.
  Note that some post-processing passes (e.g. SSAO) sample from the depth buffer while also enabling
  depth testing. Using GENERAL makes this legal.
  (4) **Swap Chain Textures**
  -These should be transitioned to GENERAL using the first render pass of the frame, then transitioned
  -to PRESENT at the end of the frame using a barrier. With some GPU vendors it might be preferable to
  -transition them using the last render pass, but we have no way of knowing ahead of time which pass
  -is last.
  +During construction, these are transitioned to GENERAL using a barrier. They are then transitioned
  +to PRESENT at the end of the frame using a barrier, and transitioned back to GENERAL using the first
  +render pass of the frame.
  +
  +Note that we transition to PRESENT using a barrier, but with some GPU vendors it might be preferable
  +to transition them using the last render pass. However we have no way of knowing ahead of time which
  +pass is last.
  Note that Filament allows swap chains to be used as blit targets and blit sources (e.g. for
  ReadPixels). Using GENERAL makes this easier to manage.
  