// Copyright (c) 2014-2016 Khronos Group. This work is licensed under a // Creative Commons Attribution 4.0 International License; see // http://creativecommons.org/licenses/by/4.0/ VkAttachmentDescription(3) ========================== Name ---- VkAttachmentDescription - Structure specifying an attachment description C Specification --------------- // refBegin VkAttachmentDescription - Structure specifying an attachment description The sname:VkAttachmentDescription structure is defined as: include::../api/structs/VkAttachmentDescription.txt[] Members ------- * pname:flags is a bitmask describing additional properties of the attachment. Bits which can: be set include: + -- // refBegin VkAttachmentDescriptionFlagBits - Bitmask specifying additional properties of an attachment include::../api/enums/VkAttachmentDescriptionFlagBits.txt[] -- * pname:format is a elink:VkFormat value specifying the format of the image that will be used for the attachment. * pname:samples is the number of samples of the image as defined in elink:VkSampleCountFlagBits. * pname:loadOp specifies how the contents of color and depth components of the attachment are treated at the beginning of the subpass where it is first used: + -- // refBegin VkAttachmentLoadOp - specify how contents of an attachment are treated at the beginning of a subpass include::../api/enums/VkAttachmentLoadOp.txt[] -- ** ename:VK_ATTACHMENT_LOAD_OP_LOAD means the contents within the render area will be preserved. ** ename:VK_ATTACHMENT_LOAD_OP_CLEAR means the contents within the render area will be cleared to a uniform value, which is specified when a render pass instance is begun. ** ename:VK_ATTACHMENT_LOAD_OP_DONT_CARE means the contents within the area need not be preserved; the contents of the attachment will be undefined inside the render area. * pname:storeOp specifies how the contents of color and depth components of the attachment are treated at the end of the subpass where it is last used: + -- // refBegin VkAttachmentStoreOp - specify how contents of an attachment are treated at the end of a subpass include::../api/enums/VkAttachmentStoreOp.txt[] -- ** ename:VK_ATTACHMENT_STORE_OP_STORE means the contents within the render area are written to memory and will be available for reading after the render pass instance completes once the writes have been synchronized with ename:VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT (for color attachments) or ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT (for depth/stencil attachments). ** ename:VK_ATTACHMENT_STORE_OP_DONT_CARE means the contents within the render area are not needed after rendering, and may: be discarded; the contents of the attachment will be undefined inside the render area. * pname:stencilLoadOp specifies how the contents of stencil components of the attachment are treated at the beginning of the subpass where it is first used, and must: be one of the same values allowed for pname:loadOp above. * pname:stencilStoreOp specifies how the contents of stencil components of the attachment are treated at the end of the last subpass where it is used, and must: be one of the same values allowed for pname:storeOp above. * pname:initialLayout is the layout the attachment image subresource will be in when a render pass instance begins. * pname:finalLayout is the layout the attachment image subresource will be transitioned to when a render pass instance ends. During a render pass instance, an attachment can: use a different layout in each subpass, if desired. Description ----------- If the attachment uses a color format, then pname:loadOp and pname:storeOp are used, and pname:stencilLoadOp and pname:stencilStoreOp are ignored. If the format has depth and/or stencil components, pname:loadOp and pname:storeOp apply only to the depth data, while pname:stencilLoadOp and pname:stencilStoreOp define how the stencil data is handled. [[renderpass-precision]] During a render pass instance, input/color attachments with color formats that have a component size of 8, 16, or 32 bits must: be represented in the attachment's format throughout the instance. Attachments with other floating- or fixed-point color formats, or with depth components may: be represented in a format with a precision higher than the attachment format, but must: be represented with the same range. When such a component is loaded via the pname:loadOp, it will be converted into an implementation-dependent format used by the render pass. Such components must: be converted from the render pass format, to the format of the attachment, before they are stored or resolved at the end of a render pass instance via pname:storeOp. Conversions occur as described in <> and <>. [[renderpass-aliasing]] If pname:flags includes ename:VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT, then the attachment is treated as if it shares physical memory with another attachment in the same render pass. This information limits the ability of the implementation to reorder certain operations (like layout transitions and the pname:loadOp) such that it is not improperly reordered against other uses of the same physical memory via a different attachment. This is described in more detail below. include::../validity/structs/VkAttachmentDescription.txt[] See Also -------- elink:VkAttachmentDescriptionFlags, elink:VkAttachmentLoadOp, elink:VkAttachmentStoreOp, elink:VkFormat, elink:VkImageLayout, slink:VkRenderPassCreateInfo, elink:VkSampleCountFlagBits Document Notes -------------- For more information, see the Vulkan Specification at URL https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#VkAttachmentDescription This page is extracted from the Vulkan Specification. Fixes and changes should be made to the Specification,not directly. include::footer.txt[]