VK_KHR_load_store_op_none

In Vulkan 1.0, there exist two VkAttachmentStoreOp values: VK_ATTACHMENT_STORE_OP_STORE and VK_ATTACHMENT_STORE_OP_DONT_CARE. The former causes the attachment contents to be written back to the image at the end of the render pass, and the latter causes the contents to be discarded. Both these operations are write operations. As a result:

In some cases, for example for a depth/stencil attachment that is being used as read-only, the contents of the attachment are not modified, yet should not be discarded either. There is thus a need for another store operation to retain the contents of the attachment without a write.

In Vulkan 1.0, there exist three VkAttachmentLoadOp values: VK_ATTACHMENT_LOAD_OP_LOAD, VK_ATTACHMENT_LOAD_OP_CLEAR, and VK_ATTACHMENT_LOAD_OP_DONT_CARE. In some scenarios, a render pass subpass may not actually use an attachment. Using VK_ATTACHMENT_LOAD_OP_LOAD (followed by VK_ATTACHMENT_STORE_OP_NONE_KHR) can be detrimental to performance on some devices. Note that VK_ATTACHMENT_LOAD_OP_DONT_CARE is not usable as it is a write operation and may corrupt the contents of the attachment. In Vulkan 1.0, these attachments should be placed in a "preserve attachment" (i.e. `VkSubpassDescription::pPreserveAttachments).

This is not always possible however, in software where usage of attachments is not a priori known. This is the case in OpenGL emulation layers for example, and certain game engines. Due to the render pass compatibility rules, the application is not allowed to assume all attachments are used, only to move some to preserve attachments at the end of a logical render pass (where the Vulkan render pass is created).

The VK_KHR_dynamic_rendering extension solves this problem by allowing the application to provide VK_NULL_HANDLE in VkRenderingAttachmentInfo::imageView. The applications can thus simply avoid providing the view of the attachments that need to be preserved. For applications using legacy render passes however, the problem remains.