mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-01-20 03:08:53 +00:00
6db51e9241
* Bump API patch number and header version number to 11 for this
update.
Github Issues:
* Clarify the WSI extension language by switching from the fuzzier
"ownership" language to more-consistent "acquire" language (public
issue 117).
* Clarify that memory barriers apply to all commands in the dependency
chains in the flink:vkGetRenderAreaGranularity command and the
<<synchronization-execution-and-memory-dependencies,Execution And
Memory Dependencies>> section (public issue 132).
* Clarify that a queue family is a set of queues in the
<<fundamentals-execmodel,Execution Model>> section (public issue
166).
* Removed requirement from valid usage language that
VkPresentInfoKHR::waitSemaphoreCount must be greater than 0 (public
issue 171).
* Fix broken internal links, describe structures consistently, use
consistent style for SPIR-V codewords, and tag normative terms that
were missing asciidoc tags (public issue 183 and ancillary
markup/normative language fixes).
* Fix typos for slink:VkPhysicalDeviceLimits member names in
slink:VkImageCreateInfo validity language (public issue 184).
Internal Issues:
* Document that the requested patch version number specified as part
of slink:VkApplicationInfo::pname:apiVersion is ignored when
creating an instance (internal issue 176).
* Clarify handling of extension structs in the
<<fundamentals-validusageValid Usage>> section (internal issue 254).
* Update required slink:VkImageFormatProperties::pname:maxMipLevels to
be limited to the maximum allowed mipmap pyramid size corresponding
to the actual maximum supported size for the format (internal issue
256).
* Modify the <<features-extentperimagetype,Allowed Extent Values Based
On Image Type>> section so the allowed maximum extent is the maximum
image dimension supported for each dimension of the type of texture
being queried (internal issue 257).
* Clarify in the <<spirvenv-module-validation,Validation Rules within
a Module>> section that at least one of the code:LocalSize execution
mode or code:WorkgroupSize decoration is required for each compute
shader entry point in a shader module (internal issue 279).
* Add validity rules for formats in flink:vkCmdClearColorImage and
flink:vkCmdClearDepthStencilImage (internal issue 283).
* Clarify that slink:VkImageFormatProperties::pname:maxResourceSize is
an upper bound, and that it may not be possible to create an image
anywhere near that size (internal issue 284).
Other Commits:
* Fix various minor markup errors reported by validation scripts.
* Change copyright from Khronos Free Use License to Apache 2.0 license
on relevant script/XML/header files. This does not affect the
specification source copyright.
33 lines
3.1 KiB
Plaintext
33 lines
3.1 KiB
Plaintext
// WARNING: DO NOT MODIFY! This file is automatically generated from the vk.xml registry
|
|
ifndef::doctype-manpage[]
|
|
.Valid Usage
|
|
********************************************************************************
|
|
endif::doctype-manpage[]
|
|
ifdef::doctype-manpage[]
|
|
Valid Usage
|
|
-----------
|
|
endif::doctype-manpage[]
|
|
* pname:flags must: be `0`
|
|
* pname:pipelineBindPoint must: be a valid elink:VkPipelineBindPoint value
|
|
* If pname:inputAttachmentCount is not `0`, pname:pInputAttachments must: be a pointer to an array of pname:inputAttachmentCount valid sname:VkAttachmentReference structures
|
|
* If pname:colorAttachmentCount is not `0`, pname:pColorAttachments must: be a pointer to an array of pname:colorAttachmentCount valid sname:VkAttachmentReference structures
|
|
* If pname:colorAttachmentCount is not `0`, and pname:pResolveAttachments is not `NULL`, pname:pResolveAttachments must: be a pointer to an array of pname:colorAttachmentCount valid sname:VkAttachmentReference structures
|
|
* If pname:pDepthStencilAttachment is not `NULL`, pname:pDepthStencilAttachment must: be a pointer to a valid sname:VkAttachmentReference structure
|
|
* If pname:preserveAttachmentCount is not `0`, pname:pPreserveAttachments must: be a pointer to an array of pname:preserveAttachmentCount basetype:uint32_t values
|
|
* pname:pipelineBindPoint must: be ename:VK_PIPELINE_BIND_POINT_GRAPHICS
|
|
* pname:colorCount must: be less than or equal to sname:VkPhysicalDeviceLimits::pname:maxColorAttachments
|
|
* If the first use of an attachment in this render pass is as an input attachment, and the attachment is not also used as a color or depth/stencil attachment in the same subpass, then pname:loadOp mustnot: be ename:VK_ATTACHMENT_LOAD_OP_CLEAR
|
|
* If pname:pResolveAttachments is not `NULL`, for each resolve attachment that does not have the value ename:VK_ATTACHMENT_UNUSED, the corresponding color attachment mustnot: have the value ename:VK_ATTACHMENT_UNUSED
|
|
* If pname:pResolveAttachments is not `NULL`, the sample count of each element of pname:pColorAttachments must: be anything other than ename:VK_SAMPLE_COUNT_1_BIT
|
|
* Any given element of pname:pResolveAttachments must: have a sample count of ename:VK_SAMPLE_COUNT_1_BIT
|
|
* Any given element of pname:pResolveAttachments must: have the same elink:VkFormat as its corresponding color attachment
|
|
* All attachments in pname:pColorAttachments and pname:pDepthStencilAttachment that are not ename:VK_ATTACHMENT_UNUSED must: have the same sample count
|
|
* If any input attachments are ename:VK_ATTACHMENT_UNUSED, then any pipelines bound during the subpass mustnot: accesss those input attachments from the fragment shader
|
|
* The pname:attachment member of any element of pname:pPreserveAttachments mustnot: be ename:VK_ATTACHMENT_UNUSED
|
|
* Any given element of pname:pPreserveAttachments mustnot: also be an element of any other member of the subpass description
|
|
* If any attachment is used as both an input attachment and a color or depth/stencil attachment, then each use must: use the same pname:layout
|
|
ifndef::doctype-manpage[]
|
|
********************************************************************************
|
|
endif::doctype-manpage[]
|
|
|