From adadfce8a3610c026e56d2e026c0c6387e2bbdad Mon Sep 17 00:00:00 2001 From: Jon Leech Date: Sat, 8 Sep 2018 15:52:13 -0700 Subject: [PATCH] Change log for September 8, 2018 Vulkan 1.1.84 spec update: * Update release number to 84. Public Issues: * Fix code sample in the `<>` 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 <> section (public pull request 773). * Fix typo in equation in the <> 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 `<>` 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` --- ChangeLog.txt | 45 + Makefile | 2 +- appendices/VK_EXT_astc_decode_mode.txt | 113 +++ appendices/VK_EXT_debug_utils.txt | 12 +- appendices/VK_EXT_inline_uniform_block.txt | 112 +++ .../VK_EXT_vertex_attribute_divisor.txt | 12 +- appendices/VK_KHR_vulkan_memory_model.txt | 45 + appendices/compressedtex.txt | 258 ++++++ appendices/extensions.txt | 1 + appendices/glossary.txt | 27 + appendices/memorymodel.txt | 848 ++++++++++++++++++ appendices/spirvenv.txt | 27 + chapters/cmdbuffers.txt | 2 +- chapters/descriptorsets.txt | 366 +++++++- chapters/features.txt | 225 +++++ chapters/fxvertex.txt | 29 +- chapters/interfaces.txt | 27 + chapters/memory.txt | 15 +- chapters/resources.txt | 73 +- chapters/shaders.txt | 14 + chapters/synchronization.txt | 51 +- chapters/textures.txt | 6 +- include/vulkan/vulkan_core.h | 87 +- reflow_count.py | 2 +- registry.txt | 2 + style/writing.txt | 1 + vkspec.txt | 4 + xml/extensionmetadocgenerator.py | 28 +- xml/registry.rnc | 2 + xml/vk.xml | 127 ++- 30 files changed, 2481 insertions(+), 82 deletions(-) create mode 100644 appendices/VK_EXT_astc_decode_mode.txt create mode 100644 appendices/VK_EXT_inline_uniform_block.txt create mode 100644 appendices/VK_KHR_vulkan_memory_model.txt create mode 100644 appendices/memorymodel.txt diff --git a/ChangeLog.txt b/ChangeLog.txt index acbb0604..ca9419f6 100644 --- a/ChangeLog.txt +++ b/ChangeLog.txt @@ -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 `<>` 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 <> section + (public pull request 773). + * Fix typo in equation in the <> 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 + `<>` 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. diff --git a/Makefile b/Makefile index 6c4fc137..19f7057b 100644 --- a/Makefile +++ b/Makefile @@ -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 diff --git a/appendices/VK_EXT_astc_decode_mode.txt b/appendices/VK_EXT_astc_decode_mode.txt new file mode 100644 index 00000000..03cea212 --- /dev/null +++ b/appendices/VK_EXT_astc_decode_mode.txt @@ -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 + diff --git a/appendices/VK_EXT_debug_utils.txt b/appendices/VK_EXT_debug_utils.txt index 5c732be6..067feb4c 100644 --- a/appendices/VK_EXT_debug_utils.txt +++ b/appendices/VK_EXT_debug_utils.txt @@ -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** diff --git a/appendices/VK_EXT_inline_uniform_block.txt b/appendices/VK_EXT_inline_uniform_block.txt new file mode 100644 index 00000000..5b6722e0 --- /dev/null +++ b/appendices/VK_EXT_inline_uniform_block.txt @@ -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 diff --git a/appendices/VK_EXT_vertex_attribute_divisor.txt b/appendices/VK_EXT_vertex_attribute_divisor.txt index e3701efd..dc0d236a 100644 --- a/appendices/VK_EXT_vertex_attribute_divisor.txt +++ b/appendices/VK_EXT_vertex_attribute_divisor.txt @@ -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. diff --git a/appendices/VK_KHR_vulkan_memory_model.txt b/appendices/VK_KHR_vulkan_memory_model.txt new file mode 100644 index 00000000..9f2baac3 --- /dev/null +++ b/appendices/VK_KHR_vulkan_memory_model.txt @@ -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 +<>, 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 + + * <> + +=== Issues + +=== Version History + + * Revision 1, 2018-06-24 (Jeff Bolz) + - Initial draft diff --git a/appendices/compressedtex.txt b/appendices/compressedtex.txt index f83419c4..e2f97275 100644 --- a/appendices/compressedtex.txt +++ b/appendices/compressedtex.txt @@ -117,3 +117,261 @@ chapter of the <>. | 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 <> 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 <>. +==== + +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 +[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 +[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 <>. +==== + +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 <>. +==== + +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 <>). + diff --git a/appendices/extensions.txt b/appendices/extensions.txt index ec511133..2dfacc66 100644 --- a/appendices/extensions.txt +++ b/appendices/extensions.txt @@ -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[] diff --git a/appendices/glossary.txt b/appendices/glossary.txt index d565a3c3..931daadf 100644 --- a/appendices/glossary.txt +++ b/appendices/glossary.txt @@ -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. diff --git a/appendices/memorymodel.txt b/appendices/memorymodel.txt new file mode 100644 index 00000000..561420c8 --- /dev/null +++ b/appendices/memorymodel.txt @@ -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 +<> 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-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 <> and a +<>. +Informally, the scope determines which other agents it is atomic with +respect to, and the <> 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 <>). +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 +<>) 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 <>. +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 +<>. + +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 <> 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 +<> 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_ +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 some X and X + inter-thread-happens-before 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 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 <> operations may: be required for writes to be +<> other memory accesses. + +NOTE: Happens-before is not transitive, but each of program-order and +inter-thread-happens-before 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 +<>. +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 +<>, 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 <> 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 + <> 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 <>. +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 <>, 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. diff --git a/appendices/spirvenv.txt b/appendices/spirvenv.txt index 7f85a853..4283663e 100755 --- a/appendices/spirvenv.txt +++ b/appendices/spirvenv.txt @@ -206,6 +206,11 @@ ifdef::VK_KHR_8bit_storage[] | code:UniformAndStorageBuffer8BitAccess | <> | code:StoragePushConstant8 | <> endif::VK_KHR_8bit_storage[] +ifdef::VK_KHR_vulkan_memory_model[] +[[spirvenv-capabilities-table-memorymodel]] +| code:VulkanMemoryModelKHR | <> +| code:VulkanMemoryModelDeviceScopeKHR | <> +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 <> is + enabled and + <> + is not enabled, *Device* scope must: not be used. + *** If <> 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 <> is + not enabled, *QueueFamilyKHR* must: not be used. +endif::VK_KHR_vulkan_memory_model[] ** *Workgroup* ifdef::VK_VERSION_1_1[] ** *Subgroup* diff --git a/chapters/cmdbuffers.txt b/chapters/cmdbuffers.txt index 1d4b87bf..20e635b0 100644 --- a/chapters/cmdbuffers.txt +++ b/chapters/cmdbuffers.txt @@ -1023,7 +1023,7 @@ See <>. 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 <>, there must: exist a previously submitted diff --git a/chapters/descriptorsets.txt b/chapters/descriptorsets.txt index 4d396868..8e42b12e 100644 --- a/chapters/descriptorsets.txt +++ b/chapters/descriptorsets.txt @@ -267,6 +267,30 @@ to a <> 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 +<>, 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 + <> 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 +<> 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 <> +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 <>. - * ename:VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT specifies a + * ename:VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT specifies an <>. +ifdef::VK_EXT_inline_uniform_block[] + * ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT specifies an + <>. +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 <> +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 <> +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[] diff --git a/chapters/features.txt b/chapters/features.txt index 57fdfc5d..2e247963 100755 --- a/chapters/features.txt +++ b/chapters/features.txt @@ -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 + <>. + 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>> ** <> +ifdef::VK_EXT_inline_uniform_block[] + * <>, if + the `<>` extension is supported. + * <>, if the + `<>` and `<>` + 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 + <> 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[] diff --git a/chapters/fxvertex.txt b/chapters/fxvertex.txt index 4cea7c7d..ccf7315e 100644 --- a/chapters/fxvertex.txt +++ b/chapters/fxvertex.txt @@ -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 +<> +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 + <> + 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; diff --git a/chapters/interfaces.txt b/chapters/interfaces.txt index 678abf57..d4679bf3 100755 --- a/chapters/interfaces.txt +++ b/chapters/interfaces.txt @@ -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 <>. @@ -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:: diff --git a/chapters/memory.txt b/chapters/memory.txt index fac17d63..238f1956 100644 --- a/chapters/memory.txt +++ b/chapters/memory.txt @@ -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 <> 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 <> using the ename:VK_ACCESS_HOST_WRITE_BIT <>. 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 -<>, 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 <>, 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. diff --git a/chapters/resources.txt b/chapters/resources.txt index 05d098c5..7b175cd1 100644 --- a/chapters/resources.txt +++ b/chapters/resources.txt @@ -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 <> 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 <>, 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 ==== diff --git a/chapters/shaders.txt b/chapters/shaders.txt index fc7d6a0a..0970030e 100644 --- a/chapters/shaders.txt +++ b/chapters/shaders.txt @@ -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 <> appendix defines the terminology and rules +for how to correctly communicate between shader invocations, such as when a +write is <> a read, and what constitutes +a <>. + +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 diff --git a/chapters/synchronization.txt b/chapters/synchronization.txt index 4f4c9b64..88a29b9b 100644 --- a/chapters/synchronization.txt +++ b/chapters/synchronization.txt @@ -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 <> section of the <> chapter. +Which API operations perform each of these operations is defined in +<>. +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 <>, where it can: be further made available to the device by -<>. +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 -<> 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 <>. -Similarly, writes made visible to the ename:VK_ACCESS_HOST_READ_BIT -<> 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 <> 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 <>. The first <> -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 <> includes all memory access performed by the device. diff --git a/chapters/textures.txt b/chapters/textures.txt index d9757de0..228f7f99 100644 --- a/chapters/textures.txt +++ b/chapters/textures.txt @@ -578,9 +578,9 @@ elink:VkFormat), using the appropriate equations in <>. 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 <>. The A component, if present, is unchanged. diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h index 8891ca46..fe450142 100644 --- a/include/vulkan/vulkan_core.h +++ b/include/vulkan/vulkan_core.h @@ -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 diff --git a/reflow_count.py b/reflow_count.py index b2f701ab..fdb7e0c2 100644 --- a/reflow_count.py +++ b/reflow_count.py @@ -1,2 +1,2 @@ # The value to start tagging VU statements at, unless overridden by -nextvu -startVUID = 2027 +startVUID = 2234 diff --git a/registry.txt b/registry.txt index b41cd9bd..b25ec841 100644 --- a/registry.txt +++ b/registry.txt @@ -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. diff --git a/style/writing.txt b/style/writing.txt index c7e23338..36c6b729 100644 --- a/style/writing.txt +++ b/style/writing.txt @@ -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} ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +|==== ---- diff --git a/vkspec.txt b/vkspec.txt index 880ea233..ce1d692b 100644 --- a/vkspec.txt +++ b/vkspec.txt @@ -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[] diff --git a/xml/extensionmetadocgenerator.py b/xml/extensionmetadocgenerator.py index 06774891..23dd3e58 100644 --- a/xml/extensionmetadocgenerator.py +++ b/xml/extensionmetadocgenerator.py @@ -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 diff --git a/xml/registry.rnc b/xml/registry.rnc index 69d2de7c..5ec5d477 100644 --- a/xml/registry.rnc +++ b/xml/registry.rnc @@ -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, / 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 { diff --git a/xml/vk.xml b/xml/vk.xml index f33d9cdf..9cd1c72d 100644 --- a/xml/vk.xml +++ b/xml/vk.xml @@ -147,7 +147,7 @@ server. // Vulkan 1.1 version number #define VK_API_VERSION_1_1 VK_MAKE_VERSION(1, 1, 0)// Patch version should always be set to 0 // Version of this file -#define VK_HEADER_VERSION 83 +#define VK_HEADER_VERSION 84 #define VK_DEFINE_HANDLE(object) typedef struct object##_T* object; @@ -2796,7 +2796,7 @@ server. const void* pNext VkSamplerReductionModeEXT reductionMode - + VkStructureType sType void* pNext VkBool32 advancedBlendCoherentOperations @@ -2818,6 +2818,32 @@ server. VkBool32 dstPremultiplied VkBlendOverlapEXT blendOverlap + + VkStructureType sType + void* pNext + VkBool32 inlineUniformBlock + VkBool32 descriptorBindingInlineUniformBlockUpdateAfterBind + + + VkStructureType sType + void* pNext + uint32_t maxInlineUniformBlockSize + uint32_t maxPerStageDescriptorInlineUniformBlocks + uint32_t maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks + uint32_t maxDescriptorSetInlineUniformBlocks + uint32_t maxDescriptorSetUpdateAfterBindInlineUniformBlocks + + + VkStructureType sType + const void* pNext + uint32_t dataSize + const void* pData + + + VkStructureType sType + const void* pNext + uint32_t maxInlineUniformBlockBindings + VkStructureType sType const void* pNext @@ -2858,7 +2884,7 @@ server. VkBool32 supported - + VkStructureType sType void* pNext VkBool32 shaderDrawParameters @@ -3199,6 +3225,18 @@ server. VkBool32 conditionalRendering VkBool32 inheritedConditionalRendering + + VkStructureType sType + void* pNext + VkBool32 vulkanMemoryModel + VkBool32 vulkanMemoryModelDeviceScope + + + VkStructureType sType + void* pNext + VkBool32 vertexAttributeInstanceRateDivisor + VkBool32 vertexAttributeInstanceRateZeroDivisor + VkStructureType sType void* pNext @@ -3210,6 +3248,16 @@ server. VkPipelineStageFlagBits stage void* pCheckpointMarker + + VkStructureType sType + const void* pNext + VkFormat decodeMode + + + VkStructureType sType + void* pNext + VkBool32 decodeModeSharedExponent + Vulkan enumerant (token) definitions @@ -7493,10 +7541,14 @@ server. - + - - + + + + + + @@ -8344,10 +8396,19 @@ server. - + - - + + + + + + + + + + + @@ -8705,18 +8766,13 @@ server. + - - - - - - @@ -8730,6 +8786,12 @@ server. + + + + + + @@ -8897,13 +8959,15 @@ server. - + + + @@ -9037,10 +9101,12 @@ server. - + - - + + + + @@ -9073,5 +9139,28 @@ server. + + + + + + + + + + + + + + + + + + + + + + +