(The previous commit didn't actually include internal gitlab changes

since 1.1.89; fixed now).

Change log for October 28, 2018 Vulkan 1.1.90 spec update:

  * Update release number to 90.

Public Issues:

  * Tag flink:vkQueueWaitIdle as `externsync` in `vk.xml` (public pull
    request 815).
  * Update README (public pull request 834).
  * `VK_NV_framebuffer_mixed_samples` and `VK_AMD_mixed_attachment_samples`
    had confusing and contradictory valid usage statements when read in the
    all-extensions spec build. Change them to explicitly mention which
    extension each is for (public issue Vulkan-ValidationLayers/issues/353).

Internal Issues:

  * Update `COPYING.md` to clarify how externally generated Vulkan
    Specifications (for translations, annotations, or other reasons) must be
    copyrighted, and acknowledge the Exception Clause on the `vk.xml`
    license (internal issue 1079).
  * Specify that flink:vkGetPhysicalDeviceImageFormatProperties may: return
    pname:maxMipLevels 1 if the format is ycbcr (internal issue 1361).
  * Clarify previously underspecified language for
    flink:vkCmdPushConstants::pname:pStageFlags regarding use of push
    constants across multiple pipelines (internal issue 1403).
  * Fix typo in XML/headers for
    ename:VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_EXPLICIT_CREATE_INFO_EXT,
    which was previously
    etext:VK_STRUCTURE_TYPE_IMAGE_EXCPLICIT_DRM_FORMAT_MODIFIER_CREATE_INFO_EXT
    (internal issue 1428).
  * Fix markup of equations that were sporadically breaking the
    `optimize-pdf` step of PDF generation, due (apparently) to inconsistent
    treatment of unwrapped multicharacter terms by different LaTeX parsers
    (internal issue 1435).
  * For the <<memory-model-synchronizes-with synchronizes-with>> memory
    model relation cases involving a release barrier plus relaxed atomic
    write, treat the atomic as if it were a release atomic and allow the
    acquire side to read from its hypothetical release sequence. This is
    more consistent with how C++ defines synchronization for release fences
    (internal issue cross-api/memory-model#72).
  * Minor editorial changes to the <<memory-model, memory model>> appendix
    based on external feedback.

.gitlab/issue_templates/Release checklist.md

@@ -0,0 +1,71 @@
+
+# _Vulkan Feature Development Checklist Template_
+
+_This template captures checklists for the stages of development that
+a Vulkan KHR extension passes through as it moves from development to
+ratification and release. You should create an issue from this template
+when the extension draft is stable and there is reasonable consensus in
+the working group that it is on a path to ratification._
+
+_Edit the template to suit the extension you are considering (and to
+delete the italicized instructions). Delete any requirements that are not
+relevant; for example, an extension that has no language dependencies
+will not need SPIR-V / GLSL / HLSL items, and an EXT GLSL extension
+will not require Promoter ratification._
+
+_Requirements may be waived by vote of of the working group, provided
+that a 2/3 majority of non-abstaining vote are in favor._
+
+# Release checklist for _VK_KHR_extension_name_here_
+
+## Preconditions for Call for Votes (CfV)
+
+_A formal CfV is issued following agreement at a Tuesday meeting that a
+vote should be held at the following Tuesday meeting. Preconditions
+for a CfV are as follows; "specification stable" means that there are
+no MRs in flight that modify behavior defined by the extension and its
+dependencies. Delete any of the following preconditions that are not relevant to
+the extension in question_
+
+
+ - [ ] VAP consulted to the extent the WG considers appropriate
+ - [ ] CTS tests approved with three passing implementations
+ - [ ] Vulkan specification merged and stable in devel
+ - [ ] SPIR-V specification merged and stable
+ - [ ] GLSL specification merged and stable
+
+## Preconditions for submission to Promoters
+
+ - [ ] WG vote to submit passed with a 3/4 majority
+ - [ ] Submission package available for Promoter review
+
+## Preconditions for creating public release issue on GitHub
+
+_Delete any of the following preconditions that are not relevant to
+the extension in question_
+
+ - [ ] Vulkan specification ratified by Promoters
+ - [ ] SPIR-V specification ratified by Promoters
+ - [ ] GLSL specification ratified by Promoters
+ - [ ] GLSLang implementation approved to merge
+ - [ ] Marketing summary written and approved by Vulkan WG and PR team
+ - [ ] Validation layer implementation approved to merge
+ - [ ] HLSL mapping defined
+ - [ ] HLSL mapping supported in GLSLang
+ - [ ] HLSL mapping supported in DXC
+ - [ ] CTS tests approved to merge
+ - [ ] SPIR-V tools implementation approved to merge
+ - [ ] Loader support approved to merge (for instance extensions)
+ - [ ] Public release approved by Vulkan WG
+
+## Preconditions for closing this issue
+
+ - [ ] Public release issue items checked off and issue closed
+
+## Additional (Optional) Items 
+
+_These additional items are recommended for creation at some
+point during or after the release, but are not required at any point._
+
+ - [ ] Usage Examples
+ - [ ] Usage Advice

ChangeLog.txt

@@ -8,6 +8,51 @@ public pull requests that have been accepted.
 
 -----------------------------------------------------
 
+Change log for October 28, 2018 Vulkan 1.1.90 spec update:
+
+  * Update release number to 90.
+
+Public Issues:
+
+  * Tag flink:vkQueueWaitIdle as `externsync` in `vk.xml` (public pull
+    request 815).
+  * Update README (public pull request 834).
+  * `VK_NV_framebuffer_mixed_samples` and `VK_AMD_mixed_attachment_samples`
+    had confusing and contradictory valid usage statements when read in the
+    all-extensions spec build. Change them to explicitly mention which
+    extension each is for (public issue Vulkan-ValidationLayers/issues/353).
+
+Internal Issues:
+
+  * Update `COPYING.md` to clarify how externally generated Vulkan
+    Specifications (for translations, annotations, or other reasons) must be
+    copyrighted, and acknowledge the Exception Clause on the `vk.xml`
+    license (internal issue 1079).
+  * Specify that flink:vkGetPhysicalDeviceImageFormatProperties may: return
+    pname:maxMipLevels 1 if the format is ycbcr (internal issue 1361).
+  * Clarify previously underspecified language for
+    flink:vkCmdPushConstants::pname:pStageFlags regarding use of push
+    constants across multiple pipelines (internal issue 1403).
+  * Fix typo in XML/headers for
+    ename:VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_EXPLICIT_CREATE_INFO_EXT,
+    which was previously
+    etext:VK_STRUCTURE_TYPE_IMAGE_EXCPLICIT_DRM_FORMAT_MODIFIER_CREATE_INFO_EXT
+    (internal issue 1428).
+  * Fix markup of equations that were sporadically breaking the
+    `optimize-pdf` step of PDF generation, due (apparently) to inconsistent
+    treatment of unwrapped multicharacter terms by different LaTeX parsers
+    (internal issue 1435).
+  * For the <<memory-model-synchronizes-with synchronizes-with>> memory
+    model relation cases involving a release barrier plus relaxed atomic
+    write, treat the atomic as if it were a release atomic and allow the
+    acquire side to read from its hypothetical release sequence. This is
+    more consistent with how C++ defines synchronization for release fences
+    (internal issue cross-api/memory-model#72).
+  * Minor editorial changes to the <<memory-model, memory model>> appendix
+    based on external feedback.
+
+-----------------------------------------------------
+
 Change log for October 21, 2018 Vulkan 1.1.89 spec update:
 
   * Update release number to 89.

Makefile

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

appendices/VK_KHR_8bit_storage.txt

@@ -14,7 +14,7 @@ include::meta/VK_KHR_8bit_storage.txt[]
 *Contributors*::
   - Alexander Galazin, Arm
 
-The +VK_KHR_8bit_storage+ extension allows use of 8-bit types in uniform and
+The `VK_KHR_8bit_storage` extension allows use of 8-bit types in uniform and
 storage buffers, and push constant blocks.
 This extension introduces several new optional features which map to SPIR-V
 capabilities and allow access to 8-bit data in code:Block-decorated objects

appendices/VK_KHR_vulkan_memory_model.txt

@@ -19,7 +19,7 @@ include::meta/VK_KHR_vulkan_memory_model.txt[]
   - Robert Simpson, Qualcomm Technologies, Inc.
   - Brian Sumner, AMD
 
-The +VK_KHR_vulkan_memory_model+ extension allows use of the
+The `VK_KHR_vulkan_memory_model` extension allows use of the
 <<memory-model,Vulkan Memory Model>>, which formally defines how to
 synchronize memory accesses to the same memory locations performed by
 multiple shader invocations.

appendices/compressedtex.txt

@@ -122,7 +122,7 @@ ifdef::VK_EXT_astc_decode_mode[]
 
 === ASTC decode mode
 
-If the +VK_EXT_astc_decode_mode+ extension is enabled the ASTC decoding
+If the `VK_EXT_astc_decode_mode` extension is enabled the ASTC decoding
 described in the <<data-format,Khronos Data Format Specification>> is
 modified by replacing or modifying the corresponding sections as described
 below.

appendices/memorymodel.txt

@@ -175,9 +175,9 @@ potentially-mutually-ordered and any of the following are true:
   * A is a device operation, B is a host operation, and the implementation
     supports concurrent host- and device-atomics.
 
-NOTE: If two atomic operations are not mutually-ordered, and if their sets of
+NOTE: If two atomic operations are not mutually-ordered, and if their sets
-memory locations overlap, then each must: be synchronized against the other
+of memory locations overlap, then each must: be synchronized against the
-as if they were non-atomic operations.
+other as if they were non-atomic operations.
 
 [[memory-model-scoped-modification-order]]
 == Scoped Modification Order
@@ -273,9 +273,9 @@ tessellation control shaders, which is the only execution model where output
 variables are shared between invocations.
 
 The memory semantics operand also optionally includes availability and
-visibility flags, which apply optional availability and visibility operations as
+visibility flags, which apply optional availability and visibility
-described in <<memory-model-availability-visibility,availability and
+operations as described in
-visibility>>.
+<<memory-model-availability-visibility,availability and visibility>>.
 The availability/visibility flags are:
 
   * MakeAvailable: Semantics must: be Release or AcquireRelease.
@@ -361,8 +361,8 @@ synchronizes-with B if all of the following are true:
   * there exists an atomic read Y (with any memory semantics)
   * Y is program-ordered before B
   * X and Y are mutually-ordered
-  * Y reads the value written by X or by an operation in the release sequence
+  * Y reads the value written by X or by an operation in the release
-    headed by X
+    sequence headed by X
   ** If X is relaxed, it is still considered to head a hypothetical release
      sequence for this rule
   * A and B are in the instance of each other's memory scopes
@@ -371,8 +371,8 @@ synchronizes-with B if all of the following are true:
      mutually ordered.
 
 If A is a release barrier and B is an acquire barrier and C is a control
-barrier (where A can optionally equal C and B can optionally equal C),
+barrier (where A can optionally equal C and B can optionally equal C), then
-then A synchronizes-with B if all of the following are true:
+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

chapters/fragops.txt

@@ -592,10 +592,10 @@ ifdef::VK_AMD_mixed_attachment_samples[]
 [[fragops-mixed-attachment-samples]]
 == Mixed attachment samples
 
-When the +VK_AMD_mixed_attachment_samples+ extension is enabled,
+When the `VK_AMD_mixed_attachment_samples` extension is enabled, special
-special rules apply to per-fragment operations when the number of samples of
+rules apply to per-fragment operations when the number of samples of the
-the color attachments differs from the number of samples of the
+color attachments differs from the number of samples of the depth/stencil
-depth/stencil attachment used in a subpass.
+attachment used in a subpass.
 
 Let [eq]#C# be the number of color attachment samples and [eq]#D# be the
 number of depth/stencil attachment samples used by a given subpass.
@@ -1267,14 +1267,14 @@ with one bit for each sample in the color attachment(s) for the subpass.
 If a bit in the color sample mask is 0, then blending and writing to the
 framebuffer are not performed for that sample.
 
-When the +VK_NV_framebuffer_mixed_samples+ extension is not enabled,
+When the `VK_NV_framebuffer_mixed_samples` extension is not enabled, each
-each color sample is associated with a unique rasterization sample, and the
+color sample is associated with a unique rasterization sample, and the value
-value of the coverage mask is assigned to the color sample mask.
+of the coverage mask is assigned to the color sample mask.
 
 ifdef::VK_NV_framebuffer_mixed_samples[]
 
-When the +VK_NV_framebuffer_mixed_samples+ extension is enabled,
+When the `VK_NV_framebuffer_mixed_samples` extension is enabled, if the
-if the pipeline's
+pipeline's
 slink:VkPipelineMultisampleStateCreateInfo::pname:rasterizationSamples is
 greater than one and the slink:VkAttachmentDescription::pname:samples of the
 color attachments is one, then the fragment's coverage is reduced from

chapters/pipelines.txt

@@ -840,28 +840,28 @@ endif::VK_EXT_sample_locations[]
     <<descriptorsets-pipelinelayout-consistency,consistent>> with all
     shaders specified in pname:pStages
   * [[VUID-VkGraphicsPipelineCreateInfo-subpass-00757]]
-    If neither the +VK_AMD_mixed_attachment_samples+ nor the
+    If neither the `VK_AMD_mixed_attachment_samples` nor the
-    +VK_NV_framebuffer_mixed_samples+ extensions are enabled, and if
+    `VK_NV_framebuffer_mixed_samples` extensions are enabled, and if
     pname:subpass uses color and/or depth/stencil attachments, then the
     pname:rasterizationSamples member of pname:pMultisampleState must: be
     the same as the sample count for those subpass attachments
 ifdef::VK_AMD_mixed_attachment_samples[]
   * [[VUID-VkGraphicsPipelineCreateInfo-subpass-01505]]
-    If the +VK_AMD_mixed_attachment_samples+ extension is enabled, and
+    If the `VK_AMD_mixed_attachment_samples` extension is enabled, and if
-    if pname:subpass uses color and/or depth/stencil attachments, then the
+    pname:subpass uses color and/or depth/stencil attachments, then the
     pname:rasterizationSamples member of pname:pMultisampleState must: equal
     the maximum of the sample counts of those subpass attachments
 endif::VK_AMD_mixed_attachment_samples[]
 ifdef::VK_NV_framebuffer_mixed_samples[]
   * [[VUID-VkGraphicsPipelineCreateInfo-subpass-01411]]
-    If the +VK_NV_framebuffer_mixed_samples+ extension is enabled, and
+    If the `VK_NV_framebuffer_mixed_samples` extension is enabled, and if
-    if pname:subpass has a depth/stencil attachment and depth test, stencil
+    pname:subpass has a depth/stencil attachment and depth test, stencil
     test, or depth bounds test are enabled, then the
     pname:rasterizationSamples member of pname:pMultisampleState must: be
     the same as the sample count of the depth/stencil attachment
   * [[VUID-VkGraphicsPipelineCreateInfo-subpass-01412]]
-    If the +VK_NV_framebuffer_mixed_samples+ extension is enabled, and
+    If the `VK_NV_framebuffer_mixed_samples` extension is enabled, and if
-    if pname:subpass has any color attachments, then the
+    pname:subpass has any color attachments, then the
     pname:rasterizationSamples member of pname:pMultisampleState must: be
     greater than or equal to the sample count for those subpass attachments
 endif::VK_NV_framebuffer_mixed_samples[]

chapters/primsrast.txt

@@ -153,10 +153,10 @@ include::../api/structs/VkPipelineMultisampleStateCreateInfo.txt[]
     pname:minSampleShading must: be in the range [eq]#[0,1]#
 ifdef::VK_NV_framebuffer_mixed_samples[]
   * [[VUID-VkPipelineMultisampleStateCreateInfo-rasterizationSamples-01415]]
-    If the +VK_NV_framebuffer_mixed_samples+ extension is enabled, and
+    If the `VK_NV_framebuffer_mixed_samples` extension is enabled, and if
-    if the subpass has any color attachments and pname:rasterizationSamples
+    the subpass has any color attachments and pname:rasterizationSamples is
-    is greater than the number of color samples, then
+    greater than the number of color samples, then pname:sampleShadingEnable
-    pname:sampleShadingEnable must: be ename:VK_FALSE
+    must: be ename:VK_FALSE
 endif::VK_NV_framebuffer_mixed_samples[]
 
 ****
@@ -184,16 +184,16 @@ Surviving fragments are processed by fragment shaders.
 Fragment shaders determine associated data for fragments, and can: also
 modify or replace their assigned depth values.
 
-When the +VK_AMD_mixed_attachment_samples+ and
+When the `VK_AMD_mixed_attachment_samples` and
-+VK_NV_framebuffer_mixed_samples+ extensions are not enabled,
+`VK_NV_framebuffer_mixed_samples` extensions are not enabled, if the subpass
-if the subpass for which this pipeline is being created uses color and/or
+for which this pipeline is being created uses color and/or depth/stencil
-depth/stencil attachments, then pname:rasterizationSamples must: be the same
+attachments, then pname:rasterizationSamples must: be the same as the sample
-as the sample count for those subpass attachments.
+count for those subpass attachments.
 
 ifdef::VK_AMD_mixed_attachment_samples[]
 
-When the +VK_AMD_mixed_attachment_samples+ extension is enabled,
+When the `VK_AMD_mixed_attachment_samples` extension is enabled, if the
-if the subpass for which this pipeline is being created uses color and/or
+subpass for which this pipeline is being created uses color and/or
 depth/stencil attachments, then pname:rasterizationSamples must: be the same
 as the maximum of the sample counts of those subpass attachments.
 
@@ -201,10 +201,10 @@ endif::VK_AMD_mixed_attachment_samples[]
 
 ifdef::VK_NV_framebuffer_mixed_samples[]
 
-When the +VK_NV_framebuffer_mixed_samples+ extension is enabled,
+When the `VK_NV_framebuffer_mixed_samples` extension is enabled,
 pname:rasterizationSamples must: match the sample count of the depth/stencil
-attachment if present, otherwise must: be greater than or equal to the sample
+attachment if present, otherwise must: be greater than or equal to the
-count of the color attachments, if present.
+sample count of the color attachments, if present.
 
 endif::VK_NV_framebuffer_mixed_samples[]
 
@@ -1276,9 +1276,9 @@ If sample shading is enabled an implementation must: provide a minimum of
 {rceil}, 1)# unique associated data for each fragment, where
 pname:minSampleShadingFactor is the minimum fraction of sample shading.
 ifdef::VK_AMD_mixed_attachment_samples[]
-If the +VK_AMD_mixed_attachment_samples+ extension is enabled and the subpass
+If the `VK_AMD_mixed_attachment_samples` extension is enabled and the
-uses color attachments, pname:totalSamples is the number of samples of the
+subpass uses color attachments, pname:totalSamples is the number of samples
-color attachments.
+of the color attachments.
 Otherwise,
 endif::VK_AMD_mixed_attachment_samples[]
 pname:totalSamples is the value of

chapters/renderpass.txt

@@ -868,17 +868,17 @@ attachment.
     ename:VK_ATTACHMENT_UNUSED must: have the same sample count
 ifdef::VK_AMD_mixed_attachment_samples[]
   * [[VUID-VkSubpassDescription-pColorAttachments-01506]]
-    If the +VK_AMD_mixed_attachment_samples+ extension is enabled, and
+    If the `VK_AMD_mixed_attachment_samples` extension is enabled, and all
-    all attachments in pname:pColorAttachments that are not
+    attachments in pname:pColorAttachments that are not
     ename:VK_ATTACHMENT_UNUSED must: have a sample count that is smaller
     than or equal to the sample count of pname:pDepthStencilAttachment if it
     is not ename:VK_ATTACHMENT_UNUSED
 endif::VK_AMD_mixed_attachment_samples[]
   * [[VUID-VkSubpassDescription-pDepthStencilAttachment-01418]]
-    If neither the +VK_AMD_mixed_attachment_samples+ nor the
+    If neither the `VK_AMD_mixed_attachment_samples` nor the
-    +VK_NV_framebuffer_mixed_samples+ extensions are enabled, and if
+    `VK_NV_framebuffer_mixed_samples` extensions are enabled, and if
-    pname:pDepthStencilAttachment is not ename:VK_ATTACHMENT_UNUSED and
+    pname:pDepthStencilAttachment is not ename:VK_ATTACHMENT_UNUSED and any
-    any attachments in pname:pColorAttachments are not
+    attachments in pname:pColorAttachments are not
     ename:VK_ATTACHMENT_UNUSED, they must: have the same sample count
   * [[VUID-VkSubpassDescription-None-00852]]
     If any input attachments are ename:VK_ATTACHMENT_UNUSED, then any
@@ -1693,17 +1693,17 @@ corresponding subpass.
     ename:VK_ATTACHMENT_UNUSED must: have the same sample count
 ifdef::VK_AMD_mixed_attachment_samples[]
   * [[VUID-VkSubpassDescription2KHR-pColorAttachments-03070]]
-    If the +VK_AMD_mixed_attachment_samples+ extension is enabled,
+    If the `VK_AMD_mixed_attachment_samples` extension is enabled, all
-    all attachments in pname:pColorAttachments that are not
+    attachments in pname:pColorAttachments that are not
     ename:VK_ATTACHMENT_UNUSED must: have a sample count that is smaller
     than or equal to the sample count of pname:pDepthStencilAttachment if it
     is not ename:VK_ATTACHMENT_UNUSED
 endif::VK_AMD_mixed_attachment_samples[]
   * [[VUID-VkSubpassDescription2KHR-pDepthStencilAttachment-03071]]
-    If neither the +VK_AMD_mixed_attachment_samples+ nor the
+    If neither the `VK_AMD_mixed_attachment_samples` nor the
-    +VK_NV_framebuffer_mixed_samples+ extensions are enabled, and if
+    `VK_NV_framebuffer_mixed_samples` extensions are enabled, and if
-    pname:pDepthStencilAttachment is not ename:VK_ATTACHMENT_UNUSED and
+    pname:pDepthStencilAttachment is not ename:VK_ATTACHMENT_UNUSED and any
-    any attachments in pname:pColorAttachments are not
+    attachments in pname:pColorAttachments are not
     ename:VK_ATTACHMENT_UNUSED, they must: have the same sample count
   * [[VUID-VkSubpassDescription2KHR-None-03072]]
     If any input attachments are ename:VK_ATTACHMENT_UNUSED, then any

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 89
+#define VK_HEADER_VERSION 90
 
 
 #define VK_NULL_HANDLE 0

style/naming.txt

@@ -33,7 +33,7 @@ place of the full word unless there is good reason not to.
 When a number is part of an identifier, it is treated as a word if it is a
 standalone number, such as the extension name token
 ename:VK_KHR_GET_MEMORY_REQUIREMENTS_2_EXTENSION_NAME for the
-+VK_KHR_get_memory_requirements2+ extension.
+`VK_KHR_get_memory_requirements2` extension.
 For uses where the number is part of a common abbreviation such as etext:2D
 or etext:R8B8`, the entire abbreviation is treated as a word.
 

xml/vk.xml

@@ -150,7 +150,7 @@ server.
         <type category="define">// Vulkan 1.1 version number
 #define <name>VK_API_VERSION_1_1</name> <type>VK_MAKE_VERSION</type>(1, 1, 0)// Patch version should always be set to 0</type>
         <type category="define">// Version of this file
-#define <name>VK_HEADER_VERSION</name> 89</type>
+#define <name>VK_HEADER_VERSION</name> 90</type>
 
         <type category="define">
 #define <name>VK_DEFINE_HANDLE</name>(object) typedef struct object##_T* object;</type>
@@ -10094,5 +10094,11 @@ server.
                 <enum value="&quot;VK_INTEL_extension_243&quot;"             name="VK_INTEL_EXTENSION_243_EXTENSION_NAME"/>
             </require>
         </extension>
+        <extension name="VK_MESA_extension_244" number="244" author="MESA" contact="Andres Rodriguez @lostgoat" supported="disabled">
+            <require>
+                <enum value="0"                                              name="VK_MESA_EXTENSION_244_SPEC_VERSION"/>
+                <enum value="&quot;VK_MESA_extension_244&quot;"              name="VK_MESA_EXTENSION_244_EXTENSION_NAME"/>
+            </require>
+        </extension>
     </extensions>
 </registry>