| // Copyright (c) 2019-2020 Qualcomm Technologies, Inc. |
| // |
| // SPDX-License-Identifier: CC-BY-4.0 |
| |
| include::{generated}/meta/{refprefix}VK_QCOM_render_pass_store_ops.txt[] |
| |
| === Other Extension Metadata |
| |
| *Last Modified Date*:: |
| 2020-03-25 |
| *Contributors*:: |
| - Bill Licea-Kane, Qualcomm Technologies, Inc. |
| |
| === Description |
| |
| Renderpass attachments can: be read-only for the duration of a render pass. |
| |
| Examples include input attachments and depth attachments where depth tests |
| are enabled but depth writes are not enabled. |
| |
| In such cases, there can: be no contents generated for an attachment within |
| the render area. |
| |
| This extension adds a new elink:VkAttachmentStoreOp |
| ename:VK_ATTACHMENT_STORE_OP_NONE_QCOM which specifies that the contents |
| within the render area may: not be written to memory, but that the prior |
| contents of the attachment in memory are preserved. |
| However, if any contents were generated within the render area during |
| rendering, the contents of the attachment will be undefined: inside the |
| render area. |
| |
| [NOTE] |
| .Note |
| ==== |
| The elink:VkAttachmentStoreOp ename:VK_ATTACHMENT_STORE_OP_STORE may: force |
| an implementation to assume that the attachment was written and force an |
| implementation to flush data to memory or to a higher level cache. |
| The elink:VkAttachmentStoreOp ename:VK_ATTACHMENT_STORE_OP_NONE_QCOM may: |
| allow an implementation to assume that the attachment was not written and |
| allow an implementation to avoid such a flush.. |
| ==== |
| |
| include::{generated}/interfaces/VK_QCOM_render_pass_store_ops.txt[] |
| |
| === Version History |
| |
| * Revision 1, 2019-12-20 (wwlk) |
| - Initial version |
| * Revision 2, 2020-03-25 (wwlk) |
| - Minor renaming |
