status-im/Vulkan-Docs
2
0
Fork 0
mirror of https://github.com/status-im/Vulkan-Docs.git synced 2025-02-22 11:08:19 +00:00
Code Issues Projects Releases Wiki Activity

Change log for September 8, 2018 Vulkan 1.1.84 spec update:

Browse Source 
* Update release number to 84.

Public Issues:

  * Fix code sample in the `<<VK_EXT_debug_utils>>` extension (public issue
    751).
  * Fix misleading comment in `vk.xml` for
    slink:VkDescriptorBufferInfo::pname:buffer (public pull request 762).
  * Fix formatting of deprecation attributes in schema doc (public pull
    request 767).
  * Change `can` to `may` in the description of
    elink:VkSparseImageFormatFlagBits, which are return values from queries
    (public pull request 768).
  * Prettify generated contact list in extension appendices, adding logos
    and a New Issue link (public pull request 770).
  * Enable sRGB conversion based on the image view format, not the image
    format, in the <<textures-format-conversion, Format Conversion>> section
    (public pull request 773).
  * Fix typo in equation in the <<primsrast-lines-basic, Basic Line Segment
    Rasterization>> section (public pull request 780).
  * Fix special characters in GitHub contacts links (public pull request
    783).
  * Make clean_pdf target remove pdf folder (public pull request 784).
  * Fix styleguide bad markup of block continuation (public pull request
    792).

Other Issues:

  * Allow a zero vertex attribute divisor in the
    `<<VK_EXT_vertex_attribute_divisor>>` extension, exposed via the
    slink:VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT feature.
  * Add missing `structextends="VkDeviceCreateInfo"` to
    slink:VkPhysicalDeviceShaderDrawParameterFeatures and
    slink:VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT.

New Extensions:

  * `VK_KHR_memory_model`
  * `VK_EXT_astc_decode_mode`
  * `VK_EXT_inline_uniform_block`
This commit is contained in:
Jon Leech 2018-09-08 15:52:13 -07:00
parent 89155faa62
commit adadfce8a3
30 changed files with 2481 additions and 82 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
ChangeLog.txt
View File

@ -8,6 +8,51 @@ public pull requests that have been accepted.
-----------------------------------------------------
Change log for September 8, 2018 Vulkan 1.1.84 spec update:
* Update release number to 84.
Public Issues:
* Fix code sample in the `<<VK_EXT_debug_utils>>` extension (public issue
751).
* Fix misleading comment in `vk.xml` for
slink:VkDescriptorBufferInfo::pname:buffer (public pull request 762).
* Fix formatting of deprecation attributes in schema doc (public pull
request 767).
* Change `can` to `may` in the description of
elink:VkSparseImageFormatFlagBits, which are return values from queries
(public pull request 768).
* Prettify generated contact list in extension appendices, adding logos
and a New Issue link (public pull request 770).
* Enable sRGB conversion based on the image view format, not the image
format, in the <<textures-format-conversion, Format Conversion>> section
(public pull request 773).
* Fix typo in equation in the <<primsrast-lines-basic, Basic Line Segment
Rasterization>> section (public pull request 780).
* Fix special characters in GitHub contacts links (public pull request
783).
* Make clean_pdf target remove pdf folder (public pull request 784).
* Fix styleguide bad markup of block continuation (public pull request
792).
Other Issues:
* Allow a zero vertex attribute divisor in the
`<<VK_EXT_vertex_attribute_divisor>>` extension, exposed via the
slink:VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT feature.
* Add missing `structextends="VkDeviceCreateInfo"` to
slink:VkPhysicalDeviceShaderDrawParameterFeatures and
slink:VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT.
New Extensions:
* `VK_KHR_memory_model`
* `VK_EXT_astc_decode_mode`
* `VK_EXT_inline_uniform_block`
-----------------------------------------------------
Change log for August 13, 2018 Vulkan 1.1.83 spec update:
* Update release number to 83.

2
Makefile
View File

@ -107,7 +107,7 @@ VERBOSE =
# EXTRAATTRIBS sets additional attributes, if passed to make
# ADOCOPTS options for asciidoc->HTML5 output
NOTEOPTS = -a editing-notes -a implementation-guide
PATCHVERSION = 83
PATCHVERSION = 84
ifneq (,$(findstring VK_VERSION_1_1,$(VERSIONS)))
SPECREVISION = 1.1.$(PATCHVERSION)
else

113
appendices/VK_EXT_astc_decode_mode.txt Normal file
View File

@ -0,0 +1,113 @@
// Copyright (c) 2018 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
include::meta/VK_EXT_astc_decode_mode.txt[]
Last Modified Date::
2018-08-07
Contributors::
- Jan-Harald Fredriksen, Arm
The existing specification requires that low dynamic range (LDR) ASTC
textures are decompressed to FP16 values per component.
In many cases, decompressing LDR textures to a lower precision intermediate
result gives acceptable image quality.
Source material for LDR textures is typically authored as 8-bit UNORM
values, so decoding to FP16 values adds little value.
On the other hand, reducing precision of the decoded result reduces the size
of the decompressed data, potentially improving texture cache performance
and saving power.
The goal of this extension is to enable this efficiency gain on existing
ASTC texture data.
This is achieved by giving the application the ability to select the
intermediate decoding precision.
Three decoding options are provided:
* Decode to elink:VK_FORMAT_R16G16B16A16_SFLOAT precision: This is the
default, and matches the required behavior in the core API.
* Decode to elink:VK_FORMAT_R8G8B8A8_UNORM precision: This is provided as
an option in LDR mode.
* Decode to elink:VK_FORMAT_E5B9G9R9_UFLOAT_PACK32 precision: This is
provided as an option in both LDR and HDR mode.
In this mode, negative values cannot be represented and are clamped to
zero.
The alpha component is ignored, and the results are as if alpha was 1.0.
This decode mode is optional and support can be queried via the physical
device properties.
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ASTC_DECODE_FEATURES_EXT
=== New Enums
None.
=== New Structures
* slink:VkImageViewASTCDecodeModeEXT
* slink:VkPhysicalDeviceASTCDecodeFeaturesEXT
=== New Functions
None.
=== Issues
1) Are implementations allowed to decode at a higher precision than what is
requested?
RESOLUTION: No.
If we allow this, then this extension could be exposed on all
implementations that support ASTC.
But developers would have no way of knowing what precision was actually
used, and thus whether the image quality is sufficient at reduced
precision.
2) Should the decode mode be image view state and/or sampler state?
RESOLUTION: Image view state only.
Some implementations treat the different decode modes as different
texture formats.
=== Example
Create an image view that decodes to VK_FORMAT_R8G8B8A8_UNORM precision:
[source,c++]
----------------------------------------
VkImageViewASTCDecodeModeEXT decodeMode =
{
VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT, // sType
NULL, // pNext
VK_FORMAT_R8G8B8A8_UNORM // decode mode
};
VkImageViewCreateInfo createInfo =
{
VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO, // sType
&decodeMode, // pNext
// flags, image, viewType set to application-desired values
VK_FORMAT_ASTC_8x8_UNORM_BLOCK, // format
// components, subresourceRange set to application-desired values
};
VkImageView imageView;
VkResult result = vkCreateImageView(
device,
&createInfo,
NULL,
&imageView);
----------------------------------------
=== Version History
* Revision 1, 2018-08-07 (Jan-Harald Fredriksen)
- Initial revision

12
appendices/VK_EXT_debug_utils.txt
View File

@ -152,7 +152,7 @@ happens and the third will log warnings to stdout.
myOutputDebugString, // pfnUserCallback
NULL // pUserData
};
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, &cb1);
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, NULL, &cb1);
if (res != VK_SUCCESS) {
// Do error handling for VK_ERROR_OUT_OF_MEMORY
}
@ -160,7 +160,7 @@ happens and the third will log warnings to stdout.
callback1.messageSeverity = VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT;
callback1.pfnCallback = myDebugBreak;
callback1.pUserData = NULL;
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, &cb2);
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, NULL, &cb2);
if (res != VK_SUCCESS) {
// Do error handling for VK_ERROR_OUT_OF_MEMORY
}
@ -175,7 +175,7 @@ happens and the third will log warnings to stdout.
mystdOutLogger, // pfnUserCallback
NULL // pUserData
};
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback3, &cb3);
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback3, NULL, &cb3);
if (res != VK_SUCCESS) {
// Do error handling for VK_ERROR_OUT_OF_MEMORY
}
@ -183,9 +183,9 @@ happens and the third will log warnings to stdout.
...
// Remove callbacks when cleaning up
pfnDestroyDebugUtilsMessengerEXT(instance, cb1);
pfnDestroyDebugUtilsMessengerEXT(instance, cb2);
pfnDestroyDebugUtilsMessengerEXT(instance, cb3);
pfnDestroyDebugUtilsMessengerEXT(instance, cb1, NULL);
pfnDestroyDebugUtilsMessengerEXT(instance, cb2, NULL);
pfnDestroyDebugUtilsMessengerEXT(instance, cb3, NULL);
------------------------------------------------------------------------------
**Example 2**

112
appendices/VK_EXT_inline_uniform_block.txt Normal file
View File

@ -0,0 +1,112 @@
include::meta/VK_EXT_inline_uniform_block.txt[]
*Last Modified Date*::
2018-08-01
*IP Status*::
No known IP claims.
*Contributors*::
- Daniel Rakos, AMD
- Jeff Bolz, NVIDIA
- Slawomir Grajewski, Intel
- Neil Henning, Codeplay
This extension introduces the ability to back uniform blocks directly with
descriptor sets by storing inline uniform data within descriptor pool
storage.
Compared to push constants this new construct allows uniform data to be
reused across multiple disjoint sets of draw or dispatch commands and may:
enable uniform data to be accessed with less indirections compared to
uniforms backed by buffer memory.
=== New Object Types
None
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_FEATURES_EXT
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_PROPERTIES_EXT
** ename:VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT
** ename:VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_INLINE_UNIFORM_BLOCK_CREATE_INFO_EXT
* Extending elink:VkDescriptorType:
** ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT
=== New Enums
None
=== New Structures
* slink:VkPhysicalDeviceInlineUniformBlockFeaturesEXT
* slink:VkPhysicalDeviceInlineUniformBlockPropertiesEXT
* slink:VkWriteDescriptorSetInlineUniformBlockEXT
* slink:VkDescriptorPoolInlineUniformBlockCreateInfoEXT
=== New Functions
None
=== New Built-In Variables
None
=== Issues
1) Do we need a new storage class for inline uniform blocks vs uniform
blocks?
*RESOLVED*: No.
The code:Uniform storage class is used to allow the same syntax used for
both uniform buffers and inline uniform blocks.
2) Is the descriptor array index and array size expressed in terms of bytes
or dwords for inline uniform block descriptors?
*RESOLVED*: In bytes, but both must: be a multiple of 4, similar to how push
constant ranges are specified.
The pname:descriptorCount of sname:VkDescriptorSetLayoutBinding thus
provides the total number of bytes a particular binding with an inline
uniform block descriptor type can hold, while the pname:srcArrayElement,
pname:dstArrayElement, and pname:descriptorCount members of
sname:VkWriteDescriptorSet, sname:VkCopyDescriptorSet, and
sname:VkDescriptorUpdateTemplateEntry (where applicable) specify the byte
offset and number of bytes to write/copy to the binding's backing store.
Additionally, the pname:stride member of
sname:VkDescriptorUpdateTemplateEntry is ignored for inline uniform blocks
and a default value of one is used, meaning that the data to update inline
uniform block bindings with must be contiguous in memory.
3) What layout rules apply for uniform blocks corresponding to inline
constants?
*RESOLVED*: They use the same layout rules as uniform buffers.
4) Do we need to add non-uniform indexing features/properties as introduced
by `VK_EXT_descriptor_indexing` for inline uniform blocks?
*RESOLVED*: No, because inline uniform blocks are not allowed to be
"arrayed".
A single binding with an inline uniform block descriptor type corresponds to
a single uniform block instance and the array indices inside that binding
refer to individual offsets within the uniform block (see issue #2).
However, this extension does introduce new features/properties about the
level of support for update-after-bind inline uniform blocks.
5) Is the pname:descriptorBindingVariableDescriptorCount feature introduced
by `VK_EXT_descriptor_indexing` supported for inline uniform blocks?
*RESOLVED*: Yes, as long as other inline uniform block specific limits are
respected.
6) Do the robustness guarantees of pname:robustBufferAccess apply to inline
uniform block accesses?
*RESOLVED*: No, similarly to push constants, as they are not backed by
buffer memory like uniform buffers.
=== Version History
* Revision 1, 2018-08-01 (Daniel Rakos)
- Internal revisions

12
appendices/VK_EXT_vertex_attribute_divisor.txt
View File

@ -1,7 +1,7 @@
include::meta/VK_EXT_vertex_attribute_divisor.txt[]
*Last Modified Date*::
2018-07-16
2018-08-03
*IP Status*::
No known IP claims.
*Contributors*::
@ -33,6 +33,8 @@ None.
** slink:VkPipelineVertexInputDivisorStateCreateInfoEXT
* slink:VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT
* slink:VkVertexInputBindingDivisorDescriptionEXT
* Extending slink:VkPhysicalDeviceFeatures2:
** slink:VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT
=== New Functions
@ -48,9 +50,8 @@ offsets.
2) Should zero be an allowed divisor?
*RESOLVED*: No.
The zero case in OpenGL is handled in Vulkan by setting the pname:inputRate
on the binding to ename:VK_VERTEX_INPUT_RATE_VERTEX.
*RESOLVED*: Yes.
A zero divisor means the vertex attribute is repeated for all instances.
=== Examples
@ -101,3 +102,6 @@ application could use the following set of structures:
- Adjust the interaction between fname:divisor and pname:firstInstance
to match the OpenGL convention.
- Disallow divisors of zero.
* Revision 3, 2018-08-03 (Vikram Kushwaha)
- Allow a zero divisor.
- Add a physical device features structure to query/enable this feature.

45
appendices/VK_KHR_vulkan_memory_model.txt Normal file
View File

@ -0,0 +1,45 @@
// Copyright (c) 2017-2018 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
include::meta/VK_KHR_vulkan_memory_model.txt[]
*Last Modified Date*::
2018-02-05
*IP Status*::
No known IP claims.
*Interactions and External Dependencies*::
- This extension requires
https://www.khronos.org/registry/spir-v/extensions/KHR/SPV_KHR_vulkan_memory_model.html[+SPV_KHR_vulkan_memory_model+]
*Contributors*::
- Jeff Bolz, NVIDIA
- Alan Baker, Google
- Tobias Hector, AMD
- David Neto, Google
- Robert Simpson, Qualcomm Technologies, Inc.
- Brian Sumner, AMD
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.
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR
=== New Structures
* slink:VkPhysicalDeviceVulkanMemoryModelFeaturesKHR
=== New SPIR-V Capabilities
* <<spirvenv-capabilities-table-memorymodel,code:VulkanMemoryModelKHR>>
=== Issues
=== Version History
* Revision 1, 2018-06-24 (Jeff Bolz)
- Initial draft

258
appendices/compressedtex.txt
View File

@ -117,3 +117,261 @@ chapter of the <<data-format,Khronos Data Format Specification>>.
| ename:VK_FORMAT_ASTC_12x12_UNORM_BLOCK ^|[eq]#12 {times} 12# ^|No
| ename:VK_FORMAT_ASTC_12x12_SRGB_BLOCK ^|[eq]#12 {times} 12# ^|Yes
|====
ifdef::VK_EXT_astc_decode_mode[]
=== ASTC decode mode
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.
.Mapping of Vulkan ASTC decoding format to ASTC decoding modes
[width="75%",options="header",cols="75%,25%"]
|====
| VkFormat ^| Decoding mode
| ename:VK_FORMAT_R16G16B16A16_SFLOAT ^| decode_float16
| ename:VK_FORMAT_R8G8B8A8_UNORM ^| decode_unorm8
| ename:VK_FORMAT_E5B9G9R9_UFLOAT_PACK32 ^| decode_rgb9e5
|====
==== LDR and HDR Modes
[NOTE]
.Note
====
This replaces section 16.5 in the <<data-format,Khronos Data Format
Specification>>.
====
The decoding process for LDR content can be simplified if it is known in
advance that sRGB output is required.
This selection is therefore included as part of the global configuration.
The two modes differ in various ways, as shown in
<<appendix-compressedtex-astc-differences-between-ldr-and-hdr-modes, ASTC
differences between LDR and HDR modes>>.
[[appendix-compressedtex-astc-differences-between-ldr-and-hdr-modes]]
.ASTC differences between LDR and HDR modes
[width="75%",options="header"]
|====
| Operation | LDR Mode | HDR Mode
| Returned Value | Determined by decoding mode | Determined by decoding mode
| sRGB compatible | Yes | No
| LDR endpoint decoding precision | 16 bits, or 8 bits for sRGB | 16 bits
| HDR endpoint mode results | Error color | As decoded
| Error results | Error color | Vector of NaNs (0xFFFF)
|====
The type of the values returned by the decoding process is determined by the
decoding mode as shown in <<appendix-compressedtex-astc-decoding-modes, ASTC
decoding modes>>.
[[appendix-compressedtex-astc-decoding-modes]]
.ASTC decoding modes
[width="75%",options="header"]
|====
| Decode mode | LDR Mode | HDR Mode
| decode_float16 | Vector of FP16 values | Vector of FP16 values
| decode_unorm8 | Vector of 8-bit unsigned normalized values | invalid
| decode_rgb9e5 | Vector using a shared exponent format | Vector using a shared exponent format
|====
Using the decode_unorm8 decoding mode in HDR mode gives undefined results.
For sRGB, the decoding mode is ignored, and the decoding always returns a
vector of 8-bit unsigned normalized values.
The error color is opaque fully-saturated magenta [eq]#[(R,G,B,A) =
(0xFF,0x00,0xFF,0xFF)#.
This has been chosen as it is much more noticeable than black or white, and
occurs far less often in valid images.
For linear RGB decode, the error color may: be either opaque fully-saturated
magenta [eq]#(R,G,B,A) = (1.0,0.0,1.0,1.0)# or a vector of four NaNs
[eq]#(R,G,B,A) = (NaN,NaN,NaN,NaN)#.
In the latter case, the recommended [eq]#NaN# value returned is
[eq]#0xFFFF#.
When using the decode_rgb9e5 decoding mode in HDR mode, error results will
return the error color because NaN cannot be represented.
The error color is returned as an informative response to invalid
conditions, including invalid block encodings or use of reserved endpoint
modes.
Future, forward-compatible extensions to ASTC may define valid
interpretations of these conditions, which will decode to some other color.
Therefore, encoders and applications must not rely on invalid encodings as a
way of generating the error color.
[[appendix-compressedtex-astc-weight-application]]
[NOTE]
.Note
====
This replaces section 16.19 in the <<data-format,Khronos Data Format
Specification>>.
====
Once the effective weight _i_ for the texel has been calculated, the color
endpoints are interpolated and expanded.
For LDR endpoint modes, each color component C is calculated from the
corresponding 8-bit endpoint components C~0~ and C~1~ as follows:
If sRGB conversion is not enabled, or for the alpha channel in any case,
C~0~ and C~1~ are first expanded to 16 bits by bit replication:
-----
C0 = (C0 << 8) | C0; C1 = (C1 << 8) | C1;
-----
If sRGB conversion is enabled, C~0~ and C~1~ for the R, G, and B channels
are expanded to 16 bits differently, as follows:
-----
C0 = (C0 << 8) | 0x80; C1 = (C1 << 8) | 0x80;
-----
C~0~ and C~1~ are then interpolated to produce a UNORM16 result C:
-----
C = floor( (C0*(64-i) + C1*i + 32)/64 )
-----
If sRGB conversion is not enabled and the decoding mode is decode_float16,
then if C = 65535 the final result is 1.0 (0x3C00); otherwise C is divided
by 65536 and the infinite-precision result of the division is converted to
FP16 with round-to-zero semantics.
If sRGB conversion is not enabled and the decoding mode is decode_unorm8,
then top 8 bits of the interpolation result for the R, G, B, and A channels
are used as the final result.
If sRGB conversion is not enabled and the decoding mode is decode_rgb9e5,
then the final result is a combination of the (UNORM16) values of C for the
three color components (Cr, Cg, and Cb) computed as follows:
-----
int lz = clz17( Cr | Cg | Cb | 1);
if (Cr == 65535 ) { Cr = 65536; lz = 0; }
if (Cg == 65535 ) { Cg = 65536; lz = 0; }
if (Cb == 65535 ) { Cb = 65536; lz = 0; }
Cr <<= lz;
Cg <<= lz;
Cb <<= lz;
Cr = (Cr >> 8) & 0x1FF;
Cg = (Cg >> 8) & 0x1FF;
Cb = (Cb >> 8) & 0x1FF;
uint32_t exponent = 16 - lz;
uint32_t texel = (exponent << 27) | (Cb << 18) | (Cg << 9) | Cr;
-----
The clz17() function counts leading zeros in a 17-bit value.
If sRGB conversion is enabled, then the decoding mode is ignored, and the
top 8 bits of the interpolation result for the R, G and B channels are
passed to the external sRGB conversion block and used as the final result.
The A channle uses the decode_float16 decoding mode.
For HDR endpoint modes, color values are represented in a 12-bit
pseudo-logarithmic representation, and interpolation occurs in a
piecewise-approximate logarithmic manner as follows:
In LDR mode, the error result is returned.
In HDR mode, the color components from each endpoint, C~0~ and C~1~, are
initially shifted left 4 bits to become 16-bit integer values and these are
interpolated in the same way as LDR.
The 16-bit value C is then decomposed into the top five bits, E, and the
bottom 11 bits M, which are then processed and recombined with E to form the
final value C~f~:
-----
C = floor( (C0*(64-i) + C1*i + 32)/64 )
E = (C & 0xF800) >> 11; M = C & 0x7FF;
if (M < 512) { Mt = 3*M; }
else if (M >= 1536) { Mt = 5*M - 2048; }
else { Mt = 4*M - 512; }
Cf = (E<<10) + (Mt>>3)
-----
This interpolation is a considerably closer approximation to a logarithmic
space than simple 16-bit interpolation.
This final value C~f~ is interpreted as an IEEE FP16 value.
If the result is +Inf or NaN, it is converted to the bit pattern 0x7BFF,
which is the largest representable finite value.
If the decoding mode is decode_rgb9e5, then the final result is a
combination of the (IEEE FP16) values of Cf for the three color components
(Cr, Cg, and Cb) computed as follows:
-----
if( Cr > 0x7c00 ) Cr = 0; else if( Cr == 0x7c00 ) Cr = 0x7bff;
if( Cg > 0x7c00 ) Cg = 0; else if( Cg == 0x7c00 ) Cg = 0x7bff;
if( Cb > 0x7c00 ) Cb = 0; else if( Cb == 0x7c00 ) Cb = 0x7bff;
int Re = (Cr >> 10) & 0x1F;
int Ge = (Cg >> 10) & 0x1F;
int Be = (Cb >> 10) & 0x1F;
int Rex = Re == 0 ? 1 : Re;
int Gex = Ge == 0 ? 1 : Ge;
int Bex = Be == 0 ? 1 : Be;
int Xm = ((Cr | Cg | Cb) & 0x200) >> 9;
int Xe = Re | Ge | Be;
uint32_t rshift, gshift, bshift, expo;
if (Xe == 0)
{
expo = rshift = gshift = bshift = Xm;
}
else if (Re >= Ge && Re >= Be)
{
expo = Rex + 1;
rshift = 2;
gshift = Rex - Gex + 2;
bshift = Rex - Bex + 2;
}
else if (Ge >= Be)
{
expo = Gex + 1;
rshift = Gex - Rex + 2;
gshift = 2;
bshift = Gex - Bex + 2;
}
else
{
expo = Bex + 1;
rshift = Bex - Rex + 2;
gshift = Bex - Gex + 2;
bshift = 2;
}
int Rm = (Cr & 0x3FF) | (Re == 0 ? 0 : 0x400);
int Gm = (Cg & 0x3FF) | (Ge == 0 ? 0 : 0x400);
int Bm = (Cb & 0x3FF) | (Be == 0 ? 0 : 0x400);
Rm = (Rm >> rshift) & 0x1FF;
Gm = (Gm >> gshift) & 0x1FF;
Bm = (Bm >> bshift) & 0x1FF;
uint32_t texel = (expo << 27) | (Bm << 18) | (Gm << 9) | (Rm << 0);
-----
=== Void-Extent Blocks
[NOTE]
.Note
====
This modifies section 16.23 in the <<data-format,Khronos Data Format
Specification>>.
====
In the HDR case, if the decoding mode is decode_rgb9e5, then any negative
color component values are set to 0 before conversion to the shared exponent
format (as described in <<appendix-compressedtex-astc-weight-application,
Weight Application>>).

1
appendices/extensions.txt
View File

@ -59,4 +59,5 @@ interface stability than a non-`X` extension from the same vendor.
====
include::meta/current_extensions_appendix.txt[]
include::meta/provisional_extensions_appendix.txt[]
include::meta/deprecated_extensions_appendix.txt[]

27
appendices/glossary.txt
View File

@ -660,6 +660,12 @@ Initial State (Command Buffer)::
A command buffer that has not begun recording commands.
See also Recorded State and Executable State.
ifdef::VK_EXT_inline_uniform_block[]
Inline Uniform Block::
A descriptor type that represents uniform data stored directly in
descriptor sets, and supports read-only access in a shader.
endif::VK_EXT_inline_uniform_block[]
Input Attachment::
A descriptor type that represents an image view, and supports unfiltered
read-only access in a shader, only at the fragment's location in the
@ -750,6 +756,20 @@ Memory Dependency::
* The availability operation happens-before the visibility operation
* The visibility operation happens-before the second set of operations
Memory Domain::
A memory domain is an abstract place to which memory writes are made
available by availability operations and memory domain operations.
The memory domains correspond to the set of agents that the write can:
then be made visible to.
The memory domains are _host_, _device_, _shader_, _workgroup instance_
(for workgroup instance there is a unique domain for each compute
workgroup) and _subgroup instance_ (for subgroup instance there is a
unique domain for each subgroup).
Memory Domain Operation::
An operation that makes the writes that are available to one memory
domain available to another memory domain.
Memory Heap::
A region of memory from which device memory allocations can: be made.
@ -972,6 +992,13 @@ Protected Image::
An image to which protected device memory can: be bound.
endif::VK_VERSION_1_1[]
Provisional::
A feature is released provisionally in order to get wider feedback on
the functionality before it is finalized.
Provisional features may change in ways that break backwards
compatibility, and thus are not recommended for use in production
applications.
Provoking Vertex::
The vertex in a primitive from which flat shaded attribute values are
taken.

848
appendices/memorymodel.txt Normal file
View File

@ -0,0 +1,848 @@
[[memory-model]]
= Memory Model
[[memory-model-agent]]
== Agent
_Operation_ is a general term for any task that is executed on the system.
NOTE: An operation is by definition something that is executed, thus if an
instruction is skipped due to flow control it does not constitute an
operation.
Each operation is executed by a particular _agent_.
Possible agents include each shader invocation, each host thread, and each
fixed-function stage of the pipeline.
[[memory-model-memory-location]]
== Memory Location
A _memory location_ identifies unique storage for 8 bits of data.
Memory operations access a _set of memory locations_ consisting of one or
more memory locations at a time, e.g. an operation accessing a 32-bit
integer in memory would read/write a set of four memory locations.
Two sets of memory locations _overlap_ if the intersection of their sets of
memory locations is non-empty.
A memory operation must: not affect memory at a memory location not within
its set of memory locations.
Memory locations for buffers and images are explicitly allocated in
VkDeviceMemory objects, and are implicitly allocated for SPIR-V variables in
each shader invocation.
[[memory-model-allocation]]
== Allocation
The values stored in newly allocated memory locations are determined by a
SPIR-V variable's initializer, if present, or else are undefined.
At the time an allocation is created there have been no
<<memory-model-memory-operation,memory operations>> to any of its memory
locations.
The initialization is not considered to be a memory operation.
NOTE: For tessellation control shader output variables, a consequence of
initialization not being considered a memory operation is that some
implementations may need to insert a barrier between the initialization of
the output variables and any reads of those variables.
[[memory-model-memory-operation]]
== Memory Operation
For an operation A and memory location M:
* [[memory-model-access-read]] A _reads_ M if and only if the data stored
in M is an input to A.
* [[memory-model-access-write]] A _writes_ M if and only if the data
output from A is stored to M.
* [[memory-model-access-access]] A _accesses_ M if and only if it either
reads or writes (or both) M.
NOTE: A write whose value is the same as what was already in those memory
locations is still considered to be a write and has all the same effects.
[[memory-model-references]]
== Reference
A _reference_ is an object that a particular agent can: use to access a set
of memory locations.
On the host, a reference is a host virtual address.
On the device, a reference is:
* The descriptor that a variable is bound to, for variables in Image,
Uniform, or StorageBuffer storage classes.
If the variable is an array (or array of arrays, etc.) then each element
of the array may: be a unique reference.
* The variable itself for variables in other storage classes.
Two memory accesses through distinct references may: require availability
and visibility operations as defined
<<memory-model-location-ordered,below>>.
[[memory-model-program-order]]
== Program-Order
A _dynamic instance_ of an instruction is defined in SPIR-V
(https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#DynamicInstance)
as a way of referring to a particular execution of a static instruction.
Program-order is an ordering on dynamic instances of instructions executed
by a single shader invocation:
* (Basic block): If instructions A and B are in the same basic block, and
A is listed in the module before B, then the n'th dynamic instance of A
is program-ordered before the n'th dynamic instance of B.
* (Branch): The dynamic instance of a branch or switch instruction is
program-ordered before the dynamic instance of the OpLabel instruction
to which it transfers control.
* (Call entry): The dynamic instance of a function call instruction is
program-ordered before the dynamic instances of the
code:OpFunctionParameter instructions and the body of the called
function.
* (Call exit): The dynamic instance of the instruction following a
function call instruction is program-ordered after the dynamic instance
of the return instruction executed by the called function.
* (Transitive Closure): If dynamic instance A of any instruction is
program-ordered before dynamic instance B of any instruction and B is
program-ordered before dynamic instance C of any instruction then A is
program-ordered before C.
* (Complete definition): No other dynamic instances are program-ordered.
For instructions executed on the host, the source language defines the
program-order relation (e.g. as "sequenced-before").
[[memory-model-scope]]
== Scope
A _scope_ describes a set of shader invocations, where each such set is a
_scope instance_.
Scopes are defined hierarchically such that a more inclusive scope includes
one or more sets of less inclusive scope instances.
The scopes defined by SPIR-V are as follows, defined from most inclusive to
least inclusive:
* code:CrossDevice identifies all shader invocations in a Vulkan instance
across all shader launches, and all host threads interacting with that
instance.
* code:Device identifes all shader invocations that execute on a given
device, including those from different shader launches.
* code:QueueFamilyKHR identifes all shader invocations that execute on any
queue in a given queue family, including those from different shader
launches.
* code:Workgroup identifies all invocations in a single workgroup.
* code:Subgroup identifies all invocations in a single subgroup.
* code:Invocation identifies a single invocation.
Atomic and barrier instructions include scopes which identify sets of shader
invocations that must: obey the requested ordering and atomicity rules of
the operation, as defined below.
[[memory-model-atomic-operation]]
== Atomic Operation
An _atomic operation_ on the device is any SPIR-V operation whose name
begins with code:OpAtomic.
An atomic operation on the host is any operation performed with an
std::atomic typed object.
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.
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
relaxed, acquire, release, acq_rel, or seq_cst.
Two atomic operations A and B are _potentially-mutually-ordered_ if and only
if all of the following are true:
* They access the same set of memory locations.
* They use the same reference.
* A is in the instance of B's memory scope.
* B is in the instance of A's memory scope.
Two atomic operations A and B are _mutually-ordered_ if and only if they are
potentially-mutually-ordered and any of the following are true:
* A and B are both device operations.
* A and B are both host operations.
* 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.
[[memory-model-scoped-modification-order]]
== Scoped Modification Order
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_.
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
that disagrees with the scoped modification order.
NOTE: It is valid to have non-atomic operations or atomics in a different
scope instance to the same set of memory locations, as long as they are
synchronized against each other as if they were non-atomic (if they are not,
it is treated as a <<memory-model-access-data-race,data race>>).
That means this definition of A's scoped modification order could include
atomic operations that occur much later, after intervening non-atomics.
That is a bit non-intuitive, but it helps to keep this definition simple and
non-circular.
[[memory-model-memory-semantics]]
== Memory Semantics
Non-atomic memory operations, by default, may: be observed by one agent in a
different order than they were written by another agent.
Atomics and some synchronization operations include _memory semantics_,
which are flags that constrain the order in which other memory accesses
(including non-atomic memory accesses and
<<memory-model-availability-visibility,availability and visibility
operations>>) performed by the same agent can: be observed by other agents,
or can: observe accesses by other agents.
Device instructions that include semantics are code:OpAtomic*,
code:OpControlBarrier, code:OpMemoryBarrier, and code:OpMemoryNamedBarrier.
Host instructions that include semantics are some std::atomic methods and
memory fences.
SPIR-V supports the following memory semantics:
* Relaxed: No constraints on order of other memory accesses.
* Acquire: A memory read with this semantic performs an _acquire
operation_.
A memory barrier with this semantic is an _acquire barrier_.
* Release: A memory write with this semantic performs a _release
operation_.
A memory barrier with this semantic is a _release barrier_.
* AcquireRelease: A memory read-modify-write operation with this semantic
performs both an acquire operation and a release operation, and inherits
the limitations on ordering from both of those operations.
A memory barrier with this semantic is both a release and acquire
barrier.
NOTE: SPIR-V does not support "consume" semantics on the device.
The memory semantics operand also includes _storage class semantics_ which
indicate which storage classes are constrained by the synchronization.
SPIR-V storage class semantics include:
* UniformMemory
* WorkgroupMemory
* ImageMemory
* OutputMemoryKHR
Each SPIR-V memory operation accesses a single storage class.
Semantics in synchronization operations can include a combination of storage
classes.
The UniformMemory storage class semantic applies to accesses to memory in
the Uniform and StorageBuffer storage classes.
The WorkgroupMemory storage class semantic applies to accesses to memory in
the Workgroup storage class.
The ImageMemory storage class semantic applies to accesses to memory in the
Image storage class.
The OutputMemoryKHR storage class semantic applies to accesses to memory in
the Output storage class.
NOTE: Informally, these constraints limit how memory operations can be
reordered, and these limits apply not only to the order of accesses as
performed in the agent that executes the instruction, but also to the order
the effects of writes become visible to all other agents within the same
instance of the instruction's memory scope.
NOTE: Release and acquire operations in different threads can: act as
synchronization operations, to guarantee that writes that happened before
the release are visible after the acquire.
(This is not a formal definition, just an informative forward reference.)
NOTE: The OutputMemoryKHR storage class semantic is only useful in
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
described in <<memory-model-availability-visibility,availability and
visibility>>.
The availability/visibility flags are:
* MakeAvailable: Semantics must: be Release or AcquireRelease.
Performs an availability operation before the release operation or
barrier.
* MakeVisible: Semantics must: be Acquire or AcquireRelease.
Performs a visibility operation after the acquire operation or barrier.
The specifics of these operations are defined in
<<memory-model-availability-visibility-semantics,Availability and Visibility
Semantics>>.
Host atomic operations may: support a different list of memory semantics and
synchronization operations, depending on the host architecture and source
language.
[[memory-model-release-sequence]]
== Release Sequence
After an atomic operation A performs a release operation on a set of memory
locations M, the _release sequence headed by A_ is the longest continuous
subsequence of A's scoped modification order that consists of:
* the atomic operation A as its first element
* atomic read-modify-write operations on M by any agent
NOTE: The atomics in the last bullet must: be mutually-ordered with A by
virtue of being in A's scoped modification order.
NOTE: This intentionally omits "atomic writes to M performed by the same
agent that performed A", which is present in the corresponding C++
definition.
[[memory-model-synchronizes-with]]
== Synchronizes-With
_Synchronizes-with_ is a relation between atomic operations and/or memory
barriers (aka fences 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:
* 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
code:OpControlBarrier, code:OpMemoryBarrier, and code:OpMemoryNamedBarrier
are _memory barrier_ instructions in SPIR-V.
If A is a release barrier and B is an atomic operation that performs an
acquire operation, then A synchronizes-with B if and only if all of the
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)
* A and B are in the instance of each other's memory scopes
* X's storage class is in A's semantics.
If A is an atomic operation that performs a release operation and B is an
acquire barrier, then A synchronizes-with B if and only if all of the
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)
* A and B are in the instance of each other's memory scopes
* X's storage class is in B's semantics.
If A is a release barrier and B is an acquire barrier, then A
synchronizes-with B if all of the following are true:
* there exists an atomic write X (with any memory semantics)
* A is program-ordered before X
* 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)
* 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),
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
* A and B are in the instance of each other's memory scopes
* A and B are in the instance of C's execution scope
NOTE: This is similar to the barrier-barrier synchronization above, but with
a control barrier filling the role of the relaxed atomics.
No other release and acquire barriers synchronize-with each other.
[[memory-model-system-synchronizes-with]]
== System-Synchronizes-With
_System-synchronizes-with_ is a relation between arbitrary operations on the
device or host.
Certain operations system-synchronize-with each other, which informally
means the first operation occurs before the second and that the
synchronization is performed without using application-visible memory
accesses.
If there is an <<synchronization-dependencies-execution,execution
dependency>> between two operations A and B, then the operation in the first
synchronization scope system-synchronizes-with the operation in the second
synchronization scope.
NOTE: This covers all Vulkan synchronization primitives, including device
operations executing before a synchronization primitive is signaled, wait
operations happening before subsequent device operations, signal operations
happening before host operations that wait on them, and host operations
happening before vkQueueSubmit.
The list is spread throughout the synchronization chapter, and is not
repeated here.
System-synchronizes-with implicitly includes all storage class semantics and
has code:CrossDevice scope.
If A system-synchronizes-with B, we also say A is
_system-synchronized-before_ B and B is _system-synchronized-after_ A.
[[memory-model-non-private]]
== Private vs. Non-Private
By default, non-atomic memory operations are treated as _private_, meaning
such a memory operation is not intended to be used for communication with
other agents.
Memory operations with the NonPrivatePointerKHR/NonPrivateTexelKHR bit set
are treated as _non-private_, and are intended to be used for communication
with other agents.
More precisely, for private memory operations to be
<<memory-model-location-ordered,Location-Ordered>> between distinct agents
requires using system-synchronizes-with rather than shader-based
synchronization.
Non-private memory operations still obey program-order.
Atomic operations are always considered non-private.
[[memory-model-inter-thread-happens-before]]
== Inter-Thread-Happens-Before
Let SC be a non-empty set of storage class semantics.
Then (using template syntax) operation A _inter-thread-happens-before_<SC>
operation B if and only if any of the following is true:
* A system-synchronizes-with B
* A synchronizes-with B, and both A and B have all of SC in their
semantics
* A is an operation on memory in a storage class in SC or that has all of
SC in its semantics, B is a release barrier or release atomic with all
of SC in its semantics, and A is program-ordered before B
* A is an acquire barrier or acquire atomic with all of SC in its
semantics, B is an operation on memory in a storage class in SC or that
has all of SC in its semantics, and A is program-ordered before B
* A and B are both host operations and A inter-thread-happens-before B as
defined in the host language spec
* A inter-thread-happens-before<SC> some X and X
inter-thread-happens-before<SC> B
[[memory-model-happens-before]]
== Happens-Before
Operation A _happens-before_ operation B if and only if any of the following
is true:
* A is program-ordered before B
* A inter-thread-happens-before<SC> B for some set of storage classes SC
_Happens-after_ is defined similarly.
NOTE: Unlike C++, happens-before is not always sufficient for a write to be
visible to a read.
Additional <<memory-model-availability-visibility,availability and
visibility>> operations may: be required for writes to be
<<memory-model-visible-to,visible-to>> other memory accesses.
NOTE: Happens-before is not transitive, but each of program-order and
inter-thread-happens-before<SC> are transitive.
These can be thought of as covering the "single-threaded" case and the
"multi-threaded" case, and it's not necessary (and not valid) to form chains
between the two.
[[memory-model-availability-visibility]]
== Availability and Visibility
_Availability_ and _visibility_ are states of a write operation, which
(informally) track how far the write has permeated the system, i.e. which
agents and references are able to observe the write.
Availability state is per _memory domain_.
Visibility state is per (agent,reference) pair.
Availability and visibility states are per-memory location for each write.
Memory domains are named according to the agents whose memory accesses use
the domain.
Domains used by shader invocations are organized hierarchically into
multiple smaller memory domains which correspond to the different
<<memory-model-scope, scopes>>.
The memory domains defined in Vulkan include:
* _host_ - accessible by host agents
* _device_ - accessible by all device agents for a particular device
* _shader_ - accessible by shader agents for a particular device,
corresponding to the code:Device scope
* _queue family instance_ - accessible by shader agents in a single queue
family, corresponding to the code:QueueFamilyKHR scope.
* _workgroup instance_ - accessible by shader agents in the same
workgroup, corresponding to the code:Workgroup scope.
* _subgroup instance_ - accessible by shader agents in the same subgroup,
corresponding to the code:Subgroup scope.
NOTE: These do not correspond to storage classes or device-local and
host-local VkDeviceMemory allocations, rather they indicate whether a write
can be made visible only to agents in the same subgroup, same workgroup, in
any shader invocation, or anywhere on the device, or host.
The shader, queue family instance, workgroup instance, and subgroup instance
domains are only used for shader-based availability/visibility operatons, in
other cases writes can be made available from/visible to the shader via the
device domain.
_Availability operations_, _visibility operations_, and _memory domain
operations_ alter the state of the write operations that happen-before them,
and which are included in their _source scope_ to be available or visible to
their _destination scope_.
* For an availability operation, the source scope is a set of
(agent,reference,memory location) tuples, and the destination scope is a
set of memory domains.
* For a memory domain operation, the source scope is a memory domain and
the destination scope is a memory domain.
* For a visibility operation, the source scope is a set of memory domains
and the destination scope is a set of (agent,reference,memory location)
tuples.
How the scopes are determined depends on the specific operation.
Availability and memory domain operations expand the set of memory domains
to which the write is available.
Visibility operations expand the set of (agent,reference,memory location)
tuples to which the write is visible.
Recall that availability and visibility states are per-memory location, and
let W be a write operation to one or more locations performed by agent A via
reference R. Let L be one of the locations written.
(W,L) (the write W to L), is initially not available to any memory domain
and only visible to (A,R,L).
An availability operation AV that happens-after W and that includes (A,R,L)
in its source scope makes (W,L) _available_ to the memory domains in its
destination scope.
A memory domain operation DOM that happens-after AV and for which (W,L) is
available in the source scope makes (W,L) available in the destination
memory domain.
A visibility operation VIS that happens-after AV (or DOM) and for which
(W,L) is available in any domain in the source scope makes (W,L) _visible_
to all (agent,reference,L) tuples included in its destination scope.
If write W~2~ happens-after W, and their sets of memory locations overlap,
then W will not be available/visible to all agents/references for those
memory locations that overlap (and future AV/DOM/VIS ops can't revive W's
write to those locations).
Availability, memory domain, and visibility operations are treated like
other non-atomic memory accesses for the purpose of
<<memory-model-memory-semantics,memory semantics>>, meaning they can be
ordered by release-acquire sequences or memory barriers.
[[memory-model-vulkan-availability-visibility]]
== Availability, Visibility, and Domain Operations
The following operations generate availability, visibility, and domain
operations.
When multiple availability/visibility/domain operations are described, they
are system-synchronized-with each other in the order listed.
An operation that performs a <<synchronization-dependencies-memory,memory
dependency>> generates:
* If the source access mask includes ename:VK_ACCESS_HOST_WRITE_BIT, then
the dependency includes a memory domain operation from host domain to
device domain.
* An availability operation with source scope of all writes in the first
<<synchronization-dependencies-access-scopes,access scope>> of the
dependency and a destination scope of the device domain.
* A visibility operation with source scope of the device domain and
destination scope of the second access scope of the dependency.
* If the destination access mask includes ename:VK_ACCESS_HOST_READ_BIT or
ename:VK_ACCESS_HOST_WRITE_BIT, then the dependency includes a memory
domain operation from device domain to host domain.
flink:vkFlushMappedMemoryRanges performs an availability operation, with a
source scope of (agents,references) = (all host threads, all mapped memory
ranges passed to the command), and destination scope of the host domain.
flink:vkInvalidateMappedMemoryRanges performs a visibility operation, with a
source scope of the host domain and a destination scope of
(agents,references) = (all host threads, all mapped memory ranges passed to
the command).
flink:vkQueueSubmit performs a memory domain operation from host to device,
and a visibility operation with source scope of the device domain and
destination scope of all agents and references on the device.
[[memory-model-availability-visibility-semantics]]
== Availability and Visibility Semantics
A memory barrier or atomic operation via agent A that includes MakeAvailable
in its semantics performs an availability operation whose source scope
includes agent A and all references in the storage classes in that
instruction's storage class semantics, and all memory locations, and whose
destination scope is a set of memory domains selected as specified below.
The implicit availability operation is program-ordered between the barrier
or atomic and all other operations program-ordered before the write.
A memory barrier or atomic operation via agent A that includes MakeVisible
in its semantics performs a visibility operation whose source scope is a set
of memory domains selected as specified below, and whose destination scope
includes agent A and all references in the storage classes in that
instruction's storage class semantics, and all memory locations.
The implicit visibility operation is program-ordered between the barrier or
atomic and all other operations program-ordered after the write.
The memory domains are selected based on the memory scope of the instruction
as follows:
* code:Device scope uses the shader domain
* code:QueueFamilyKHR scope uses the queue family instance domain
* code:Workgroup scope uses the workgroup instance domain
* code:Subgroup uses the subgroup instance domain
* code:Invocation perform no availability/visibility operations.
When an availability operation performed by an agent A includes a memory
domain D in its destination scope, where D corresponds to scope instance S,
it also includes the memory domains that correspond to each smaller scope
instance S' that is a subset of S and that includes A. Similarly for
visibility operations.
[[memory-model-instruction-av-vis]]
== Per-Instruction Availability and Visibility Semantics
A memory write instruction that includes MakePointerAvailable, or an image
write instruction that includes MakeTexelAvailable, performs an availability
operation whose source scope includes the agent and reference used to
perform the write and the memory locations written by the instruction, and
whose destination scope is a set of memory domains selected by the Scope
operand specified in <<memory-model-availability-visibility-semantics,
Availability and Visibility Semantics>>.
The implicit availability operation is program-ordered between the write and
all other operations program-ordered after the write.
A memory read instruction that includes MakePointerVisible, or an image read
instruction that includes MakeTexelVisible, performs a visibility operation
whose source scope is a set of memory domains selected by the Scope operand
as specified in <<memory-model-availability-visibility-semantics,
Availability and Visibility Semantics>>, and whose destination scope
includes the agent and reference used to perform the read and the memory
locations read by the instruction.
The implicit visibility operation is program-ordered between read and all
other operations program-ordered before the read.
NOTE: Although reads with per-instruction visibility only perform visibility
ops from the shader or workgroup instance or subgroup instance domain, they
will also see writes that were made visible via the device domain, i.e.
those writes previously performed by non-shader agents and made visible via
API commands.
NOTE: It is expected that all invocations in a subgroup execute on the same
processor with the same path to memory, and thus availability and visibility
operations with subgroup scope can be expected to be "free".
[[memory-model-location-ordered]]
== Location-Ordered
Let X and Y be memory accesses to overlapping sets of memory locations M,
where X != Y. Let (A~X~,R~X~) be the agent and reference used for X, and
(A~Y~,R~Y~) be the agent and reference used for Y. For now, let "->" denote
happens-before and "->^rcpo^" denote the reflexive closure of
program-ordered before.
If D~1~ and D~2~ are different memory domains, then let DOM(D~1~,D~2~) be a
memory domain operation from D~1~ to D~2~.
Otherwise, let DOM(D,D) be a placeholder such that X->DOM(D,D)->Y if and
only if X->Y.
X is _location-ordered_ before Y for a location L in M if and only if any of
the following is true:
* A~X~ == A~Y~ and R~X~ == R~Y~ and X->Y
** NOTE: this case means no availability/visibility ops required when it's
the same (agent,reference).
* X and Y are mutually-ordered atomics, and X is before Y in X's scoped
modification order
* X is a read, both X and Y are non-private, and X->Y
* X is a read, and X (transitively) system-synchronizes with Y
* If R~X~ == R~Y~ and A~X~ and A~Y~ access a common memory domain D (e.g.
are in the same workgroup instance if D is the workgroup instance
domain), and both X and Y are non-private:
** X is a write, Y is a write, AV(A~X~,R~X~,D,L) is an availability
operation making (X,L) available to domain D, and
X->^rcpo^AV(A~X~,R~X~,D,L)->Y
** X is a write, Y is a read, AV(A~X~,R~X~,D,L) is an availability
operation making (X,L) available to domain D, VIS(A~Y~,R~Y~,D,L) is a
visibility operation making writes to L available in domain D visible
to Y, and X->^rcpo^AV(A~X~,R~X~,D,L)->VIS(A~Y~,R~Y~,D,L)->^rcpo^Y
* Let D~X~ and D~Y~ each be either the device domain or the host domain,
depending on whether A~X~ and A~Y~ execute on the device or host:
** X is a write and Y is a write, and
X->AV(A~X~,R~X~,D~X~,L)->DOM(D~X~,D~Y~)->Y
** X is a write and Y is a read, and
X->AV(A~X~,R~X~,D~X~,L)->DOM(D~X~,D~Y~)->VIS(A~Y~,R~Y~,D~Y~,L)->Y
NOTE: The final bullet (synchronization through device/host domain) requires
API-level synchronization operations, since the device/host domains are not
accessible via shader instructions.
And "device domain" is not to be confused with "device scope", which
synchronizes through the "shader domain".
[[memory-model-access-data-race]]
== Data Race
Let X and Y be operations that access overlapping sets of memory locations
M, where X != Y, and at least one of X and Y is a write, and X and Y are not
mutually-ordered atomic operations.
If there does not exist a location-ordered relation between X and Y for each
location in M, then there is a _data race_.
Applications must: ensure that no data races occur during the execution of
their application.
NOTE: Data races can only occur due to instructions that are actually
executed, and for example an instruction skipped due to flow control must
not contribute to a data race.
[[memory-model-visible-to]]
== Visible-To
Let X be a write and Y be a read whose sets of memory locations overlap, and
let M be the set of memory locations that overlap.
Let M~2~ be a non-empty subset of M. Then X is _visible-to_ Y for memory
locations M~2~ if and only if all of the following are true:
* X is location-ordered before Y for each location L in M~2~.
* There does not exist another write Z to any location L in M~2~ such that
X is location-ordered before Z for location L and Z is location-ordered
before Y for location L.
If X is visible-to Y, then Y reads the value written by X for locations
M~2~.
NOTE: It is possible for there to be a write between X and Y that overwrites
a subset of the memory locations, but the remaining memory locations (M~2~)
will still be visible-to Y.
[[memory-model-scoped-modification-order-coherence]]
== Scoped Modification Order Coherence
Let A and B be mutually-ordered atomic operations, where A happens-before B,
and let O be A's scoped modification order.
Then:
* If A and B are both writes, then A must: be earlier than B in O
* If A and B are both reads, then the write that A takes its value from
must: be earlier in O than (or the same as) the write that B takes its
value from
* If A is a write and B is a read, then B must: take its value from A or a
write later than A in O
* If A is a read and B is a write, then A must: take its value from a
write earlier than B in O
[[memory-model-shader-io]]
== Shader I/O
If a shader invocation A in a shader stage other than code:Vertex performs a
memory read operation X from an object in the code:Input storage class, then
X is system-synchronized-after all writes to the corresponding code:Output
storage variable(s) in the upstream shader invocation(s) that contribute to
generating invocation A, and those writes are all visible-to X.
NOTE: It is not necessary for the upstream shader invocations to have
completed execution, they only need to have generated the output that is
being read.
[[memory-model-deallocation]]
== Deallocation
A call to vkFreeMemory must: happen-after all memory operations on all
memory locations in that VkDeviceMemory object.
NOTE: Normally, device memory operations in a given queue are synchronized
with vkFreeMemory by having a host thread wait on a fence signalled by that
queue, and the wait happens-before the call to vkFreeMemory on the host.
The deallocation of SPIR-V variables is managed by the system and
happens-after all operations on those variables.
[[memory-model-informative-descriptions]]
== Informative Descriptions
This subsection is non-normative, and offers more easily understandable
consequences of the memory model for app/compiler developers.
Let SC be the storage class(es) specified by a release or acquire operation
or barrier.
* An atomic write with release semantics must not be reordered against any
read or write to SC that is program-ordered before it (regardless of the
storage class the atomic is in).
* An atomic read with acquire semantics must not be reordered against any
read or write to SC that is program-ordered after it (regardless of the
storage class the atomic is in).
* Any write to SC program-ordered after a release barrier must not be
reordered against any read or write to SC program-ordered before that
barrier.
* Any read from SC program-ordered before an acquire barrier must not be
reordered against any read or write to SC program-ordered after the
barrier.
A control barrier (even if it has no memory semantics) must not be reordered
against any memory barriers.
This memory model allows memory accesses with and without availability and
visibility operations, as well as atomic operations, all to be performed on
the same memory location.
This is critical to allow it to reason about memory that is reused in
multiple ways, e.g. across the lifetime of different shader invocations or
draw calls.
While GLSL (and legacy SPIR-V) applies the "coherent" decoration to
variables (for historical reasons), this model treats each memory access
instruction as having optional implicit availability/visibility operations.
GLSL to SPIR-V compilers should map all (non-atomic) operations on a
coherent variable to Make{Pointer,Texel}{Available}{Visible} flags in this
model.
Atomic operations implicitly have availability/visibility operations, and
the scope of those operations is taken from the atomic operation's scope.
[[memory-model-tessellation-output-ordering]]
== Tessellation Output Ordering
For SPIR-V that uses the Vulkan Memory Model, the code:OutputMemory storage
class is used to synchronize accesses to tessellation control output
variables.
For legacy SPIR-V that does not enable the Vulkan Memory Model via
code:OpMemoryModel, tessellation outputs can be ordered using a control
barrier with no particular memory scope or semantics, as defined below.
Let X and Y be memory operations performed by shader invocations A~X~ and
A~Y~.
Operation X is _tessellation-output-ordered_ before operation Y if and only
if all of the following are true:
* There is a dynamic instance of an code:OpControlBarrier instruction C
such that X is program-ordered before C in A~X~ and C is program-ordered
before Y in A~Y~.
* A~X~ and A~Y~ are in the same instance of C's execution scope.
If shader invocations A~X~ and A~Y~ in the code:TessellationControl
execution model execute memory operations X and Y, respectively, on the
code:Output storage class, and X is tessellation-output-ordered before Y
with a scope of code:Workgroup, then X is location-ordered before Y, and if
X is a write and Y is a read then X is visible-to Y.

27
appendices/spirvenv.txt
View File

@ -206,6 +206,11 @@ ifdef::VK_KHR_8bit_storage[]
| code:UniformAndStorageBuffer8BitAccess | <<features-features-uniformAndStorageBuffer8BitAccess,UniformAndStorageBuffer8BitAccess>>
| code:StoragePushConstant8 | <<features-features-storagePushConstant8,StoragePushConstant8>>
endif::VK_KHR_8bit_storage[]
ifdef::VK_KHR_vulkan_memory_model[]
[[spirvenv-capabilities-table-memorymodel]]
| code:VulkanMemoryModelKHR | <<features-features-vulkanMemoryModel,vulkanMemoryModel>>
| code:VulkanMemoryModelDeviceScopeKHR | <<features-features-vulkanMemoryModel,vulkanMemoryModelDeviceScope>>
endif::VK_KHR_vulkan_memory_model[]
|====
ifdef::VK_VERSION_1_1,VK_KHR_variable_pointers[]
@ -332,6 +337,11 @@ The application can: pass a SPIR-V module to flink:vkCreateShaderModule that
uses the +SPV_EXT_descriptor_indexing+ SPIR-V extension.
endif::VK_EXT_descriptor_indexing[]
ifdef::VK_KHR_vulkan_memory_model[]
The application can: pass a SPIR-V module to flink:vkCreateShaderModule that
uses the `SPV_KHR_vulkan_memory_model` SPIR-V extension.
endif::VK_KHR_vulkan_memory_model[]
The application must: not pass a SPIR-V module containing any of the
following to flink:vkCreateShaderModule:
@ -356,6 +366,23 @@ following rules:
** *Subgroup*
* *Scope* for memory must: be limited to:
** *Device*
ifdef::VK_KHR_vulkan_memory_model[]
*** If <<features-features-vulkanMemoryModel,pname:vulkanMemoryModel>> is
enabled and
<<features-features-vulkanMemoryModelDeviceScope,pname:vulkanMemoryModelDeviceScope>>
is not enabled, *Device* scope must: not be used.
*** If <<features-features-vulkanMemoryModel,pname:vulkanMemoryModel>> is
not enabled, *Device* scope only extends to the queue family, not the
whole device.
endif::VK_KHR_vulkan_memory_model[]
ifndef::VK_KHR_vulkan_memory_model[]
*** *Device* scope only extends to the queue family, not the whole device.
endif::VK_KHR_vulkan_memory_model[]
ifdef::VK_KHR_vulkan_memory_model[]
** *QueueFamilyKHR*
*** If <<features-features-vulkanMemoryModel,pname:vulkanMemoryModel>> is
not enabled, *QueueFamilyKHR* must: not be used.
endif::VK_KHR_vulkan_memory_model[]
** *Workgroup*
ifdef::VK_VERSION_1_1[]
** *Subgroup*

2
chapters/cmdbuffers.txt
View File

@ -1023,7 +1023,7 @@ See <<devsandqueues-lost-device,Lost Device>>.
Each element of the pname:pCommandBuffers member of each element of
pname:pSubmits must: have been allocated from a sname:VkCommandPool that
was created for the same queue family pname:queue belongs to.
* [[VUID-vkQueueSubmit-pCommandBuffers]]
* [[VUID-vkQueueSubmit-pSubmits-02207]]
If any element of pname:pSubmits->pname:pCommandBuffers includes a
<<synchronization-queue-transfers-acquire, Queue Family Transfer Acquire
Operation>>, there must: exist a previously submitted

366
chapters/descriptorsets.txt
View File

@ -267,6 +267,30 @@ to a <<descriptorsets-binding-dynamicoffsets, dynamic offset>> when binding
the descriptor set.
ifdef::VK_EXT_inline_uniform_block[]
[[descriptorsets-inlineuniformblock]]
=== Inline Uniform Block
An _inline uniform block_
(ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT) is almost identical to a
<<descriptorsets-uniformbuffer, uniform buffer>>, and differs only in taking
its storage directly from the encompassing descriptor set instead of being
backed by buffer memory.
It is typically used to access a small set of constant data that does not
require the additional flexibility provided by the indirection enabled when
using a uniform buffer where the descriptor and the referenced buffer memory
are decoupled.
Compared to push constants, they allow reusing the same set of constant data
across multiple disjoint sets of draw and dispatch commands.
Inline uniform block descriptors cannot: be aggregated into arrays.
Instead, the array size specified for an inline uniform block descriptor
binding specifies the binding's capacity in bytes.
endif::VK_EXT_inline_uniform_block[]
[[descriptorsets-inputattachment]]
=== Input Attachment
@ -380,6 +404,13 @@ ifdef::VK_KHR_push_descriptor[]
elements of pname:pBindings must: not have a pname:descriptorType of
ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC or
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkDescriptorSetLayoutCreateInfo-flags-02208]]
If pname:flags contains
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all
elements of pname:pBindings must: not have a pname:descriptorType of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT
endif::VK_EXT_inline_uniform_block[]
* [[VUID-VkDescriptorSetLayoutCreateInfo-flags-00281]]
If pname:flags contains
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then the
@ -460,7 +491,13 @@ include::../api/structs/VkDescriptorSetLayoutBinding.txt[]
* pname:descriptorType is a elink:VkDescriptorType specifying which type
of resource descriptors are used for this binding.
* pname:descriptorCount is the number of descriptors contained in the
binding, accessed in a shader as an array.
binding, accessed in a shader as an array
ifdef::VK_EXT_inline_uniform_block[]
, except if pname:descriptorType is
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT in which case
pname:descriptorCount is the size in bytes of the inline uniform block
endif::VK_EXT_inline_uniform_block[]
.
If pname:descriptorCount is zero this binding entry is reserved and the
resource must: not be accessed from any stage via this binding within
any pipeline using the set layout.
@ -523,6 +560,17 @@ avoid wasted memory.
pname:descriptorCount is not `0` and pname:pImmutableSamplers is not
`NULL`, pname:pImmutableSamplers must: be a valid pointer to an array of
pname:descriptorCount valid sname:VkSampler handles
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkDescriptorSetLayoutBinding-descriptorType-02209]]
If pname:descriptorType is
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT then
pname:descriptorCount must: be a multiple of `4`
* [[VUID-VkDescriptorSetLayoutBinding-descriptorType-02210]]
If pname:descriptorType is
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT then
pname:descriptorCount must: be less than or equal to
sname:VkPhysicalDeviceInlineUniformBlockPropertiesEXT::pname:maxInlineUniformBlockSize
endif::VK_EXT_inline_uniform_block[]
* [[VUID-VkDescriptorSetLayoutBinding-descriptorCount-00283]]
If pname:descriptorCount is not `0`, pname:stageFlags must: be a valid
combination of elink:VkShaderStageFlagBits values
@ -621,6 +669,14 @@ endif::VK_KHR_push_descriptor[]
is not enabled, all bindings with descriptor type
ename:VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER must: not use
ename:VK_DESCRIPTOR_BINDING_UPDATE_AFTER_BIND_BIT_EXT
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkDescriptorSetLayoutBindingFlagsCreateInfoEXT-descriptorBindingInlineUniformBlockUpdateAfterBind-02211]]
If
slink:VkPhysicalDeviceInlineUniformBlockFeatureEXT::pname:descriptorBindingInlineUniformBlockUpdateAfterBind
is not enabled, all bindings with descriptor type
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT must: not use
ename:VK_DESCRIPTOR_BINDING_UPDATE_AFTER_BIND_BIT_EXT
endif::VK_EXT_inline_uniform_block[]
* [[VUID-VkDescriptorSetLayoutBindingFlagsCreateInfoEXT-None-03011]]
All bindings with descriptor type
ename:VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT,
@ -702,7 +758,16 @@ endif::VK_KHR_descriptor_update_template[]
layout (i.e. the binding with the largest value of pname:binding).
For the purposes of counting against limits such as
pname:maxDescriptorSet* and pname:maxPerStageDescriptor*, the full value
of pname:descriptorCount is counted.
of pname:descriptorCount is counted
ifdef::VK_EXT_inline_uniform_block[]
, except for descriptor bindings with a descriptor type of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT where
pname:descriptorCount specifies the upper bound on the byte size of the
binding, thus it counts against the
<<features-limits-maxInlineUniformBlockSize,
pname:maxInlineUniformBlockSize>> limit instead.
endif::VK_EXT_inline_uniform_block[]
.
[NOTE]
.Note
@ -822,6 +887,12 @@ include::../api/structs/VkDescriptorSetVariableDescriptorCountLayoutSupportEXT.t
* pname:maxVariableDescriptorCount indicates the maximum number of
descriptors supported in the highest numbered binding of the layout, if
that binding is variable-sized.
ifdef::VK_EXT_inline_uniform_block[]
If the highest numbered binding of the layout has a descriptor type of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT then
pname:maxVariableDescriptorCount indicates the maximum byte size
supported for the binding, if that binding is variable-sized.
endif::VK_EXT_inline_uniform_block[]
If the create info includes a variable-sized descriptor, then
pname:supported is determined assuming the requested size of the
@ -1133,6 +1204,14 @@ ifndef::VK_EXT_descriptor_indexing[]
stage across all elements of pname:pSetLayouts must: be less than or
equal to
sname:VkPhysicalDeviceLimits::pname:maxPerStageDescriptorInputAttachments
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkPipelineLayoutCreateInfo-descriptorType-02212]]
The total number of bindings with a pname:descriptorType of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT accessible to any
given shader stage across all elements of pname:pSetLayouts must: be
less than or equal to
sname:VkPhysicalDeviceInlineUniformBlockPropertiesEXT::pname:maxPerStageDescriptorInlineUniformBlocks
endif::VK_EXT_inline_uniform_block[]
* [[VUID-VkPipelineLayoutCreateInfo-pSetLayouts-01677]]
The total number of descriptors of the type
ename:VK_DESCRIPTOR_TYPE_SAMPLER and
@ -1185,6 +1264,14 @@ ifndef::VK_EXT_descriptor_indexing[]
stages and across all elements of pname:pSetLayouts must: be less than
or equal to
sname:VkPhysicalDeviceLimits::pname:maxDescriptorSetInputAttachments
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkPipelineLayoutCreateInfo-descriptorType-02213]]
The total number of bindings with a pname:descriptorType of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT accessible across all
shader stages and across all elements of pname:pSetLayouts must: be less
than or equal to
sname:VkPhysicalDeviceInlineUniformBlockPropertiesEXT::pname:maxDescriptorSetInlineUniformBlocks
endif::VK_EXT_inline_uniform_block[]
endif::VK_EXT_descriptor_indexing[]
ifdef::VK_EXT_descriptor_indexing[]
* [[VUID-VkPipelineLayoutCreateInfo-descriptorType-03016]]
@ -1246,6 +1333,16 @@ ifdef::VK_EXT_descriptor_indexing[]
stage across all elements of pname:pSetLayouts must: be less than or
equal to
sname:VkPhysicalDeviceLimits::pname:maxPerStageDescriptorInputAttachments
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkPipelineLayoutCreateInfo-descriptorType-02214]]
The total number of bindings in descriptor set layouts created without
the ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT
bit set with a pname:descriptorType of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT accessible to any
given shader stage across all elements of pname:pSetLayouts must: be
less than or equal to
sname:VkPhysicalDeviceInlineUniformBlockPropertiesEXT::pname:maxPerStageDescriptorInlineUniformBlocks
endif::VK_EXT_inline_uniform_block[]
* [[VUID-VkPipelineLayoutCreateInfo-descriptorType-03022]]
The total number of descriptors with a pname:descriptorType of
ename:VK_DESCRIPTOR_TYPE_SAMPLER and
@ -1288,6 +1385,14 @@ ifdef::VK_EXT_descriptor_indexing[]
stage across all elements of pname:pSetLayouts must: be less than or
equal to
sname:VkPhysicalDeviceDescriptorIndexingPropertiesEXT::pname:maxPerStageDescriptorUpdateAfterBindInputAttachments
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkPipelineLayoutCreateInfo-descriptorType-02215]]
The total number of bindings with a pname:descriptorType of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT accessible to any
given shader stage across all elements of pname:pSetLayouts must: be
less than or equal to
sname:VkPhysicalDeviceInlineUniformBlockPropertiesEXT::pname:maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks
endif::VK_EXT_inline_uniform_block[]
* [[VUID-VkPipelineLayoutCreateInfo-descriptorType-03028]]
The total number of descriptors in descriptor set layouts created
without the
@ -1363,6 +1468,16 @@ ifdef::VK_EXT_descriptor_indexing[]
stages and across all elements of pname:pSetLayouts must: be less than
or equal to
sname:VkPhysicalDeviceLimits::pname:maxDescriptorSetInputAttachments
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkPipelineLayoutCreateInfo-descriptorType-02216]]
The total number of bindings in descriptor set layouts created without
the ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT
bit set with a pname:descriptorType of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT accessible across all
shader stages and across all elements of pname:pSetLayouts must: be less
than or equal to
sname:VkPhysicalDeviceInlineUniformBlockPropertiesEXT::pname:maxDescriptorSetInlineUniformBlocks
endif::VK_EXT_inline_uniform_block[]
* [[VUID-VkPipelineLayoutCreateInfo-pSetLayouts-03036]]
The total number of descriptors of the type
ename:VK_DESCRIPTOR_TYPE_SAMPLER and
@ -1415,6 +1530,14 @@ ifdef::VK_EXT_descriptor_indexing[]
stages and across all elements of pname:pSetLayouts must: be less than
or equal to
sname:VkPhysicalDeviceDescriptorIndexingPropertiesEXT::pname:maxDescriptorSetUpdateAfterBindInputAttachments
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkPipelineLayoutCreateInfo-descriptorType-02217]]
The total number of bindings with a pname:descriptorType of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT accessible across all
shader stages and across all elements of pname:pSetLayouts must: be less
than or equal to
sname:VkPhysicalDeviceInlineUniformBlockPropertiesEXT::pname:maxDescriptorSetUpdateAfterBindInlineUniformBlocks
endif::VK_EXT_inline_uniform_block[]
endif::VK_EXT_descriptor_indexing[]
* [[VUID-VkPipelineLayoutCreateInfo-pPushConstantRanges-00292]]
Any two elements of pname:pPushConstantRanges must: not include the same
@ -1566,6 +1689,13 @@ ifdef::VK_EXT_descriptor_indexing[]
or pname:maxDescriptorSetUpdateAfterBindInputAttachments
endif::VK_EXT_descriptor_indexing[]
| input attachment
ifdef::VK_EXT_inline_uniform_block[]
| pname:maxDescriptorSetInlineUniformBlocks
ifdef::VK_EXT_descriptor_indexing[]
or pname:maxDescriptorSetUpdateAfterBindInlineUniformBlocks
endif::VK_EXT_descriptor_indexing[]
| inline uniform block
endif::VK_EXT_inline_uniform_block[]
|====
@ -1803,6 +1933,37 @@ endif::VK_EXT_descriptor_indexing[]
include::../validity/structs/VkDescriptorPoolCreateInfo.txt[]
--
ifdef::VK_EXT_inline_uniform_block[]
[open,refpage='VkDescriptorPoolInlineUniformBlockCreateInfoEXT',desc='Structure specifying the maximum number of inline uniform block bindings of a newly created descriptor pool',type='structs']
--
In order to be able to allocate descriptor sets having
<<descriptorsets-inlineuniformblock, inline uniform block>> bindings the
descriptor pool must: be created with specifying the inline uniform block
binding capacity of the descriptor pool, in addition to the total inline
uniform data capacity in bytes which is specified through an instance of the
slink:VkDescriptorPoolSize structure with a pname:descriptorType value of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT.
This can: be done by chaining an instance of the
sname:VkDescriptorPoolInlineUniformBlockCreateInfoEXT structure to the
pname:pNext chain of sname:VkDescriptorPoolCreateInfo.
The sname:VkDescriptorPoolInlineUniformBlockCreateInfoEXT structure is
defined as:
include::../api/structs/VkDescriptorPoolInlineUniformBlockCreateInfoEXT.txt[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:maxInlineUniformBlockBindings is the number of inline uniform
block bindings to allocate.
include::../validity/structs/VkDescriptorPoolInlineUniformBlockCreateInfoEXT.txt[]
--
endif::VK_EXT_inline_uniform_block[]
[open,refpage='VkDescriptorPoolCreateFlagBits',desc='Bitmask specifying certain supported operations on a descriptor pool',type='enums']
--
@ -1849,11 +2010,21 @@ include::../api/structs/VkDescriptorPoolSize.txt[]
* pname:type is the type of descriptor.
* pname:descriptorCount is the number of descriptors of that type to
allocate.
ifdef::VK_EXT_inline_uniform_block[]
If pname:type is ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT then
pname:descriptorCount is the number of bytes to allocate for descriptors
of this type.
endif::VK_EXT_inline_uniform_block[]
.Valid Usage
****
* [[VUID-VkDescriptorPoolSize-descriptorCount-00302]]
pname:descriptorCount must: be greater than `0`
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkDescriptorPoolSize-type-02218]]
If pname:type is ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT then
pname:descriptorCount must: be a multiple of `4`
endif::VK_EXT_inline_uniform_block[]
****
include::../validity/structs/VkDescriptorPoolSize.txt[]
@ -1954,6 +2125,15 @@ fname:vkAllocateDescriptorSets would cause the number of any given
descriptor type to exceed the sum of all the pname:descriptorCount members
of each element of slink:VkDescriptorPoolCreateInfo::pname:pPoolSizes with a
pname:member equal to that type.
ifdef::VK_EXT_inline_uniform_block[]
Additionally, the allocation may: also fail if a call to
fname:vkAllocateDescriptorSets would cause the total number of inline
uniform block bindings allocated from the pool to exceed the value of
slink:VkDescriptorPoolInlineUniformBlockCreateInfoEXT::pname:maxInlineUniformBlockBindings
used to create the descriptor pool.
endif::VK_EXT_inline_uniform_block[]
If the allocation fails due to no more space in the descriptor pool, and not
because of system or device memory exhaustion, then
ename:VK_ERROR_OUT_OF_POOL_MEMORY must: be returned.
@ -2075,6 +2255,12 @@ pname:pNext chain, then the variable lengths are considered to be zero.
Otherwise, pname:pDescriptorCounts[i] is the number of descriptors in the
variable count descriptor binding in the corresponding descriptor set
layout.
ifdef::VK_EXT_inline_uniform_block[]
If the variable count descriptor binding in the corresponding descriptor set
layout has a descriptor type of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT then
pname:pDescriptorCounts[i] specifies the binding's capacity in bytes.
endif::VK_EXT_inline_uniform_block[]
If slink:VkDescriptorSetAllocateInfo::pname:pSetLayouts[i] does not include
a variable count descriptor binding, then pname:pDescriptorCounts[i] is
ignored.
@ -2250,9 +2436,27 @@ include::../api/structs/VkWriteDescriptorSet.txt[]
* pname:dstSet is the destination descriptor set to update.
* pname:dstBinding is the descriptor binding within that set.
* pname:dstArrayElement is the starting element in that array.
ifdef::VK_EXT_inline_uniform_block[]
If the descriptor binding identified by pname:dstSet and
pname:dstBinding has a descriptor type of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT then
pname:dstArrayElement specifies the starting byte offset within the
binding.
endif::VK_EXT_inline_uniform_block[]
* pname:descriptorCount is the number of descriptors to update (the number
of elements in pname:pImageInfo, pname:pBufferInfo, or
pname:pTexelBufferView).
pname:pTexelBufferView
ifdef::VK_EXT_inline_uniform_block[]
, or a value matching the pname:dataSize member of an instance of
slink:VkWriteDescriptorSetInlineUniformBlockEXT in the pname:pNext chain
endif::VK_EXT_inline_uniform_block[]
).
ifdef::VK_EXT_inline_uniform_block[]
If the descriptor binding identified by pname:dstSet and
pname:dstBinding has a descriptor type of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT then
pname:descriptorCount specifies the number of bytes to update.
endif::VK_EXT_inline_uniform_block[]
* pname:descriptorType is a elink:VkDescriptorType specifying the type of
each descriptor in pname:pImageInfo, pname:pBufferInfo, or
pname:pTexelBufferView, as described below.
@ -2271,7 +2475,15 @@ include::../api/structs/VkWriteDescriptorSet.txt[]
Only one of pname:pImageInfo, pname:pBufferInfo, or pname:pTexelBufferView
members is used according to the descriptor type specified in the
pname:descriptorType member of the containing sname:VkWriteDescriptorSet
structure, as specified below.
structure,
ifdef::VK_EXT_inline_uniform_block[]
or none of them in case pname:descriptorType is
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT, in which case the source
data for the descriptor writes is taken from the instance of
slink:VkWriteDescriptorSetInlineUniformBlockEXT in the pname:pNext chain of
sname:VkWriteDescriptorSet,
endif::VK_EXT_inline_uniform_block[]
as specified below.
[[descriptorsets-updates-consecutive, consecutive binding updates]]
If the pname:dstBinding has fewer than pname:descriptorCount array elements
@ -2282,6 +2494,22 @@ If a binding has a pname:descriptorCount of zero, it is skipped.
This behavior applies recursively, with the update affecting consecutive
bindings as needed to update all pname:descriptorCount descriptors.
ifdef::VK_EXT_inline_uniform_block[]
[NOTE]
.Note
====
The same behavior applies to bindings with a descriptor type of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK where pname:descriptorCount
specifies the number of bytes to update while pname:dstArrayElement
specifies the starting byte offset, thus in this case if the
pname:dstBinding has a smaller byte size than the sum of
pname:dstArrayElement and pname:descriptorCount, then the remainder will be
used to update the subsequent binding - [eq]#pname:dstBinding+1# starting at
offset zero.
This falls out as a special case of the above rule.
====
endif::VK_EXT_inline_uniform_block[]
.Valid Usage
****
* [[VUID-VkWriteDescriptorSet-dstBinding-00315]]
@ -2309,6 +2537,16 @@ bindings as needed to update all pname:descriptorCount descriptors.
than or equal to the number of array elements in the descriptor set
binding specified by pname:dstBinding, and all applicable consecutive
bindings, as described by <<descriptorsets-updates-consecutive>>
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkWriteDescriptorSet-descriptorType-02219]]
If pname:descriptorType is
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT, pname:dstArrayElement
must: be an integer multiple of `4`
* [[VUID-VkWriteDescriptorSet-descriptorType-02220]]
If pname:descriptorType is
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT, pname:descriptorCount
must: be an integer multiple of `4`
endif::VK_EXT_inline_uniform_block[]
* [[VUID-VkWriteDescriptorSet-descriptorType-00322]]
If pname:descriptorType is ename:VK_DESCRIPTOR_TYPE_SAMPLER,
ename:VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER,
@ -2343,6 +2581,13 @@ bindings as needed to update all pname:descriptorCount descriptors.
ename:VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT, the pname:imageView and
pname:imageLayout members of each element of pname:pImageInfo must: be a
valid sname:VkImageView and elink:VkImageLayout, respectively
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkWriteDescriptorSet-descriptorType-02221]]
If pname:descriptorType is
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT, the pname:pNext chain
must: include a slink:VkWriteDescriptorSetInlineUniformBlockEXT
structure whose pname:dataSize member equals pname:descriptorCount
endif::VK_EXT_inline_uniform_block[]
ifdef::VULKAN_1_1,VK_KHR_sampler_ycbcr_conversion[]
* [[VUID-VkWriteDescriptorSet-descriptorType-01946]]
If pname:descriptorType is ename:VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE, then
@ -2491,8 +2736,12 @@ include::../api/enums/VkDescriptorType.txt[]
* ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC specifies a
<<descriptorsets-storagebufferdynamic, dynamic storage buffer
descriptor>>.
* ename:VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT specifies a
* ename:VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT specifies an
<<descriptorsets-inputattachment, input attachment descriptor>>.
ifdef::VK_EXT_inline_uniform_block[]
* ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT specifies an
<<descriptorsets-inlineuniformblock, inline uniform block>>.
endif::VK_EXT_inline_uniform_block[]
When a descriptor set is updated via elements of slink:VkWriteDescriptorSet,
members of pname:pImageInfo, pname:pBufferInfo and pname:pTexelBufferView
@ -2500,7 +2749,7 @@ are only accessed by the implementation when they correspond to descriptor
type being defined - otherwise they are ignored.
The members accessed are as follows for each descriptor type:
* For ename:VK_DESCRIPTOR_TYPE_SAMPLER, only the pname:sample member of
* For ename:VK_DESCRIPTOR_TYPE_SAMPLER, only the pname:sampler member of
each element of slink:VkWriteDescriptorSet::pname:pImageInfo is
accessed.
* For ename:VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE,
@ -2518,6 +2767,15 @@ The members accessed are as follows for each descriptor type:
* For ename:VK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER or
ename:VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER, each element of
slink:VkWriteDescriptorSet::pname:pTexelBufferView is accessed.
ifdef::VK_EXT_inline_uniform_block[]
When updating descriptors with a pname:descriptorType of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT, none of the
pname:pImageInfo, pname:pBufferInfo, or pname:pTexelBufferView members are
accessed, instead the source data of the descriptor update operation is
taken from the instance of slink:VkWriteDescriptorSetInlineUniformBlockEXT
in the pname:pNext chain of sname:VkWriteDescriptorSet.
endif::VK_EXT_inline_uniform_block[]
--
[open,refpage='VkDescriptorBufferInfo',desc='Structure specifying descriptor buffer info',type='structs']
@ -2627,6 +2885,37 @@ endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
include::../validity/structs/VkDescriptorImageInfo.txt[]
--
ifdef::VK_EXT_inline_uniform_block[]
[open,refpage='VkWriteDescriptorSetInlineUniformBlockEXT',desc='Structure specifying inline uniform block data',type='structs']
--
If the pname:descriptorType member of slink:VkWriteDescriptorSet is
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT then the data to write to
the descriptor set is specified through an instance of
sname:VkWriteDescriptorSetInlineUniformBlockEXT chained to the pname:pNext
chain of sname:VkWriteDescriptorSet.
The sname:VkWriteDescriptorSetInlineUniformBlockEXT structure is defined as:
include::../api/structs/VkWriteDescriptorSetInlineUniformBlockEXT.txt[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:dataSize is the number of bytes of inline uniform block data
pointed to by pname:pData.
* pname:pData is a pointer to pname:dataSize number of bytes of data to
write to the inline uniform block.
.Valid Usage
****
* [[VUID-VkWriteDescriptorSetInlineUniformBlockEXT-dataSize-02222]]
pname:dataSize must: be an integer multiple of `4`
****
include::../validity/structs/VkWriteDescriptorSetInlineUniformBlockEXT.txt[]
--
endif::VK_EXT_inline_uniform_block[]
[open,refpage='VkCopyDescriptorSet',desc='Structure specifying a copy descriptor set operation',type='structs']
--
@ -2638,13 +2927,35 @@ include::../api/structs/VkCopyDescriptorSet.txt[]
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:srcSet, pname:srcBinding, and pname:srcArrayElement are the source
set, binding, and array element, respectively.
ifdef::VK_EXT_inline_uniform_block[]
If the descriptor binding identified by pname:srcSet and
pname:srcBinding has a descriptor type of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT then
pname:srcArrayElement specifies the starting byte offset within the
binding to copy from.
endif::VK_EXT_inline_uniform_block[]
* pname:dstSet, pname:dstBinding, and pname:dstArrayElement are the
destination set, binding, and array element, respectively.
ifdef::VK_EXT_inline_uniform_block[]
If the descriptor binding identified by pname:dstSet and
pname:dstBinding has a descriptor type of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT then
pname:dstArrayElement specifies the starting byte offset within the
binding to copy to.
endif::VK_EXT_inline_uniform_block[]
* pname:descriptorCount is the number of descriptors to copy from the
source to destination.
If pname:descriptorCount is greater than the number of remaining array
elements in the source or destination binding, those affect consecutive
bindings in a manner similar to slink:VkWriteDescriptorSet above.
ifdef::VK_EXT_inline_uniform_block[]
If the descriptor binding identified by pname:srcSet and
pname:srcBinding has a descriptor type of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT then
pname:descriptorCount specifies the number of bytes to copy and the
remaining array elements in the source or destination binding refer to
the remaining number of bytes in those.
endif::VK_EXT_inline_uniform_block[]
.Valid Usage
****
@ -2667,6 +2978,21 @@ include::../api/structs/VkCopyDescriptorSet.txt[]
destination ranges of descriptors must: not overlap, where the ranges
may: include array elements from consecutive bindings as described by
<<descriptorsets-updates-consecutive>>
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkCopyDescriptorSet-srcBinding-02223]]
If the descriptor type of the descriptor set binding specified by
pname:srcBinding is ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT,
pname:srcArrayElement must: be an integer multiple of `4`
* [[VUID-VkCopyDescriptorSet-dstBinding-02224]]
If the descriptor type of the descriptor set binding specified by
pname:dstBinding is ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT,
pname:dstArrayElement must: be an integer multiple of `4`
* [[VUID-VkCopyDescriptorSet-srcBinding-02225]]
If the descriptor type of the descriptor set binding specified by either
pname:srcBinding or pname:dstBinding is
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT, pname:descriptorCount
must: be an integer multiple of `4`
endif::VK_EXT_inline_uniform_block[]
ifdef::VK_EXT_descriptor_indexing[]
* [[VUID-VkCopyDescriptorSet-srcSet-01918]]
If pname:srcSet's layout was created with the
@ -2941,10 +3267,22 @@ endif::VK_KHR_descriptor_update_template[]
descriptor update template.
* pname:dstArrayElement is the starting element in the array belonging to
pname:dstBinding.
ifdef::VK_EXT_inline_uniform_block[]
If the descriptor binding identified by pname:srcBinding has a
descriptor type of ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT
then pname:dstArrayElement specifies the starting byte offset to update.
endif::VK_EXT_inline_uniform_block[]
* pname:descriptorCount is the number of descriptors to update.
If pname:descriptorCount is greater than the number of remaining array
elements in the destination binding, those affect consecutive bindings
in a manner similar to slink:VkWriteDescriptorSet above.
ifdef::VK_EXT_inline_uniform_block[]
If the descriptor binding identified by pname:dstBinding has a
descriptor type of ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT
then pname:descriptorCount specifies the number of bytes to update and
the remaining array elements in the destination binding refer to the
remaining number of bytes in it.
endif::VK_EXT_inline_uniform_block[]
* pname:descriptorType is a elink:VkDescriptorType specifying the type of
the descriptor.
* pname:offset is the offset in bytes of the first binding in the raw data
@ -2962,6 +3300,12 @@ endif::VK_KHR_descriptor_update_template[]
+
The stride is useful in case the bindings are stored in structs along with
other data.
ifdef::VK_EXT_inline_uniform_block[]
If pname:descriptorType is ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT
then the value of pname:stride is ignored and the stride is assumed to be
`1`, i.e. the descriptor update information for them is always specified as
a contiguous range.
endif::VK_EXT_inline_uniform_block[]
.Valid Usage
****
@ -2975,6 +3319,16 @@ other data.
implicitly specified when using a descriptor update template to update
descriptors, and all applicable consecutive bindings, as described by
<<descriptorsets-updates-consecutive>>
ifdef::VK_EXT_inline_uniform_block[]
* [[VUID-VkDescriptorUpdateTemplateEntry-descriptor-02226]]
If pname:descriptor type is
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT, pname:dstArrayElement
must: be an integer multiple of `4`
* [[VUID-VkDescriptorUpdateTemplateEntry-descriptor-02227]]
If pname:descriptor type is
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT, pname:descriptorCount
must: be an integer multiple of `4`
endif::VK_EXT_inline_uniform_block[]
****
include::../validity/structs/VkDescriptorUpdateTemplateEntry.txt[]

225
chapters/features.txt
View File

@ -1316,6 +1316,141 @@ include::../validity/structs/VkPhysicalDeviceDescriptorIndexingFeaturesEXT.txt[]
endif::VK_EXT_descriptor_indexing[]
ifdef::VK_EXT_vertex_attribute_divisor[]
[open,refpage='VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT',desc='Structure describing if fetching of vertex attribute may be repeated for instanced rendering',type='structs']
--
The sname:VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT structure is
defined as:
include::../api/structs/VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT.txt[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[features-features-vertexAttributeInstanceRateDivisor]]
pname:vertexAttributeInstanceRateDivisor specifies whether vertex
attribute fetching may be repeated in case of instanced rendering.
* [[features-features-vertexAttributeInstanceRateZeroDivisor]]
pname:vertexAttributeInstanceRateZeroDivisor specifies whether a zero
value for sname:VkVertexInputBindingDivisorDescriptionEXT::pname:divisor
is supported.
If the sname:VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT structure is
included in the pname:pNext chain of flink:VkPhysicalDeviceFeatures2, it is
filled with values indicating the implementation-dependent behavior.
sname:VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT can: also be used in
pname:pNext chain of slink:VkDeviceCreateInfo to enable the feature.
include::../validity/structs/VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT.txt[]
--
endif::VK_EXT_vertex_attribute_divisor[]
ifdef::VK_EXT_astc_decode_mode[]
[open,refpage='VkPhysicalDeviceASTCDecodeFeaturesEXT',desc='Structure describing ASTC decode mode features',type='structs']
--
The sname:VkPhysicalDeviceASTCDecodeFeaturesEXT structure is defined as:
include::../api/structs/VkPhysicalDeviceASTCDecodeFeaturesEXT.txt[]
The members of the sname:VkPhysicalDeviceASTCDecodeFeaturesEXT structure
describe the following features:
* [[features-features-astc-decodeModeSharedExponent]]
pname:decodeModeSharedExponent indicates whether the implementation
supports decoding ASTC compressed formats to
ename:FORMAT_E5B9G9R9_UFLOAT_PACK32 internal precision.
If the sname:VkPhysicalDeviceASTCDecodeFeaturesEXT structure is included in
the pname:pNext chain of flink:vkGetPhysicalDeviceFeatures2KHR, it is filled
with values indicating whether each feature is supported.
sname:VkPhysicalDeviceASTCDecodeFeaturesEXT can: also be used in the
pname:pNext chain of flink:vkCreateDevice to enable features.
include::../validity/structs/VkPhysicalDeviceASTCDecodeFeaturesEXT.txt[]
--
endif::VK_EXT_astc_decode_mode[]
ifdef::VK_KHR_vulkan_memory_model[]
[open,refpage='VkPhysicalDeviceVulkanMemoryModelFeaturesKHR',desc='Structure describing features supported by VK_KHR_vulkan_memory_model',type='structs']
--
To query memory model features additionally supported call
flink:vkGetPhysicalDeviceFeatures2 with a
sname:VkPhysicalDeviceVulkanMemoryModelFeaturesKHR structure included in the
pname:pNext chain of its pname:pFeatures parameter.
The sname:VkPhysicalDeviceVulkanMemoryModelFeaturesKHR structure can: also
be in the pname:pNext chain of a slink:VkDeviceCreateInfo structure, in
which case it controls which additional features are enabled in the device.
The slink:VkPhysicalDeviceVulkanMemoryModelFeaturesKHR structure is defined
as:
include::../api/structs/VkPhysicalDeviceVulkanMemoryModelFeaturesKHR.txt[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[features-features-vulkanMemoryModel]] pname:vulkanMemoryModel
indicates whether the Vulkan Memory Model is supported, as defined in
<<memory-model,Vulkan Memory Model>>.
This also indicates whether shader modules can: declare the
code:VulkanMemoryModelKHR capability.
* [[features-features-vulkanMemoryModelDeviceScope]]
pname:vulkanMemoryModelDeviceScope indicates whether the Vulkan Memory
Model can use code:Device scope synchronization.
This also indicates whether shader modules can: declare the
code:VulkanMemoryModelDeviceScopeKHR capability.
include::../validity/structs/VkPhysicalDeviceVulkanMemoryModelFeaturesKHR.txt[]
--
endif::VK_KHR_vulkan_memory_model[]
ifdef::VK_EXT_inline_uniform_block[]
[open,refpage='VkPhysicalDeviceInlineUniformBlockFeaturesEXT',desc='Structure describing inline uniform block features that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceInlineUniformBlockFeaturesEXT structure is defined
as:
include::../api/structs/VkPhysicalDeviceInlineUniformBlockFeaturesEXT.txt[]
The members of the sname:VkPhysicalDeviceInlineUniformBlockFeaturesEXT
structure describe the following features:
* [[features-features-inlineUniformBlock]] pname:inlineUniformBlock
indicates whether the implementation supports inline uniform block
descriptors.
If this feature is not enabled,
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT must: not be used.
* [[features-features-descriptorBindingInlineUniformBlockUpdateAfterBind]]
pname:descriptorBindingInlineUniformBlockUpdateAfterBind
ifndef::VK_EXT_descriptor_indexing[]
is ename:VK_FALSE and reserved for future use.
endif::VK_EXT_descriptor_indexing[]
ifdef::VK_EXT_descriptor_indexing[]
indicates whether the implementation supports updating inline uniform
block descriptors after a set is bound.
If this feature is not enabled,
ename:VK_DESCRIPTOR_BINDING_UPDATE_AFTER_BIND_BIT_EXT must: not be used
with ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT.
endif::VK_EXT_descriptor_indexing[]
If the sname:VkPhysicalDeviceInlineUniformBlockFeaturesEXT structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceFeatures2, it is
filled with values indicating whether each feature is supported.
sname:VkPhysicalDeviceInlineUniformBlockFeaturesEXT can: also be used in the
pname:pNext chain of slink:VkDeviceCreateInfo to enable features.
include::../validity/structs/VkPhysicalDeviceInlineUniformBlockFeaturesEXT.txt[]
--
endif::VK_EXT_inline_uniform_block[]
[[features-features-requirements]]
=== Feature Requirements
@ -1374,6 +1509,14 @@ ifdef::VK_EXT_descriptor_indexing[]
pname:descriptorBindingPartiallyBound>>
** <<features-features-runtimeDescriptorArray,
pname:runtimeDescriptorArray>>
ifdef::VK_EXT_inline_uniform_block[]
* <<features-features-inlineUniformBlock,pname:inlineUniformBlock>>, if
the `<<VK_EXT_inline_uniform_block>>` extension is supported.
* <<features-features-descriptorBindingInlineUniformBlockUpdateAfterBind,
pname:descriptorBindingInlineUniformBlockUpdateAfterBind>>, if the
`<<VK_EXT_inline_uniform_block>>` and `<<VK_EXT_descriptor_indexing>>`
extensions are both supported.
endif::VK_EXT_inline_uniform_block[]
endif::VK_EXT_descriptor_indexing[]
All other features defined in the Specification are optional:.
@ -2903,6 +3046,81 @@ include::../validity/structs/VkPhysicalDeviceDescriptorIndexingPropertiesEXT.txt
endif::VK_EXT_descriptor_indexing[]
ifdef::VK_EXT_inline_uniform_block[]
[open,refpage='VkPhysicalDeviceInlineUniformBlockPropertiesEXT',desc='Structure describing inline uniform block properties that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceInlineUniformBlockPropertiesEXT structure is
defined as:
include::../api/structs/VkPhysicalDeviceInlineUniformBlockPropertiesEXT.txt[]
The members of the sname:VkPhysicalDeviceInlineUniformBlockPropertiesEXT
structure describe the following implementation-dependent limits:
* [[features-limits-maxInlineUniformBlockSize]]
pname:maxInlineUniformBlockSize is the maximum size in bytes of an
<<descriptorsets-inlineuniformblock, inline uniform block>> binding.
* [[features-limits-maxPerStageDescriptorInlineUniformBlocks]]
pname:maxPerStageDescriptorInlineUniformBlock is the maximum number of
inline uniform block bindings that can: be accessible to a single shader
stage in a pipeline layout.
Descriptor bindings with a descriptor type of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT count against this
limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptor bindings in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
* [[features-limits-maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks]]
pname:maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks
ifndef::VK_EXT_descriptor_indexing[]
equals pname:maxPerStageDescriptorInlineUniformBlocks and is reserved
for future use.
endif::VK_EXT_descriptor_indexing[]
ifdef::VK_EXT_descriptor_indexing[]
is similar to pname:maxPerStageDescriptorInlineUniformBlocks but counts
descriptor bindings from descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
endif::VK_EXT_descriptor_indexing[]
* [[features-limits-maxDescriptorSetInlineUniformBlocks]]
pname:maxDescriptorSetInlineUniformBlocks is the maximum number of
inline uniform block bindings that can: be included in descriptor
bindings in a pipeline layout across all pipeline shader stages and
descriptor set numbers.
Descriptor bindings with a descriptor type of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT count against this
limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptor bindings in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
* [[features-limits-maxDescriptorSetUpdateAfterBindInlineUniformBlocks]]
pname:maxDescriptorSetUpdateAfterBindInlineUniformBlocks
ifndef::VK_EXT_descriptor_indexing[]
equals pname:maxDescriptorSetInlineUniformBlocks and is reserved for
future use.
endif::VK_EXT_descriptor_indexing[]
ifdef::VK_EXT_descriptor_indexing[]
is similar to pname:maxDescriptorSetInlineUniformBlocks but counts
descriptor bindings from descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
endif::VK_EXT_descriptor_indexing[]
If the sname:VkPhysicalDeviceInlineUniformBlockPropertiesEXT structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2KHR,
it is filled with the implementation-dependent limits.
include::../validity/structs/VkPhysicalDeviceInlineUniformBlockPropertiesEXT.txt[]
--
endif::VK_EXT_inline_uniform_block[]
ifdef::VK_EXT_conservative_rasterization[]
[open,refpage='VkPhysicalDeviceConservativeRasterizationPropertiesEXT',desc='Structure describing conservative raster properties that can be supported by an implementation',type='structs']
@ -3413,6 +3631,13 @@ ifdef::VK_EXT_descriptor_indexing[]
| pname:maxDescriptorSetUpdateAfterBindStorageImages | - |500000 ^9^ | min
| pname:maxDescriptorSetUpdateAfterBindInputAttachments | - |500000 ^9^ | min
endif::VK_EXT_descriptor_indexing[]
ifdef::VK_EXT_inline_uniform_block[]
| pname:maxInlineUniformBlockSize | - | 256 | min
| pname:maxPerStageDescriptorInlineUniformBlocks | - | 4 | min
| pname:maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks | - | 4 | min
| pname:maxDescriptorSetInlineUniformBlocks | - | 4 | min
| pname:maxDescriptorSetUpdateAfterBindInlineUniformBlocks | - | 4 | min
endif::VK_EXT_inline_uniform_block[]
ifdef::VK_EXT_vertex_attribute_divisor[]
| pname:maxVertexAttribDivisor | - | 2^16^-1 | min
endif::VK_EXT_vertex_attribute_divisor[]

29
chapters/fxvertex.txt
View File

@ -460,10 +460,13 @@ ifdef::VK_EXT_vertex_attribute_divisor[]
[open,refpage='VkPipelineVertexInputDivisorStateCreateInfoEXT',desc='Structure specifying vertex attributes assignment during instanced rendering',type='structs']
--
If the pname:pNext chain of slink:VkPipelineVertexInputStateCreateInfo
includes a sname:VkPipelineVertexInputDivisorStateCreateInfoEXT structure,
then that structure controls how vertex attributes are assigned to an
instance when instanced rendering is enabled.
If
<<features-features-vertexAttributeInstanceRateDivisor,pname:vertexAttributeInstanceRateDivisor>>
feature is enabled and the pname:pNext chain of
slink:VkPipelineVertexInputStateCreateInfo includes a
sname:VkPipelineVertexInputDivisorStateCreateInfoEXT structure, then that
structure controls how vertex attributes are assigned to an instance when
instanced rendering is enabled.
The sname:VkPipelineVertexInputDivisorStateCreateInfoEXT structure is
defined as:
@ -497,6 +500,11 @@ include::../api/structs/VkVertexInputBindingDivisorDescriptionEXT.txt[]
The maximum value of divisor is implementation dependent and can be
queried using
sname:VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT::pname:maxVertexAttribDivisor.
A value of `0` can: be used for the divisor if the
<<features-features-vertexAttributeInstanceRateZeroDivisor,pname:vertexAttributeInstanceRateZeroDivisor>>
feature is enabled.
In this case, the same vertex attribute will be applied to all
instances.
If this structure is not used to define a divisor value for an attribute
then the divisor has a logical default value of 1.
@ -506,8 +514,14 @@ then the divisor has a logical default value of 1.
* [[VUID-VkVertexInputBindingDivisorDescriptionEXT-binding-01869]]
pname:binding must: be less than
sname:VkPhysicalDeviceLimits::pname:maxVertexInputBindings
* [[VUID-VkVertexInputBindingDivisorDescriptionEXT-vertexAttributeInstanceRateZeroDivisor-02228]]
If the pname:vertexAttributeInstanceRateZeroDivisor feature is not
enabled, pname:divisor must: not be `0`
* [[VUID-VkVertexInputBindingDivisorDescriptionEXT-vertexAttributeInstanceRateDivisor-02229]]
If the pname:vertexAttributeInstanceRateDivisor feature is not enabled,
pname:divisor must: be `1`
* [[VUID-VkVertexInputBindingDivisorDescriptionEXT-divisor-01870]]
pname:divisor must: be a value between `1` and
pname:divisor must: be a value between `0` and
sname:VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT::pname:maxVertexAttribDivisor,
inclusive.
* [[VUID-VkVertexInputBindingDivisorDescriptionEXT-inputRate-01871]]
@ -555,7 +569,10 @@ ifndef::VK_EXT_vertex_attribute_divisor[]
vertexOffset = instanceIndex * bindingDesc.stride;
endif::VK_EXT_vertex_attribute_divisor[]
ifdef::VK_EXT_vertex_attribute_divisor[]
vertexOffset = (firstInstance + ((instanceIndex - firstInstance) / divisor)) * bindingDesc.stride;
if (divisor == 0)
vertexOffset = firstInstance * bindingDesc.stride;
else
vertexOffset = (firstInstance + ((instanceIndex - firstInstance) / divisor)) * bindingDesc.stride;
endif::VK_EXT_vertex_attribute_divisor[]
attribAddress = bufferBindingAddress + vertexOffset + attribDesc.offset;

27
chapters/interfaces.txt
View File

@ -563,6 +563,18 @@ for that variable to extend outside the range [eq]#[0,
pname:maxStorageBufferRange)#.
endif::VK_VERSION_1_1,VK_KHR_storage_buffer_storage_class[]
ifdef::VK_EXT_inline_uniform_block[]
Variables identified with the code:Uniform storage class can: also be used
to access transparent descriptor set backed resources when the variable is
assigned to a descriptor set layout binding with a pname:descriptorType of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK.
In this case the variable must: be typed as code:OpTypeStruct and cannot: be
aggregated into arrays of that type.
Further, the code:Offset decoration for any member of such a variable must:
not cause the space required for that variable to extend outside the range
[eq]#[0,maxInlineUniformBlockSize)#.
endif::VK_EXT_inline_uniform_block[]
Variables identified with a storage class of code:UniformConstant and a
decoration of code:InputAttachmentIndex must: be declared as described in
<<interfaces-inputattachment,Fragment Input Attachment Interface>>.
@ -661,6 +673,9 @@ endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
| storage buffer | ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC
| input attachment | ename:VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT
ifdef::VK_EXT_inline_uniform_block[]
| inline uniform block | ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT
endif::VK_EXT_inline_uniform_block[]
|====
[[interfaces-resources-storage-class-correspondence]]
@ -699,6 +714,11 @@ endif::VK_VERSION_1_1,VK_KHR_storage_buffer_storage_class[]
| input attachment
| code:UniformConstant | code:OpTypeImage (code:Dim=code:SubpassData, code:Sampled=2)
| code:InputAttachmentIndex
ifdef::VK_EXT_inline_uniform_block[]
| inline uniform block
| code:Uniform | code:OpTypeStruct
| code:Block, code:Offset, (code:ArrayStride), (code:MatrixStride)
endif::VK_EXT_inline_uniform_block[]
|====
1:: in addition to code:DescriptorSet and code:Binding
@ -834,6 +854,13 @@ ifdef::VK_EXT_descriptor_indexing[]
or pname:maxPerStageDescriptorUpdateAfterBindInputAttachments
endif::VK_EXT_descriptor_indexing[]
| input attachment^1^
ifdef::VK_EXT_inline_uniform_block[]
| pname:maxPerStageDescriptorInlineUniformBlocks
ifdef::VK_EXT_descriptor_indexing[]
or pname:maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks
endif::VK_EXT_descriptor_indexing[]
| inline uniform block
endif::VK_EXT_inline_uniform_block[]
|====
1::

15
chapters/memory.txt
View File

@ -2436,9 +2436,10 @@ include::../api/protos/vkFlushMappedMemoryRanges.txt[]
flush.
fname:vkFlushMappedMemoryRanges guarantees that host writes to the memory
ranges described by pname:pMemoryRanges can: be made available to device
access, via <<synchronization-dependencies-available-and-visible,
availability operations>> from the ename:VK_ACCESS_HOST_WRITE_BIT
ranges described by pname:pMemoryRanges are made available to the host
memory domain, such that they can: be made available to the device memory
domain via <<synchronization-dependencies-available-and-visible, memory
domain operations>> using the ename:VK_ACCESS_HOST_WRITE_BIT
<<synchronization-access-types,access type>>.
Within each range described by pname:pMemoryRanges, each set of
@ -2482,10 +2483,10 @@ include::../api/protos/vkInvalidateMappedMemoryRanges.txt[]
invalidate.
fname:vkInvalidateMappedMemoryRanges guarantees that device writes to the
memory ranges described by pname:pMemoryRanges, which have been made visible
to the ename:VK_ACCESS_HOST_WRITE_BIT and ename:VK_ACCESS_HOST_READ_BIT
<<synchronization-access-types, access types>>, are made visible to the
host.
memory ranges described by pname:pMemoryRanges, which have been made
available to the host memory domain using the ename:VK_ACCESS_HOST_WRITE_BIT
and ename:VK_ACCESS_HOST_READ_BIT <<synchronization-access-types, access
types>>, are made visible to the host.
If a range of non-coherent memory is written by the host and then
invalidated without first being flushed, its contents are undefined.

73
chapters/resources.txt
View File

@ -2837,6 +2837,76 @@ That is:
--
ifdef::VK_EXT_astc_decode_mode[]
[open,refpage='VkImageViewASTCDecodeModeEXT',desc='Structure describing the ASTC decode mode for an image view',type='structs']
--
If the pname:pNext list includes a sname:VkImageViewASTCDecodeModeEXT
structure, then that structure includes a parameter that specifies the
decode mode for image views using ASTC compressed formats.
The sname:VkImageViewASTCDecodeModeEXT structure is defined as:
include::../api/structs/VkImageViewASTCDecodeModeEXT.txt[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:decodeMode is the intermediate format used to decode ASTC
compressed formats.
.Valid Usage
****
* [[VUID-VkImageViewASTCDecodeModeEXT-decodeMode-02230]]
pname:decodeMode must: be one of ename:VK_FORMAT_R16G16B16A16_SFLOAT,
ename:VK_FORMAT_R8G8B8A8_UNORM, or
ename:VK_FORMAT_E5B9G9R9_UFLOAT_PACK32
* [[VUID-VkImageViewASTCDecodeModeEXT-decodeMode-02231]]
If the <<features-features-astc-decodeModeSharedExponent,
decodeModeSharedExponent>> feature is not enabled, pname:decodeMode
must: not be ename:VK_FORMAT_E5B9G9R9_UFLOAT_PACK32
* [[VUID-VkImageViewASTCDecodeModeEXT-decodeMode-02232]]
If pname:decodeMode is ename:VK_FORMAT_R8G8B8A8_UNORM the image view
must: not include blocks using any of the ASTC HDR modes
* [[VUID-VkImageViewASTCDecodeModeEXT-format-02233]]
pname:format of the image view must: be one of
ename:VK_FORMAT_ASTC_4x4_UNORM_BLOCK,
ename:VK_FORMAT_ASTC_4x4_SRGB_BLOCK,
ename:VK_FORMAT_ASTC_5x4_UNORM_BLOCK,
ename:VK_FORMAT_ASTC_5x4_SRGB_BLOCK,
ename:VK_FORMAT_ASTC_5x5_UNORM_BLOCK,
ename:VK_FORMAT_ASTC_5x5_SRGB_BLOCK,
ename:VK_FORMAT_ASTC_6x5_UNORM_BLOCK,
ename:VK_FORMAT_ASTC_6x5_SRGB_BLOCK,
ename:VK_FORMAT_ASTC_6x6_UNORM_BLOCK,
ename:VK_FORMAT_ASTC_6x6_SRGB_BLOCK,
ename:VK_FORMAT_ASTC_8x5_UNORM_BLOCK,
ename:VK_FORMAT_ASTC_8x5_SRGB_BLOCK,
ename:VK_FORMAT_ASTC_8x6_UNORM_BLOCK,
ename:VK_FORMAT_ASTC_8x6_SRGB_BLOCK,
ename:VK_FORMAT_ASTC_8x8_UNORM_BLOCK,
ename:VK_FORMAT_ASTC_8x8_SRGB_BLOCK,
ename:VK_FORMAT_ASTC_10x5_UNORM_BLOCK,
ename:VK_FORMAT_ASTC_10x5_SRGB_BLOCK,
ename:VK_FORMAT_ASTC_10x6_UNORM_BLOCK,
ename:VK_FORMAT_ASTC_10x6_SRGB_BLOCK,
ename:VK_FORMAT_ASTC_10x8_UNORM_BLOCK,
ename:VK_FORMAT_ASTC_10x8_SRGB_BLOCK,
ename:VK_FORMAT_ASTC_10x10_UNORM_BLOCK,
ename:VK_FORMAT_ASTC_10x10_SRGB_BLOCK,
ename:VK_FORMAT_ASTC_12x10_UNORM_BLOCK,
ename:VK_FORMAT_ASTC_12x10_SRGB_BLOCK,
ename:VK_FORMAT_ASTC_12x12_UNORM_BLOCK, or
ename:VK_FORMAT_ASTC_12x12_SRGB_BLOCK
****
If pname:format uses sRGB encoding then the pname:decodeMode has no effect.
include::../validity/structs/VkImageViewASTCDecodeModeEXT.txt[]
--
endif::VK_EXT_astc_decode_mode[]
[open,refpage='vkDestroyImageView',desc='Destroy an image view object',type='protos']
--
@ -4587,9 +4657,6 @@ render pass must: declare the attachments using the
<<renderpass-aliasing,ename:VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT>>, and
follow the other rules listed in that section.
Access to resources which alias memory from shaders using variables
decorated with code:Coherent are not automatically coherent with each other.
[NOTE]
.Note
====

14
chapters/shaders.txt
View File

@ -251,6 +251,19 @@ assumes that the other invocation has been launched and will complete its
writes in finite time.
====
ifdef::VK_KHR_vulkan_memory_model[]
The <<memory-model,Memory Model>> appendix defines the terminology and rules
for how to correctly communicate between shader invocations, such as when a
write is <<memory-model-visible-to,Visible-To>> a read, and what constitutes
a <<memory-model-access-data-race,Data Race>>.
Applications must: not cause a data race.
endif::VK_KHR_vulkan_memory_model[]
ifndef::VK_KHR_vulkan_memory_model[]
Stores issued to different memory locations within a single shader
invocation may: not be visible to other invocations, or may: not become
visible in the order they were performed.
@ -319,6 +332,7 @@ Atomics allow shaders to use shared global addresses for mutual exclusion or
as counters, among other uses.
====
endif::VK_KHR_vulkan_memory_model[]
[[shaders-inputs]]
== Shader Inputs and Outputs

51
chapters/synchronization.txt
View File

@ -119,14 +119,27 @@ resulting from writes in one set of operations can: be read from another set
of operations.
[[synchronization-dependencies-available-and-visible]]
Two additional types of operation are used to control memory access.
Three additional types of operation are used to control memory access.
_Availability operations_ cause the values generated by specified memory
write accesses to become _available_ for future access.
write accesses to become _available_ to a memory domain for future access.
Any available value remains available until a subsequent write to the same
memory location occurs (whether it is made available or not) or the memory
is freed.
_Visibility operations_ cause any available values to become _visible_ to
specified memory accesses.
_Memory domain operations_ cause writes that are available to a source
memory domain to become available to a destination memory domain (an example
of this is making writes available to the host domain available to the
device domain).
_Visibility operations_ cause values available to a memory domain to become
_visible_ to specified memory accesses.
ifdef::VK_KHR_vulkan_memory_model[]
Availability, visibility, memory domains, and memory domain operations are
formally defined in the <<memory-model-availability-visibility,Availability
and Visibility>> section of the <<memory-model,Memory Model>> chapter.
Which API operations perform each of these operations is defined in
<<memory-model-vulkan-availability-visibility,Availability, Visibility, and
Domain Operations>>.
endif::VK_KHR_vulkan_memory_model[]
[[synchronization-dependencies-memory]]
A _memory dependency_ is an execution dependency which includes availability
@ -732,31 +745,27 @@ endif::VK_EXT_conditional_rendering[]
If a memory object does not have the
ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT property, then
flink:vkFlushMappedMemoryRanges must: be called in order to guarantee that
writes to the memory object from the host are made visible to the
ename:VK_ACCESS_HOST_WRITE_BIT <<synchronization-access-types, access
type>>, where it can: be further made available to the device by
<<synchronization, synchronization commands>>.
writes to the memory object from the host are made available to the host
domain, where they can: be further made available to the device domain via a
domain operation.
Similarly, flink:vkInvalidateMappedMemoryRanges must: be called to guarantee
that writes which are visible to the ename:VK_ACCESS_HOST_READ_BIT
<<synchronization-access-types, access type>> are made visible to host
that writes which are available to the host domain are made visible to host
operations.
If the memory object does have the
ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT property flag, writes to the
memory object from the host are automatically made visible to the
ename:VK_ACCESS_HOST_WRITE_BIT <<synchronization-access-types,access type>>.
Similarly, writes made visible to the ename:VK_ACCESS_HOST_READ_BIT
<<synchronization-access-types, access type>> are automatically made visible
to the host.
memory object from the host are automatically made available to the host
domain.
Similarly, writes made available to the host domain are automatically made
visible to the host.
[NOTE]
.Note
====
The flink:vkQueueSubmit command <<synchronization-submission-host-writes,
automatically guarantees that host writes flushed to
ename:VK_ACCESS_HOST_WRITE_BIT are made available>> if they were flushed
before the command executed, so in most cases an explicit memory barrier is
not needed for this case.
automatically performs a domain operation from host to device>> for all
writes performed before the command executes, so in most cases an explicit
memory barrier is not needed for this case.
In the few circumstances where a submit does not occur between the host
write and the device read access, writes can: be made available by using an
explicit memory barrier.
@ -4227,8 +4236,8 @@ queue submission>>, and all commands that occur later in
<<synchronization-submission-order,submission order>>.
The first <<synchronization-dependencies-access-scopes, access scope>>
includes all host writes to mappable device memory that are either coherent,
or have been flushed with flink:vkFlushMappedMemoryRanges.
includes all host writes to mappable device memory that are available to the
host memory domain.
The second <<synchronization-dependencies-access-scopes, access scope>>
includes all memory access performed by the device.

6
chapters/textures.txt
View File

@ -578,9 +578,9 @@ elink:VkFormat), using the appropriate equations in
<<textures-sexp-RGB,Shared Exponent to RGB>>.
Signed integer components smaller than 32 bits are sign-extended.
If the image view format is sRGB, the color components are first converted as if
they are UNORM, and then sRGB to linear conversion is applied to the R, G,
and B components as described in the "`sRGB EOTF`" section of the
If the image view format is sRGB, the color components are first converted
as if they are UNORM, and then sRGB to linear conversion is applied to the
R, G, and B components as described in the "`sRGB EOTF`" section of the
<<data-format,Khronos Data Format Specification>>.
The A component, if present, is unchanged.

87
include/vulkan/vulkan_core.h
View File

@ -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 83
#define VK_HEADER_VERSION 84
#define VK_NULL_HANDLE 0
@ -305,6 +305,8 @@ typedef enum VkStructureType {
VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_NV = 1000058000,
VK_STRUCTURE_TYPE_VALIDATION_FLAGS_EXT = 1000061000,
VK_STRUCTURE_TYPE_VI_SURFACE_CREATE_INFO_NN = 1000062000,
VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT = 1000067000,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ASTC_DECODE_FEATURES_EXT = 1000067001,
VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR = 1000073000,
VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_KHR = 1000073001,
VK_STRUCTURE_TYPE_MEMORY_WIN32_HANDLE_PROPERTIES_KHR = 1000073002,
@ -380,6 +382,10 @@ typedef enum VkStructureType {
VK_STRUCTURE_TYPE_EXTERNAL_FORMAT_ANDROID = 1000129005,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_FILTER_MINMAX_PROPERTIES_EXT = 1000130000,
VK_STRUCTURE_TYPE_SAMPLER_REDUCTION_MODE_CREATE_INFO_EXT = 1000130001,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_FEATURES_EXT = 1000138000,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_PROPERTIES_EXT = 1000138001,
VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT = 1000138002,
VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_INLINE_UNIFORM_BLOCK_CREATE_INFO_EXT = 1000138003,
VK_STRUCTURE_TYPE_SAMPLE_LOCATIONS_INFO_EXT = 1000143000,
VK_STRUCTURE_TYPE_RENDER_PASS_SAMPLE_LOCATIONS_BEGIN_INFO_EXT = 1000143001,
VK_STRUCTURE_TYPE_PIPELINE_SAMPLE_LOCATIONS_STATE_CREATE_INFO_EXT = 1000143002,
@ -406,8 +412,10 @@ typedef enum VkStructureType {
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_AMD = 1000185000,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT = 1000190000,
VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_EXT = 1000190001,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT = 1000190002,
VK_STRUCTURE_TYPE_CHECKPOINT_DATA_NV = 1000206000,
VK_STRUCTURE_TYPE_QUEUE_FAMILY_CHECKPOINT_PROPERTIES_NV = 1000206001,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR = 1000211000,
VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT = VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,
VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO_KHR = VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHR = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES,
@ -1122,6 +1130,7 @@ typedef enum VkDescriptorType {
VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC = 8,
VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC = 9,
VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT = 10,
VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT = 1000138000,
VK_DESCRIPTOR_TYPE_BEGIN_RANGE = VK_DESCRIPTOR_TYPE_SAMPLER,
VK_DESCRIPTOR_TYPE_END_RANGE = VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT,
VK_DESCRIPTOR_TYPE_RANGE_SIZE = (VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT - VK_DESCRIPTOR_TYPE_SAMPLER + 1),
@ -5983,6 +5992,19 @@ typedef struct VkPhysicalDevice8BitStorageFeaturesKHR {
#define VK_KHR_vulkan_memory_model 1
#define VK_KHR_VULKAN_MEMORY_MODEL_SPEC_VERSION 2
#define VK_KHR_VULKAN_MEMORY_MODEL_EXTENSION_NAME "VK_KHR_vulkan_memory_model"
typedef struct VkPhysicalDeviceVulkanMemoryModelFeaturesKHR {
VkStructureType sType;
void* pNext;
VkBool32 vulkanMemoryModel;
VkBool32 vulkanMemoryModelDeviceScope;
} VkPhysicalDeviceVulkanMemoryModelFeaturesKHR;
#define VK_EXT_debug_report 1
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkDebugReportCallbackEXT)
@ -6433,6 +6455,24 @@ typedef struct VkValidationFlagsEXT {
#define VK_EXT_SHADER_SUBGROUP_VOTE_EXTENSION_NAME "VK_EXT_shader_subgroup_vote"
#define VK_EXT_astc_decode_mode 1
#define VK_EXT_ASTC_DECODE_MODE_SPEC_VERSION 1
#define VK_EXT_ASTC_DECODE_MODE_EXTENSION_NAME "VK_EXT_astc_decode_mode"
typedef struct VkImageViewASTCDecodeModeEXT {
VkStructureType sType;
const void* pNext;
VkFormat decodeMode;
} VkImageViewASTCDecodeModeEXT;
typedef struct VkPhysicalDeviceASTCDecodeFeaturesEXT {
VkStructureType sType;
void* pNext;
VkBool32 decodeModeSharedExponent;
} VkPhysicalDeviceASTCDecodeFeaturesEXT;
#define VK_EXT_conditional_rendering 1
#define VK_EXT_CONDITIONAL_RENDERING_SPEC_VERSION 1
#define VK_EXT_CONDITIONAL_RENDERING_EXTENSION_NAME "VK_EXT_conditional_rendering"
@ -7301,6 +7341,42 @@ typedef struct VkPhysicalDeviceSamplerFilterMinmaxPropertiesEXT {
#define VK_AMD_SHADER_FRAGMENT_MASK_EXTENSION_NAME "VK_AMD_shader_fragment_mask"
#define VK_EXT_inline_uniform_block 1
#define VK_EXT_INLINE_UNIFORM_BLOCK_SPEC_VERSION 1
#define VK_EXT_INLINE_UNIFORM_BLOCK_EXTENSION_NAME "VK_EXT_inline_uniform_block"
typedef struct VkPhysicalDeviceInlineUniformBlockFeaturesEXT {
VkStructureType sType;
void* pNext;
VkBool32 inlineUniformBlock;
VkBool32 descriptorBindingInlineUniformBlockUpdateAfterBind;
} VkPhysicalDeviceInlineUniformBlockFeaturesEXT;
typedef struct VkPhysicalDeviceInlineUniformBlockPropertiesEXT {
VkStructureType sType;
void* pNext;
uint32_t maxInlineUniformBlockSize;
uint32_t maxPerStageDescriptorInlineUniformBlocks;
uint32_t maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks;
uint32_t maxDescriptorSetInlineUniformBlocks;
uint32_t maxDescriptorSetUpdateAfterBindInlineUniformBlocks;
} VkPhysicalDeviceInlineUniformBlockPropertiesEXT;
typedef struct VkWriteDescriptorSetInlineUniformBlockEXT {
VkStructureType sType;
const void* pNext;
uint32_t dataSize;
const void* pData;
} VkWriteDescriptorSetInlineUniformBlockEXT;
typedef struct VkDescriptorPoolInlineUniformBlockCreateInfoEXT {
VkStructureType sType;
const void* pNext;
uint32_t maxInlineUniformBlockBindings;
} VkDescriptorPoolInlineUniformBlockCreateInfoEXT;
#define VK_EXT_shader_stencil_export 1
#define VK_EXT_SHADER_STENCIL_EXPORT_SPEC_VERSION 1
#define VK_EXT_SHADER_STENCIL_EXPORT_EXTENSION_NAME "VK_EXT_shader_stencil_export"
@ -7734,7 +7810,7 @@ typedef struct VkPhysicalDeviceShaderCorePropertiesAMD {
#define VK_EXT_vertex_attribute_divisor 1
#define VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_SPEC_VERSION 2
#define VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_SPEC_VERSION 3
#define VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_EXTENSION_NAME "VK_EXT_vertex_attribute_divisor"
typedef struct VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT {
@ -7755,6 +7831,13 @@ typedef struct VkPipelineVertexInputDivisorStateCreateInfoEXT {
const VkVertexInputBindingDivisorDescriptionEXT* pVertexBindingDivisors;
} VkPipelineVertexInputDivisorStateCreateInfoEXT;
typedef struct VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT {
VkStructureType sType;
void* pNext;
VkBool32 vertexAttributeInstanceRateDivisor;
VkBool32 vertexAttributeInstanceRateZeroDivisor;
} VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT;
#define VK_NV_shader_subgroup_partitioned 1

2
reflow_count.py
View File

@ -1,2 +1,2 @@
# The value to start tagging VU statements at, unless overridden by -nextvu
startVUID = 2027
startVUID = 2234

2
registry.txt
View File

@ -2004,6 +2004,8 @@ files and Python scripts are logged in Github history.
[[changelog]]
= Change Log
* 2018-08-28 - Add optional attr:provisional attribute to tag:extension
tags.
* 2018-07-07 - Add optional attr:promotedto, attr:deprecatedby, and
attr:obsoletedby attributes to tag:extension tags.
* 2018-06-25 - Remove attr:vendorids tags for Khronos vendor IDs.

1
style/writing.txt
View File

@ -480,6 +480,7 @@ cell separator must be `a|` instead of just `|`:
p_2(A_s,A_d) & = A_d(1-A_s) \\
\end{aligned}
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|====
----

4
vkspec.txt
View File

@ -119,6 +119,10 @@ include::chapters/debugging.txt[]
include::appendices/spirvenv.txt[]
ifdef::VK_KHR_vulkan_memory_model[]
include::appendices/memorymodel.txt[]
endif::VK_KHR_vulkan_memory_model[]
include::appendices/compressedtex.txt[]
ifdef::VK_VERSION_1_1[]

28
xml/extensionmetadocgenerator.py
View File

@ -52,6 +52,7 @@ class Extension:
promotedTo,
deprecatedBy,
obsoletedBy,
provisional,
revision ):
self.generator = generator
self.filename = filename
@ -64,6 +65,7 @@ class Extension:
self.promotedTo = promotedTo
self.deprecatedBy = deprecatedBy
self.obsoletedBy = obsoletedBy
self.provisional = provisional
self.revision = revision
self.deprecationType = None
@ -279,6 +281,7 @@ class Extension:
# or empty string if deprecated without replacement
# obsoletedBy extension or Vulkan version which obsoleted this extension,
# or empty string if obsoleted without replacement
# provisional 'true' if this extension is released provisionally
#
# ---- methods ----
# ExtensionMetaDocOutputGenerator(errFile, warnFile, diagFile) - args as for
@ -367,6 +370,10 @@ class ExtensionMetaDocOutputGenerator(OutputGenerator):
deprecated_extension_appendices_fp = self.newFile(self.directory + '/deprecated_extension_appendices.txt')
deprecated_extension_appendices_toc_fp = self.newFile(self.directory + '/deprecated_extension_appendices_toc.txt')
deprecated_extensions_guard_macro_fp = self.newFile(self.directory + '/deprecated_extensions_guard_macro.txt')
provisional_extensions_appendix_fp = self.newFile(self.directory + '/provisional_extensions_appendix.txt')
provisional_extension_appendices_fp = self.newFile(self.directory + '/provisional_extension_appendices.txt')
provisional_extension_appendices_toc_fp = self.newFile(self.directory + '/provisional_extension_appendices_toc.txt')
provisional_extensions_guard_macro_fp = self.newFile(self.directory + '/provisional_extensions_guard_macro.txt')
write('include::deprecated_extensions_guard_macro.txt[]', file=current_extensions_appendix_fp)
write('', file=current_extensions_appendix_fp)
@ -396,12 +403,28 @@ class ExtensionMetaDocOutputGenerator(OutputGenerator):
# add include guard to allow multiple includes
write('ifndef::DEPRECATED_EXTENSIONS_GUARD_MACRO_INCLUDE_GUARD[]', file=deprecated_extensions_guard_macro_fp)
write(':DEPRECATED_EXTENSIONS_GUARD_MACRO_INCLUDE_GUARD:\n', file=deprecated_extensions_guard_macro_fp)
write('ifndef::PROVISIONAL_EXTENSIONS_GUARD_MACRO_INCLUDE_GUARD[]', file=provisional_extensions_guard_macro_fp)
write(':PROVISIONAL_EXTENSIONS_GUARD_MACRO_INCLUDE_GUARD:\n', file=provisional_extensions_guard_macro_fp)
write('include::provisional_extensions_guard_macro.txt[]', file=provisional_extensions_appendix_fp)
write('', file=provisional_extensions_appendix_fp)
write('ifdef::HAS_PROVISIONAL_EXTENSIONS[]', file=provisional_extensions_appendix_fp)
write('[[provisional-extension-appendices-list]]', file=provisional_extensions_appendix_fp)
write('== List of Provisional Extensions', file=provisional_extensions_appendix_fp)
write('include::provisional_extension_appendices_toc.txt[]', file=provisional_extensions_appendix_fp)
write('<<<', file=provisional_extensions_appendix_fp)
write('include::provisional_extension_appendices.txt[]', file=provisional_extensions_appendix_fp)
write('endif::HAS_PROVISIONAL_EXTENSIONS[]', file=provisional_extensions_appendix_fp)
for ext in self.extensions:
include = 'include::../' + ext.name + '.txt[]'
link = ' * <<' + ext.name + '>>'
if ext.deprecationType is None:
if ext.provisional == 'true':
write(self.conditionalExt(ext.name, include), file=provisional_extension_appendices_fp)
write(self.conditionalExt(ext.name, link), file=provisional_extension_appendices_toc_fp)
write(self.conditionalExt(ext.name, ':HAS_PROVISIONAL_EXTENSIONS:'), file=provisional_extensions_guard_macro_fp)
elif ext.deprecationType is None:
write(self.conditionalExt(ext.name, include), file=current_extension_appendices_fp)
write(self.conditionalExt(ext.name, link), file=current_extension_appendices_toc_fp)
else:
@ -449,10 +472,11 @@ class ExtensionMetaDocOutputGenerator(OutputGenerator):
promotedTo = self.getAttrib(interface, 'promotedto', OPTIONAL)
deprecatedBy = self.getAttrib(interface, 'deprecatedby', OPTIONAL)
obsoletedBy = self.getAttrib(interface, 'obsoletedby', OPTIONAL)
provisional = self.getAttrib(interface, 'provisional', OPTIONAL, 'false')
filename = self.directory + '/' + name + '.txt'
self.extensions.append( Extension(self, filename, name, number, type, requires, requiresCore, contact, promotedTo, deprecatedBy, obsoletedBy, revision) )
self.extensions.append( Extension(self, filename, name, number, type, requires, requiresCore, contact, promotedTo, deprecatedBy, obsoletedBy, provisional, revision) )
def endFeature(self):
# Finish processing in superclass

2
xml/registry.rnc
View File

@ -414,6 +414,7 @@ Extensions = element extensions {
# obsoletedby - Vulkan version or a name of an extension that obsoletes
# this extension. It may be empty string.
# e.g. 'VK_VERSION_1_1', or 'VK_EXT_debug_utils', or ''
# provisional - 'true' if this extension is released provisionally
# In addition, <require> / <remove> tags also support an api attribute:
# api - only require/remove these features for the matching API.
# Not a regular expression.
@ -431,6 +432,7 @@ Extension = element extension {
attribute promotedto { text } ? ,
attribute deprecatedby { text } ? ,
attribute obsoletedby { text } ? ,
attribute provisional { text } ? ,
Comment ? ,
(
element require {

127
xml/vk.xml
View File

@ -147,7 +147,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> 83</type>
#define <name>VK_HEADER_VERSION</name> 84</type>
<type category="define">
#define <name>VK_DEFINE_HANDLE</name>(object) typedef struct object##_T* object;</type>
@ -2796,7 +2796,7 @@ server.
<member>const <type>void</type>* <name>pNext</name></member>
<member><type>VkSamplerReductionModeEXT</type> <name>reductionMode</name></member>
</type>
<type category="struct" name="VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT" structextends="VkPhysicalDeviceFeatures2">
<type category="struct" name="VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT" structextends="VkPhysicalDeviceFeatures2,VkDeviceCreateInfo">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BLEND_OPERATION_ADVANCED_FEATURES_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member noautovalidity="true"><type>void</type>* <name>pNext</name></member>
<member><type>VkBool32</type> <name>advancedBlendCoherentOperations</name></member>
@ -2818,6 +2818,32 @@ server.
<member><type>VkBool32</type> <name>dstPremultiplied</name></member>
<member><type>VkBlendOverlapEXT</type> <name>blendOverlap</name></member>
</type>
<type category="struct" name="VkPhysicalDeviceInlineUniformBlockFeaturesEXT" returnedonly="true" structextends="VkPhysicalDeviceFeatures2,VkDeviceCreateInfo">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_FEATURES_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member><type>void</type>* <name>pNext</name></member>
<member><type>VkBool32</type> <name>inlineUniformBlock</name></member>
<member><type>VkBool32</type> <name>descriptorBindingInlineUniformBlockUpdateAfterBind</name></member>
</type>
<type category="struct" name="VkPhysicalDeviceInlineUniformBlockPropertiesEXT" returnedonly="true" structextends="VkPhysicalDeviceProperties2">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_PROPERTIES_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member><type>void</type>* <name>pNext</name></member>
<member><type>uint32_t</type> <name>maxInlineUniformBlockSize</name></member>
<member><type>uint32_t</type> <name>maxPerStageDescriptorInlineUniformBlocks</name></member>
<member><type>uint32_t</type> <name>maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks</name></member>
<member><type>uint32_t</type> <name>maxDescriptorSetInlineUniformBlocks</name></member>
<member><type>uint32_t</type> <name>maxDescriptorSetUpdateAfterBindInlineUniformBlocks</name></member>
</type>
<type category="struct" name="VkWriteDescriptorSetInlineUniformBlockEXT">
<member values="VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member>const <type>void</type>* <name>pNext</name></member>
<member><type>uint32_t</type> <name>dataSize</name></member>
<member len="dataSize">const <type>void</type>* <name>pData</name></member>
</type>
<type category="struct" name="VkDescriptorPoolInlineUniformBlockCreateInfoEXT" structextends="VkDescriptorPoolCreateInfo">
<member values="VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_INLINE_UNIFORM_BLOCK_CREATE_INFO_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member>const <type>void</type>* <name>pNext</name></member>
<member><type>uint32_t</type> <name>maxInlineUniformBlockBindings</name></member>
</type>
<type category="struct" name="VkPipelineCoverageModulationStateCreateInfoNV" structextends="VkPipelineMultisampleStateCreateInfo">
<member values="VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_MODULATION_STATE_CREATE_INFO_NV"><type>VkStructureType</type> <name>sType</name></member>
<member>const <type>void</type>* <name>pNext</name></member>
@ -2858,7 +2884,7 @@ server.
<member><type>VkBool32</type> <name>supported</name></member>
</type>
<type category="struct" name="VkDescriptorSetLayoutSupportKHR" alias="VkDescriptorSetLayoutSupport"/>
<type category="struct" name="VkPhysicalDeviceShaderDrawParameterFeatures" structextends="VkPhysicalDeviceFeatures2">
<type category="struct" name="VkPhysicalDeviceShaderDrawParameterFeatures" structextends="VkPhysicalDeviceFeatures2,VkDeviceCreateInfo">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_DRAW_PARAMETER_FEATURES"><type>VkStructureType</type> <name>sType</name></member>
<member noautovalidity="true"><type>void</type>* <name>pNext</name></member>
<member><type>VkBool32</type> <name>shaderDrawParameters</name></member>
@ -3199,6 +3225,18 @@ server.
<member><type>VkBool32</type> <name>conditionalRendering</name></member>
<member><type>VkBool32</type> <name>inheritedConditionalRendering</name></member>
</type>
<type category="struct" name="VkPhysicalDeviceVulkanMemoryModelFeaturesKHR" returnedonly="true" structextends="VkPhysicalDeviceFeatures2,VkDeviceCreateInfo">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR"><type>VkStructureType</type> <name>sType</name></member>
<member noautovalidity="true"><type>void</type>* <name>pNext</name></member>
<member><type>VkBool32</type> <name>vulkanMemoryModel</name></member>
<member><type>VkBool32</type> <name>vulkanMemoryModelDeviceScope</name></member>
</type>
<type category="struct" name="VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT" structextends="VkPhysicalDeviceFeatures2,VkDeviceCreateInfo">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member noautovalidity="true"><type>void</type>* <name>pNext</name></member>
<member><type>VkBool32</type> <name>vertexAttributeInstanceRateDivisor</name></member>
<member><type>VkBool32</type> <name>vertexAttributeInstanceRateZeroDivisor</name></member>
</type>
<type category="struct" name="VkQueueFamilyCheckpointPropertiesNV" structextends="VkQueueFamilyProperties2" returnedonly="true">
<member values="VK_STRUCTURE_TYPE_QUEUE_FAMILY_CHECKPOINT_PROPERTIES_NV"><type>VkStructureType</type> <name>sType</name></member>
<member><type>void</type>* <name>pNext</name></member>
@ -3210,6 +3248,16 @@ server.
<member><type>VkPipelineStageFlagBits</type> <name>stage</name></member>
<member noautovalidity="true"><type>void</type>* <name>pCheckpointMarker</name></member>
</type>
<type category="struct" name="VkImageViewASTCDecodeModeEXT" structextends="VkImageViewCreateInfo">
<member values="VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member>const <type>void</type>* <name>pNext</name></member>
<member><type>VkFormat</type> <name>decodeMode</name></member>
</type>
<type category="struct" name="VkPhysicalDeviceASTCDecodeFeaturesEXT" structextends="VkPhysicalDeviceFeatures2,VkDeviceCreateInfo">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ASTC_DECODE_FEATURES_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member noautovalidity="true"><type>void</type>* <name>pNext</name></member>
<member><type>VkBool32</type> <name>decodeModeSharedExponent</name></member>
</type>
</types>
<comment>Vulkan enumerant (token) definitions</comment>
@ -7493,10 +7541,14 @@ server.
<enum value="&quot;VK_ARM_extension_01&quot;" name="VK_ARM_EXTENSION_01_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_ARM_extension_02" number="68" type="device" author="ARM" contact="Jan-Harald Fredriksen @janharaldfredriksen-arm" supported="disabled">
<extension name="VK_EXT_astc_decode_mode" number="68" type="device" author="ARM" contact="Jan-Harald Fredriksen @janharaldfredriksen-arm" requires="VK_KHR_get_physical_device_properties2" supported="vulkan">
<require>
<enum value="0" name="VK_ARM_EXTENSION_02_SPEC_VERSION"/>
<enum value="&quot;VK_ARM_extension_02&quot;" name="VK_ARM_EXTENSION_02_EXTENSION_NAME"/>
<enum value="1" name="VK_EXT_ASTC_DECODE_MODE_SPEC_VERSION"/>
<enum value="&quot;VK_EXT_astc_decode_mode&quot;" name="VK_EXT_ASTC_DECODE_MODE_EXTENSION_NAME"/>
<enum offset="0" extends="VkStructureType" name="VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT"/>
<enum offset="1" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ASTC_DECODE_FEATURES_EXT"/>
<type name="VkImageViewASTCDecodeModeEXT"/>
<type name="VkPhysicalDeviceASTCDecodeFeaturesEXT"/>
</require>
</extension>
<extension name="VK_IMG_extension_69" number="69" type="device" author="IMG" contact="Tobias Hector @tobski" supported="disabled">
@ -8344,10 +8396,19 @@ server.
<enum value="&quot;VK_AMD_shader_fragment_mask&quot;" name="VK_AMD_SHADER_FRAGMENT_MASK_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_139" number="139" author="AMD" contact="Mais Alnasser @malnasse" supported="disabled">
<extension name="VK_EXT_inline_uniform_block" number="139" type="device" author="EXT" requires="VK_KHR_get_physical_device_properties2,VK_KHR_maintenance1" contact="Daniel Rakos @aqnuep" supported="vulkan">
<require>
<enum value="0" name="VK_AMD_EXTENSION_139_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_139&quot;" name="VK_AMD_EXTENSION_139_EXTENSION_NAME"/>
<enum value="1" name="VK_EXT_INLINE_UNIFORM_BLOCK_SPEC_VERSION"/>
<enum value="&quot;VK_EXT_inline_uniform_block&quot;" name="VK_EXT_INLINE_UNIFORM_BLOCK_EXTENSION_NAME"/>
<enum offset="0" extends="VkDescriptorType" name="VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT"/>
<enum offset="0" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_FEATURES_EXT"/>
<enum offset="1" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_PROPERTIES_EXT"/>
<enum offset="2" extends="VkStructureType" name="VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT"/>
<enum offset="3" extends="VkStructureType" name="VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_INLINE_UNIFORM_BLOCK_CREATE_INFO_EXT"/>
<type name="VkPhysicalDeviceInlineUniformBlockFeaturesEXT"/>
<type name="VkPhysicalDeviceInlineUniformBlockPropertiesEXT"/>
<type name="VkWriteDescriptorSetInlineUniformBlockEXT"/>
<type name="VkDescriptorPoolInlineUniformBlockCreateInfoEXT"/>
</require>
</extension>
<extension name="VK_AMD_extension_140" number="140" author="AMD" contact="Mais Alnasser @malnasse" supported="disabled">
@ -8705,18 +8766,13 @@ server.
<enum value="&quot;VK_NV_extension_165&quot;" name="VK_EXT_EXTENSION_165_EXTENSION_NAME"/>
<enum bitpos="23" extends="VkAccessFlagBits" name="VK_ACCESS_RESERVED_23_BIT_NV"/>
<enum bitpos="8" extends="VkImageUsageFlagBits" name="VK_IMAGE_USAGE_RESERVED_8_BIT_NV"/>
<enum bitpos="22" extends="VkPipelineStageFlagBits" name="VK_PIPELINE_STAGE_RESERVED_22_BIT_NV"/>
</require>
</extension>
<extension name="VK_NV_extension_166" number="166" author="NV" contact="Daniel Koch @dgkoch" supported="disabled">
<require>
<enum value="0" name="VK_EXT_EXTENSION_166_SPEC_VERSION"/>
<enum value="&quot;VK_NV_extension_166&quot;" name="VK_EXT_EXTENSION_166_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_NV_extension_167" number="167" author="NV" contact="Daniel Koch @dgkoch" supported="disabled">
<require>
<enum value="0" name="VK_EXT_EXTENSION_167_SPEC_VERSION"/>
<enum value="&quot;VK_NV_extension_167&quot;" name="VK_EXT_EXTENSION_167_EXTENSION_NAME"/>
<enum bitpos="8" extends="VkShaderStageFlagBits" name="VK_SHADER_STAGE_RESERVED_8_BIT_NV"/>
<enum bitpos="9" extends="VkShaderStageFlagBits" name="VK_SHADER_STAGE_RESERVED_9_BIT_NV"/>
<enum bitpos="10" extends="VkShaderStageFlagBits" name="VK_SHADER_STAGE_RESERVED_10_BIT_NV"/>
@ -8730,6 +8786,12 @@ server.
<enum bitpos="5" extends="VkPipelineCreateFlagBits" name="VK_PIPELINE_CREATE_RESERVED_5_BIT_NV"/>
</require>
</extension>
<extension name="VK_NV_extension_167" number="167" author="NV" contact="Daniel Koch @dgkoch" supported="disabled">
<require>
<enum value="0" name="VK_EXT_EXTENSION_167_SPEC_VERSION"/>
<enum value="&quot;VK_NV_extension_167&quot;" name="VK_EXT_EXTENSION_167_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_NV_extension_168" number="168" author="NV" contact="Daniel Koch @dgkoch" supported="disabled">
<require>
<enum value="0" name="VK_EXT_EXTENSION_168_SPEC_VERSION"/>
@ -8897,13 +8959,15 @@ server.
</extension>
<extension name="VK_EXT_vertex_attribute_divisor" number="191" type="device" requires="VK_KHR_get_physical_device_properties2" author="NV" contact="Vikram Kushwaha @vkushwaha" supported="vulkan">
<require>
<enum value="2" name="VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_SPEC_VERSION"/>
<enum value="3" name="VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_SPEC_VERSION"/>
<enum value="&quot;VK_EXT_vertex_attribute_divisor&quot;" name="VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_EXTENSION_NAME"/>
<enum offset="0" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT"/>
<enum offset="1" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_EXT"/>
<enum offset="2" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT"/>
<type name="VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT"/>
<type name="VkVertexInputBindingDivisorDescriptionEXT"/>
<type name="VkPipelineVertexInputDivisorStateCreateInfoEXT"/>
<type name="VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT"/>
</require>
</extension>
<extension name="VK_GOOGLE_extension_192" number="192" author="GOOGLE" contact="Jean-Francois Roy @jfroy" supported="disabled">
@ -9037,10 +9101,12 @@ server.
<enum value="&quot;VK_KHR_extension_211&quot;" name="VK_KHR_EXTENSION_211_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_KHR_extension_212" number="212" type="device" author="KHR" contact="Jeff Bolz @jeffbolznv" supported="disabled">
<extension name="VK_KHR_vulkan_memory_model" number="212" type="device" author="KHR" contact="Jeff Bolz @jeffbolznv" provisional="true" supported="vulkan">
<require>
<enum value="0" name="VK_KHR_EXTENSION_212_SPEC_VERSION"/>
<enum value="&quot;VK_KHR_extension_212&quot;" name="VK_KHR_EXTENSION_212_EXTENSION_NAME"/>
<enum value="2" name="VK_KHR_VULKAN_MEMORY_MODEL_SPEC_VERSION"/>
<enum value="&quot;VK_KHR_vulkan_memory_model&quot;" name="VK_KHR_VULKAN_MEMORY_MODEL_EXTENSION_NAME"/>
<enum offset="0" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR"/>
<type name="VkPhysicalDeviceVulkanMemoryModelFeaturesKHR"/>
</require>
</extension>
<extension name="VK_AMD_extension_213" number="213" author="AMD" contact="Neil Henning @sheredom" supported="disabled">
@ -9073,5 +9139,28 @@ server.
<enum value="&quot;VK_KHR_extension_217&quot;" name="VK_KHR_EXTENSION_217_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_EXT_macos_ios_window" number="218" author="EXT" contact="Dzmitry Malyshau @kvark" supported="disabled">
<require>
<enum value="0" name="VK_EXT_MACOS_IOS_WINDOW_SPEC_VERSION"/>
<enum value="&quot;VK_EXT_macos_ios_window&quot;" name="VK_EXT_MACOS_IOS_WINDOW_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_EXT_extension_219" number="219" type="device" author="EXT" contact="Matthew Netsch @mnetsch" supported="disabled">
<require>
<enum value="0" name="VK_EXT_EXTENSION_219_SPEC_VERSION"/>
<enum value="&quot;VK_EXT_extension_219&quot;" name="VK_EXT_EXTENSION_219_EXTENSION_NAME"/>
<enum bitpos="14" extends="VkImageCreateFlagBits" name="VK_IMAGE_CREATE_RESERVED_14_BIT_EXT"/>
<enum bitpos="24" extends="VkAccessFlagBits" name="VK_ACCESS_RESERVED_24_BIT_EXT"/>
<enum bitpos="24" extends="VkFormatFeatureFlagBits" name="VK_FORMAT_FEATURE_RESERVED_24_BIT_EXT"/>
<enum bitpos="9" extends="VkImageUsageFlagBits" name="VK_IMAGE_USAGE_RESERVED_9_BIT_EXT"/>
<enum bitpos="23" extends="VkPipelineStageFlagBits" name="VK_PIPELINE_STAGE_RESERVED_23_BIT_EXT"/>
</require>
</extension>
<extension name="VK_EXT_extension_220" number="220" author="EXT" contact="Dzmitry Malyshau @kvark" supported="disabled">
<require>
<enum value="0" name="VK_EXT_EXTENSION_220_SPEC_VERSION"/>
<enum value="&quot;VK_EXT_extension_220&quot;" name="VK_EXT_EXTENSION_220_EXTENSION_NAME"/>
</require>
</extension>
</extensions>
</registry>