(The previous commit didn't actually include internal gitlab changes
since 1.1.89; fixed now).
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
1858598fe0
commit
894211de5f
|
|
@ -0,0 +1,71 @@
|
|||
|
||||
# _Vulkan Feature Development Checklist Template_
|
||||
|
||||
_This template captures checklists for the stages of development that
|
||||
a Vulkan KHR extension passes through as it moves from development to
|
||||
ratification and release. You should create an issue from this template
|
||||
when the extension draft is stable and there is reasonable consensus in
|
||||
the working group that it is on a path to ratification._
|
||||
|
||||
_Edit the template to suit the extension you are considering (and to
|
||||
delete the italicized instructions). Delete any requirements that are not
|
||||
relevant; for example, an extension that has no language dependencies
|
||||
will not need SPIR-V / GLSL / HLSL items, and an EXT GLSL extension
|
||||
will not require Promoter ratification._
|
||||
|
||||
_Requirements may be waived by vote of of the working group, provided
|
||||
that a 2/3 majority of non-abstaining vote are in favor._
|
||||
|
||||
# Release checklist for _VK_KHR_extension_name_here_
|
||||
|
||||
## Preconditions for Call for Votes (CfV)
|
||||
|
||||
_A formal CfV is issued following agreement at a Tuesday meeting that a
|
||||
vote should be held at the following Tuesday meeting. Preconditions
|
||||
for a CfV are as follows; "specification stable" means that there are
|
||||
no MRs in flight that modify behavior defined by the extension and its
|
||||
dependencies. Delete any of the following preconditions that are not relevant to
|
||||
the extension in question_
|
||||
|
||||
|
||||
- [ ] VAP consulted to the extent the WG considers appropriate
|
||||
- [ ] CTS tests approved with three passing implementations
|
||||
- [ ] Vulkan specification merged and stable in devel
|
||||
- [ ] SPIR-V specification merged and stable
|
||||
- [ ] GLSL specification merged and stable
|
||||
|
||||
## Preconditions for submission to Promoters
|
||||
|
||||
- [ ] WG vote to submit passed with a 3/4 majority
|
||||
- [ ] Submission package available for Promoter review
|
||||
|
||||
## Preconditions for creating public release issue on GitHub
|
||||
|
||||
_Delete any of the following preconditions that are not relevant to
|
||||
the extension in question_
|
||||
|
||||
- [ ] Vulkan specification ratified by Promoters
|
||||
- [ ] SPIR-V specification ratified by Promoters
|
||||
- [ ] GLSL specification ratified by Promoters
|
||||
- [ ] GLSLang implementation approved to merge
|
||||
- [ ] Marketing summary written and approved by Vulkan WG and PR team
|
||||
- [ ] Validation layer implementation approved to merge
|
||||
- [ ] HLSL mapping defined
|
||||
- [ ] HLSL mapping supported in GLSLang
|
||||
- [ ] HLSL mapping supported in DXC
|
||||
- [ ] CTS tests approved to merge
|
||||
- [ ] SPIR-V tools implementation approved to merge
|
||||
- [ ] Loader support approved to merge (for instance extensions)
|
||||
- [ ] Public release approved by Vulkan WG
|
||||
|
||||
## Preconditions for closing this issue
|
||||
|
||||
- [ ] Public release issue items checked off and issue closed
|
||||
|
||||
## Additional (Optional) Items
|
||||
|
||||
_These additional items are recommended for creation at some
|
||||
point during or after the release, but are not required at any point._
|
||||
|
||||
- [ ] Usage Examples
|
||||
- [ ] Usage Advice
|
||||
|
|
@ -8,6 +8,51 @@ public pull requests that have been accepted.
|
|||
|
||||
-----------------------------------------------------
|
||||
|
||||
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.
|
||||
|
||||
-----------------------------------------------------
|
||||
|
||||
Change log for October 21, 2018 Vulkan 1.1.89 spec update:
|
||||
|
||||
* Update release number to 89.
|
||||
|
|
|
|||
2
Makefile
2
Makefile
|
|
@ -112,7 +112,7 @@ VERBOSE =
|
|||
# EXTRAATTRIBS sets additional attributes, if passed to make
|
||||
# ADOCOPTS options for asciidoc->HTML5 output
|
||||
NOTEOPTS = -a editing-notes -a implementation-guide
|
||||
PATCHVERSION = 89
|
||||
PATCHVERSION = 90
|
||||
ifneq (,$(findstring VK_VERSION_1_1,$(VERSIONS)))
|
||||
SPECREVISION = 1.1.$(PATCHVERSION)
|
||||
else
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ include::meta/VK_KHR_8bit_storage.txt[]
|
|||
*Contributors*::
|
||||
- Alexander Galazin, Arm
|
||||
|
||||
The +VK_KHR_8bit_storage+ extension allows use of 8-bit types in uniform and
|
||||
The `VK_KHR_8bit_storage` extension allows use of 8-bit types in uniform and
|
||||
storage buffers, and push constant blocks.
|
||||
This extension introduces several new optional features which map to SPIR-V
|
||||
capabilities and allow access to 8-bit data in code:Block-decorated objects
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ include::meta/VK_KHR_vulkan_memory_model.txt[]
|
|||
- Robert Simpson, Qualcomm Technologies, Inc.
|
||||
- Brian Sumner, AMD
|
||||
|
||||
The +VK_KHR_vulkan_memory_model+ extension allows use of the
|
||||
The `VK_KHR_vulkan_memory_model` extension allows use of the
|
||||
<<memory-model,Vulkan Memory Model>>, which formally defines how to
|
||||
synchronize memory accesses to the same memory locations performed by
|
||||
multiple shader invocations.
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ ifdef::VK_EXT_astc_decode_mode[]
|
|||
|
||||
=== ASTC decode mode
|
||||
|
||||
If the +VK_EXT_astc_decode_mode+ extension is enabled the ASTC decoding
|
||||
If the `VK_EXT_astc_decode_mode` extension is enabled the ASTC decoding
|
||||
described in the <<data-format,Khronos Data Format Specification>> is
|
||||
modified by replacing or modifying the corresponding sections as described
|
||||
below.
|
||||
|
|
|
|||
|
|
@ -175,9 +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, and if their sets of
|
||||
memory locations overlap, then each must: be synchronized against the other
|
||||
as if they were non-atomic operations.
|
||||
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
|
||||
|
|
@ -273,9 +273,9 @@ 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 optional availability and visibility operations as
|
||||
described in <<memory-model-availability-visibility,availability and
|
||||
visibility>>.
|
||||
visibility flags, which apply optional availability and visibility
|
||||
operations as described in
|
||||
<<memory-model-availability-visibility,availability and visibility>>.
|
||||
The availability/visibility flags are:
|
||||
|
||||
* MakeAvailable: Semantics must: be Release or AcquireRelease.
|
||||
|
|
@ -361,8 +361,8 @@ 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 by an operation in the release sequence
|
||||
headed by X
|
||||
* 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
|
||||
|
|
@ -371,8 +371,8 @@ synchronizes-with B if all of the following are true:
|
|||
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 B can optionally equal C),
|
||||
then A synchronizes-with B if all of the following are true:
|
||||
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
|
||||
* C is program-ordered before (or equals) B
|
||||
|
|
|
|||
|
|
@ -592,10 +592,10 @@ ifdef::VK_AMD_mixed_attachment_samples[]
|
|||
[[fragops-mixed-attachment-samples]]
|
||||
== Mixed attachment samples
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Let [eq]#C# be the number of color attachment samples and [eq]#D# be the
|
||||
number of depth/stencil attachment samples used by a given subpass.
|
||||
|
|
@ -1267,14 +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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
ifdef::VK_NV_framebuffer_mixed_samples[]
|
||||
|
||||
When the +VK_NV_framebuffer_mixed_samples+ extension is enabled,
|
||||
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
|
||||
|
|
|
|||
|
|
@ -840,28 +840,28 @@ endif::VK_EXT_sample_locations[]
|
|||
<<descriptorsets-pipelinelayout-consistency,consistent>> with all
|
||||
shaders specified in pname:pStages
|
||||
* [[VUID-VkGraphicsPipelineCreateInfo-subpass-00757]]
|
||||
If neither the +VK_AMD_mixed_attachment_samples+ nor the
|
||||
+VK_NV_framebuffer_mixed_samples+ extensions are enabled, and if
|
||||
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
|
||||
ifdef::VK_AMD_mixed_attachment_samples[]
|
||||
* [[VUID-VkGraphicsPipelineCreateInfo-subpass-01505]]
|
||||
If the +VK_AMD_mixed_attachment_samples+ extension is enabled, and
|
||||
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 the +VK_NV_framebuffer_mixed_samples+ extension is enabled, and
|
||||
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 the +VK_NV_framebuffer_mixed_samples+ extension is enabled, and
|
||||
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,10 +153,10 @@ 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 +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
|
||||
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[]
|
||||
|
||||
****
|
||||
|
|
@ -184,16 +184,16 @@ Surviving fragments are processed by fragment shaders.
|
|||
Fragment shaders determine associated data for fragments, and can: also
|
||||
modify or replace their assigned depth values.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
ifdef::VK_AMD_mixed_attachment_samples[]
|
||||
|
||||
When the +VK_AMD_mixed_attachment_samples+ extension is enabled,
|
||||
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.
|
||||
|
||||
|
|
@ -201,10 +201,10 @@ endif::VK_AMD_mixed_attachment_samples[]
|
|||
|
||||
ifdef::VK_NV_framebuffer_mixed_samples[]
|
||||
|
||||
When the +VK_NV_framebuffer_mixed_samples+ extension is enabled,
|
||||
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.
|
||||
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[]
|
||||
|
||||
|
|
@ -1276,9 +1276,9 @@ If sample shading is enabled an implementation must: provide a minimum of
|
|||
{rceil}, 1)# unique associated data for each fragment, where
|
||||
pname:minSampleShadingFactor is the minimum fraction of sample shading.
|
||||
ifdef::VK_AMD_mixed_attachment_samples[]
|
||||
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.
|
||||
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[]
|
||||
pname:totalSamples is the value of
|
||||
|
|
|
|||
|
|
@ -868,17 +868,17 @@ attachment.
|
|||
ename:VK_ATTACHMENT_UNUSED must: have the same sample count
|
||||
ifdef::VK_AMD_mixed_attachment_samples[]
|
||||
* [[VUID-VkSubpassDescription-pColorAttachments-01506]]
|
||||
If the +VK_AMD_mixed_attachment_samples+ extension is enabled, and
|
||||
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[]
|
||||
* [[VUID-VkSubpassDescription-pDepthStencilAttachment-01418]]
|
||||
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
|
||||
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
|
||||
* [[VUID-VkSubpassDescription-None-00852]]
|
||||
If any input attachments are ename:VK_ATTACHMENT_UNUSED, then any
|
||||
|
|
@ -1693,17 +1693,17 @@ corresponding subpass.
|
|||
ename:VK_ATTACHMENT_UNUSED must: have the same sample count
|
||||
ifdef::VK_AMD_mixed_attachment_samples[]
|
||||
* [[VUID-VkSubpassDescription2KHR-pColorAttachments-03070]]
|
||||
If the +VK_AMD_mixed_attachment_samples+ extension is enabled,
|
||||
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[]
|
||||
* [[VUID-VkSubpassDescription2KHR-pDepthStencilAttachment-03071]]
|
||||
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
|
||||
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
|
||||
* [[VUID-VkSubpassDescription2KHR-None-03072]]
|
||||
If any input attachments are ename:VK_ATTACHMENT_UNUSED, then any
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ extern "C" {
|
|||
#define VK_VERSION_MINOR(version) (((uint32_t)(version) >> 12) & 0x3ff)
|
||||
#define VK_VERSION_PATCH(version) ((uint32_t)(version) & 0xfff)
|
||||
// Version of this file
|
||||
#define VK_HEADER_VERSION 89
|
||||
#define VK_HEADER_VERSION 90
|
||||
|
||||
|
||||
#define VK_NULL_HANDLE 0
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ place of the full word unless there is good reason not to.
|
|||
When a number is part of an identifier, it is treated as a word if it is a
|
||||
standalone number, such as the extension name token
|
||||
ename:VK_KHR_GET_MEMORY_REQUIREMENTS_2_EXTENSION_NAME for the
|
||||
+VK_KHR_get_memory_requirements2+ extension.
|
||||
`VK_KHR_get_memory_requirements2` extension.
|
||||
For uses where the number is part of a common abbreviation such as etext:2D
|
||||
or etext:R8B8`, the entire abbreviation is treated as a word.
|
||||
|
||||
|
|
|
|||
|
|
@ -150,7 +150,7 @@ server.
|
|||
<type category="define">// Vulkan 1.1 version number
|
||||
#define <name>VK_API_VERSION_1_1</name> <type>VK_MAKE_VERSION</type>(1, 1, 0)// Patch version should always be set to 0</type>
|
||||
<type category="define">// Version of this file
|
||||
#define <name>VK_HEADER_VERSION</name> 89</type>
|
||||
#define <name>VK_HEADER_VERSION</name> 90</type>
|
||||
|
||||
<type category="define">
|
||||
#define <name>VK_DEFINE_HANDLE</name>(object) typedef struct object##_T* object;</type>
|
||||
|
|
@ -10094,5 +10094,11 @@ server.
|
|||
<enum value=""VK_INTEL_extension_243"" name="VK_INTEL_EXTENSION_243_EXTENSION_NAME"/>
|
||||
</require>
|
||||
</extension>
|
||||
<extension name="VK_MESA_extension_244" number="244" author="MESA" contact="Andres Rodriguez @lostgoat" supported="disabled">
|
||||
<require>
|
||||
<enum value="0" name="VK_MESA_EXTENSION_244_SPEC_VERSION"/>
|
||||
<enum value=""VK_MESA_extension_244"" name="VK_MESA_EXTENSION_244_EXTENSION_NAME"/>
|
||||
</require>
|
||||
</extension>
|
||||
</extensions>
|
||||
</registry>
|
||||
|
|
|
|||
Loading…
Reference in New Issue