mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-25 04:25:12 +00:00
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>>`
This commit is contained in:
Jon Leech
parent
d82c1a8d49
commit
a5b10770a3
@ -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.
|
||||
|
||||
2
Makefile
2
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
|
||||
|
||||
@ -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`]
|
||||
|
||||
123
appendices/VK_KHR_spirv_1_4.txt
Normal file
123
appendices/VK_KHR_spirv_1_4.txt
Normal file
@ -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,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.
|
||||
|
||||
@ -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
|
||||
The implementation must: ensure the access rights allow read and write
|
||||
access to the memory.
|
||||
|
||||
code:GENERIC_ALL
|
||||
|
||||
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
|
||||
|
||||
@ -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
|
||||
<<synchronization-access-types-supported, table of supported access
|
||||
types>>.
|
||||
* [[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
|
||||
<<synchronization-buffer-memory-barriers, buffer memory barrier>> (for a
|
||||
buffer range) or an <<synchronization-image-memory-barriers, image memory
|
||||
barrier>> (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
|
||||
<<synchronization-buffer-memory-barriers, buffer memory barrier>> (for a
|
||||
buffer range) or an <<synchronization-image-memory-barriers, image memory
|
||||
barrier>> (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 <<synchronization-events>> 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
|
||||
|
||||
@ -1,2 +1,2 @@
|
||||
# The value to start tagging VU statements at, unless overridden by -nextvu
|
||||
startVUID = 2802
|
||||
startVUID = 2805
|
||||
|
||||
16
xml/vk.xml
16
xml/vk.xml
@ -154,7 +154,7 @@ server.
|
||||
<type category="define">// Vulkan 1.1 version number
|
||||
#define <name>VK_API_VERSION_1_1</name> <type>VK_MAKE_VERSION</type>(1, 1, 0)// Patch version should always be set to 0</type>
|
||||
<type category="define">// Version of this file
|
||||
#define <name>VK_HEADER_VERSION</name> 124</type>
|
||||
#define <name>VK_HEADER_VERSION</name> 125</type>
|
||||
|
||||
<type category="define">
|
||||
#define <name>VK_DEFINE_HANDLE</name>(object) typedef struct object##_T* object;</type>
|
||||
@ -3812,7 +3812,7 @@ typedef void <name>CAMetalLayer</name>;
|
||||
<member><type>VkExtent2D</type> <name>maxFragmentDensityTexelSize</name></member>
|
||||
<member><type>VkBool32</type> <name>fragmentDensityInvocations</name></member>
|
||||
</type>
|
||||
<type category="struct" name="VkRenderPassFragmentDensityMapCreateInfoEXT" structextends="VkRenderPassCreateInfo">
|
||||
<type category="struct" name="VkRenderPassFragmentDensityMapCreateInfoEXT" structextends="VkRenderPassCreateInfo,VkRenderPassCreateInfo2KHR">
|
||||
<member values="VK_STRUCTURE_TYPE_RENDER_PASS_FRAGMENT_DENSITY_MAP_CREATE_INFO_EXT"><type>VkStructureType</type> <name>sType</name></member>
|
||||
<member>const <type>void</type>* <name>pNext</name></member>
|
||||
<member><type>VkAttachmentReference</type> <name>fragmentDensityMapAttachment</name></member>
|
||||
@ -11173,10 +11173,10 @@ typedef void <name>CAMetalLayer</name>;
|
||||
<enum value=""VK_AMD_extension_236"" name="VK_AMD_EXTENSION_236_EXTENSION_NAME"/>
|
||||
</require>
|
||||
</extension>
|
||||
<extension name="VK_KHR_extension_237" number="237" author="KHR" contact="Jesse Hall @critsec" supported="disabled">
|
||||
<extension name="VK_KHR_spirv_1_4" number="237" type="device" requiresCore="1.1" requires="VK_KHR_shader_float_controls" author="KHR" contact="Jesse Hall @critsec" supported="vulkan">
|
||||
<require>
|
||||
<enum value="0" name="VK_KHR_EXTENSION_237_SPEC_VERSION"/>
|
||||
<enum value=""VK_KHR_extension_237"" name="VK_KHR_EXTENSION_237_EXTENSION_NAME"/>
|
||||
<enum value="1" name="VK_KHR_SPIRV_1_4_SPEC_VERSION"/>
|
||||
<enum value=""VK_KHR_spirv_1_4"" name="VK_KHR_SPIRV_1_4_EXTENSION_NAME"/>
|
||||
</require>
|
||||
</extension>
|
||||
<extension name="VK_EXT_memory_budget" number="238" type="device" requires="VK_KHR_get_physical_device_properties2" author="EXT" contact="Jeff Bolz @jeffbolznv" supported="vulkan">
|
||||
@ -11629,5 +11629,11 @@ typedef void <name>CAMetalLayer</name>;
|
||||
<enum value=""VK_NV_extension_293"" name="VK_NV_EXTENSION_293_EXTENSION_NAME"/>
|
||||
</require>
|
||||
</extension>
|
||||
<extension name="VK_KHR_extension_294" number="294" author="KHR" contact="Baldur Karlsson @baldurk" supported="disabled">
|
||||
<require>
|
||||
<enum value="0" name="VK_KHR_EXTENSION_294_SPEC_VERSION"/>
|
||||
<enum value=""VK_KHR_extension_294"" name="VK_KHR_EXTENSION_294_EXTENSION_NAME"/>
|
||||
</require>
|
||||
</extension>
|
||||
</extensions>
|
||||
</registry>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user