mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-17 00:36:24 +00:00
e2d981c029
* Bump API patch number and header version number to 20 for this
update.
Github Issues:
* Replaced existing reference pages by text automatically extracted
from the specification source, or generated from vk.xml in some
cases. This isn't a complete solution for the reference pages, but
puts them in a much better state. The ref pages (only) are now
placed under a CC BY open source license, which is more current than
the obsolete license previously used.
Further improvements to the pages should not edit them directly, but
instead concentrate on the specification source from which the ref
pages are being extracted (public issues 44, 55, 160; internal issue
389).
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[]
|
|
|