Change log for October 13, 2019 Vulkan 1.1.125 spec update:

* Update release number to 125.

Github Issues:

  * Allow slink:VkRenderPassFragmentDensityMapCreateInfoEXT to extend
    slink:VkRenderPassCreateInfo2KHR in `vk.xml` (public issue 1027).
  * Fix markup in `<<VK_EXT_external_memory_dma_buf>>` appendix (public pull
    request 1051).
  * Update .gitignore (public pull request 1052).

Internal Issues:

  * Disallowed slink:VkEvent from participating in queue family ownership
    transfers in the <<devsandqueues-index, Queue Family Index>> section
    (internal issue 1691).
  * Relax language describing default NT handle access rights for
    slink:VkExportMemoryWin32HandleInfoKHR and
    slink:VkExportSemaphoreWin32HandleInfoKHR (internal issue 1838).
  * Fix markup for slink:VkDeviceCreateInfo valid usage statement 00372 to
    remove imbedded asciidoctor conditionals by splitting it into two VUs
    (internal issue 1846).
  * Clarify lifetime of samplers used as immutable samplers in
    slink:VkDescriptorSetLayoutBinding (internal issue 1849).
  * Add a valid usage statement prohibiting flink:vkCmdBeginQuery on
    timestamp queries (internal issue 1851).
  * Correct some <<Precision of GLSL.std.450 Instructions, SPIR-V
    instruction precisions>> (internal merge request 3391).
  * Fix a typo in flink:vkQueueBindSparse valid usage statement 03245
    (internal merge request 3394).

New Extensions

  * `<<VK_KHR_spirv_1_4>>`

ChangeLog.txt

@@ -8,6 +8,44 @@ public pull requests that have been accepted.
 
 -----------------------------------------------------
 
+Change log for October 13, 2019 Vulkan 1.1.125 spec update:
+
+  * Update release number to 125.
+
+Github Issues:
+
+  * Allow slink:VkRenderPassFragmentDensityMapCreateInfoEXT to extend
+    slink:VkRenderPassCreateInfo2KHR in `vk.xml` (public issue 1027).
+  * Fix markup in `<<VK_EXT_external_memory_dma_buf>>` appendix (public pull
+    request 1051).
+  * Update .gitignore (public pull request 1052).
+
+Internal Issues:
+
+  * Disallowed slink:VkEvent from participating in queue family ownership
+    transfers in the <<devsandqueues-index, Queue Family Index>> section
+    (internal issue 1691).
+  * Relax language describing default NT handle access rights for
+    slink:VkExportMemoryWin32HandleInfoKHR and
+    slink:VkExportSemaphoreWin32HandleInfoKHR (internal issue 1838).
+  * Fix markup for slink:VkDeviceCreateInfo valid usage statement 00372 to
+    remove imbedded asciidoctor conditionals by splitting it into two VUs
+    (internal issue 1846).
+  * Clarify lifetime of samplers used as immutable samplers in
+    slink:VkDescriptorSetLayoutBinding (internal issue 1849).
+  * Add a valid usage statement prohibiting flink:vkCmdBeginQuery on
+    timestamp queries (internal issue 1851).
+  * Correct some <<Precision of GLSL.std.450 Instructions, SPIR-V
+    instruction precisions>> (internal merge request 3391).
+  * Fix a typo in flink:vkQueueBindSparse valid usage statement 03245
+    (internal merge request 3394).
+
+New Extensions
+
+  * `<<VK_KHR_spirv_1_4>>`
+
+-----------------------------------------------------
+
 Change log for October 6, 2019 Vulkan 1.1.124 spec update:
 
   * Update release number to 124.

Makefile

@@ -119,7 +119,7 @@ VERBOSE =
 # ADOCOPTS options for asciidoc->HTML5 output
 
 NOTEOPTS     = -a editing-notes -a implementation-guide
-PATCHVERSION = 124
+PATCHVERSION = 125
 ifneq (,$(findstring VK_VERSION_1_1,$(VERSIONS)))
 SPECREVISION = 1.1.$(PATCHVERSION)
 else

appendices/VK_EXT_external_memory_dma_buf.txt

@@ -9,8 +9,9 @@ include::{generated}/meta/VK_EXT_external_memory_dma_buf.txt[]
   - James Jones, NVIDIA
   - Jason Ekstrand, Intel
 
-A code:dma_buf is a type of file descriptor, defined by the Linux kernel, that
+A code:dma_buf is a type of file descriptor, defined by the Linux kernel,
-allows sharing memory across kernel device drivers and across processes.
+that allows sharing memory across kernel device drivers and across
+processes.
 This extension enables applications to import a code:dma_buf as
 slink:VkDeviceMemory, to export slink:VkDeviceMemory as a code:dma_buf, and
 to create slink:VkBuffer objects that can: be bound to that memory.
@@ -25,9 +26,8 @@ to create slink:VkBuffer objects that can: be bound to that memory.
 1) How does the application, when creating a slink:VkImage that it intends
 to bind to code:dma_buf slink:VkDeviceMemory containing an externally
 produced image, specify the memory layout (such as row pitch and DRM format
-modifier) of the slink:VkImage?
+modifier) of the slink:VkImage? In other words, how does the application
-In other words, how does the application achieve behavior comparable to
+achieve behavior comparable to that provided by
-that provided by
 https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt[`EGL_EXT_image_dma_buf_import`]
 and
 https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt[`EGL_EXT_image_dma_buf_import_modifiers`]

appendices/VK_KHR_spirv_1_4.txt

@@ -0,0 +1,123 @@
+// Copyright (c) 2018-2019 Khronos Group. This work is licensed under a
+// Creative Commons Attribution 4.0 International License; see
+// http://creativecommons.org/licenses/by/4.0/
+
+include::{generated}/meta/VK_KHR_spirv_1_4.txt[]
+
+*Last Modified Date*::
+    2019-04-01
+*IP Status*::
+    No known IP claims.
+*Interactions and External Dependencies*::
+  - Requires SPIR-V 1.4.
+*Contributors*::
+  - Alexander Galazin, Arm
+  - David Neto, Google
+  - Jesse Hall, Google
+  - John Kessenich, Google
+  - Neil Henning, AMD
+  - Tom Olson, Arm
+
+This extension allows the use of SPIR-V 1.4 shader modules.
+SPIR-V 1.4's new features primarily make it an easier target for compilers
+from high-level languages, rather than exposing new hardware functionality.
+
+SPIR-V 1.4 incorporates features that are also available separately as
+extensions.
+SPIR-V 1.4 shader modules do not need to enable those extensions with the
+`OpExtension` opcode, since they are integral parts of SPIR-V 1.4.
+
+SPIR-V 1.4 introduces new floating point execution mode capabilities, also
+available via `SPV_KHR_float_controls`.
+Implementations are not required to support all of these new capabilities;
+support can be queried using
+slink:VkPhysicalDeviceFloatControlsPropertiesKHR from the
+<<VK_KHR_shader_float_controls>> extension.
+
+=== New Object Types
+
+None.
+
+=== New Enum Constants
+
+None.
+
+=== New Enums
+
+None.
+
+=== New Structures
+
+None.
+
+=== New Functions
+
+None.
+
+=== Issues
+
+1.
+Should we have an extension specific to this SPIR-V version, or add a
+version-generic query for SPIR-V version? SPIR-V 1.4 doesn't need any other
+API changes.
+
+RESOLVED: Just expose SPIR-V 1.4.
+
+Most new SPIR-V versions introduce optionally-required capabilities or have
+implementation-defined limits, and would need more API and specification
+changes specific to that version to make them available in Vulkan.
+For example, to support the subgroup features added in SPIR-V 1.3 required
+introducing slink:VkPhysicalDeviceSubgroupProperties to allow querying the
+supported subgroup operation categories, maximum supported subgroup size,
+etc.
+While we could expose the parts of a new SPIR-V version that don't need
+accompanying changes generically, we'll still end up writing extensions
+specific to each version for the remaining parts.
+Thus the generic mechanism won't reduce future spec-writing effort.
+In addition, making it clear which parts of a future version are supported
+by the generic mechanism and which can't be used without specific support
+would be difficult to get right ahead of time.
+
+2.
+Can different stages of the same pipeline use shaders with different SPIR-V
+versions?
+
+RESOLVED: Yes.
+
+Mixing SPIR-V versions 1.0-1.3 in the same pipeline has not been disallowed,
+so it would be inconsistent to disallow mixing 1.4 with previous versions..
+SPIR-V 1.4 does not introduce anything that should cause new difficulties
+here.
+
+3.
+Must Vulkan extensions corresponding to SPIR-V extensions that were promoted
+to core in 1.4 be enabled in order to use that functionality in a SPIR-V 1.4
+module?
+
+RESOLVED: No, with caveats.
+
+The SPIR-V 1.4 module does not need to declare the SPIR-V extensions, since
+the functionality is now part of core, so there is no need to enable the
+Vulkan extension that allows SPIR-V modules to declare the SPIR-V extension.
+However, when the functionality that is now core in SPIR-V 1.4 is optionally
+supported, the query for support is provided by a Vulkan extension, and that
+query can only be used if the extension is enabled.
+
+This applies to any SPIR-V version; specifically for SPIR-V 1.4 this only
+applies to the functionality from `SPV_KHR_float_controls`, which was made
+available in Vulkan by <<VK_KHR_shader_float_controls>>.
+Even though the extension was promoted in SPIR-V 1.4, the capabilities are
+still optional in implementations that support `VK_KHR_spirv_1_4`.
+
+A SPIR-V 1.4 module doesn't need to enable `SPV_KHR_float_controls` in order
+to use the capabilities, so if the application has _a priori_ knowledge that
+the implementation supports the capabilities, it doesn't need to enable
+<<VK_KHR_shader_float_controls>>.
+However, if it doesn't have this knowledge and has to query for support at
+runtime, it must enable <<VK_KHR_shader_float_controls>> in order to use
+slink:VkPhysicalDeviceFloatControlsPropertiesKHR.
+
+=== Version History
+
+  * Revision 1, 2019-04-01 (Jesse Hall)
+    - Internal draft versions

appendices/spirvenv.txt

@@ -23,6 +23,10 @@ ifndef::VK_VERSION_1_1[]
 A Vulkan 1.0 implementation must: support the 1.0 version of SPIR-V and the
 1.0 version of the SPIR-V Extended Instructions for GLSL.
 endif::VK_VERSION_1_1[]
+ifdef::VK_KHR_spirv_1_4[]
+If the <<VK_KHR_spirv_1_4>> extension is enabled, the implementation must:
+additionally support the 1.4 version of SPIR-V.
+endif::VK_KHR_spirv_1_4[]
 
 A SPIR-V module passed into flink:vkCreateShaderModule is interpreted as a
 series of 32-bit words in host endianness, with literal strings packed as
@@ -1293,9 +1297,9 @@ different sign than the infinitely precise result.
 | code:inversesqrt()
 2+| 2 ULP.
 | code:radians(x)
-2+a| Inherited from latexmath:[\frac{x \times \pi}{180}].
+2+a| Inherited from latexmath:[x \times \frac{\pi}{180}].
 | code:degrees(x)
-2+a| Inherited from latexmath:[\frac{x \times 180}{\pi}].
+2+a| Inherited from latexmath:[x \times \frac{180}{\pi}].
 | code:sin()
   a| Absolute error latexmath:[\leq 2^{-11}] inside the range latexmath:[[-\pi, \pi\]]. a| Absolute error latexmath:[\leq 2^{-7}] inside the range latexmath:[[-\pi, \pi\]].
 | code:cos()
@@ -1303,9 +1307,9 @@ different sign than the infinitely precise result.
 | code:tan()
 2+a| Inherited from latexmath:[\frac{\sin()}{\cos()}].
 | code:asin(x)
-2+a| Inherited from latexmath:[\mathrm{atan2}(x, sqrt(1.0 - x^2))].
+2+a| Inherited from latexmath:[\mathrm{atan2}(x, sqrt(1.0 - x \times x))].
 | code:acos(x)
-2+a| Inherited from latexmath:[\mathrm{atan2}(sqrt(1.0 - x^2), x)].
+2+a| Inherited from latexmath:[\mathrm{atan2}(sqrt(1.0 - x \times x), x)].
 | code:atan(), code:atan2()
    | 4096 ULP                                                      | 5 ULP.
 | code:sinh(x)
@@ -1315,9 +1319,9 @@ different sign than the infinitely precise result.
 | code:tanh()
 2+a| Inherited from latexmath:[\frac{\sinh()}{\cosh()}].
 | code:asinh(x)
-2+a| Inherited from latexmath:[\log(x + sqrt(x^2 + 1.0))].
+2+a| Inherited from latexmath:[\log(x + sqrt(x \times x + 1.0))].
 | code:acosh(x)
-2+a| Inherited from latexmath:[\log(x + sqrt(x^2 - 1.0))].
+2+a| Inherited from latexmath:[\log(x + sqrt(x \times x - 1.0))].
 | code:atanh(x)
 2+a| Inherited from latexmath:[\log(\frac{1.0 + x}{1.0 - x}) \times 0.5].
 | code:frexp()
@@ -1332,12 +1336,12 @@ different sign than the infinitely precise result.
 2+| Inherited from [eq]#code:OpFSub(code:OpFMul, code:OpFMul)#.
 | code:normalize(x)
 2+a| Inherited from latexmath:[\frac{x}{length(x)}].
-| code:faceforward
+| code:faceforward(N, I, NRef)
-2+| Correctly rounded.
+2+| Inherited from [eq]#code:dot(NRef, I) < 0.0 ? N : -N#.
 | code:reflect(x, y)
 2+| Inherited from [eq]#x - 2.0 {times} code:dot(y, x) {times} y#.
 | code:refract(I, N, eta)
-2+| Inherited from [eq]#eta {times} I - (eta {times} code:dot(N, I) {plus} code:sqrt(k)) {times} N#.
+2+| Inherited from [eq]#k < 0.0 ? 0.0 : eta {times} I - (eta {times} code:dot(N, I) {plus} code:sqrt(k)) {times} N#, where [eq]#k = 1 - eta {times} eta {times} (1.0 - code:dot(N, I) {times} code:dot(N, I))#.
 | code:round
 2+| Correctly rounded.
 | code:roundEven
@@ -1367,7 +1371,7 @@ different sign than the infinitely precise result.
 | code:step
 2+| Correctly rounded.
 | code:smoothStep(edge0, edge1, x)
-2+a| Inherited from latexmath:[t^{2} \times (3.0 - 2.0 \times t)],
+2+a| Inherited from latexmath:[t \times t \times (3.0 - 2.0 \times t)],
 where latexmath:[t = clamp(\frac{x - edge0}{edge1 - edge0}, 0.0, 1.0)].
 | code:nmin
 2+| Correctly rounded.

chapters/commonvalidity/query_begin_common.txt

@@ -4,6 +4,9 @@
     <<queries-operation-active,active>> within pname:commandBuffer
   * [[VUID-{refpage}-None-00807]]
     All queries used by the command must: be unavailable
+  * [[VUID-{refpage}-queryType-2804]]
+    The pname:queryType used to create pname:queryPool must: not be
+    ename:VK_QUERY_TYPE_TIMESTAMP
   * [[VUID-{refpage}-queryType-00800]]
     If the <<features-occlusionQueryPrecise,precise occlusion queries>>
     feature is not enabled, or the pname:queryType used to create

chapters/descriptorsets.txt

@@ -557,9 +557,12 @@ and the compute stage.
     ename:VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER descriptor with
     immutable samplers does not modify the samplers (the image views are
     updated, but the sampler updates are ignored).
-    If pname:pImmutableSamplers is not `NULL`, then it is considered to be a
+    If pname:pImmutableSamplers is not `NULL`, then it points to an array of
-    pointer to an array of sampler handles that will be consumed by the set
+    sampler handles that will be copied into the set layout and used for the
-    layout and used for the corresponding binding.
+    corresponding binding.
+    Only the sampler handles are copied; the sampler objects must: not be
+    destroyed before the final use of the set layout and any descriptor
+    pools and sets created using it.
     If pname:pImmutableSamplers is `NULL`, then the sampler slots are
     dynamic and sampler handles must: be bound into descriptor sets using
     this layout.

chapters/devsandqueues.txt

@@ -951,12 +951,13 @@ include::{generated}/api/structs/VkDeviceCreateInfo.txt[]
 
 .Valid Usage
 ****
-  * [[VUID-VkDeviceCreateInfo-queueFamilyIndex-00372]]
 ifndef::VK_VERSION_1_1[]
+  * [[VUID-VkDeviceCreateInfo-queueFamilyIndex-00372]]
     The pname:queueFamilyIndex member of each element of
     pname:pQueueCreateInfos must: be unique within pname:pQueueCreateInfos
 endif::VK_VERSION_1_1[]
 ifdef::VK_VERSION_1_1[]
+  * [[VUID-VkDeviceCreateInfo-queueFamilyIndex-02802]]
     The pname:queueFamilyIndex member of each element of
     pname:pQueueCreateInfos must: be unique within pname:pQueueCreateInfos,
     except that two members can share the same pname:queueFamilyIndex if one
@@ -1626,9 +1627,9 @@ slink:VkBufferCreateInfo structures to specify the queue families that can:
 access the resource.
 
 When inserting a slink:VkBufferMemoryBarrier or slink:VkImageMemoryBarrier
-(see <<synchronization-events>>) a source and destination queue family index
+(see <<synchronization-pipeline-barriers>>), a source and destination queue
-is specified to allow the ownership of a buffer or image to be transferred
+family index is specified to allow the ownership of a buffer or image to be
-from one queue family to another.
+transferred from one queue family to another.
 See the <<resources-sharing,Resource Sharing>> section for details.
 
 

chapters/introduction.txt

@@ -136,7 +136,8 @@ _SPIR-V Extended Instructions for GLSL, Version 1.00_ (February 10, 2016).
 https://www.khronos.org/registry/spir-v/ .
 
 [[spirv-spec]] John Kessenich, Boaz Ouriel, and Raun Krisch.
-_SPIR-V Specification, Version 1.3, Revision 2, Unified_ (May 11, 2018).
+_SPIR-V Specification, Version 1.4, Revision 1, Unified_ (December 14,
+2018).
 https://www.khronos.org/registry/spir-v/ .
 
 [[vulkan-styleguide]] Jon Leech and Tobias Hector.

chapters/memory.txt

@@ -1597,24 +1597,26 @@ If this structure is not present, or if pname:pAttributes is set to `NULL`,
 default security descriptor values will be used, and child processes created
 by the application will not inherit the handle, as described in the MSDN
 documentation for "`Synchronization Object Security and Access Rights`"^1^.
-Further, if the structure is not present, the access rights will be
+Further, if the structure is not present, the access rights used depend on
+the handle type.
 
-code:DXGI_SHARED_RESOURCE_READ | code:DXGI_SHARED_RESOURCE_WRITE
+For handles of the following types:
-
-for handles of the following types:
 
 ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT
 ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT
 
-And
+The implementation must: ensure the access rights allow read and write
+access to the memory.
 
-code:GENERIC_ALL
+For handles of the following types:
-
-for handles of the following types:
 
 ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_HEAP_BIT
 ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT
 
+The access rights must: be:
+
+code:GENERIC_ALL
+
 1::
     https://msdn.microsoft.com/en-us/library/windows/desktop/ms686670.aspx
 

chapters/sparsemem.txt

@@ -1669,7 +1669,7 @@ Additional information about fence and semaphore operation is described in
     previously submitted for execution.
 ifdef::VK_KHR_timeline_semaphore[]
   * [[VUID-vkQueueBindSparse-pWaitSemaphores-03245]]
-    All elements of the pname:pWaitSemaphores of all elements of
+    All elements of the pname:pWaitSemaphores member of all elements of
     pname:pBindInfo created with a elink:VkSemaphoreTypeKHR of
     ename:VK_SEMAPHORE_TYPE_BINARY_KHR must: reference a semaphore signal
     operation that has been submitted for execution and any semaphore signal

chapters/synchronization.txt

@@ -2449,22 +2449,23 @@ If this structure is not present, or if pname:pAttributes is set to `NULL`,
 default security descriptor values will be used, and child processes created
 by the application will not inherit the handle, as described in the MSDN
 documentation for "`Synchronization Object Security and Access Rights`"^1^.
-Further, if the structure is not present, the access rights will be
 
-code:DXGI_SHARED_RESOURCE_READ | code:DXGI_SHARED_RESOURCE_WRITE
 
-for handles of the following types:
+For handles of the following types:
 
 ename:VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_BIT
 
-And
+The implementation must: ensure the access rights allow both signal and wait
+operations on the semaphore.
 
-code:GENERIC_ALL
+For handles of the following types:
-
-for handles of the following types:
 
 ename:VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_D3D12_FENCE_BIT
 
+The access rights must: be:
+
+code:GENERIC_ALL
+
 1::
     https://msdn.microsoft.com/en-us/library/windows/desktop/ms686670.aspx
 
@@ -3912,6 +3913,9 @@ flink:vkCmdWaitEvents is used with flink:vkCmdSetEvent to define a memory
 dependency between two sets of action commands, roughly in the same way as
 pipeline barriers, but split into two commands such that work between the
 two may: execute unhindered.
+Unlike flink:vkCmdPipelineBarrier, a queue family ownership transfer can't
+be performed using flink:vkCmdWaitEvents since events only support
+host/queue and intra-queue dependencies.
 ====
 
 [NOTE]
@@ -3976,6 +3980,10 @@ semaphore).
     the pipeline stages in pname:dstStageMask, as specified in the
     <<synchronization-access-types-supported, table of supported access
     types>>.
+  * [[VUID--srcQueueFamilyIndex-02803]]
+    The pname:srcQueueFamilyIndex and pname:dstQueueFamilyIndex members of
+    any element of pname:pBufferMemoryBarriers or pname:pImageMemoryBarriers
+    must: be equal.
 ifdef::VK_VERSION_1_1,VK_KHR_device_group[]
   * [[VUID-vkCmdWaitEvents-commandBuffer-01167]]
     pname:commandBuffer's current device mask must: include exactly one
@@ -4850,8 +4858,8 @@ range.
 A release operation is defined by executing a
 <<synchronization-buffer-memory-barriers, buffer memory barrier>> (for a
 buffer range) or an <<synchronization-image-memory-barriers, image memory
-barrier>> (for an image subresource range), on a queue from the source queue
+barrier>> (for an image subresource range) using flink:vkCmdPipelineBarrier,
-family.
+on a queue from the source queue family.
 The pname:srcQueueFamilyIndex parameter of the barrier must: be set to the
 source queue family index, and the pname:dstQueueFamilyIndex parameter to
 the destination queue family index.
@@ -4866,8 +4874,8 @@ range.
 An acquire operation is defined by executing a
 <<synchronization-buffer-memory-barriers, buffer memory barrier>> (for a
 buffer range) or an <<synchronization-image-memory-barriers, image memory
-barrier>> (for an image subresource range), on a queue from the destination
+barrier>> (for an image subresource range) using flink:vkCmdPipelineBarrier,
-queue family.
+on a queue from the destination queue family.
 The buffer range or image subresource range specified in an acquire
 operation must: match exactly that of a previous release operation.
 The pname:srcQueueFamilyIndex parameter of the barrier must: be set to the
@@ -4925,6 +4933,16 @@ The contents of any portion of another resource which aliases memory that is
 bound to the transferred buffer or image subresource range are undefined:
 after a release or acquire operation.
 
+[NOTE]
+.Note
+====
+Because <<synchronization-events>> can't be used directly for inter-queue
+synchronization, and because flink:vkCmdSetEvent doesn't have the queue
+family index or memory barrier parameters needed by a _release operation_,
+the release and acquire operations of a queue family ownership transfer can:
+only be performed using flink:vkCmdPipelineBarrier.
+====
+
 
 [[synchronization-wait-idle]]
 == Wait Idle Operations

scripts/reflow_count.py

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

xml/vk.xml

@@ -154,7 +154,7 @@ server.
         <type category="define">// Vulkan 1.1 version number
 #define <name>VK_API_VERSION_1_1</name> <type>VK_MAKE_VERSION</type>(1, 1, 0)// Patch version should always be set to 0</type>
         <type category="define">// Version of this file
-#define <name>VK_HEADER_VERSION</name> 124</type>
+#define <name>VK_HEADER_VERSION</name> 125</type>
 
         <type category="define">
 #define <name>VK_DEFINE_HANDLE</name>(object) typedef struct object##_T* object;</type>
@@ -3812,7 +3812,7 @@ typedef void <name>CAMetalLayer</name>;
             <member><type>VkExtent2D</type>                       <name>maxFragmentDensityTexelSize</name></member>
             <member><type>VkBool32</type>                         <name>fragmentDensityInvocations</name></member>
         </type>
-        <type category="struct" name="VkRenderPassFragmentDensityMapCreateInfoEXT" structextends="VkRenderPassCreateInfo">
+        <type category="struct" name="VkRenderPassFragmentDensityMapCreateInfoEXT" structextends="VkRenderPassCreateInfo,VkRenderPassCreateInfo2KHR">
             <member values="VK_STRUCTURE_TYPE_RENDER_PASS_FRAGMENT_DENSITY_MAP_CREATE_INFO_EXT"><type>VkStructureType</type> <name>sType</name></member>
             <member>const <type>void</type>*                      <name>pNext</name></member>
             <member><type>VkAttachmentReference</type>            <name>fragmentDensityMapAttachment</name></member>
@@ -11173,10 +11173,10 @@ typedef void <name>CAMetalLayer</name>;
                 <enum value="&quot;VK_AMD_extension_236&quot;"              name="VK_AMD_EXTENSION_236_EXTENSION_NAME"/>
             </require>
         </extension>
-        <extension name="VK_KHR_extension_237" number="237" author="KHR" contact="Jesse Hall @critsec" supported="disabled">
+        <extension name="VK_KHR_spirv_1_4" number="237" type="device" requiresCore="1.1" requires="VK_KHR_shader_float_controls" author="KHR" contact="Jesse Hall @critsec" supported="vulkan">
             <require>
-                <enum value="0"                                             name="VK_KHR_EXTENSION_237_SPEC_VERSION"/>
+                <enum value="1"                                             name="VK_KHR_SPIRV_1_4_SPEC_VERSION"/>
-                <enum value="&quot;VK_KHR_extension_237&quot;"              name="VK_KHR_EXTENSION_237_EXTENSION_NAME"/>
+                <enum value="&quot;VK_KHR_spirv_1_4&quot;"                  name="VK_KHR_SPIRV_1_4_EXTENSION_NAME"/>
             </require>
         </extension>
         <extension name="VK_EXT_memory_budget" number="238" type="device" requires="VK_KHR_get_physical_device_properties2" author="EXT" contact="Jeff Bolz @jeffbolznv" supported="vulkan">
@@ -11629,5 +11629,11 @@ typedef void <name>CAMetalLayer</name>;
                 <enum value="&quot;VK_NV_extension_293&quot;"               name="VK_NV_EXTENSION_293_EXTENSION_NAME"/>
             </require>
         </extension>
+        <extension name="VK_KHR_extension_294" number="294" author="KHR" contact="Baldur Karlsson @baldurk" supported="disabled">
+            <require>
+                <enum value="0"                                             name="VK_KHR_EXTENSION_294_SPEC_VERSION"/>
+                <enum value="&quot;VK_KHR_extension_294&quot;"               name="VK_KHR_EXTENSION_294_EXTENSION_NAME"/>
+            </require>
+        </extension>
     </extensions>
 </registry>