// 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/

VkSubpassDescription(3)
=======================

Name
----
VkSubpassDescription - Structure specifying a subpass description

C Specification
---------------

// refBegin VkSubpassDescription - Structure specifying a subpass description

The sname:VkSubpassDescription structure is defined as:

include::../structs/VkSubpassDescription.txt[]


Members
-------

  * pname:flags is reserved for future use.
  * pname:pipelineBindPoint is a elink:VkPipelineBindPoint value specifying
    whether this is a compute or graphics subpass. Currently, only graphics
    subpasses are supported.
  * pname:inputAttachmentCount is the number of input attachments.
  * pname:pInputAttachments is an array of slink:VkAttachmentReference
    structures (defined below) that lists which of the render pass's
    attachments can: be read in the shader during the subpass, and what
    layout the attachment images will be in during the subpass. Each element
    of the array corresponds to an input attachment unit number in the
    shader, i.e. if the shader declares an input variable
    `layout(input_attachment_index=X, set=Y, binding=Z)` then it uses the
    attachment provided in pname:pInputAttachments[X]. Input attachments
    must: also be bound to the pipeline with a descriptor set, with the
    input attachment descriptor written in the location (set=Y, binding=Z).
  * pname:colorAttachmentCount is the number of color attachments.
  * pname:pColorAttachments is an array of pname:colorAttachmentCount
    slink:VkAttachmentReference structures that lists which of the render
    pass's attachments will be used as color attachments in the subpass, and
    what layout the attachment images will be in during the subpass. Each
    element of the array corresponds to a fragment shader output location,
    i.e. if the shader declared an output variable `layout(location=X)` then
    it uses the attachment provided in pname:pColorAttachments[X].
  * pname:pResolveAttachments is `NULL` or a pointer to an array of
    slink:VkAttachmentReference structures. If pname:pResolveAttachments is
    not `NULL`, each of its elements corresponds to a color attachment (the
    element in pname:pColorAttachments at the same index). At the end of
    each subpass, the subpass's color attachments are resolved to
    corresponding resolve attachments, unless the resolve attachment index
    is ename:VK_ATTACHMENT_UNUSED or pname:pResolveAttachments is `NULL`. If
    the first use of an attachment in a render pass is as a resolve
    attachment, then the pname:loadOp is effectively ignored as the resolve
    is guaranteed to overwrite all pixels in the render area.
  * pname:pDepthStencilAttachment is a pointer to a
    slink:VkAttachmentReference specifying which attachment will be used for
    depth/stencil data and the layout it will be in during the subpass.
    Setting the attachment index to ename:VK_ATTACHMENT_UNUSED or leaving
    this pointer as `NULL` indicates that no depth/stencil attachment will
    be used in the subpass.
  * pname:preserveAttachmentCount is the number of preserved attachments.
  * pname:pPreserveAttachments is an array of pname:preserveAttachmentCount
    render pass attachment indices describing the attachments that
    are not used by a subpass, but whose contents must: be preserved
    throughout the subpass.


Description
-----------

The contents of an attachment within the render area become undefined at
the start of a subpass S if all of the following conditions are true:

  * The attachment is used as a color, depth/stencil, or resolve attachment
    in any subpass in the render pass.
  * There is a subpass S1 that uses or preserves the attachment, and a
    subpass dependency from S1 to S.
  * The attachment is not used or preserved in subpass S.

Once the contents of an attachment become undefined in subpass S, they
remain undefined for subpasses in subpass dependency chains starting with
subpass S until they are written again. However, they remain valid for
subpasses in other subpass dependency chains starting with subpass S1 if
those subpasses use or preserve the attachment.

include::../validity/structs/VkSubpassDescription.txt[]


See Also
--------

slink:VkAttachmentReference, elink:VkPipelineBindPoint, slink:VkRenderPassCreateInfo, elink:VkSubpassDescriptionFlags


Document Notes
--------------

For more information, see the Vulkan Specification at URL

https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#VkSubpassDescription

This page is extracted from the Vulkan Specification.
Fixes and changes should be made to the Specification,not directly.

include::footer.txt[]