mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-01-23 04:40:13 +00:00
Change log for October 28, 2018 Vulkan 1.1.90 spec update:
* Update release number to 90.
Public Issues:
* Tag flink:vkQueueWaitIdle as `externsync` in `vk.xml` (public pull
request 815).
* Update README (public pull request 834).
* `VK_NV_framebuffer_mixed_samples` and `VK_AMD_mixed_attachment_samples`
had confusing and contradictory valid usage statements when read in the
all-extensions spec build. Change them to explicitly mention which
extension each is for (public issue Vulkan-ValidationLayers/issues/353).
Internal Issues:
* Update `COPYING.md` to clarify how externally generated Vulkan
Specifications (for translations, annotations, or other reasons) must be
copyrighted, and acknowledge the Exception Clause on the `vk.xml`
license (internal issue 1079).
* Specify that flink:vkGetPhysicalDeviceImageFormatProperties may: return
pname:maxMipLevels 1 if the format is ycbcr (internal issue 1361).
* Clarify previously underspecified language for
flink:vkCmdPushConstants::pname:pStageFlags regarding use of push
constants across multiple pipelines (internal issue 1403).
* Fix typo in XML/headers for
ename:VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_EXPLICIT_CREATE_INFO_EXT,
which was previously
etext:VK_STRUCTURE_TYPE_IMAGE_EXCPLICIT_DRM_FORMAT_MODIFIER_CREATE_INFO_EXT
(internal issue 1428).
* Fix markup of equations that were sporadically breaking the
`optimize-pdf` step of PDF generation, due (apparently) to inconsistent
treatment of unwrapped multicharacter terms by different LaTeX parsers
(internal issue 1435).
* For the <<memory-model-synchronizes-with synchronizes-with>> memory
model relation cases involving a release barrier plus relaxed atomic
write, treat the atomic as if it were a release atomic and allow the
acquire side to read from its hypothetical release sequence. This is
more consistent with how C++ defines synchronization for release fences
(internal issue cross-api/memory-model#72).
* Minor editorial changes to the <<memory-model, memory model>> appendix
based on external feedback.
This commit is contained in:
Jon Leech
parent
3c0abef815
commit
099174883d
109
COPYING.md
109
COPYING.md
@ -1,39 +1,74 @@
|
||||
The files in, and generated output documents from this Vulkan-Docs
|
||||
project are under a mix of copyright and license statements. Refer to
|
||||
the individual files for specific information. As a general
|
||||
guideline:
|
||||
COPYING.md for the KhronosGroup/Vulkan-Docs project
|
||||
===================================================
|
||||
|
||||
* The Vulkan Specification asciidoc sources, as well as other documentation
|
||||
which we expect people may wish to regenerate and distributed in other
|
||||
formats - such as the reference pages generated from the Specification
|
||||
source - are under a Creative Commons Attribution 4.0 license.
|
||||
** The specification sources have only recently (as of June 2017) been
|
||||
placed under this license. We will now be able to accept pull requests on
|
||||
Github, but there is a related Contribution License Agreement which
|
||||
people proposing PRs to the Vulkan-Docs repository must execute as part
|
||||
of opening the PR.
|
||||
* Generated output documents, including the official Vulkan Specification
|
||||
PDF and HTML documents, are under a proprietary Khronos license. See
|
||||
https://www.khronos.org/registry/speccopyright.html . Only Specification
|
||||
documents posted in the Vulkan Registry are official.
|
||||
* The Vulkan headers, spec build tools, and spec and registry configuration
|
||||
files are, for the most part, under the Apache 2 license. Some older files
|
||||
are under BSD-like licenses which may eventually be updated to Apache 2 as
|
||||
we have time.
|
||||
* There may be some configuration files customized from material shipped
|
||||
with the asciidoc and dblatex distributions. Such files continue under
|
||||
their original copyrights.
|
||||
* Some generated, transient files produced during the course of building
|
||||
the specification, headers, or other targets may not have copyrights.
|
||||
These are typically very short asciidoc fragments describing parts of
|
||||
the Vulkan API, and are incorporated by reference into specification
|
||||
or reference page builds.
|
||||
* If something is missing a copyright statement and that poses an
|
||||
*actual problem* for whatever you're doing, file an issue on GitHub
|
||||
and we'll eventually correct it in some fashion.
|
||||
# Licenses
|
||||
|
||||
Working with the different Khronos member company IP lawyers to make
|
||||
license changes is a very slow process constrained by the Khronos Member
|
||||
Agreement and IP Policy as well as by individual company concerns about
|
||||
their IP. Do not expect rapid changes in anything having to to with
|
||||
copyrights and licensing.
|
||||
The Vulkan-Docs project uses several licenses.
|
||||
|
||||
* The source files (in asciidoctor and other formats) for the Vulkan
|
||||
Specification, reference pages, and supporting documentation are licensed
|
||||
under the Creative Commons Attribution 4.0 International License
|
||||
("CC-BY").
|
||||
* Header files, scripts, programs, XML files, and other tooling used or
|
||||
generated as part of the build process is licensed under the Apache
|
||||
License, Version 2.0.
|
||||
* There are a few remaining configuration files and scripts adopted from
|
||||
other open source projects, such as the 'optimize-pdf' script. Such files
|
||||
continue under their original copyrights.
|
||||
* Some generated, transient files produced during the course of building the
|
||||
specification, headers, or other targets may not have copyrights. These
|
||||
are typically very short asciidoc fragments describing parts of the Vulkan
|
||||
API, and are incorporated by reference into specification or reference
|
||||
page builds.
|
||||
|
||||
Users outside Khronos who create and post Vulkan Specifications, whether
|
||||
modified or not, should use the CC-BY license on the output documents (HTML,
|
||||
PDF, etc.) they generate.
|
||||
|
||||
|
||||
# Frequently Asked Questions
|
||||
|
||||
Q: Why are the HTML and PDF Specifications posted on Khronos' website under
|
||||
a license which is neither CC-BY nor Apache 2.0?
|
||||
|
||||
A: The Specifications posted by Khronos in the Vulkan Registry are licensed
|
||||
under the proprietary Khronos Specification License. Only these
|
||||
Specifications are Ratified by the Khronos Board of Promoters, and therefore
|
||||
they are the only Specifications covered by the Khronos Intellectual
|
||||
Property Rights Policy.
|
||||
|
||||
|
||||
Q: Does Khronos allow the creation and distribution of modified versions of
|
||||
the Vulkan Specification, such as translations to other languages?
|
||||
|
||||
A: Yes. Such modified Specifications, since they are not created by Khronos,
|
||||
should be placed under the CC-BY license. If you believe your modifications
|
||||
are of general interest, consider contributing them back by making a pull
|
||||
request (PR) on the Vulkan-Docs project.
|
||||
|
||||
|
||||
Q: Can I contribute changes to the Vulkan Specification?
|
||||
|
||||
A: Yes, by opening a PR on the KhronosGroup/Vulkan-Docs Github project. You
|
||||
must execute a click-through Contributor License Agreement, which brings
|
||||
your changes under the umbrella of the Khronos IP policy. We welcome
|
||||
feedback and proposed changes, but will not neccessarily accept all such
|
||||
changes. Please keep PRs focused on solving a single problem; more ambitious
|
||||
PRs that try to solve multiple problems, or touch many parts of the
|
||||
Specification at once, are difficult for the Vulkan Working Group to review
|
||||
in a timely fashion.
|
||||
|
||||
|
||||
Q: Can you change the license on your files so they're compatible with my
|
||||
license?
|
||||
|
||||
A: We've added an "Exceptions to the Apache 2.0 License" clause to the
|
||||
copyright on vk.xml, to make it more compatible with GPL-licensed software,
|
||||
such as externally-generated language bindings. This seems to have addressed
|
||||
the problems we're aware of. It is possible we could extend the Exception
|
||||
Clause to other Apache-licensed files in the project, or otherwise
|
||||
accomodate new needs of external projects; but working with the different
|
||||
Khronos member company IP lawyers to make license changes is a very slow
|
||||
process, constrained by the Khronos Member Agreement and IP Policy as well
|
||||
as by individual company concerns about their IP. Do not expect rapid
|
||||
changes in anything having to to with copyrights and licensing.
|
||||
|
||||
@ -153,7 +153,7 @@ Each atomic operation has a memory <<memory-model-scope,scope>> and a
|
||||
<<memory-model-memory-semantics,semantics>>.
|
||||
Informally, the scope determines which other agents it is atomic with
|
||||
respect to, and the <<memory-model-memory-semantics,semantics>> constrains
|
||||
the ordering of other memory accesses.
|
||||
its ordering against other memory accesses.
|
||||
Device atomic operations have explicit scopes and semantics.
|
||||
Each host atomic operation implicitly uses the code:CrossDevice scope, and
|
||||
uses a memory semantics equivalent to a C++ std::memory_order value of
|
||||
@ -175,8 +175,9 @@ potentially-mutually-ordered and any of the following are true:
|
||||
* A is a device operation, B is a host operation, and the implementation
|
||||
supports concurrent host- and device-atomics.
|
||||
|
||||
NOTE: If two atomic operations are not mutually-ordered, then each must: be
|
||||
synchronized against the other as if it were a non-atomic operation.
|
||||
NOTE: If two atomic operations are not mutually-ordered, and if their sets of
|
||||
memory locations overlap, then each must: be synchronized against the other
|
||||
as if they were non-atomic operations.
|
||||
|
||||
[[memory-model-scoped-modification-order]]
|
||||
== Scoped Modification Order
|
||||
@ -184,6 +185,7 @@ synchronized against the other as if it were a non-atomic operation.
|
||||
For a given atomic operation A, all atomic operations that are
|
||||
mutually-ordered with A occur in an order known as A's _scoped modification
|
||||
order_.
|
||||
A's scoped modification order relates no other operations.
|
||||
|
||||
NOTE: Invocations outside the instance of A's memory scope may: observe the
|
||||
values at A's set of memory locations becoming visible to it in an order
|
||||
@ -271,7 +273,7 @@ tessellation control shaders, which is the only execution model where output
|
||||
variables are shared between invocations.
|
||||
|
||||
The memory semantics operand also optionally includes availability and
|
||||
visibility flags, which apply availability and/or visibility operations as
|
||||
visibility flags, which apply optional availability and visibility operations as
|
||||
described in <<memory-model-availability-visibility,availability and
|
||||
visibility>>.
|
||||
The availability/visibility flags are:
|
||||
@ -310,8 +312,8 @@ definition.
|
||||
[[memory-model-synchronizes-with]]
|
||||
== Synchronizes-With
|
||||
|
||||
_Synchronizes-with_ is a relation between atomic operations and/or memory
|
||||
barriers (aka fences on the host).
|
||||
_Synchronizes-with_ is a relation between operations, where each operation
|
||||
is either an atomic operation or a memory barrier (aka fence on the host).
|
||||
|
||||
If A and B are atomic operations, then A synchronizes-with B if and only if
|
||||
all of the following are true:
|
||||
@ -319,7 +321,8 @@ all of the following are true:
|
||||
* A performs a release operation
|
||||
* B performs an acquire operation
|
||||
* A and B are mutually-ordered
|
||||
* B takes its value from the release sequence headed by A
|
||||
* B reads a value written by A or by an operation in the release sequence
|
||||
headed by A
|
||||
|
||||
code:OpControlBarrier, code:OpMemoryBarrier, and code:OpMemoryNamedBarrier
|
||||
are _memory barrier_ instructions in SPIR-V.
|
||||
@ -331,8 +334,10 @@ following are true:
|
||||
* there exists an atomic write X (with any memory semantics)
|
||||
* A is program-ordered before X
|
||||
* X and B are mutually-ordered
|
||||
* B reads the value written by X (or the release sequence headed by X, if
|
||||
X has release semantics)
|
||||
* B reads a value written by X or by an operation in the release sequence
|
||||
headed by X
|
||||
** If X is relaxed, it is still considered to head a hypothetical release
|
||||
sequence for this rule
|
||||
* A and B are in the instance of each other's memory scopes
|
||||
* X's storage class is in A's semantics.
|
||||
|
||||
@ -343,7 +348,8 @@ following are true:
|
||||
* there exists an atomic read X (with any memory semantics)
|
||||
* X is program-ordered before B
|
||||
* X and A are mutually-ordered
|
||||
* X reads the value written by A (or the release sequence headed by A)
|
||||
* X reads a value written by A or by an operation in the release sequence
|
||||
headed by A
|
||||
* A and B are in the instance of each other's memory scopes
|
||||
* X's storage class is in B's semantics.
|
||||
|
||||
@ -355,15 +361,17 @@ synchronizes-with B if all of the following are true:
|
||||
* there exists an atomic read Y (with any memory semantics)
|
||||
* Y is program-ordered before B
|
||||
* X and Y are mutually-ordered
|
||||
* Y reads the value written by X (or the release sequence headed by X, if
|
||||
X has release semantics)
|
||||
* Y reads the value written by X or by an operation in the release sequence
|
||||
headed by X
|
||||
** If X is relaxed, it is still considered to head a hypothetical release
|
||||
sequence for this rule
|
||||
* A and B are in the instance of each other's memory scopes
|
||||
* X's and Y's storage class is in A's and B's semantics.
|
||||
** NOTE: X and Y must have the same storage class, because they are
|
||||
mutually ordered.
|
||||
|
||||
If A is a release barrier and B is an acquire barrier and C is a control
|
||||
barrier (where A can optionally equal C and/or B can optionally equal C),
|
||||
barrier (where A can optionally equal C and B can optionally equal C),
|
||||
then A synchronizes-with B if all of the following are true:
|
||||
|
||||
* A is program-ordered before (or equals) C
|
||||
|
||||
@ -3876,6 +3876,15 @@ include::../api/protos/vkCmdPushConstants.txt[]
|
||||
* pname:pValues is an array of pname:size bytes containing the new push
|
||||
constant values.
|
||||
|
||||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
As pname:stageFlags needs to include all flags the relevant push constant
|
||||
ranges were created with, any flags that are not supported by the queue
|
||||
family that the slink:VkCommandPool used to allocate pname:commandBuffer was
|
||||
created on are ignored.
|
||||
====
|
||||
|
||||
.Valid Usage
|
||||
****
|
||||
* [[VUID-vkCmdPushConstants-offset-01795]]
|
||||
|
||||
@ -7242,6 +7242,10 @@ ifdef::VK_VERSION_1_1,VK_KHR_external_memory_capabilities[]
|
||||
with a handle type included in the pname:handleTypes member for which
|
||||
mipmap image support is not required
|
||||
endif::VK_VERSION_1_1,VK_KHR_external_memory_capabilities[]
|
||||
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
|
||||
** image pname:format is one of those listed in
|
||||
<<features-formats-requiring-sampler-ycbcr-conversion>>
|
||||
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
|
||||
* pname:maxArrayLayers is the maximum number of array layers.
|
||||
* If pname:tiling is ename:VK_IMAGE_TILING_LINEAR, then
|
||||
pname:maxArrayLayers must: either be equal to 1 or be no less than
|
||||
|
||||
@ -592,7 +592,8 @@ ifdef::VK_AMD_mixed_attachment_samples[]
|
||||
[[fragops-mixed-attachment-samples]]
|
||||
== Mixed attachment samples
|
||||
|
||||
Special rules apply to per-fragment operations when the number of samples of
|
||||
When the +VK_AMD_mixed_attachment_samples+ extension is enabled,
|
||||
special rules apply to per-fragment operations when the number of samples of
|
||||
the color attachments differs from the number of samples of the
|
||||
depth/stencil attachment used in a subpass.
|
||||
|
||||
@ -1266,16 +1267,14 @@ with one bit for each sample in the color attachment(s) for the subpass.
|
||||
If a bit in the color sample mask is 0, then blending and writing to the
|
||||
framebuffer are not performed for that sample.
|
||||
|
||||
ifndef::VK_NV_framebuffer_mixed_samples[]
|
||||
|
||||
Each color sample is associated with a unique rasterization sample, and the
|
||||
When the +VK_NV_framebuffer_mixed_samples+ extension is not enabled,
|
||||
each color sample is associated with a unique rasterization sample, and the
|
||||
value of the coverage mask is assigned to the color sample mask.
|
||||
|
||||
endif::VK_NV_framebuffer_mixed_samples[]
|
||||
|
||||
ifdef::VK_NV_framebuffer_mixed_samples[]
|
||||
|
||||
If the pipeline's
|
||||
When the +VK_NV_framebuffer_mixed_samples+ extension is enabled,
|
||||
if the pipeline's
|
||||
slink:VkPipelineMultisampleStateCreateInfo::pname:rasterizationSamples is
|
||||
greater than one and the slink:VkAttachmentDescription::pname:samples of the
|
||||
color attachments is one, then the fragment's coverage is reduced from
|
||||
|
||||
@ -839,28 +839,29 @@ endif::VK_EXT_sample_locations[]
|
||||
pname:layout must: be
|
||||
<<descriptorsets-pipelinelayout-consistency,consistent>> with all
|
||||
shaders specified in pname:pStages
|
||||
ifndef::VK_AMD_mixed_attachment_samples[]
|
||||
ifndef::VK_NV_framebuffer_mixed_samples[]
|
||||
* [[VUID-VkGraphicsPipelineCreateInfo-subpass-00757]]
|
||||
If pname:subpass uses color and/or depth/stencil attachments, then the
|
||||
If neither the +VK_AMD_mixed_attachment_samples+ nor the
|
||||
+VK_NV_framebuffer_mixed_samples+ extensions are enabled, and if
|
||||
pname:subpass uses color and/or depth/stencil attachments, then the
|
||||
pname:rasterizationSamples member of pname:pMultisampleState must: be
|
||||
the same as the sample count for those subpass attachments
|
||||
endif::VK_NV_framebuffer_mixed_samples[]
|
||||
endif::VK_AMD_mixed_attachment_samples[]
|
||||
ifdef::VK_AMD_mixed_attachment_samples[]
|
||||
* [[VUID-VkGraphicsPipelineCreateInfo-subpass-01505]]
|
||||
If pname:subpass uses color and/or depth/stencil attachments, then the
|
||||
If the +VK_AMD_mixed_attachment_samples+ extension is enabled, and
|
||||
if pname:subpass uses color and/or depth/stencil attachments, then the
|
||||
pname:rasterizationSamples member of pname:pMultisampleState must: equal
|
||||
the maximum of the sample counts of those subpass attachments
|
||||
endif::VK_AMD_mixed_attachment_samples[]
|
||||
ifdef::VK_NV_framebuffer_mixed_samples[]
|
||||
* [[VUID-VkGraphicsPipelineCreateInfo-subpass-01411]]
|
||||
If pname:subpass has a depth/stencil attachment and depth test, stencil
|
||||
If the +VK_NV_framebuffer_mixed_samples+ extension is enabled, and
|
||||
if pname:subpass has a depth/stencil attachment and depth test, stencil
|
||||
test, or depth bounds test are enabled, then the
|
||||
pname:rasterizationSamples member of pname:pMultisampleState must: be
|
||||
the same as the sample count of the depth/stencil attachment
|
||||
* [[VUID-VkGraphicsPipelineCreateInfo-subpass-01412]]
|
||||
If pname:subpass has any color attachments, then the
|
||||
If the +VK_NV_framebuffer_mixed_samples+ extension is enabled, and
|
||||
if pname:subpass has any color attachments, then the
|
||||
pname:rasterizationSamples member of pname:pMultisampleState must: be
|
||||
greater than or equal to the sample count for those subpass attachments
|
||||
endif::VK_NV_framebuffer_mixed_samples[]
|
||||
|
||||
@ -153,7 +153,8 @@ include::../api/structs/VkPipelineMultisampleStateCreateInfo.txt[]
|
||||
pname:minSampleShading must: be in the range [eq]#[0,1]#
|
||||
ifdef::VK_NV_framebuffer_mixed_samples[]
|
||||
* [[VUID-VkPipelineMultisampleStateCreateInfo-rasterizationSamples-01415]]
|
||||
If the subpass has any color attachments and pname:rasterizationSamples
|
||||
If the +VK_NV_framebuffer_mixed_samples+ extension is enabled, and
|
||||
if the subpass has any color attachments and pname:rasterizationSamples
|
||||
is greater than the number of color samples, then
|
||||
pname:sampleShadingEnable must: be ename:VK_FALSE
|
||||
endif::VK_NV_framebuffer_mixed_samples[]
|
||||
@ -183,24 +184,30 @@ Surviving fragments are processed by fragment shaders.
|
||||
Fragment shaders determine associated data for fragments, and can: also
|
||||
modify or replace their assigned depth values.
|
||||
|
||||
ifndef::VK_AMD_mixed_attachment_samples[]
|
||||
ifndef::VK_NV_framebuffer_mixed_samples[]
|
||||
|
||||
If the subpass for which this pipeline is being created uses color and/or
|
||||
When the +VK_AMD_mixed_attachment_samples+ and
|
||||
+VK_NV_framebuffer_mixed_samples+ extensions are not enabled,
|
||||
if the subpass for which this pipeline is being created uses color and/or
|
||||
depth/stencil attachments, then pname:rasterizationSamples must: be the same
|
||||
as the sample count for those subpass attachments.
|
||||
|
||||
endif::VK_NV_framebuffer_mixed_samples[]
|
||||
endif::VK_AMD_mixed_attachment_samples[]
|
||||
|
||||
ifdef::VK_AMD_mixed_attachment_samples[]
|
||||
|
||||
If the subpass for which this pipeline is being created uses color and/or
|
||||
When the +VK_AMD_mixed_attachment_samples+ extension is enabled,
|
||||
if the subpass for which this pipeline is being created uses color and/or
|
||||
depth/stencil attachments, then pname:rasterizationSamples must: be the same
|
||||
as the maximum of the sample counts of those subpass attachments.
|
||||
|
||||
endif::VK_AMD_mixed_attachment_samples[]
|
||||
|
||||
ifdef::VK_NV_framebuffer_mixed_samples[]
|
||||
|
||||
When the +VK_NV_framebuffer_mixed_samples+ extension is enabled,
|
||||
pname:rasterizationSamples must: match the sample count of the depth/stencil
|
||||
attachment if present, otherwise must: be greater than or equal to the sample
|
||||
count of the color attachments, if present.
|
||||
|
||||
endif::VK_NV_framebuffer_mixed_samples[]
|
||||
|
||||
If the subpass for which this pipeline is being created does not use color
|
||||
or depth/stencil attachments, pname:rasterizationSamples must: follow the
|
||||
rules for a <<renderpass-noattachments, zero-attachment subpass>>.
|
||||
@ -1267,13 +1274,14 @@ process for each fragment.
|
||||
If sample shading is enabled an implementation must: provide a minimum of
|
||||
[eq]#max({lceil} pname:minSampleShadingFactor {times} pname:totalSamples
|
||||
{rceil}, 1)# unique associated data for each fragment, where
|
||||
pname:minSampleShadingFactor is the minimum fraction of sample shading and
|
||||
pname:totalSamples is
|
||||
pname:minSampleShadingFactor is the minimum fraction of sample shading.
|
||||
ifdef::VK_AMD_mixed_attachment_samples[]
|
||||
the number of samples of the color attachments used in the subpass or, if
|
||||
the subpass does not use any color attachments,
|
||||
If the +VK_AMD_mixed_attachment_samples+ extension is enabled and the subpass
|
||||
uses color attachments, pname:totalSamples is the number of samples of the
|
||||
color attachments.
|
||||
Otherwise,
|
||||
endif::VK_AMD_mixed_attachment_samples[]
|
||||
the value of
|
||||
pname:totalSamples is the value of
|
||||
slink:VkPipelineMultisampleStateCreateInfo::pname:rasterizationSamples
|
||||
specified at pipeline creation time.
|
||||
These are associated with the samples in an implementation-dependent manner.
|
||||
|
||||
@ -868,19 +868,18 @@ attachment.
|
||||
ename:VK_ATTACHMENT_UNUSED must: have the same sample count
|
||||
ifdef::VK_AMD_mixed_attachment_samples[]
|
||||
* [[VUID-VkSubpassDescription-pColorAttachments-01506]]
|
||||
All attachments in pname:pColorAttachments that are not
|
||||
If the +VK_AMD_mixed_attachment_samples+ extension is enabled, and
|
||||
all attachments in pname:pColorAttachments that are not
|
||||
ename:VK_ATTACHMENT_UNUSED must: have a sample count that is smaller
|
||||
than or equal to the sample count of pname:pDepthStencilAttachment if it
|
||||
is not ename:VK_ATTACHMENT_UNUSED
|
||||
endif::VK_AMD_mixed_attachment_samples[]
|
||||
ifndef::VK_AMD_mixed_attachment_samples[]
|
||||
ifndef::VK_NV_framebuffer_mixed_samples[]
|
||||
* [[VUID-VkSubpassDescription-pDepthStencilAttachment-01418]]
|
||||
If pname:pDepthStencilAttachment is not ename:VK_ATTACHMENT_UNUSED and
|
||||
If neither the +VK_AMD_mixed_attachment_samples+ nor the
|
||||
+VK_NV_framebuffer_mixed_samples+ extensions are enabled, and if
|
||||
pname:pDepthStencilAttachment is not ename:VK_ATTACHMENT_UNUSED and
|
||||
any attachments in pname:pColorAttachments are not
|
||||
ename:VK_ATTACHMENT_UNUSED, they must: have the same sample count
|
||||
endif::VK_NV_framebuffer_mixed_samples[]
|
||||
endif::VK_AMD_mixed_attachment_samples[]
|
||||
* [[VUID-VkSubpassDescription-None-00852]]
|
||||
If any input attachments are ename:VK_ATTACHMENT_UNUSED, then any
|
||||
pipelines bound during the subpass must: not access those input
|
||||
@ -1694,19 +1693,18 @@ corresponding subpass.
|
||||
ename:VK_ATTACHMENT_UNUSED must: have the same sample count
|
||||
ifdef::VK_AMD_mixed_attachment_samples[]
|
||||
* [[VUID-VkSubpassDescription2KHR-pColorAttachments-03070]]
|
||||
All attachments in pname:pColorAttachments that are not
|
||||
If the +VK_AMD_mixed_attachment_samples+ extension is enabled,
|
||||
all attachments in pname:pColorAttachments that are not
|
||||
ename:VK_ATTACHMENT_UNUSED must: have a sample count that is smaller
|
||||
than or equal to the sample count of pname:pDepthStencilAttachment if it
|
||||
is not ename:VK_ATTACHMENT_UNUSED
|
||||
endif::VK_AMD_mixed_attachment_samples[]
|
||||
ifndef::VK_AMD_mixed_attachment_samples[]
|
||||
ifndef::VK_NV_framebuffer_mixed_samples[]
|
||||
* [[VUID-VkSubpassDescription2KHR-pDepthStencilAttachment-03071]]
|
||||
If pname:pDepthStencilAttachment is not ename:VK_ATTACHMENT_UNUSED and
|
||||
If neither the +VK_AMD_mixed_attachment_samples+ nor the
|
||||
+VK_NV_framebuffer_mixed_samples+ extensions are enabled, and if
|
||||
pname:pDepthStencilAttachment is not ename:VK_ATTACHMENT_UNUSED and
|
||||
any attachments in pname:pColorAttachments are not
|
||||
ename:VK_ATTACHMENT_UNUSED, they must: have the same sample count
|
||||
endif::VK_NV_framebuffer_mixed_samples[]
|
||||
endif::VK_AMD_mixed_attachment_samples[]
|
||||
* [[VUID-VkSubpassDescription2KHR-None-03072]]
|
||||
If any input attachments are ename:VK_ATTACHMENT_UNUSED, then any
|
||||
pipelines bound during the subpass must: not access those input
|
||||
|
||||
@ -978,36 +978,44 @@ pname:chromaFilter is ename:VK_FILTER_NEAREST for explicit reconstruction.
|
||||
Due to the number of options, these formulae are expressed more
|
||||
concisely as follows:
|
||||
+
|
||||
[width="30%",options="header",cols="5,1"]
|
||||
|====
|
||||
| pname:xChromaOffset | δ~i~
|
||||
| etext:COSITED_EVEN | 0
|
||||
| etext:MIDPOINT | 0.5
|
||||
|====
|
||||
+
|
||||
[width="30%",options="header",cols="5,1"]
|
||||
|====
|
||||
| pname:yChromaOffset | δ~j~
|
||||
| etext:COSITED_EVEN | 0
|
||||
| etext:MIDPOINT | 0.5
|
||||
|====
|
||||
[latexmath]
|
||||
+++++
|
||||
\begin{aligned}
|
||||
i_{RB} & =
|
||||
\begin{cases}
|
||||
0.5 \times (i) & \textrm{If xChromaOffset = COSITED}\_\textrm{EVEN} \\
|
||||
0.5 \times (i - 0.5) & \textrm{If xChromaOffset = MIDPOINT}
|
||||
\end{cases}\\
|
||||
j_{RB} & =
|
||||
\begin{cases}
|
||||
0.5 \times (j) & \textrm{If yChromaOffset = COSITED}\_\textrm{EVEN} \\
|
||||
0.5 \times (j - 0.5) & \textrm{If yChromaOffset = MIDPOINT}
|
||||
\end{cases}\\
|
||||
\\
|
||||
i_{floor} & = \lfloor i_{RB} \rfloor \\
|
||||
j_{floor} & = \lfloor j_{RB} \rfloor \\
|
||||
\\
|
||||
i_{frac} & = i_{RB} - i_{floor} \\
|
||||
j_{frac} & = j_{RB} - j_{floor}
|
||||
\end{aligned}
|
||||
+++++
|
||||
+
|
||||
[latexmath]
|
||||
+++++
|
||||
\begin{aligned}
|
||||
\tau_{RB}'(i,j) = &\\
|
||||
&\tau_{RB}(\lfloor 0.5\times(i-\delta_i)\rfloor, \lfloor 0.5\times(j-\delta_j)\rfloor)[level]
|
||||
&& \times (1 - (0.5\times(i-\delta_i) - \lfloor 0.5\times(i-\delta_i)\rfloor))
|
||||
&& \times (1 - (0.5\times(j-\delta_j) - \lfloor 0.5\times(j-\delta_j)\rfloor)) +\\
|
||||
&\tau_{RB}(1+\lfloor 0.5\times(i-\delta_i)\rfloor, \lfloor 0.5\times(j-\delta_j)\rfloor)[level]
|
||||
&& \times (0.5\times(i-\delta_i) - \lfloor 0.5\times(i-\delta_i)\rfloor)
|
||||
&& \times (1 - (0.5\times(j-\delta_j) - \lfloor 0.5\times(j-\delta_j)\rfloor)) +\\
|
||||
&\tau_{RB}(\lfloor 0.5\times(i-\delta_i)\rfloor, 1+\lfloor 0.5\times(j-\delta_j)\rfloor)[level]
|
||||
&& \times (1 - (0.5\times(i-\delta_i) - \lfloor 0.5\times(i-\delta_i)\rfloor))
|
||||
&& \times (0.5\times(j-\delta_j) - \lfloor 0.5\times(j-\delta_j)\rfloor) +\\
|
||||
&\tau_{RB}(1+\lfloor 0.5\times(i-\delta_i)\rfloor, 1+\lfloor 0.5\times(j-\delta_j)\rfloor)[level]
|
||||
&& \times (0.5\times(i-\delta_i) - \lfloor 0.5\times(i-\delta_i)\rfloor)
|
||||
&& \times (0.5\times(j-\delta_j) - \lfloor 0.5\times(j-\delta_j)\rfloor)
|
||||
\tau_{RB}'(i,j) =
|
||||
& \tau_{RB}( i_{floor}, j_{floor})[level]
|
||||
& \times & ( 1 - i_{frac} ) &
|
||||
& \times & ( 1 - j_{frac} ) & + \\
|
||||
& \tau_{RB}( 1 + i_{floor}, j_{floor})[level]
|
||||
& \times & ( i_{frac} ) &
|
||||
& \times & ( 1 - j_{frac} ) & + \\
|
||||
& \tau_{RB}( i_{floor}, 1 + j_{floor})[level]
|
||||
& \times & ( 1 - i_{frac} ) &
|
||||
& \times & ( j_{frac} ) & + \\
|
||||
& \tau_{RB}( 1 + i_{floor}, 1 + j_{floor})[level]
|
||||
& \times & ( i_{frac} ) &
|
||||
& \times & ( j_{frac} ) &
|
||||
\end{aligned}
|
||||
+++++
|
||||
|
||||
|
||||
@ -47,7 +47,7 @@ extern "C" {
|
||||
|
||||
|
||||
#define VK_NULL_HANDLE 0
|
||||
|
||||
|
||||
|
||||
|
||||
#define VK_DEFINE_HANDLE(object) typedef struct object##_T* object;
|
||||
@ -60,7 +60,7 @@ extern "C" {
|
||||
#define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef uint64_t object;
|
||||
#endif
|
||||
#endif
|
||||
|
||||
|
||||
|
||||
|
||||
typedef uint32_t VkFlags;
|
||||
@ -406,7 +406,7 @@ typedef enum VkStructureType {
|
||||
VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT = 1000158001,
|
||||
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_DRM_FORMAT_MODIFIER_INFO_EXT = 1000158002,
|
||||
VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_LIST_CREATE_INFO_EXT = 1000158003,
|
||||
VK_STRUCTURE_TYPE_IMAGE_EXCPLICIT_DRM_FORMAT_MODIFIER_CREATE_INFO_EXT = 1000158004,
|
||||
VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_EXPLICIT_CREATE_INFO_EXT = 1000158004,
|
||||
VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT = 1000158005,
|
||||
VK_STRUCTURE_TYPE_VALIDATION_CACHE_CREATE_INFO_EXT = 1000160000,
|
||||
VK_STRUCTURE_TYPE_SHADER_MODULE_VALIDATION_CACHE_CREATE_INFO_EXT = 1000160001,
|
||||
|
||||
@ -977,7 +977,7 @@ server.
|
||||
<member>const <type>void</type>* <name>pNext</name></member>
|
||||
<member optional="true"><type>VkShaderModuleCreateFlags</type> <name>flags</name></member>
|
||||
<member><type>size_t</type> <name>codeSize</name><comment>Specified in bytes</comment></member>
|
||||
<member len="latexmath:[codeSize \over 4]" altlen="codeSize / 4">const <type>uint32_t</type>* <name>pCode</name><comment>Binary code of size codeSize</comment></member>
|
||||
<member len="latexmath:[\textrm{codeSize} \over 4]" altlen="codeSize / 4">const <type>uint32_t</type>* <name>pCode</name><comment>Binary code of size codeSize</comment></member>
|
||||
</type>
|
||||
<type category="struct" name="VkDescriptorSetLayoutBinding">
|
||||
<member><type>uint32_t</type> <name>binding</name><comment>Binding number for this entry</comment></member>
|
||||
@ -3564,7 +3564,7 @@ server.
|
||||
<member len="drmFormatModifierCount">const <type>uint64_t</type>* <name>pDrmFormatModifiers</name></member>
|
||||
</type>
|
||||
<type category="struct" name="VkImageDrmFormatModifierExplicitCreateInfoEXT" structextends="VkImageCreateInfo">
|
||||
<member values="VK_STRUCTURE_TYPE_IMAGE_EXCPLICIT_DRM_FORMAT_MODIFIER_CREATE_INFO_EXT"><type>VkStructureType</type> <name>sType</name></member>
|
||||
<member values="VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_EXPLICIT_CREATE_INFO_EXT"><type>VkStructureType</type> <name>sType</name></member>
|
||||
<member>const <type>void</type>* <name>pNext</name></member>
|
||||
<member><type>uint64_t</type> <name>drmFormatModifier</name></member>
|
||||
<member optional="false"><type>uint32_t</type> <name>drmFormatModifierPlaneCount</name></member>
|
||||
@ -9367,7 +9367,7 @@ server.
|
||||
<enum offset="1" extends="VkStructureType" name="VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT"/>
|
||||
<enum offset="2" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_DRM_FORMAT_MODIFIER_INFO_EXT"/>
|
||||
<enum offset="3" extends="VkStructureType" name="VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_LIST_CREATE_INFO_EXT"/>
|
||||
<enum offset="4" extends="VkStructureType" name="VK_STRUCTURE_TYPE_IMAGE_EXCPLICIT_DRM_FORMAT_MODIFIER_CREATE_INFO_EXT"/>
|
||||
<enum offset="4" extends="VkStructureType" name="VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_EXPLICIT_CREATE_INFO_EXT"/>
|
||||
<enum offset="5" extends="VkStructureType" name="VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT"/>
|
||||
|
||||
<enum offset="0" extends="VkImageTiling" name="VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT"/>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user