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
-allows sharing memory across kernel device drivers and across processes.
+A code:dma_buf is a type of file descriptor, defined by the Linux kernel,
+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?
-In other words, how does the application achieve behavior comparable to
-that provided by
+modifier) of the slink:VkImage? In other words, how does the application
+achieve behavior comparable to 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,19 +1297,19 @@ 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()
   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: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
-2+| Correctly rounded.
+| code:faceforward(N, I, NRef)
+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
-    pointer to an array of sampler handles that will be consumed by the set
-    layout and used for the corresponding binding.
+    If pname:pImmutableSamplers is not `NULL`, then it points to an array of
+    sampler handles that will be copied into the set layout and used for the
+    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
-is specified to allow the ownership of a buffer or image to be transferred
-from one queue family to another.
+(see <<synchronization-pipeline-barriers>>), a source and destination queue
+family index is specified to allow the ownership of a buffer or image to be
+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
-
-code:GENERIC_ALL
+The implementation must: ensure the access rights allow read and write
+access to the memory.
 
-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