mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-03-02 15:00:46 +00:00
7f7686d7f2
* Bump API patch number and header version number to 23 for this update.
Github Issues:
* Add explicit valid value attributes to pname:sType members in vk.xml
(public issue 34).
* Clarify usage of flink:vkGetInstanceProcAddr and
flink:vkGetDeviceProcAddr (public issue 225).
* Fix a copy-and-paste error in the description of
pname:pSwapchainImageCount saying that it was the count of ``format
pairs'' instead of ``swapchain images'' (public issue 292).
* flink:vkCmdExecuteCommandBuffers requires all command buffers to be
allocated from command pools created for the same queue family (public
issue 296).
* Remove bogus +optional+ attribute for
flink:vkEnumerateDeviceLayerProperties::pname:physicalDevice from vk.xml
(public issue 301).
* Clean up the <<resources-image-views-compatibility,image and image view
compatibility table>> reference and contents. Use full enumerant names.
Refer to pname:layerCount in the ``view parameters'' column instead of
pname:arrayLayers. Require N >= 1 for the cube array subview row, not
just arrayLayers >= 6 N (public issue 304).
* Modify description of <<resources-memory-aliasing,memory aliasing>> to
be consistent with the description of
<<resources-bufferimagegranularity,buffer image granularity>> (public
issue 307).
Internal Issues:
* Describe remaining +vk_platform.h+ macros in the <<boilerplate,API
Boilerplate>> appendix (internal issue 6).
* Clarify
<<features-features-robustBufferAccess,pname:robustBufferAccess>>
feature behavior; what memory can be accessed, how bounds checking is
performed, and allowing for vectorization (internal issue 332).
* Document markup for automatic extraction of reference pages from the
spec sources in the style guide (internal issue 395).
* Allow flink:vkCreateDisplayModeKHR to return
ename:VK_ERROR_INITIALIZAION_FAILED_KHR if the user requests mode
parameters that the specified display does not support (internal issue
411).
* Remove atomic counters (atomic_uint style) from KHR_vulkan_glsl, and
more clearly remove the subroutine keyword alongside it (internal issue
421).
* Clarify behavior of flink:vkCmdBindDescriptorSets for descriptor sets
not contained in the layout (internal issue 427).
Other Commits:
* Change the order in which members of sname:VkAttachmentDescription and
sname:VkPipelineInputAssemblyStateCreateInfo are described to match
their order in the structures.
139 lines
5.9 KiB
Plaintext
139 lines
5.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/
|
|
|
|
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
|
|
<<fundamentals-numerics,Numeric Representation and Computation>> and
|
|
<<fundamentals-fixedconv, Fixed-Point Data Conversions>>.
|
|
|
|
[[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[]
|
|
|