Change log for July 13, 2017 Vulkan 1.0.54 spec update:

  * Bump API patch number and header version number to 54 for this update.

Github Issues:

Internal Issues:

  * Fix tessellation domain to have an upper-left origin in the
    <<img-tessellation-topology-ul, tessellation toplogy image>> and related
    language. CTS and all implementations were already doing this, it was
    just a documentation bug that it was flipped to lower-left (internal
    issue 603).
  * Add a section to the style guide describing how VUID tags are changed
    and removed when the corresponding Valid Usage statements are modified
    (internal issue 829).
  * Add explicit Valid Usage statement to
    slink:VkPipelineDynamicStateCreateInfo to require that members of
    pname:pDynamicStates must be unique (internal issue 851).

New Extensions:

  * `VK_KHR_16bit_storage`
  * `VK_KHR_dedicated_allocation`
  * `VK_KHR_external_fence`
  * `VK_KHR_external_fence_capabilities`
  * `VK_KHR_external_fence_fd`
  * `VK_KHR_external_fence_win32`
  * `VK_KHR_get_memory_requirements2`
  * `VK_KHR_storage_buffer_storage_class`
  * `VK_KHR_variable_pointers`

Extensions Promoted From KHX To KHR Status:

  * `VK_KHR_external_memory`
  * `VK_KHR_external_memory_capabilities`
  * `VK_KHR_external_memory_fd`
  * `VK_KHR_external_memory_win32`
  * `VK_KHR_external_semaphore`
  * `VK_KHR_external_semaphore_capabilities`
  * `VK_KHR_external_semaphore_fd`
  * `VK_KHR_external_semaphore_win32`
  * `VK_KHR_win32_keyed_mutex`

ChangeLog.txt

@@ -8,6 +8,52 @@ public issues.
 
 -----------------------------------------------------
 
+Change log for July 13, 2017 Vulkan 1.0.54 spec update:
+
+  * Bump API patch number and header version number to 54 for this update.
+
+Github Issues:
+
+Internal Issues:
+
+  * Fix tessellation domain to have an upper-left origin in the
+    <<img-tessellation-topology-ul, tessellation toplogy image>> and related
+    language. CTS and all implementations were already doing this, it was
+    just a documentation bug that it was flipped to lower-left (internal
+    issue 603).
+  * Add a section to the style guide describing how VUID tags are changed
+    and removed when the corresponding Valid Usage statements are modified
+    (internal issue 829).
+  * Add explicit Valid Usage statement to
+    slink:VkPipelineDynamicStateCreateInfo to require that members of
+    pname:pDynamicStates must be unique (internal issue 851).
+
+New Extensions:
+
+  * `VK_KHR_16bit_storage`
+  * `VK_KHR_dedicated_allocation`
+  * `VK_KHR_external_fence`
+  * `VK_KHR_external_fence_capabilities`
+  * `VK_KHR_external_fence_fd`
+  * `VK_KHR_external_fence_win32`
+  * `VK_KHR_get_memory_requirements2`
+  * `VK_KHR_storage_buffer_storage_class`
+  * `VK_KHR_variable_pointers`
+
+Extensions Promoted From KHX To KHR Status:
+
+  * `VK_KHR_external_memory`
+  * `VK_KHR_external_memory_capabilities`
+  * `VK_KHR_external_memory_fd`
+  * `VK_KHR_external_memory_win32`
+  * `VK_KHR_external_semaphore`
+  * `VK_KHR_external_semaphore_capabilities`
+  * `VK_KHR_external_semaphore_fd`
+  * `VK_KHR_external_semaphore_win32`
+  * `VK_KHR_win32_keyed_mutex`
+
+-----------------------------------------------------
+
 Change log for June 24, 2017 Vulkan 1.0.53 spec update:
 
   * Bump API patch number and header version number to 53 for this update.

doc/specs/vulkan/Makefile

@@ -87,7 +87,7 @@ VERBOSE =
 #	     $(EXTENSIONS))
 # ADOCOPTS   options for asciidoc->HTML5 output
 NOTEOPTS     = -a editing-notes -a implementation-guide
-SPECREVISION = 1.0.53
+SPECREVISION = 1.0.54
 # Spell out RFC2822 format as not all date commands support -R
 SPECDATE     = $(shell echo `date -u "+%a, %d %b %Y %T %z"`)
 

doc/specs/vulkan/appendices/VK_AMD_gpu_shader_int16.txt

@@ -1,3 +1,4 @@
+[[VK_AMD_gpu_shader_int16]]
 == VK_AMD_gpu_shader_int16
 
 *Name String*::
@@ -12,19 +13,18 @@
 *IP Status*::
     No known IP claims.
 *Dependencies*::
-    - This extension is written against version 1.0 of the Vulkan API.
-    - Requires the SPV_AMD_gpu_shader_int16 SPIR-V extension.
-
+  - This extension is written against version 1.0 of the Vulkan API.
+  - Requires the SPV_AMD_gpu_shader_int16 SPIR-V extension.
 *Contributors*::
-    - Daniel Rakos, AMD
-    - Dominik Witczak, AMD
-    - Matthaeus G.
-      Chajdas, AMD
-    - Rex Xu, AMD
-    - Timothy Lottes, AMD
-    - Zhi Cai, AMD
+  - Daniel Rakos, AMD
+  - Dominik Witczak, AMD
+  - Matthaeus G.
+    Chajdas, AMD
+  - Rex Xu, AMD
+  - Timothy Lottes, AMD
+  - Zhi Cai, AMD
 *Contacts*::
-    - Qun Lin, AMD (quentin.lin@amd.com)
+  - Qun Lin, AMD (quentin.lin@amd.com)
 
 This extension adds support for the following SPIR-V extension in Vulkan:
 

doc/specs/vulkan/appendices/VK_AMD_texture_gather_bias_lod.txt

@@ -1,3 +1,4 @@
+[[VK_AMD_texture_gather_bias_lod]]
 == VK_AMD_texture_gather_bias_lod
 
 *Name String*::
@@ -55,8 +56,7 @@ None.
 
 === New SPIR-V Capabilities
 
-* <<spirvenv-capabilities-table-imagegatherbiaslodamd,code:ImageGatherBiasLodAMD>>
-
+  * <<spirvenv-capabilities-table-imagegatherbiaslodamd,code:ImageGatherBiasLodAMD>>
 
 === New Structures
 
@@ -114,5 +114,5 @@ else
 
 === Version History
 
- * Revision 1, 2017-03-21 (Dominik Witczak)
-   - Initial draft
+   * Revision 1, 2017-03-21 (Dominik Witczak)
+     - Initial draft

doc/specs/vulkan/appendices/VK_EXT_blend_operation_advanced.txt

@@ -1,5 +1,6 @@
 [[VK_EXT_blend_operation_advanced]]
 == VK_EXT_blend_operation_advanced
+
 *Name String*::
     VK_EXT_blend_operation_advanced
 *Extension Type*::
@@ -13,32 +14,31 @@
 *Revision*::
     2
 *Dependencies*::
-    - This extension is written against version 1.0 of the Vulkan API.
-    - This extension requires Vulkan 1.0.
+  - This extension is written against version 1.0 of the Vulkan API.
+  - This extension requires Vulkan 1.0.
 *Contributors*::
-    - Jeff Bolz, NVIDIA
+  - Jeff Bolz, NVIDIA
 *Contact*::
-    - Jeff Bolz (jbolz 'at' nvidia.com)
-*Overview*::
-+
---
-This extension adds a number of "advanced" blending operations that can: be
-used to perform new color blending operations, many of which are more
+  - Jeff Bolz (jbolz 'at' nvidia.com)
+
+This extension adds a number of "`advanced`" blending operations that can:
+be used to perform new color blending operations, many of which are more
 complex than the standard blend modes provided by unextended Vulkan.
 This extension requires different styles of usage, depending on the level of
 hardware support and the feature enable:
 
-- If
-  slink:VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT::pname:advancedBlendCoherentOperations
-  is ename:VK_FALSE, the new blending operations are supported, but a memory
-  dependency must: separate each advanced blend operation on a given sample.
-  ename:VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT is used to
-  synchronize reads using advanced blend operations.
+  - If
+    slink:VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT::pname:advancedBlendCoherentOperations
+    is ename:VK_FALSE, the new blending operations are supported, but a
+    memory dependency must: separate each advanced blend operation on a
+    given sample.
+    ename:VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT is used to
+    synchronize reads using advanced blend operations.
 
-- If
-  slink:VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT::pname:advancedBlendCoherentOperations
-  is ename:VK_TRUE, advanced blend operations obey primitive order just like
-  basic blend operations.
+  - If
+    slink:VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT::pname:advancedBlendCoherentOperations
+    is ename:VK_TRUE, advanced blend operations obey primitive order just
+    like basic blend operations.
 
 In unextended Vulkan, the set of blending operations is limited, and can: be
 expressed very simply.
@@ -53,7 +53,7 @@ This limited set of operations supports many common blending operations but
 precludes the use of more sophisticated transparency and blending operations
 commonly available in many dedicated imaging APIs.
 
-This extension provides a number of new "advanced" blending operations.
+This extension provides a number of new "`advanced`" blending operations.
 Unlike traditional blending operations using ename:VK_BLEND_OP_ADD, these
 blending equations do not use source and destination factors specified by
 elink:VkBlendFactor.
@@ -103,12 +103,13 @@ which may: result in a loss of precision and dynamic range for framebuffer
 formats with 32-bit floating-point components, and in a loss of precision
 for formats with 12- and 16-bit signed or unsigned normalized integer
 components.
---
 
 === New Object Types
+
 None.
 
 === New Enum Constants
+
   * Extending elink:VkStructureType:
   ** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BLEND_OPERATION_ADVANCED_FEATURES_EXT
   ** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BLEND_OPERATION_ADVANCED_PROPERTIES_EXT
@@ -166,19 +167,24 @@ None.
   ** ename:VK_BLEND_OP_BLUE_EXT
 
 === New Enums
+
   * elink:VkBlendOverlapEXT
 
 === New Structures
+
   * slink:VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT
   * slink:VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT
   * slink:VkPipelineColorBlendAdvancedStateCreateInfoEXT
 
 === New Functions
+
 None.
 
 === Issues
+
 None.
 
 === Version History
+
   * Revisions 1-2, 2017-06-12 (Jeff Bolz)
     - Internal revisions

doc/specs/vulkan/appendices/VK_EXT_debug_report.txt

@@ -155,9 +155,9 @@ The older enum is still available for backwards compatibility.
 === Issues
 
 1) What is the hierarchy / seriousness of the message flags? E.g. ERROR >
-   WARN > PERF_WARN ...
+WARN > PERF_WARN ...
 
-**RESOLVED**: There is no specific hierarchy.
+*RESOLVED*: There is no specific hierarchy.
 Each bit is independent and should be checked via bitwise AND.
 For example:
 
@@ -181,18 +181,18 @@ with extension values the application's debug report handler may not be
 familiar with so it is important to treat each flag independently.
 
 2) Should there be a VU requiring
-   sname:VkDebugReportCallbackCreateInfoEXT::pname:flags to be non-zero?
+sname:VkDebugReportCallbackCreateInfoEXT::pname:flags to be non-zero?
 
-**RESOLVED**: It may not be very useful, but we do not need VU statement
+*RESOLVED*: It may not be very useful, but we do not need VU statement
 requiring the sname:VkDebugReportCallbackCreateInfoEXT::pname:msgFlags at
 create-time be non-zero.
 One can imagine that apps may prefer it as it allows them to set the mask as
 desired - including nothing - at runtime without having to check.
 
 3) What is the difference between ename:VK_DEBUG_REPORT_DEBUG_BIT_EXT and
-   ename:VK_DEBUG_REPORT_INFORMATION_BIT_EXT?
+ename:VK_DEBUG_REPORT_INFORMATION_BIT_EXT?
 
-**RESOLVED**: ename:VK_DEBUG_REPORT_DEBUG_BIT_EXT indicates information that
+*RESOLVED*: ename:VK_DEBUG_REPORT_DEBUG_BIT_EXT indicates information that
 could be useful debugging the Vulkan implementation itself.
 
 === Version History

doc/specs/vulkan/appendices/VK_EXT_discard_rectangles.txt

@@ -1,5 +1,6 @@
 [[VK_EXT_discard_rectangles]]
 == VK_EXT_discard_rectangles
+
 *Name String*::
     VK_EXT_discard_rectangles
 *Extension Type*::
@@ -13,18 +14,16 @@
 *Revision*::
     1
 *Dependencies*::
-    - This extension is written against version 1.0 of the Vulkan API.
-    - This extension requires Vulkan 1.0.
-    - Requires
-      <<VK_KHR_get_physical_device_properties2,VK_KHR_get_physical_device_properties2>>.
+  - This extension is written against version 1.0 of the Vulkan API.
+  - This extension requires Vulkan 1.0.
+  - Requires
+    <<VK_KHR_get_physical_device_properties2,VK_KHR_get_physical_device_properties2>>.
 *Contributors*::
-    - Daniel Koch, NVIDIA
-    - Jeff Bolz, NVIDIA
+  - Daniel Koch, NVIDIA
+  - Jeff Bolz, NVIDIA
 *Contact*::
-    - Piers Daniell (pdaniell 'at' nvidia.com)
-*Overview*::
-+
---
+  - Piers Daniell (pdaniell 'at' nvidia.com)
+
 This extension provides additional orthogonally aligned "discard rectangles"
 specified in framebuffer-space coordinates that restrict rasterization of
 all points, lines and triangles.
@@ -43,12 +42,13 @@ functionality.
 If the VK_KHX_device_group extension is enabled the discard rectangles can
 be different for each physical device in the device group by specifying the
 device mask and setting discard rectangle dynamic state.
---
 
 === New Object Types
+
 None.
 
 === New Enum Constants
+
   * Extending elink:VkStructureType:
 
   ** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DISCARD_RECTANGLE_PROPERTIES_EXT
@@ -59,19 +59,24 @@ None.
   ** ename:VK_DYNAMIC_STATE_DISCARD_RECTANGLE_EXT
 
 === New Enums
+
   * elink:VkPipelineDiscardRectangleStateCreateFlagsEXT
   * elink:VkDiscardRectangleModeEXT
 
 === New Structures
+
   * slink:VkPhysicalDeviceDiscardRectanglePropertiesEXT
   * slink:VkPipelineDiscardRectangleStateCreateInfoEXT
 
 === New Functions
+
   * flink:vkCmdSetDiscardRectangleEXT
 
 === Issues
+
 None.
 
 === Version History
+
   * Revision 1, 2016-12-22 (Piers Daniell)
     - Internal revisions

doc/specs/vulkan/appendices/VK_EXT_hdr_metadata.txt

@@ -47,7 +47,7 @@ It is up to the implementation to determine how to make use of the metadata.
 === New Enum Constants
 
   * Extending elink:VkStructureType:
-      ** ename:VK_STRUCTURE_TYPE_HDR_METADATA_EXT
+  ** ename:VK_STRUCTURE_TYPE_HDR_METADATA_EXT
 
 === New Structures
 
@@ -62,14 +62,14 @@ It is up to the implementation to determine how to make use of the metadata.
 
 1) Do we need a query function?
 
-   PROPOSED: No, Vulkan does not provide queries for state that the
-   application can track on its own.
+*PROPOSED*: No, Vulkan does not provide queries for state that the
+application can track on its own.
 
 2) Should we specify default if not specified by the application?
 
-   PROPOSED: No, that leaves the default up to the display.
+*PROPOSED*: No, that leaves the default up to the display.
 
 === Version History
 
-* Revision 1, 2016-12-27 (Courtney Goeltzenleuchter)
-  - Initial version
+  * Revision 1, 2016-12-27 (Courtney Goeltzenleuchter)
+    - Initial version