Change log for August 10, 2020 Vulkan 1.2.150 spec update:

  * Update release number to 150 for this update.

Github Issues:

  * Remove ename:VK_ERROR_TOO_MANY_OBJECTS as a required error code for
    flink:vkAllocateMemory and and flink:vkCreateSampler, and note that
    while it may still occur as a historical artifact, exceeding
    implementation limits will result in undefined behavior (public issue
    1295).
  * Allow duplicate slink:VkDebugUtilsMessengerCreateInfoEXT structs in
    pname:pNext chain (public issue 1329)
  * Fix typo in slink:VkSubmitInfo valid usage statement 04120 (public merge
    request 1336).
  * Remove `KHR` suffix from some names promoted to core, in the
    <<renderpass, Render Pass>> chapter (public merge request 1341).

Internal Issues:

  * Add ename:VK_ERROR_OUT_OF_HOST_MEMORY to `vk.xml` as a possible error
    code for some additional commands returing elink:VkResult, and add a
    note to the description of elink:VkResult giving some guidance on which
    commands may and may not return that error code (internal issue 2063).
  * Make a handful of terminology changes which move this repository closer
    to the conventions of the AOSP
    https://source.android.com/setup/contribute/respectful-code[Coding with
    Respect] document (internal issue 2282).
  * Update `<<VK_MVK_ios_surface>>` and `<<VK_MVK_macos_surface>>`
    documentation and mark them as deprecated and replaced by
    `<<VK_EXT_metal_surface>>` (internal merge request 4024).
  * Add a section to the style guide on markup for the copyright and license
    block on files in the repository (internal merge request 4036).
  * Add ename:VK_VALIDATION_FEATURE_ENABLE_SYNCHRONIZATION_VALIDATION_EXT to
    `<<VK_EXT_validation_features>>` to enable synchronization validation
    (internal merge request 4037).

ChangeLog.txt

@@ -12,6 +12,45 @@ public pull requests that have been accepted.
 
 -----------------------------------------------------
 
+Change log for August 10, 2020 Vulkan 1.2.150 spec update:
+
+  * Update release number to 150 for this update.
+
+Github Issues:
+
+  * Remove ename:VK_ERROR_TOO_MANY_OBJECTS as a required error code for
+    flink:vkAllocateMemory and and flink:vkCreateSampler, and note that
+    while it may still occur as a historical artifact, exceeding
+    implementation limits will result in undefined behavior (public issue
+    1295).
+  * Allow duplicate slink:VkDebugUtilsMessengerCreateInfoEXT structs in
+    pname:pNext chain (public issue 1329)
+  * Fix typo in slink:VkSubmitInfo valid usage statement 04120 (public merge
+    request 1336).
+  * Remove `KHR` suffix from some names promoted to core, in the
+    <<renderpass, Render Pass>> chapter (public merge request 1341).
+
+Internal Issues:
+
+  * Add ename:VK_ERROR_OUT_OF_HOST_MEMORY to `vk.xml` as a possible error
+    code for some additional commands returing elink:VkResult, and add a
+    note to the description of elink:VkResult giving some guidance on which
+    commands may and may not return that error code (internal issue 2063).
+  * Make a handful of terminology changes which move this repository closer
+    to the conventions of the AOSP
+    https://source.android.com/setup/contribute/respectful-code[Coding with
+    Respect] document (internal issue 2282).
+  * Update `<<VK_MVK_ios_surface>>` and `<<VK_MVK_macos_surface>>`
+    documentation and mark them as deprecated and replaced by
+    `<<VK_EXT_metal_surface>>` (internal merge request 4024).
+  * Add a section to the style guide on markup for the copyright and license
+    block on files in the repository (internal merge request 4036).
+  * Add ename:VK_VALIDATION_FEATURE_ENABLE_SYNCHRONIZATION_VALIDATION_EXT to
+    `<<VK_EXT_validation_features>>` to enable synchronization validation
+    (internal merge request 4037).
+
+-----------------------------------------------------
+
 Change log for August 3, 2020 Vulkan 1.2.149 spec update:
 
   * Update release number to 149 for this update.
@@ -4459,7 +4498,7 @@ Github Issues:
 
 Internal Issues:
 
-  * Specify a whitelist of supported SPIR-V Storage Classes in the
+  * Specify a list of supported SPIR-V Storage Classes in the
     <<spirvenv-module-validation, Validation Rules within a Module>>
     appendix (internal SPIR-V issue 166).
   * Relax the shared semaphore wait timeout requirement in the

Makefile

@@ -109,7 +109,7 @@ VERBOSE =
 # ADOCOPTS options for asciidoc->HTML5 output
 
 NOTEOPTS     = -a editing-notes -a implementation-guide
-PATCHVERSION = 149
+PATCHVERSION = 150
 ifneq (,$(findstring VK_VERSION_1_2,$(VERSIONS)))
 SPECREVISION = 1.2.$(PATCHVERSION)
 else

appendices/VK_EXT_acquire_xlib_display.txt

@@ -38,8 +38,8 @@ Vulkan display handle as input?
 
 *RESOLVED*: A Vulkan display handle.
 Otherwise there would be no way to specify handles to displays that had been
-"`blacklisted`" or prevented from being included in the X11 display list by
-some native platform or vendor-specific mechanism.
+prevented from being included in the X11 display list by some native
+platform or vendor-specific mechanism.
 
 2) How does an application figure out which RandR display corresponds to a
 Vulkan display?

appendices/VK_EXT_validation_features.txt

@@ -16,6 +16,7 @@ include::{generated}/meta/{refprefix}VK_EXT_validation_features.txt[]
   - Mark Lobodzinski, LunarG
   - Camden Stocker, LunarG
   - Tony Barbour, LunarG
+  - John Zulauf, LunarG
 
 === Description
 
@@ -47,3 +48,5 @@ include::{generated}/interfaces/VK_EXT_validation_features.txt[]
    - Add Best Practices enable
  * Revision 3, 2020-03-04 (Tony Barbour)
    - Add Debug Printf enable
+ * Revision 4, 2020-07-29 (John Zulauf)
+   - Add Synchronization Validation enable

appendices/VK_KHR_display.txt

@@ -118,7 +118,8 @@ object.
 *PROPOSED RESOLUTION*: Developers prefer to query modes directly from the
 physical GPU so they can use display information as an input to their device
 selection algorithms prior to device creation.
-This avoids the need to create dummy device instances to enumerate displays.
+This avoids the need to create placeholder device instances to enumerate
+displays.
 
 This preference must be weighed against the extra initialization that must
 be done by driver vendors prior to device instance creation to support this

appendices/VK_MVK_ios_surface.txt

@@ -7,7 +7,7 @@ include::{generated}/meta/{refprefix}VK_MVK_ios_surface.txt[]
 === Other Extension Metadata
 
 *Last Modified Date*::
-    2017-02-24
+    2020-07-31
 *IP Status*::
     No known IP claims.
 *Contributors*::
@@ -17,10 +17,17 @@ include::{generated}/meta/{refprefix}VK_MVK_ios_surface.txt[]
 
 The `VK_MVK_ios_surface` extension is an instance extension.
 It provides a mechanism to create a slink:VkSurfaceKHR object (defined by
-the `<<VK_KHR_surface>>` extension) that refers to a code:UIView, the native
+the `<<VK_KHR_surface>>` extension) based on a code:UIView, the native
 surface type of iOS, which is underpinned by a basetype:CAMetalLayer, to
 support rendering to the surface using Apple's Metal framework.
 
+ifdef::VK_EXT_metal_surface[]
+=== Deprecation by `VK_EXT_metal_surface`
+
+The `VK_MVK_ios_surface` extension is considered deprecated and has been
+superseded by the `<<VK_EXT_metal_surface>>` extension.
+endif::VK_EXT_metal_surface[]
+
 include::{generated}/interfaces/VK_MVK_ios_surface.txt[]
 
 === Version History
@@ -29,5 +36,9 @@ include::{generated}/interfaces/VK_MVK_ios_surface.txt[]
    - Initial draft.
 
  * Revision 2, 2017-02-24 (Bill Hollings)
-   - Minor syntax fix to emphasize firm requirement for UIView to be backed
-     by a CAMetalLayer.
+   - Minor syntax fix to emphasize firm requirement for `UIView` to be
+     backed by a `CAMetalLayer`.
+
+ * Revision 3, 2020-07-31 (Bill Hollings)
+   - Update documentation on requirements for UIView.
+   - Mark as deprecated by `VK_EXT_metal_surface`.

appendices/VK_MVK_macos_surface.txt

@@ -7,7 +7,7 @@ include::{generated}/meta/{refprefix}VK_MVK_macos_surface.txt[]
 === Other Extension Metadata
 
 *Last Modified Date*::
-    2017-02-24
+    2020-07-31
 *IP Status*::
     No known IP claims.
 *Contributors*::
@@ -17,10 +17,16 @@ include::{generated}/meta/{refprefix}VK_MVK_macos_surface.txt[]
 
 The `VK_MVK_macos_surface` extension is an instance extension.
 It provides a mechanism to create a slink:VkSurfaceKHR object (defined by
-the `<<VK_KHR_surface>>` extension) that refers to an code:NSView, the
-native surface type of macOS, which is underpinned by a
-basetype:CAMetalLayer, to support rendering to the surface using Apple's
-Metal framework.
+the `<<VK_KHR_surface>>` extension) based on an code:NSView, the native
+surface type of macOS, which is underpinned by a basetype:CAMetalLayer, to
+support rendering to the surface using Apple's Metal framework.
+
+ifdef::VK_EXT_metal_surface[]
+=== Deprecation by `VK_EXT_metal_surface`
+
+The `VK_MVK_macos_surface` extension is considered deprecated and has been
+superseded by the `<<VK_EXT_metal_surface>>` extension.
+endif::VK_EXT_metal_surface[]
 
 include::{generated}/interfaces/VK_MVK_macos_surface.txt[]
 
@@ -30,5 +36,9 @@ include::{generated}/interfaces/VK_MVK_macos_surface.txt[]
    - Initial draft.
 
  * Revision 2, 2017-02-24 (Bill Hollings)
-   - Minor syntax fix to emphasize firm requirement for NSView to be backed
-     by a CAMetalLayer.
+   - Minor syntax fix to emphasize firm requirement for `NSView` to be
+     backed by a `CAMetalLayer`.
+
+ * Revision 3, 2020-07-31 (Bill Hollings)
+   - Update documentation on requirements for `NSView`.
+   - Mark as deprecated by `VK_EXT_metal_surface`.

chapters/VK_EXT_validation_features.txt

@@ -74,6 +74,12 @@ include::{generated}/api/enums/VkValidationFeatureEnableEXT.txt[]
     layers will process code:debugPrintfEXT operations in shaders and send
     the resulting output to the debug callback.
     This feature is disabled by default.
+  * ename:VK_VALIDATION_FEATURE_ENABLE_SYNCHRONIZATION_VALIDATION_EXT
+    specifies that Vulkan synchronization validation is enabled.
+    This feature reports resource access conflicts due to missing or
+    incorrect synchronization operations between actions (Draw, Copy,
+    Dispatch, Blit) reading or writing the same regions of memory.
+    This feature is disabled by default.
 
 --
 

chapters/VK_MVK_ios_surface/platformCreateSurface_ios.txt

@@ -9,10 +9,21 @@
 [open,refpage='vkCreateIOSSurfaceMVK',desc='Create a VkSurfaceKHR object for an iOS UIView',type='protos']
 --
 
-To create a sname:VkSurfaceKHR object for an iOS code:UIView, call:
+To create a sname:VkSurfaceKHR object for an iOS code:UIView or
+basetype:CAMetalLayer, call:
 
 include::{generated}/api/protos/vkCreateIOSSurfaceMVK.txt[]
 
+ifdef::VK_EXT_metal_surface[]
+[NOTE]
+.Note
+====
+The `vkCreateIOSSurfaceMVK` function is considered deprecated and has been
+superseded by flink:vkCreateMetalSurfaceEXT from the
+`<<VK_EXT_metal_surface>>` extension.
+====
+endif::VK_EXT_metal_surface[]
+
   * pname:instance is the instance with which to associate the surface.
   * pname:pCreateInfo is a pointer to a slink:VkIOSSurfaceCreateInfoMVK
     structure containing parameters affecting the creation of the surface
@@ -37,16 +48,18 @@ include::{generated}/api/structs/VkIOSSurfaceCreateInfoMVK.txt[]
   * pname:pNext is `NULL` or a pointer to a structure extending this
     structure.
   * pname:flags is reserved for future use.
-  * pname:pView is a reference to a code:UIView object which will display
-    this surface.
-    This code:UIView must: be backed by a code:CALayer instance of type
-    basetype:CAMetalLayer.
+  * pname:pView is a reference to either a basetype:CAMetalLayer object or a
+    code:UIView object.
 
 .Valid Usage
 ****
+  * [[VUID-VkIOSSurfaceCreateInfoMVK-pView-04143]]
+    If pname:pView is a basetype:CAMetalLayer object, it must: be a valid
+    basetype:CAMetalLayer.
   * [[VUID-VkIOSSurfaceCreateInfoMVK-pView-01316]]
-    pname:pView must: be a valid code:UIView and must: be backed by a
-    code:CALayer instance of type basetype:CAMetalLayer
+    If pname:pView is a code:UIView object, it must: be a valid code:UIView,
+    must: be backed by a code:CALayer object of type basetype:CAMetalLayer,
+    and flink:vkCreateIOSSurfaceMVK must: be called on the main thread.
 ****
 
 include::{generated}/validity/structs/VkIOSSurfaceCreateInfoMVK.txt[]

chapters/VK_MVK_macos_surface/platformCreateSurface_macos.txt

@@ -9,10 +9,21 @@
 [open,refpage='vkCreateMacOSSurfaceMVK',desc='Create a VkSurfaceKHR object for a macOS NSView',type='protos']
 --
 
-To create a sname:VkSurfaceKHR object for a macOS code:NSView, call:
+To create a sname:VkSurfaceKHR object for a macOS code:NSView or
+basetype:CAMetalLayer, call:
 
 include::{generated}/api/protos/vkCreateMacOSSurfaceMVK.txt[]
 
+ifdef::VK_EXT_metal_surface[]
+[NOTE]
+.Note
+====
+The `vkCreateMacOSSurfaceMVK` function is considered deprecated and has been
+superseded by flink:vkCreateMetalSurfaceEXT from the
+`<<VK_EXT_metal_surface>>` extension.
+====
+endif::VK_EXT_metal_surface[]
+
   * pname:instance is the instance with which to associate the surface.
   * pname:pCreateInfo is a pointer to a slink:VkMacOSSurfaceCreateInfoMVK
     structure containing parameters affecting the creation of the surface
@@ -37,16 +48,19 @@ include::{generated}/api/structs/VkMacOSSurfaceCreateInfoMVK.txt[]
   * pname:pNext is `NULL` or a pointer to a structure extending this
     structure.
   * pname:flags is reserved for future use.
-  * pname:pView is a reference to a code:NSView object which will display
-    this surface.
-    This code:NSView must: be backed by a code:CALayer instance of type
-    basetype:CAMetalLayer.
+  * pname:pView is a reference to either a basetype:CAMetalLayer object or
+    an code:NSView object.
 
 .Valid Usage
 ****
+  * [[VUID-VkMacOSSurfaceCreateInfoMVK-pView-04144]]
+    If pname:pView is a basetype:CAMetalLayer object, it must: be a valid
+    basetype:CAMetalLayer.
   * [[VUID-VkMacOSSurfaceCreateInfoMVK-pView-01317]]
-    pname:pView must: be a valid code:NSView and must: be backed by a
-    code:CALayer instance of type basetype:CAMetalLayer
+    If pname:pView is an code:NSView object, it must: be a valid
+    code:NSView, must: be backed by a code:CALayer object of type
+    basetype:CAMetalLayer, and flink:vkCreateMacOSSurfaceMVK must: be called
+    on the main thread.
 ****
 
 include::{generated}/validity/structs/VkMacOSSurfaceCreateInfoMVK.txt[]

chapters/fundamentals.txt

@@ -1255,10 +1255,20 @@ fields will be unmodified.
 Any structures chained from pname:pNext will also have undefined: contents,
 except that pname:sType and pname:pNext will be unmodified.
 
-Out of memory errors do not damage any currently existing Vulkan objects.
+etext:VK_ERROR_OUT_OF_*_MEMORY errors do not modify any currently existing
+Vulkan objects.
 Objects that have already been successfully created can: still be used by
 the application.
 
+[NOTE]
+.Note
+====
+As a general rule, ftext:Free, ftext:Release, and ftext:Reset commands do
+not return ename:VK_ERROR_OUT_OF_HOST_MEMORY, while any other command with a
+return code may: return it.
+Any exceptions from this rule are described for those commands.
+====
+
 ename:VK_ERROR_UNKNOWN will be returned by an implementation when an
 unexpected error occurs that cannot be attributed to valid behavior of the
 application and implementation.

chapters/initialization.txt

@@ -144,7 +144,7 @@ include::{generated}/validity/protos/vkGetDeviceProcAddr.txt[]
 
 --
 
-[open,refpage='PFN_vkVoidFunction',desc='Dummy function pointer type returned by queries',type='funcpointers',xrefs='vkGetDeviceProcAddr vkGetInstanceProcAddr']
+[open,refpage='PFN_vkVoidFunction',desc='Placeholder function pointer type returned by queries',type='funcpointers',xrefs='vkGetDeviceProcAddr vkGetInstanceProcAddr']
 --
 
 The definition of tlink:PFN_vkVoidFunction is:

chapters/memory.txt

@@ -1001,13 +1001,20 @@ endif::VK_VERSION_1_1[]
 The maximum number of valid memory allocations that can: exist
 simultaneously within a slink:VkDevice may: be restricted by implementation-
 or platform-dependent limits.
-If a call to flink:vkAllocateMemory would cause the total number of
-allocations to exceed these limits, such a call will fail and must: return
-ename:VK_ERROR_TOO_MANY_OBJECTS.
 The <<limits-maxMemoryAllocationCount,pname:maxMemoryAllocationCount>>
 feature describes the number of allocations that can: exist simultaneously
 before encountering these internal limits.
 
+[NOTE]
+.Note
+====
+For historical reasons, if pname:maxMemoryAllocationCount is exceeded, some
+implementations may return ename:VK_ERROR_TOO_MANY_OBJECTS.
+Exceeding this limit will result in undefined behavior, and an application
+should not rely on the use of the returned error code in order to identify
+when the limit is reached.
+====
+
 Some platforms may: have a limit on the maximum size of a single allocation.
 For example, certain systems may: fail to create allocations with a size
 greater than or equal to 4GB.

chapters/samplers.txt

@@ -149,8 +149,16 @@ The maximum number of sampler objects which can: be simultaneously created
 on a device is implementation-dependent and specified by the
 <<limits-maxSamplerAllocationCount,maxSamplerAllocationCount>> member of the
 slink:VkPhysicalDeviceLimits structure.
-If pname:maxSamplerAllocationCount is exceeded, fname:vkCreateSampler will
-return ename:VK_ERROR_TOO_MANY_OBJECTS.
+
+[NOTE]
+.Note
+====
+For historical reasons, if pname:maxSamplerAllocationCount is exceeded, some
+implementations may return ename:VK_ERROR_TOO_MANY_OBJECTS.
+Exceeding this limit will result in undefined behavior, and an application
+should not rely on the use of the returned error code in order to identify
+when the limit is reached.
+====
 
 Since slink:VkSampler is a non-dispatchable handle type, implementations
 may: return the same handle for sampler state vectors that are identical.

chapters/sparsemem.txt

@@ -557,14 +557,14 @@ Any implementation that cannot: access unbound pages without causing a fault
 will require the implementation to bind the entire device virtual address
 range to physical memory.
 Any pages that the application does not bind to memory may: be bound to one
-(or more) "`dummy`" physical page(s) allocated by the implementation.
+(or more) "`placeholder" physical page(s) allocated by the implementation.
 Given the following properties:
 
   * A process must: not access memory from another process
   * Reads return undefined: values
 
-It is sufficient for each host process to allocate these dummy pages and use
-them for all resources in that process.
+It is sufficient for each host process to allocate these placeholder pages
+and use them for all resources in that process.
 Implementations may: allocate more often (per instance, per device, or per
 resource).
 

registry.txt

@@ -1,4 +1,4 @@
-// Copyright (c) 2013-2020 Khronos Group.
+// Copyright 2013-2020 The Khronos Group Inc.
 //
 // SPDX-License-Identifier: CC-BY-4.0
 
@@ -1713,7 +1713,7 @@ extern "C" {
 #endif
 
 #if defined(VK_TYPE_SAFE_COMPATIBLE_HANDLES) && !defined(VK_DISABLE_TYPE_SAFE_HANDLES)
-    #define VK_DEFINE_PTR_HANDLE(_obj) struct _obj##_T { char _dummy; }; typedef _obj##_T* _obj;
+    #define VK_DEFINE_PTR_HANDLE(_obj) struct _obj##_T { char _placeholder; }; typedef _obj##_T* _obj;
     #define VK_DEFINE_PTR_SUBCLASS_HANDLE(_obj, _base) struct _obj##_T : public _base##_T {}; typedef _obj##_T* _obj;
 
     #define VK_DEFINE_BASE_HANDLE(_obj) VK_DEFINE_PTR_HANDLE(_obj)