Change log for April 26, 2020 Vulkan 1.2.139 spec update:

  * Update release number to 139 for this update.

Github Issues:

  * Configure Github CI with Azure pipelines and the Khronos Docker build
    image (public pull request 1141).
  * Move NOTE in flink:vkEnumerateInstanceVersion prior to valid usage
    statements (public pull request 1237).
  * Add `implicitexternsyncparams` to flink:vkDestroyInstance for
    slink:VkPhysicalDevice objects (public pull request 1244).
  * Note in the style guide that extension names are used as preprocessor
    symbols in all the generated Vulkan headers (public pull request 1245).
  * Move NOTE about app use of `switch` statements and Vulkan API enums from
    the style guide into the <<fundamentals-validusage-enums, Valid Usage
    for Enumerated Types>> section (public pull request 1246).
  * Modify generator script to use Unix newlines on all platforms (public
    pull request 1250).

Internal Issues:

  * Allow ename:VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT error to be
    generated by flink:vkQueuePresentKHR (internal issue 1932).
  * Update references to the SPIR-V Specification to version 1.5.3 (internal
    issue 1957).
  * Add a \<comment> explaining why the bitfields defined for
    slink:VkAccelerationStructureInstanceKHR in `vk.xml` are non-normative
    (internal issue 1975).
  * Add valid usage statement for flink:vkBindImageMemory2::pname:pBindInfos
    to prevent binding disjoint memory twice (internal merge request 3696).
  * Add valid usage statements to flink:vkGetBufferMemoryRequirements,
    flink:vkGetImageMemoryRequirements, and
    slink:VkBufferMemoryRequirementsInfo2 requiring that external Android
    hardware buffers be bound to memory (internal merge request 3717).
  * Fix implicit valid usage statement generation script for handle
    parameters with `optional="false,true"` XML attributes (internal merge
    request 3753).

New Extensions:

  * `<<VK_EXT_robustness2>>`
  * `<<VK_QCOM_render_pass_shader_resolve>>`

BUILD.adoc

@@ -364,6 +364,17 @@ Once docker is installed and the vulkan-docs image is available, it can be
 executed as described above under <<building, Building the Spec>> to
 generate Specification output documents or other Makefile targets.
 
+The `vulkan-docs` image includes a Docker 'entrypoint' script which can
+switch to a user and group specified on the docker command line, and which
+*always* runs /bin/bash as its final action. This may be undesirable
+behavior in some circumstances; for example, Azure Pipelines does not
+interact well with this entrypoint script. To support such uses, a more
+stripped-down build image is available from docker hub at
+
+    khronosgroup/docker-images:vulkan-docs-base
+
+This image omits the entrypoint script.
+
 
 [[depends-nondocker]]
 === Non-Docker Build Environments

ChangeLog.txt

@@ -8,6 +8,52 @@ public pull requests that have been accepted.
 
 -----------------------------------------------------
 
+Change log for April 26, 2020 Vulkan 1.2.139 spec update:
+
+  * Update release number to 139 for this update.
+
+Github Issues:
+
+  * Configure Github CI with Azure pipelines and the Khronos Docker build
+    image (public pull request 1141).
+  * Move NOTE in flink:vkEnumerateInstanceVersion prior to valid usage
+    statements (public pull request 1237).
+  * Add `implicitexternsyncparams` to flink:vkDestroyInstance for
+    slink:VkPhysicalDevice objects (public pull request 1244).
+  * Note in the style guide that extension names are used as preprocessor
+    symbols in all the generated Vulkan headers (public pull request 1245).
+  * Move NOTE about app use of `switch` statements and Vulkan API enums from
+    the style guide into the <<fundamentals-validusage-enums, Valid Usage
+    for Enumerated Types>> section (public pull request 1246).
+  * Modify generator script to use Unix newlines on all platforms (public
+    pull request 1250).
+
+Internal Issues:
+
+  * Allow ename:VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT error to be
+    generated by flink:vkQueuePresentKHR (internal issue 1932).
+  * Update references to the SPIR-V Specification to version 1.5.3 (internal
+    issue 1957).
+  * Add a \<comment> explaining why the bitfields defined for
+    slink:VkAccelerationStructureInstanceKHR in `vk.xml` are non-normative
+    (internal issue 1975).
+  * Add valid usage statement for flink:vkBindImageMemory2::pname:pBindInfos
+    to prevent binding disjoint memory twice (internal merge request 3696).
+  * Add valid usage statements to flink:vkGetBufferMemoryRequirements,
+    flink:vkGetImageMemoryRequirements, and
+    slink:VkBufferMemoryRequirementsInfo2 requiring that external Android
+    hardware buffers be bound to memory (internal merge request 3717).
+  * Fix implicit valid usage statement generation script for handle
+    parameters with `optional="false,true"` XML attributes (internal merge
+    request 3753).
+
+New Extensions:
+
+  * `<<VK_EXT_robustness2>>`
+  * `<<VK_QCOM_render_pass_shader_resolve>>`
+
+-----------------------------------------------------
+
 Change log for April 16, 2020 Vulkan 1.2.138 spec update:
 
   * Update release number to 138 for this update.

Makefile

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

appendices/VK_EXT_robustness2.txt

@@ -0,0 +1,81 @@
+include::{generated}/meta/{refprefix}VK_EXT_robustness2.txt[]
+
+=== Other Extension Metadata
+
+*Last Modified Date*::
+    2020-01-29
+*IP Status*::
+    No known IP claims.
+*Contributors*::
+    - Liam Middlebrook, NVIDIA
+    - Jeff Bolz, NVIDIA
+
+=== Description
+
+This extension adds stricter requirements for how out of bounds reads and
+writes are handled.
+Most accesses must: be tightly bounds-checked, out of bounds writes must: be
+discarded, out of bound reads must: return zero.
+Rather than allowing multiple possible [eq]#(0,0,0,x)# vectors, the out of
+bounds values are treated as zero, and then missing components are inserted
+based on the format as described in <<textures-conversion-to-rgba,
+Conversion to RGBA>> and <<fxvertex-input-extraction,vertex input attribute
+extraction>>.
+
+These additional requirements may: be expensive on some implementations, and
+should only be enabled when truly necessary.
+
+This extension also adds support for "null descriptors", where
+dlink:VK_NULL_HANDLE can: be used instead of a valid handle.
+Accesses to null descriptors have well-defined behavior, and don't rely on
+robustness.
+
+
+=== New Object Types
+
+None.
+
+=== New Enum Constants
+
+    * Extending elink:VkStructureType:
+    ** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ROBUSTNESS_2_FEATURES_EXT
+    ** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ROBUSTNESS_2_PROPERTIES_EXT
+
+=== New Enums
+
+None.
+
+=== New Structures
+
+    * slink:VkPhysicalDeviceRobustness2FeaturesEXT
+    * slink:VkPhysicalDeviceRobustness2PropertiesEXT
+
+=== New Functions
+
+None.
+
+=== Issues
+
+1. Why do
+   slink:VkPhysicalDeviceRobustness2PropertiesEXT::pname:robustUniformBufferAccessSizeAlignment
+   and
+   slink:VkPhysicalDeviceRobustness2PropertiesEXT::pname:robustStorageBufferAccessSizeAlignment
+   exist?
+
+RESOLVED: Some implementations can't efficiently tightly bounds-check all
+buffer accesses.
+Rather, the size of the bound range is padded to some power of two multiple,
+up to 256 bytes for uniform buffers and up to 4 bytes for storage buffers,
+and that padded size is bounds-checked.
+This is sufficient to implement D3D-like behavior, because D3D only allows
+binding whole uniform buffers or ranges that are a multiple of 256 bytes,
+and D3D raw and structured buffers only support 32-bit accesses.
+
+=== Examples
+
+None.
+
+=== Version History
+
+    * Revision 1, 2019-11-01 (Jeff Bolz, Liam Middlebrook)
+        - Initial draft

appendices/VK_QCOM_render_pass_shader_resolve.txt

@@ -0,0 +1,116 @@
+include::{generated}/meta/{refprefix}VK_QCOM_render_pass_shader_resolve.txt[]
+
+=== Other Extension Metadata
+
+*Last Modified Date*::
+    2019-11-07
+*IP Status*::
+    No known IP claims.
+*Interactions and External Dependencies*::
+    None.
+*Contributors*::
+  - Srihari Babu Alla, Qualcomm
+  - Bill Licea-Kane, Qualcomm
+  - Jeff Leger, Qualcomm
+
+=== Description
+
+This extension allows a shader resolve to replace fixed-function resolve.
+
+Fixed-function resolve is limited in function to simple filters of
+multisample buffers to a single sample buffer.
+
+Fixed-function resolve is more performance efficient and/or power efficient
+than shader resolve for such simple filters.
+
+Shader resolve allows a shader writer to create complex, non-linear
+filtering of a multisample buffer in the last subpass of a subpass
+dependency chain.
+
+This extension also provides a bit which can: be used to enlarge a sample
+region dependency to a fragment region dependency, so that a
+framebuffer-region dependency can: replace a framebuffer-global dependency
+in some cases.
+
+=== New Object Types
+
+None.
+
+=== New Enum Constants
+
+  * Extending elink:VkSubpassDescriptionFlagBits
+  ** ename:VK_SUBPASS_DESCRIPTION_FRAGMENT_REGION_BIT_QCOM
+  ** ename:VK_SUBPASS_DESCRIPTION_SHADER_RESOLVE_BIT_QCOM
+
+=== New Enums
+
+None.
+
+=== New Structures
+
+None.
+
+=== New Functions
+
+None.
+
+=== New Built-In Variables
+
+None.
+
+=== New SPIR-V Capabilities
+
+None.
+
+=== Issues
+
+1) Should this extension be named render_pass_shader_resolve?
+
+*RESOLVED* Yes.
+
+This is part of suite of small extensions to render pass.
+
+Following the style guide, instead of following VK_KHR_create_renderpass2.
+
+2) Should the VK_SAMPLE_COUNT_1_BIT be required for each pColorAttachment
+and the DepthStencilAttachent?
+
+*RESOLVED* No.
+
+While this may not be a common use case, and while most fixed-function
+resolve hardware has this limitation, there is little reason to require a
+shader resolve to resolve to a single sample buffer.
+
+3) Should a shader resolve subpass be the last subpass in a renderpass?
+
+*RESOLVED* Yes.
+
+To be more specific, it should be the last subpass in a subpass dependency
+chain.
+
+4) Do we need the ename:VK_SUBPASS_DESCRIPTION_FRAGMENT_REGION_BIT_QCOM bit?
+
+*RESOLVED* Yes.
+
+This applies when an input attachment's sample count is equal to
+pname:rasterizationSamples.
+Further, if pname:sampleShading is enabled (explicitly or implicitly) then
+pname:minSampleShading must: equal 0.0.
+
+However, this bit may be set on any subpass, it is not restricted to a
+shader resolve subpass.
+
+=== Version History
+
+  * Revision 1, 2019-06-28 (wwlk)
+    - Initial draft
+  * Revision 2, 2019-11-06 (wwlk)
+    - General clean-up/spec updates
+    - Added issues
+  * Revision 3, 2019-11-07 (wwlk)
+    - Typos
+    - Additional issues
+    - Clarified that a shader resolve subpass is the last subpass in a
+      subpass dependency chain
+  * Revision 4, 2020-01-06 (wwlk)
+    - Change resolution of Issue 1 (_render_pass_, not _renderpass_)

chapters/VK_KHR_swapchain/wsi.txt

@@ -1190,8 +1190,11 @@ unable to make that guarantee, the implementation must: return
 ename:VK_ERROR_DEVICE_LOST.
 
 However, if the presentation request is rejected by the presentation engine
-with an error ename:VK_ERROR_OUT_OF_DATE_KHR or
-ename:VK_ERROR_SURFACE_LOST_KHR, the set of queue operations are still
+with an error ename:VK_ERROR_OUT_OF_DATE_KHR,
+ifdef::VK_EXT_full_screen_exclusive[]
+ename:VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT,
+endif::VK_EXT_full_screen_exclusive[]
+or ename:VK_ERROR_SURFACE_LOST_KHR, the set of queue operations are still
 considered to be enqueued and thus any semaphore wait operation specified in
 slink:VkPresentInfoKHR will execute when the corresponding queue operation
 is complete.

chapters/commonvalidity/draw_vertex_binding.txt

@@ -1,9 +1,14 @@
 // Common Valid Usage
 // Common to drawing commands that consume vertex binding state
-  * [[VUID-{refpage}-None-02720]]
+  * [[VUID-{refpage}-None-04007]]
     All vertex input bindings accessed via vertex input variables declared
-    in the vertex shader entry point's interface must: have valid buffers
-    bound
+    in the vertex shader entry point's interface must: have either valid or
+    dlink:VK_NULL_HANDLE buffers bound
+  * [[VUID-{refpage}-None-04008]]
+    If the <<features-nullDescriptor,nullDescriptor>> feature is not
+    enabled, all vertex input bindings accessed via vertex input variables
+    declared in the vertex shader entry point's interface must: not be
+    dlink:VK_NULL_HANDLE
   * [[VUID-{refpage}-None-02721]]
     For a given vertex buffer binding, any attribute data fetched must: be
     entirely contained within the corresponding vertex buffer binding, as