110 lines
4.7 KiB
Plaintext
110 lines
4.7 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::../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[]
|
|
|