diff --git a/ChangeLog.txt b/ChangeLog.txt index 3ac17cdad6..d3e6136da4 100644 --- a/ChangeLog.txt +++ b/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 `<>` 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 <> 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 <> (internal merge request 3391). + * Fix a typo in flink:vkQueueBindSparse valid usage statement 03245 + (internal merge request 3394). + +New Extensions + + * `<>` + +----------------------------------------------------- + Change log for October 6, 2019 Vulkan 1.1.124 spec update: * Update release number to 124. diff --git a/Makefile b/Makefile index 66caf9b4f1..0fcf2e371a 100644 --- a/Makefile +++ b/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 diff --git a/appendices/VK_EXT_external_memory_dma_buf.txt b/appendices/VK_EXT_external_memory_dma_buf.txt index da1d37bb22..36518f93b1 100644 --- a/appendices/VK_EXT_external_memory_dma_buf.txt +++ b/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`] diff --git a/appendices/VK_KHR_spirv_1_4.txt b/appendices/VK_KHR_spirv_1_4.txt new file mode 100644 index 0000000000..2d3eaa946d --- /dev/null +++ b/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 +<> 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 <>. +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 +<>. +However, if it doesn't have this knowledge and has to query for support at +runtime, it must enable <> in order to use +slink:VkPhysicalDeviceFloatControlsPropertiesKHR. + +=== Version History + + * Revision 1, 2019-04-01 (Jesse Hall) + - Internal draft versions diff --git a/appendices/spirvenv.txt b/appendices/spirvenv.txt index 5285353c9d..733b9310df 100644 --- a/appendices/spirvenv.txt +++ b/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 <> 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,9 +1297,9 @@ 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() @@ -1303,9 +1307,9 @@ different sign than the infinitely precise result. | 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. diff --git a/chapters/commonvalidity/query_begin_common.txt b/chapters/commonvalidity/query_begin_common.txt index c79fa31569..34d6f44437 100644 --- a/chapters/commonvalidity/query_begin_common.txt +++ b/chapters/commonvalidity/query_begin_common.txt @@ -4,6 +4,9 @@ <> 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 <> feature is not enabled, or the pname:queryType used to create diff --git a/chapters/descriptorsets.txt b/chapters/descriptorsets.txt index dd6ad85c4a..b7898fd2ab 100644 --- a/chapters/descriptorsets.txt +++ b/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. diff --git a/chapters/devsandqueues.txt b/chapters/devsandqueues.txt index ff223008b2..9ad4665374 100644 --- a/chapters/devsandqueues.txt +++ b/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 <>) 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 <>), 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 <> section for details. diff --git a/chapters/introduction.txt b/chapters/introduction.txt index aa915feca1..b6aa034acb 100644 --- a/chapters/introduction.txt +++ b/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. diff --git a/chapters/memory.txt b/chapters/memory.txt index b688022dce..f50a8caf38 100644 --- a/chapters/memory.txt +++ b/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 diff --git a/chapters/sparsemem.txt b/chapters/sparsemem.txt index 7c0ae4583f..418117719d 100644 --- a/chapters/sparsemem.txt +++ b/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 diff --git a/chapters/synchronization.txt b/chapters/synchronization.txt index 6c83dcd175..9ced57f203 100644 --- a/chapters/synchronization.txt +++ b/chapters/synchronization.txt @@ -2449,22 +2449,23 @@ 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 -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_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_BIT -And +The implementation must: ensure the access rights allow both signal and wait +operations on the semaphore. -code:GENERIC_ALL - -for handles of the following types: +For handles of the following types: ename:VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_D3D12_FENCE_BIT +The access rights must: be: + +code:GENERIC_ALL + 1:: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686670.aspx @@ -3912,6 +3913,9 @@ flink:vkCmdWaitEvents is used with flink:vkCmdSetEvent to define a memory dependency between two sets of action commands, roughly in the same way as pipeline barriers, but split into two commands such that work between the two may: execute unhindered. +Unlike flink:vkCmdPipelineBarrier, a queue family ownership transfer can't +be performed using flink:vkCmdWaitEvents since events only support +host/queue and intra-queue dependencies. ==== [NOTE] @@ -3976,6 +3980,10 @@ semaphore). the pipeline stages in pname:dstStageMask, as specified in the <>. + * [[VUID--srcQueueFamilyIndex-02803]] + The pname:srcQueueFamilyIndex and pname:dstQueueFamilyIndex members of + any element of pname:pBufferMemoryBarriers or pname:pImageMemoryBarriers + must: be equal. ifdef::VK_VERSION_1_1,VK_KHR_device_group[] * [[VUID-vkCmdWaitEvents-commandBuffer-01167]] pname:commandBuffer's current device mask must: include exactly one @@ -4850,8 +4858,8 @@ range. A release operation is defined by executing a <> (for a buffer range) or an <> (for an image subresource range), on a queue from the source queue -family. +barrier>> (for an image subresource range) using flink:vkCmdPipelineBarrier, +on a queue from the source queue family. The pname:srcQueueFamilyIndex parameter of the barrier must: be set to the source queue family index, and the pname:dstQueueFamilyIndex parameter to the destination queue family index. @@ -4866,8 +4874,8 @@ range. An acquire operation is defined by executing a <> (for a buffer range) or an <> (for an image subresource range), on a queue from the destination -queue family. +barrier>> (for an image subresource range) using flink:vkCmdPipelineBarrier, +on a queue from the destination queue family. The buffer range or image subresource range specified in an acquire operation must: match exactly that of a previous release operation. The pname:srcQueueFamilyIndex parameter of the barrier must: be set to the @@ -4925,6 +4933,16 @@ The contents of any portion of another resource which aliases memory that is bound to the transferred buffer or image subresource range are undefined: after a release or acquire operation. +[NOTE] +.Note +==== +Because <> can't be used directly for inter-queue +synchronization, and because flink:vkCmdSetEvent doesn't have the queue +family index or memory barrier parameters needed by a _release operation_, +the release and acquire operations of a queue family ownership transfer can: +only be performed using flink:vkCmdPipelineBarrier. +==== + [[synchronization-wait-idle]] == Wait Idle Operations diff --git a/scripts/reflow_count.py b/scripts/reflow_count.py index 6ee7081d3c..74d0a9f6f4 100644 --- a/scripts/reflow_count.py +++ b/scripts/reflow_count.py @@ -1,2 +1,2 @@ # The value to start tagging VU statements at, unless overridden by -nextvu -startVUID = 2802 +startVUID = 2805 diff --git a/xml/vk.xml b/xml/vk.xml index 832a41a524..3f5ca9c826 100644 --- a/xml/vk.xml +++ b/xml/vk.xml @@ -154,7 +154,7 @@ server. // Vulkan 1.1 version number #define VK_API_VERSION_1_1 VK_MAKE_VERSION(1, 1, 0)// Patch version should always be set to 0 // Version of this file -#define VK_HEADER_VERSION 124 +#define VK_HEADER_VERSION 125 #define VK_DEFINE_HANDLE(object) typedef struct object##_T* object; @@ -3812,7 +3812,7 @@ typedef void CAMetalLayer; VkExtent2D maxFragmentDensityTexelSize VkBool32 fragmentDensityInvocations - + VkStructureType sType const void* pNext VkAttachmentReference fragmentDensityMapAttachment @@ -11173,10 +11173,10 @@ typedef void CAMetalLayer; - + - - + + @@ -11629,5 +11629,11 @@ typedef void CAMetalLayer; + + + + + +