status-im
/
Vulkan-Docs
mirror of https://github.com/status-im/Vulkan-Docs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Change log for February 17, 2019 Vulkan 1.1.101 spec update: 

* Update release number to 101.

Public Issues:

  * Make clear that memory types for imported host memory must be host
    visible in slink:VkMemoryHostPointerPropertiesEXT.txt (public issue
    897).
  * Make <<interfaces-resources-layout, WARNING block>> into a NOTE block,
    per the styleguide (public pull request 916).

Internal Issues:

  * Make <<textures-output-format-conversion, computation of derivatives in
    non-uniform flow control>> have undefined behavior (internal issue
    1367).
  * Make behavior, not just values, undefined for
    <<textures-layout-validation, reads from inconsistent YCbCr layouts>>
    (internal issue 1366).
  * Consolidate version and extension behavior documentation in the
    <<extended-functionality, Extended Functionality>> appendix, While a
    great deal of text was moved from other parts of the Specification into
    the appendix, this just serves to simplify and make consistent
    discussions of versions and extensions (internal issue 1473).
  * Add limits for slink:VkPhysicalDeviceRayTracingPropertiesNV in the
    <<features-limits-types, Required Limit Types>> and
    <<features-limits-required, Required Limits>> tables (internal issue
    1511).
  * Disallow <<memory-protected-memory, indirect calls within protected
    command buffers>> by adding valid usage statements for the related
    indirect dispatch and draw commands (internal issue 1513).
  * Add valid usage stataements to slink:VkGraphicsPipelineCreateInfo,
    slink:VkSubpassDescription, slink:VkSubpassDescription2KHR,
    slink:VkSubpassDescriptionDepthStencilResolveKHR, and
    slink:VkImageViewCreateInfo preventing the creation of a renderpass with
    attachments in formats that are not supported for rendering (internal
    issue 1552).
  * Qualify valid usage statements for
    slink:VkAttachmentReference::pname:layout parameter so restrictions only
    apply if an attachment is ename:VK_ATTACHMENT_UNUSED (internal issue
    1561).
  * Add valid usage statement for flink:vkCmdDrawIndirectByteCountEXT
    restricting pname:vertexStride to be positive (internal issue 1566).
  * Make the `VK_EXT_sample_locations` extension depend on
    `VK_KHR_get_physical_device_properties2` in `vk.xml`.
  * Rearrange and simplify the <<interfaces-resources-layout, block layout
    rules>>.

New Extensions:

  * `VK_NV_cooperative_matrix`
  * `VK_EXT_depth_clip_enable` (internal issue 1485).
This commit is contained in:
Jon Leech 2019-02-15 04:00:36 -08:00
parent f7d3f5dd78
commit 55220784e0
34 changed files with 1414 additions and 532 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
ChangeLog.txt
View File

@ -8,6 +8,62 @@ public pull requests that have been accepted.
-----------------------------------------------------
Change log for February 17, 2019 Vulkan 1.1.101 spec update:
* Update release number to 101.
Public Issues:
* Make clear that memory types for imported host memory must be host
visible in slink:VkMemoryHostPointerPropertiesEXT.txt (public issue
897).
* Make <<interfaces-resources-layout, WARNING block>> into a NOTE block,
per the styleguide (public pull request 916).
Internal Issues:
* Make <<textures-output-format-conversion, computation of derivatives in
non-uniform flow control>> have undefined behavior (internal issue
1367).
* Make behavior, not just values, undefined for
<<textures-layout-validation, reads from inconsistent YCbCr layouts>>
(internal issue 1366).
* Consolidate version and extension behavior documentation in the
<<extended-functionality, Extended Functionality>> appendix, While a
great deal of text was moved from other parts of the Specification into
the appendix, this just serves to simplify and make consistent
discussions of versions and extensions (internal issue 1473).
* Add limits for slink:VkPhysicalDeviceRayTracingPropertiesNV in the
<<features-limits-types, Required Limit Types>> and
<<features-limits-required, Required Limits>> tables (internal issue
1511).
* Disallow <<memory-protected-memory, indirect calls within protected
command buffers>> by adding valid usage statements for the related
indirect dispatch and draw commands (internal issue 1513).
* Add valid usage stataements to slink:VkGraphicsPipelineCreateInfo,
slink:VkSubpassDescription, slink:VkSubpassDescription2KHR,
slink:VkSubpassDescriptionDepthStencilResolveKHR, and
slink:VkImageViewCreateInfo preventing the creation of a renderpass with
attachments in formats that are not supported for rendering (internal
issue 1552).
* Qualify valid usage statements for
slink:VkAttachmentReference::pname:layout parameter so restrictions only
apply if an attachment is ename:VK_ATTACHMENT_UNUSED (internal issue
1561).
* Add valid usage statement for flink:vkCmdDrawIndirectByteCountEXT
restricting pname:vertexStride to be positive (internal issue 1566).
* Make the `VK_EXT_sample_locations` extension depend on
`VK_KHR_get_physical_device_properties2` in `vk.xml`.
* Rearrange and simplify the <<interfaces-resources-layout, block layout
rules>>.
New Extensions:
* `VK_NV_cooperative_matrix`
* `VK_EXT_depth_clip_enable` (internal issue 1485).
-----------------------------------------------------
Change log for February 10, 2019 Vulkan 1.1.100 spec update:
* Update release number to 100.

2
Makefile
View File

@ -115,7 +115,7 @@ VERBOSE =
# ADOCOPTS options for asciidoc->HTML5 output
NOTEOPTS = -a editing-notes -a implementation-guide
PATCHVERSION = 100
PATCHVERSION = 101
ifneq (,$(findstring VK_VERSION_1_1,$(VERSIONS)))
SPECREVISION = 1.1.$(PATCHVERSION)
else

53
appendices/VK_EXT_depth_clip_enable.txt Normal file
View File

@ -0,0 +1,53 @@
include::meta/VK_EXT_depth_clip_enable.txt[]
*Last Modified Data*::
2018-12-20
*Contributors*::
- Daniel Rakos, AMD
- Henri Verbeet, CodeWeavers
- Jeff Bolz, NVIDIA
- Philip Rebohle, DXVK
- Tobias Hector, AMD
This extension allows the depth clipping operation, that is normally
implicitly controlled by
slink:VkPipelineRasterizationStateCreateInfo::pname:depthClampEnable, to
instead be controlled explicitly by
slink:VkPipelineRasterizationDepthClipStateCreateInfoEXT::pname:depthClipEnable.
This is useful for translating DX content which assumes depth clamping is
always enabled, but depth clip can be controlled by the DepthClipEnable
rasterization state (D3D12_RASTERIZER_DESC).
=== New Object Types
None
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLIP_ENABLE_FEATURES_EXT
** ename:VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_DEPTH_CLIP_STATE_CREATE_INFO_EXT
=== New Enums
* tlink:VkPipelineRasterizationDepthClipStateCreateFlagsEXT
=== New Structures
* slink:VkPhysicalDeviceDepthClipEnableFeaturesEXT
* slink:VkPipelineRasterizationDepthClipStateCreateInfoEXT
=== New Functions
None
=== Issues
None
=== Version History
* Revision 1, 2018-12-20 (Piers Daniell)
- Internal revisions

78
appendices/VK_NV_cooperative_matrix.txt Normal file
View File

@ -0,0 +1,78 @@
include::meta/VK_NV_cooperative_matrix.txt[]
*Last Modified Data*::
2019-02-05
*Contributors*::
- Jeff Bolz, NVIDIA
- Markus Tavenrath, NVIDIA
- Daniel Koch, NVIDIA
This extension adds support for using cooperative matrix types in SPIR-V.
Cooperative matrix types are medium-sized matrices that are primarily
supported in compute shaders, where the storage for the matrix is spread
across all invocations in some scope (usually a subgroup) and those
invocations cooperate to efficiently perform matrix multiplies.
Cooperative matrix types are defined by the
http://htmlpreview.github.io/?https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/NV/SPV_NV_cooperative_matrix.html[+SPV_NV_cooperative_matrix+]
SPIR-V extension and can be used with the
https://github.com/KhronosGroup/GLSL/blob/master/extensions/nv/GLSL_NV_cooperative_matrix.txt[+GL_NV_cooperative_matrix+]
GLSL extension.
This extension includes support for enumerating the matrix types and
dimensions that are supported by the implementation.
=== New Object Types
None.
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_FEATURES_NV
** ename:VK_STRUCTURE_TYPE_COOPERATIVE_MATRIX_PROPERTIES_NV
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_PROPERTIES_NV
=== New Enums
* elink:VkScopeNV
* elink:VkComponentTypeNV
=== New Structures
* Extending slink:VkPhysicalDeviceFeatures2:
** slink:VkPhysicalDeviceCooperativeMatrixFeaturesNV
* Extending slink:VkPhysicalDeviceProperties2:
** slink:VkPhysicalDeviceCooperativeMatrixPropertiesNV
* slink:VkCooperativeMatrixPropertiesNV
=== New Functions
* flink:vkGetPhysicalDeviceCooperativeMatrixPropertiesNV
=== New SPIR-V Capabilities
* <<spirvenv-capabilities-table-cooperativeMatrix,CooperativeMatrixNV>>
=== Issues
(1) What matrix properties will be supported in practice?
RESOLVED: In NVIDIA's initial implementation, we will support:
* AType = BType = fp16 CType = DType = fp16 MxNxK = 16x8x16 scope =
Subgroup
* AType = BType = fp16 CType = DType = fp16 MxNxK = 16x8x8 scope =
Subgroup
* AType = BType = fp16 CType = DType = fp32 MxNxK = 16x8x16 scope =
Subgroup
* AType = BType = fp16 CType = DType = fp32 MxNxK = 16x8x8 scope =
Subgroup
=== Version History
* Revision 1, 2019-02-05 (Jeff Bolz)
- Internal revisions

97
appendices/boilerplate.txt
View File

@ -131,94 +131,7 @@ In addition to the Vulkan API, `vulkan_core.h` also defines a small number
of C preprocessor macros that are described below.
[[boilerplate-versions]]
==== Vulkan Version Number Macros
<<fundamentals-versionnum,API Version Numbers>> are packed into integers.
These macros manipulate version numbers in useful ways.
[open,refpage='VK_VERSION_MAJOR',desc='Extract API major version number',type='defines']
--
dname:VK_VERSION_MAJOR extracts the API major version number from a packed
version number:
include::../api/defines/VK_VERSION_MAJOR.txt[]
--
[open,refpage='VK_VERSION_MINOR',desc='Extract API minor version number',type='defines']
--
dname:VK_VERSION_MINOR extracts the API minor version number from a packed
version number:
include::../api/defines/VK_VERSION_MINOR.txt[]
--
[open,refpage='VK_VERSION_PATCH',desc='Extract API patch version number',type='defines']
--
dname:VK_VERSION_PATCH extracts the API patch version number from a packed
version number:
include::../api/defines/VK_VERSION_PATCH.txt[]
--
[open,refpage='VK_API_VERSION_1_0',desc='Return API version number for Vulkan 1.0',type='defines',xrefs='vkCreateInstance vkGetPhysicalDeviceProperties']
--
dname:VK_API_VERSION_1_0 returns the API version number for Vulkan 1.0.
The patch version number in this macro will always be zero.
The supported patch version for a physical device can: be queried with
flink:vkGetPhysicalDeviceProperties.
include::../api/defines/VK_API_VERSION_1_0.txt[]
--
ifdef::VK_VERSION_1_1[]
[open,refpage='VK_API_VERSION_1_1',desc='Return API version number for Vulkan 1.1',type='defines',xrefs='vkCreateInstance vkGetPhysicalDeviceProperties']
--
dname:VK_API_VERSION_1_1 returns the API version number for Vulkan 1.1.
The patch version number in this macro will always be zero.
The supported patch version for a physical device can: be queried with
flink:vkGetPhysicalDeviceProperties.
include::../api/defines/VK_API_VERSION_1_1.txt[]
--
endif::VK_VERSION_1_1[]
[open,refpage='VK_API_VERSION',desc='Deprecated version number macro',type='defines']
--
dname:VK_API_VERSION is now commented out of `vulkan_core.h` and cannot: be
used.
include::../api/defines/VK_API_VERSION.txt[]
--
[open,refpage='VK_MAKE_VERSION',desc='Construct an API version number',type='defines',xrefs='VkApplicationInfo vkCreateInstance']
--
dname:VK_MAKE_VERSION constructs an API version number.
include::../api/defines/VK_MAKE_VERSION.txt[]
* pname:major is the major version number.
* pname:minor is the minor version number.
* pname:patch is the patch version number.
This macro can: be used when constructing the
slink:VkApplicationInfo::pname:apiVersion parameter passed to
flink:vkCreateInstance.
--
==== Vulkan Header File Version Number
@ -234,6 +147,16 @@ include::../api/defines/VK_HEADER_VERSION.txt[]
--
[open,refpage='VK_API_VERSION',desc='Deprecated version number macro',type='defines']
--
dname:VK_API_VERSION is now commented out of `vulkan_core.h` and cannot: be
used.
include::../api/defines/VK_API_VERSION.txt[]
--
==== Vulkan Handle Macros

38
appendices/glossary.txt
View File

@ -45,6 +45,10 @@ Advanced Blend Operation::
See <<framebuffer-blend-advanced, Advanced Blending Operations>>.
endif::VK_EXT_blend_operation_advanced[]
Alias (API type/command)::
An identical definition of another API type/command with the same
behavior but a different name.
Aliased Range (Memory)::
A range of a device memory allocation that is bound to multiple
resources simultaneously.
@ -238,6 +242,12 @@ Compressed Texel Block::
these elements in units of texels, and a size in bytes of the encoding
in memory.
ifdef::VK_NV_cooperative_matrix[]
Cooperative Matrix::
A SPIR-V type where the storage for and computations performed on the
matrix are spread across a set of invocations such as a subgroup.
endif::VK_NV_cooperative_matrix[]
ifdef::VK_NV_corner_sampled_image[]
Corner-Sampled Image::
A slink:VkImage where unnormalized texel coordinates are centered on
@ -267,12 +277,9 @@ Decoration (SPIR-V)::
invariance, interpolation type, relaxed precision, etc., added to
variables or structure-type members through decorations.
Deprecated::
Deprecated (feature)::
A feature is deprecated if it is no longer recommended as the correct or
best way to achieve its intended purpose.
Generally a newer feature will have been created that solves the same
problem - in cases where no newer alternative feature exists,
justification should be provided.
Depth/Stencil Attachment::
A subpass attachment point, or image view, that is the target of depth
@ -972,12 +979,8 @@ Object Table::
Entries are registered or unregistered via code:uint32_t indices.
endif::VK_NVX_device_generated_commands[]
Obsoleted::
Obsoleted (feature)::
A feature is obsolete if it can no longer be used.
For core features, making one obsolete would be in violation of the
<<fundamentals-versionnum, compatibility rules>>, so must not be done.
However extensions do not have these guarantees, and can be made
obsolete by a newer core version or extension.
Overlapped Range (Aliased Range)::
The aliased range of a device memory allocation that intersects a given
@ -1121,17 +1124,10 @@ Primitive Topology::
State that controls how vertices are assembled into primitives, e.g. as
lists of triangles, strips of lines, etc..
Promoted::
A feature is promoted if it is taken from an older extension and made
available as part of a new <<versions,core version of the API>>, or a
newer extension that is considered to be either as widely supported or
more so.
A promoted feature may have minor differences from the original such as:
* It may be renamed
* A small number of non-intrusive parameters may have been added
* The feature may be advertised differently by
<<features-features,device features>>
* The author ID suffixes will be changed or removed as appropriate
Promoted (feature)::
A feature from an older extension is considered promoted if it is made
available as part of a new core version or newer extension with wider
support.
ifdef::VK_VERSION_1_1[]
Protected Buffer::
@ -1238,7 +1234,7 @@ Render Pass Instance::
Required Extensions::
Extensions that must: be enabled alongside extensions dependent on them
(see <<extended-functionality-extensions-dependencies, Extension
(see <<extendingvulkan-extensions-extensiondependencies, Extension
Dependencies>>).
Reset (Command Buffer)::

13
appendices/memorymodel.txt
View File

@ -900,3 +900,16 @@ execution model execute memory operations X and Y, respectively, on the
code:Output storage class, and X is tessellation-output-ordered before Y
with a scope of code:Workgroup, then X is location-ordered before Y, and if
X is a write and Y is a read then X is visible-to Y.
ifdef::VK_NV_cooperative_matrix[]
[[memory-model-cooperative-matrix]]
== Cooperative Matrix Memory Access
For each dynamic instance of a cooperative matrix load or store instruction
(code:OpCooperativeMatrixLoadNV or code:OpCooperativeMatrixStoreNV), a
single implementation-dependent invocation within the instance of the
matrix's scope performs a non-atomic load or store (respectively) to each
memory location that is defined to be accessed by the instruction.
endif::VK_NV_cooperative_matrix[]

42
appendices/spirvenv.txt
View File

@ -270,6 +270,10 @@ ifdef::VK_EXT_buffer_device_address[]
[[spirvenv-capabilities-table-physicalstoragebufferaddresses]]
| code:PhysicalStorageBufferAddressesEXT | <<features-features-bufferDeviceAddress,bufferDeviceAddress>>
endif::VK_EXT_buffer_device_address[]
ifdef::VK_NV_cooperative_matrix[]
[[spirvenv-capabilities-table-cooperativeMatrix]]
| code:CooperativeMatrixNV | <<features-features-cooperativeMatrix,cooperativeMatrix>>
endif::VK_NV_cooperative_matrix[]
|====
ifdef::VK_VERSION_1_1,VK_KHR_variable_pointers[]
@ -458,6 +462,11 @@ The application can: pass a SPIR-V module to flink:vkCreateShaderModule that
uses the `SPV_EXT_physical_storage_buffer` SPIR-V extension.
endif::VK_EXT_buffer_device_address[]
ifdef::VK_NV_cooperative_matrix[]
The application can: pass a SPIR-V module to flink:vkCreateShaderModule that
uses the `SPV_NV_cooperative_matrix` SPIR-V extension.
endif::VK_NV_cooperative_matrix[]
The application must: not pass a SPIR-V module containing any of the
following to flink:vkCreateShaderModule:
@ -892,6 +901,35 @@ ifdef::VK_EXT_buffer_device_address[]
** code:OpConvertUToPtr and code:OpConvertPtrToU must: use an integer type
whose code:Width is 64.
endif::VK_EXT_buffer_device_address[]
ifdef::VK_NV_cooperative_matrix[]
* For code:OpCooperativeMatrixLoadNV and code:OpCooperativeMatrixStoreNV
instructions, the code:Pointer and code:Stride operands must: be aligned
to at least the lesser of 16 bytes or the natural alignment of a row or
column (depending on code:ColumnMajor) of the matrix (where the natural
alignment is the number of columns/rows multiplied by the component
size).
* For code:OpTypeCooperativeMatrixNV, the component type, scope, number of
rows, and number of columns must: match one of the matrices in any of
the supported slink:VkCooperativeMatrixPropertiesNV.
* For code:OpCooperativeMatrixMulAddNV, the code:Result, code:A, code:B,
and code:C matrices must: all have types that satisfy the same supported
slink:VkCooperativeMatrixPropertiesNV.
That is, for one supported supported
slink:VkCooperativeMatrixPropertiesNV, all of the following must: hold:
** The type of code:A must have pname:MSize rows and pname:KSize columns
and have a component type that matches pname:AType.
** The type of code:B must have pname:KSize rows and pname:NSize columns
and have a component type that matches pname:BType.
** The type of code:C must have pname:MSize rows and pname:NSize columns
and have a component type that matches pname:CType.
** The type of code:Result must have pname:MSize rows and pname:NSize
columns and have a component type that matches pname:DType.
** The type of code:A, code:B, code:C, and code:Result must all have a
scope of pname:scope.
* code:OpTypeCooperativeMatrixNV and code:OpCooperativeMatrix*
instructions must: not be used in shader stages not included in
slink:VkPhysicalDeviceCooperativeMatrixPropertiesNV::pname:cooperativeMatrixSupportedStages.
endif::VK_NV_cooperative_matrix[]
[[spirvenv-precision-operation]]
@ -1285,6 +1323,10 @@ Vulkan environment, they require non-negative values and thus do not enable
additional functionality beyond what code:OpUMod provides.
====
ifdef::VK_NV_cooperative_matrix[]
code:OpCooperativeMatrixMulAddNV performs its operations in an
implementation-dependent order and internal precision.
endif::VK_NV_cooperative_matrix[]
[[spirvenv-image-formats]]
== Compatibility Between SPIR-V Image Formats And Vulkan Formats

31
appendices/versions.txt
View File

@ -10,32 +10,8 @@
New minor versions of the Vulkan API are defined periodically by the Khronos
Vulkan Working Group.
These consist of some amount of additional functionality added to the core
API, some of which may: be promoted from extensions, other parts of which
may: be new.
Extensions that are promoted in this way typically have their functionality
replicated directly in the core, but with extension suffixes dropped.
The existing values with suffixes are still present in the API itself as
aliases of the original extension functionality.
Any differences between the core and extension version of the functionality
will be documented in the extension appendix, and mentioned briefly in the
version description in this appendix.
[NOTE]
.Note
====
For structure and enumeration aliases, the aliased extension type is
semantically identical to the new core type.
The C99 headers simply `typedef` the aliases to the core types.
For command aliases, however, there are two separate entry point
definitions, due to the fact that the C99 ABI has no way to alias command
definitions without resorting to the preprocessor.
Calling via either entry point definition will produce identical behavior
within the bounds of the specification, and should still invoke the same
entry point in the implementation.
Debug tools may use separate entry points with different debug behavior; to
write the appropriate command name to an output log, for instance.
====
API, potentially including both new functionality and functionality
<<extendingvulkan-compatibility-promotions,promoted>> from extensions.
It's possible to build the specification for earlier versions, but to aid
readability of the latest versions, this appendix gives an overview of the
@ -46,7 +22,8 @@ ifdef::VK_VERSION_1_1[]
== Version 1.1
[[versions-1.1-promotions]]
Vulkan Version 1.1 _promoted_ a number of key extensions into the core API:
Vulkan Version 1.1 <<extendingvulkan-compatibility-promotions,promoted>> a
number of key extensions into the core API:
include::meta/promoted_extensions_VK_VERSION_1_1.txt[]

2
chapters/clears.txt
View File

@ -628,7 +628,7 @@ include::../validity/protos/vkCmdUpdateBuffer.txt[]
.Note
====
The pname:pData parameter was of type code:uint32_t* instead of code:void*
prior to revision 1.0.19 of the Specification and dlink:VK_HEADER_VERSION 19
prior to version 1.0.19 of the Specification and dlink:VK_HEADER_VERSION 19
of the <<boilerplate-headers,Vulkan Header Files>>.
This was a historical anomaly, as the source data may be of other types.
====

2
chapters/cmdbuffers.txt
View File

@ -288,7 +288,7 @@ a bulk allocation would prevent that allocation from being freed, even if
only a small proportion of the bulk allocation is in use.
In most cases trimming will result in a reduction in allocated but unused
memory, but it does not guarantee the "`ideal`" behaviour.
memory, but it does not guarantee the "`ideal`" behavior.
Trimming may: be an expensive operation, and should: not be called
frequently.

10
chapters/descriptorsets.txt
View File

@ -86,7 +86,7 @@ shader.
A _sampler descriptor_ (ename:VK_DESCRIPTOR_TYPE_SAMPLER) is a descriptor
type associated with a <<samplers,sampler>> object, used to control the
behaviour of <<textures,sampling operations>> performed on a
behavior of <<textures,sampling operations>> performed on a
<<descriptorsets-sampledimage, sampled image>>.
@ -2220,10 +2220,10 @@ If ename:VK_ERROR_FRAGMENTED_POOL is the actual return value, it adds
certainty to that decision.
The reason for this is that ename:VK_ERROR_FRAGMENTED_POOL was only added in
a later revision of the 1.0 specification, and so drivers may: return other
errors if they were written against earlier revisions.
To ensure full compatibility with earlier patch revisions, these other
errors are allowed.
a later version of the 1.0 specification, and so drivers may: return other
errors if they were written against earlier versions.
To ensure full compatibility with earlier patch versions, these other errors
are allowed.
====
endif::VK_VERSION_1_1,VK_KHR_maintenance2[]

11
chapters/devsandqueues.txt
View File

@ -82,8 +82,7 @@ The sname:VkPhysicalDeviceProperties structure is defined as:
include::../api/structs/VkPhysicalDeviceProperties.txt[]
* pname:apiVersion is the version of Vulkan supported by the device,
encoded as described in the <<fundamentals-versionnum,API Version
Numbers and Semantics>> section.
encoded as described in <<extendingvulkan-coreversions-versionnumbers>>.
* pname:driverVersion is the vendor-specified version of the driver.
* pname:vendorID is a unique identifier for the _vendor_ (see below) of
the physical device.
@ -893,7 +892,7 @@ ename:VK_ERROR_TOO_MANY_OBJECTS.
.Valid Usage
****
* [[VUID-vkCreateDevice-ppEnabledExtensionNames-01387]]
All <<extended-functionality-extensions-dependencies, required
All <<extendingvulkan-extensions-extensiondependencies, required
extensions>> for each extension in the
slink:VkDeviceCreateInfo::pname:ppEnabledExtensionNames list must: also
be present in that list.
@ -923,15 +922,13 @@ include::../api/structs/VkDeviceCreateInfo.txt[]
below for further details.
* pname:enabledLayerCount is deprecated and ignored.
* pname:ppEnabledLayerNames is deprecated and ignored.
See <<extended-functionality-device-layer-deprecation,Device Layer
Deprecation>>.
See <<extendingvulkan-layers-devicelayerdeprecation>>.
* pname:enabledExtensionCount is the number of device extensions to
enable.
* pname:ppEnabledExtensionNames is a pointer to an array of
pname:enabledExtensionCount null-terminated UTF-8 strings containing the
names of extensions to enable for the created device.
See the <<extended-functionality-extensions,Extensions>> section for
further details.
See the <<extendingvulkan-extensions>> section for further details.
* pname:pEnabledFeatures is `NULL` or a pointer to a
slink:VkPhysicalDeviceFeatures structure that contains boolean
indicators of all the features to be enabled.

13
chapters/dispatch.txt
View File

@ -289,23 +289,14 @@ ifdef::VK_EXT_filter_cubic[]
endif::VK_EXT_filter_cubic[]
endif::VK_IMG_filter_cubic,VK_EXT_filter_cubic[]
ifdef::VK_VERSION_1_1[]
* [[VUID-vkCmdDispatchIndirect-commandBuffer-02639]]
pname:commandBuffer must: not be a protected command buffer
* [[VUID-vkCmdDispatchIndirect-commandBuffer-01847]]
If pname:commandBuffer is an unprotected command buffer, and any
pipeline stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_COMPUTE reads from or writes to any image
or buffer, that image or buffer must: not be a protected image or
protected buffer.
* [[VUID-vkCmdDispatchIndirect-commandBuffer-01848]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_COMPUTE writes to any image or buffer, that
image or buffer must: not be an unprotected image or unprotected buffer.
* [[VUID-vkCmdDispatchIndirect-commandBuffer-01849]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage other than the compute pipeline stage in the sname:VkPipeline
object bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE reads from any
image or buffer, the image or buffer must: not be a protected image or
protected buffer.
endif::VK_VERSION_1_1[]
ifdef::VK_NV_corner_sampled_image[]
* [[VUID-vkCmdDispatchIndirect-flags-02041]]

100
chapters/drawing.txt
View File

@ -1102,24 +1102,14 @@ ifdef::VK_VERSION_1_1,VK_KHR_multiview[]
slink:VkPhysicalDeviceMultiviewProperties::pname:maxMultiviewInstanceIndex.
endif::VK_VERSION_1_1,VK_KHR_multiview[]
ifdef::VK_VERSION_1_1[]
* [[VUID-vkCmdDrawIndirect-commandBuffer-02640]]
pname:commandBuffer must: not be a protected command buffer
* [[VUID-vkCmdDrawIndirect-commandBuffer-01856]]
If pname:commandBuffer is an unprotected command buffer, and any
pipeline stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS reads from or writes to any image
or buffer, that image or buffer must: not be a protected image or
protected buffer.
* [[VUID-vkCmdDrawIndirect-commandBuffer-01857]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS writes to any image or buffer,
that image or buffer must: not be an unprotected image or unprotected
buffer.
* [[VUID-vkCmdDrawIndirect-commandBuffer-01858]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage other than the framebuffer-space pipeline stages in the
sname:VkPipeline object bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS
reads from or writes to any image or buffer, the image or buffer must:
not be a protected image or protected buffer.
endif::VK_VERSION_1_1[]
ifdef::VK_EXT_sample_locations[]
* [[VUID-vkCmdDrawIndirect-sampleLocationsEnable-01514]]
@ -1368,24 +1358,14 @@ ifdef::VK_VERSION_1_1,VK_KHR_multiview[]
slink:VkPhysicalDeviceMultiviewProperties::pname:maxMultiviewInstanceIndex.
endif::VK_VERSION_1_1,VK_KHR_multiview[]
ifdef::VK_VERSION_1_1[]
* [[VUID-vkCmdDrawIndirectCountKHR-commandBuffer-02641]]
pname:commandBuffer must: not be a protected command buffer
* [[VUID-vkCmdDrawIndirectCountKHR-commandBuffer-03133]]
If pname:commandBuffer is an unprotected command buffer, and any
pipeline stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS reads from or writes to any image
or buffer, that image or buffer must: not be a protected image or
protected buffer.
* [[VUID-vkCmdDrawIndirectCountKHR-commandBuffer-03134]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS writes to any image or buffer,
that image or buffer must: not be an unprotected image or unprotected
buffer.
* [[VUID-vkCmdDrawIndirectCountKHR-commandBuffer-03135]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage other than the framebuffer-space pipeline stages in the
sname:VkPipeline object bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS
reads from or writes to any image or buffer, the image or buffer must:
not be a protected image or protected buffer.
endif::VK_VERSION_1_1[]
ifdef::VK_EXT_sample_locations[]
* [[VUID-vkCmdDrawIndirectCountKHR-sampleLocationsEnable-03171]]
@ -1575,24 +1555,14 @@ ifdef::VK_VERSION_1_1,VK_KHR_multiview[]
slink:VkPhysicalDeviceMultiviewProperties::pname:maxMultiviewInstanceIndex.
endif::VK_VERSION_1_1,VK_KHR_multiview[]
ifdef::VK_VERSION_1_1[]
* [[VUID-vkCmdDrawIndirectCountAMD-commandBuffer-02642]]
pname:commandBuffer must: not be a protected command buffer
* [[VUID-vkCmdDrawIndirectCountAMD-commandBuffer-01859]]
If pname:commandBuffer is an unprotected command buffer, and any
pipeline stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS reads from or writes to any image
or buffer, that image or buffer must: not be a protected image or
protected buffer.
* [[VUID-vkCmdDrawIndirectCountAMD-commandBuffer-01860]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS writes to any image or buffer,
that image or buffer must: not be an unprotected image or unprotected
buffer.
* [[VUID-vkCmdDrawIndirectCountAMD-commandBuffer-01861]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage other than the framebuffer-space pipeline stages in the
sname:VkPipeline object bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS
reads from or writes to any image or buffer, the image or buffer must:
not be a protected image or protected buffer.
endif::VK_VERSION_1_1[]
ifdef::VK_EXT_sample_locations[]
* [[VUID-vkCmdDrawIndirectCountAMD-sampleLocationsEnable-01515]]
@ -1799,24 +1769,14 @@ ifdef::VK_VERSION_1_1,VK_KHR_multiview[]
slink:VkPhysicalDeviceMultiviewProperties::pname:maxMultiviewInstanceIndex.
endif::VK_VERSION_1_1,VK_KHR_multiview[]
ifdef::VK_VERSION_1_1[]
* [[VUID-vkCmdDrawIndexedIndirect-commandBuffer-02643]]
pname:commandBuffer must: not be a protected command buffer
* [[VUID-vkCmdDrawIndexedIndirect-commandBuffer-01862]]
If pname:commandBuffer is an unprotected command buffer, and any
pipeline stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS reads from or writes to any image
or buffer, that image or buffer must: not be a protected image or
protected buffer.
* [[VUID-vkCmdDrawIndexedIndirect-commandBuffer-01863]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS writes to any image or buffer,
that image or buffer must: not be an unprotected image or unprotected
buffer.
* [[VUID-vkCmdDrawIndexedIndirect-commandBuffer-01864]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage other than the framebuffer-space pipeline stages in the
sname:VkPipeline object bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS
reads from or writes to any image or buffer, the image or buffer must:
not be a protected image or protected buffer.
endif::VK_VERSION_1_1[]
ifdef::VK_EXT_sample_locations[]
* [[VUID-vkCmdDrawIndexedIndirect-sampleLocationsEnable-01516]]
@ -2073,24 +2033,14 @@ ifdef::VK_VERSION_1_1,VK_KHR_multiview[]
slink:VkPhysicalDeviceMultiviewProperties::pname:maxMultiviewInstanceIndex.
endif::VK_VERSION_1_1,VK_KHR_multiview[]
ifdef::VK_VERSION_1_1[]
* [[VUID-vkCmdDrawIndexedIndirectCountKHR-commandBuffer-02644]]
pname:commandBuffer must: not be a protected command buffer
* [[VUID-vkCmdDrawIndexedIndirectCountKHR-commandBuffer-03165]]
If pname:commandBuffer is an unprotected command buffer, and any
pipeline stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS reads from or writes to any image
or buffer, that image or buffer must: not be a protected image or
protected buffer.
* [[VUID-vkCmdDrawIndexedIndirectCountKHR-commandBuffer-03166]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS writes to any image or buffer,
that image or buffer must: not be an unprotected image or unprotected
buffer.
* [[VUID-vkCmdDrawIndexedIndirectCountKHR-commandBuffer-03167]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage other than the framebuffer-space pipeline stages in the
sname:VkPipeline object bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS
reads from or writes to any image or buffer, the image or buffer must:
not be a protected image or protected buffer.
endif::VK_VERSION_1_1[]
ifdef::VK_EXT_sample_locations[]
* [[VUID-vkCmdDrawIndexedIndirectCountKHR-sampleLocationsEnable-03174]]
@ -2281,24 +2231,14 @@ ifdef::VK_VERSION_1_1,VK_KHR_multiview[]
slink:VkPhysicalDeviceMultiviewProperties::pname:maxMultiviewInstanceIndex.
endif::VK_VERSION_1_1,VK_KHR_multiview[]
ifdef::VK_VERSION_1_1[]
* [[VUID-vkCmdDrawIndexedIndirectCountAMD-commandBuffer-02645]]
pname:commandBuffer must: not be a protected command buffer
* [[VUID-vkCmdDrawIndexedIndirectCountAMD-commandBuffer-01865]]
If pname:commandBuffer is an unprotected command buffer, and any
pipeline stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS reads from or writes to any image
or buffer, that image or buffer must: not be a protected image or
protected buffer.
* [[VUID-vkCmdDrawIndexedIndirectCountAMD-commandBuffer-01866]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS writes to any image or buffer,
that image or buffer must: not be an unprotected image or unprotected
buffer.
* [[VUID-vkCmdDrawIndexedIndirectCountAMD-commandBuffer-01867]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage other than the framebuffer-space pipeline stages in the
sname:VkPipeline object bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS
reads from or writes to any image or buffer, the image or buffer must:
not be a protected image or protected buffer.
endif::VK_VERSION_1_1[]
ifdef::VK_EXT_sample_locations[]
* [[VUID-vkCmdDrawIndexedIndirectCountAMD-sampleLocationsEnable-01517]]
@ -2399,7 +2339,7 @@ The effective pname:firstVertex is zero.
The implementation must: support
sname:VkPhysicalDeviceTransformFeedbackPropertiesEXT::pname:transformFeedbackDraw
* [[VUID-vkCmdDrawIndirectByteCountEXT-vertexStride-02289]]
pname:vertexStride must be less than or equal to
pname:vertexStride must: be greater than 0 and less than or equal to
slink:VkPhysicalDeviceLimits::pname:maxTransformFeedbackBufferDataStride
* [[VUID-vkCmdDrawIndirectByteCountEXT-counterBuffer-02290]]
pname:counterBuffer must: have been created with the
@ -2517,24 +2457,14 @@ ifdef::VK_VERSION_1_1,VK_KHR_multiview[]
slink:VkPhysicalDeviceMultiviewProperties::pname:maxMultiviewInstanceIndex
endif::VK_VERSION_1_1,VK_KHR_multiview[]
ifdef::VK_VERSION_1_1[]
* [[VUID-vkCmdDrawIndirectByteCountEXT-commandBuffer-02646]]
pname:commandBuffer must: not be a protected command buffer
* [[VUID-vkCmdDrawIndirectByteCountEXT-commandBuffer-02309]]
If pname:commandBuffer is an unprotected command buffer, and any
pipeline stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS reads from or writes to any image
or buffer, that image or buffer must: not be a protected image or
protected buffer
* [[VUID-vkCmdDrawIndirectByteCountEXT-commandBuffer-02310]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage in the sname:VkPipeline object bound to
ename:VK_PIPELINE_BIND_POINT_GRAPHICS writes to any image or buffer,
that image or buffer must: not be an unprotected image or unprotected
buffer
* [[VUID-vkCmdDrawIndirectByteCountEXT-commandBuffer-02311]]
If pname:commandBuffer is a protected command buffer, and any pipeline
stage other than the framebuffer-space pipeline stages in the
sname:VkPipeline object bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS
reads from or writes to any image or buffer, the image or buffer must:
not be a protected image or protected buffer
endif::VK_VERSION_1_1[]
ifdef::VK_EXT_sample_locations[]
* [[VUID-vkCmdDrawIndirectByteCountEXT-sampleLocationsEnable-02312]]

508
chapters/extensions.txt
View File

@ -2,51 +2,218 @@
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
[[extended-functionality]]
= Extended Functionality
[[extendingvulkan]]
= Extending Vulkan
Additional functionality may: be provided by layers or extensions.
A layer cannot: add or modify Vulkan commands, while an extension may: do
so.
New functionality may: be added to Vulkan via either new extensions or new
versions of the core, or new versions of an extension in some cases.
The set of layers to enable is specified when creating an instance, and
those layers are able to intercept any Vulkan command dispatched to that
instance or any of its child objects.
This chapter describes how Vulkan is versioned, how compatibility is
affected between different versions, and compatibility rules that are
followed by the Vulkan Working Group.
Extensions can operate at either the instance or device _extension scope_.
Enabled instance extensions are able to affect the operation of the instance
and any of its child objects, while device extensions may: only be available
on a subset of physical devices, must: be individually enabled per-device,
and only affect the operation of the devices where they are enabled.
[[extendingvulkan-instanceanddevicefunctionality]]
== Instance and Device Functionality
Commands that enumerate instance properties, or that accept a
slink:VkInstance object as a parameter, are considered instance-level
functionality.
Commands
ifdef::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[]
that enumerate physical device properties, or
endif::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[]
that accept a slink:VkDevice object or any of a device's child objects as a
parameter, are considered device-level functionality.
ifdef::VK_VERSION_1_1[]
[NOTE]
.Note
====
Applications usually interface to Vulkan using a loader that implements only
instance-level functionality, passing device-level functionality to
implementations of the full Vulkan API on the system.
In some circumstances, as these may be implemented independently, it's
possible that the loader and device implementations on a given installation
will support different versions.
To allow for this and call out when it happens, the Vulkan specification
enumerates device and instance level functionality separately - they have
<<extendingvulkan-coreversions-queryingversionsupport,independent version
queries>>.
====
endif::VK_VERSION_1_1[]
[NOTE]
.Note
====
Examples of these might be:
* Whole API validation is an example of a layer.
* Debug capabilities might make a good instance extension.
* A layer that provides implementation-specific performance telemetry and
analysis could be a layer that is only active for devices created from
compatible physical devices.
* Functions to allow an application to use additional implementation
features beyond the core would be a good candidate for a device
extension.
Vulkan 1.0 initially specified new physical device enumeration functionality
as instance-level, requiring it to be included in an instance extension.
As the capabilities of device-level functionality require discovery via
physical device enumeration, this led to the situation where many device
extensions required an instance extension as well.
To alleviate this extra work, `VK_KHR_get_physical_device_properties2` (and
subsequently Vulkan 1.1) redefined device-level functionality to include
physical device enumeration.
====
[[extended-functionality-layers]]
[[extendingvulkan-coreversions]]
== Core Versions
The Vulkan Specification is regularly updated with bug fixes and
clarifications.
Occasionally new functionality is added to the core and at some point it is
expected that there will be a desire to perform a large, breaking change to
the API.
In order to indicate to developers how and when these changes are made to
the specification, and to provide a way to identify each set of changes, the
Vulkan API maintains a version number.
[[extendingvulkan-coreversions-versionnumbers]]
=== Version Numbers
The Vulkan version number comprises three parts indicating the major, minor
and patch version of the Vulkan API Specification.
The _major version_ indicates a significant change in the API, which will
encompass a wholly new version of the specification.
The _minor version_ indicates the incorporation of new functionality into
the core specification.
The _patch version_ indicates bug fixes, clarifications, and language
improvements have been incorporated into the specification.
Compatibility guarantees made about versions of the API sharing any of the
same version numbers are documented in
<<extendingvulkan-compatibility-coreversions>>
The version number is used in several places in the API.
In each such use, the version numbers are packed into a 32-bit integer as
follows:
* The major version is a 10-bit integer packed into bits 31-22.
* The minor version number is a 10-bit integer packed into bits 21-12.
* The patch version number is a 12-bit integer packed into bits 11-0.
[open,refpage='VK_VERSION_MAJOR',desc='Extract API major version number',type='defines']
--
dname:VK_VERSION_MAJOR extracts the API major version number from a packed
version number:
include::../api/defines/VK_VERSION_MAJOR.txt[]
--
[open,refpage='VK_VERSION_MINOR',desc='Extract API minor version number',type='defines']
--
dname:VK_VERSION_MINOR extracts the API minor version number from a packed
version number:
include::../api/defines/VK_VERSION_MINOR.txt[]
--
[open,refpage='VK_VERSION_PATCH',desc='Extract API patch version number',type='defines']
--
dname:VK_VERSION_PATCH extracts the API patch version number from a packed
version number:
include::../api/defines/VK_VERSION_PATCH.txt[]
--
[open,refpage='VK_MAKE_VERSION',desc='Construct an API version number',type='defines',xrefs='VkApplicationInfo vkCreateInstance']
--
dname:VK_MAKE_VERSION constructs an API version number.
include::../api/defines/VK_MAKE_VERSION.txt[]
* pname:major is the major version number.
* pname:minor is the minor version number.
* pname:patch is the patch version number.
--
[open,refpage='VK_API_VERSION_1_0',desc='Return API version number for Vulkan 1.0',type='defines',xrefs='vkCreateInstance vkGetPhysicalDeviceProperties']
--
dname:VK_API_VERSION_1_0 returns the API version number for Vulkan 1.0.0.
include::../api/defines/VK_API_VERSION_1_0.txt[]
--
ifdef::VK_VERSION_1_1[]
[open,refpage='VK_API_VERSION_1_1',desc='Return API version number for Vulkan 1.1',type='defines',xrefs='vkCreateInstance vkGetPhysicalDeviceProperties']
--
dname:VK_API_VERSION_1_1 returns the API version number for Vulkan 1.1.0.
include::../api/defines/VK_API_VERSION_1_1.txt[]
--
endif::VK_VERSION_1_1[]
[[extendingvulkan-coreversions-queryingversionsupport]]
=== Querying Version Support
ifndef::VK_VERSION_1_1[]
[NOTE]
.Note
====
In Vulkan 1.0, there is no mechanism to detect the separate versions of
<<extendingvulkan-instanceanddevicefunctionality,instance-level and
device-level functionality>> supported.
However, the fname:vkEnumerateInstanceVersion command was added in Vulkan
1.1 to determine the supported version of instance-level functionality -
querying for this function via flink:vkGetInstanceProcAddr will return
`NULL` on implementations that only support Vulkan 1.0 functionality.
For more information on this, please refer to the Vulkan 1.1 specification.
====
endif::VK_VERSION_1_1[]
ifdef::VK_VERSION_1_1[]
The version of instance-level functionality can be queried by calling
flink:vkEnumerateInstanceVersion.
endif::VK_VERSION_1_1[]
The version of device-level functionality can be queried by calling
flink:vkGetPhysicalDeviceProperties
ifdef::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[]
or flink:vkGetPhysicalDeviceProperties2,
endif::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[]
and is returned in slink:VkPhysicalDeviceProperties::pname:apiVersion,
encoded as described in <<extendingvulkan-coreversions-versionnumbers>>.
[[extendingvulkan-layers]]
== Layers
When a layer is enabled, it inserts itself into the call chain for Vulkan
commands the layer is interested in.
A common use of layers is to validate application behavior during
development.
For example, the implementation will not check that Vulkan enums used by the
application fall within allowed ranges.
Layers can: be used for a variety of tasks that extend the base behavior of
Vulkan beyond what is required by the specification - such as call logging,
tracing, validation, or providing additional extensions.
[NOTE]
.Note
====
For example, an implementation is not expected to check that the value of
enums used by the application fall within allowed ranges.
Instead, a validation layer would do those checks and flag issues.
This avoids a performance penalty during production use of the application
because those layers would not be enabled in production.
====
[NOTE]
.Note
====
Vulkan layers may: wrap object handles (i.e. return a different handle value
to the application than that generated by the implementation).
This is generally discouraged, as it increases the probability of
@ -55,6 +222,7 @@ The validation layers wrap handles in order to track the proper use and
destruction of each object.
See the <<LoaderAndLayerInterface, "`Vulkan Loader Specification and
Architecture Overview`">> document for additional information.
====
[open,refpage='vkEnumerateInstanceLayerProperties',desc='Returns up to requested number of global layer properties',type='protos']
--
@ -105,8 +273,7 @@ include::../api/structs/VkLayerProperties.txt[]
slink:VkInstanceCreateInfo structure to enable this layer for an
instance.
* pname:specVersion is the Vulkan version the layer was written to,
encoded as described in the <<fundamentals-versionnum,API Version
Numbers and Semantics>> section.
encoded as described in <<extendingvulkan-coreversions-versionnumbers>>.
* pname:implementationVersion is the version of this layer.
It is an integer, increasing with backward compatible changes.
* pname:description is a null-terminated UTF-8 string providing additional
@ -130,7 +297,7 @@ Explicitly enabling a layer that is implicitly enabled has no additional
effect.
[[extended-functionality-device-layer-deprecation]]
[[extendingvulkan-layers-devicelayerdeprecation]]
=== Device Layer Deprecation
Previous versions of this specification distinguished between instance and
@ -202,7 +369,7 @@ the sequence of layers active for a device will be exactly the sequence of
layers enabled when the parent instance was created.
[[extended-functionality-extensions]]
[[extendingvulkan-extensions]]
== Extensions
Extensions may: define new Vulkan commands, structures, and enumerants.
@ -232,6 +399,13 @@ valid, although it might do so in the future.
It is defined only in the <<fundamentals-validusage-extensions>> section.
====
=== Instance Extensions
Instance extensions add new
<<extendingvulkan-instanceanddevicefunctionality,instance-level
functionality>> to the API, outside of the core specification.
[open,refpage='vkEnumerateInstanceExtensionProperties',desc='Returns up to requested number of global extension properties',type='protos']
--
@ -271,6 +445,10 @@ The extensions supported by a layer may also change between two calls, e.g.
if the layer implementation is replaced by a different version between those
calls.
Implementations must: not advertise any pair of extensions that cannot be
enabled together due to behavioral differences, or any extension that cannot
be enabled against the advertised version.
include::../validity/protos/vkEnumerateInstanceExtensionProperties.txt[]
--
@ -278,9 +456,20 @@ To enable an instance extension, the name of the extension should: be added
to the pname:ppEnabledExtensionNames member of slink:VkInstanceCreateInfo
when creating a sname:VkInstance.
[NOTE]
.Note
====
Enabling an extension does not change behavior of functionality exposed by
the core Vulkan API or any other extension, other than making valid the use
of the commands, enums and structures defined by that extension.
====
=== Device Extensions
Device extensions add new
<<extendingvulkan-instanceanddevicefunctionality,device-level
functionality>> to the API, outside of the core specification.
[open,refpage='vkEnumerateDeviceExtensionProperties',desc='Returns properties of available physical device extensions',type='protos']
--
@ -305,6 +494,10 @@ Vulkan implementation or by implicitly enabled layers are returned.
When pname:pLayerName is the name of a layer, the device extensions provided
by that layer are returned.
Implementations must: not advertise any pair of extensions that cannot be
enabled together due to behavioral differences, or any extension that cannot
be enabled against the advertised version.
include::../validity/protos/vkEnumerateDeviceExtensionProperties.txt[]
--
@ -323,33 +516,7 @@ include::../api/structs/VkExtensionProperties.txt[]
include::../validity/structs/VkExtensionProperties.txt[]
--
[[extended-functionality-instance-extensions-and-devices]]
=== Instance Extensions and Device Extensions
This section provides some guidelines and rules for when to expose new
functionality as an instance extension, as a device extension, or as both.
The decision depends on the scope of the new functionality; such as whether
it extends instance-level or device-level functionality.
All Vulkan commands, structures, and enumerants are considered either
instance-level, physical-device-level, or device-level.
New instance-level extension functionality must: be structured within an
instance extension.
New device-level extension functionality may: be structured within a device
extension.
Vulkan 1.0 initially required all new physical-device-level extension
functionality to be structured within an instance extension.
ifdef::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[]
In order to avoid using an instance extension, which often requires loader
support, physical-device-level extension functionality may: be implemented
within device extensions (which must: depend on the
`<<VK_KHR_get_physical_device_properties2>>` extension, or on Vulkan 1.1 or
later).
endif::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[]
[[extended-functionality-extensions-dependencies]]
[[extendingvulkan-extensions-extensiondependencies]]
== Extension Dependencies
Some extensions are dependent on other extensions to function.
@ -371,17 +538,216 @@ must: not be returned by flink:vkEnumerateDeviceExtensionProperties for any
slink:VkPhysicalDevice child of the instance.
[[extended-functionality-extensions-compatibility]]
== Extension Compatibility
== Compatibility Guarantees (Informative)
By default, all extensions are considered compatible with each other and any
core API version, unless otherwise stated.
Thus enabling such extensions does not otherwise alter the behavior of the
application.
This section is marked as informal as there is no binding responsibility on
implementations of the Vulkan API - these guarantees are however a contract
between the Vulkan Working Group and developers using this Specification.
Each extension that is mutually exclusive or otherwise incompatible with
another extension or set of extensions documents them in the <<extensions,
appendix summarizing that extension>> and has a corresponding Valid Usage
statement disallowing enabling such an incompatible combination of
extensions at sname:VkInstance creation time or sname:VkDevice creation
time, depending on the type of extensions participating in the interaction.
[[extendingvulkan-compatibility-coreversions]]
=== Core Versions
Each of the <<extendingvulkan-coreversions,major, minor, and patch
versions>> of the Vulkan specification provide different compatibility
guarantees.
==== Patch Versions
A difference in the patch version indicates that a set of bug fixes or
clarifications have been made to the Specification.
Informative enums returned by Vulkan commands that won't affect the runtime
behavior of a valid application may be added in a patch version (e.g.
elink:VkVendorId).
The specification's patch version is strictly increasing for a given major
version of the specification; any change to a specification as described
above will result in the patch version being increased by 1.
Patch versions are applied to all minor versions, even if a given minor
version is not affected by the provoking change.
Specifications with different patch versions but the same major and minor
version are _fully compatible_ with each other - such that a valid
application written against one will work with an implementation of another.
[NOTE]
.Note
====
If a patch version includes a bug fix or clarification that could have a
significant impact on developer expectations, these will be highlighted in
the change log.
Generally the Vulkan Working Group tries to avoid these kinds of changes,
instead fixing them in either an extension or core version.
====
==== Minor Versions
Changes in the minor version of the specification indicate that new
functionality has been added to the core specification.
This will usually include new interfaces in the header, and may: also
include behavior changes and bug fixes.
Core functionality may: be deprecated in a minor version, but will not be
obsoleted or removed.
The specification's minor version is strictly increasing for a given major
version of the specification; any change to a specification as described
above will result in the minor version being increased by 1.
Changes that can be accomodated in a patch version will not increase the
minor version.
Specifications with a lower minor version are _backwards compatible_ with an
implementation of a specification with a higher minor version for core
functionality and extensions issued with the KHR vendor tag.
Vendor and multi-vendor extensions are not guaranteed to remain functional
across minor versions, though in general they are with few exceptions - see
<<extendingvulkan-compatibility-obsoletion>> for more information.
==== Major Versions
A difference in the major version of specifications indicates a large set of
changes which will likely include interface changes, behavioral changes,
removal of <<extendingvulkan-compatibility-deprecation,deprecated
functionality>>, and the modification, addition, or replacement of other
functionality.
The specification's major version is monotonically increasing; any change to
the specification as described above will result in the major version being
increased.
Changes that can be accomodated in a patch or minor version will not
increase the major version.
The Vulkan Working Group intends to only issue a new major version of the
Specification in order to realise significant improvements to the Vulkan API
that will necessarily require breaking compatibility.
A new major version will likely include a wholly new version of the
specification to be issued - which could include an overhaul of the
versioning semantics for the minor and patch versions.
The patch and minor versions of a specification are therefore not meaningful
across major versions.
If a major version of the specification includes similar versioning
semantics, it is expected that the the patch and minor version will be reset
to 0 for that major version.
[[extendingvulkan-compatibility-extensions]]
=== Extensions
A KHR extension must: be able to be enabled alongside any other KHR
extension, and for any minor or patch version of the core Specification
beyond the minimum version it requires.
A multi-vendor extension should: be able to be enabled alongside any KHR
extension or other multi-vendor extension, and for any minor or patch
version of the core Specification beyond the minimum version it requires.
A vendor extension should: be able to be enabled alongside any KHR
extension, multi-vendor extension, or other vendor extension from the same
vendor, and for any minor or patch version of the core Specification beyond
the minimum version it requires.
A vendor extension may: be able to be enabled alongside vendor extensions
from another vendor.
The one other exception to this is if a vendor or multi-vendor extension is
<<extendingvulkan-compatibility-obsoletion, made obsolete>> by either a core
version or another extension, which will be highlighted in the
<<extensions,extension appendix>>.
[[extendingvulkan-compatibility-promotion]]
==== Promotion
Extensions, or features of an extension, may: be promoted to a new
<<versions,core version of the API>>, or a newer extension which an equal or
greater number of implementors are in favour of.
When extension functionality is promoted, minor changes may: be introduced,
limited to the following:
* Naming
* Non-intrusive parameters changes
* <<features-features,Feature advertisement/enablement>>
* Combining structure parameters into larger structures
* Author ID suffixes changed or removed
[NOTE]
.Note
====
If extension functionality is promoted, there's no guarantee of direct
compatibility, however it should require little effort to port code from the
original feature to the promoted one.
The Vulkan Working Group endeavours to ensure that larger changes are marked
as either <<extendingvulkan-compatibility-deprecation, deprecated>> or
<<extendingvulkan-compatibility-obsoletion, obsoleted>> as appropriate, and
can do so retroactively if necessary.
====
Extensions that are promoted are listed as being promoted in their extension
appendices, with reference to where they were promoted to.
[[extendingvulkan-compatibility-deprecation]]
==== Deprecation
Extensions may: be marked as deprecated when the intended use cases either
become irrelevant or can be solved in other ways.
Generally, a new feature will become available to solve the use case in
another extension or core version of the API, but it is not guaranteed.
[NOTE]
.Note
====
Features that are intended to replace deprecated functionality have no
guarantees of compatibility, and applications may require drastic
modification in order to make use of the new features.
====
Extensions that are deprecated are listed as being deprecated in their
extension appendices, with an explanation of the deprecation and any
features that are relevant.
[[extendingvulkan-compatibility-obsoletion]]
==== Obsoletion
Occasionally, an extension will be marked as obsolete if a new version of
the core API or a new extension is fundamentally incompatible with it.
An obsoleted extension must: not be used with the extension or core version
that obsoleted it.
Extensions that are obsoleted are listed as being obsoleted in their
extension appendices, with reference to what they were obsoleted by.
[[extendingvulkan-compatibility-aliases]]
==== Aliases
When an extension is promoted or deprecated by a newer feature, some or all
of its functionality may: be replicated into the newer feature.
Rather than duplication of all the documentation and definitions, the
specification instead identifies the identical commands and types as
_aliases_ of one another.
Each alias is mentioned together with the definition it aliases, with the
older aliases marked as "equivalents".
Each alias of the same command has identical behavior, and each alias of the
same type has identical meaning - they can be used interchangably in an
application with no compatibility issues.
[NOTE]
.Note
====
For promoted types, the aliased extension type is semantically identical to
the new core type.
The C99 headers simply `typedef` the older aliases to the promoted types.
For promoted command aliases, however, there are two separate entry point
definitions, due to the fact that the C99 ABI has no way to alias command
definitions without resorting to macros.
Calling via either entry point definition will produce identical behavior
within the bounds of the specification, and should still invoke the same
entry point in the implementation.
Debug tools may use separate entry points with different debug behavior; to
write the appropriate command name to an output log, for instance.
====

122
chapters/features.txt
View File

@ -198,6 +198,13 @@ ifdef::VK_EXT_buffer_device_address[]
Buffer accesses through buffer device addresses are not
bounds-checked.
endif::VK_EXT_buffer_device_address[]
ifdef::VK_NV_cooperative_matrix[]
If the
<<features-features-cooperativeMatrixRobustBufferAccess,pname:cooperativeMatrixRobustBufferAccess>>
feature is not enabled, then accesses using
code:OpCooperativeMatrixLoadNV and code:OpCooperativeMatrixStoreNV
may: not be bounds-checked.
endif::VK_NV_cooperative_matrix[]
+
[NOTE]
.Note
@ -1882,6 +1889,37 @@ include::../validity/structs/VkPhysicalDeviceScalarBlockLayoutFeaturesEXT.txt[]
endif::VK_EXT_scalar_block_layout[]
ifdef::VK_EXT_depth_clip_enable[]
[open,refpage='VkPhysicalDeviceDepthClipEnableFeaturesEXT',desc='Structure indicating support for explicit enable of depth clip',type='structs']
--
The sname:VkPhysicalDeviceDepthClipEnableFeaturesEXT structure is defined
as:
include::../api/structs/VkPhysicalDeviceDepthClipEnableFeaturesEXT.txt[]
The members of the sname:VkPhysicalDeviceDepthClipEnableFeaturesEXT
structure describe the following features:
* [[features-features-depthClipEnable]] pname:depthClipEnable indicates
that the implementation supports setting the depth clipping operation
explicitly via the
slink:VkPipelineRasterizationDepthClipStateCreateInfoEXT pipeline state.
Otherwise depth clipping is only enabled when
sname:VkPipelineRasterizationStateCreateInfo::pname:depthClampEnable is
set to ename:VK_FALSE.
If the sname:VkPhysicalDeviceDepthClipEnableFeaturesEXT structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceFeatures2KHR, it
is filled with values indicating whether the feature is supported.
sname:VkPhysicalDeviceDepthClipEnableFeaturesEXT can: also be used in the
pname:pNext chain of slink:VkDeviceCreateInfo to enable this feature.
include::../validity/structs/VkPhysicalDeviceDepthClipEnableFeaturesEXT.txt[]
--
endif::VK_EXT_depth_clip_enable[]
ifdef::VK_EXT_memory_priority[]
[open,refpage='VkPhysicalDeviceMemoryPriorityFeaturesEXT',desc='Structure describing memory priority features that can be supported by an implementation',type='structs']
@ -1985,6 +2023,38 @@ include::../validity/structs/VkPhysicalDeviceDedicatedAllocationImageAliasingFea
endif::VK_NV_dedicated_allocation_image_aliasing[]
ifdef::VK_NV_cooperative_matrix[]
[open,refpage='VkPhysicalDeviceCooperativeMatrixFeaturesNV',desc='Structure describing cooperative matrix features that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceCooperativeMatrixFeaturesNV structure is defined
as:
include::../api/structs/VkPhysicalDeviceCooperativeMatrixFeaturesNV.txt[]
The members of the sname:VkPhysicalDeviceCooperativeMatrixFeaturesNV
structure describe the following features:
* [[features-features-cooperativeMatrix]] pname:cooperativeMatrix
indicates that the implementation supports the code:CooperativeMatrixNV
SPIR-V capability.
* [[features-features-cooperativeMatrixRobustBufferAccess]]
pname:cooperativeMatrixRobustBufferAccess indicates that the
implementation supports robust buffer access for SPIR-V
code:OpCooperativeMatrixLoadNV and code:OpCooperativeMatrixStoreNV
instructions.
If the sname:VkPhysicalDeviceCooperativeMatrixFeaturesNV structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceFeatures2KHR, it
is filled with values indicating whether the feature is supported.
sname:VkPhysicalDeviceCooperativeMatrixFeaturesNV can: also be used in the
pname:pNext chain of slink:VkDeviceCreateInfo to enable features.
include::../validity/structs/VkPhysicalDeviceCooperativeMatrixFeaturesNV.txt[]
--
endif::VK_NV_cooperative_matrix[]
[[features-features-requirements]]
=== Feature Requirements
@ -4295,6 +4365,40 @@ include::../validity/structs/VkPhysicalDeviceRayTracingPropertiesNV.txt[]
endif::VK_NV_ray_tracing[]
ifdef::VK_NV_cooperative_matrix[]
[open,refpage='VkPhysicalDeviceCooperativeMatrixPropertiesNV',desc='Structure describing cooperative matrix properties supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceCooperativeMatrixPropertiesNV structure is defined
as:
include::../api/structs/VkPhysicalDeviceCooperativeMatrixPropertiesNV.txt[]
The members of the sname:VkPhysicalDeviceCooperativeMatrixPropertiesNV
structure describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[features-limits-cooperativeMatrixSupportedStages]]
pname:cooperativeMatrixSupportedStages is a bitfield of
elink:VkShaderStageFlagBits describing the shader stages that
cooperative matrix instructions are supported in.
pname:cooperativeMatrixSupportedStages will have the
ename:VK_SHADER_STAGE_COMPUTE_BIT bit set if any of the physical
device's queues support ename:VK_QUEUE_COMPUTE_BIT.
If the sname:VkPhysicalDeviceCooperativeMatrixPropertiesNV structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it
is filled with the implementation-dependent limits.
include::../validity/structs/VkPhysicalDeviceCooperativeMatrixPropertiesNV.txt[]
--
endif::VK_NV_cooperative_matrix[]
[[features-limits-minmax]]
=== Limit Requirements
@ -4468,6 +4572,15 @@ ifdef::VK_EXT_fragment_density_map[]
| slink:VkExtent2D | pname:maxFragmentDensityTexelSize | pname:fragmentDensityMap
| basetype:VkBool32 | pname:fragmentDensityInvocations | pname:fragmentDensityMap
endif::VK_EXT_fragment_density_map[]
ifdef::VK_NV_ray_tracing[]
| code:uint32_t | pname:shaderGroupHandleSize | `<<VK_NV_ray_tracing>>`
| code:uint32_t | pname:maxRecursionDepth | `<<VK_NV_ray_tracing>>`
| code:uint32_t | pname:shaderGroupBaseAlignment | `<<VK_NV_ray_tracing>>`
| code:uint32_t | pname:maxGeometryCount | `<<VK_NV_ray_tracing>>`
| code:uint32_t | pname:maxInstanceCount | `<<VK_NV_ray_tracing>>`
| code:uint32_t | pname:maxTriangleCount | `<<VK_NV_ray_tracing>>`
| code:uint32_t | pname:maxDescriptorSetAccelerationStructures | `<<VK_NV_ray_tracing>>`
endif::VK_NV_ray_tracing[]
|====
[[features-limits-required]]
@ -4696,6 +4809,15 @@ ifdef::VK_EXT_fragment_density_map[]
| pname:maxFragmentDensityTexelSize | - | (1,1) | min
| pname:fragmentDensityInvocations | - | - | implementation dependent
endif::VK_EXT_fragment_density_map[]
ifdef::VK_NV_ray_tracing[]
| pname:shaderGroupHandleSize | - | 16 | min
| pname:maxRecursionDepth | - | 31 | min
| pname:shaderGroupBaseAlignment | - | 64 | max
| pname:maxGeometryCount | - | 2^24 | min
| pname:maxInstanceCount | - | 2^24 | min
| pname:maxTriangleCount | - | 2^29 | min
| pname:maxDescriptorSetAccelerationStructures | - | 16 | min
endif::VK_NV_ray_tracing[]
|====
1::

2
chapters/fragops.txt
View File

@ -784,7 +784,7 @@ endif::VK_EXT_depth_range_unrestricted[]
include::../validity/protos/vkCmdSetDepthBounds.txt[]
--
If [eq]#pname:minDepthBounds {leq} z~a~ {leq} pname:maxDepthBounds}#, then
If [eq]#pname:minDepthBounds {leq} z~a~ {leq} pname:maxDepthBounds#, then
the depth bounds test passes.
Otherwise, the test fails and the sample's coverage bit is cleared in the
fragment.

49
chapters/fundamentals.txt
View File

@ -1408,55 +1408,6 @@ This equation is used everywhere that floating-point values are converted to
signed normalized fixed-point.
[[fundamentals-versionnum]]
== API Version Numbers and Semantics
The Vulkan version number is used in several places in the API.
In each such use, the API _major version number_, _minor version number_,
and _patch version number_ are packed into a 32-bit integer as follows:
* The major version number is a 10-bit integer packed into bits 31-22.
* The minor version number is a 10-bit integer packed into bits 21-12.
* The patch version number is a 12-bit integer packed into bits 11-0.
Differences in any of the Vulkan version numbers indicates a change to the
API in some way, with each part of the version number indicating a different
scope of changes.
A difference in patch version numbers indicates that some usually small part
of the Specification or header has been modified, typically to fix a bug,
and may: have an impact on the behavior of existing functionality.
Differences in this version number should: not affect either _full
compatibility_ or _backwards compatibility_ between two versions, or add
additional interfaces to the API.
A difference in minor version numbers indicates that some amount of new
functionality has been added.
This will usually include new interfaces in the header, and may: also
include behavior changes and bug fixes.
Functionality may: be deprecated in a minor revision, but will not be
removed.
The patch version will continue to increment through minor version number
changes since all minor versions are generated from the same source files,
and changes to the source files may affect all minor versions within a major
version.
Differences in the patch version should: not affect backwards compatibility,
but will affect full compatibility.
The patch version of the Specification is taken from
dlink:VK_HEADER_VERSION.
A difference in major version numbers indicates a large set of changes to
the API, potentially including new functionality and header interfaces,
behavioral changes, removal of deprecated features, modification or outright
replacement of any feature, and is thus very likely to break any and all
compatibility.
Differences in this version will typically require significant modification
to an application in order for it to function.
C language macros for manipulating version numbers are defined in the
<<boilerplate-versions,Version Number Macros>> appendix.
[[fundamentals-common-objects]]
== Common Object Types

28
chapters/initialization.txt
View File

@ -18,9 +18,9 @@ Commands to query function pointers for Vulkan commands are described below.
[NOTE]
.Note
====
When extensions are promoted or otherwise incorporated into another
extension or Vulkan core version, commands that have the same definition and
behavior are referred to as "`aliases`", and are documented as such.
When extensions are <<extendingvulkan-compatibility-promotion,promoted>> or
otherwise incorporated into another extension or Vulkan core version,
command <<extendingvulkan-compatibility-aliases,aliases>> may be included.
Whilst the behavior of each command alias is identical, the behavior of
retrieving each alias's function pointer is not.
A function pointer for a given alias can only be retrieved if the extension
@ -193,20 +193,17 @@ include::../api/handles/VkInstance.txt[]
--
ifdef::VK_VERSION_1_1[]
[open,refpage='vkEnumerateInstanceVersion',desc='Query instance-level version before instance creation',type='protos']
--
The version of Vulkan that is supported by an instance may: be different
than the version of Vulkan supported by a device or physical device.
To query properties that can: be used in creating an instance, call:
To query the version of instance-level functionality supported by the
implementation, call:
include::../api/protos/vkEnumerateInstanceVersion.txt[]
* pname:pApiVersion points to a code:uint32_t, which is the version of
Vulkan supported by instance-level functionality, encoded as described
in the <<fundamentals-versionnum,API Version Numbers and Semantics>>
section.
in <<extendingvulkan-coreversions-versionnumbers>>.
include::../validity/protos/vkEnumerateInstanceVersion.txt[]
@ -242,7 +239,7 @@ creation to succeed.
.Valid Usage
****
* [[VUID-vkCreateInstance-ppEnabledExtensionNames-01388]]
All <<extended-functionality-extensions-dependencies, required
All <<extendingvulkan-extensions-extensiondependencies, required
extensions>> for each extension in the
slink:VkInstanceCreateInfo::pname:ppEnabledExtensionNames list must:
also be present in that list.
@ -270,8 +267,7 @@ include::../api/structs/VkInstanceCreateInfo.txt[]
* pname:ppEnabledLayerNames is a pointer to an array of
pname:enabledLayerCount null-terminated UTF-8 strings containing the
names of layers to enable for the created instance.
See the <<extended-functionality-layers,Layers>> section for further
details.
See the <<extendingvulkan-layers>> section for further details.
* pname:enabledExtensionCount is the number of global extensions to
enable.
* pname:ppEnabledExtensionNames is a pointer to an array of
@ -319,8 +315,8 @@ include::../api/structs/VkApplicationInfo.txt[]
application.
ifndef::VK_VERSION_1_1[]
* pname:apiVersion is the version of the Vulkan API against which the
application expects to run, encoded as described in the
<<fundamentals-versionnum,API Version Numbers and Semantics>> section.
application expects to run, encoded as described in
<<extendingvulkan-coreversions-versionnumbers>>.
If pname:apiVersion is 0 the implementation must: ignore it, otherwise
if the implementation does not support the requested pname:apiVersion,
or an effective substitute for pname:apiVersion, it must: return
@ -328,8 +324,8 @@ ifndef::VK_VERSION_1_1[]
endif::VK_VERSION_1_1[]
ifdef::VK_VERSION_1_1[]
* pname:apiVersion must: be the highest version of Vulkan that the
application is designed to use, encoded as described in the
<<fundamentals-versionnum,API Version Numbers and Semantics>> section.
application is designed to use, encoded as described in
<<extendingvulkan-coreversions-versionnumbers>>.
endif::VK_VERSION_1_1[]
The patch version number specified in pname:apiVersion is ignored when
creating an instance object.

186
chapters/interfaces.txt
View File

@ -920,48 +920,49 @@ The numeric order of code:Offset decorations does not need to follow member
declaration order.
====
ifdef::VK_EXT_scalar_block_layout[]
If the <<features-features-scalarBlockLayout,pname:scalarBlockLayout>>
feature is enabled, then the layout of blocks in these storage classes must:
adhere to the <<interfaces-scalar-block-layout, Scalar Alignment>>
requirements below.
If the feature is not enabled, they must adhere to the stricter
<<interfaces-base-block-layout, Base Alignment>>.
[NOTE]
.Note
====
Even if scalar alignment is supported, it is generally more performant to
use the _base alignment_.
====
[[interfaces-alignment-requirements]]
*Alignment Requirements*
[[interfaces-base-block-layout]]
==== Base Alignment
endif::VK_EXT_scalar_block_layout[]
There are different alignment requirements depending on the specific
resources and on the features enabled on the device.
There are two different layouts requirements depending on the specific
resources.
[[interfaces-resources-layout-std140]]
*Standard Uniform Buffer Layout*
The _base alignment_ of the type of an code:OpTypeStruct member of is
The _scalar alignment_ of the type of an code:OpTypeStruct member of is
defined recursively as follows:
* A scalar of size [eq]#N# has a base alignment of [eq]#N#.
* A two-component vector, with components of size [eq]#N#, has a base
alignment of [eq]#2 N#.
* A three- or four-component vector, with components of size [eq]#N#, has
a base alignment of [eq]#4 N#.
* A scalar of size [eq]#N# has a scalar alignment of [eq]#N#.
* A vector or matrix type has a scalar alignment equal to that of its
component type.
* An array type has a scalar alignment equal to that of its element type.
* A structure has a scalar alignment equal to the largest scalar alignment
of any of its members.
The _base alignment_ of the type of an code:OpTypeStruct member is defined
recursively as follows:
* A scalar has a base alignment equal to its scalar alignment.
* A two-component vector has a base alignment equal to twice its scalar
alignment.
* A three- or four-component vector has a base alignment equal to four
times its scalar alignment.
* An array has a base alignment equal to the base alignment of its element
type, rounded up to a multiple of [eq]#16#.
type.
* A structure has a base alignment equal to the largest base alignment of
any of its members, rounded up to a multiple of [eq]#16#.
any of its members.
* A row-major matrix of [eq]#C# columns has a base alignment equal to the
base alignment of a vector of [eq]#C# matrix components.
* A column-major matrix has a base alignment equal to the base alignment
of the matrix column type.
The _extended alignment_ of the type of an code:OpTypeStruct member is
similarly defined as follows:
* A scalar, vector or matrix type has an extended alignment equal to its
base alignment.
* An array or structure type has an extended alignment equal to the
largest extended alignment of any of its members, rounded up to a
multiple of 16.
ifdef::VK_VERSION_1_1,VK_KHR_relaxed_block_layout[]
A member is defined to _improperly straddle_ if either of the following are
@ -976,85 +977,60 @@ true:
endif::VK_VERSION_1_1,VK_KHR_relaxed_block_layout[]
Every member of an code:OpTypeStruct with storage class of code:Uniform and
a decoration of code:Block (uniform buffers) must: be laid out according to
the following rules:
ifndef::VK_VERSION_1_1,VK_KHR_relaxed_block_layout[]
* The code:Offset decoration must: be a multiple of its base alignment.
endif::VK_VERSION_1_1,VK_KHR_relaxed_block_layout[]
ifdef::VK_VERSION_1_1,VK_KHR_relaxed_block_layout[]
* The code:Offset decoration of a scalar, an array, a structure, or a
matrix must: be a multiple of its base alignment.
* The code:Offset decoration of a vector must: be an integer multiple of
the base alignment of its scalar component type, and must: not
improperly straddle, as defined above.
endif::VK_VERSION_1_1,VK_KHR_relaxed_block_layout[]
* Any code:ArrayStride or code:MatrixStride decoration must: be an integer
multiple of the base alignment of the array or matrix from above.
* The code:Offset decoration of a member must: not place it between the
end of a structure or an array and the next multiple of the base
alignment of that structure or array.
[NOTE]
.Note
====
The *std140 layout* in GLSL satisfies these rules.
====
[[interfaces-resources-layout-std430]]
*Standard Storage Buffer Layout*
Member variables of an code:OpTypeStruct with a storage class of
code:PushConstant (push constants), or a storage class of code:Uniform with
a decoration of code:BufferBlock (storage buffers)
ifdef::VK_VERSION_1_1,VK_KHR_storage_buffer_storage_class[]
, or a storage class of code:StorageBuffer with a decoration of code:Block
endif::VK_VERSION_1_1,VK_KHR_storage_buffer_storage_class[]
ifdef::VK_EXT_buffer_device_address[]
, or a storage class of code:PhysicalStorageBufferEXT with a decoration of
code:Block
endif::VK_EXT_buffer_device_address[]
must: be laid out as <<interfaces-resources-layout-std140,above>>, except
for array and structure base alignment which do not need to be rounded up to
a multiple of [eq]#16#.
[NOTE]
.Note
====
The *std430 layout* in GLSL satisfies these rules.
====
ifdef::VK_EXT_scalar_block_layout[]
[[interfaces-scalar-block-layout]]
==== Scalar Alignment
The _scalar alignment_ of the type of an code:OpTypeStruct member of is
defined recursively as follows:
* A scalar of size [eq]#N# has a scalar alignment of [eq]#N#.
* A vector has a scalar alignment equal to that of its component type.
* A matrix has a scalar alignment equal to that of its component type.
* An array has a scalar alignment equal to that of its element type.
* A structure has a scalar alignment equal to the largest scalar alignment
of any of its members.
[[interfaces-resources-standard-layout]]
*Standard Buffer Layout*
Every member of an code:OpTypeStruct with storage class of code:Uniform,
code:StorageBuffer, or code:PushConstant must: be laid out according to the
following rules:
* The code:Offset decoration must: be a multiple of its scalar alignment.
* Any code:ArrayStride or code:MatrixStride decoration must: be an integer
multiple of the scalar alignment of the array or matrix from above.
code:StorageBuffer, or code:PushConstant must: be aligned according to the
first matching rule as follows:
ifdef::VK_EXT_scalar_block_layout[]
. If the code:scalarBlockLayout feature is enabled on the device then every
member must: be aligned according to its scalar alignment.
endif::VK_EXT_scalar_block_layout[]
ifdef::VK_VERSION_1_1,VK_KHR_relaxed_block_layout[]
. All vectors must: be aligned according to their scalar alignment.
endif::VK_VERSION_1_1,VK_KHR_relaxed_block_layout[]
. Any member of an code:OpTypeStruct with a storage class of code:Uniform and a
decoration of code:Block must: be aligned according to its extended
alignment.
. Every other member must: be aligned according to its base alignment.
ifdef::VK_EXT_scalar_block_layout[]
[NOTE]
.Note
====
Even if scalar alignment is supported, it is generally more performant to
use the _base alignment_.
====
endif::VK_EXT_scalar_block_layout[]
The memory layout must: obey the following rules:
* The code:Offset decoration of any member must: be a multiple of its
alignment.
* Any code:ArrayStride or code:MatrixStride decoration must: be a multiple
of the alignment of the array or matrix as defined above.
ifdef::VK_EXT_scalar_block_layout[]
Unless the code:scalarBlockLayout feature is enabled on the device:
endif::VK_EXT_scalar_block_layout[]
ifdef::VK_VERSION_1_1,VK_KHR_relaxed_block_layout[]
* Vectors must: not improperly straddle, as defined above.
endif::VK_VERSION_1_1,VK_KHR_relaxed_block_layout[]
* The code:Offset decoration of a member must: not place it between the
end of a structure or an array and the next multiple of the alignment of
that structure or array.
[NOTE]
.Note
====
The *std430 layout* in GLSL satisfies these rules for types using the base
alignment.
The *std140 layout* satisfies the rules for types using the extended
alignment.
====
[[interfaces-builtin-variables]]

5
chapters/memory.txt
View File

@ -2006,6 +2006,9 @@ include::../api/structs/VkMemoryHostPointerPropertiesEXT.txt[]
* pname:memoryTypeBits is a bitmask containing one bit set for every
memory type which the specified host pointer can: be imported as.
The value returned by pname:memoryTypeBits must: only include bits that
identify memory types which are host visible.
include::../validity/structs/VkMemoryHostPointerPropertiesEXT.txt[]
--
@ -2849,6 +2852,8 @@ Protected memory adds the following concepts:
subject to the inviolable rules below.
*** Any query during protected queue operations results in undefined:
behavior, but is subject to the inviolable rules below.
*** Any indirect command during protected queue operations results in
undefined: behavior but is subject to the inviolable rules below.
[[memory-protected-memory-undefined]]

2
chapters/pipelines.txt
View File

@ -745,7 +745,7 @@ endif::VK_VERSION_1_1,VK_KHR_maintenance2[]
then for each color attachment in the subpass the pname:blendEnable
member of the corresponding element of the pname:pAttachment member of
pname:pColorBlendState must: be ename:VK_FALSE if the attached image's
<<resources-image-format-features,format features>> does not contain the
<<resources-image-format-features,format features>> does not contain
ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT.
* [[VUID-VkGraphicsPipelineCreateInfo-attachmentCount-00746]]
If rasterization is not disabled and the subpass uses color attachments,

50
chapters/primsrast.txt
View File

@ -50,8 +50,21 @@ include::../api/structs/VkPipelineRasterizationStateCreateInfo.txt[]
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:flags is reserved for future use.
* pname:depthClampEnable controls whether to clamp the fragment's depth
values instead of clipping primitives to the z planes of the frustum, as
described in <<vertexpostproc-clipping,Primitive Clipping>>.
values as described in <<fragops-depth,Depth Test>>.
ifdef::VK_EXT_depth_clip_enable[]
If the pipeline is not created with
slink:VkPipelineRasterizationDepthClipStateCreateInfoEXT present then
enabling depth clamp will also disable clipping primitives to the z
planes of the frustrum as described in <<vertexpostproc-clipping,
Primitive Clipping>>.
Otherwise depth clipping is controlled by the state set in
sname:VkPipelineRasterizationDepthClipStateCreateInfoEXT.
endif::VK_EXT_depth_clip_enable[]
ifndef::VK_EXT_depth_clip_enable[]
Enabling depth clamp will also disable clipping primitives to the z
planes of the frustrum as described in <<vertexpostproc-clipping,
Primitive Clipping>>.
endif::VK_EXT_depth_clip_enable[]
* pname:rasterizerDiscardEnable controls whether primitives are discarded
immediately before the rasterization stage.
* pname:polygonMode is the triangle rendering mode.
@ -113,6 +126,39 @@ tname:VkPipelineRasterizationStateCreateFlags is a bitmask type for setting
a mask, but is currently reserved for future use.
--
ifdef::VK_EXT_depth_clip_enable[]
[open,refpage='VkPipelineRasterizationDepthClipStateCreateInfoEXT',desc='Structure specifying depth clipping state',type='structs']
--
If the pNext chain of slink:VkPipelineRasterizationStateCreateInfo includes
a sname:VkPipelineRasterizationDepthClipStateCreateInfoEXT structure, then
that structure controls whether depth clipping is enabled or disabled.
The sname:VkPipelineRasterizationDepthClipStateCreateInfoEXT structure is
defined as:
include::../api/structs/VkPipelineRasterizationDepthClipStateCreateInfoEXT.txt[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:flags is reserved for future use.
* pname:depthClipEnable controls whether depth clipping is enabled as
described in <<vertexpostproc-clipping, Primitive Clipping>>.
include::../validity/structs/VkPipelineRasterizationDepthClipStateCreateInfoEXT.txt[]
--
[open,refpage='VkPipelineRasterizationDepthClipStateCreateFlagsEXT',desc='Reserved for future use',type='flags']
--
include::../api/flags/VkPipelineRasterizationDepthClipStateCreateFlagsEXT.txt[]
tname:VkPipelineRasterizationDepthClipStateCreateFlagsEXT is a bitmask type
for setting a mask, but is currently reserved for future use.
--
endif::VK_EXT_depth_clip_enable[]
[open,refpage='VkPipelineMultisampleStateCreateInfo',desc='Structure specifying parameters of a newly created pipeline multisample state',type='structs']
--

65
chapters/renderpass.txt
View File

@ -982,22 +982,40 @@ attachment.
not be ename:VK_ATTACHMENT_LOAD_OP_CLEAR
* [[VUID-VkSubpassDescription-pResolveAttachments-00847]]
If pname:pResolveAttachments is not `NULL`, for each resolve attachment
that does not have the value ename:VK_ATTACHMENT_UNUSED, the
corresponding color attachment must: not have the value
ename:VK_ATTACHMENT_UNUSED
that is not ename:VK_ATTACHMENT_UNUSED, the corresponding color
attachment must: not be ename:VK_ATTACHMENT_UNUSED
* [[VUID-VkSubpassDescription-pResolveAttachments-00848]]
If pname:pResolveAttachments is not `NULL`, the sample count of each
element of pname:pColorAttachments must: be anything other than
ename:VK_SAMPLE_COUNT_1_BIT
If pname:pResolveAttachments is not `NULL`, for each resolve attachment
that is not ename:VK_ATTACHMENT_UNUSED, the corresponding color
attachment must: not have a sample count of ename:VK_SAMPLE_COUNT_1_BIT
* [[VUID-VkSubpassDescription-pResolveAttachments-00849]]
Each element of pname:pResolveAttachments must: have a sample count of
If pname:pResolveAttachments is not `NULL`, each resolve attachment that
is not ename:VK_ATTACHMENT_UNUSED must: have a sample count of
ename:VK_SAMPLE_COUNT_1_BIT
* [[VUID-VkSubpassDescription-pResolveAttachments-00850]]
Each element of pname:pResolveAttachments must: have the same
elink:VkFormat as its corresponding color attachment
If pname:pResolveAttachments is not `NULL`, each resolve attachment that
is not ename:VK_ATTACHMENT_UNUSED must: have the same elink:VkFormat as
its corresponding color attachment
* [[VUID-VkSubpassDescription-pColorAttachments-01417]]
All attachments in pname:pColorAttachments that are not
ename:VK_ATTACHMENT_UNUSED must: have the same sample count
* [[VUID-VkSubpassDescription-pInputAttachments-02647]]
All attachments in pname:pInputAttachments that are not
ename:VK_ATTACHMENT_UNUSED must: have formats whose features contain at
least one of ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT or
ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT.
* [[VUID-VkSubpassDescription-pColorAttachments-02648]]
All attachments in pname:pColorAttachments that are not
ename:VK_ATTACHMENT_UNUSED must: have formats whose features contain
ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT
* [[VUID-VkSubpassDescription-pResolveAttachments-02649]]
All attachments in pname:pResolveAttachments that are not
ename:VK_ATTACHMENT_UNUSED must: have formats whose features contain
ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT
* [[VUID-VkSubpassDescription-pDepthStencilAttachment-02650]]
If pname:pDepthStencilAttachment is not `NULL` and the attachment is not
ename:VK_ATTACHMENT_UNUSED then it must: have a format whose features
contain ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT
ifdef::VK_AMD_mixed_attachment_samples[]
* [[VUID-VkSubpassDescription-pColorAttachments-01506]]
If the `VK_AMD_mixed_attachment_samples` extension is enabled, and all
@ -1088,7 +1106,8 @@ include::../api/structs/VkAttachmentReference.txt[]
.Valid Usage
****
* [[VUID-VkAttachmentReference-layout-00857]]
pname:layout must: not be ename:VK_IMAGE_LAYOUT_UNDEFINED or
If pname:attachment is not ename:VK_ATTACHMENT_UNUSED, pname:layout
must: not be ename:VK_IMAGE_LAYOUT_UNDEFINED or
ename:VK_IMAGE_LAYOUT_PREINITIALIZED
****
@ -1820,12 +1839,13 @@ corresponding subpass.
corresponding color attachment must: not have the value
ename:VK_ATTACHMENT_UNUSED
* [[VUID-VkSubpassDescription2KHR-pResolveAttachments-03066]]
If pname:pResolveAttachments is not `NULL`, the sample count of each
element of pname:pColorAttachments must: be anything other than
ename:VK_SAMPLE_COUNT_1_BIT
If pname:pResolveAttachments is not `NULL`, for each resolve attachment
that is not ename:VK_ATTACHMENT_UNUSED, the corresponding color
attachment must: not have a sample count of ename:VK_SAMPLE_COUNT_1_BIT
* [[VUID-VkSubpassDescription2KHR-pResolveAttachments-03067]]
Any given element of pname:pResolveAttachments must: have a sample count
of ename:VK_SAMPLE_COUNT_1_BIT
If pname:pResolveAttachments is not `NULL`, each resolve attachment that
is not ename:VK_ATTACHMENT_UNUSED must: have a sample count of
ename:VK_SAMPLE_COUNT_1_BIT
* [[VUID-VkSubpassDescription2KHR-pResolveAttachments-03068]]
Any given element of pname:pResolveAttachments must: have the same
elink:VkFormat as its corresponding color attachment
@ -1911,12 +1931,18 @@ include::../api/structs/VkSubpassDescriptionDepthStencilResolveKHR.txt[]
pname:stencilResolveMode must: not both be
ename:VK_RESOLVE_MODE_NONE_KHR
* [[VUID-VkSubpassDescriptionDepthStencilResolveKHR-pDepthStencilResolveAttachment-03179]]
If pname:pDepthStencilResolveAttachment is not `NULL`, the sample count
of pname:pDepthStencilAttachment must: be anything other than
ename:VK_SAMPLE_COUNT_1_BIT
If pname:pDepthStencilResolveAttachment is not `NULL` and does not have
the value ename:VK_ATTACHMENT_UNUSED, pname:pDepthStencilAttachment
must: not have a sample count of ename:VK_SAMPLE_COUNT_1_BIT
* [[VUID-VkSubpassDescriptionDepthStencilResolveKHR-pDepthStencilResolveAttachment-03180]]
If pname:pDepthStencilResolveAttachment is not `NULL` and does not have
the value ename:VK_ATTACHMENT_UNUSED,
pname:pDepthStencilResolveAttachment must: have a sample count of
ename:VK_SAMPLE_COUNT_1_BIT
* [[VUID-VkSubpassDescriptionDepthStencilResolveKHR-pDepthStencilResolveAttachment-02651]]
If pname:pDepthStencilResolveAttachment is not `NULL` and does not have
the value ename:VK_ATTACHMENT_UNUSED then it must: have a format whose
features contain ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT
* [[VUID-VkSubpassDescriptionDepthStencilResolveKHR-pDepthStencilResolveAttachment-03181]]
If the elink:VkFormat of pname:pDepthStencilResolveAttachment has a
depth component, then the elink:VkFormat of
@ -2018,7 +2044,8 @@ input attachment reference.
.Valid Usage
****
* [[VUID-VkAttachmentReference2KHR-layout-03077]]
pname:layout must: not be ename:VK_IMAGE_LAYOUT_UNDEFINED or
If pname:attachment is not ename:VK_ATTACHMENT_UNUSED, pname:layout
must: not be ename:VK_IMAGE_LAYOUT_UNDEFINED or
ename:VK_IMAGE_LAYOUT_PREINITIALIZED
****

6
chapters/resources.txt
View File

@ -3171,6 +3171,12 @@ endif::VK_EXT_fragment_density_map[]
ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT, then the image view's
<<resources-image-view-format-features,format features>> must: contain
ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT.
* [[VUID-VkImageViewCreateInfo-usage-02652]]
If pname:usage contains ename:VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT, then
the image view's <<resources-image-view-format-features,format
features>> must: contain at least one of
ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT or
ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT.
* [[VUID-VkImageViewCreateInfo-subresourceRange-01478]]
pname:subresourceRange.baseMipLevel must: be less than the
pname:mipLevels specified in slink:VkImageCreateInfo when pname:image

144
chapters/shaders.txt
View File

@ -982,6 +982,150 @@ endif::VK_NV_shader_subgroup_partitioned[]
endif::VK_VERSION_1_1[]
ifdef::VK_NV_cooperative_matrix[]
== Cooperative Matrices
A _cooperative matrix_ type is a SPIR-V type where the storage for and
computations performed on the matrix are spread across a set of invocations
such as a subgroup.
These types give the implementation freedom in how to optimize matrix
multiplies.
SPIR-V defines the types and instructions, but does not specify rules about
what sizes/combinations are valid, and it is expected that different
implementations may: support different sizes.
[open,refpage='vkGetPhysicalDeviceCooperativeMatrixPropertiesNV',desc='Returns properties describing what cooperative matrix types are supported',type='protos']
--
To enumerate the supported cooperative matrix types and operations, call:
include::../api/protos/vkGetPhysicalDeviceCooperativeMatrixPropertiesNV.txt[]
* pname:physicalDevice is the physical device.
* pname:pPropertyCount is a pointer to an integer related to the number of
cooperative matrix properties available or queried.
* pname:pProperties is either `NULL` or a pointer to an array of
slink:VkCooperativeMatrixPropertiesNV structures.
If pname:pProperties is `NULL`, then the number of cooperative matrix
properties available is returned in pname:pPropertyCount.
Otherwise, pname:pPropertyCount must: point to a variable set by the user to
the number of elements in the pname:pProperties array, and on return the
variable is overwritten with the number of structures actually written to
pname:pProperties.
If pname:pPropertyCount is less than the number of cooperative matrix
properties available, at most pname:pPropertyCount structures will be
written.
If pname:pPropertyCount is smaller than the number of cooperative matrix
properties available, ename:VK_INCOMPLETE will be returned instead of
ename:VK_SUCCESS, to indicate that not all the available cooperative matrix
properties were returned.
include::../validity/protos/vkGetPhysicalDeviceCooperativeMatrixPropertiesNV.txt[]
--
[open,refpage='VkCooperativeMatrixPropertiesNV',desc='Structure specifying cooperative matrix properties',type='structs']
--
Each sname:VkCooperativeMatrixPropertiesNV structure describes a single
supported combination of types for a matrix multiply/add operation
(code:OpCooperativeMatrixMulAddNV).
The multiply can: be described in terms of the following variables and types
(in SPIR-V pseudocode):
[source,c]
---------------------------------------------------
%A is of type OpTypeCooperativeMatrixNV %AType %scope %MSize %KSize
%B is of type OpTypeCooperativeMatrixNV %BType %scope %KSize %NSize
%C is of type OpTypeCooperativeMatrixNV %CType %scope %MSize %NSize
%D is of type OpTypeCooperativeMatrixNV %DType %scope %MSize %NSize
%D = %A * %B + %C // using OpCooperativeMatrixMulAddNV
---------------------------------------------------
A matrix multiply with these dimensions is known as an _MxNxK_ matrix
multiply.
The sname:VkCooperativeMatrixPropertiesNV structure is defined as:
include::../api/structs/VkCooperativeMatrixPropertiesNV.txt[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:MSize is the number of rows in matrices A, C, and D.
* pname:KSize is the number of columns in matrix A and rows in matrix B.
* pname:NSize is the number of columns in matrices B, C, D.
* pname:AType is the component type of matrix A, of type
elink:VkComponentTypeNV.
* pname:BType is the component type of matrix B, of type
elink:VkComponentTypeNV.
* pname:CType is the component type of matrix C, of type
elink:VkComponentTypeNV.
* pname:DType is the component type of matrix D, of type
elink:VkComponentTypeNV.
* pname:scope is the scope of all the matrix types, of type
elink:VkScopeNV.
If some types are preferred over other types (e.g. for performance), they
should: appear earlier in the list enumerated by
flink:vkGetPhysicalDeviceCooperativeMatrixPropertiesNV.
At least one entry in the list must: have power of two values for all of
pname:MSize, pname:KSize, and pname:NSize.
include::../validity/structs/VkCooperativeMatrixPropertiesNV.txt[]
--
[open,refpage='VkScopeNV',desc='Specify SPIR-V scope',type='enums']
--
Possible values for elink:VkScopeNV include:
include::../api/enums/VkScopeNV.txt[]
* ename:VK_SCOPE_DEVICE_NV corresponds to SPIR-V code:Device scope.
* ename:VK_SCOPE_WORKGROUP_NV corresponds to SPIR-V code:Workgroup scope.
* ename:VK_SCOPE_SUBGROUP_NV corresponds to SPIR-V code:Subgroup scope.
* ename:VK_SCOPE_QUEUE_FAMILY_NV corresponds to SPIR-V code:QueueFamilyKHR
scope.
All enum values match the corresponding SPIR-V value.
--
[open,refpage='VkComponentTypeNV',desc='Specify SPIR-V cooperative matrix component type',type='enums']
--
Possible values for elink:VkComponentTypeNV include:
include::../api/enums/VkComponentTypeNV.txt[]
* ename:VK_COMPONENT_TYPE_FLOAT16_NV corresponds to SPIR-V
code:OpTypeFloat 16.
* ename:VK_COMPONENT_TYPE_FLOAT32_NV corresponds to SPIR-V
code:OpTypeFloat 32.
* ename:VK_COMPONENT_TYPE_FLOAT64_NV corresponds to SPIR-V
code:OpTypeFloat 64.
* ename:VK_COMPONENT_TYPE_SINT8_NV corresponds to SPIR-V code:OpTypeInt 8
1.
* ename:VK_COMPONENT_TYPE_SINT16_NV corresponds to SPIR-V code:OpTypeInt
16 1.
* ename:VK_COMPONENT_TYPE_SINT32_NV corresponds to SPIR-V code:OpTypeInt
32 1.
* ename:VK_COMPONENT_TYPE_SINT64_NV corresponds to SPIR-V code:OpTypeInt
64 1.
* ename:VK_COMPONENT_TYPE_UINT8_NV corresponds to SPIR-V code:OpTypeInt 8
0.
* ename:VK_COMPONENT_TYPE_UINT16_NV corresponds to SPIR-V code:OpTypeInt
16 0.
* ename:VK_COMPONENT_TYPE_UINT32_NV corresponds to SPIR-V code:OpTypeInt
32 0.
* ename:VK_COMPONENT_TYPE_UINT64_NV corresponds to SPIR-V code:OpTypeInt
64 0.
--
endif::VK_NV_cooperative_matrix[]
ifdef::VK_EXT_validation_cache[]
[[shaders-validation-cache]]
== Validation Cache

2
chapters/synchronization.txt
View File

@ -2577,7 +2577,7 @@ Unlike fences or events, the act of waiting for a semaphore also unsignals
that semaphore.
If two operations are separately specified to wait for the same semaphore,
and there are no other execution dependencies between those operations,
behaviour is undefined:.
behavior is undefined:.
An execution dependency must: be present that guarantees that the semaphore
unsignal operation for the first of those waits, happens-before the
semaphore is signalled again, and before the second unsignal operation.

14
chapters/textures.txt
View File

@ -594,9 +594,9 @@ ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
==== Layout Validation
If all planes of a _disjoint_ _multi-planar_ image are not in the same
<<resources-image-layouts,image layout>> when the image is sampled with
<<samplers-YCbCr-conversion,sampler Y'C~B~C~R~ conversion>>, the values
returned by texel reads are undefined:.
<<resources-image-layouts,image layout>>, sampling the image with
<<samplers-YCbCr-conversion,sampler Y'C~B~C~R~ conversion>>, will result in
undefined: behavior.
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
@ -792,7 +792,7 @@ It is defined as follows for each color [eq]#component#:
[latexmath]
+++++++++++++++++++
\begin{aligned}
Color'_{component} & =
Color'_{component} & =
\begin{cases}
Color_r & \text{for RED swizzle} \\
Color_g & \text{for GREEN swizzle} \\
@ -816,7 +816,7 @@ one & =
& 1 & \text{for integer components} \\
\end{cases}
\\
identity & =
identity & =
\begin{cases}
& Color_r & \text{for}\ component = r \\
& Color_g & \text{for}\ component = g \\
@ -1362,7 +1362,9 @@ fragments for each fragment shader invocation.
These neighboring fragments are used to compute derivatives with the
assumption that the values of P in the neighborhood are piecewise linear.
It is further assumed that the values of P in the neighborhood are locally
continuous, therefore derivatives in non-uniform control flow are undefined.
continuous.
Therefore, computation of derivatives in non-uniform control flow has
undefined: behavior.
[latexmath]
+++++++++++++++++++

17
chapters/vertexpostproc.txt
View File

@ -589,9 +589,22 @@ determined by the explicit size of the built-in arrays code:ClipDistance and
code:CullDistance, respectively, declared as an output in the interface of
the entry point of the final shader stage before clipping.
ifdef::VK_EXT_depth_clip_enable[]
If sname:VkPipelineRasterizationDepthClipStateCreateInfoEXT is present in
the graphics pipeline state then depth clipping is disabled if
sname:VkPipelineRasterizationDepthClipStateCreateInfoEXT::pname:depthClipEnable
is ename:VK_FALSE.
Otherwise, if sname:VkPipelineRasterizationDepthClipStateCreateInfoEXT is
not present, depth clipping is disabled when
sname:VkPipelineRasterizationStateCreateInfo::pname:depthClampEnable is
ename:VK_TRUE.
endif::VK_EXT_depth_clip_enable[]
ifndef::VK_EXT_depth_clip_enable[]
Depth clamping is enabled or disabled via the pname:depthClampEnable enable
of the sname:VkPipelineRasterizationStateCreateInfo structure.
If depth clamping is enabled, the plane equation
Depth clipping is disabled when pname:depthClampEnable is ename:VK_TRUE.
endif::VK_EXT_depth_clip_enable[]
When depth clipping is disabled, the plane equation
:: [eq]#0 {leq} z~c~ {leq} w~c~#
@ -609,7 +622,7 @@ endif::VK_VERSION_1_1,VK_KHR_maintenance2[]
ifdef::VK_VERSION_1_1,VK_KHR_maintenance2[]
[open,refpage='VkPointClippingBehavior',desc='Enum specifying the point clipping behaviour',type='enums']
[open,refpage='VkPointClippingBehavior',desc='Enum specifying the point clipping behavior',type='enums']
--
Possible values of

98
include/vulkan/vulkan_core.h
View File

@ -43,7 +43,7 @@ extern "C" {
#define VK_VERSION_MINOR(version) (((uint32_t)(version) >> 12) & 0x3ff)
#define VK_VERSION_PATCH(version) ((uint32_t)(version) & 0xfff)
// Version of this file
#define VK_HEADER_VERSION 100
#define VK_HEADER_VERSION 101
#define VK_NULL_HANDLE 0
@ -349,6 +349,8 @@ typedef enum VkStructureType {
VK_STRUCTURE_TYPE_PIPELINE_DISCARD_RECTANGLE_STATE_CREATE_INFO_EXT = 1000099001,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CONSERVATIVE_RASTERIZATION_PROPERTIES_EXT = 1000101000,
VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_CONSERVATIVE_STATE_CREATE_INFO_EXT = 1000101001,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLIP_ENABLE_FEATURES_EXT = 1000102000,
VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_DEPTH_CLIP_STATE_CREATE_INFO_EXT = 1000102001,
VK_STRUCTURE_TYPE_HDR_METADATA_EXT = 1000105000,
VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2_KHR = 1000109000,
VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2_KHR = 1000109001,
@ -474,6 +476,9 @@ typedef enum VkStructureType {
VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_CREATE_INFO_EXT = 1000244002,
VK_STRUCTURE_TYPE_IMAGE_STENCIL_USAGE_CREATE_INFO_EXT = 1000246000,
VK_STRUCTURE_TYPE_VALIDATION_FEATURES_EXT = 1000247000,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_FEATURES_NV = 1000249000,
VK_STRUCTURE_TYPE_COOPERATIVE_MATRIX_PROPERTIES_NV = 1000249001,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_PROPERTIES_NV = 1000249002,
VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT = VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,
VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO_KHR = VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHR = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES,
@ -7462,6 +7467,27 @@ typedef struct VkPipelineRasterizationConservativeStateCreateInfoEXT {
#define VK_EXT_depth_clip_enable 1
#define VK_EXT_DEPTH_CLIP_ENABLE_SPEC_VERSION 1
#define VK_EXT_DEPTH_CLIP_ENABLE_EXTENSION_NAME "VK_EXT_depth_clip_enable"
typedef VkFlags VkPipelineRasterizationDepthClipStateCreateFlagsEXT;
typedef struct VkPhysicalDeviceDepthClipEnableFeaturesEXT {
VkStructureType sType;
void* pNext;
VkBool32 depthClipEnable;
} VkPhysicalDeviceDepthClipEnableFeaturesEXT;
typedef struct VkPipelineRasterizationDepthClipStateCreateInfoEXT {
VkStructureType sType;
const void* pNext;
VkPipelineRasterizationDepthClipStateCreateFlagsEXT flags;
VkBool32 depthClipEnable;
} VkPipelineRasterizationDepthClipStateCreateInfoEXT;
#define VK_EXT_swapchain_colorspace 1
#define VK_EXT_SWAPCHAIN_COLOR_SPACE_SPEC_VERSION 3
#define VK_EXT_SWAPCHAIN_COLOR_SPACE_EXTENSION_NAME "VK_EXT_swapchain_colorspace"
@ -9126,6 +9152,76 @@ typedef struct VkValidationFeaturesEXT {
#define VK_NV_cooperative_matrix 1
#define VK_NV_COOPERATIVE_MATRIX_SPEC_VERSION 1
#define VK_NV_COOPERATIVE_MATRIX_EXTENSION_NAME "VK_NV_cooperative_matrix"
typedef enum VkComponentTypeNV {
VK_COMPONENT_TYPE_FLOAT16_NV = 0,
VK_COMPONENT_TYPE_FLOAT32_NV = 1,
VK_COMPONENT_TYPE_FLOAT64_NV = 2,
VK_COMPONENT_TYPE_SINT8_NV = 3,
VK_COMPONENT_TYPE_SINT16_NV = 4,
VK_COMPONENT_TYPE_SINT32_NV = 5,
VK_COMPONENT_TYPE_SINT64_NV = 6,
VK_COMPONENT_TYPE_UINT8_NV = 7,
VK_COMPONENT_TYPE_UINT16_NV = 8,
VK_COMPONENT_TYPE_UINT32_NV = 9,
VK_COMPONENT_TYPE_UINT64_NV = 10,
VK_COMPONENT_TYPE_BEGIN_RANGE_NV = VK_COMPONENT_TYPE_FLOAT16_NV,
VK_COMPONENT_TYPE_END_RANGE_NV = VK_COMPONENT_TYPE_UINT64_NV,
VK_COMPONENT_TYPE_RANGE_SIZE_NV = (VK_COMPONENT_TYPE_UINT64_NV - VK_COMPONENT_TYPE_FLOAT16_NV + 1),
VK_COMPONENT_TYPE_MAX_ENUM_NV = 0x7FFFFFFF
} VkComponentTypeNV;
typedef enum VkScopeNV {
VK_SCOPE_DEVICE_NV = 1,
VK_SCOPE_WORKGROUP_NV = 2,
VK_SCOPE_SUBGROUP_NV = 3,
VK_SCOPE_QUEUE_FAMILY_NV = 5,
VK_SCOPE_BEGIN_RANGE_NV = VK_SCOPE_DEVICE_NV,
VK_SCOPE_END_RANGE_NV = VK_SCOPE_QUEUE_FAMILY_NV,
VK_SCOPE_RANGE_SIZE_NV = (VK_SCOPE_QUEUE_FAMILY_NV - VK_SCOPE_DEVICE_NV + 1),
VK_SCOPE_MAX_ENUM_NV = 0x7FFFFFFF
} VkScopeNV;
typedef struct VkCooperativeMatrixPropertiesNV {
VkStructureType sType;
void* pNext;
uint32_t MSize;
uint32_t NSize;
uint32_t KSize;
VkComponentTypeNV AType;
VkComponentTypeNV BType;
VkComponentTypeNV CType;
VkComponentTypeNV DType;
VkScopeNV scope;
} VkCooperativeMatrixPropertiesNV;
typedef struct VkPhysicalDeviceCooperativeMatrixFeaturesNV {
VkStructureType sType;
void* pNext;
VkBool32 cooperativeMatrix;
VkBool32 cooperativeMatrixRobustBufferAccess;
} VkPhysicalDeviceCooperativeMatrixFeaturesNV;
typedef struct VkPhysicalDeviceCooperativeMatrixPropertiesNV {
VkStructureType sType;
void* pNext;
VkShaderStageFlags cooperativeMatrixSupportedStages;
} VkPhysicalDeviceCooperativeMatrixPropertiesNV;
typedef VkResult (VKAPI_PTR *PFN_vkGetPhysicalDeviceCooperativeMatrixPropertiesNV)(VkPhysicalDevice physicalDevice, uint32_t* pPropertyCount, VkCooperativeMatrixPropertiesNV* pProperties);
#ifndef VK_NO_PROTOTYPES
VKAPI_ATTR VkResult VKAPI_CALL vkGetPhysicalDeviceCooperativeMatrixPropertiesNV(
VkPhysicalDevice physicalDevice,
uint32_t* pPropertyCount,
VkCooperativeMatrixPropertiesNV* pProperties);
#endif
#ifdef __cplusplus
}
#endif

2
reflow_count.py
View File

@ -1,2 +1,2 @@
# The value to start tagging VU statements at, unless overridden by -nextvu
startVUID = 2639
startVUID = 2653

6
style/naming.txt
View File

@ -272,7 +272,7 @@ A number of commands in the API are used to determine the properties of some
object in the implementation.
The queried properties may either be invariant, or they may: change based on
application behaviour.
application behavior.
If the results are not invariant, the lifetime of the results should be
clearly described in the command description.
See <<fundamentals-commandsyntax-results-lifetime,Lifetime of Retrieved
@ -316,7 +316,7 @@ verbs at the time of writing.
| Verb | Meaning
| Acquire | Acquire ownership of an object from an external source
| Allocate | Allocates memory in a pool or memory heap and creates object - paired with "Free"
| Begin | Start of a range of command buffer commands with different behaviour than those outside the range - "End" marks the end of the range
| Begin | Start of a range of command buffer commands with different behavior than those outside the range - "End" marks the end of the range
| Bind | Binds an object to another object
| Blit | Performs a filtered and scaled copy of pixels from one image to another
| Clear | Sets all pixels in an image to the same value
@ -325,7 +325,7 @@ verbs at the time of writing.
| Destroy | Destroys an object - paired with "Create"
| Dispatch | Kicks off a set of compute tasks
| Draw | Kicks off a set of rasterization tasks
| End | End of a range of command buffer commands with different behaviour than those outside the range - "Begin" marks the start of the range
| End | End of a range of command buffer commands with different behavior than those outside the range - "Begin" marks the start of the range
| Enumerate | Queries the capabilities of objects that could be created, before creating them
| Execute | Executes commands recorded in another command buffer
| Fill | Sets all data units in a buffer to the same value

92
xml/vk.xml Normal file → Executable file
View File

@ -146,7 +146,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> 100</type>
#define <name>VK_HEADER_VERSION</name> 101</type>
<type category="define">
#define <name>VK_DEFINE_HANDLE</name>(object) typedef struct object##_T* object;</type>
@ -311,6 +311,7 @@ server.
<type requires="VkConditionalRenderingFlagBitsEXT" category="bitmask">typedef <type>VkFlags</type> <name>VkConditionalRenderingFlagsEXT</name>;</type>
<type requires="VkResolveModeFlagBitsKHR" category="bitmask">typedef <type>VkFlags</type> <name>VkResolveModeFlagsKHR</name>;</type>
<type category="bitmask">typedef <type>VkFlags</type> <name>VkPipelineRasterizationStateStreamCreateFlagsEXT</name>;</type>
<type category="bitmask">typedef <type>VkFlags</type> <name>VkPipelineRasterizationDepthClipStateCreateFlagsEXT</name>;</type>
<comment>Types which can be void pointers or class pointers, selected at compile time</comment>
@ -476,6 +477,8 @@ server.
<type name="VkRayTracingShaderGroupTypeNV" category="enum"/>
<type name="VkAccelerationStructureMemoryRequirementsTypeNV" category="enum"/>
<type name="VkMemoryOverallocationBehaviorAMD" category="enum"/>
<type name="VkScopeNV" category="enum"/>
<type name="VkComponentTypeNV" category="enum"/>
<comment>WSI extensions</comment>
<type name="VkColorSpaceKHR" category="enum"/>
@ -3681,6 +3684,17 @@ server.
<member><type>void</type>* <name>pNext</name></member>
<member><type>VkBool32</type> <name>scalarBlockLayout</name></member>
</type>
<type category="struct" name="VkPhysicalDeviceDepthClipEnableFeaturesEXT" structextends="VkPhysicalDeviceFeatures2,VkDeviceCreateInfo">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLIP_ENABLE_FEATURES_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member><type>void</type>* <name>pNext</name><comment>Pointer to next structure</comment></member>
<member><type>VkBool32</type> <name>depthClipEnable</name></member>
</type>
<type category="struct" name="VkPipelineRasterizationDepthClipStateCreateInfoEXT" structextends="VkPipelineRasterizationStateCreateInfo">
<member values="VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_DEPTH_CLIP_STATE_CREATE_INFO_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member>const <type>void</type>* <name>pNext</name></member> <!-- Pointer to next structure -->
<member optional="true"><type>VkPipelineRasterizationDepthClipStateCreateFlagsEXT</type> <name>flags</name></member> <!-- Reserved -->
<member><type>VkBool32</type> <name>depthClipEnable</name></member>
</type>
<type category="struct" name="VkPhysicalDeviceMemoryBudgetPropertiesEXT" structextends="VkPhysicalDeviceMemoryProperties2" returnedonly="true">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member noautovalidity="true"><type>void</type>* <name>pNext</name></member>
@ -3725,6 +3739,29 @@ server.
<member><type>VkBool32</type> <name>filterCubic</name></member> <!-- The combinations of format, image type (and image view type if provided) can be filtered with VK_FILTER_CUBIC_EXT -->
<member><type>VkBool32</type> <name>filterCubicMinmax</name> </member> <!-- The combination of format, image type (and image view type if provided) can be filtered with VK_FILTER_CUBIC_EXT and ReductionMode of Min or Max -->
</type>
<type category="struct" name="VkPhysicalDeviceCooperativeMatrixFeaturesNV" structextends="VkPhysicalDeviceFeatures2,VkDeviceCreateInfo">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_FEATURES_NV"><type>VkStructureType</type> <name>sType</name></member>
<member><type>void</type>* <name>pNext</name></member>
<member><type>VkBool32</type> <name>cooperativeMatrix</name></member>
<member><type>VkBool32</type> <name>cooperativeMatrixRobustBufferAccess</name></member>
</type>
<type category="struct" name="VkPhysicalDeviceCooperativeMatrixPropertiesNV" returnedonly="true" structextends="VkPhysicalDeviceProperties2">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_PROPERTIES_NV"><type>VkStructureType</type> <name>sType</name></member>
<member><type>void</type>* <name>pNext</name></member>
<member><type>VkShaderStageFlags</type> <name>cooperativeMatrixSupportedStages</name></member>
</type>
<type category="struct" name="VkCooperativeMatrixPropertiesNV">
<member values="VK_STRUCTURE_TYPE_COOPERATIVE_MATRIX_PROPERTIES_NV"><type>VkStructureType</type> <name>sType</name></member>
<member><type>void</type>* <name>pNext</name></member>
<member><type>uint32_t</type> <name>MSize</name></member>
<member><type>uint32_t</type> <name>NSize</name></member>
<member><type>uint32_t</type> <name>KSize</name></member>
<member><type>VkComponentTypeNV</type> <name>AType</name></member>
<member><type>VkComponentTypeNV</type> <name>BType</name></member>
<member><type>VkComponentTypeNV</type> <name>CType</name></member>
<member><type>VkComponentTypeNV</type> <name>DType</name></member>
<member><type>VkScopeNV</type> <name>scope</name></member>
</type>
</types>
<comment>Vulkan enumerant (token) definitions</comment>
@ -4928,6 +4965,25 @@ server.
<enum value="1" name="VK_MEMORY_OVERALLOCATION_BEHAVIOR_ALLOWED_AMD"/>
<enum value="2" name="VK_MEMORY_OVERALLOCATION_BEHAVIOR_DISALLOWED_AMD"/>
</enums>
<enums name="VkScopeNV" type="enum">
<enum value="1" name="VK_SCOPE_DEVICE_NV"/>
<enum value="2" name="VK_SCOPE_WORKGROUP_NV"/>
<enum value="3" name="VK_SCOPE_SUBGROUP_NV"/>
<enum value="5" name="VK_SCOPE_QUEUE_FAMILY_NV"/>
</enums>
<enums name="VkComponentTypeNV" type="enum">
<enum value="0" name="VK_COMPONENT_TYPE_FLOAT16_NV"/>
<enum value="1" name="VK_COMPONENT_TYPE_FLOAT32_NV"/>
<enum value="2" name="VK_COMPONENT_TYPE_FLOAT64_NV"/>
<enum value="3" name="VK_COMPONENT_TYPE_SINT8_NV"/>
<enum value="4" name="VK_COMPONENT_TYPE_SINT16_NV"/>
<enum value="5" name="VK_COMPONENT_TYPE_SINT32_NV"/>
<enum value="6" name="VK_COMPONENT_TYPE_SINT64_NV"/>
<enum value="7" name="VK_COMPONENT_TYPE_UINT8_NV"/>
<enum value="8" name="VK_COMPONENT_TYPE_UINT16_NV"/>
<enum value="9" name="VK_COMPONENT_TYPE_UINT32_NV"/>
<enum value="10" name="VK_COMPONENT_TYPE_UINT64_NV"/>
</enums>
<commands comment="Vulkan command definitions">
<command successcodes="VK_SUCCESS" errorcodes="VK_ERROR_OUT_OF_HOST_MEMORY,VK_ERROR_OUT_OF_DEVICE_MEMORY,VK_ERROR_INITIALIZATION_FAILED,VK_ERROR_LAYER_NOT_PRESENT,VK_ERROR_EXTENSION_NOT_PRESENT,VK_ERROR_INCOMPATIBLE_DRIVER">
<proto><type>VkResult</type> <name>vkCreateInstance</name></proto>
@ -7116,6 +7172,12 @@ server.
<param><type>VkDevice</type> <name>device</name></param>
<param>const <type>VkBufferDeviceAddressInfoEXT</type>* <name>pInfo</name></param>
</command>
<command successcodes="VK_SUCCESS,VK_INCOMPLETE" errorcodes="VK_ERROR_OUT_OF_HOST_MEMORY,VK_ERROR_OUT_OF_DEVICE_MEMORY">
<proto><type>VkResult</type> <name>vkGetPhysicalDeviceCooperativeMatrixPropertiesNV</name></proto>
<param><type>VkPhysicalDevice</type> <name>physicalDevice</name></param>
<param optional="false,true"><type>uint32_t</type>* <name>pPropertyCount</name></param>
<param optional="true" len="pPropertyCount"><type>VkCooperativeMatrixPropertiesNV</type>* <name>pProperties</name></param>
</command>
</commands>
<feature api="vulkan" name="VK_VERSION_1_0" number="1.0" comment="Vulkan core API interface definitions">
@ -8864,10 +8926,15 @@ server.
<type name="VkConservativeRasterizationModeEXT"/>
</require>
</extension>
<extension name="VK_NV_extension_103" number="103" author="NV" contact="Daniel Koch @dgkoch" supported="disabled">
<extension name="VK_EXT_depth_clip_enable" number="103" type="device" author="EXT" contact="Piers Daniell @pdaniell-nv" supported="vulkan">
<require>
<enum value="0" name="VK_NV_EXTENSION_103_SPEC_VERSION"/>
<enum value="&quot;VK_NV_extension_103&quot;" name="VK_NV_EXTENSION_103_EXTENSION_NAME"/>
<enum value="1" name="VK_EXT_DEPTH_CLIP_ENABLE_SPEC_VERSION"/>
<enum value="&quot;VK_EXT_depth_clip_enable&quot;" name="VK_EXT_DEPTH_CLIP_ENABLE_EXTENSION_NAME"/>
<enum offset="0" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLIP_ENABLE_FEATURES_EXT"/>
<enum offset="1" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_DEPTH_CLIP_STATE_CREATE_INFO_EXT"/>
<type name="VkPhysicalDeviceDepthClipEnableFeaturesEXT"/>
<type name="VkPipelineRasterizationDepthClipStateCreateInfoEXT"/>
<type name="VkPipelineRasterizationDepthClipStateCreateFlagsEXT"/>
</require>
</extension>
<extension name="VK_NV_extension_104" number="104" author="NV" contact="Mathias Schott gitlab:@mschott" supported="disabled">
@ -9290,7 +9357,7 @@ server.
<enum value="&quot;VK_AMD_extension_143&quot;" name="VK_AMD_EXTENSION_143_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_EXT_sample_locations" number="144" type="device" author="AMD" contact="Daniel Rakos @drakos-amd" supported="vulkan">
<extension name="VK_EXT_sample_locations" number="144" type="device" author="AMD" contact="Daniel Rakos @drakos-amd" supported="vulkan" requires="VK_KHR_get_physical_device_properties2">
<require>
<enum value="1" name="VK_EXT_SAMPLE_LOCATIONS_SPEC_VERSION"/>
<enum value="&quot;VK_EXT_sample_locations&quot;" name="VK_EXT_SAMPLE_LOCATIONS_EXTENSION_NAME"/>
@ -10385,10 +10452,19 @@ server.
<enum value="&quot;VK_KHR_extension_249&quot;" name="VK_KHR_EXTENSION_249_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_NV_extension_250" number="250" author="NV" contact="Jeff Bolz @jeffbolznv" supported="disabled">
<extension name="VK_NV_cooperative_matrix" number="250" type="device" requires="VK_KHR_get_physical_device_properties2" author="NV" contact="Jeff Bolz @jeffbolznv" supported="vulkan">
<require>
<enum value="0" name="VK_NV_EXTENSION_250_SPEC_VERSION"/>
<enum value="&quot;VK_NV_extension_250&quot;" name="VK_NV_EXTENSION_250_EXTENSION_NAME"/>
<enum value="1" name="VK_NV_COOPERATIVE_MATRIX_SPEC_VERSION"/>
<enum value="&quot;VK_NV_cooperative_matrix&quot;" name="VK_NV_COOPERATIVE_MATRIX_EXTENSION_NAME"/>
<enum offset="0" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_FEATURES_NV"/>
<enum offset="1" extends="VkStructureType" name="VK_STRUCTURE_TYPE_COOPERATIVE_MATRIX_PROPERTIES_NV"/>
<enum offset="2" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_PROPERTIES_NV"/>
<type name="VkCooperativeMatrixPropertiesNV"/>
<type name="VkScopeNV"/>
<type name="VkComponentTypeNV"/>
<type name="VkPhysicalDeviceCooperativeMatrixFeaturesNV"/>
<type name="VkPhysicalDeviceCooperativeMatrixPropertiesNV"/>
<command name="vkGetPhysicalDeviceCooperativeMatrixPropertiesNV"/>
</require>
</extension>
<extension name="VK_NV_extension_251" number="251" author="NV" contact="Kedarnath Thangudu @kthangudu" supported="disabled">