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 September 29, 2018 Vulkan 1.1.86 spec update: 

* Update release number to 86.

Internal Issues:

  * Add new <<resources-image-creation-limits, Image Creation Limits>>
    section and reference that from valid usage statements, reducing
    combinatorial complexity of extension-dependent VUs. Also fixes some
    underspecified limits (such as pname:maxMipLevels) in the VUs for
    slink:VkImageCreateInfo when
    slink:VkExternalMemoryImageCreateInfo::pname:externalMemoryHandles
    contains multiple bits, and fixes incorrectly (and underspecified)
    limits when an Android external format is used (internal issue 1370).
  * Remove unused "`Fragment Area Granularity`" glossary entry accidentally
    introduced in the 1.1.85 update.

New Extensions:

  * `VK_KHR_driver_properties`
  * `VK_KHR_shader_atomic_int64`
  * The specification sources contain text for another extension,
    `VK_EXT_image_drm_format_modifier`, but this extension is not yet
    complete, and is marked disabled in `vk.xml`. The extension will be
    enabled, and become part of the spec, only when the authors decide it is
    ready.
This commit is contained in:
Jon Leech 2018-09-29 03:23:41 -07:00
parent 9f2171b411
commit 7ea62a02a9
17 changed files with 1926 additions and 341 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
ChangeLog.txt
View File

@ -8,6 +8,35 @@ public pull requests that have been accepted.
-----------------------------------------------------
Change log for September 29, 2018 Vulkan 1.1.86 spec update:
* Update release number to 86.
Internal Issues:
* Add new <<resources-image-creation-limits, Image Creation Limits>>
section and reference that from valid usage statements, reducing
combinatorial complexity of extension-dependent VUs. Also fixes some
underspecified limits (such as pname:maxMipLevels) in the VUs for
slink:VkImageCreateInfo when
slink:VkExternalMemoryImageCreateInfo::pname:externalMemoryHandles
contains multiple bits, and fixes incorrectly (and underspecified)
limits when an Android external format is used (internal issue 1370).
* Remove unused "`Fragment Area Granularity`" glossary entry accidentally
introduced in the 1.1.85 update.
New Extensions:
* `VK_KHR_driver_properties`
* `VK_KHR_shader_atomic_int64`
* The specification sources contain text for another extension,
`VK_EXT_image_drm_format_modifier`, but this extension is not yet
complete, and is marked disabled in `vk.xml`. The extension will be
enabled, and become part of the spec, only when the authors decide it is
ready.
-----------------------------------------------------
Change log for September 19, 2018 Vulkan 1.1.85 spec update:
* Update release number to 85.

2
Makefile
View File

@ -107,7 +107,7 @@ VERBOSE =
# EXTRAATTRIBS sets additional attributes, if passed to make
# ADOCOPTS options for asciidoc->HTML5 output
NOTEOPTS = -a editing-notes -a implementation-guide
PATCHVERSION = 85
PATCHVERSION = 86
ifneq (,$(findstring VK_VERSION_1_1,$(VERSIONS)))
SPECREVISION = 1.1.$(PATCHVERSION)
else

435
appendices/VK_EXT_image_drm_format_modifier.txt Normal file
View File

@ -0,0 +1,435 @@
// Copyright (c) 2018 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
include::meta/VK_EXT_image_drm_format_modifier.txt[]
*Last Modified Date*::
2018-08-29
*IP Status*::
No known IP claims.
*Contributors*::
- Antoine Labour, Google
- Chad Versace, Google
- James Jones, NVIDIA
- Jason Ekstrand, Intel
- Jőrg Wagner, ARM
- Kristian Høgsberg Kristensen, Google
- Ray Smith, ARM
=== Overview
==== Summary
This extension provides the ability to use _DRM format modifiers_ with images,
enabling Vulkan to better integrate with the Linux ecosystem of graphics,
video, and display APIs.
Its functionality closely overlaps with
`EGL_EXT_image_dma_buf_import_modifiers`^<<VK_EXT_image_drm_format_modifier-fn2,2>>^
and
`EGL_MESA_image_dma_buf_export`^<<VK_EXT_image_drm_format_modifier-fn3,3>>^.
Unlike the EGL extensions, this extension does not require the use of
a specific handle type (such as a dma_buf) for external memory
and provides more explicit control of image creation.
==== Introduction to DRM Format Modifiers
A _DRM format modifier_ is a 64-bit, vendor-prefixed, semi-opaque unsigned integer.
Most _modifiers_ represent a concrete, vendor-specific tiling format for images.
Some exceptions are etext:DRM_FORMAT_MOD_LINEAR (which is not vendor-specific);
etext:DRM_FORMAT_MOD_NONE (which is an alias of etext:DRM_FORMAT_MOD_LINEAR due
to historical accident);
and etext:DRM_FORMAT_MOD_INVALID (which does not represent a tiling format).
The _modifier's_ vendor prefix consists of the 8 most signficant bits.
The canonical list of _modifiers_ and vendor prefixes is found in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_fourcc.h[`drm_fourcc.h`]
in the Linux kernel source.
The other dominant source of _modifiers_ are vendor kernel trees.
One goal of _modifiers_ in the Linux ecosystem
is to enumerate for each vendor a reasonably sized set of tiling formats that
are appropriate for images shared
across processes, APIs, and/or devices,
where each participating component may possibly be from different vendors.
A non-goal is to enumerate all tiling formats supported
by all vendors. Some tiling formats used internally by vendors are
inappropriate for sharing; no _modifiers_ should be assigned to such tiling
formats.
Modifier values typically do not _describe_ memory layouts.
More precisely, a _modifier_'s lower 56 bits usually have no structure.
Instead, modifiers _name_ memory layouts;
they name a small set of vendor-preferred layouts for image sharing.
As a consequence, in each vendor namespace the modifier values are often
sequentially allocated starting at 1.
Each _modifier_ is usually supported by a single vendor
and its name matches the pattern `{VENDOR}_FORMAT_MOD_*`
or `DRM_FORMAT_MOD_{VENDOR}_*`.
Examples are
etext:I915_FORMAT_MOD_X_TILED and
etext:DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED.
An exception is etext:DRM_FORMAT_MOD_LINEAR,
which is supported by most vendors.
Many APIs in Linux use _modifiers_ to negotiate and specify the
memory layout of shared images. For example, a Wayland compositor and Wayland
client may, by relaying _modifiers_ over the Wayland protocol
`zwp_linux_dmabuf_v1`, negotiate a vendor-specific tiling format for a shared
stext:wl_buffer. The client may allocate the underlying memory for the
stext:wl_buffer with GBM, providing the chosen _modifier_ to
fname:gbm_bo_create_with_modifiers. The client may then import the stext:wl_buffer
into Vulkan for producing image content, providing the resource's
dma_buf to slink:VkImportMemoryFdInfo and
its _modifier_ to slink:VkImageDrmFormatModifierExplicitCreateInfoEXT.
The compositor may then import the stext:wl_buffer into OpenGL for sampling,
providing the resource's dma_buf and _modifier_ to
fname:eglCreateImage.
The compositor may also bypass OpenGL and submit the stext:wl_buffer directly
to the kernel's display API, providing the dma_buf and _modifier_ through
stext:drm_mode_fb_cmd2.
==== Format Translation
_Modifier_-capable APIs often pair _modifiers_ with DRM formats,
which are defined in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_fourcc.h[`drm_fourcc.h`].
However, `VK_EXT_image_drm_format_modifier` uses elink:VkFormat instead of DRM formats.
The application must convert between elink:VkFormat and DRM format
when it sends or receives a DRM format to or from an external API.
The mapping from elink:VkFormat to DRM format is lossy.
Therefore, when receiving a DRM format from an external API,
often the application must use information from the external API
to accurately map the DRM format to a elink:VkFormat.
For example, DRM formats do not distinguish between RGB and sRGB
(as of 2018-03-28);
external information is required to identify the image's colorspace.
The mapping between elink:VkFormat and DRM format is also incomplete.
For some DRM formats there exist no corresponding Vulkan format,
and for some Vulkan formats there exist no corresponding DRM format.
==== Usage Patterns
Three primary usage patterns are intended for this extension:
* *Negotiation.*
The application negotiates with _modifier_-aware, external components to
determine sets of image creation parameters supported among all components.
+
--
In the Linux ecosystem, the negotiation usually assumes the image is a 2D,
single-sampled, non-mipmapped, non-array image; this extension permits that
assumption but does not require it. The result of the negotiation usually
resembles a set of tuples such as _(drmFormat, drmFormatModifier)_,
where each participating component supports all tuples in the set.
Many details of this negotiation—such as the protocol used during negotiation,
the set of image creation parameters expressable in the protocol, and how the
protocol chooses which process and which API will create the image—are outside
the scope of this specification.
In this extension, flink:vkGetPhysicalDeviceFormatProperties2 with
slink:VkDrmFormatModifierPropertiesListEXT serves a primary role during the
negotiation, and flink:vkGetPhysicalDeviceImageFormatProperties2 with
slink:VkPhysicalDeviceImageDrmFormatModifierInfoEXT serves a secondary role.
--
* *Import.*
The application imports an image with a _modifier_.
+
--
In this pattern, the application receives from an external source the
image's memory and its creation parameters, which are often the result of
the negotiation described above. Some image creation parameters are
implicitly defined by the external source; for example,
ename:VK_IMAGE_TYPE_2D is often assumed. Some image creation parameters are
usually explicit, such as the image's pname:format,
pname:drmFormatModifier, and pname:extent; and each plane's pname:offset
and pname:rowPitch.
Before creating the image, the application first verifies that the physical device
supports the received creation parameters by querying
flink:vkGetPhysicalDeviceFormatProperties2 with
slink:VkDrmFormatModifierPropertiesListEXT and
flink:vkGetPhysicalDeviceImageFormatProperties2 with
slink:VkPhysicalDeviceImageDrmFormatModifierInfoEXT. Then the application creates
the image by chaining slink:VkImageDrmFormatModifierExplicitCreateInfoEXT
and slink:VkExternalMemoryImageCreateInfo onto slink:VkImageCreateInfo.
--
* *Export.* The application creates an image and allocates its memory.
Then the application exports to _modifier_-aware consumers the image's
memory handles; its creation parameters; its _modifier_; and the
<<VkSubresourceLayout,pname:offset>>, <<VkSubresourceLayout,pname:size>>,
and <<VkSubresourceLayout,pname:rowPitch>> of each _memory plane_.
+
--
In this pattern, the Vulkan device is the authority for the image; it is
the allocator of the image's memory and the decider of the image's creation
parameters. When choosing the image's creation parameters, the application
usually chooses a tuple _(format, drmFormatModifier)_
from the result of the negotiation described above.
The negotiation's result often contains multiple tuples
that share the same format but differ in their _modifier_. In this case, the
application should defer the choice of the image's _modifier_ to the Vulkan
implementation by providing all such _modifiers_ to
slink:VkImageDrmFormatModifierListCreateInfoEXT::pname:pDrmFormatModifiers;
and the implementation should choose from pname:pDrmFormatModifiers the
optimal _modifier_ in consideration with the other image parameters.
The application creates the image by chaining
slink:VkImageDrmFormatModifierListCreateInfoEXT and
slink:VkExternalMemoryImageCreateInfo onto slink:VkImageCreateInfo. The
protocol and APIs by which the application will share the image with external
consumers will likely determine the value of
slink:VkExternalMemoryImageCreateInfo::pname:handleTypes. The
implementation chooses for the image an optimal _modifier_ from
slink:VkImageDrmFormatModifierListCreateInfoEXT::pname:pDrmFormatModifiers.
The application then queries the implementation-chosen _modifier_ with
flink:vkGetImageDrmFormatModifierPropertiesEXT, and queries the memory
layout of each plane with flink:vkGetImageSubresourceLayout.
The application then allocates the image's memory with slink:VkMemoryAllocateInfo,
adding chained extension structures for external memory; binds it to the
image; and exports the memory, for example, with flink:vkGetMemoryFd.
Finally, the application sends the image's creation parameters, its _modifier_,
its per-plane memory layout, and the exported memory handle to the
external consumers. The details of how the application transmits this
information to external consumers is outside the scope of this specification.
--
==== Prior Art
Extension
`EGL_EXT_image_dma_buf_import`^<<VK_EXT_image_drm_format_modifier-fn1,1>>^
introduced the ability to create an stext:EGLImage by importing for each plane
a dma_buf, offset, and row pitch.
Later, extension
`EGL_EXT_image_dma_buf_import_modifiers`^<<VK_EXT_image_drm_format_modifier-fn2,2>>^
introduced the ability to query which combination of formats and _modifiers_
the implementation supports and to specify _modifiers_ during creation of the
stext:EGLImage.
Extension
`EGL_MESA_image_dma_buf_export`^<<VK_EXT_image_drm_format_modifier-fn3,3>>^ is
the inverse of `EGL_EXT_image_dma_buf_import_modifiers`.
The Linux kernel modesetting API (KMS), when configuring the display's
framebuffer with `struct
drm_mode_fb_cmd2`^<<VK_EXT_image_drm_format_modifier-fn4,4>>^, allows one to
specify the frambuffer's _modifier_ as well as a per-plane memory handle,
offset, and row pitch.
GBM, a graphics buffer manager for Linux, allows creation of a `gbm_bo` (that
is, a graphics _buffer object_) by importing data similar to that in
`EGL_EXT_image_dma_buf_import_modifiers`^<<VK_EXT_image_drm_format_modifier-fn1,1>>^;
and symmetrically allows exporting the same data from the `gbm_bo`. See the
references to _modifier_ and _plane_ in
`gbm.h`^<<VK_EXT_image_drm_format_modifier-fn5,5>>^.
=== New Object Types
None.
=== New Enum Constants
* Extending elink:VkResult:
** ename:VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_LIST_EXT
** ename:VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_DRM_FORMAT_MODIFIER_INFO_EXT
** ename:VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_LIST_CREATE_INFO_EXT
** ename:VK_STRUCTURE_TYPE_IMAGE_EXPLICIT_DRM_FORMAT_MODIFIER_CREATE_INFO_EXT
** ename:VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT
* Extending elink:VkImageTiling:
** ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT
* Extending elink:VkImageAspectFlagBits:
** ename:VK_IMAGE_ASPECT_MEMORY_PLANE_0_BIT_EXT
** ename:VK_IMAGE_ASPECT_MEMORY_PLANE_1_BIT_EXT
** ename:VK_IMAGE_ASPECT_MEMORY_PLANE_2_BIT_EXT
** ename:VK_IMAGE_ASPECT_MEMORY_PLANE_3_BIT_EXT
=== New Enums
None.
=== New Structures
* Extends elink:VkFormatProperties2:
** slink:VkDrmFormatModifierPropertiesListEXT
* Member of slink:VkDrmFormatModifierPropertiesListEXT:
** slink:VkDrmFormatModifierPropertiesEXT
* Extends slink:VkPhysicalDeviceImageFormatInfo2:
** slink:VkPhysicalDeviceImageDrmFormatModifierInfoEXT
* Extends slink:VkImageCreateInfo:
** slink:VkImageDrmFormatModifierListCreateInfoEXT
** slink:VkImageDrmFormatModifierExplicitCreateInfoEXT
* Parameter to flink:vkGetImageDrmFormatModifierPropertiesEXT:
** slink:VkImageDrmFormatModifierPropertiesEXT
=== New Functions
* flink:vkGetImageDrmFormatModifierPropertiesEXT
=== Issues
1. Should this extension define a single DRM format modifier per
sname:VkImage? Or define one per plane?
+
--
*RESOLVED.*
There exists a single DRM format modifier per sname:VkImage.
*DISCUSSION.*
Prior art, such as
`EGL_EXT_image_dma_buf_import_modifiers`^<<VK_EXT_image_drm_format_modifier-fn2,2>>^,
`struct drm_mode_fb_cmd2`^<<VK_EXT_image_drm_format_modifier-fn4,4>>^, and
`struct gbm_import_fd_modifier_data`^<<VK_EXT_image_drm_format_modifier-fn5,5>>^,
allows defining one _modifier_ per plane.
However, developers of the GBM and kernel APIs concede it was a mistake. Beginning in
Linux 4.10, the kernel requires that the application provide the same DRM format
_modifier_ for each plane.
(See Linux commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bae781b259269590109e8a4a8227331362b88212[bae781b259269590109e8a4a8227331362b88212]).
And GBM provides an entrypoint, ftext:gbm_bo_get_modifier, for querying the
_modifier_ of the image but does not provide one to query the modifier of
individual planes.
--
2. When creating an image with slink:VkImageDrmFormatModifierExplicitCreateInfoEXT,
which is typically used when _importing_ an image,
should the application explicitly provide the size of each plane?
+
--
*RESOLVED.* No. The application must: not provide the size. To enforce this,
the API requires that
slink:VkImageDrmFormatModifierExplicitCreateInfoEXT::pname:pPlaneLayouts::<<VkSubresourceLayout,pname:size>>
must: be 0.
*DISCUSSION.*
Prior art, such as
`EGL_EXT_image_dma_buf_import_modifiers`^<<VK_EXT_image_drm_format_modifier-fn2,2>>^,
`struct drm_mode_fb_cmd2`^<<VK_EXT_image_drm_format_modifier-fn4,4>>^, and
`struct gbm_import_fd_modifier_data`^<<VK_EXT_image_drm_format_modifier-fn5,5>>^, omits
from the API the size of each plane. Instead, the APIs infer each plane's size
from the import parameters, which include the image's pixel format and
a dma_buf, offset, and row pitch for each plane.
However, Vulkan differs from EGL and GBM with regards to image
creation in the following ways:
.Differences in Image Creation
- *Undedicated allocation by default.*
When importing or exporting a set of dma_bufs as an stext:EGLImage or
stext:gbm_bo, common practice mandates that each dma_buf's memory be
dedicated (in the sense of `VK_KHR_dedicated_allocation`) to the image
(though not necessarily dedicated to a single plane). In particular,
neither the GBM documentation nor the EGL extension specifications explicitly
state this requirement, but in light of common practice this is likely due to
under-specification rather than intentional omission. In contrast,
`VK_EXT_image_drm_format_modifier` permits, but does not require, the
implementation to require dedicated allocations for images created with
ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT.
- *Separation of image creation and memory allocation.*
When importing a set of dma_bufs as an stext:EGLImage or stext:gbm_bo, EGL
and GBM create the image resource and bind it to memory (the dma_bufs)
simultaneously. This allows EGL and GBM to query each dma_buf's size during
image creation. In Vulkan, image creation and memory allocation are
independent unless a dedicated allocation is used (as in
`VK_KHR_dedicated_allocation`). Therefore, without requiring dedicated
allocation, Vulkan cannot query the size of each dma_buf (or other external
handle) when calculating the image's memory layout. Even if dedication
allocation were required, Vulkan cannot calculate the image's memory layout
until after the image is bound to its dma_ufs.
The above differences complicate the potential inference of plane size in
Vulkan. Consider the following problematic cases:
.Problematic Plane Size Calculations
- *Padding.* Some plane of the image may require implementation-dependent padding.
- *Metadata.* For some _modifiers_, the image may have a metadata plane which
requires a non-trivial calculation to determine its size.
- *Mipmapped, array, and 3D images.* The implementation may support
ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT for images whose
pname:mipLevels, pname:arrayLayers, or pname:depth is greater than 1. For
such images with certain _modifiers_, the calculation of each plane's size
may be non-trivial.
However, an application-provided plane size solves none of the above problems.
For simplicity, consider an external image with a single memory plane. The
implementation is obviously capable calculating the image's size when its
tiling is ename:VK_IMAGE_TILING_OPTIMAL. Likewise, any reasonable
implementation is capable of calculating the image's size when its tiling uses
a supported _modifier_.
Suppose that the external image's size is smaller than the
implementation-calculated size. If the application provided the external
image's size to slink:vkCreateImage, the implementation would observe the
mismatched size and recognize its inability to comprehend the external image's
layout (unless the implementation used the application-provided size to select
a refinement of the tiling layout indicated by the _modifier_, which is
strongly discouraged). The implementation would observe the conflict, and
reject image creation with
ename:VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT. On the other
hand, if the application did not provide the external image's size to
slink:vkCreateImage, then the application would observe after
calling flink:vkGetImageMemoryRequirements that the external image's size is
less than the size required by the implementation. The application would
observe the conflict and refuse to bind the sname:VkImage to the external
memory. In both cases, the result is explicit failure.
Suppose that the external image's size is larger than the
implementation-calculated size. If the application provided the external
image's size to slink:vkCreateImage, for reasons similar to above the
implementation would observe the mismatched size and recognize its inability to
comprehend the image data residing in the extra size. The implementation,
however, must assume that image data resides in the entire size provided by the
application. The implementation would observe the conflict and reject image
creation with ename:VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT. On
the other hand, if the application did not provide the external image's size to
flink:vkCreateImage, then the application would observe after calling
flink:vkGetImageMemoryRequirements that the external image's size is larger
than the implementation-usable size. The application would observe the
conflict and refuse to bind the sname:VkImage to the external memory. In both
cases, the result is explicit failure.
Therefore, an application-provided size provides no benefit, and this extension
should not require it. This decision renders
slink:VkSubresourceLayout::pname:size an unused field during image creation,
and thus introduces a risk that implementations may require applications to
submit sideband creation parameters in the unused field. To prevent
implementations from relying on sideband data, this extension _requires_ the
application to set pname:size to 0.
--
==== References
1. [[VK_EXT_image_drm_format_modifier-fn1]] https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt[EGL_EXT_image_dma_buf_import]
2. [[VK_EXT_image_drm_format_modifier-fn2]] https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt[EGL_EXT_image_dma_buf_import_modifiers]
3. [[VK_EXT_image_drm_format_modifier-fn3]] https://www.khronos.org/registry/EGL/extensions/MESA/EGL_MESA_image_dma_buf_export.txt[EGL_MESA_image_dma_buf_export]
4. [[VK_EXT_image_drm_format_modifier-fn4]] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_mode.h?id=refs/tags/v4.10#n392[struct drm_mode_fb_cmd2]
5. [[VK_EXT_image_drm_format_modifier-fn5]] https://cgit.freedesktop.org/mesa/mesa/tree/src/gbm/main/gbm.h?id=refs/tags/mesa-18.0.0-rc1[gbm.h]
==== Version History
* Revision 1.0, 2018-08-29 (Chad Versace)
- First stable revision

61
appendices/VK_KHR_driver_properties.txt Normal file
View File

@ -0,0 +1,61 @@
// Copyright (c) 2016-2018 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
include::meta/VK_KHR_driver_properties.txt[]
*Last Modified Date*::
2018-04-11
*IP Status*::
No known IP claims.
*Contributors*::
- Baldur Karlsson
- Matthaeus G. Chajdas, AMD
- Piers Daniell, NVIDIA
- Alexander Galazin, Arm
- Jesse Hall, Google
- Daniel Rakos, AMD
This extension provides a new physical device query which allows retrieving
information about the driver implementation, allowing applications to
determine which physical device corresponds to which particular vendor's
driver, and which conformance test suite version the driver implementation
is compliant with.
=== New Object Types
None.
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR
* ename:VK_MAX_DRIVER_NAME_SIZE_KHR
* ename:VK_MAX_DRIVER_INFO_SIZE_KHR
=== New Enums
None.
=== New Structures
* slink:VkConformanceVersionKHR
* slink:VkPhysicalDeviceDriverPropertiesKHR
=== New Functions
None.
=== Issues
None.
=== Examples
None.
=== Version History
* Revision 1, 2018-04-11 (Daniel Rakos)
- Internal revisions

44
appendices/VK_KHR_shader_atomic_int64.txt Normal file
View File

@ -0,0 +1,44 @@
// Copyright (c) 2014-2018 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
include::meta/VK_KHR_shader_atomic_int64.txt[]
*Last Modified Data*::
2018-07-05
*Interactions and External Dependencies*::
- This extension requires the
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_int64.txt[+GL_ARB_gpu_shader_int64+]
and
https://github.com/KhronosGroup/GLSL/tree/master/extensions/ext/GL_EXT_shader_atomic_int64.txt[+GL_EXT_shader_atomic_int64+]
extensions for GLSL source languages.
*Contributors*::
- Aaron Hagan, AMD
- Daniel Rakos, AMD
- Jeff Bolz, NVIDIA
- Neil Henning, Codeplay
This extension advertises the SPIR-V *Int64Atomics* capability for Vulkan,
which allows a shader to contain 64-bit atomic operations on signed and
unsigned integers.
The supported operations include OpAtomicMin, OpAtomicMax, OpAtomicAnd,
OpAtomicOr, OpAtomicXor, OpAtomicAdd, OpAtomicExchange, and
OpAtomicCompSwap.
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_INT64_FEATURES_KHR
=== New SPIR-V Capabilities
* <<spirvenv-capabilities-table-int64atomics, code:Int64Atomics>>
=== New Structures
* slink:VkPhysicalDeviceShaderAtomicInt64FeaturesKHR
=== Version History
* Revision 1, 2018-07-05 (Aaron Hagan)
- Internal revisions

47
appendices/glossary.txt
View File

@ -159,9 +159,12 @@ endif::VK_AMD_shader_fragment_mask[]
Color Renderable Format::
A elink:VkFormat where ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT is
set in the pname:optimalTilingFeatures or pname:linearTilingFeatures
member of slink:VkFormatProperties returned by
flink:vkGetPhysicalDeviceFormatProperties, depending on the tiling used.
set in one of the following, depending on the image's tiling:
* slink:VkImageFormatProperties::pname:linearTilingFeatures
* slink:VkImageFormatProperties::pname:optimalTilingFeatures
ifdef::VK_EXT_image_drm_format_modifier[]
* slink:VkDrmFormatPropertiesEXT::pname:drmFormatModifierTilingFeatures
endif::VK_EXT_image_drm_format_modifier[]
Color Sample Mask::
A bitfield associated with a fragment, with one bit for each sample in
@ -496,11 +499,6 @@ Fragment::
Fragment Area::
The width and height, in pixels, of a fragment.
[[glossary-fragment-area-granularity]]
Fragment Area Granularity::
The framebuffer granularity in x and y for which unique fragment areas
may: be specified.
Fragment Input Attachment Interface::
Variables with code:UniformConstant storage class and a decoration of
code:InputAttachmentIndex that are statically used by a fragment
@ -777,10 +775,35 @@ Invocation Group::
[[glossary-linear-resource]]
Linear Resource::
A resource is _linear_ if it is a slink:VkBuffer, or a slink:VkImage
created with ename:VK_IMAGE_TILING_LINEAR.
A resource is _non-linear_ if it is a slink:VkImage created with
ename:VK_IMAGE_TILING_OPTIMAL.
A resource is _linear_ if it is one of the following:
* a slink:VkBuffer
* a slink:VkImage created with ename:VK_IMAGE_TILING_LINEAR
ifdef::VK_EXT_image_drm_format_modifier[]
* a slink:VkImage created with ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT
and whose <<glossary-drm-format-modifier,Linux DRM format modifier>>
is ename:DRM_FORMAT_MOD_LINEAR
endif::VK_EXT_image_drm_format_modifier[]
+
A resource is _non-linear_ if it is one of the following:
* a slink:VkImage created with ename:VK_IMAGE_TILING_OPTIMAL
ifdef::VK_EXT_image_drm_format_modifier[]
* a slink:VkImage created with ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT
and whose <<glossary-drm-format-modifier,Linux DRM format modifier>>
is not ename:DRM_FORMAT_MOD_LINEAR
endif::VK_EXT_image_drm_format_modifier[]
ifdef::VK_EXT_image_drm_format_modifier[]
[[glossary-drm-format-modifier,Linux DRM format modifier]]
Linux DRM Format Modifier::
A 64-bit, vendor-prefixed, semi-opaque unsigned integer that describes
vendor-specific details of an image's memory layout. In Linux graphics APIs,
_modifiers_ are
commonly used to specify the memory layout of externally shared images.
An image has a _modifier_ if and only if it is created with pname:tiling
equal to ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT.
For more details, refer to the appendix for extension
<<VK_EXT_image_drm_format_modifier>>.
endif::VK_EXT_image_drm_format_modifier[]
Local Workgroup::
A collection of compute shader invocations invoked by a single dispatch

22
appendices/spirvenv.txt
View File

@ -60,6 +60,10 @@ with that capability.
| code:Tessellation | <<features-features-tessellationShader,tessellationShader>>
| code:Float64 | <<features-features-shaderFloat64,shaderFloat64>>
| code:Int64 | <<features-features-shaderInt64,shaderInt64>>
ifdef::VK_KHR_shader_atomic_int64[]
[[spirvenv-capabilities-table-int64atomics]]
| code:Int64Atomics | <<VK_KHR_shader_atomic_int64,VK_KHR_shader_atomic_int64>>
endif::VK_KHR_shader_atomic_int64[]
| code:Int16 | <<features-features-shaderInt16,shaderInt16>>
| code:TessellationPointSize | <<features-features-shaderTessellationAndGeometryPointSize,shaderTessellationAndGeometryPointSize>>
| code:GeometryPointSize | <<features-features-shaderTessellationAndGeometryPointSize,shaderTessellationAndGeometryPointSize>>
@ -600,8 +604,20 @@ ifdef::VK_VERSION_1_1[]
** *InclusiveScan*
** *ExclusiveScan*
endif::VK_VERSION_1_1[]
* Atomic instructions must: declare a scalar 32-bit integer type for the
_Result Type_ and the type of the value pointed to by _Pointer_.
* Atomic instructions must: declare a scalar 32-bit integer type,
ifdef::VK_KHR_shader_atomic_int64[]
or a scalar 64-bit integer type if the code:Int64Atomics capability is
enabled,
endif::VK_KHR_shader_atomic_int64[]
for the _Result Type_ and the type of the value pointed to by _Pointer_.
ifdef::VK_KHR_shader_atomic_int64[]
** <<features-features-shaderBufferInt64Atomics,shaderBufferInt64Atomics>>
must: be enabled for 64-bit integer atomic operations to be supported
on buffers.
** <<features-features-shaderSharedInt64Atomics,shaderSharedInt64Atomics>>
must: be enabled for 64-bit integer atomic operations to be supported
on shared variables.
endif::VK_KHR_shader_atomic_int64[]
ifdef::VK_EXT_descriptor_indexing[]
* If an instruction loads from or stores to a resource (including atomics
and image instructions) and the resource descriptor being accessed is
@ -679,7 +695,7 @@ any result, otherwise let the largest permitted value in any of the ranges
be [eq]#F~max~# and the smallest be [eq]#F~min~#.
The operation must return a value in the range [eq]#[x - E, x + E]# where
latexmath:[E = \mathrm{max} \left( | x - F_{\mathrm{min}} |, | x -
F_{\mathrm{max}} | \right) ]
F_{\mathrm{max}} | \right) ].
For single precision (32 bit) instructions, precisions are required: to be
at least as follows, unless decorated with RelaxedPrecision:

16
chapters/VK_NVX_raytracing/raytracing.txt
View File

@ -316,7 +316,7 @@ performance.
Before copying, an application must: query the size of the resulting
acceleration structure.
[open,refpage='vkCmdWriteAccelerationStructurePropertiesNVX',desc='Copy an acceleration structure',type='protos']
[open,refpage='vkCmdWriteAccelerationStructurePropertiesNVX',desc='Write acceleration structure result parameters to query results.',type='protos']
--
To query acceleration structure size parameters call:
@ -376,8 +376,16 @@ specifying additional operations to perform during the copy, are:
include::../../api/enums/VkCopyAccelerationStructureModeNVX.txt[]
// Needs to be filled in
// * ename:VK_COPY_ACCELERATION_STRUCTURE_MODE_CLONE_NVX specifies ...
// * ename:VK_COPY_ACCELERATION_STRUCTURE_MODE_COMPACT_NVX specifies ...
* ename:VK_COPY_ACCELERATION_STRUCTURE_MODE_CLONE_NVX creates a direct
copy of the acceleration structure specified in pname:src into the one
specified by pname:dst.
The pname:dst acceleration structure must: have been created with the
same parameters as pname:src.
* ename:VK_COPY_ACCELERATION_STRUCTURE_MODE_COMPACT_NVX creates a more
compact version of an acceleration structure pname:src into pname:dst.
The acceleration structure pname:dst must: have been created with a
pname:compactedSize corresponding to the one returned by
slink:vkCmdWriteAccelerationStructurePropertiesNVX after the build of
the acceleration structure specified by pname:src.
--

5
chapters/clears.txt
View File

@ -324,6 +324,11 @@ described for flink:vkCreateRenderPass.
ename:VK_IMAGE_ASPECT_STENCIL_BIT
* [[VUID-VkClearAttachment-aspectMask-00020]]
pname:aspectMask must: not include ename:VK_IMAGE_ASPECT_METADATA_BIT
ifdef::VK_EXT_image_drm_format_modifier[]
* [[VUID-VkClearAttachment-aspectMask-02246]]
pname:aspectMask must: not include
etext:VK_IMAGE_ASPECT_MEMORY_PLANE___i___BIT_EXT for any index __i__.
endif::VK_EXT_image_drm_format_modifier[]
* [[VUID-VkClearAttachment-clearValue-00021]]
pname:clearValue must: be a valid sname:VkClearValue union
ifdef::VK_VERSION_1_1[]

5
chapters/copies.txt
View File

@ -801,6 +801,11 @@ include::../api/structs/VkImageSubresourceLayers.txt[]
ename:VK_IMAGE_ASPECT_STENCIL_BIT
* [[VUID-VkImageSubresourceLayers-aspectMask-00168]]
pname:aspectMask must: not contain ename:VK_IMAGE_ASPECT_METADATA_BIT
ifdef::VK_EXT_image_drm_format_modifier[]
* [[VUID-VkImageSubresourceLayers-aspectMask-02247]]
pname:aspectMask must: not include
etext:VK_IMAGE_ASPECT_MEMORY_PLANE___i___BIT_EXT for any index __i__.
endif::VK_EXT_image_drm_format_modifier[]
* [[VUID-VkImageSubresourceLayers-layerCount-01700]]
pname:layerCount must: be greater than 0
****

72
chapters/devsandqueues.txt
View File

@ -392,6 +392,78 @@ include::../validity/structs/VkPhysicalDeviceIDProperties.txt[]
endif::VK_VERSION_1_1,VK_KHR_external_memory_capabilities,VK_KHR_external_semaphore_capabilities,VK_KHR_external_fence_capabilities[]
ifdef::VK_KHR_driver_properties[]
[open,refpage='VkPhysicalDeviceDriverPropertiesKHR',desc='Structure containing driver identification information',type='structs']
--
To query the properties of the driver corresponding to a physical device,
add slink:VkPhysicalDeviceDriverPropertiesKHR to the pname:pNext chain of
the slink:VkPhysicalDeviceProperties2 structure.
The sname:VkPhysicalDeviceDriverPropertiesKHR structure is defined as:
include::../api/structs/VkPhysicalDeviceDriverPropertiesKHR.txt[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension specific structure.
* pname:driverID is a unique identifier for the driver of the physical
device.
* pname:driverName is a null-terminated UTF-8 string containing the name
of the driver.
* pname:driverInfo is a null-terminated UTF-8 string containing additional
information about the driver.
* pname:conformanceVersion is the version of the Vulkan conformance test
this driver is conformant against (see slink:VkConformanceVersionKHR).
pname:driverID must: be immutable for a given driver across instances,
processes, driver versions, and system reboots.
include::../validity/structs/VkPhysicalDeviceDriverPropertiesKHR.txt[]
--
[open,refpage='VkDriverIdKHR',desc='Khronos driver IDs',type='enums']
--
Khronos driver IDs which may: be returned in
slink:VkPhysicalDeviceDriverPropertiesKHR::pname:driverID are:
include::../api/enums/VkDriverIdKHR.txt[]
[NOTE]
.Note
====
Khronos driver IDs may be allocated by vendors at any time.
There may be multiple driver IDs for the same vendor, representing different
drivers (for e.g. different platforms, proprietary or open source, etc.).
Only the latest canonical versions of this Specification, of the
corresponding `vk.xml` API Registry, and of the corresponding
`vulkan_core.h` header file must: contain all reserved Khronos driver IDs.
Only driver IDs registered with Khronos are given symbolic names.
There may: be unregistered driver IDs returned.
====
--
[open,refpage='VkConformanceVersionKHR',desc='Structure containing the conformance test suite version the implementation is compliant with',type='structs']
--
The conformance test suite version an implementation is compliant with is
described with an instance of the sname:VkConformanceVersionKHR structure.
The sname:VkConformanceVersionKHR structure is defined as:
include::../api/structs/VkConformanceVersionKHR.txt[]
* pname:major is the major version number of the conformance test suite.
* pname:minor is the minor version number of the conformance test suite.
* pname:subminor is the subminor version number of the conformance test
suite.
* pname:patch is the patch version number of the conformance test suite.
include::../validity/structs/VkConformanceVersionKHR.txt[]
--
endif::VK_KHR_driver_properties[]
endif::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[]
[open,refpage='vkGetPhysicalDeviceQueueFamilyProperties',desc='Reports properties of the queues of the specified physical device',type='protos']

254
chapters/features.txt
View File

@ -877,6 +877,36 @@ include::../validity/structs/VkPhysicalDeviceMultiviewFeatures.txt[]
endif::VK_VERSION_1_1,VK_KHR_multiview[]
ifdef::VK_KHR_shader_atomic_int64[]
[open,refpage='VkPhysicalDeviceShaderAtomicInt64FeaturesKHR',desc='Structure describing features supported by VK_KHR_shader_atomic_int64',type='structs']
--
To query 64-bit atomic support for signed and unsigned integers call
flink:vkGetPhysicalDeviceFeatures2 with a
sname:VkPhysicalDeviceShaderAtomicInt64FeaturesKHR structure included in the
pname:pNext chain of its pname:pFeatures parameter.
The slink:VkPhysicalDeviceShaderAtomicInt64FeaturesKHR structure is defined
as:
include::../api/structs/VkPhysicalDeviceShaderAtomicInt64FeaturesKHR.txt[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[features-features-shaderBufferInt64Atomics]]
pname:shaderBufferInt64Atomics indicates whether shaders can: support
64-bit unsigned and signed integer atomic operations on buffers.
* [[features-features-shaderSharedInt64Atomics]]
pname:shaderSharedInt64Atomics indicates whether shaders can: support
64-bit unsigned and signed integer atomic operations on shared memory.
include::../validity/structs/VkPhysicalDeviceShaderAtomicInt64FeaturesKHR.txt[]
--
endif::VK_KHR_shader_atomic_int64[]
ifdef::VK_KHR_8bit_storage[]
[open,refpage='VkPhysicalDevice8BitStorageFeaturesKHR',desc='Structure describing features supported by VK_KHR_8bit_storage',type='structs']
--
@ -6018,14 +6048,24 @@ include::../validity/structs/VkFormatProperties.txt[]
--
Bits which can: be set in the slink:VkFormatProperties features
pname:linearTilingFeatures, pname:optimalTilingFeatures, and
pname:bufferFeatures are:
pname:linearTilingFeatures, pname:optimalTilingFeatures,
ifdef::VK_EXT_image_drm_format_modifier[]
<<VkDrmFormatModifierPropertiesEXT,pname:drmFormatModifierTilingFeatures>>,
endif::VK_EXT_image_drm_format_modifier[]
and pname:bufferFeatures are:
include::../api/enums/VkFormatFeatureFlagBits.txt[]
The following bits may: be set in pname:linearTilingFeatures and
pname:optimalTilingFeatures, specifying that the features are supported by
<<VkImage,images>> or <<VkImageView,image views>> created with the queried
The following bits may: be set in
ifndef::VK_EXT_image_drm_format_modifier[]
pname:linearTilingFeatures and pname:optimalTilingFeatures,
endif::VK_EXT_image_drm_format_modifier[]
ifdef::VK_EXT_image_drm_format_modifier[]
pname:linearTilingFeatures, pname:optimalTilingFeatures, and
<<VkDrmFormatModifierPropertiesEXT,pname:drmFormatModifierTilingFeatures>>,
endif::VK_EXT_image_drm_format_modifier[]
specifying that the features are supported by <<VkImage,images>> or
<<VkImageView,image views>> created with the queried
flink:vkGetPhysicalDeviceFormatProperties::pname:format:
* ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT specifies that an image view
@ -6223,8 +6263,135 @@ endif::VK_KHR_get_physical_device_properties2[]
include::../validity/structs/VkFormatProperties2.txt[]
--
endif::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[]
ifdef::VK_EXT_image_drm_format_modifier[]
[open,refpage='VkDrmFormatModifierPropertiesListEXT',desc='Structure specifying the list of DRM format modifiers supported for a format',type='structs']
--
To obtain the list of <<glossary-drm-format-modifier,Linux DRM format
modifiers>> compatible with a elink:VkFormat, add
slink:VkDrmFormatModifierPropertiesListEXT to the pname:pNext chain of
slink:VkFormatProperties2.
The slink:VkDrmFormatModifierPropertiesListEXT structure is defined as:
include::../api/structs/VkDrmFormatModifierPropertiesListEXT.txt[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:drmFormatModifierCount is an inout parameter related to the number
of modifiers compatible with the pname:format, as descibed below.
* pname:pDrmFormatModifierProperties is either `NULL` or an array of
slink:VkDrmFormatModifierPropertiesEXT structures.
If pname:pDrmFormatModifierProperties is `NULL`, then the function returns
in pname:drmFormatModifierCount the number of modifiers compatible with the
queried pname:format.
Otherwise, the application must: set pname:drmFormatModifierCount to the
length of the array pname:pDrmFormatModifierProperties; the function will
write at most pname:drmFormatModifierCount elements to the array, and will
return in pname:drmFormatModifierCount the number of elements written.
Among the elements in array pname:pDrmFormatModifierProperties, each
returned pname:drmFormatModifier must: be unique.
include::../validity/structs/VkDrmFormatModifierPropertiesListEXT.txt[]
--
[open,refpage='VkDrmFormatModifierPropertiesEXT',desc='Structure specifying properties of a format when combined with a DRM format modifier',type='structs']
--
The slink:VkDrmFormatModifierPropertiesEXT structure describes properties of
a elink:VkFormat when that format is combined with a
<<glossary-drm-format-modifier,Linux DRM format modifier>>.
These properties, like those of slink:VkFormatProperties2, are independent
of any particular image.
The slink:VkDrmFormatModifierPropertiesEXT structure is defined as:
include::../api/structs/VkDrmFormatModifierPropertiesEXT.txt[]
* pname:drmFormatModifier is a _Linux DRM format modifier_.
* pname:drmFormatModifierPlaneCount is the number of _memory planes_ in
any image created with pname:format and pname:drmFormatModifier.
An image's _memory planecount_ is distinct from its _format planecount_,
as explained below.
* pname:drmFormatModifierTilingFeatures is a bitmask of
elink:VkFormatFeatureFlagBits that are supported by any image created
with pname:format and pname:drmFormatModifier.
The returned pname:drmFormatModifierTilingFeatures must: contain at least
one bit.
The implementation must: not return etext:DRM_FORMAT_MOD_INVALID in
pname:drmFormatModifier.
An image's _memory planecount_ (as returned by
pname:drmFormatModifierPlaneCount) is distinct from its _format planecount_
(in the sense of
<<features-formats-requiring-sampler-ycbcr-conversion,multi-planar>>
Y'C~B~C~R~ formats).
In elink:VkImageAspectFlags, each
etext:VK_IMAGE_ASPECT_MEMORY_PLANE___i___BIT_EXT represents a _memory plane_
and each etext:VK_IMAGE_ASPECT_PLANE___i___BIT a _format plane_.
An image's set of _format planes_ is an ordered partition of the image's
*content* into separable groups of format channels.
The ordered partition is encoded in the name of each elink:VkFormat.
For example, ename:VK_FORMAT_G8_B8R8_2PLANE_420_UNORM contains two _format
planes_; the first plane contains the green channel and the second plane
contains the blue channel and red channel.
If the format name does not contain `PLANE`, then the format contains a
single plane; for example, ename:VK_FORMAT_R8G8B8A8_UNORM.
Some commands, such as flink:vkCmdBufferToImage, do not operate on all
format channels in the image, but instead operate only on the _format
planes_ explicitly chosen by the application and operate on each _format
plane_ independently.
An image's set of _memory planes_ is an ordered partition of the image's
*memory* rather than the image's *content*.
Each _memory plane_ is a contiguous range of memory.
The union of an image's _memory planes_ is not necessarily contiguous.
If an image is <<glossary-linear-resource,linear>>, then the partition is
the same for _memory planes_ and for _format planes_.
Therefore, if the returned pname:drmFormatModifier is
ename:DRM_FORMAT_MOD_LINEAR, then pname:drmFormatModifierPlaneCount must:
equal the _format planecount_, and pname:drmFormatModifierTilingFeatures
must: be identical to the
slink:VkFormatProperties2::pname:linearTilingFeatures returned in the same
pname:pNext chain.
If an image is <<glossary-linear-resource,non-linear>>, then the partition
of the image's *memory* into _memory planes_ is implementation-specific and
may: be unrelated to the partition of the image's *content* into _format
planes_.
For example, consider an image whose pname:format is
ename:VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM, pname:tiling is
ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT, whose pname:drmFormatModifier
is not ename:DRM_FORMAT_MOD_LINEAR, and pname:flags lacks
ename:VK_IMAGE_CREATE_DISJOINT_BIT.
The image has 3 _format planes_, and commands such
flink:vkCmdCopyBufferToImage act on each _format plane_ independently as if
the data of each _format plane_ were separable from the data of the other
planes.
In a straightforward implementation, the implementation may: store the
image's content in 3 adjacent _memory planes_ where each _memory plane_
corresponds exactly to a _format plane_.
However, the implementation may: also store the image's content in a single
_memory plane_ where all format channels are combined using an
implementation-private block-compressed format; or the implementation may:
store the image's content in a collection of 7 adjacent _memory planes_
using an implementation-private sharding technique.
Because the image is non-linear and non-disjoint, the implementation has
much freedom when choosing the image's placement in memory.
The _memory planecount_ applies to function parameters and structures only
when the API specifies an explicit requirement on
pname:drmFormatModifierPlaneCount.
In all other cases, the _memory planecount_ is ignored.
include::../validity/structs/VkDrmFormatModifierPropertiesEXT.txt[]
--
endif::VK_EXT_image_drm_format_modifier[]
endif::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[]
[[features-required-format-support]]
=== Required Format Support
@ -6901,6 +7068,15 @@ then the limitations for code:usage1 and code:flags1 must: be no more strict
than the limitations for code:usage2 and code:flags2, for all values of
pname:format, pname:type, and pname:tiling.
ifdef::VK_EXT_image_drm_format_modifier[]
.Valid Usage
****
* [[VUID-vkGetPhysicalDeviceImageFormatProperties-tiling-02248]]
pname:tiling must: not be ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT.
(Use flink:vkGetPhysicalDeviceImageFormatProperties2 instead).
****
endif::VK_EXT_image_drm_format_modifier[]
include::../validity/protos/vkGetPhysicalDeviceImageFormatProperties.txt[]
--
@ -6922,6 +7098,10 @@ include::../api/structs/VkImageFormatProperties.txt[]
instead be `1`:
** fname:vkGetPhysicalDeviceImageFormatProperties::pname:tiling was
ename:VK_IMAGE_TILING_LINEAR
ifdef::VK_EXT_image_drm_format_modifier[]
** slink:VkPhysicalDeviceImageFormatInfo2::pname:tiling was
ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT
endif::VK_EXT_image_drm_format_modifier[]
ifdef::VK_VERSION_1_1,VK_KHR_external_memory_capabilities[]
** the slink:VkPhysicalDeviceImageFormatInfo2::pname:pNext chain
included an instance of slink:VkPhysicalDeviceExternalImageFormatInfo
@ -6929,11 +7109,20 @@ ifdef::VK_VERSION_1_1,VK_KHR_external_memory_capabilities[]
mipmap image support is not required
endif::VK_VERSION_1_1,VK_KHR_external_memory_capabilities[]
* pname:maxArrayLayers is the maximum number of array layers.
pname:maxArrayLayers must: either be equal to 1 or be greater than or
equal to the pname:maxImageArrayLayers member of
slink:VkPhysicalDeviceLimits.
A value of 1 is valid only if pname:tiling is
ename:VK_IMAGE_TILING_LINEAR or if pname:type is ename:VK_IMAGE_TYPE_3D.
* If pname:tiling is ename:VK_IMAGE_TILING_LINEAR, then
pname:maxArrayLayers must: either be equal to 1 or be no less than
slink:VkPhysicalDeviceLimits::pname:maxImageArrayLayers.
* If pname:tiling is ename:VK_IMAGE_TILING_OPTIMAL and pname:type is
ename:VK_IMAGE_TYPE_3D, then pname:maxArrayLayers must: either be equal
to 1 or be no less than
slink:VkPhysicalDeviceLimits::pname:maxImageArrayLayers.
* If pname:tiling is ename:VK_IMAGE_TILING_OPTIMAL and pname:type is not
ename:VK_IMAGE_TYPE_3D, then pname:maxArrayLayers must: be no less than
slink:VkPhysicalDeviceLimits::pname:maxImageArrayLayers.
ifdef::VK_EXT_image_drm_format_modifier[]
* If pname:tiling is ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT, then
pname:maxArrayLayers must: not be 0.
endif::VK_EXT_image_drm_format_modifier[]
* pname:sampleCounts is a bitmask of elink:VkSampleCountFlagBits
specifying all the supported sample counts for this image as described
<<features-supported-sample-counts, below>>.
@ -7059,6 +7248,16 @@ The members of sname:VkPhysicalDeviceImageFormatInfo2 correspond to the
arguments to flink:vkGetPhysicalDeviceImageFormatProperties, with
pname:sType and pname:pNext added for extensibility.
ifdef::VK_EXT_image_drm_format_modifier[]
.Valid Usage
****
* [[VUID-VkPhysicalDeviceImageFormatInfo2KHR-tiling-02249]]
pname:tiling must: be ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT if
and only if the pname:pNext chain contains
slink:VkPhysicalDeviceImageDrmFormatModifierInfoEXT.
****
endif::VK_EXT_image_drm_format_modifier[]
include::../validity/structs/VkPhysicalDeviceImageFormatInfo2.txt[]
--
@ -7444,6 +7643,39 @@ zero or more slink:VkExternalMemoryFeatureFlagBits.
endif::VK_VERSION_1_1,VK_KHR_external_memory_capabilities[]
ifdef::VK_EXT_image_drm_format_modifier[]
[open,refpage='VkPhysicalDeviceImageDrmFormatModifierInfoEXT',desc='Structure specifying a DRM format modifier as image creation parameter',type='structs']
--
To query the image capabilities that are compatible with a
<<glossary-drm-format-modifier,Linux DRM format modifier>>, set
slink:VkPhysicalDeviceImageFormatInfo2::pname:tiling to
ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT and add
slink:VkPhysicalDeviceImageDrmFormatModifierInfoEXT to the pname:pNext chain
of slink:VkPhysicalDeviceImageFormatInfo2.
The slink:VkPhysicalDeviceImageDrmFormatModifierInfoEXT structure is defined
as:
include::../api/structs/VkPhysicalDeviceImageDrmFormatModifierInfoEXT.txt[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:drmFormatModifier is the image's _Linux DRM format modifier_,
corresponding to
slink:VkImageDrmFormatModifierExplicitCreateInfoEXT::pname:modifier or
to slink:VkImageDrmFormatModifierListCreateInfoEXT::pname:pModifiers.
If the pname:drmFormatModifier is incompatible with the parameters specified
in slink:VkPhysicalDeviceImageFormatInfo2 and its pname:pNext chain, then
flink:vkGetPhysicalDeviceImageFormatProperties2 returns
ename:VK_ERROR_FORMAT_NOT_SUPPORTED.
The implementation must: support the query of any pname:drmFormatModifier,
including unknown and invalid modifier values.
include::../validity/structs/VkPhysicalDeviceImageDrmFormatModifierInfoEXT.txt[]
--
endif::VK_EXT_image_drm_format_modifier[]
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
[open,refpage='VkSamplerYcbcrConversionImageFormatProperties',desc='Structure specifying combined image sampler descriptor count for multi-planar images',type='structs']

5
chapters/renderpass.txt
View File

@ -583,6 +583,11 @@ endif::VK_KHR_maintenance2[]
****
* [[VUID-VkInputAttachmentAspectReference-aspectMask-01964]]
pname:aspectMask must: not include ename:VK_IMAGE_ASPECT_METADATA_BIT
ifdef::VK_EXT_image_drm_format_modifier[]
* [[VUID-VkInputAttachmentAspectReferenceKHR-aspectMask-02250]]
pname:aspectMask must: not include
etext:VK_IMAGE_ASPECT_MEMORY_PLANE___i___BIT_EXT for any index __i__.
endif::VK_EXT_image_drm_format_modifier[]
****
include::../validity/structs/VkInputAttachmentAspectReference.txt[]

953
chapters/resources.txt
View File

File diff suppressed because it is too large Load Diff

74
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 85
#define VK_HEADER_VERSION 86
#define VK_NULL_HANDLE 0
@ -427,10 +427,12 @@ typedef enum VkStructureType {
VK_STRUCTURE_TYPE_IMPORT_MEMORY_HOST_POINTER_INFO_EXT = 1000178000,
VK_STRUCTURE_TYPE_MEMORY_HOST_POINTER_PROPERTIES_EXT = 1000178001,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_MEMORY_HOST_PROPERTIES_EXT = 1000178002,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_INT64_FEATURES_KHR = 1000180000,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_AMD = 1000185000,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT = 1000190000,
VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_EXT = 1000190001,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT = 1000190002,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR = 1000196000,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_SHADER_DERIVATIVES_FEATURES_NV = 1000201000,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_FEATURES_NV = 1000202000,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_PROPERTIES_NV = 1000202001,
@ -6044,6 +6046,60 @@ typedef struct VkPhysicalDevice8BitStorageFeaturesKHR {
#define VK_KHR_shader_atomic_int64 1
#define VK_KHR_SHADER_ATOMIC_INT64_SPEC_VERSION 1
#define VK_KHR_SHADER_ATOMIC_INT64_EXTENSION_NAME "VK_KHR_shader_atomic_int64"
typedef struct VkPhysicalDeviceShaderAtomicInt64FeaturesKHR {
VkStructureType sType;
void* pNext;
VkBool32 shaderBufferInt64Atomics;
VkBool32 shaderSharedInt64Atomics;
} VkPhysicalDeviceShaderAtomicInt64FeaturesKHR;
#define VK_KHR_driver_properties 1
#define VK_MAX_DRIVER_NAME_SIZE_KHR 256
#define VK_MAX_DRIVER_INFO_SIZE_KHR 256
#define VK_KHR_DRIVER_PROPERTIES_SPEC_VERSION 1
#define VK_KHR_DRIVER_PROPERTIES_EXTENSION_NAME "VK_KHR_driver_properties"
typedef enum VkDriverIdKHR {
VK_DRIVER_ID_AMD_PROPRIETARY_KHR = 1,
VK_DRIVER_ID_AMD_OPEN_SOURCE_KHR = 2,
VK_DRIVER_ID_MESA_RADV_KHR = 3,
VK_DRIVER_ID_NVIDIA_PROPRIETARY_KHR = 4,
VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS_KHR = 5,
VK_DRIVER_ID_INTEL_OPEN_SOURCE_MESA_KHR = 6,
VK_DRIVER_ID_IMAGINATION_PROPRIETARY_KHR = 7,
VK_DRIVER_ID_QUALCOMM_PROPRIETARY_KHR = 8,
VK_DRIVER_ID_ARM_PROPRIETARY_KHR = 9,
VK_DRIVER_ID_BEGIN_RANGE_KHR = VK_DRIVER_ID_AMD_PROPRIETARY_KHR,
VK_DRIVER_ID_END_RANGE_KHR = VK_DRIVER_ID_ARM_PROPRIETARY_KHR,
VK_DRIVER_ID_RANGE_SIZE_KHR = (VK_DRIVER_ID_ARM_PROPRIETARY_KHR - VK_DRIVER_ID_AMD_PROPRIETARY_KHR + 1),
VK_DRIVER_ID_MAX_ENUM_KHR = 0x7FFFFFFF
} VkDriverIdKHR;
typedef struct VkConformanceVersionKHR {
uint8_t major;
uint8_t minor;
uint8_t subminor;
uint8_t patch;
} VkConformanceVersionKHR;
typedef struct VkPhysicalDeviceDriverPropertiesKHR {
VkStructureType sType;
void* pNext;
uint32_t driverID;
char driverName[VK_MAX_DRIVER_NAME_SIZE_KHR];
char driverInfo[VK_MAX_DRIVER_INFO_SIZE_KHR];
VkConformanceVersionKHR conformanceVersion;
} VkPhysicalDeviceDriverPropertiesKHR;
#define VK_KHR_vulkan_memory_model 1
#define VK_KHR_VULKAN_MEMORY_MODEL_SPEC_VERSION 2
#define VK_KHR_VULKAN_MEMORY_MODEL_EXTENSION_NAME "VK_KHR_vulkan_memory_model"
@ -8044,13 +8100,13 @@ typedef void (VKAPI_PTR *PFN_vkDestroyAccelerationStructureNVX)(VkDevice device,
typedef void (VKAPI_PTR *PFN_vkGetAccelerationStructureMemoryRequirementsNVX)(VkDevice device, const VkAccelerationStructureMemoryRequirementsInfoNVX* pInfo, VkMemoryRequirements2KHR* pMemoryRequirements);
typedef void (VKAPI_PTR *PFN_vkGetAccelerationStructureScratchMemoryRequirementsNVX)(VkDevice device, const VkAccelerationStructureMemoryRequirementsInfoNVX* pInfo, VkMemoryRequirements2KHR* pMemoryRequirements);
typedef VkResult (VKAPI_PTR *PFN_vkBindAccelerationStructureMemoryNVX)(VkDevice device, uint32_t bindInfoCount, const VkBindAccelerationStructureMemoryInfoNVX* pBindInfos);
typedef void (VKAPI_PTR *PFN_vkCmdBuildAccelerationStructureNVX)(VkCommandBuffer cmdBuf, VkAccelerationStructureTypeNVX type, uint32_t instanceCount, VkBuffer instanceData, VkDeviceSize instanceOffset, uint32_t geometryCount, const VkGeometryNVX* pGeometries, VkBuildAccelerationStructureFlagsNVX flags, VkBool32 update, VkAccelerationStructureNVX dst, VkAccelerationStructureNVX src, VkBuffer scratch, VkDeviceSize scratchOffset);
typedef void (VKAPI_PTR *PFN_vkCmdCopyAccelerationStructureNVX)(VkCommandBuffer cmdBuf, VkAccelerationStructureNVX dst, VkAccelerationStructureNVX src, VkCopyAccelerationStructureModeNVX mode);
typedef void (VKAPI_PTR *PFN_vkCmdTraceRaysNVX)(VkCommandBuffer cmdBuf, VkBuffer raygenShaderBindingTableBuffer, VkDeviceSize raygenShaderBindingOffset, VkBuffer missShaderBindingTableBuffer, VkDeviceSize missShaderBindingOffset, VkDeviceSize missShaderBindingStride, VkBuffer hitShaderBindingTableBuffer, VkDeviceSize hitShaderBindingOffset, VkDeviceSize hitShaderBindingStride, uint32_t width, uint32_t height);
typedef void (VKAPI_PTR *PFN_vkCmdBuildAccelerationStructureNVX)(VkCommandBuffer commandBuffer, VkAccelerationStructureTypeNVX type, uint32_t instanceCount, VkBuffer instanceData, VkDeviceSize instanceOffset, uint32_t geometryCount, const VkGeometryNVX* pGeometries, VkBuildAccelerationStructureFlagsNVX flags, VkBool32 update, VkAccelerationStructureNVX dst, VkAccelerationStructureNVX src, VkBuffer scratch, VkDeviceSize scratchOffset);
typedef void (VKAPI_PTR *PFN_vkCmdCopyAccelerationStructureNVX)(VkCommandBuffer commandBuffer, VkAccelerationStructureNVX dst, VkAccelerationStructureNVX src, VkCopyAccelerationStructureModeNVX mode);
typedef void (VKAPI_PTR *PFN_vkCmdTraceRaysNVX)(VkCommandBuffer commandBuffer, VkBuffer raygenShaderBindingTableBuffer, VkDeviceSize raygenShaderBindingOffset, VkBuffer missShaderBindingTableBuffer, VkDeviceSize missShaderBindingOffset, VkDeviceSize missShaderBindingStride, VkBuffer hitShaderBindingTableBuffer, VkDeviceSize hitShaderBindingOffset, VkDeviceSize hitShaderBindingStride, uint32_t width, uint32_t height);
typedef VkResult (VKAPI_PTR *PFN_vkCreateRaytracingPipelinesNVX)(VkDevice device, VkPipelineCache pipelineCache, uint32_t createInfoCount, const VkRaytracingPipelineCreateInfoNVX* pCreateInfos, const VkAllocationCallbacks* pAllocator, VkPipeline* pPipelines);
typedef VkResult (VKAPI_PTR *PFN_vkGetRaytracingShaderHandlesNVX)(VkDevice device, VkPipeline pipeline, uint32_t firstGroup, uint32_t groupCount, size_t dataSize, void* pData);
typedef VkResult (VKAPI_PTR *PFN_vkGetAccelerationStructureHandleNVX)(VkDevice device, VkAccelerationStructureNVX accelerationStructure, size_t dataSize, void* pData);
typedef void (VKAPI_PTR *PFN_vkCmdWriteAccelerationStructurePropertiesNVX)(VkCommandBuffer cmdBuf, VkAccelerationStructureNVX accelerationStructure, VkQueryType queryType, VkQueryPool queryPool, uint32_t query);
typedef void (VKAPI_PTR *PFN_vkCmdWriteAccelerationStructurePropertiesNVX)(VkCommandBuffer commandBuffer, VkAccelerationStructureNVX accelerationStructure, VkQueryType queryType, VkQueryPool queryPool, uint32_t query);
typedef VkResult (VKAPI_PTR *PFN_vkCompileDeferredNVX)(VkDevice device, VkPipeline pipeline, uint32_t shader);
#ifndef VK_NO_PROTOTYPES
@ -8081,7 +8137,7 @@ VKAPI_ATTR VkResult VKAPI_CALL vkBindAccelerationStructureMemoryNVX(
const VkBindAccelerationStructureMemoryInfoNVX* pBindInfos);
VKAPI_ATTR void VKAPI_CALL vkCmdBuildAccelerationStructureNVX(
VkCommandBuffer cmdBuf,
VkCommandBuffer commandBuffer,
VkAccelerationStructureTypeNVX type,
uint32_t instanceCount,
VkBuffer instanceData,
@ -8096,13 +8152,13 @@ VKAPI_ATTR void VKAPI_CALL vkCmdBuildAccelerationStructureNVX(
VkDeviceSize scratchOffset);
VKAPI_ATTR void VKAPI_CALL vkCmdCopyAccelerationStructureNVX(
VkCommandBuffer cmdBuf,
VkCommandBuffer commandBuffer,
VkAccelerationStructureNVX dst,
VkAccelerationStructureNVX src,
VkCopyAccelerationStructureModeNVX mode);
VKAPI_ATTR void VKAPI_CALL vkCmdTraceRaysNVX(
VkCommandBuffer cmdBuf,
VkCommandBuffer commandBuffer,
VkBuffer raygenShaderBindingTableBuffer,
VkDeviceSize raygenShaderBindingOffset,
VkBuffer missShaderBindingTableBuffer,
@ -8137,7 +8193,7 @@ VKAPI_ATTR VkResult VKAPI_CALL vkGetAccelerationStructureHandleNVX(
void* pData);
VKAPI_ATTR void VKAPI_CALL vkCmdWriteAccelerationStructurePropertiesNVX(
VkCommandBuffer cmdBuf,
VkCommandBuffer commandBuffer,
VkAccelerationStructureNVX accelerationStructure,
VkQueryType queryType,
VkQueryPool queryPool,

2
reflow_count.py
View File

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

241
xml/vk.xml
View File

@ -147,7 +147,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> 85</type>
#define <name>VK_HEADER_VERSION</name> 86</type>
<type category="define">
#define <name>VK_DEFINE_HANDLE</name>(object) typedef struct object##_T* object;</type>
@ -523,6 +523,7 @@ server.
<comment>Enumerated types in the header, but not used by the API</comment>
<type name="VkVendorId" category="enum"/>
<type name="VkDriverIdKHR" category="enum"/>
<type name="VkShadingRatePaletteEntryNV" category="enum"/>
<type name="VkCoarseSampleOrderTypeNV" category="enum"/>
@ -1972,6 +1973,20 @@ server.
<member><type>void</type>* <name>pNext</name></member>
<member><type>uint32_t</type> <name>maxPushDescriptors</name></member>
</type>
<type category="struct" name="VkConformanceVersionKHR">
<member><type>uint8_t</type> <name>major</name></member>
<member><type>uint8_t</type> <name>minor</name></member>
<member><type>uint8_t</type> <name>subminor</name></member>
<member><type>uint8_t</type> <name>patch</name></member>
</type>
<type category="struct" name="VkPhysicalDeviceDriverPropertiesKHR" structextends="VkPhysicalDeviceProperties2" returnedonly="true">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR"><type>VkStructureType</type> <name>sType</name></member>
<member><type>void</type>* <name>pNext</name></member>
<member><type>uint32_t</type> <name>driverID</name></member>
<member><type>char</type> <name>driverName</name>[<enum>VK_MAX_DRIVER_NAME_SIZE_KHR</enum>]</member>
<member><type>char</type> <name>driverInfo</name>[<enum>VK_MAX_DRIVER_INFO_SIZE_KHR</enum>]</member>
<member><type>VkConformanceVersionKHR</type> <name>conformanceVersion</name></member>
</type>
<type category="struct" name="VkPresentRegionsKHR" structextends="VkPresentInfoKHR">
<member values="VK_STRUCTURE_TYPE_PRESENT_REGIONS_KHR"><type>VkStructureType</type> <name>sType</name></member>
<member>const <type>void</type>* <name>pNext</name></member>
@ -3243,6 +3258,12 @@ server.
<member><type>VkBool32</type> <name>vulkanMemoryModel</name></member>
<member><type>VkBool32</type> <name>vulkanMemoryModelDeviceScope</name></member>
</type>
<type category="struct" name="VkPhysicalDeviceShaderAtomicInt64FeaturesKHR" structextends="VkPhysicalDeviceFeatures2,VkDeviceCreateInfo">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_INT64_FEATURES_KHR"><type>VkStructureType</type> <name>sType</name></member>
<member><type>void</type>* <name>pNext</name></member>
<member><type>VkBool32</type> <name>shaderBufferInt64Atomics</name></member>
<member><type>VkBool32</type> <name>shaderSharedInt64Atomics</name></member>
</type>
<type category="struct" name="VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT" structextends="VkPhysicalDeviceFeatures2,VkDeviceCreateInfo">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member noautovalidity="true"><type>void</type>* <name>pNext</name></member>
@ -3464,6 +3485,40 @@ server.
<member><type>uint32_t</type> <name>maxRecursionDepth</name></member>
<member><type>uint32_t</type> <name>maxGeometryCount</name></member>
</type>
<type category="struct" name="VkDrmFormatModifierPropertiesListEXT" structextends="VkFormatProperties2">
<member values="VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_LIST_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member><type>void</type>* <name>pNext</name></member>
<member optional="true"><type>uint32_t</type> <name>drmFormatModifierCount</name></member>
<member optional="true,false" len="drmFormatModifierCount"><type>VkDrmFormatModifierPropertiesEXT</type>* <name>pDrmFormatModifierProperties</name></member>
</type>
<type category="struct" name="VkDrmFormatModifierPropertiesEXT" returnedonly="true">
<member><type>uint64_t</type> <name>drmFormatModifier</name></member>
<member><type>uint32_t</type> <name>drmFormatModifierPlaneCount</name></member>
<member><type>VkFormatFeatureFlags</type> <name>drmFormatModifierTilingFeatures</name></member>
</type>
<type category="struct" name="VkPhysicalDeviceImageDrmFormatModifierInfoEXT" structextends="VkPhysicalDeviceImageFormatInfo2">
<member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_DRM_FORMAT_MODIFIER_INFO_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member>const <type>void</type>* <name>pNext</name></member>
<member><type>uint64_t</type> <name>drmFormatModifier</name></member>
</type>
<type category="struct" name="VkImageDrmFormatModifierListCreateInfoEXT" structextends="VkImageCreateInfo">
<member values="VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_LIST_CREATE_INFO_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member>const <type>void</type>* <name>pNext</name></member>
<member><type>uint32_t</type> <name>drmFormatModifierCount</name></member>
<member len="drmFormatModifierCount">const <type>uint64_t</type>* <name>pDrmFormatModifiers</name></member>
</type>
<type category="struct" name="VkImageDrmFormatModifierExplicitCreateInfoEXT" structextends="VkImageCreateInfo">
<member values="VK_STRUCTURE_TYPE_IMAGE_EXCPLICIT_DRM_FORMAT_MODIFIER_CREATE_INFO_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member>const <type>void</type>* <name>pNext</name></member>
<member><type>uint64_t</type> <name>drmFormatModifier</name></member>
<member optional="false"><type>uint32_t</type> <name>drmFormatModifierPlaneCount</name></member>
<member len="drmFormatModifierPlaneCount">const <type>VkSubresourceLayout</type>* <name>pPlaneLayouts</name></member>
</type>
<type category="struct" name="VkImageDrmFormatModifierPropertiesEXT" returnedonly="true">
<member values="VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member><type>void</type>* <name>pNext</name></member>
<member><type>uint64_t</type> <name>drmFormatModifier</name></member>
</type>
</types>
<comment>Vulkan enumerant (token) definitions</comment>
@ -3491,6 +3546,8 @@ server.
<enum value="(~0U)" name="VK_SUBPASS_EXTERNAL"/>
<enum value="32" name="VK_MAX_DEVICE_GROUP_SIZE"/>
<enum name="VK_MAX_DEVICE_GROUP_SIZE_KHR" alias="VK_MAX_DEVICE_GROUP_SIZE"/>
<enum value="256" name="VK_MAX_DRIVER_NAME_SIZE_KHR"/>
<enum value="256" name="VK_MAX_DRIVER_INFO_SIZE_KHR"/>
</enums>
<comment>
@ -4043,6 +4100,7 @@ server.
<enum bitpos="2" name="VK_QUEUE_TRANSFER_BIT" comment="Queue supports transfer operations"/>
<enum bitpos="3" name="VK_QUEUE_SPARSE_BINDING_BIT" comment="Queue supports sparse resource memory management operations"/>
</enums>
<enums name="VkRenderPassCreateFlagBits" type="bitmask"></enums>
<enums name="VkDeviceQueueCreateFlagBits" type="bitmask"></enums>
<enums name="VkMemoryPropertyFlagBits" type="bitmask">
<enum bitpos="0" name="VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT" comment="If otherwise stated, then allocate memory on device"/>
@ -4549,6 +4607,20 @@ server.
<enum value="0x10003" name="VK_VENDOR_ID_KAZAN" comment="Kazan Software Renderer"/>
<unused start="0x10004" comment="This is the next unused available Khronos vendor ID"/>
</enums>
<enums name="VkDriverIdKHR" type="enum">
<comment>Driver IDs are now represented as enums instead of the old
&lt;driverids&gt; tag, allowing them to be included in the
API headers.</comment>
<enum value="1" name="VK_DRIVER_ID_AMD_PROPRIETARY_KHR" comment="Advanced Micro Devices, Inc."/>
<enum value="2" name="VK_DRIVER_ID_AMD_OPEN_SOURCE_KHR" comment="Advanced Micro Devices, Inc."/>
<enum value="3" name="VK_DRIVER_ID_MESA_RADV_KHR" comment="Mesa open source project"/>
<enum value="4" name="VK_DRIVER_ID_NVIDIA_PROPRIETARY_KHR" comment="NVIDIA Corporation"/>
<enum value="5" name="VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS_KHR" comment="Intel Corporation"/>
<enum value="6" name="VK_DRIVER_ID_INTEL_OPEN_SOURCE_MESA_KHR" comment="Intel Corporation"/>
<enum value="7" name="VK_DRIVER_ID_IMAGINATION_PROPRIETARY_KHR" comment="Imagination Technologies"/>
<enum value="8" name="VK_DRIVER_ID_QUALCOMM_PROPRIETARY_KHR" comment="Qualcomm Technologies, Inc."/>
<enum value="9" name="VK_DRIVER_ID_ARM_PROPRIETARY_KHR" comment="Arm Limited"/>
</enums>
<enums name="VkConditionalRenderingFlagBitsEXT" type="bitmask">
<enum bitpos="0" name="VK_CONDITIONAL_RENDERING_INVERTED_BIT_EXT"/>
</enums>
@ -6658,14 +6730,14 @@ server.
</command>
<command queues="graphics,compute" renderpass="both" cmdbufferlevel="primary,secondary">
<proto><type>void</type> <name>vkCmdCopyAccelerationStructureNVX</name></proto>
<param><type>VkCommandBuffer</type> <name>cmdBuf</name></param>
<param><type>VkCommandBuffer</type> <name>commandBuffer</name></param>
<param><type>VkAccelerationStructureNVX</type> <name>dst</name></param>
<param><type>VkAccelerationStructureNVX</type> <name>src</name></param>
<param><type>VkCopyAccelerationStructureModeNVX</type> <name>mode</name></param>
</command>
<command queues="graphics,compute" renderpass="both" cmdbufferlevel="primary,secondary">
<proto><type>void</type> <name>vkCmdWriteAccelerationStructurePropertiesNVX</name></proto>
<param><type>VkCommandBuffer</type> <name>cmdBuf</name></param>
<param><type>VkCommandBuffer</type> <name>commandBuffer</name></param>
<param><type>VkAccelerationStructureNVX</type> <name>accelerationStructure</name></param>
<param><type>VkQueryType</type> <name>queryType</name></param>
<param><type>VkQueryPool</type> <name>queryPool</name></param>
@ -6673,7 +6745,7 @@ server.
</command>
<command queues="graphics,compute" renderpass="both" cmdbufferlevel="primary,secondary">
<proto><type>void</type> <name>vkCmdBuildAccelerationStructureNVX</name></proto>
<param><type>VkCommandBuffer</type> <name>cmdBuf</name></param>
<param><type>VkCommandBuffer</type> <name>commandBuffer</name></param>
<param><type>VkAccelerationStructureTypeNVX</type> <name>type</name></param>
<param optional="true"><type>uint32_t</type> <name>instanceCount</name></param>
<param optional="true"><type>VkBuffer</type> <name>instanceData</name></param>
@ -6689,7 +6761,7 @@ server.
</command>
<command queues="graphics,compute" renderpass="both" cmdbufferlevel="primary,secondary">
<proto><type>void</type> <name>vkCmdTraceRaysNVX</name></proto>
<param><type>VkCommandBuffer</type> <name>cmdBuf</name></param>
<param><type>VkCommandBuffer</type> <name>commandBuffer</name></param>
<param><type>VkBuffer</type> <name>raygenShaderBindingTableBuffer</name></param>
<param><type>VkDeviceSize</type> <name>raygenShaderBindingOffset</name></param>
<param><type>VkBuffer</type> <name>missShaderBindingTableBuffer</name></param>
@ -6726,6 +6798,12 @@ server.
<param optional="true">const <type>VkAllocationCallbacks</type>* <name>pAllocator</name></param>
<param len="createInfoCount"><type>VkPipeline</type>* <name>pPipelines</name></param>
</command>
<command>
<proto><type>VkResult</type> <name>vkGetImageDrmFormatModifierPropertiesEXT</name></proto>
<param><type>VkDevice</type> <name>device</name></param>
<param><type>VkImage</type> <name>image</name></param>
<param><type>VkImageDrmFormatModifierPropertiesEXT</type>* <name>pProperties</name></param>
</command>
</commands>
<feature api="vulkan" name="VK_VERSION_1_0" number="1.0" comment="Vulkan core API interface definitions">
@ -9115,10 +9193,38 @@ server.
<type name="VkBindImageMemoryInfoKHR"/>
</require>
</extension>
<extension name="VK_EXT_extension_159" number="159" author="EXT" contact="Chad Versace @chadversary" supported="disabled">
<extension name="VK_EXT_image_drm_format_modifier" number="159" type="device" requires="VK_KHR_bind_memory2,VK_KHR_get_physical_device_properties2,VK_KHR_sampler_ycbcr_conversion" author="EXT" contact="Chad Versace @chadversary" supported="disabled">
<require>
<enum value="0" name="VK_EXT_EXTENSION_159_SPEC_VERSION"/>
<enum value="&quot;VK_EXT_extension_159&quot;" name="VK_EXT_EXTENSION_159_EXTENSION_NAME"/>
<enum value="1" name="VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_SPEC_VERSION"/>
<enum value="&quot;VK_EXT_image_drm_format_modifier&quot;" name="VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME"/>
<enum offset="0" dir="-" extends="VkResult" name="VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT"/>
<enum offset="0" extends="VkStructureType" name="VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_LIST_EXT"/>
<enum offset="1" extends="VkStructureType" name="VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT"/>
<enum offset="2" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_DRM_FORMAT_MODIFIER_INFO_EXT"/>
<enum offset="3" extends="VkStructureType" name="VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_LIST_CREATE_INFO_EXT"/>
<enum offset="4" extends="VkStructureType" name="VK_STRUCTURE_TYPE_IMAGE_EXCPLICIT_DRM_FORMAT_MODIFIER_CREATE_INFO_EXT"/>
<enum offset="5" extends="VkStructureType" name="VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT"/>
<enum offset="0" extends="VkImageTiling" name="VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT"/>
<enum bitpos="7" extends="VkImageAspectFlagBits" name="VK_IMAGE_ASPECT_MEMORY_PLANE_0_BIT_EXT"/>
<enum bitpos="8" extends="VkImageAspectFlagBits" name="VK_IMAGE_ASPECT_MEMORY_PLANE_1_BIT_EXT"/>
<enum bitpos="9" extends="VkImageAspectFlagBits" name="VK_IMAGE_ASPECT_MEMORY_PLANE_2_BIT_EXT"/>
<enum bitpos="10" extends="VkImageAspectFlagBits" name="VK_IMAGE_ASPECT_MEMORY_PLANE_3_BIT_EXT"/>
<type name="VkDrmFormatModifierPropertiesListEXT"/>
<type name="VkDrmFormatModifierPropertiesEXT"/>
<type name="VkPhysicalDeviceImageDrmFormatModifierInfoEXT"/>
<type name="VkImageDrmFormatModifierListCreateInfoEXT"/>
<type name="VkImageDrmFormatModifierExplicitCreateInfoEXT"/>
<type name="VkImageDrmFormatModifierPropertiesEXT"/>
<command name="vkGetImageDrmFormatModifierPropertiesEXT"/>
</require>
</extension>
<extension name="VK_EXT_extension_160" number="160" author="EXT" contact="Mark Young @marky-lunarg" supported="disabled">
@ -9383,10 +9489,12 @@ server.
<command name="vkCmdWriteBufferMarkerAMD"/>
</require>
</extension>
<extension name="VK_AMD_extension_181" number="181" author="AMD" contact="Daniel Rakos @drakos-amd" supported="disabled">
<extension name="VK_KHR_shader_atomic_int64" number="181" type="device" author="KHR" requires="VK_KHR_get_physical_device_properties2" contact="Aaron Hagan @ahagan" supported="vulkan">
<require>
<enum value="0" name="VK_KHR_EXTENSION_181_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_181&quot;" name="VK_KHR_EXTENSION_181_EXTENSION_NAME"/>
<enum value="1" name="VK_KHR_SHADER_ATOMIC_INT64_SPEC_VERSION"/>
<enum value="&quot;VK_KHR_shader_atomic_int64&quot;" name="VK_KHR_SHADER_ATOMIC_INT64_EXTENSION_NAME"/>
<enum offset="0" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_INT64_FEATURES_KHR"/>
<type name="VkPhysicalDeviceShaderAtomicInt64FeaturesKHR"/>
</require>
</extension>
<extension name="VK_AMD_extension_182" number="182" author="AMD" contact="Daniel Rakos @drakos-amd" supported="disabled">
@ -9488,10 +9596,16 @@ server.
<enum value="&quot;VK_GOOGLE_extension_196&quot;" name="VK_GOOGLE_EXTENSION_196_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_EXT_extension_197" number="197" author="Baldur Karlsson" contact="Baldur Karlsson @baldurk" supported="disabled">
<extension name="VK_KHR_driver_properties" number="197" type="device" requires="VK_KHR_get_physical_device_properties2" author="KHR" contact="Daniel Rakos @drakos-amd" supported="vulkan">
<require>
<enum value="0" name="VK_EXT_EXTENSION_197_SPEC_VERSION"/>
<enum value="&quot;VK_EXT_extension_197&quot;" name="VK_EXT_EXTENSION_197_EXTENSION_NAME"/>
<enum value="1" name="VK_KHR_DRIVER_PROPERTIES_SPEC_VERSION"/>
<enum value="&quot;VK_KHR_driver_properties&quot;" name="VK_KHR_DRIVER_PROPERTIES_EXTENSION_NAME"/>
<enum offset="0" extends="VkStructureType" name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR"/>
<enum name="VK_MAX_DRIVER_NAME_SIZE_KHR"/>
<enum name="VK_MAX_DRIVER_INFO_SIZE_KHR"/>
<type name="VkDriverIdKHR"/>
<type name="VkConformanceVersionKHR"/>
<type name="VkPhysicalDeviceDriverPropertiesKHR"/>
</require>
</extension>
<extension name="VK_ARM_extension_198" number="198" author="Alexander Galazin" contact="Alexander Galazin @alegal-arm" supported="disabled">
@ -9670,5 +9784,108 @@ server.
<enum value="&quot;VK_EXT_extension_220&quot;" name="VK_EXT_EXTENSION_220_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_KHR_extension_221" number="221" author="KHR" contact="Tobias Hector @tobski" supported="disabled">
<require>
<enum value="0" name="VK_KHR_EXTENSION_221_SPEC_VERSION"/>
<enum value="&quot;VK_KHR_extension_221&quot;" name="VK_KHR_EXTENSION_221_EXTENSION_NAME"/>
<enum bitpos="0" extends="VkRenderPassCreateFlagBits" name="VK_RENDER_PASS_CREATE_RESERVED_0_BIT_KHR"/>
</require>
</extension>
<extension name="VK_EXT_extension_222" number="222" author="EXT" contact="Tobias Hector @tobski" supported="disabled">
<require>
<enum value="0" name="VK_EXT_EXTENSION_222_SPEC_VERSION"/>
<enum value="&quot;VK_EXT_extension_222&quot;" name="VK_EXT_EXTENSION_222_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_EXT_extension_223" number="223" author="EXT" contact="Tobias Hector @tobski" supported="disabled">
<require>
<enum value="0" name="VK_EXT_EXTENSION_223_SPEC_VERSION"/>
<enum value="&quot;VK_EXT_extension_223&quot;" name="VK_EXT_EXTENSION_223_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_224" number="224" author="AMD" contact="Martin Dinkov @mdinkov" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_224_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_224&quot;" name="VK_AMD_EXTENSION_224_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_225" number="225" author="AMD" contact="Martin Dinkov @mdinkov" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_225_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_225&quot;" name="VK_AMD_EXTENSION_225_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_226" number="226" author="AMD" contact="Martin Dinkov @mdinkov" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_226_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_226&quot;" name="VK_AMD_EXTENSION_226_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_227" number="227" author="AMD" contact="Martin Dinkov @mdinkov" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_227_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_227&quot;" name="VK_AMD_EXTENSION_227_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_228" number="228" author="AMD" contact="Martin Dinkov @mdinkov" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_228_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_228&quot;" name="VK_AMD_EXTENSION_228_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_229" number="229" author="AMD" contact="Martin Dinkov @mdinkov" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_229_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_229&quot;" name="VK_AMD_EXTENSION_229_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_230" number="230" author="AMD" contact="Martin Dinkov @mdinkov" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_230_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_230&quot;" name="VK_AMD_EXTENSION_230_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_231" number="231" author="AMD" contact="Martin Dinkov @mdinkov" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_231_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_231&quot;" name="VK_AMD_EXTENSION_231_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_232" number="232" author="AMD" contact="Martin Dinkov @mdinkov" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_232_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_232&quot;" name="VK_AMD_EXTENSION_232_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_233" number="233" author="AMD" contact="Martin Dinkov @mdinkov" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_233_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_233&quot;" name="VK_AMD_EXTENSION_233_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_234" number="234" author="AMD" contact="Martin Dinkov @mdinkov" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_234_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_234&quot;" name="VK_AMD_EXTENSION_234_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_235" number="235" author="AMD" contact="Martin Dinkov @mdinkov" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_235_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_235&quot;" name="VK_AMD_EXTENSION_235_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_AMD_extension_236" number="236" author="AMD" contact="Martin Dinkov @mdinkov" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_236_SPEC_VERSION"/>
<enum value="&quot;VK_AMD_extension_236&quot;" name="VK_AMD_EXTENSION_236_EXTENSION_NAME"/>
</require>
</extension>
<extension name="VK_KHR_extension_237" number="237" author="KHR" contact="Jesse Hall @critsec" supported="disabled">
<require>
<enum value="0" name="VK_AMD_EXTENSION_237_SPEC_VERSION"/>
<enum value="&quot;VK_KHR_extension_237&quot;" name="VK_AMD_EXTENSION_237_EXTENSION_NAME"/>
</require>
</extension>
</extensions>
</registry>