Skip to content
Permalink
Browse files

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>>`
  • Loading branch information...
oddhack committed Oct 14, 2019
1 parent d82c1a8 commit a5b10770a313a4b1fcf74645c6041c6090630085
@@ -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.
@@ -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
@@ -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`]
@@ -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
@@ -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.
@@ -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
@@ -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.
@@ -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.


@@ -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.
@@ -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

@@ -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

0 comments on commit a5b1077

Please sign in to comment.
You can’t perform that action at this time.