Vulkan-Docs/doc/specs/vulkan/man/VkSubpassDescription.txt

112 lines
4.9 KiB
Plaintext

// 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::../api/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 each attachment 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 each attachment 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 an array of pname:colorAttachmentCount
slink:VkAttachmentReference structures that lists which of the render pass's
attachments are resolved to at the end of the subpass, and what layout
each attachment will be in during the resolve. 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[]