diff --git a/.mailmap b/.mailmap index 5ffa3a84b..ab7e5802a 100644 --- a/.mailmap +++ b/.mailmap @@ -4,3 +4,4 @@ Faith Ekstrand Faith Ekstrand Faith Ekstrand +Rylie Pavlik diff --git a/.reuse/dep5 b/.reuse/dep5 index 19e95d66b..e2486a3bb 100644 --- a/.reuse/dep5 +++ b/.reuse/dep5 @@ -2,7 +2,7 @@ Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: Vulkan-Docs Source: https://github.com/KhronosGroup/Vulkan-Docs -Files: images/*.svg config/chunkindex/custom.patch config/CI/contractions* config/CI/writing config/CI/txt-files-allowed config/*/docinfo-header.html build_tests/expectations/* build_tests/images/*.svg +Files: images/*.svg config/chunkindex/custom.patch config/CI/contractions* config/CI/writing config/CI/txt-files-allowed config/*/docinfo-header.html build_tests/expectations/* build_tests/images/*.svg images/proposals/*.svg Copyright: 2015-2024 The Khronos Group Inc. License: CC-BY-4.0 diff --git a/BUILD.adoc b/BUILD.adoc index 9ea5cacb8..8a4c90a57 100644 --- a/BUILD.adoc +++ b/BUILD.adoc @@ -103,18 +103,24 @@ Vulkan Specification:: dependency in $(OUTDIR)/katex * `chunked` -- Chunked HTML5 in `$(OUTDIR)/html/chap?.html` * `pdf` -- PDF in `$(OUTDIR)/pdf/vkspec.pdf` + "`styleguide`" (Vulkan Documentation and Extensions: Procedures and Conventions):: * `styleguide` -- Single-file HTML5 in `$(OUTDIR)/styleguide.html` + XML Registry schema document:: * `registry` -- Single-file HTML5 in `$(OUTDIR)/registry.html` + <>:: * `diff_html` -- Single-file HTML5 in `$(OUTDIR)/html/diff.html` + <>:: * `manhtmlpages` -- File-per-entry-point HTML in `$(OUTDIR)/man/html/*`. Must be built with all extensions enabled (using `makeSpec -spec all`). + <>:: * None at present. The `allchecks` target writes to standard output unless the underlying script is given additional options. + Valid usage database:: * `validusage` - json database of all valid usage statements in the specification. Must be built with `./makeAllExts` (for now). @@ -171,6 +177,7 @@ Valid values for the `VULKAN_API` environment are: If `VULKAN_API` is not set, the repository default is used. + [[building-extensions]] === Building With Extensions Included @@ -463,9 +470,20 @@ toolchain yourself. ==== +[[building-epub-outputs]] +=== Building EPUB Outputs + +The `epub` target will generate an EPUB file in in +`$(OUTDIR)/epub/vkspec.epub`. Note that the `epub` target is +community-contributed, and not supported by Khronos. See +https://github.com/KhronosGroup/Vulkan-Docs/pull/2286 for more. + + [[history]] == Revision History + * 2024-01-24 - Add <> + section describing a community-contributed EPUB spec output target. * 2023-05-29 - Add Vulkan SC spec build instructions. * 2022-10-11 - Update descriptions of using the Docker image to use the `runDocker` script and the same SHA256 of the latest image as used by diff --git a/ChangeLog.adoc b/ChangeLog.adoc index f7f12fcdd..dfcd30c9f 100644 --- a/ChangeLog.adoc +++ b/ChangeLog.adoc @@ -14,6 +14,77 @@ appears frequently in the change log. ----------------------------------------------------- +Change log for January 25, 2024 Vulkan 1.3.276 spec update: + +Github Issues + + * Add missing VUs to structures taking elink:VkFormat parameters where + formats cannot be ename:VK_FORMAT_UNDEFINED (public issue 2165). + * Add EPUB generation target to the Makefile. NOTE: the `epub` target is + not supported by Khronos, but provided in case it is of use to people + building their own specification outputs. Please see + https://github.com/KhronosGroup/Vulkan-Docs/pull/2286 for more about + this (public PR 2286). + +Internal Issues + + * Fix VU 06604 to allow omitting fragment shaders when creating a graphics + pipeline library (internal issue 3178). + * Clarify pname:maxCombinedClipAndCullDistances and related VUs (internal + issue 3325). + * Refactor apiext:VK_EXT_extended_dynamic_state3 and + apiext:VK_EXT_shader_object XML to include extension dependencies + (internal issue 3360). + * Add <> VU banning code:PhysicalStorageBuffer pointers in shader + interfaces (internal issue 3677). + * Clarified image requirement for slink:VkSparseImageFormatProperties + (internal issue 3686). + * Add slink:VkQueryPoolCreateInfo VU requiring pname:pipelineStatistics + not be zero for that query type (internal issue 3722). + * Add slink:VkWriteDescriptorSet and flink:vkGetDescriptorEXT VUs banning + dlink:VK_NULL_HANDLE YCbCr descriptors (internal issue 3727). + * Clarify acceleration structure binding requirements in a NOTE for + flink:vkCreateAccelerationStructureKHR and new VUs for + flink:vkGetAccelerationStructureDeviceAddressKHR (internal issue 3735). + * Add `optional` attribute to shader parameter of flink:vkDestroyShaderEXT + (internal issue 3754). + * Add flink:vkSetEvent VU for pending command buffers (internal MR 6326). + * Allow pname:pMessage to be `NULL` in + slink:VkDebugUtilsMessengerCallbackDataEXT (internal MR 6331). + * Fix link to the H.265 specification (internal MR 6334). + * Remove redundant slink:VkDeferredOperationKHR check formerly in VUID + 03677 (internal MR 6374). + * Add VU requiring pname:commandBuffer to not be protected for + flink:vkCmdBuildAccelerationStructuresKHR (internal MR 6375). + * Update `genvk.py` to not load generators when they are not available, as + may be the case in VulkanSC-Headers or downstream repositories (internal + MR 6384). + * Add `returnedonly` attributes to some Properties structs missing them + (internal MR 6392). + * Remove redundant slink:VkDebugUtilsMessengerCreateInfoEXT VU 01914 + (internal MR 6404). + * Clarify the conditions under which <> may become inactive (internal MR 6405). + * Fix typo in + slink:VkPipelineMultisampleStateCreateInfo::pname:sampleShadingEnable + member name (internal MR 6407). + +New Extensions + + * Roadmap 2024 Extensions + ** VK_KHR_dynamic_rendering_local_read + ** VK_KHR_index_type_uint8 (promoted from EXT) + ** VK_KHR_line_rasterization (promoted from EXT) + ** VK_KHR_load_store_op_none (promoted from EXT) + ** VK_KHR_shader_expect_assume + ** VK_KHR_shader_float_controls2 + ** VK_KHR_shader_maximal_reconvergence + ** VK_KHR_shader_quad_control + ** VK_KHR_shader_subgroup_rotate + +----------------------------------------------------- + Change log for January 5, 2024 Vulkan 1.3.275 spec update: Github Issues diff --git a/Makefile b/Makefile index 73d94f837..5b927bb71 100644 --- a/Makefile +++ b/Makefile @@ -137,7 +137,7 @@ VERBOSE = # ADOCOPTS options for asciidoc->HTML5 output NOTEOPTS = -a editing-notes -a implementation-guide -PATCHVERSION = 275 +PATCHVERSION = 276 BASEOPTS = ifneq (,$(findstring VKSC_VERSION_1_0,$(VERSIONS))) @@ -371,6 +371,8 @@ $(PDFDIR)/vkspec.pdf: $(SPECSRC) $(COMMONDOCS) $(QUIET)$(OPTIMIZEPDF) $@ $@.out.pdf && mv $@.out.pdf $@ $(QUIET)$(RMRF) $(PDFMATHDIR) +# EPUB generation is community-contributed and not supported by Khronos. +# See https://github.com/KhronosGroup/Vulkan-Docs/pull/2286 epub: $(EPUBDIR)/vkspec.epub $(SPECSRC) $(COMMONDOCS) $(EPUBDIR)/vkspec.epub: $(SPECSRC) $(COMMONDOCS) diff --git a/appendices/VK_EXT_index_type_uint8.adoc b/appendices/VK_EXT_index_type_uint8.adoc index 7856d0a8e..1252b587b 100644 --- a/appendices/VK_EXT_index_type_uint8.adoc +++ b/appendices/VK_EXT_index_type_uint8.adoc @@ -18,6 +18,13 @@ include::{generated}/meta/{refprefix}VK_EXT_index_type_uint8.adoc[] This extension allows code:uint8_t indices to be used with flink:vkCmdBindIndexBuffer. +=== Promotion to `VK_KHR_index_type_uint8` + +All functionality in this extension is included in +`apiext:VK_KHR_index_type_uint8`, with the suffix changed to KHR. +The original enum names are still available as aliases of the KHR +functionality. + include::{generated}/interfaces/VK_EXT_index_type_uint8.adoc[] === Version History diff --git a/appendices/VK_EXT_line_rasterization.adoc b/appendices/VK_EXT_line_rasterization.adoc index 092b104ca..bfeb6797b 100644 --- a/appendices/VK_EXT_line_rasterization.adoc +++ b/appendices/VK_EXT_line_rasterization.adoc @@ -23,6 +23,13 @@ Bresenham-style line rasterization is supported, smooth rectangular lines (coverage to alpha) are supported, and stippled lines are supported for all three line rasterization modes. +=== Promotion to `VK_KHR_line_rasterization` + +All functionality in this extension is included in +`apiext:VK_KHR_line_rasterization`, with the suffix changed to KHR. +The original enum names are still available as aliases of the KHR +functionality. + include::{generated}/interfaces/VK_EXT_line_rasterization.adoc[] === Issues diff --git a/appendices/VK_EXT_load_store_op_none.adoc b/appendices/VK_EXT_load_store_op_none.adoc index 491d1405a..0eebcf844 100644 --- a/appendices/VK_EXT_load_store_op_none.adoc +++ b/appendices/VK_EXT_load_store_op_none.adoc @@ -28,6 +28,13 @@ an alternative to preserve attachments in applications that cannot decide if an attachment will be used in a render pass until after the necessary pipelines have been created. +=== Promotion to `VK_KHR_load_store_op_none` + +All functionality in this extension is included in +`apiext:VK_KHR_load_store_op_none`, with the suffix changed to KHR. +The original enum names are still available as aliases of the KHR +functionality. + include::{generated}/interfaces/VK_EXT_load_store_op_none.adoc[] === Version History diff --git a/appendices/VK_KHR_dynamic_rendering_local_read.adoc b/appendices/VK_KHR_dynamic_rendering_local_read.adoc new file mode 100644 index 000000000..61c420d87 --- /dev/null +++ b/appendices/VK_KHR_dynamic_rendering_local_read.adoc @@ -0,0 +1,47 @@ +// Copyright 2023-2024 The Khronos Group Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + +include::{generated}/meta/{refprefix}VK_KHR_dynamic_rendering_local_read.adoc[] + +=== Other Extension Metadata + +*Last Modified Date*:: + 2023-11-03 +*Contributors*:: + - Tobias Hector, AMD + - Hans-Kristian Arntzen, Valve + - Connor Abbot, Valve + - Pan Gao, Huawei + - Lionel Landwerlin, Intel + - Shahbaz Youssefi, Google + - Alyssa Rosenzweig, Valve + - Jan-Harald Fredriksen, Arm + - Mike Blumenkrantz, Valve + - Graeme Leese, Broadcom + - Piers Daniell, Nvidia + - Stuart Smith, AMD + - Daniel Story, Nintendo + - James Fitzpatrick, Imagination + - Piotr Byszewski, Mobica + - Spencer Fricke, LunarG + - Tom Olson, Arm + - Michal Pietrasiuk, Intel + - Matthew Netsch, Qualcomm + - Marty Johnson, Khronos + - Huilong Wang, Huawei + - Jeff Bolz, Nvidia + - Samuel (Sheng-Wen) Huang, MediaTek + + +=== Description + +This extension enables reads from attachments and resources written by +previous fragment shaders within a dynamic render pass. + +include::{generated}/interfaces/VK_KHR_dynamic_rendering_local_read.adoc[] + +=== Version History + + * Revision 1, 2023-11-03 (Tobias Hector) + ** Initial revision diff --git a/appendices/VK_KHR_index_type_uint8.adoc b/appendices/VK_KHR_index_type_uint8.adoc new file mode 100644 index 000000000..42149b12d --- /dev/null +++ b/appendices/VK_KHR_index_type_uint8.adoc @@ -0,0 +1,26 @@ +// Copyright 2019-2024 The Khronos Group Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + +include::{generated}/meta/{refprefix}VK_KHR_index_type_uint8.adoc[] + +=== Other Extension Metadata + +*Last Modified Date*:: + 2023-06-06 +*IP Status*:: + No known IP claims. +*Contributors*:: + - Jeff Bolz, NVIDIA + +=== Description + +This extension allows code:uint8_t indices to be used with +flink:vkCmdBindIndexBuffer. + +include::{generated}/interfaces/VK_KHR_index_type_uint8.adoc[] + +=== Version History + + * Revision 1, 2023-06-06 (Piers Daniell) + ** Internal revisions diff --git a/appendices/VK_KHR_line_rasterization.adoc b/appendices/VK_KHR_line_rasterization.adoc new file mode 100644 index 000000000..97134b2ad --- /dev/null +++ b/appendices/VK_KHR_line_rasterization.adoc @@ -0,0 +1,42 @@ +// Copyright 2019-2024 The Khronos Group Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + +include::{generated}/meta/{refprefix}VK_KHR_line_rasterization.adoc[] + +=== Other Extension Metadata + +*Last Modified Date*:: + 2023-06-08 +*IP Status*:: + No known IP claims. +*Contributors*:: + - Jeff Bolz, NVIDIA + - Allen Jensen, NVIDIA + - Faith Ekstrand, Intel + +=== Description + +This extension adds some line rasterization features that are commonly used +in CAD applications and supported in other APIs like OpenGL. +Bresenham-style line rasterization is supported, smooth rectangular lines +(coverage to alpha) are supported, and stippled lines are supported for all +three line rasterization modes. + +include::{generated}/interfaces/VK_KHR_line_rasterization.adoc[] + +=== Issues + +1) Do we need to support Bresenham-style and smooth lines with more than one +rasterization sample? i.e. the equivalent of glDisable(GL_MULTISAMPLE) in +OpenGL when the framebuffer has more than one sample? + +*RESOLVED*: Yes. +For simplicity, Bresenham line rasterization carries forward a few +restrictions from OpenGL, such as not supporting per-sample shading, alpha +to coverage, or alpha to one. + +=== Version History + + * Revision 1, 2019-05-09 (Jeff Bolz) + ** Initial draft diff --git a/appendices/VK_KHR_load_store_op_none.adoc b/appendices/VK_KHR_load_store_op_none.adoc new file mode 100644 index 000000000..586d279ba --- /dev/null +++ b/appendices/VK_KHR_load_store_op_none.adoc @@ -0,0 +1,27 @@ +// Copyright 2023-2024 The Khronos Group Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + +include::{generated}/meta/{refprefix}VK_KHR_load_store_op_none.adoc[] + +=== Other Extension Metadata + +*Last Modified Date*:: + 2023-05-16 +*Contributors*:: + - Shahbaz Youssefi, Google + - Bill Licea-Kane, Qualcomm Technologies, Inc. + - Tobias Hector, AMD + +=== Description + +This extension provides ename:VK_ATTACHMENT_LOAD_OP_NONE_KHR and +ename:VK_ATTACHMENT_STORE_OP_NONE_KHR, which are identically promoted from +the `apiext:VK_EXT_load_store_op_none` extension. + +include::{generated}/interfaces/VK_KHR_load_store_op_none.adoc[] + +=== Version History + + * Revision 1, 2023-05-16 (Shahbaz Youssefi) + ** Initial revision, based on VK_EXT_load_store_op_none. diff --git a/appendices/VK_KHR_shader_expect_assume.adoc b/appendices/VK_KHR_shader_expect_assume.adoc new file mode 100644 index 000000000..9d9ea1c35 --- /dev/null +++ b/appendices/VK_KHR_shader_expect_assume.adoc @@ -0,0 +1,33 @@ +// Copyright 2021-2024 The Khronos Group, Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + +include::{generated}/meta/{refprefix}VK_KHR_shader_expect_assume.adoc[] + +=== Other Extension Metadata + +*Last Modified Date*:: + 2023-12-06 +*IP Status*:: + No known IP claims. +*Contributors*:: + - Kevin Petit, Arm + - Tobias Hector, AMD + - James Fitzpatrick, Imagination Technologies + +=== Description + +This extension allows the use of the `SPV_KHR_expect_assume` extension in +SPIR-V shader modules which enables SPIR-V producers to provide optimization +hints to the Vulkan implementation. + +include::{generated}/interfaces/VK_KHR_shader_expect_assume.adoc[] + +=== New SPIR-V Capabilities + + * <> + +=== Version History + + * Revision 1, 2023-12-06 (Kevin Petit) + ** Initial revision diff --git a/appendices/VK_KHR_shader_float_controls2.adoc b/appendices/VK_KHR_shader_float_controls2.adoc new file mode 100644 index 000000000..7bff61b42 --- /dev/null +++ b/appendices/VK_KHR_shader_float_controls2.adoc @@ -0,0 +1,35 @@ +// Copyright 2017-2024 The Khronos Group Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + +include::{generated}/meta/{refprefix}VK_KHR_shader_float_controls2.adoc[] + +=== Other Extension Metadata + +*Last Modified Date*:: + 2023-05-16 +*Interactions and External Dependencies*:: + - This extension requires + {spirv}/KHR/SPV_KHR_float_controls2.html[`SPV_KHR_float_controls2`]. +*Contributors*:: + - Graeme Leese, Broadcom + +=== Description + +This extension enables use of the more expressive fast floating-point math +flags in the SPV_KHR_float_controls2 extension. +These flags give finer- grained control over which optimisations compilers +may apply, potentially speeding up execution while retaining correct +results. + +The extension also adds control over the fast-math modes to the GLSL +extended instruction set, making these operations more consistent with +SPIR-V and allowing their use in situations where floating-point conformance +is important. + +include::{generated}/interfaces/VK_KHR_shader_float_controls2.adoc[] + +=== Version History + + * Revision 1, 2023-05-16 (Graeme Leese) + ** Initial draft diff --git a/appendices/VK_KHR_shader_maximal_reconvergence.adoc b/appendices/VK_KHR_shader_maximal_reconvergence.adoc new file mode 100644 index 000000000..77b1ea1de --- /dev/null +++ b/appendices/VK_KHR_shader_maximal_reconvergence.adoc @@ -0,0 +1,43 @@ +// Copyright 2024 The Khronos Group Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + +include::{generated}/meta/{refprefix}VK_KHR_shader_maximal_reconvergence.adoc[] + +=== Other Extension Metadata + +*Last Modified Date*:: + 2021-11-12 +*IP Status*:: + No known IP claims. +*Interactions and External Dependencies*:: + - Requires SPIR-V 1.3. + - This extension requires + {spirv}/KHR/SPV_KHR_maximal_reconvergence.html[`SPV_KHR_maximal_reconvergence`] +*Contributors*:: + - Alan Baker, Google + +=== Description + +This extension allows the use of the `SPV_KHR_maximal_reconvergence` SPIR-V +extension in shader modules. +`SPV_KHR_maximal_reconvergence` provides stronger guarantees that diverged +subgroups will reconverge. +These guarantees should match shader author intuition about divergence and +reconvergence of invocations based on the structure of the code in the HLL. + +Developers should utilize this extension if they require stronger guarantees +about reconvergence than either the core spec or +SPV_KHR_subgroup_uniform_control_flow. +This extension will define the rules that govern how invocations diverge and +reconverge in a way that should match developer intuition. +It allows robust programs to be written relying on subgroup operations and +other tangled instructions. + +include::{generated}/interfaces/VK_KHR_shader_maximal_reconvergence.adoc[] + +=== Version History + +* Revision 1, 2021-11-12 (Alan Baker) + - Internal draft version + diff --git a/appendices/VK_KHR_shader_quad_control.adoc b/appendices/VK_KHR_shader_quad_control.adoc new file mode 100644 index 000000000..69e771b6a --- /dev/null +++ b/appendices/VK_KHR_shader_quad_control.adoc @@ -0,0 +1,36 @@ +// Copyright 2020-2024 The Khronos Group Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + +include::{generated}/meta/{refprefix}VK_KHR_shader_quad_control.adoc[] + +=== Other Extension Metadata + +*Last Modified Date*:: + 2023-11-01 +*IP Status*:: + No known IP claims. +*Contributors*:: + - Tobias Hector, AMD + - Bill Licea-Kane, Qualcomm + - Graeme Leese, Broadcom + - Jan-Harald Fredriksen, Arm + - Nicolai Hähnle, AMD + - Jeff Bolz, NVidia + - Alan Baker, Google + - Hans-Kristian Arntzen, Valve + + +=== Description + +This extension adds new quad any/all operations, requires that derivatives +are well-defined in quad-uniform control flow, and adds the ability to +require helper invocations participate in group operations. + +include::{generated}/interfaces/VK_KHR_shader_quad_control.adoc[] + + +=== Version History + + * Revision 1, 2023-11-01 (Tobias Hector) + ** Initial draft diff --git a/appendices/VK_KHR_shader_subgroup_rotate.adoc b/appendices/VK_KHR_shader_subgroup_rotate.adoc new file mode 100644 index 000000000..bf372ac79 --- /dev/null +++ b/appendices/VK_KHR_shader_subgroup_rotate.adoc @@ -0,0 +1,32 @@ +// Copyright (c) 2021-2023 Khronos Group. +// +// SPDX-License-Identifier: CC-BY-4.0 + +include::{generated}/meta/{refprefix}VK_KHR_shader_subgroup_rotate.adoc[] + +*Last Modified Date*:: + 2023-06-20 +*IP Status*:: + No known IP claims. +*Contributors*:: + - Kévin Petit, Arm Ltd. + - Tobias Hector, AMD + - John Leech, Khronos + - Matthew Netsch, Qualcomm + - Jan-Harald Fredriksen, Arm Ltd. + - Graeme Leese, Broadcom + - Tom Olson, Arm Ltd. + +This extension adds support for the subgroup rotate instruction defined in +SPV_KHR_subgroup_rotate. + +include::{generated}/interfaces/VK_KHR_shader_subgroup_rotate.adoc[] + +=== New SPIR-V Capabilities + + * <> + +=== Version History + + * Revision 1, 2023-06-20 (Kévin Petit) + ** Initial revision diff --git a/appendices/roadmap.adoc b/appendices/roadmap.adoc index d642f4ca5..6c9e7a70b 100644 --- a/appendices/roadmap.adoc +++ b/appendices/roadmap.adoc @@ -14,3 +14,5 @@ and formats across these devices, and should be supported by all such new hardware shipping by the end of the target year or shortly thereafter. include::{appendices}/roadmap/Roadmap-2022.adoc[] + +include::{appendices}/roadmap/Roadmap-2024.adoc[] diff --git a/appendices/roadmap/Roadmap-2024.adoc b/appendices/roadmap/Roadmap-2024.adoc new file mode 100644 index 000000000..e03b2f64b --- /dev/null +++ b/appendices/roadmap/Roadmap-2024.adoc @@ -0,0 +1,81 @@ +// Copyright 2023-2024 The Khronos Group Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + + +[[roadmap-2024]] +== Roadmap 2024 + +The Roadmap 2024 milestone is intended to be supported by newer mid-to-high-end devices shipping in 2024 or shortly thereafter across mainstream smartphone, tablet, laptops, console and desktop devices. + +Two of the core aims of this roadmap profile are to enable developers to rely on a number of important rasterization and shader features have been available for a long time, but until now have not enjoyed wide support. + +Shader features required include smaller types (<> and <>), reconvergence guarantees for subgroup ops (apiext:VK_KHR_shader_maximal_reconvergence and apiext:VK_KHR_shader_quad_control), and more consistent floating point handling (apiext:VK_KHR_shader_float_controls2 and <>). +Rasterization features include requiring support for multi-draw indirect, shader draw parameters, 8-bit indices, better line rasterization definitions, and local reads when using dynamic rendering. +A few other features have been added opportunistically, in lieu of shipping a Vulkan 1.4 in the same time frame, such as <> and the various minor improvements included in apiext:VK_KHR_maintenance5. + + +=== Required Profiles + +This profile requires the Roadmap 2022 profile. + + +=== Required Features + +The following core optional features are required to be supported: + +* Vulkan 1.0 Optional Features +** <> +** <> +** <> + +* Vulkan 1.1 Optional Features +** <> +** <> + +* Vulkan 1.2 Optional Features +** <> +** <> +** <> + + +=== Required Limits + +The following core increased limits are required: + +.Vulkan 1.0 Limits +[width="100%",cols="<35,<9,<14,<14,<11",options="header"] +|==== +| Limit Name | Unsupported Limit | Core Limit | Profile Limit | Limit Type^1^ +| pname:maxBoundDescriptorSets | - | 4 | 7 | min +| pname:maxColorAttachments | - | 4 | 8 | min +| pname:timestampComputeAndGraphics | - | FALSE | TRUE | Boolean +|==== + +.Vulkan 1.2 Limits +[width="100%",cols="<35,<9,<14,<14,<11",options="header"] +|==== +| Limit Name | Unsupported Limit | Core Limit | Profile Limit | Limit Type^1^ +| pname:shaderRoundingModeRTEFloat16 | - | FALSE | TRUE | Boolean +| pname:shaderRoundingModeRTEFloat32 | - | FALSE | TRUE | Boolean +|==== + + +=== Required extensions + +The following extensions are required: + + * apiext:VK_KHR_dynamic_rendering_local_read + * apiext:VK_KHR_load_store_op_none + * apiext:VK_KHR_shader_quad_control + * apiext:VK_KHR_shader_maximal_reconvergence + * apiext:VK_KHR_shader_subgroup_uniform_control_flow + * apiext:VK_KHR_shader_subgroup_rotate + * apiext:VK_KHR_shader_float_controls2 + * apiext:VK_KHR_shader_expect_assume + * apiext:VK_KHR_line_rasterization + * apiext:VK_KHR_vertex_attribute_divisor + * apiext:VK_KHR_index_type_uint8 + * apiext:VK_KHR_map_memory2 + * apiext:VK_KHR_maintenance5 + * apiext:VK_KHR_push_descriptor diff --git a/appendices/spirvenv.adoc b/appendices/spirvenv.adoc index 5284bf24d..861c395ce 100644 --- a/appendices/spirvenv.adoc +++ b/appendices/spirvenv.adoc @@ -380,6 +380,10 @@ or knowledge of runtime information, such as enabled features. * [[VUID-{refpage}-Component-07703]] The code:Component decorations must: not be used for a 64-bit vector type with more than two components + * [[VUID-{refpage}-Input-09557]] + The pointers of any code:Input or code:Output + <> must: + not contain any code:PhysicalStorageBuffer {StorageClass} pointers * [[VUID-{refpage}-GLSLShared-04669]] The code:GLSLShared and code:GLSLPacked decorations must: not be used * [[VUID-{refpage}-Flat-04670]] @@ -742,6 +746,16 @@ ifndef::VK_VERSION_1_3,VK_KHR_format_feature_flags2[] operand of 2 and an "`Image Format`" operand of code:Unknown must: be decorated with code:NonReadable endif::VK_VERSION_1_3,VK_KHR_format_feature_flags2[] + * [[VUID-{refpage}-None-09558]] + {empty} +ifdef::VK_KHR_dynamic_rendering_local_read[] + If <> is not enabled, any +endif::VK_KHR_dynamic_rendering_local_read[] +ifndef::VK_KHR_dynamic_rendering_local_read[Any] + variable created with a "`Type`" of code:OpTypeImage that has a "`Dim`" + operand of code:SubpassData must: be decorated with + code:InputAttachmentIndex ifdef::VK_VERSION_1_3[] ifndef::VK_KHR_format_feature_flags2[] * [[VUID-{refpage}-apiVersion-07952]] @@ -1043,6 +1057,41 @@ ifdef::VK_VERSION_1_2,VK_KHR_shader_float_controls[] pname:shaderRoundingModeRTZFloat64>> is ename:VK_FALSE, then code:RoundingModeRTZ for 64-bit floating-point type must: not be used endif::VK_VERSION_1_2,VK_KHR_shader_float_controls[] +ifdef::VK_KHR_shader_float_controls2[] + * [[VUID-{refpage}-shaderSignedZeroInfNanPreserveFloat16-09559]] + If <> is ename:VK_FALSE then any + code:FPFastMathDefault execution mode with a type of 16-bit float must: + include the code:NSZ, code:NotInf, and code:NotNaN flags. + * [[VUID-{refpage}-shaderSignedZeroInfNanPreserveFloat16-09560]] + If <> is ename:VK_FALSE then any + code:FPFastMath decoration on an instruction with result type or any + operand type that includes a 16-bit float must: include the code:NSZ, + code:NotInf, and code:NotNaN flags. + * [[VUID-{refpage}-shaderSignedZeroInfNanPreserveFloat32-09561]] + If <> is ename:VK_FALSE then any + code:FPFastMathDefault execution mode with a type of 32-bit float must: + include the code:NSZ, code:NotInf, and code:NotNaN flags. + * [[VUID-{refpage}-shaderSignedZeroInfNanPreserveFloat32-09562]] + If <> is ename:VK_FALSE then any + code:FPFastMath decoration on an instruction with result type or any + operand type that includes a 32-bit float must: include the code:NSZ, + code:NotInf, and code:NotNaN flags. + * [[VUID-{refpage}-shaderSignedZeroInfNanPreserveFloat64-09563]] + If <> is ename:VK_FALSE then any + code:FPFastMathDefault execution mode with a type of 64-bit float must: + include the code:NSZ, code:NotInf, and code:NotNaN flags. + * [[VUID-{refpage}-shaderSignedZeroInfNanPreserveFloat64-09564]] + If <> is ename:VK_FALSE then any + code:FPFastMath decoration on an instruction with result type or any + operand type that includes a 64-bit float must: include the code:NSZ, + code:NotInf, and code:NotNaN flags. +endif::VK_KHR_shader_float_controls2[] ifdef::VK_EXT_transform_feedback[] * [[VUID-{refpage}-Offset-06308]] The code:Offset plus size of the type of each variable, in the output @@ -2041,7 +2090,19 @@ ifdef::VK_QCOM_image_processing2[] asampler object that included slink:VkSamplerBlockMatchWindowCreateInfoQCOM in the pname:pNext chain. endif::VK_QCOM_image_processing2[] - +ifdef:VK_KHR_shader_maximal_reconvergence[] + * [[VUID-{refpage}-MaximallyReconvergesKHR-09565]] + The execution mode code:MaximallyReconvergesKHR must: not be applied to + an entry point unless the entry point does not execute any + <>. +endif:VK_KHR_shader_maximal_reconvergence[] +ifdef::VK_KHR_shader_subgroup_rotate[] + * [[VUID-{refpage}-shaderSubgroupRotateClustered-09566]] + If <> is ename:VK_FALSE, then the + code:ClusterSize operand to code:OpGroupNonUniformRotateKHR must: not be + used. +endif::VK_KHR_shader_subgroup_rotate[] **** -- @@ -2061,6 +2122,32 @@ point instructions: are never raised. Signaling [eq]##NaN## may: be converted to quiet [eq]##NaN##s values by any floating point instruction. +ifdef::VK_KHR_shader_float_controls2[] + * The floating-point environment used for an instruction can be determined + as follows: + ** If the SPIR-V specifies it explicitly using the code:FPFastMath + decoration or code:FPFastMathDefault {ExecutionMode} then that is used. + ** If the environment is not specified in the SPIR-V then it is determined + as follows: + *** If the operation is not decorated code:NoContraction then the flags + code:AllowContract, code:AllowReassoc, code:AllowRecip, and + code:AllowTransform are assumed. + *** If any of the following conditions are true then the flags code:NSZ, + code:NotInf, and code:NotNaN are assumed: + **** The entry point does not use the {ExecutionMode} + code:SignedZeroInfNanPreserve with a bit-width corresponding to one + of the operands or to the result type. + **** The operation is not one of: code:OpPhi, code:OpSelect, + code:OpReturnValue, code:OpVectorExtractDynamic, + code:OpVectorInsertDynamic, code:OpVectorShuffle, + code:OpCompositeConstruct, code:OpCompositeExtract, + code:OpCompositeInsert, code:OpCopyObject, code:OpTranspose, + code:OpFConvert, code:OpFNegate, code:OpFAdd, code:OpFSub, + code:OpFMul, code:OpStore, code:OpLoad. + **** The operation is an code:OpLoad from the code:Input {StorageClass} in + the fragment shader stage. +endif::VK_KHR_shader_float_controls2[] +ifndef::VK_KHR_shader_float_controls2[] * By default, the implementation may: perform optimizations on half, single, or double-precision floating-point instructions that ignore sign of a zero, or assume that arguments and results are not NaNs or @@ -2083,6 +2170,7 @@ ifdef::VK_VERSION_1_2,VK_KHR_shader_float_controls[] Other SPIR-V instructions may: also respect the code:SignedZeroInfNanPreserve {ExecutionMode}. endif::VK_VERSION_1_2,VK_KHR_shader_float_controls[] +endif::VK_KHR_shader_float_controls2[] * The following instructions must: not flush denormalized values: code:OpConstant, code:OpConstantComposite, code:OpSpecConstant, code:OpSpecConstantComposite, code:OpLoad, code:OpStore, code:OpBitcast, diff --git a/chapters/VK_AMD_shader_info.adoc b/chapters/VK_AMD_shader_info.adoc index 9c146bb27..fcfafc787 100644 --- a/chapters/VK_AMD_shader_info.adoc +++ b/chapters/VK_AMD_shader_info.adoc @@ -49,7 +49,7 @@ device resources used by that shader along with other miscellaneous information and is described in further detail below. For pname:infoType ename:VK_SHADER_INFO_TYPE_DISASSEMBLY_AMD, pname:pInfo is -a pointer to a UTF-8 null-terminated string containing human-readable +a pointer to a null-terminated UTF-8 string containing human-readable disassembly. The exact formatting and contents of the disassembly string are vendor-specific. diff --git a/chapters/VK_EXT_debug_report.adoc b/chapters/VK_EXT_debug_report.adoc index 00802e729..454642c1e 100644 --- a/chapters/VK_EXT_debug_report.adoc +++ b/chapters/VK_EXT_debug_report.adoc @@ -133,10 +133,10 @@ include::{generated}/api/funcpointers/PFN_vkDebugReportCallbackEXT.adoc[] This is an optional: value. * pname:messageCode is a layer-defined value indicating what test triggered this callback. - * pname:pLayerPrefix is a null-terminated string that is an abbreviation - of the name of the component making the callback. + * pname:pLayerPrefix is a null-terminated UTF-8 string that is an + abbreviation of the name of the component making the callback. pname:pLayerPrefix is only valid for the duration of the callback. - * pname:pMessage is a null-terminated string detailing the trigger + * pname:pMessage is a null-terminated UTF-8 string detailing the trigger conditions. pname:pMessage is only valid for the duration of the callback. * pname:pUserData is the user data given when the @@ -246,7 +246,7 @@ include::{generated}/api/protos/vkDebugReportMessageEXT.adoc[] * pname:messageCode is an application defined value. * pname:pLayerPrefix is the abbreviation of the component making this event/message. - * pname:pMessage is a null-terminated string detailing the trigger + * pname:pMessage is a null-terminated UTF-8 string detailing the trigger conditions. The call will propagate through the layers and generate callback(s) as diff --git a/chapters/VK_EXT_debug_utils.adoc b/chapters/VK_EXT_debug_utils.adoc index 17a23c77b..97fd5e19a 100644 --- a/chapters/VK_EXT_debug_utils.adoc +++ b/chapters/VK_EXT_debug_utils.adoc @@ -489,13 +489,6 @@ Vulkan call. A callback can: be called from multiple threads simultaneously (if the application is making Vulkan calls from multiple threads). -.Valid Usage -**** - * [[VUID-VkDebugUtilsMessengerCreateInfoEXT-pfnUserCallback-01914]] - pname:pfnUserCallback must: be a valid - tlink:PFN_vkDebugUtilsMessengerCallbackEXT -**** - include::{generated}/validity/structs/VkDebugUtilsMessengerCreateInfoEXT.adoc[] -- @@ -638,8 +631,9 @@ include::{generated}/api/structs/VkDebugUtilsMessengerCallbackDataEXT.adoc[] * pname:pNext is `NULL` or a pointer to a structure extending this structure. * pname:flags is `0` and is reserved for future use. - * pname:pMessageIdName is a null-terminated string that identifies the - particular message ID that is associated with the provided message. + * pname:pMessageIdName is `NULL` or a null-terminated UTF-8 string that + identifies the particular message ID that is associated with the + provided message. If the message corresponds to a validation layer message, then this string may contain the portion of the Vulkan specification that is believed to have been violated. @@ -647,8 +641,12 @@ include::{generated}/api/structs/VkDebugUtilsMessengerCallbackDataEXT.adoc[] If the message corresponds to a validation layer message, then this number is related to the internal number associated with the message being triggered. - * pname:pMessage is a null-terminated string detailing the trigger - conditions. + * pname:pMessage is +ifdef::VK_EXT_device_address_binding_report[] + `NULL` if pname:messageTypes is equal to + ename:VK_DEBUG_UTILS_MESSAGE_TYPE_DEVICE_ADDRESS_BINDING_BIT_EXT, or +endif::VK_EXT_device_address_binding_report[] + a null-terminated UTF-8 string detailing the trigger conditions. * pname:queueLabelCount is a count of items contained in the pname:pQueueLabels array. * pname:pQueueLabels is `NULL` or a pointer to an array of @@ -743,7 +741,7 @@ submit a debug message with the following properties: * pname:messageSeverity equal to ename:VK_DEBUG_UTILS_MESSAGE_SEVERITY_INFO_BIT_EXT - * pname:messageType equal to + * pname:messageTypes equal to ename:VK_DEBUG_UTILS_MESSAGE_TYPE_DEVICE_ADDRESS_BINDING_BIT_EXT * sname:VkDebugUtilsMessengerCallbackDataEXT::pname:pObjects must: identify the associated Vulkan object diff --git a/chapters/VK_NV_device_generated_commands/generation.adoc b/chapters/VK_NV_device_generated_commands/generation.adoc index 40f1a47cf..ac5519e92 100644 --- a/chapters/VK_NV_device_generated_commands/generation.adoc +++ b/chapters/VK_NV_device_generated_commands/generation.adoc @@ -78,7 +78,7 @@ ifdef::VK_NV_device_generated_commands_compute[] ename:VK_PIPELINE_BIND_POINT_COMPUTE, and the pname:indirectCommandsLayout contains a ename:VK_INDIRECT_COMMANDS_TOKEN_TYPE_PIPELINE_NV token, then the - pname:pipeline must: be `NULL` + pname:pipeline must: be dlink:VK_NULL_HANDLE endif::VK_NV_device_generated_commands_compute[] **** diff --git a/chapters/accelstructures.adoc b/chapters/accelstructures.adoc index 6ea83f140..b9f6cc7f1 100644 --- a/chapters/accelstructures.adoc +++ b/chapters/accelstructures.adoc @@ -456,8 +456,6 @@ include::{chapters}/commonvalidity/build_acceleration_structure_device_common.ad `4` * [[VUID-vkCmdBuildAccelerationStructuresIndirectKHR-pIndirectStrides-03787]] Each element of pname:pIndirectStrides must: be a multiple of `4` - * [[VUID-vkCmdBuildAccelerationStructuresIndirectKHR-commandBuffer-03649]] - pname:commandBuffer must: not be a protected command buffer * [[VUID-vkCmdBuildAccelerationStructuresIndirectKHR-pIndirectDeviceAddresses-03651]] Each slink:VkAccelerationStructureBuildRangeInfoKHR structure referenced by any element of pname:pIndirectDeviceAddresses must: be a valid @@ -965,6 +963,11 @@ the sum of matching pname:count provided. .Valid Usage **** + * [[VUID-VkAccelerationStructureTrianglesDisplacementMicromapNV-displacementBiasAndScaleFormat-09501]] + pname:displacementBiasAndScaleFormat must: not be + ename:VK_FORMAT_UNDEFINED + * [[VUID-VkAccelerationStructureTrianglesDisplacementMicromapNV-displacementVectorFormat-09502]] + pname:displacementVectorFormat must: not be ename:VK_FORMAT_UNDEFINED * [[VUID-VkAccelerationStructureTrianglesDisplacementMicromapNV-pUsageCounts-07992]] Only one of pname:pUsageCounts or pname:ppUsageCounts can: be a valid pointer, the other must: be `NULL` diff --git a/chapters/clears.adoc b/chapters/clears.adoc index c39bbd435..ffd327d30 100644 --- a/chapters/clears.adoc +++ b/chapters/clears.adoc @@ -360,6 +360,13 @@ ifdef::VK_VERSION_1_1,VK_KHR_multiview[] If the render pass instance this is recorded in uses multiview, then pname:baseArrayLayer must: be zero and pname:layerCount must: be one endif::VK_VERSION_1_1,VK_KHR_multiview[] +ifdef::VK_KHR_dynamic_rendering_local_read[] + * [[VUID-vkCmdClearAttachments-colorAttachment-09503]] + The pname:colorAttachment member of each element of pname:pAttachments + must: not identify a color attachment that is currently mapped to + ename:VK_ATTACHMENT_UNUSED in pname:commandBuffer via + slink:VkRenderingAttachmentLocationInfoKHR +endif::VK_KHR_dynamic_rendering_local_read[] ifdef::VK_ANDROID_external_format_resolve[] * [[VUID-vkCmdClearAttachments-aspectMask-09298]] If the subpass this is recorded in performs an external format resolve, diff --git a/chapters/cmdbuffers.adoc b/chapters/cmdbuffers.adoc index 8570bc96b..b9ea3e35e 100644 --- a/chapters/cmdbuffers.adoc +++ b/chapters/cmdbuffers.adoc @@ -3239,6 +3239,22 @@ ifdef::VK_EXT_nested_command_buffer[] element of pname:pCommandBuffers must: not have been recorded with ename:VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT endif::VK_EXT_nested_command_buffer[] +ifdef::VK_VERSION_1_3,VK_KHR_dynamic_rendering[] +ifdef::VK_KHR_dynamic_rendering_local_read[] + * [[VUID-vkCmdExecuteCommands-pCommandBuffers-09504]] + If fname:vkCmdExecuteCommands is being called within a render pass + instance begun with flink:vkCmdBeginRendering, the color attachment + mapping state specified by slink:VkRenderingAttachmentLocationInfoKHR in + the inheritance info of each element of pname:pCommandBuffers and in the + current state of pname:commandBuffer must: match + * [[VUID-vkCmdExecuteCommands-pCommandBuffers-09505]] + If fname:vkCmdExecuteCommands is being called within a render pass + instance begun with flink:vkCmdBeginRendering, the input attachment + mapping state specified by slink:VkRenderingInputAttachmentIndexInfoKHR + in the inheritance info of each element of pname:pCommandBuffers and in + the current state of pname:commandBuffer must: match +endif::VK_KHR_dynamic_rendering_local_read[] +endif::VK_VERSION_1_3,VK_KHR_dynamic_rendering[] **** include::{generated}/validity/protos/vkCmdExecuteCommands.adoc[] diff --git a/chapters/commonvalidity/attachment_description_common.adoc b/chapters/commonvalidity/attachment_description_common.adoc index 1053bcb90..b021013d8 100644 --- a/chapters/commonvalidity/attachment_description_common.adoc +++ b/chapters/commonvalidity/attachment_description_common.adoc @@ -114,4 +114,16 @@ endif::VK_EXT_attachment_feedback_loop_layout[] set in pname:imageCreateSampleCounts (as defined in <>) for the given pname:format +ifdef::VK_KHR_dynamic_rendering_local_read[] + * [[VUID-{refpage}-dynamicRenderingLocalRead-09544]] + If the <> feature is not enabled, + pname:initialLayout must: not be + ename:VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR + * [[VUID-{refpage}-dynamicRenderingLocalRead-09545]] + If the <> feature is not enabled, + pname:finalLayout must: not be + ename:VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR +endif::VK_KHR_dynamic_rendering_local_read[] // Common Valid Usage diff --git a/chapters/commonvalidity/attachment_reference_common.adoc b/chapters/commonvalidity/attachment_reference_common.adoc index cd32c33bf..eb173cf83 100644 --- a/chapters/commonvalidity/attachment_reference_common.adoc +++ b/chapters/commonvalidity/attachment_reference_common.adoc @@ -33,4 +33,10 @@ ifdef::VK_EXT_attachment_feedback_loop_layout[] pname:layout must: not be ename:VK_IMAGE_LAYOUT_ATTACHMENT_FEEDBACK_LOOP_OPTIMAL_EXT endif::VK_EXT_attachment_feedback_loop_layout[] +ifdef::VK_KHR_dynamic_rendering_local_read[] + * [[VUID-{refpage}-dynamicRenderingLocalRead-09546]] + If the <> feature is not enabled, pname:layout + must: not be ename:VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR +endif::VK_KHR_dynamic_rendering_local_read[] // Common Valid Usage diff --git a/chapters/commonvalidity/bind_index_buffer_common.adoc b/chapters/commonvalidity/bind_index_buffer_common.adoc index 8e3af8761..42d05a79c 100644 --- a/chapters/commonvalidity/bind_index_buffer_common.adoc +++ b/chapters/commonvalidity/bind_index_buffer_common.adoc @@ -19,12 +19,12 @@ ifdef::VK_NV_ray_tracing,VK_KHR_acceleration_structure[] * [[VUID-{refpage}-indexType-08786]] pname:indexType must: not be ename:VK_INDEX_TYPE_NONE_KHR endif::VK_NV_ray_tracing,VK_KHR_acceleration_structure[] -ifdef::VK_EXT_index_type_uint8[] +ifdef::VK_KHR_index_type_uint8,VK_EXT_index_type_uint8[] * [[VUID-{refpage}-indexType-08787]] - If pname:indexType is ename:VK_INDEX_TYPE_UINT8_EXT, the + If pname:indexType is ename:VK_INDEX_TYPE_UINT8_KHR, the <> feature must: be enabled -endif::VK_EXT_index_type_uint8[] +endif::VK_KHR_index_type_uint8,VK_EXT_index_type_uint8[] * [[VUID-{refpage}-None-09493]] {empty} ifdef::VK_KHR_maintenance6+VK_EXT_robustness2[] diff --git a/chapters/commonvalidity/buffer_usage_flags_common.adoc b/chapters/commonvalidity/buffer_usage_flags_common.adoc index f921e8eac..e2f370aa5 100644 --- a/chapters/commonvalidity/buffer_usage_flags_common.adoc +++ b/chapters/commonvalidity/buffer_usage_flags_common.adoc @@ -10,7 +10,7 @@ ifdef::VK_KHR_maintenance5[] If the pname:pNext chain does not include a slink:VkBufferUsageFlags2CreateInfoKHR structure, endif::VK_KHR_maintenance5[] - pname:usage: must be a valid combination of elink:VkBufferUsageFlagBits + pname:usage must be a valid combination of elink:VkBufferUsageFlagBits values * [[VUID-{refpage}-None-09500]] {empty} @@ -18,5 +18,5 @@ ifdef::VK_KHR_maintenance5[] If the pname:pNext chain does not include a slink:VkBufferUsageFlags2CreateInfoKHR structure, endif::VK_KHR_maintenance5[] - pname:usage: must not be 0 + pname:usage must not be 0 // Common Valid Usage diff --git a/chapters/commonvalidity/build_acceleration_structure_device_common.adoc b/chapters/commonvalidity/build_acceleration_structure_device_common.adoc index 4e73c5fae..f581b28f0 100644 --- a/chapters/commonvalidity/build_acceleration_structure_device_common.adoc +++ b/chapters/commonvalidity/build_acceleration_structure_device_common.adoc @@ -186,4 +186,6 @@ value in pname:geometry.instances.data.deviceAddress must: be a valid device address containing a value obtained from flink:vkGetAccelerationStructureDeviceAddressKHR or `0` + * [[VUID-{refpage}-commandBuffer-09547]] + pname:commandBuffer must: not be a protected command buffer // Common Valid Usage diff --git a/chapters/commonvalidity/deferred_operations_common.adoc b/chapters/commonvalidity/deferred_operations_common.adoc index 85295e522..9739de15f 100644 --- a/chapters/commonvalidity/deferred_operations_common.adoc +++ b/chapters/commonvalidity/deferred_operations_common.adoc @@ -4,9 +4,6 @@ // Common Valid Usage // Common to commands including a deferredOperation parameter - * [[VUID-{refpage}-deferredOperation-03677]] - If pname:deferredOperation is not dlink:VK_NULL_HANDLE, it must: be a - valid slink:VkDeferredOperationKHR object * [[VUID-{refpage}-deferredOperation-03678]] Any previous deferred operation that was associated with pname:deferredOperation must: be complete diff --git a/chapters/commonvalidity/draw_common.adoc b/chapters/commonvalidity/draw_common.adoc index 4fd91e91c..18a9aa524 100644 --- a/chapters/commonvalidity/draw_common.adoc +++ b/chapters/commonvalidity/draw_common.adoc @@ -1613,7 +1613,7 @@ ifdef::VK_EXT_shader_object[] been called in the current command buffer prior to this drawing command endif::VK_EXT_shader_object[] endif::VK_EXT_provoking_vertex[] -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] ifdef::VK_EXT_extended_dynamic_state3[] * [[VUID-{refpage}-None-07637]] If the bound graphics pipeline state was created with the @@ -1623,27 +1623,29 @@ ifdef::VK_EXT_extended_dynamic_state3[] endif::VK_EXT_extended_dynamic_state3[] ifdef::VK_EXT_shader_object[] * [[VUID-{refpage}-None-08666]] - If the `apiext:VK_EXT_line_rasterization` extension is enabled, and a - shader object is bound to any graphics stage, and the most recent call - to flink:vkCmdSetRasterizerDiscardEnable in the current command buffer - set pname:rasterizerDiscardEnable to ename:VK_FALSE, and the most recent + If the `apiext:VK_KHR_line_rasterization` or + `apiext:VK_EXT_line_rasterization` extension is enabled, and a shader + object is bound to any graphics stage, and the most recent call to + flink:vkCmdSetRasterizerDiscardEnable in the current command buffer set + pname:rasterizerDiscardEnable to ename:VK_FALSE, and the most recent call to flink:vkCmdSetPolygonModeEXT in the current command buffer set pname:polygonMode to ename:VK_POLYGON_MODE_LINE, then flink:vkCmdSetLineRasterizationModeEXT must: have been called in the current command buffer prior to this drawing command * [[VUID-{refpage}-None-08667]] - If the `apiext:VK_EXT_line_rasterization` extension is enabled, and a - shader object is bound to the ename:VK_SHADER_STAGE_VERTEX_BIT stage, - and the most recent call to flink:vkCmdSetRasterizerDiscardEnable in the - current command buffer set pname:rasterizerDiscardEnable to - ename:VK_FALSE, and the most recent call to - flink:vkCmdSetPrimitiveTopology in the current command buffer set - pname:primitiveTopology to any line topology, then + If the `apiext:VK_KHR_line_rasterization` or + `apiext:VK_EXT_line_rasterization` extension is enabled, and a shader + object is bound to the ename:VK_SHADER_STAGE_VERTEX_BIT stage, and the + most recent call to flink:vkCmdSetRasterizerDiscardEnable in the current + command buffer set pname:rasterizerDiscardEnable to ename:VK_FALSE, and + the most recent call to flink:vkCmdSetPrimitiveTopology in the current + command buffer set pname:primitiveTopology to any line topology, then flink:vkCmdSetLineRasterizationModeEXT must: have been called in the current command buffer prior to this drawing command * [[VUID-{refpage}-None-08668]] - If the `apiext:VK_EXT_line_rasterization` extension is enabled, and a - shader object that outputs line primitives is bound to the + If the `apiext:VK_KHR_line_rasterization` or + `apiext:VK_EXT_line_rasterization` extension is enabled, and a shader + object that outputs line primitives is bound to the ename:VK_SHADER_STAGE_TESSELLATION_EVALUATION_BIT or ename:VK_SHADER_STAGE_GEOMETRY_BIT stage, and the most recent call to flink:vkCmdSetRasterizerDiscardEnable in the current command buffer set @@ -1660,27 +1662,29 @@ ifdef::VK_EXT_extended_dynamic_state3[] endif::VK_EXT_extended_dynamic_state3[] ifdef::VK_EXT_shader_object[] * [[VUID-{refpage}-None-08669]] - If the `apiext:VK_EXT_line_rasterization` extension is enabled, and a - shader object is bound to any graphics stage, and the most recent call - to flink:vkCmdSetRasterizerDiscardEnable in the current command buffer - set pname:rasterizerDiscardEnable to ename:VK_FALSE, and the most recent + If the `apiext:VK_KHR_line_rasterization` or + `apiext:VK_EXT_line_rasterization` extension is enabled, and a shader + object is bound to any graphics stage, and the most recent call to + flink:vkCmdSetRasterizerDiscardEnable in the current command buffer set + pname:rasterizerDiscardEnable to ename:VK_FALSE, and the most recent call to flink:vkCmdSetPolygonModeEXT in the current command buffer set pname:polygonMode to ename:VK_POLYGON_MODE_LINE, then flink:vkCmdSetLineStippleEnableEXT must: have been called in the current command buffer prior to this drawing command * [[VUID-{refpage}-None-08670]] - If the `apiext:VK_EXT_line_rasterization` extension is enabled, and a - shader object is bound to the ename:VK_SHADER_STAGE_VERTEX_BIT stage, - and the most recent call to flink:vkCmdSetRasterizerDiscardEnable in the - current command buffer set pname:rasterizerDiscardEnable to - ename:VK_FALSE, and the most recent call to - flink:vkCmdSetPrimitiveTopology in the current command buffer set - pname:primitiveTopology to any line topology, then + If the `apiext:VK_KHR_line_rasterization` or + `apiext:VK_EXT_line_rasterization` extension is enabled, and a shader + object is bound to the ename:VK_SHADER_STAGE_VERTEX_BIT stage, and the + most recent call to flink:vkCmdSetRasterizerDiscardEnable in the current + command buffer set pname:rasterizerDiscardEnable to ename:VK_FALSE, and + the most recent call to flink:vkCmdSetPrimitiveTopology in the current + command buffer set pname:primitiveTopology to any line topology, then flink:vkCmdSetLineStippleEnableEXT must: have been called in the current command buffer prior to this drawing command * [[VUID-{refpage}-None-08671]] - If the `apiext:VK_EXT_line_rasterization` extension is enabled, and a - shader object that outputs line primitives is bound to the + If the `apiext:VK_KHR_line_rasterization` or + `apiext:VK_EXT_line_rasterization` extension is enabled, and a shader + object that outputs line primitives is bound to the ename:VK_SHADER_STAGE_TESSELLATION_EVALUATION_BIT or ename:VK_SHADER_STAGE_GEOMETRY_BIT stage, and the most recent call to flink:vkCmdSetRasterizerDiscardEnable in the current command buffer set @@ -1688,25 +1692,28 @@ ifdef::VK_EXT_shader_object[] flink:vkCmdSetLineStippleEnableEXT must: have been called in the current command buffer prior to this drawing command endif::VK_EXT_shader_object[] -ifdef::VK_EXT_extended_dynamic_state3[] * [[VUID-{refpage}-None-07849]] If the bound graphics pipeline state was created with the - ename:VK_DYNAMIC_STATE_LINE_STIPPLE_EXT dynamic state enabled then - flink:vkCmdSetLineStippleEXT must: have been called in the current - command buffer prior to this drawing command -endif::VK_EXT_extended_dynamic_state3[] +ifdef::VK_KHR_line_rasterization[ename:VK_DYNAMIC_STATE_LINE_STIPPLE_KHR] +ifndef::VK_KHR_line_rasterization[ename:VK_DYNAMIC_STATE_LINE_STIPPLE_EXT] + dynamic state enabled then +ifdef::VK_KHR_line_rasterization[flink:vkCmdSetLineStippleKHR] +ifndef::VK_KHR_line_rasterization[flink:vkCmdSetLineStippleEXT] + must: have been called in the current command buffer prior to this + drawing command ifdef::VK_EXT_shader_object[] * [[VUID-{refpage}-None-08672]] - If the `apiext:VK_EXT_line_rasterization` extension is enabled, and a - shader object is bound to any graphics stage, and the most recent call - to flink:vkCmdSetRasterizerDiscardEnable in the current command buffer - set pname:rasterizerDiscardEnable to ename:VK_FALSE, and the most recent + If the `apiext:VK_KHR_line_rasterization` or + `apiext:VK_EXT_line_rasterization` extension is enabled, and a shader + object is bound to any graphics stage, and the most recent call to + flink:vkCmdSetRasterizerDiscardEnable in the current command buffer set + pname:rasterizerDiscardEnable to ename:VK_FALSE, and the most recent call to flink:vkCmdSetLineStippleEnableEXT in the current command buffer set pname:stippledLineEnable to ename:VK_TRUE, then flink:vkCmdSetLineStippleEXT must: have been called in the current command buffer prior to this drawing command endif::VK_EXT_shader_object[] -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] ifdef::VK_EXT_depth_clip_control[] ifdef::VK_EXT_extended_dynamic_state3[] * [[VUID-{refpage}-None-07639]] @@ -2266,14 +2273,14 @@ ifdef::VK_NV_framebuffer_mixed_samples[] color samples, then the pipeline pname:sampleShadingEnable must: be ename:VK_FALSE endif::VK_NV_framebuffer_mixed_samples[] -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] * [[VUID-{refpage}-stippledLineEnable-07495]] If the bound graphics pipeline state was created with the ename:VK_DYNAMIC_STATE_LINE_STIPPLE_ENABLE_EXT or ename:VK_DYNAMIC_STATE_LINE_RASTERIZATION_MODE_EXT dynamic states enabled, and if the current pname:stippledLineEnable state is ename:VK_TRUE and the current pname:lineRasterizationMode state is - ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_KHR, then the <> feature must: be enabled * [[VUID-{refpage}-stippledLineEnable-07496]] @@ -2282,7 +2289,7 @@ ifdef::VK_EXT_line_rasterization[] ename:VK_DYNAMIC_STATE_LINE_RASTERIZATION_MODE_EXT dynamic states enabled, and if the current pname:stippledLineEnable state is ename:VK_TRUE and the current pname:lineRasterizationMode state is - ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_KHR, then the <> feature must: be enabled * [[VUID-{refpage}-stippledLineEnable-07497]] @@ -2291,7 +2298,7 @@ ifdef::VK_EXT_line_rasterization[] ename:VK_DYNAMIC_STATE_LINE_RASTERIZATION_MODE_EXT dynamic states enabled, and if the current pname:stippledLineEnable state is ename:VK_TRUE and the current pname:lineRasterizationMode state is - ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_KHR, then the <> feature must: be enabled * [[VUID-{refpage}-stippledLineEnable-07498]] @@ -2300,11 +2307,11 @@ ifdef::VK_EXT_line_rasterization[] ename:VK_DYNAMIC_STATE_LINE_RASTERIZATION_MODE_EXT dynamic states enabled, and if the current pname:stippledLineEnable state is ename:VK_TRUE and the current pname:lineRasterizationMode state is - ename:VK_LINE_RASTERIZATION_MODE_DEFAULT_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_DEFAULT_KHR, then the <> feature must: be enabled and slink:VkPhysicalDeviceLimits::pname:strictLines must: be ename:VK_TRUE -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] ifdef::VK_EXT_conservative_rasterization[] * [[VUID-{refpage}-conservativePointAndLineRasterization-07499]] If the bound graphics pipeline state was created with the @@ -2491,4 +2498,23 @@ endif::VK_EXT_extended_dynamic_state3,VK_EXT_shader_object[] used>> in the code:Fragment {ExecutionModel} executed by this command must: be less than <> +ifdef::VK_KHR_dynamic_rendering_local_read[] + * [[VUID-{refpage}-None-09548]] + If the current render pass was begun with flink:vkCmdBeginRendering, +ifdef::VK_EXT_shader_object[] + and there is no shader object bound to any graphics stage, +endif::VK_EXT_shader_object[] + the value of each element of + slink:VkRenderingAttachmentLocationInfoKHR::pname:pColorAttachmentLocations + set by flink:vkCmdSetRenderingAttachmentLocationsKHR must: match the + value set for the corresponding element in the currently bound pipeline + * [[VUID-{refpage}-None-09549]] + If the current render pass was begun with flink:vkCmdBeginRendering, +ifdef::VK_EXT_shader_object[] + and there is no shader object bound to any graphics stage, +endif::VK_EXT_shader_object[] + input attachment index mappings in the currently bound pipeline must: + match those set for the current render pass instance via + slink:VkRenderingInputAttachmentIndexInfoKHR +endif::VK_KHR_dynamic_rendering_local_read[] // Common Valid Usage diff --git a/chapters/commonvalidity/image_memory_barrier_common.adoc b/chapters/commonvalidity/image_memory_barrier_common.adoc index 26ca6db62..383c5c864 100644 --- a/chapters/commonvalidity/image_memory_barrier_common.adoc +++ b/chapters/commonvalidity/image_memory_barrier_common.adoc @@ -315,4 +315,27 @@ ifdef::VK_EXT_attachment_feedback_loop_layout[] pname:newLayout must: not be ename:VK_IMAGE_LAYOUT_ATTACHMENT_FEEDBACK_LOOP_OPTIMAL_EXT endif::VK_EXT_attachment_feedback_loop_layout[] +ifdef::VK_KHR_dynamic_rendering_local_read[] + * [[VUID-{refpage}-srcQueueFamilyIndex-09550]] + If pname:srcQueueFamilyIndex and pname:dstQueueFamilyIndex define a + <> or + pname:oldLayout and pname:newLayout define an + <>, + and pname:oldLayout or pname:newLayout is + ename:VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR then pname:image must: + have been created with either ename:VK_IMAGE_USAGE_STORAGE_BIT, or with + both ename:VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT and either of + ename:VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT or + ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT + * [[VUID-{refpage}-dynamicRenderingLocalRead-09551]] + If the <> feature is not enabled, + pname:oldLayout must: not be + ename:VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR + * [[VUID-{refpage}-dynamicRenderingLocalRead-09552]] + If the <> feature is not enabled, + pname:newLayout must: not be + ename:VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR +endif::VK_KHR_dynamic_rendering_local_read[] // Common Valid Usage diff --git a/chapters/commonvalidity/pipeline_barrier_common.adoc b/chapters/commonvalidity/pipeline_barrier_common.adoc index 386567137..a2db85c67 100644 --- a/chapters/commonvalidity/pipeline_barrier_common.adoc +++ b/chapters/commonvalidity/pipeline_barrier_common.adoc @@ -68,7 +68,7 @@ endif::VK_ANDROID_external_format_resolve[] destination stage masks of all memory barriers must: only include <> * [[VUID-{refpage}-dependencyFlags-07891]] - If fname:{refpage} is called within a render pass instance, and and the + If fname:{refpage} is called within a render pass instance, and the source stage masks of any memory barriers include <>, then pname:dependencyFlags must: include ename:VK_DEPENDENCY_BY_REGION_BIT @@ -86,24 +86,48 @@ ifdef::VK_VERSION_1_1,VK_KHR_multiview[] include ename:VK_DEPENDENCY_VIEW_LOCAL_BIT endif::VK_VERSION_1_1,VK_KHR_multiview[] ifdef::VK_VERSION_1_3,VK_KHR_dynamic_rendering[] - * [[VUID-{refpage}-shaderTileImageColorReadAccess-08718]] - If fname:{refpage} is called within a render pass instance + * [[VUID-{refpage}-None-09553]] + {empty} +ifdef::VK_EXT_shader_tile_image,VK_KHR_dynamic_rendering[] + If ifdef::VK_EXT_shader_tile_image[] - and none of the <>, + neither the <> nor <>, - <> features are enabled, + pname:shaderTileImageDepthReadAccess>> features are enabled, endif::VK_EXT_shader_tile_image[] - the render pass must: not have been started with - flink:vkCmdBeginRendering -ifdef::VK_EXT_shader_tile_image[] - * [[VUID-{refpage}-None-08719]] +ifdef::VK_EXT_shader_tile_image+VK_KHR_dynamic_rendering[and] +ifdef::VK_KHR_dynamic_rendering_local_read[] + the <> feature is not enabled, +endif::VK_KHR_dynamic_rendering_local_read[] +endif::VK_EXT_shader_tile_image,VK_KHR_dynamic_rendering[] + fname:{refpage} must: not be called within a render pass instance + started with flink:vkCmdBeginRendering +ifdef::VK_EXT_shader_tile_image,VK_KHR_dynamic_rendering_local_read[] + * [[VUID-{refpage}-None-09554]] + If +ifdef::VK_KHR_dynamic_rendering_local_read[] + the <> feature is not enabled, and +endif::VK_KHR_dynamic_rendering_local_read[] + fname:{refpage} is called within a render pass instance started with + flink:vkCmdBeginRendering, there must: be no buffer or image memory + barriers specified by this command +ifdef::VK_KHR_dynamic_rendering_local_read[] + * [[VUID-{refpage}-image-09555]] If fname:{refpage} is called within a render pass instance started with - flink:vkCmdBeginRendering, it must: adhere to the restrictions in - <> -endif::VK_EXT_shader_tile_image[] + flink:vkCmdBeginRendering, and the pname:image member of any image + memory barrier is used as an attachment in the current render pass + instance, it must: be in the + ename:VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR or + ename:VK_IMAGE_LAYOUT_GENERAL layout +endif::VK_KHR_dynamic_rendering_local_read[] + * [[VUID-{refpage}-srcStageMask-09556]] + If fname:{refpage} is called within a render pass instance started with + flink:vkCmdBeginRendering, this command must: only specify + <> in + pname:srcStageMask and pname:dstStageMask +endif::VK_EXT_shader_tile_image,VK_KHR_dynamic_rendering_local_read[] endif::VK_VERSION_1_3,VK_KHR_dynamic_rendering[] // Common Valid Usage diff --git a/chapters/descriptorsets.adoc b/chapters/descriptorsets.adoc index 874719760..d77ff45b8 100644 --- a/chapters/descriptorsets.adoc +++ b/chapters/descriptorsets.adoc @@ -430,6 +430,9 @@ endif::VK_KHR_synchronization2[] ifdef::VK_EXT_attachment_feedback_loop_layout[] * ename:VK_IMAGE_LAYOUT_ATTACHMENT_FEEDBACK_LOOP_OPTIMAL_EXT endif::VK_EXT_attachment_feedback_loop_layout[] +ifdef::VK_KHR_dynamic_rendering_local_read[] + * ename:VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR +endif::VK_KHR_dynamic_rendering_local_read[] ifdef::VK_NV_ray_tracing,VK_KHR_acceleration_structure[] @@ -3636,6 +3639,13 @@ ifdef::VK_VULKAN_1_1,VK_KHR_sampler_ycbcr_conversion[] pname:pNext chain with an _identically defined_ sname:VkSamplerYcbcrConversionInfo to the corresponding immutable sampler + * [[VUID-VkWriteDescriptorSet-descriptorType-09506]] + If pname:descriptorType is + ename:VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER, pname:dstSet was + allocated with a layout that included immutable samplers for + pname:dstBinding, and those samplers enable + <>, then + pname:imageView must: not be dlink:VK_NULL_HANDLE endif::VK_VULKAN_1_1,VK_KHR_sampler_ycbcr_conversion[] * [[VUID-VkWriteDescriptorSet-descriptorType-00327]] If pname:descriptorType is ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER or @@ -5886,6 +5896,13 @@ endif::VK_VULKAN_1_1,VK_KHR_sampler_ycbcr_conversion[] * [[VUID-vkGetDescriptorEXT-pDescriptor-08016]] pname:pDescriptor must: be a valid pointer to an array of at least pname:dataSize bytes + * [[VUID-vkGetDescriptorEXT-pDescriptorInfo-09507]] + If pname:pDescriptorInfo->type is + ename:VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER and + pname:pDescriptorInfo->data.pCombinedImageSampler is `NULL` or it has a + pname:imageView that is dlink:VK_NULL_HANDLE then pname:dataSize must: + be equal to the size of + slink:VkPhysicalDeviceDescriptorBufferPropertiesEXT::pname:combinedImageSamplerDescriptorSize **** include::{generated}/validity/protos/vkGetDescriptorEXT.adoc[] @@ -6167,6 +6184,14 @@ include::{generated}/api/structs/VkDescriptorAddressInfoEXT.adoc[] .Valid Usage **** + * [[VUID-VkDescriptorAddressInfoEXT-None-09508]] + If +ifdef::VK_EXT_robustness2[] + pname:address is not zero, and +endif::VK_EXT_robustness2[] + the descriptor is of type ename:VK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER + or ename:VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER, then pname:format + must: not be ename:VK_FORMAT_UNDEFINED * [[VUID-VkDescriptorAddressInfoEXT-address-08043]] ifdef::VK_EXT_robustness2[] If the <> feature is not diff --git a/chapters/drawing.adoc b/chapters/drawing.adoc index 925cfad91..b94b61583 100644 --- a/chapters/drawing.adoc +++ b/chapters/drawing.adoc @@ -57,9 +57,9 @@ endif::VK_EXT_multi_draw[] either 0xFFFFFFFF when the pname:indexType parameter of ifdef::VK_KHR_maintenance5[fname:vkCmdBindIndexBuffer2KHR or] fname:vkCmdBindIndexBuffer is equal to ename:VK_INDEX_TYPE_UINT32, -ifdef::VK_EXT_index_type_uint8[] - 0xFF when pname:indexType is equal to ename:VK_INDEX_TYPE_UINT8_EXT, -endif::VK_EXT_index_type_uint8[] +ifdef::VK_KHR_index_type_uint8,VK_EXT_index_type_uint8[] + 0xFF when pname:indexType is equal to ename:VK_INDEX_TYPE_UINT8_KHR, +endif::VK_KHR_index_type_uint8,VK_EXT_index_type_uint8[] or 0xFFFF when pname:indexType is equal to ename:VK_INDEX_TYPE_UINT16. ifndef::VK_EXT_primitive_topology_list_restart[] Primitive restart is not allowed for "`list`" topologies. @@ -949,10 +949,10 @@ include::{generated}/api/enums/VkIndexType.adoc[] ifdef::VK_NV_ray_tracing,VK_KHR_acceleration_structure[] * ename:VK_INDEX_TYPE_NONE_KHR specifies that no indices are provided. endif::VK_NV_ray_tracing,VK_KHR_acceleration_structure[] -ifdef::VK_EXT_index_type_uint8[] - * ename:VK_INDEX_TYPE_UINT8_EXT specifies that indices are 8-bit unsigned +ifdef::VK_KHR_index_type_uint8,VK_EXT_index_type_uint8[] + * ename:VK_INDEX_TYPE_UINT8_KHR specifies that indices are 8-bit unsigned integer values. -endif::VK_EXT_index_type_uint8[] +endif::VK_KHR_index_type_uint8,VK_EXT_index_type_uint8[] -- The parameters for each drawing command are specified directly in the @@ -1033,9 +1033,9 @@ Subsequent index values are retrieved from consecutive locations in the index buffer. Indices are first compared to the primitive restart value, then zero extended to 32 bits (if the code:indexType is -ifdef::VK_EXT_index_type_uint8[] -ename:VK_INDEX_TYPE_UINT8_EXT or -endif::VK_EXT_index_type_uint8[] +ifdef::VK_KHR_index_type_uint8,VK_EXT_index_type_uint8[] +ename:VK_INDEX_TYPE_UINT8_KHR or +endif::VK_KHR_index_type_uint8,VK_EXT_index_type_uint8[] ename:VK_INDEX_TYPE_UINT16) and have pname:vertexOffset added to them, before being supplied as the code:vertexIndex value. diff --git a/chapters/extensions.adoc b/chapters/extensions.adoc index 1c9570c3c..1d9975d87 100644 --- a/chapters/extensions.adoc +++ b/chapters/extensions.adoc @@ -679,6 +679,24 @@ ifdef::VK_VERSION_1_3[] Implementations claiming support for the <> profile must: advertise the `apiext:VK_KHR_global_priority` extension in pname:pProperties. + +Implementations claiming support for the <> +profile must: advertise the following extensions in pname:pProperties: + + * apiext:VK_KHR_dynamic_rendering_local_read + * apiext:VK_KHR_load_store_op_none + * apiext:VK_KHR_shader_quad_control + * apiext:VK_KHR_shader_maximal_reconvergence + * apiext:VK_KHR_shader_subgroup_uniform_control_flow + * apiext:VK_KHR_shader_subgroup_rotate + * apiext:VK_KHR_shader_float_controls2 + * apiext:VK_KHR_shader_expect_assume + * apiext:VK_KHR_line_rasterization + * apiext:VK_KHR_vertex_attribute_divisor + * apiext:VK_KHR_index_type_uint8 + * apiext:VK_KHR_map_memory2 + * apiext:VK_KHR_maintenance5 + * apiext:VK_KHR_push_descriptor endif::VK_VERSION_1_3[] [NOTE] diff --git a/chapters/features.adoc b/chapters/features.adoc index 503bbde5f..9b9c55f43 100644 --- a/chapters/features.adoc +++ b/chapters/features.adoc @@ -3563,12 +3563,18 @@ include::{generated}/validity/structs/VkPhysicalDeviceExternalMemoryScreenBuffer -- endif::VK_QNX_external_memory_screen_buffer[] -ifdef::VK_EXT_index_type_uint8[] -[open,refpage='VkPhysicalDeviceIndexTypeUint8FeaturesEXT',desc='Structure describing whether uint8 index type can be used',type='structs'] +ifdef::VK_KHR_index_type_uint8,VK_EXT_index_type_uint8[] +[open,refpage='VkPhysicalDeviceIndexTypeUint8FeaturesKHR',desc='Structure describing whether uint8 index type can be used',type='structs',alias='VkPhysicalDeviceIndexTypeUint8FeaturesEXT'] -- -The sname:VkPhysicalDeviceIndexTypeUint8FeaturesEXT structure is defined as: +The sname:VkPhysicalDeviceIndexTypeUint8FeaturesKHR structure is defined as: + +include::{generated}/api/structs/VkPhysicalDeviceIndexTypeUint8FeaturesKHR.adoc[] + +ifdef::VK_EXT_index_type_uint8[] +or the equivalent include::{generated}/api/structs/VkPhysicalDeviceIndexTypeUint8FeaturesEXT.adoc[] +endif::VK_EXT_index_type_uint8[] This structure describes the following feature: @@ -3576,16 +3582,16 @@ This structure describes the following feature: * pname:pNext is `NULL` or a pointer to a structure extending this structure. * [[features-indexTypeUint8]] pname:indexTypeUint8 indicates that - ename:VK_INDEX_TYPE_UINT8_EXT can be used with + ename:VK_INDEX_TYPE_UINT8_KHR can be used with ifdef::VK_KHR_maintenance5[flink:vkCmdBindIndexBuffer2KHR and] flink:vkCmdBindIndexBuffer. -:refpage: VkPhysicalDeviceIndexTypeUint8FeaturesEXT +:refpage: VkPhysicalDeviceIndexTypeUint8FeaturesKHR include::{chapters}/features.adoc[tag=features] -include::{generated}/validity/structs/VkPhysicalDeviceIndexTypeUint8FeaturesEXT.adoc[] +include::{generated}/validity/structs/VkPhysicalDeviceIndexTypeUint8FeaturesKHR.adoc[] -- -endif::VK_EXT_index_type_uint8[] +endif::VK_KHR_index_type_uint8,VK_EXT_index_type_uint8[] ifdef::VK_EXT_primitive_topology_list_restart[] [open,refpage='VkPhysicalDevicePrimitiveTopologyListRestartFeaturesEXT',desc='Structure describing whether list type primitives can support primitive restart',type='structs'] @@ -3859,13 +3865,19 @@ include::{generated}/validity/structs/VkPhysicalDeviceTextureCompressionASTCHDRF -- endif::VK_VERSION_1_3,VK_EXT_texture_compression_astc_hdr[] -ifdef::VK_EXT_line_rasterization[] -[open,refpage='VkPhysicalDeviceLineRasterizationFeaturesEXT',desc='Structure describing the line rasterization features that can be supported by an implementation',type='structs'] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] +[open,refpage='VkPhysicalDeviceLineRasterizationFeaturesKHR',desc='Structure describing the line rasterization features that can be supported by an implementation',type='structs',alias='VK_EXT_line_rasterization'] -- -The sname:VkPhysicalDeviceLineRasterizationFeaturesEXT structure is defined +The sname:VkPhysicalDeviceLineRasterizationFeaturesKHR structure is defined as: +include::{generated}/api/structs/VkPhysicalDeviceLineRasterizationFeaturesKHR.adoc[] + +ifdef::VK_EXT_line_rasterization[] +or the equivalent + include::{generated}/api/structs/VkPhysicalDeviceLineRasterizationFeaturesEXT.adoc[] +endif::VK_EXT_line_rasterization[] This structure describes the following features: @@ -3884,22 +3896,22 @@ This structure describes the following features: * [[features-stippledRectangularLines]] pname:stippledRectangularLines indicates whether the implementation supports <> with - ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT lines. + ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_KHR lines. * [[features-stippledBresenhamLines]] pname:stippledBresenhamLines indicates whether the implementation supports <> with - ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT lines. + ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_KHR lines. * [[features-stippledSmoothLines]] pname:stippledSmoothLines indicates whether the implementation supports <> with - ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT lines. + ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_KHR lines. -:refpage: VkPhysicalDeviceLineRasterizationFeaturesEXT +:refpage: VkPhysicalDeviceLineRasterizationFeaturesKHR include::{chapters}/features.adoc[tag=features] -include::{generated}/validity/structs/VkPhysicalDeviceLineRasterizationFeaturesEXT.adoc[] +include::{generated}/validity/structs/VkPhysicalDeviceLineRasterizationFeaturesKHR.adoc[] -- -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] ifdef::VK_VERSION_1_3,VK_EXT_subgroup_size_control[] [open,refpage='VkPhysicalDeviceSubgroupSizeControlFeatures',desc='Structure describing the subgroup size control features that can be supported by an implementation',type='structs',alias='VkPhysicalDeviceSubgroupSizeControlFeaturesEXT'] @@ -6485,6 +6497,31 @@ include::{generated}/validity/structs/VkPhysicalDeviceRayTracingPositionFetchFea endif::VK_KHR_ray_tracing_position_fetch[] +ifdef::VK_KHR_shader_float_controls2[] +[open,refpage='VkPhysicalDeviceShaderFloatControls2FeaturesKHR',desc='Structure describing shader float controls 2 features that can be supported by an implementation',type='structs'] +-- +The sname:VkPhysicalDeviceShaderFloatControls2FeaturesKHR structure is +defined as: + +include::{generated}/api/structs/VkPhysicalDeviceShaderFloatControls2FeaturesKHR.adoc[] + +This structure describes the following feature: + + * pname:sType is a elink:VkStructureType value identifying this structure. + * pname:pNext is `NULL` or a pointer to a structure extending this + structure. + + * [[features-shaderFloatControls2]] pname:shaderFloatControls2 specifies + whether shader modules can: declare the code:FloatControls2 capability. + +:refpage: VkPhysicalDeviceShaderFloatControls2FeaturesKHR +include::{chapters}/features.adoc[tag=features] + +include::{generated}/validity/structs/VkPhysicalDeviceShaderFloatControls2FeaturesKHR.adoc[] +-- +endif::VK_KHR_shader_float_controls2[] + + ifdef::VK_AMD_shader_early_and_late_fragment_tests[] [open,refpage='VkPhysicalDeviceShaderEarlyAndLateFragmentTestsFeaturesAMD',desc='Structure describing whether early and late fragment tests can be supported by an implementation',type='structs'] -- @@ -7283,6 +7320,30 @@ include::{generated}/validity/structs/VkPhysicalDeviceCudaKernelLaunchFeaturesNV -- endif::VK_NV_cuda_kernel_launch[] +ifdef::VK_KHR_shader_maximal_reconvergence[] +[open,refpage='VkPhysicalDeviceShaderMaximalReconvergenceFeaturesKHR',desc='Structure describing support for shader maximal reconvergence by an implementation',type='structs'] +-- +The sname:VkPhysicalDeviceShaderMaximalReconvergenceFeaturesKHR structure is +defined as: + +include::{generated}/api/structs/VkPhysicalDeviceShaderMaximalReconvergenceFeaturesKHR.adoc[] + +This structure describes the following feature: + + * pname:sType is a elink:VkStructureType value identifying this structure. + * pname:pNext is `NULL` or a pointer to a structure extending this + structure. + * [[features-shaderMaximalReconvergence]] pname:shaderMaximalReconvergence + specifies whether the implementation supports the shader execution mode + code:MaximallyReconvergesKHR + +:refpage: VkPhysicalDevicePrivateDataFeaturesEXT +include::{chapters}/features.adoc[tag=features] + +include::{generated}/validity/structs/VkPhysicalDeviceShaderMaximalReconvergenceFeaturesKHR.adoc[] +-- +endif::VK_KHR_shader_maximal_reconvergence[] + ifdef::VK_ANDROID_external_format_resolve[] [open,refpage='VkPhysicalDeviceExternalFormatResolveFeaturesANDROID',desc='Structure describing whether external format resolves are supported',type='structs'] @@ -7372,9 +7433,103 @@ include::{chapters}/features.adoc[tag=features] include::{generated}/validity/structs/VkPhysicalDeviceRenderPassStripedFeaturesARM.adoc[] -- - endif::VK_ARM_render_pass_striped[] +ifdef::VK_KHR_shader_subgroup_rotate[] +[open,refpage='VkPhysicalDeviceShaderSubgroupRotateFeaturesKHR',desc='Structure describing whether subgroup rotation is enabled',type='structs'] +-- +The sname:VkPhysicalDeviceShaderSubgroupRotateFeaturesKHR structure is +defined as: + +include::{generated}/api/structs/VkPhysicalDeviceShaderSubgroupRotateFeaturesKHR.adoc[] + + * pname:sType is a elink:VkStructureType value identifying this structure. + * pname:pNext is `NULL` or a pointer to a structure extending this + structure. + * [[features-shaderSubgroupRotate]] pname:shaderSubgroupRotate specifies + whether shader modules can: declare the code:GroupNonUniformRotateKHR + capability. + * [[features-shaderSubgroupRotateClustered]] + pname:shaderSubgroupRotateClustered specifies whether shader modules + can: use the code:ClusterSize operand to + code:OpGroupNonUniformRotateKHR. + +:refpage: VkPhysicalDeviceShaderSubgroupRotateFeaturesKHR +include::{chapters}/features.adoc[tag=features] + +include::{generated}/validity/structs/VkPhysicalDeviceShaderSubgroupRotateFeaturesKHR.adoc[] +-- +endif::VK_KHR_shader_subgroup_rotate[] + +ifdef::VK_KHR_shader_expect_assume[] +[open,refpage='VkPhysicalDeviceShaderExpectAssumeFeaturesKHR',desc='Structure describing shader expect assume features that can be supported by an implementation',type='structs'] +-- +The sname:VkPhysicalDeviceShaderExpectAssumeFeaturesKHR structure is defined +as: + +include::{generated}/api/structs/VkPhysicalDeviceShaderExpectAssumeFeaturesKHR.adoc[] + + * pname:sType is a elink:VkStructureType value identifying this structure. + * pname:pNext is `NULL` or a pointer to a structure extending this + structure. + * [[features-shaderExpectAssume]] pname:shaderExpectAssume specifies + whether shader modules can: declare the code:ExpectAssumeKHR capability. + +:refpage: VkPhysicalDeviceShaderExpectAssumeFeaturesKHR +include::{chapters}/features.adoc[tag=features] + +include::{generated}/validity/structs/VkPhysicalDeviceShaderExpectAssumeFeaturesKHR.adoc[] +-- +endif::VK_KHR_shader_expect_assume[] + + +ifdef::VK_KHR_dynamic_rendering_local_read[] +[open,refpage='VkPhysicalDeviceDynamicRenderingLocalReadFeaturesKHR',desc='Structure indicating support for local reads in dynamic render pass instances',type='structs'] +-- +The sname:VkPhysicalDeviceDynamicRenderingLocalReadFeaturesKHR structure is +defined as: + +include::{generated}/api/structs/VkPhysicalDeviceDynamicRenderingLocalReadFeaturesKHR.adoc[] + +This structure describes the following feature: + + * pname:sType is a elink:VkStructureType value identifying this structure. + * pname:pNext is `NULL` or a pointer to a structure extending this + structure. + * [[features-dynamicRenderingLocalRead]] pname:dynamicRenderingLocalRead + specifies that the implementation supports local reads inside dynamic + render pass instances using the flink:vkCmdBeginRendering command. + +:refpage: VkPhysicalDeviceDynamicRenderingLocalReadFeaturesKHR +include::{chapters}/features.adoc[tag=features] + +include::{generated}/validity/structs/VkPhysicalDeviceDynamicRenderingLocalReadFeaturesKHR.adoc[] +-- +endif::VK_KHR_dynamic_rendering_local_read[] + + +ifdef::VK_KHR_shader_quad_control[] +[open,refpage='VkPhysicalDeviceShaderQuadControlFeaturesKHR',desc='Structure describing whether quad scopes are supported by the implementation',type='structs'] +-- +The sname:VkPhysicalDeviceShaderQuadControlFeaturesKHR structure is defined +as: + +include::{generated}/api/structs/VkPhysicalDeviceShaderQuadControlFeaturesKHR.adoc[] + +This structure describes the following features: + + * [[features-shaderQuadControl]] pname:shaderQuadControl indicates whether + the implementation supports shaders with the code:QuadControlKHR + capability. + +:refpage: VkPhysicalDeviceShaderQuadControlFeaturesKHR +include::{chapters}/features.adoc[tag=features] + +include::{generated}/validity/structs/VkPhysicalDeviceShaderQuadControlFeaturesKHR.adoc[] +-- +endif::VK_KHR_shader_quad_control[] + + [[features-requirements]] == Feature Requirements @@ -7621,10 +7776,23 @@ ifdef::VK_EXT_ycbcr_image_arrays[] * <>, if the `apiext:VK_EXT_ycbcr_image_arrays` extension is supported. endif::VK_EXT_ycbcr_image_arrays[] -ifdef::VK_EXT_index_type_uint8[] +ifdef::VK_EXT_index_type_uint8,VK_KHR_index_type_uint8[] * <>, if the - `apiext:VK_EXT_index_type_uint8` extension is supported. +ifdef::VK_KHR_index_type_uint8[] + `apiext:VK_KHR_index_type_uint8` +endif::VK_KHR_index_type_uint8[] +ifdef::VK_EXT_index_type_uint8+VK_KHR_index_type_uint8[] + or +endif::VK_EXT_index_type_uint8+VK_KHR_index_type_uint8[] +ifdef::VK_EXT_index_type_uint8[] + `apiext:VK_EXT_index_type_uint8` endif::VK_EXT_index_type_uint8[] + extension is supported. +endif::VK_EXT_index_type_uint8,VK_KHR_index_type_uint8[] +ifdef::VK_KHR_index_type_uint8[] + * <>, if the + `apiext:VK_KHR_index_type_uint8` extension is supported. +endif::VK_KHR_index_type_uint8[] ifdef::VK_EXT_primitive_topology_list_restart[] * <>, if the @@ -7713,6 +7881,15 @@ ifdef::VK_EXT_fragment_shader_interlock[] pname:fragmentShaderShadingRateInterlock>>, if the `apiext:VK_EXT_fragment_shader_interlock` extension is supported. endif::VK_EXT_fragment_shader_interlock[] +ifdef::VK_KHR_line_rasterization[] + * <> or + <> or + <> or + <> or + <> or + <>, if the + `apiext:VK_KHR_line_rasterization` extension is supported. +endif::VK_KHR_line_rasterization[] ifdef::VK_EXT_line_rasterization[] * <> or <> or @@ -8094,14 +8271,14 @@ ifdef::VK_EXT_provoking_vertex[] <> feature is supported. endif::VK_EXT_provoking_vertex[] -ifdef::VK_EXT_line_rasterization[] - * `apiext:VK_EXT_line_rasterization` extension, if the - <> feature is supported. - * `apiext:VK_EXT_line_rasterization` extension, if the - <> feature is supported. -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] ifdef::VK_EXT_depth_clip_control[] * <>, if the <>, if the `apiext:VK_NV_per_stage_descriptor_set` extension is supported. endif::VK_NV_per_stage_descriptor_set[] +ifdef::VK_KHR_shader_maximal_reconvergence[] + * <>, if the + `apiext:VK_KHR_shader_maximal_reconvergence` extension is supported. +endif::VK_KHR_shader_maximal_reconvergence[] +ifdef::VK_KHR_shader_subgroup_rotate[] + * <>, if the + `<>` extension is supported. +endif::VK_KHR_shader_subgroup_rotate[] +ifdef::VK_KHR_shader_expect_assume[] + * <>, if the + `apiext:VK_KHR_shader_expect_assume` extension is supported. +endif::VK_KHR_shader_expect_assume[] +ifdef::VK_KHR_shader_float_controls2[] + * <>, if the + `apiext:VK_KHR_shader_float_controls2` extension is supported. +endif::VK_KHR_shader_float_controls2[] +ifdef::VK_KHR_dynamic_rendering_local_read[] + * <>, + if the `apiext:VK_KHR_dynamic_rendering_local_read` extension is + supported. +endif::VK_KHR_dynamic_rendering_local_read[] +ifdef::VK_KHR_shader_quad_control[] + * <>, if the + `apiext:VK_KHR_shader_quad_control` extension is supported. +endif::VK_KHR_shader_quad_control[] All other features defined in the Specification are optional:. @@ -8308,4 +8511,20 @@ profile must: support the following features: pname:descriptorBindingVariableDescriptorCount>> * <> * <> + + +[[profile-features-roadmap-2024]] +=== Roadmap 2024 + +Implementations that claim support for the <> +profile must: support the following features: + + * <> + * <> + * <> + * <> + * <> + * <> + * <> + * <> endif::VK_VERSION_1_3[] diff --git a/chapters/fragops.adoc b/chapters/fragops.adoc index 6c6e918dc..22e7dd286 100644 --- a/chapters/fragops.adoc +++ b/chapters/fragops.adoc @@ -1086,11 +1086,11 @@ If no fragment shader is active, or if the active fragment shader does not include code:SampleMask in its interface, the coverage mask is not modified. Next, the fragment alpha value and coverage mask are modified based on the -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] line coverage factor if the pname:lineRasterizationMode member of the slink:VkPipelineRasterizationStateCreateInfo structure is -ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT, and the -endif::VK_EXT_line_rasterization[] +ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_KHR, and the +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] pname:alphaToCoverageEnable and pname:alphaToOneEnable members of the slink:VkPipelineMultisampleStateCreateInfo structure. @@ -1183,14 +1183,14 @@ section). If that shader output has an integer or unsigned integer type, then these operations are skipped. -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] If the pname:lineRasterizationMode member of the slink:VkPipelineRasterizationStateCreateInfo structure is -ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT and the fragment +ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_KHR and the fragment came from a line segment, then the alpha value is replaced by multiplying it by the coverage factor for the fragment computed during <>. -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] If pname:alphaToCoverageEnable is enabled, a temporary coverage mask is generated where each bit is determined by the fragment's alpha value, which diff --git a/chapters/interfaces.adoc b/chapters/interfaces.adoc index c6121dda9..cfa3a9551 100644 --- a/chapters/interfaces.adoc +++ b/chapters/interfaces.adoc @@ -407,6 +407,119 @@ The number of available fragment output code:Location slots is given by the pname:maxFragmentOutputAttachments member of the sname:VkPhysicalDeviceLimits structure. +ifdef::VK_KHR_dynamic_rendering_local_read[] +If the +<> +feature is supported, fragment output locations can: be remapped when using +dynamic rendering. + +[open,refpage='vkCmdSetRenderingAttachmentLocationsKHR',desc='Set color attachment location mappings for a command buffer',type='protos'] +-- +To set the fragment output location mappings during rendering, call: + +include::{generated}/api/protos/vkCmdSetRenderingAttachmentLocationsKHR.adoc[] + + * pname:commandBuffer is the command buffer into which the command will be + recorded. + * pname:pLocationInfo is a slink:VkRenderingAttachmentLocationInfoKHR + structure indicating the new mappings. + +This command sets the attachment location mappings for subsequent drawing +commands, and must: match the mappings provided to the currently bound +pipeline, +ifdef::VK_EXT_shader_object[if one is bound,] +which can: be set by chaining slink:VkRenderingAttachmentLocationInfoKHR to +slink:VkGraphicsPipelineCreateInfo. + +Until this command is called, mappings in the command buffer state are +treated as each color attachment specified in flink:vkCmdBeginRendering +having a location equal to its index in +slink:VkRenderingInfo::pname:pColorAttachments. +This state is reset whenever flink:vkCmdBeginRendering is called. + +.Valid Usage +**** + * [[VUID-vkCmdSetRenderingAttachmentLocationsKHR-dynamicRenderingLocalRead-09509]] + <> + must: be enabled + * [[VUID-vkCmdSetRenderingAttachmentLocationsKHR-pLocationInfo-09510]] + pname:pLocationInfo->colorAttachmentCount must: be equal to the value of + slink:VkRenderingInfo::pname:colorAttachmentCount used to begin the + current render pass instance + * [[VUID-vkCmdSetRenderingAttachmentLocationsKHR-commandBuffer-09511]] + The current render pass instance must: have been started or resumed by + flink:vkCmdBeginRendering in this pname:commandBuffer +**** + +include::{generated}/validity/protos/vkCmdSetRenderingAttachmentLocationsKHR.adoc[] +-- + +[open,refpage='VkRenderingAttachmentLocationInfoKHR',desc='Structure specifying attachment locations',type='structs'] +-- +The sname:VkRenderingAttachmentLocationInfoKHR structure is defined as: + +include::{generated}/api/structs/VkRenderingAttachmentLocationInfoKHR.adoc[] + + * pname:sType is a elink:VkStructureType value identifying this structure. + * pname:pNext is `NULL` or a pointer to a structure extending this + structure. + * pname:colorAttachmentCount is the number of elements in + pname:pColorAttachmentLocations. + * pname:pColorAttachmentLocations is a pointer to an array of + pname:colorAttachmentCount code:uint32_t values defining remapped + locations for color attachments. + +This structure allows applications to remap the locations of color +attachments to different fragment shader output locations. + +Each element of pname:pColorAttachmentLocations set to +ename:VK_ATTACHMENT_UNUSED will be inaccessible to this pipeline as a color +attachment; no location will map to it. +Each element of pname:pColorAttachmentLocations set to any other value will +map the specified location value to the color attachment specified in the +render pass at the corresponding index in the +pname:pColorAttachmentLocations array. +If pname:pColorAttachmentLocations is `NULL`, it is equivalent to setting +each element to its index within the array. +Any writes to a fragment output location that is not mapped to an attachment +must: be discarded. + +This structure can: be included in the pname:pNext chain of a +slink:VkGraphicsPipelineCreateInfo structure to set this state for a +pipeline. +This structure can: be included in the pname:pNext chain of a +slink:VkCommandBufferInheritanceInfo structure to specify inherited state +from the primary command buffer. +If this structure is not included in the pname:pNext chain of +slink:VkGraphicsPipelineCreateInfo or slink:VkCommandBufferInheritanceInfo, +it is equivalent to specifying this structure with the following properties: + + * pname:colorAttachmentCount set to + slink:VkPipelineRenderingCreateInfo::pname:colorAttachmentCount. + * pname:pColorAttachmentLocations set to `NULL`. + +.Valid Usage +**** + * [[VUID-VkRenderingAttachmentLocationInfoKHR-dynamicRenderingLocalRead-09512]] + If the <> feature is not enabled, and + pname:pColorAttachmentLocations is not `NULL`, each element must: be set + to the value of its index within the array + * [[VUID-VkRenderingAttachmentLocationInfoKHR-pColorAttachmentLocations-09513]] + Elements of pname:pColorAttachmentLocations that are not + ename:VK_ATTACHMENT_UNUSED must: each be unique + * [[VUID-VkRenderingAttachmentLocationInfoKHR-colorAttachmentCount-09514]] + pname:colorAttachmentCount must: be less than or equal to + <> + * [[VUID-VkRenderingAttachmentLocationInfoKHR-pColorAttachmentLocations-09515]] + Each element of pname:pColorAttachmentLocations must: be less than or + equal to <> +**** + +include::{generated}/validity/structs/VkRenderingAttachmentLocationInfoKHR.adoc[] +-- +endif::VK_KHR_dynamic_rendering_local_read[] + When an active fragment shader invocation finishes, the values of all fragment shader outputs are copied out and used as blend inputs or color attachments writes. @@ -564,6 +677,149 @@ The number of available input attachment indices is given by the pname:maxPerStageDescriptorInputAttachments member of the sname:VkPhysicalDeviceLimits structure. +ifdef::VK_KHR_dynamic_rendering_local_read[] +When using dynamic rendering with the <> feature enabled, a subpass input variable +with a code:InputAttachmentIndex decoration of _i_ can be mapped to a color, +depth, or stencil attachment. + +[open,refpage='vkCmdSetRenderingInputAttachmentIndicesKHR',desc='Set input attachment index mappings for a command buffer',type='protos'] +-- +To set the input attachment index mappings during dynamic rendering, call: + +include::{generated}/api/protos/vkCmdSetRenderingInputAttachmentIndicesKHR.adoc[] + + * pname:commandBuffer is the command buffer into which the command will be + recorded. + * pname:pInputAttachmentIndexInfo is a + slink:VkRenderingInputAttachmentIndexInfoKHR structure indicating the + new mappings. + +This command sets the input attachment index mappings for subsequent drawing +commands, and must: match the mappings provided to the currently bound +pipeline, +ifdef::VK_EXT_shader_object[if one is bound,] +which can: be set by chaining slink:VkRenderingInputAttachmentIndexInfoKHR +to slink:VkGraphicsPipelineCreateInfo. + +Until this command is called, mappings in the command buffer state are +treated as each color attachment specified in flink:vkCmdBeginRendering +mapping to subpass inputs with a code:InputAttachmentIndex equal to its +index in slink:VkRenderingInfo::pname:pColorAttachments, and depth/stencil +attachments mapping to input attachments without these decorations. +This state is reset whenever flink:vkCmdBeginRendering is called. + +.Valid Usage +**** + * [[VUID-vkCmdSetRenderingInputAttachmentIndicesKHR-dynamicRenderingLocalRead-09516]] + <> + must: be enabled + * [[VUID-vkCmdSetRenderingInputAttachmentIndicesKHR-pInputAttachmentIndexInfo-09517]] + pname:pInputAttachmentIndexInfo->colorAttachmentCount must: be equal to + the value of slink:VkRenderingInfo::pname:colorAttachmentCount used to + begin the current render pass instance + * [[VUID-vkCmdSetRenderingInputAttachmentIndicesKHR-commandBuffer-09518]] + The current render pass instance must: have been started or resumed by + flink:vkCmdBeginRendering in this pname:commandBuffer +**** + +include::{generated}/validity/protos/vkCmdSetRenderingInputAttachmentIndicesKHR.adoc[] +-- + +[open,refpage='VkRenderingInputAttachmentIndexInfoKHR',desc='Structure specifying input attachment indices',type='structs'] +-- +The sname:VkRenderingInputAttachmentIndexInfoKHR structure is defined as: + +include::{generated}/api/structs/VkRenderingInputAttachmentIndexInfoKHR.adoc[] + + * pname:sType is a elink:VkStructureType value identifying this structure. + * pname:pNext is `NULL` or a pointer to a structure extending this + structure. + * pname:colorAttachmentCount is the number of elements in + pname:pColorAttachmentInputIndices. + * pname:pColorAttachmentInputIndices is a pointer to an array of + pname:colorAttachmentCount code:uint32_t values defining indices for + color attachments to be used as input attachments. + * pname:pDepthInputAttachmentIndex is either `NULL`, or a pointer to a + code:uint32_t value defining the index for the depth attachment to be + used an an input attachment. + * pname:pStencilInputAttachmentIndex is either `NULL`, or a pointer to a + code:uint32_t value defining the index for the stencil attachment to be + used an an input attachment. + +This structure allows applications to remap attachments to different input +attachment indices. + +Each element of pname:pColorAttachmentInputIndices set to a value of +ename:VK_ATTACHMENT_UNUSED indicates that the corresponding attachment will +not be used as an input attachment in this pipeline. +Any other value in each of those elements will map the corresponding +attachment to a code:InputAttachmentIndex value defined in shader code. +If pname:pColorAttachmentInputIndices is `NULL`, it is equivalent to setting +each element to its index within the array. + +If pname:pDepthInputAttachmentIndex or pname:pStencilInputAttachmentIndex +are set to `NULL`, they map to input attachments without a +code:InputAttachmentIndex decoration. +If they point to a value of ename:VK_ATTACHMENT_UNUSED, it indicates that +the corresponding attachment will not be used as an input attachment in this +pipeline. +If they point to any other value it maps the corresponding attachment to a +code:InputAttachmentIndex value defined in shader code. + +This structure can: be included in the pname:pNext chain of a +slink:VkGraphicsPipelineCreateInfo structure to set this state for a +pipeline. +This structure can: be included in the pname:pNext chain of a +slink:VkCommandBufferInheritanceInfo structure to specify inherited state +from the primary command buffer. +If this structure is not included in the pname:pNext chain of +slink:VkGraphicsPipelineCreateInfo or slink:VkCommandBufferInheritanceInfo, +it is equivalent to specifying this structure with the following properties: + + * pname:colorAttachmentCount set to + slink:VkPipelineRenderingCreateInfo::pname:colorAttachmentCount. + * pname:pColorAttachmentInputIndices set to `NULL`. + * pname:pDepthInputAttachmentIndex set to `NULL`. + * pname:pStencilInputAttachmentIndex set to `NULL`. + +.Valid Usage +**** + * [[VUID-VkRenderingInputAttachmentIndexInfoKHR-dynamicRenderingLocalRead-09519]] + If the <> feature is not enabled, and + pname:pColorAttachmentInputIndices is not `NULL`, each element must: be + set to ename:VK_ATTACHMENT_UNUSED + * [[VUID-VkRenderingInputAttachmentIndexInfoKHR-dynamicRenderingLocalRead-09520]] + If the <> feature is not enabled, + pname:pDepthInputAttachmentIndex must: be a valid pointer to a value of + ename:VK_ATTACHMENT_UNUSED + * [[VUID-VkRenderingInputAttachmentIndexInfoKHR-dynamicRenderingLocalRead-09521]] + If the <> feature is not enabled, + pname:pStencilInputAttachmentIndex must: be a valid pointer to a value + of ename:VK_ATTACHMENT_UNUSED + * [[VUID-VkRenderingInputAttachmentIndexInfoKHR-pColorAttachmentInputIndices-09522]] + Elements of pname:pColorAttachmentInputIndices that are not + ename:VK_ATTACHMENT_UNUSED must: each be unique + * [[VUID-VkRenderingInputAttachmentIndexInfoKHR-pColorAttachmentInputIndices-09523]] + Elements of pname:pColorAttachmentInputIndices that are not + ename:VK_ATTACHMENT_UNUSED must: not take the same value as the content + of pname:pDepthInputAttachmentIndex + * [[VUID-VkRenderingInputAttachmentIndexInfoKHR-pColorAttachmentInputIndices-09524]] + Elements of pname:pColorAttachmentInputIndices that are not + ename:VK_ATTACHMENT_UNUSED must: not take the same value as the content + of pname:pStencilInputAttachmentIndex + * [[VUID-VkRenderingInputAttachmentIndexInfoKHR-colorAttachmentCount-09525]] + pname:colorAttachmentCount must: be less than or equal to + <> +**** + +include::{generated}/validity/structs/VkRenderingInputAttachmentIndexInfoKHR.adoc[] +-- +endif::VK_KHR_dynamic_rendering_local_read[] + Variables identified with the code:InputAttachmentIndex must: only be used by a fragment stage. The <> of the subpass input must: diff --git a/chapters/introduction.adoc b/chapters/introduction.adoc index fb39943ad..eab9071ba 100644 --- a/chapters/introduction.adoc +++ b/chapters/introduction.adoc @@ -210,7 +210,7 @@ https://www.itu.int/rec/T-REC-H.264-202108-I/ . [[itu-t-h265]] ITU-T. _H.265 High Efficiency Video Coding_ (August, 2021). -https://www.itu.int/rec/T-REC-H.265-202108-I/ . +https://www.itu.int/rec/T-REC-H.265-202108-S/ . [[vulkan-registry]] Jon Leech. _The Khronos Vulkan API Registry_ (February 26, 2023). diff --git a/chapters/limits.adoc b/chapters/limits.adoc index bae661e9a..3387b3f79 100644 --- a/chapters/limits.adoc +++ b/chapters/limits.adoc @@ -757,10 +757,9 @@ endif::VK_VERSION_1_2,VK_KHR_create_renderpass2[] * [[limits-maxCombinedClipAndCullDistances]] pname:maxCombinedClipAndCullDistances is the maximum combined number of clip and cull distances that can: be used in a single shader stage. - The sum of the sizes of any pair of arrays declared with the - code:ClipDistance and code:CullDistance built-in decoration used by a - single shader stage in a shader module must: be less than or equal to - this limit. + The sum of the sizes of all arrays declared with the code:ClipDistance + and code:CullDistance built-in decoration used by a single shader stage + in a shader module must: be less than or equal to this limit. * [[limits-discreteQueuePriorities]] pname:discreteQueuePriorities is the number of discrete priorities that can: be assigned to a queue based on the value of each member of @@ -1299,6 +1298,12 @@ pname:shaderSubgroupUniformControlFlow>> is enabled, endif::VK_KHR_shader_subgroup_uniform_control_flow[] pname:subgroupSize must: be greater than or equal to 4. +ifdef::VK_KHR_shader_quad_control[] +If the <> feature is +supported, pname:supportedOperations must: include <>. +endif::VK_KHR_shader_quad_control[] + include::{generated}/validity/structs/VkPhysicalDeviceSubgroupProperties.adoc[] -- @@ -3148,13 +3153,19 @@ include::{generated}/validity/structs/VkPhysicalDeviceTimelineSemaphorePropertie -- endif::VK_VERSION_1_2,VK_KHR_timeline_semaphore[] -ifdef::VK_EXT_line_rasterization[] -[open,refpage='VkPhysicalDeviceLineRasterizationPropertiesEXT',desc='Structure describing line rasterization properties supported by an implementation',type='structs'] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] +[open,refpage='VkPhysicalDeviceLineRasterizationPropertiesKHR',desc='Structure describing line rasterization properties supported by an implementation',type='structs',alias='VkPhysicalDeviceLineRasterizationPropertiesEXT'] -- -The sname:VkPhysicalDeviceLineRasterizationPropertiesEXT structure is +The sname:VkPhysicalDeviceLineRasterizationPropertiesKHR structure is defined as: +include::{generated}/api/structs/VkPhysicalDeviceLineRasterizationPropertiesKHR.adoc[] + +ifdef::VK_EXT_line_rasterization[] +or the equivalent + include::{generated}/api/structs/VkPhysicalDeviceLineRasterizationPropertiesEXT.adoc[] +endif::VK_EXT_line_rasterization[] * pname:sType is a elink:VkStructureType value identifying this structure. * pname:pNext is `NULL` or a pointer to a structure extending this @@ -3164,12 +3175,12 @@ include::{generated}/api/structs/VkPhysicalDeviceLineRasterizationPropertiesEXT. [eq]#x~f~# and [eq]#y~f~# when rasterizing <>. -:refpage: VkPhysicalDeviceLineRasterizationPropertiesEXT +:refpage: VkPhysicalDeviceLineRasterizationPropertiesKHR include::{chapters}/limits.adoc[tag=limits_desc] -include::{generated}/validity/structs/VkPhysicalDeviceLineRasterizationPropertiesEXT.adoc[] +include::{generated}/validity/structs/VkPhysicalDeviceLineRasterizationPropertiesKHR.adoc[] -- -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] ifdef::VK_EXT_robustness2[] [open,refpage='VkPhysicalDeviceRobustness2PropertiesEXT',desc='Structure describing robust buffer access properties supported by an implementation',type='structs'] @@ -4814,9 +4825,9 @@ endif::VK_KHR_ray_tracing_pipeline[] ifdef::VK_VERSION_1_2,VK_KHR_timeline_semaphore[] | code:uint64_t | pname:maxTimelineSemaphoreValueDifference | `<>` endif::VK_VERSION_1_2,VK_KHR_timeline_semaphore[] -ifdef::VK_EXT_line_rasterization[] -| code:uint32_t | pname:lineSubPixelPrecisionBits | `apiext:VK_EXT_line_rasterization` -endif::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] +| code:uint32_t | pname:lineSubPixelPrecisionBits | `apiext:VK_KHR_line_rasterization`, `apiext:VK_EXT_line_rasterization` +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] ifdef::VK_EXT_custom_border_color[] | code:uint32_t | pname:maxCustomBorderColorSamplers | `apiext:VK_EXT_custom_border_color` endif::VK_EXT_custom_border_color[] @@ -5270,9 +5281,9 @@ endif::VK_KHR_ray_tracing_pipeline[] ifdef::VK_VERSION_1_2,VK_KHR_timeline_semaphore[] | pname:maxTimelineSemaphoreValueDifference | - | 2^31^-1 | min endif::VK_VERSION_1_2,VK_KHR_timeline_semaphore[] -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] | pname:lineSubPixelPrecisionBits | - | 4 | min -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] ifdef::VK_NV_device_generated_commands[] | pname:maxGraphicsShaderGroupCount | - | 2^12^ | min | pname:maxIndirectSequenceCount | - | 2^20^ | min @@ -5624,4 +5635,21 @@ profile must: satisfy the following additional limit requirements: | pname:maxSubgroupSize | 4 | min | pname:maxPerStageDescriptorUpdateAfterBindInputAttachments | 7 | min |==== + + +[[profile-limits-roadmap-2024]] +=== Roadmap 2024 + +Implementations that claim support for the <> +profile must: satisfy the following additional limit requirements: + +[width="100%",cols="<35,<14,<11",options="header"] +|==== +| Limit | Supported Limit | Limit Type^1^ +| pname:shaderRoundingModeRTEFloat16 | ename:VK_TRUE | Boolean +| pname:shaderRoundingModeRTEFloat32 | ename:VK_TRUE | Boolean +| pname:timestampComputeAndGraphics | ename:VK_TRUE | Boolean +| pname:maxColorAttachments | 8 | min +| pname:maxBoundDescriptorSets | 7 | min +|==== endif::VK_VERSION_1_3[] diff --git a/chapters/pipelines.adoc b/chapters/pipelines.adoc old mode 100644 new mode 100755 index 1e521ca74..8412ae31f --- a/chapters/pipelines.adoc +++ b/chapters/pipelines.adoc @@ -539,8 +539,9 @@ endif::VKSC_VERSION_1_0[] that variable must: not have an array size greater than sname:VkPhysicalDeviceLimits::pname:maxCullDistances * [[VUID-VkPipelineShaderStageCreateInfo-maxCombinedClipAndCullDistances-00710]] - If the identified entry point includes any variables in its interface - that are declared with the code:ClipDistance or code:CullDistance + If the identified entry point includes variables in its interface that + are declared with the code:ClipDistance code:BuiltIn decoration and + variables in its interface that are declared with the code:CullDistance code:BuiltIn decoration, those variables must: not have array sizes which sum to more than sname:VkPhysicalDeviceLimits::pname:maxCombinedClipAndCullDistances @@ -1690,6 +1691,9 @@ ifdef::VK_EXT_fragment_density_map[] ename:VK_PIPELINE_RASTERIZATION_STATE_CREATE_FRAGMENT_DENSITY_MAP_ATTACHMENT_BIT_EXT flag endif::VK_EXT_fragment_density_map[] +ifdef::VK_KHR_dynamic_rendering_local_read[] + * slink:VkRenderingInputAttachmentIndexInfoKHR +endif::VK_KHR_dynamic_rendering_local_read[] If ifdef::VK_EXT_graphics_pipeline_library[] @@ -1743,6 +1747,9 @@ ifdef::VK_EXT_attachment_feedback_loop_layout[] ename:VK_PIPELINE_CREATE_DEPTH_STENCIL_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT flags endif::VK_EXT_attachment_feedback_loop_layout[] +ifdef::VK_KHR_dynamic_rendering_local_read[] + * slink:VkRenderingAttachmentLocationInfoKHR +endif::VK_KHR_dynamic_rendering_local_read[] If ifdef::VK_EXT_graphics_pipeline_library[] @@ -2528,7 +2535,7 @@ ifdef::VK_NV_mesh_shader,VK_EXT_mesh_shader[] a code:Xfb execution mode endif::VK_NV_mesh_shader,VK_EXT_mesh_shader[] endif::VK_EXT_transform_feedback[] -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] * [[VUID-VkGraphicsPipelineCreateInfo-lineRasterizationMode-02766]] If the pipeline requires <> and at least one of @@ -2536,23 +2543,23 @@ ifdef::VK_EXT_line_rasterization[] state>> or <>, and pname:pMultisampleState is not `NULL`, the pname:lineRasterizationMode member of a - slink:VkPipelineRasterizationLineStateCreateInfoEXT structure included + slink:VkPipelineRasterizationLineStateCreateInfoKHR structure included in the pname:pNext chain of pname:pRasterizationState is - ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT or - ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_KHR or + ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_KHR, then the pname:alphaToCoverageEnable, pname:alphaToOneEnable, and pname:sampleShadingEnable members of pname:pMultisampleState must: all be ename:VK_FALSE * [[VUID-VkGraphicsPipelineCreateInfo-stippledLineEnable-02767]] If the pipeline requires <>, the pname:stippledLineEnable member of - slink:VkPipelineRasterizationLineStateCreateInfoEXT is ename:VK_TRUE, + slink:VkPipelineRasterizationLineStateCreateInfoKHR is ename:VK_TRUE, and no element of the pname:pDynamicStates member of pname:pDynamicState is ename:VK_DYNAMIC_STATE_LINE_STIPPLE_EXT, then the pname:lineStippleFactor member of - slink:VkPipelineRasterizationLineStateCreateInfoEXT must: be in the + slink:VkPipelineRasterizationLineStateCreateInfoKHR must: be in the range [eq]#[1,256]# -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] ifdef::VK_KHR_ray_tracing_pipeline[] * [[VUID-VkGraphicsPipelineCreateInfo-flags-03372]] pname:flags must: not include @@ -3234,8 +3241,13 @@ ifdef::VK_EXT_mesh_shader[] include a mesh shader endif::VK_EXT_mesh_shader[] * [[VUID-VkGraphicsPipelineCreateInfo-renderPass-06061]] - If the pipeline requires <> and pname:renderPass is dlink:VK_NULL_HANDLE, + If +ifdef::VK_KHR_dynamic_rendering_local_read[] + the <> feature is not enabled, +endif::VK_KHR_dynamic_rendering_local_read[] + the pipeline requires <>, and pname:renderPass is dlink:VK_NULL_HANDLE, fragment shaders in pname:pStages must: not include the code:InputAttachment capability ifdef::VK_EXT_shader_tile_image[] @@ -3281,19 +3293,29 @@ ifdef::VK_EXT_rasterization_order_attachment_access,VK_ARM_rasterization_order_a ename:VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_EXT ifdef::VK_VERSION_1_3,VK_KHR_dynamic_rendering[] * [[VUID-VkGraphicsPipelineCreateInfo-flags-06482]] - If the pipeline requires <> and the pname:flags member of + If +ifdef::VK_KHR_dynamic_rendering_local_read[] + the <> feature is not enabled, +endif::VK_KHR_dynamic_rendering_local_read[] + the pipeline requires <>, and the pname:flags member of slink:VkPipelineColorBlendStateCreateInfo includes ename:VK_PIPELINE_COLOR_BLEND_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_BIT_EXT, - pname:renderpass must: not be dlink:VK_NULL_HANDLE - * [[VUID-VkGraphicsPipelineCreateInfo-flags-06483]] - If the pipeline requires <> and the pname:flags member of + pname:renderPass must: not be dlink:VK_NULL_HANDLE + * [[VUID-VkGraphicsPipelineCreateInfo-None-09526]] + If +ifdef::VK_KHR_dynamic_rendering_local_read[] + the <> feature is not enabled, +endif::VK_KHR_dynamic_rendering_local_read[] + the pipeline requires <>, and the pname:flags member of slink:VkPipelineDepthStencilStateCreateInfo includes ename:VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_EXT or ename:VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_EXT, - pname:renderpass must: not be dlink:VK_NULL_HANDLE + pname:renderPass must: not be dlink:VK_NULL_HANDLE ifdef::VK_AMD_mixed_attachment_samples,VK_NV_framebuffer_mixed_samples[] * [[VUID-VkGraphicsPipelineCreateInfo-pColorAttachmentSamples-06592]] If the <> and the pname:flags member of + fragment output interface state>>, pname:renderPass is not + dlink:VK_NULL_HANDLE, and the pname:flags member of slink:VkPipelineColorBlendStateCreateInfo includes ename:VK_PIPELINE_COLOR_BLEND_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_BIT_EXT pname:subpass must: have been created with ename:VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_COLOR_ACCESS_BIT_EXT - * [[VUID-VkGraphicsPipelineCreateInfo-flags-06485]] + * [[VUID-VkGraphicsPipelineCreateInfo-renderPass-09528]] If the pipeline requires <> and the pname:flags member of + fragment shader state>>, pname:renderPass is not dlink:VK_NULL_HANDLE, + and the pname:flags member of slink:VkPipelineDepthStencilStateCreateInfo includes ename:VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_EXT, pname:subpass must: have been created with ename:VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_EXT - * [[VUID-VkGraphicsPipelineCreateInfo-flags-06486]] + * [[VUID-VkGraphicsPipelineCreateInfo-renderPass-09529]] If the pipeline requires <> and the pname:flags member of + fragment shader state>>, pname:renderPass is not dlink:VK_NULL_HANDLE, + and the pname:flags member of slink:VkPipelineDepthStencilStateCreateInfo includes ename:VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_EXT, pname:subpass must: have been created with @@ -3430,11 +3455,10 @@ ifdef::VK_VERSION_1_3,VK_KHR_dynamic_rendering[] and pname:renderPass is not dlink:VK_NULL_HANDLE, endif::VK_VERSION_1_3,VK_KHR_dynamic_rendering[] pname:renderPass must: be a valid slink:VkRenderPass handle - * [[VUID-VkGraphicsPipelineCreateInfo-stageCount-06604]] + * [[VUID-VkGraphicsPipelineCreateInfo-stageCount-09530]] If the pipeline requires <> or - <>, - pname:stageCount must: be greater than `0` + pre-rasterization shader state>>, pname:stageCount must: be greater than + `0` ifdef::VK_KHR_pipeline_library[] * [[VUID-VkGraphicsPipelineCreateInfo-graphicsPipelineLibrary-06606]] ifdef::VK_EXT_graphics_pipeline_library[] @@ -3770,8 +3794,8 @@ endif::VK_VERSION_1_3,VK_KHR_dynamic_rendering[] If one element of slink:VkPipelineLibraryCreateInfoKHR::pname:pLibraries was created with ename:VK_GRAPHICS_PIPELINE_LIBRARY_FRAGMENT_OUTPUT_INTERFACE_BIT_EXT and - a value of pname:pMultisampleState->sampleShading equal ename:VK_TRUE, - and if a different element of + a value of pname:pMultisampleState->sampleShadingEnable equal + ename:VK_TRUE, and if a different element of slink:VkPipelineLibraryCreateInfoKHR::pname:pLibraries was created with ename:VK_GRAPHICS_PIPELINE_LIBRARY_FRAGMENT_SHADER_BIT_EXT, the pname:pMultisampleState used to create each library must: be @@ -3779,10 +3803,10 @@ endif::VK_VERSION_1_3,VK_KHR_dynamic_rendering[] * [[VUID-VkGraphicsPipelineCreateInfo-flags-06637]] If slink:VkGraphicsPipelineLibraryCreateInfoEXT::pname:flags includes ename:VK_GRAPHICS_PIPELINE_LIBRARY_FRAGMENT_OUTPUT_INTERFACE_BIT_EXT, - pname:pMultisampleState->sampleShading is ename:VK_TRUE, and an element - of slink:VkPipelineLibraryCreateInfoKHR::pname:pLibraries was created - with ename:VK_GRAPHICS_PIPELINE_LIBRARY_FRAGMENT_SHADER_BIT_EXT, the - pname:pMultisampleState used to create that library must: be + pname:pMultisampleState->sampleShadingEnable is ename:VK_TRUE, and an + element of slink:VkPipelineLibraryCreateInfoKHR::pname:pLibraries was + created with ename:VK_GRAPHICS_PIPELINE_LIBRARY_FRAGMENT_SHADER_BIT_EXT, + the pname:pMultisampleState used to create that library must: be _identically defined_ pname:pMultisampleState ifdef::VK_KHR_fragment_shading_rate[] * [[VUID-VkGraphicsPipelineCreateInfo-flags-06638]] @@ -4452,6 +4476,23 @@ ifdef::VK_KHR_fragment_shading_rate[] code:PrimitiveShadingRateKHR built-in endif::VK_KHR_fragment_shading_rate[] endif::VK_ANDROID_external_format_resolve[] +ifdef::VK_KHR_dynamic_rendering_local_read[] + * [[VUID-VkGraphicsPipelineCreateInfo-renderPass-09531]] + If the pipeline is being created with + <> + and <>, and the value of pname:renderPass is dlink:VK_NULL_HANDLE, + slink:VkRenderingInputAttachmentIndexInfoKHR::pname:colorAttachmentCount + must: be equal to + slink:VkPipelineRenderingCreateInfo::pname:colorAttachmentCount + * [[VUID-VkGraphicsPipelineCreateInfo-renderPass-09532]] + If the pipeline is being created with + <>, + and the value of pname:renderPass is dlink:VK_NULL_HANDLE, + slink:VkRenderingAttachmentLocationInfoKHR::pname:colorAttachmentCount + must: be equal to + slink:VkPipelineRenderingCreateInfo::pname:colorAttachmentCount +endif::VK_KHR_dynamic_rendering_local_read[] **** ifdef::VKSC_VERSION_1_0[] ifdef::hidden[] @@ -4517,6 +4558,13 @@ in the pname:pNext chain of slink:VkGraphicsPipelineCreateInfo, defining the external format of the resolve attachment that will be used. endif::VK_ANDROID_external_format_resolve[] +.Valid Usage +**** + * [[VUID-VkPipelineRenderingCreateInfo-colorAttachmentCount-09533]] + pname:colorAttachmentCount must: be less than or equal to + <> +**** + include::{generated}/validity/structs/VkPipelineRenderingCreateInfo.adoc[] -- endif::VK_VERSION_1_3,VK_KHR_dynamic_rendering[] @@ -5262,15 +5310,15 @@ ifdef::VK_NV_shading_rate_image[] ignored and must: be set dynamically with flink:vkCmdSetCoarseSampleOrderNV before any drawing commands. endif::VK_NV_shading_rate_image[] -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] * ename:VK_DYNAMIC_STATE_LINE_STIPPLE_EXT specifies that the pname:lineStippleFactor and pname:lineStipplePattern state in - slink:VkPipelineRasterizationLineStateCreateInfoEXT will be ignored and - must: be set dynamically with flink:vkCmdSetLineStippleEXT before any + slink:VkPipelineRasterizationLineStateCreateInfoKHR will be ignored and + must: be set dynamically with flink:vkCmdSetLineStippleKHR before any draws are performed with a pipeline state with - slink:VkPipelineRasterizationLineStateCreateInfoEXT member + slink:VkPipelineRasterizationLineStateCreateInfoKHR member pname:stippledLineEnable set to ename:VK_TRUE. -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] ifdef::VK_VERSION_1_3,VK_EXT_extended_dynamic_state[] * ename:VK_DYNAMIC_STATE_CULL_MODE specifies that the pname:cullMode state in slink:VkPipelineRasterizationStateCreateInfo will be ignored and @@ -5492,18 +5540,18 @@ ifdef::VK_EXT_provoking_vertex[] ignored and must: be set dynamically with flink:vkCmdSetProvokingVertexModeEXT before any draw call. endif::VK_EXT_provoking_vertex[] -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] * ename:VK_DYNAMIC_STATE_LINE_RASTERIZATION_MODE_EXT specifies that the pname:lineRasterizationMode state in - slink:VkPipelineRasterizationLineStateCreateInfoEXT will be ignored and + slink:VkPipelineRasterizationLineStateCreateInfoKHR will be ignored and must: be set dynamically with flink:vkCmdSetLineRasterizationModeEXT before any draw call. * ename:VK_DYNAMIC_STATE_LINE_STIPPLE_ENABLE_EXT specifies that the pname:stippledLineEnable state in - slink:VkPipelineRasterizationLineStateCreateInfoEXT will be ignored and + slink:VkPipelineRasterizationLineStateCreateInfoKHR will be ignored and must: be set dynamically with flink:vkCmdSetLineStippleEnableEXT before any draw call. -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] ifdef::VK_EXT_depth_clip_control[] * ename:VK_DYNAMIC_STATE_DEPTH_CLIP_NEGATIVE_ONE_TO_ONE_EXT specifies that the pname:negativeOneToOne state in diff --git a/chapters/primsrast.adoc b/chapters/primsrast.adoc index db8f9b185..4d8947f63 100644 --- a/chapters/primsrast.adoc +++ b/chapters/primsrast.adoc @@ -2625,21 +2625,27 @@ vertex for the point. [[primsrast-lines]] == Line Segments -ifdef::VK_EXT_line_rasterization[] -[open,refpage='VkPipelineRasterizationLineStateCreateInfoEXT',desc='Structure specifying parameters of a newly created pipeline line rasterization state',type='structs'] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] +[open,refpage='VkPipelineRasterizationLineStateCreateInfoKHR',desc='Structure specifying parameters of a newly created pipeline line rasterization state',type='structs',alias='VkPipelineRasterizationLineStateCreateInfoEXT'] -- Line segment rasterization options are controlled by the -slink:VkPipelineRasterizationLineStateCreateInfoEXT structure. +slink:VkPipelineRasterizationLineStateCreateInfoKHR structure. -The sname:VkPipelineRasterizationLineStateCreateInfoEXT structure is defined +The sname:VkPipelineRasterizationLineStateCreateInfoKHR structure is defined as: +include::{generated}/api/structs/VkPipelineRasterizationLineStateCreateInfoKHR.adoc[] + +ifdef::VK_EXT_line_rasterization[] +or the equivalent + include::{generated}/api/structs/VkPipelineRasterizationLineStateCreateInfoEXT.adoc[] +endif::VK_EXT_line_rasterization[] * pname:sType is a elink:VkStructureType value identifying this structure. * pname:pNext is `NULL` or a pointer to a structure extending this structure. - * pname:lineRasterizationMode is a elink:VkLineRasterizationModeEXT value + * pname:lineRasterizationMode is a elink:VkLineRasterizationModeKHR value selecting the style of line rasterization. * pname:stippledLineEnable enables <>. @@ -2655,69 +2661,75 @@ pname:lineStippleFactor and pname:lineStipplePattern are ignored. **** * [[VUID-VkPipelineRasterizationLineStateCreateInfoEXT-lineRasterizationMode-02768]] If pname:lineRasterizationMode is - ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_KHR, then the <> feature must: be enabled * [[VUID-VkPipelineRasterizationLineStateCreateInfoEXT-lineRasterizationMode-02769]] If pname:lineRasterizationMode is - ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_KHR, then the <> feature must: be enabled * [[VUID-VkPipelineRasterizationLineStateCreateInfoEXT-lineRasterizationMode-02770]] If pname:lineRasterizationMode is - ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_KHR, then the <> feature must: be enabled * [[VUID-VkPipelineRasterizationLineStateCreateInfoEXT-stippledLineEnable-02771]] If pname:stippledLineEnable is ename:VK_TRUE and pname:lineRasterizationMode is - ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_KHR, then the <> feature must: be enabled * [[VUID-VkPipelineRasterizationLineStateCreateInfoEXT-stippledLineEnable-02772]] If pname:stippledLineEnable is ename:VK_TRUE and pname:lineRasterizationMode is - ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_KHR, then the <> feature must: be enabled * [[VUID-VkPipelineRasterizationLineStateCreateInfoEXT-stippledLineEnable-02773]] If pname:stippledLineEnable is ename:VK_TRUE and pname:lineRasterizationMode is - ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_KHR, then the <> feature must: be enabled * [[VUID-VkPipelineRasterizationLineStateCreateInfoEXT-stippledLineEnable-02774]] If pname:stippledLineEnable is ename:VK_TRUE and pname:lineRasterizationMode is - ename:VK_LINE_RASTERIZATION_MODE_DEFAULT_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_DEFAULT_KHR, then the <> feature must: be enabled and slink:VkPhysicalDeviceLimits::pname:strictLines must: be ename:VK_TRUE **** -include::{generated}/validity/structs/VkPipelineRasterizationLineStateCreateInfoEXT.adoc[] +include::{generated}/validity/structs/VkPipelineRasterizationLineStateCreateInfoKHR.adoc[] -- -[open,refpage='VkLineRasterizationModeEXT',desc='Line rasterization modes',type='enums'] +[open,refpage='VkLineRasterizationModeKHR',desc='Line rasterization modes',type='enums',alias='VkLineRasterizationModeEXT'] -- Possible values of -slink:VkPipelineRasterizationLineStateCreateInfoEXT::pname:lineRasterizationMode +slink:VkPipelineRasterizationLineStateCreateInfoKHR::pname:lineRasterizationMode are: +include::{generated}/api/enums/VkLineRasterizationModeKHR.adoc[] + +ifdef::VK_EXT_line_rasterization[] +or the equivalent + include::{generated}/api/enums/VkLineRasterizationModeEXT.adoc[] +endif::VK_EXT_line_rasterization[] - * ename:VK_LINE_RASTERIZATION_MODE_DEFAULT_EXT is equivalent to - ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT if + * ename:VK_LINE_RASTERIZATION_MODE_DEFAULT_KHR is equivalent to + ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_KHR if slink:VkPhysicalDeviceLimits::pname:strictLines is ename:VK_TRUE, otherwise lines are drawn as non-pname:strictLines parallelograms. Both of these modes are defined in <>. - * ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT specifies lines drawn + * ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_KHR specifies lines drawn as if they were rectangles extruded from the line - * ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT specifies lines drawn by + * ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_KHR specifies lines drawn by determining which pixel diamonds the line intersects and exits, as defined in <>. - * ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT specifies lines + * ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_KHR specifies lines drawn if they were rectangles extruded from the line, with alpha falloff, as defined in <>. -- @@ -2748,7 +2760,7 @@ ename:VK_DYNAMIC_STATE_LINE_RASTERIZATION_MODE_EXT set in slink:VkPipelineDynamicStateCreateInfo::pname:pDynamicStates. endif::VK_EXT_extended_dynamic_state3[] Otherwise, this state is specified by the -slink:VkPipelineRasterizationLineStateCreateInfoEXT::pname:lineRasterizationMode +slink:VkPipelineRasterizationLineStateCreateInfoKHR::pname:lineRasterizationMode value used to create the currently active pipeline. :refpage: vkCmdSetLineRasterizationModeEXT @@ -2759,17 +2771,17 @@ value used to create the currently active pipeline. include::{chapters}/commonvalidity/dynamic_state3_feature_common.adoc[] * [[VUID-vkCmdSetLineRasterizationModeEXT-lineRasterizationMode-07418]] If pname:lineRasterizationMode is - ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_KHR, then the <> feature must: be enabled * [[VUID-vkCmdSetLineRasterizationModeEXT-lineRasterizationMode-07419]] If pname:lineRasterizationMode is - ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_KHR, then the <> feature must: be enabled * [[VUID-vkCmdSetLineRasterizationModeEXT-lineRasterizationMode-07420]] If pname:lineRasterizationMode is - ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT, then the + ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_KHR, then the <> feature must: be enabled **** @@ -2799,7 +2811,7 @@ ename:VK_DYNAMIC_STATE_LINE_STIPPLE_ENABLE_EXT set in slink:VkPipelineDynamicStateCreateInfo::pname:pDynamicStates. endif::VK_EXT_extended_dynamic_state3[] Otherwise, this state is specified by the -slink:VkPipelineRasterizationLineStateCreateInfoEXT::pname:stippledLineEnable +slink:VkPipelineRasterizationLineStateCreateInfoKHR::pname:stippledLineEnable value used to create the currently active pipeline. :refpage: vkCmdSetLineStippleEnableEXT @@ -2815,7 +2827,7 @@ include::{generated}/validity/protos/vkCmdSetLineStippleEnableEXT.adoc[] endif::VK_EXT_extended_dynamic_state3,VK_EXT_shader_object[] -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] [open,refpage='vkCmdSetLineWidth',desc='Set line width dynamically for a command buffer',type='protos'] -- @@ -2866,14 +2878,14 @@ endif::VK_EXT_fragment_density_map[] [[primsrast-lines-basic]] === Basic Line Segment Rasterization -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] If the pname:lineRasterizationMode member of -slink:VkPipelineRasterizationLineStateCreateInfoEXT is -ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT, rasterized -endif::VK_EXT_line_rasterization[] -ifndef::VK_EXT_line_rasterization[] +slink:VkPipelineRasterizationLineStateCreateInfoKHR is +ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_KHR, rasterized +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] +ifndef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] Rasterized -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] line segments produce fragments which intersect a rectangle centered on the line segment. Two of the edges are parallel to the specified line segment; each is at a @@ -2946,14 +2958,14 @@ Interpolation of fragment shader input values are determined by The above description documents the preferred method of line rasterization, and must: be used when -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] pname:lineRasterizationMode is -ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT. -endif::VK_EXT_line_rasterization[] -ifndef::VK_EXT_line_rasterization[] +ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_KHR. +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] +ifndef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] the implementation advertises the pname:strictLines limit in slink:VkPhysicalDeviceLimits as ename:VK_TRUE. -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] ifndef::VK_KHR_maintenance5[] When @@ -2966,10 +2978,10 @@ ifdef::VK_IMG_relaxed_line_rasterization[] or the <> feature is enabled, endif::VK_IMG_relaxed_line_rasterization[] -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] and when the pname:lineRasterizationMode is -ename:VK_LINE_RASTERIZATION_MODE_DEFAULT_EXT, -endif::VK_EXT_line_rasterization[] +ename:VK_LINE_RASTERIZATION_MODE_DEFAULT_KHR, +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] the edges of the lines are generated as a parallelogram surrounding the original line. The major axis is chosen by noting the axis in which there is the greatest @@ -3043,12 +3055,12 @@ endif::VK_KHR_maintenance5[] [[primsrast-lines-bresenham]] === Bresenham Line Segment Rasterization -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] If pname:lineRasterizationMode is -ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT, then the following rules +ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_KHR, then the following rules replace the line rasterization rules defined in <>. -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] Non-strict lines may: also follow these rasterization rules for non-antialiased lines. @@ -3177,12 +3189,12 @@ those pixels (unless masked out or killed). ==== -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] [[primsrast-lines-stipple]] === Line Stipple If the pname:stippledLineEnable member of -slink:VkPipelineRasterizationLineStateCreateInfoEXT is ename:VK_TRUE, then +slink:VkPipelineRasterizationLineStateCreateInfoKHR is ename:VK_TRUE, then lines are rasterized with a _line stipple_ determined by pname:lineStippleFactor and pname:lineStipplePattern. pname:lineStipplePattern is an unsigned 16-bit integer that determines which @@ -3209,12 +3221,12 @@ The bits of _p_ are numbered with 0 being the least significant and 15 being the most significant. The initial value of _s_ is zero. -For ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT lines, _s_ is incremented +For ename:VK_LINE_RASTERIZATION_MODE_BRESENHAM_KHR lines, _s_ is incremented after production of each fragment of a line segment (fragments are produced in order, beginning at the starting point and working towards the ending point). -For ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT and -ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT lines, the +For ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_KHR and +ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_KHR lines, the rectangular region is subdivided into adjacent unit-length rectangles, and s is incremented once for each rectangle. Rectangles with a value of _s_ such that the _b_'th bit of _p_ is zero are @@ -3230,12 +3242,20 @@ every line segment in a group of independent segments. If the line segment has been clipped, then the value of _s_ at the beginning of the line segment is implementation-dependent. -[open,refpage='vkCmdSetLineStippleEXT',desc='Set line stipple dynamically for a command buffer',type='protos'] +[open,refpage='vkCmdSetLineStippleKHR',desc='Set line stipple dynamically for a command buffer',type='protos',alias='vkCmdSetLineStippleEXT'] -- To <> the line stipple state, call: +ifdef::VK_KHR_line_rasterization[] +include::{generated}/api/protos/vkCmdSetLineStippleKHR.adoc[] + +ifdef::VK_EXT_line_rasterization[or the equivalent command] +endif::VK_KHR_line_rasterization[] + +ifdef::VK_EXT_line_rasterization[] include::{generated}/api/protos/vkCmdSetLineStippleEXT.adoc[] +endif::VK_EXT_line_rasterization[] * pname:commandBuffer is the command buffer into which the command will be recorded. @@ -3250,9 +3270,9 @@ when the graphics pipeline is created with ename:VK_DYNAMIC_STATE_LINE_STIPPLE_EXT set in slink:VkPipelineDynamicStateCreateInfo::pname:pDynamicStates. Otherwise, this state is specified by the -slink:VkPipelineRasterizationLineStateCreateInfoEXT::pname:lineStippleFactor +slink:VkPipelineRasterizationLineStateCreateInfoKHR::pname:lineStippleFactor and -slink:VkPipelineRasterizationLineStateCreateInfoEXT::pname:lineStipplePattern +slink:VkPipelineRasterizationLineStateCreateInfoKHR::pname:lineStipplePattern values used to create the currently active pipeline. .Valid Usage @@ -3261,7 +3281,7 @@ values used to create the currently active pipeline. pname:lineStippleFactor must: be in the range [eq]#[1,256]# **** -include::{generated}/validity/protos/vkCmdSetLineStippleEXT.adoc[] +include::{generated}/validity/protos/vkCmdSetLineStippleKHR.adoc[] -- @@ -3269,10 +3289,10 @@ include::{generated}/validity/protos/vkCmdSetLineStippleEXT.adoc[] === Smooth Lines If the pname:lineRasterizationMode member of -slink:VkPipelineRasterizationLineStateCreateInfoEXT is -ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT, then lines are +slink:VkPipelineRasterizationLineStateCreateInfoKHR is +ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_KHR, then lines are considered to be rectangles using the same geometry as for -ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT lines. +ename:VK_LINE_RASTERIZATION_MODE_RECTANGULAR_KHR lines. The rules for determining which pixels are covered are implementation-dependent, and may: include nearby pixels where no sample locations are covered or where the rectangle does not intersect the pixel at @@ -3290,7 +3310,7 @@ The details of the rasterization rules and area calculation are left intentionally vague, to allow implementations to generate coverage and values that are aesthetically pleasing. ==== -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] [[primsrast-polygons]] diff --git a/chapters/queries.adoc b/chapters/queries.adoc index 4e9a56eb7..4fcb608be 100644 --- a/chapters/queries.adoc +++ b/chapters/queries.adoc @@ -137,6 +137,9 @@ endif::VK_EXT_mesh_shader[] If pname:queryType is ename:VK_QUERY_TYPE_PIPELINE_STATISTICS, pname:pipelineStatistics must: be a valid combination of elink:VkQueryPipelineStatisticFlagBits values + * [[VUID-VkQueryPoolCreateInfo-queryType-09534]] + If pname:queryType is ename:VK_QUERY_TYPE_PIPELINE_STATISTICS, + pname:pipelineStatistics must: not be zero ifdef::VK_KHR_performance_query[] * [[VUID-VkQueryPoolCreateInfo-queryType-03222]] If pname:queryType is ename:VK_QUERY_TYPE_PERFORMANCE_QUERY_KHR, the diff --git a/chapters/renderpass.adoc b/chapters/renderpass.adoc index 410e4d6bc..cb740002d 100644 --- a/chapters/renderpass.adoc +++ b/chapters/renderpass.adoc @@ -663,6 +663,7 @@ ifdef::VK_KHR_fragment_shading_rate[] endif::VK_KHR_fragment_shading_rate[] endif::VK_ANDROID_external_format_resolve[] ifdef::VK_ARM_render_pass_striped[] + * [[VUID-VkRenderingInfo-pNext-09535]] If the pname:pNext chain contains a slink:VkRenderPassStripeBeginInfoARM structure, the union of stripe areas defined by the elements of slink:VkRenderPassStripeInfoARM::pname:pStripeInfos must: cover the @@ -5317,6 +5318,12 @@ Images that can: be used with the framebuffer when beginning a render pass, as specified by slink:VkRenderPassAttachmentBeginInfo, must: be created with parameters that are identical to those specified here. +.Valid Usage +**** + * [[VUID-VkFramebufferAttachmentImageInfo-viewFormatCount-09536]] + If pname:viewFormatCount is not 0, each element of pname:pViewFormats + must: not be ename:VK_FORMAT_UNDEFINED +**** include::{generated}/validity/structs/VkFramebufferAttachmentImageInfo.adoc[] -- @@ -5404,9 +5411,9 @@ that attachment or an alias. Because load operations always happen first, external synchronization with attachment access only needs to synchronize the load operations with previous commands; not the operations within the render pass instance. -ifdef::VK_EXT_load_store_op_none[] -This does not apply when using ename:VK_ATTACHMENT_LOAD_OP_NONE_EXT. -endif::VK_EXT_load_store_op_none[] +ifdef::VK_KHR_load_store_op_none,VK_EXT_load_store_op_none[] +This does not apply when using ename:VK_ATTACHMENT_LOAD_OP_NONE_KHR. +endif::VK_KHR_load_store_op_none,VK_EXT_load_store_op_none[] ==== Load operations only update values within the defined render area for the @@ -5457,11 +5464,11 @@ include::{generated}/api/enums/VkAttachmentLoadOp.adoc[] ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT. For attachments with a color format, this uses the access type ename:VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT. -ifdef::VK_EXT_load_store_op_none[] - * ename:VK_ATTACHMENT_LOAD_OP_NONE_EXT specifies that the previous +ifdef::VK_KHR_load_store_op_none,VK_EXT_load_store_op_none[] + * ename:VK_ATTACHMENT_LOAD_OP_NONE_KHR specifies that the previous contents of the image will be undefined: inside the render pass. No access type is used as the image is not accessed. -endif::VK_EXT_load_store_op_none[] +endif::VK_KHR_load_store_op_none,VK_EXT_load_store_op_none[] -- [[renderpass-precision]] @@ -5501,9 +5508,9 @@ Because store operations always happen after other accesses in a render pass instance, external synchronization with attachment access in an earlier render pass only needs to synchronize with the store operations; not the operations within the render pass instance. -ifdef::VK_VERSION_1_3,VK_EXT_load_store_op_none,VK_KHR_dynamic_rendering,VK_QCOM_render_pass_store_ops[] +ifdef::VK_VERSION_1_3,VK_KHR_load_store_op_none,VK_EXT_load_store_op_none,VK_KHR_dynamic_rendering,VK_QCOM_render_pass_store_ops[] This does not apply when using ename:VK_ATTACHMENT_STORE_OP_NONE. -endif::VK_VERSION_1_3,VK_EXT_load_store_op_none,VK_KHR_dynamic_rendering,VK_QCOM_render_pass_store_ops[] +endif::VK_VERSION_1_3,VK_KHR_load_store_op_none,VK_EXT_load_store_op_none,VK_KHR_dynamic_rendering,VK_QCOM_render_pass_store_ops[] ==== @@ -5550,14 +5557,14 @@ include::{generated}/api/enums/VkAttachmentStoreOp.adoc[] ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT. For attachments with a color format, this uses the access type ename:VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT. -ifdef::VK_VERSION_1_3,VK_EXT_load_store_op_none,VK_KHR_dynamic_rendering,VK_QCOM_render_pass_store_ops[] +ifdef::VK_VERSION_1_3,VK_KHR_load_store_op_none,VK_EXT_load_store_op_none,VK_KHR_dynamic_rendering,VK_QCOM_render_pass_store_ops[] * ename:VK_ATTACHMENT_STORE_OP_NONE specifies the contents within the render area are not accessed by the store operation as long as no values are written to the attachment during the render pass. If values are written during the render pass, this behaves identically to ename:VK_ATTACHMENT_STORE_OP_DONT_CARE and with matching access semantics. -endif::VK_VERSION_1_3,VK_EXT_load_store_op_none,VK_KHR_dynamic_rendering,VK_QCOM_render_pass_store_ops[] +endif::VK_VERSION_1_3,VK_KHR_load_store_op_none,VK_EXT_load_store_op_none,VK_KHR_dynamic_rendering,VK_QCOM_render_pass_store_ops[] [NOTE] .Note @@ -5880,6 +5887,21 @@ ifdef::VK_EXT_attachment_feedback_loop_layout[] created with a pname:usage value the ename:VK_IMAGE_USAGE_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT usage bit endif::VK_EXT_attachment_feedback_loop_layout[] +ifdef::VK_KHR_dynamic_rendering_local_read[] + * [[VUID-vkCmdBeginRenderPass-initialLayout-09537]] + If any of the pname:initialLayout or pname:finalLayout member of the + sname:VkAttachmentDescription structures or the pname:layout member of + the sname:VkAttachmentReference structures specified when creating the + render pass specified in the pname:renderPass member of + pname:pRenderPassBegin is ename:VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR + then the corresponding attachment image view of the framebuffer + specified in the pname:framebuffer member of pname:pRenderPassBegin + must: have been created with a pname:usage value including either + ename:VK_IMAGE_USAGE_STORAGE_BIT, or both + ename:VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT and either of + ename:VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT or + ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT +endif::VK_KHR_dynamic_rendering_local_read[] **** include::{generated}/validity/protos/vkCmdBeginRenderPass.adoc[] @@ -6062,6 +6084,21 @@ ifdef::VK_EXT_attachment_feedback_loop_layout[] created with a pname:usage value the ename:VK_IMAGE_USAGE_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT usage bit endif::VK_EXT_attachment_feedback_loop_layout[] +ifdef::VK_KHR_dynamic_rendering_local_read[] + * [[VUID-vkCmdBeginRenderPass2-initialLayout-09538]] + If any of the pname:initialLayout or pname:finalLayout member of the + sname:VkAttachmentDescription structures or the pname:layout member of + the sname:VkAttachmentReference structures specified when creating the + render pass specified in the pname:renderPass member of + pname:pRenderPassBegin is ename:VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR + then the corresponding attachment image view of the framebuffer + specified in the pname:framebuffer member of pname:pRenderPassBegin + must: have been created with a pname:usage value including either + ename:VK_IMAGE_USAGE_STORAGE_BIT, or both + ename:VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT and either of + ename:VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT or + ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT +endif::VK_KHR_dynamic_rendering_local_read[] **** include::{generated}/validity/protos/vkCmdBeginRenderPass2.adoc[] @@ -6395,6 +6432,7 @@ ifdef::VK_QCOM_multiview_per_view_render_areas[] render areas. endif::VK_QCOM_multiview_per_view_render_areas[] ifdef::VK_ARM_render_pass_striped[] + * [[VUID-VkRenderPassBeginInfo-pNext-09539]] If the pname:pNext chain contains a slink:VkRenderPassStripeBeginInfoARM structure, the union of stripe areas defined by the elements of slink:VkRenderPassStripeInfoARM::pname:pStripeInfos must: cover the @@ -7199,12 +7237,12 @@ In practice, many applications have shipped reading samples outside of the covered fragment without any observable issue, but there is no guarantee that this will always work, and it is not advisable to rely on this in new or re-worked code bases. -ifdef::VK_VERSION_1_3,VK_EXT_load_store_op_none,VK_QCOM_render_pass_store_ops,VK_KHR_dynamic_rendering[] +ifdef::VK_VERSION_1_3,VK_KHR_load_store_op_none,VK_EXT_load_store_op_none,VK_QCOM_render_pass_store_ops,VK_KHR_dynamic_rendering[] As ename:VK_ATTACHMENT_STORE_OP_NONE is guaranteed to perform no writes, applications wishing to read an image as both an attachment and a non-attachment should make use of this store operation, coupled with a load operation that also performs no writes. -endif::VK_VERSION_1_3,VK_EXT_load_store_op_none,VK_QCOM_render_pass_store_ops,VK_KHR_dynamic_rendering[] +endif::VK_VERSION_1_3,VK_KHR_load_store_op_none,VK_EXT_load_store_op_none,VK_QCOM_render_pass_store_ops,VK_KHR_dynamic_rendering[] === Non-overlapping Access Between Resources diff --git a/chapters/resources.adoc b/chapters/resources.adoc index 323a33983..ba5fb113b 100644 --- a/chapters/resources.adoc +++ b/chapters/resources.adoc @@ -2757,6 +2757,13 @@ If pname:viewFormatCount is zero, pname:pViewFormats is ignored and the image is created as if the sname:VkImageFormatListCreateInfo structure were not included in the pname:pNext chain of slink:VkImageCreateInfo. +.Valid Usage +**** + * [[VUID-VkImageFormatListCreateInfo-viewFormatCount-09540]] + If pname:viewFormatCount is not 0, each element of pname:pViewFormats + must: not be ename:VK_FORMAT_UNDEFINED +**** + include::{generated}/validity/structs/VkImageFormatListCreateInfo.adoc[] -- endif::VK_VERSION_1_2,VK_KHR_image_format_list[] @@ -4439,6 +4446,16 @@ ifdef::VK_EXT_attachment_feedback_loop_layout[] ename:VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT or ename:VK_IMAGE_USAGE_SAMPLED_BIT usage bits enabled. endif::VK_EXT_attachment_feedback_loop_layout[] +ifdef::VK_KHR_dynamic_rendering_local_read[] + * ename:VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR must: only be used as + either a storage image, or a color or depth/stencil attachment and an + input attachment. + This layout is valid only for image subresources of images created with + either ename:VK_IMAGE_USAGE_STORAGE_BIT, or both + ename:VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT and either of + ename:VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT or + ename:VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT. +endif::VK_KHR_dynamic_rendering_local_read[] The layout of each image subresource is not a state of the image subresource itself, but is rather a property of how the data in memory is organized, and @@ -6529,6 +6546,13 @@ flink:vkCmdCopyMemoryToAccelerationStructureKHR with a pname:mode of ename:VK_COPY_ACCELERATION_STRUCTURE_MODE_DESERIALIZE_KHR during replay. ==== +[NOTE] +.Note +==== +Memory does not need to be bound to the underlying buffer when +flink:vkCreateAccelerationStructureKHR is called. +==== + The input buffers passed to acceleration structure build commands will be referenced by the implementation for the duration of the command. After the command completes, the acceleration structure may: hold a @@ -7623,6 +7647,14 @@ ename:VK_ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR. If pname:device was created with multiple physical devices, then the <> feature must: be enabled + * [[VUID-vkGetAccelerationStructureDeviceAddressKHR-pInfo-09541]] + If the buffer on which pname:pInfo->accelerationStructure was placed is + non-sparse then it must: be bound completely and contiguously to a + single sname:VkDeviceMemory object + * [[VUID-vkGetAccelerationStructureDeviceAddressKHR-pInfo-09542]] + The buffer on which pname:pInfo->accelerationStructure was placed must: + have been created with the + ename:VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT usage flag **** include::{generated}/validity/protos/vkGetAccelerationStructureDeviceAddressKHR.adoc[] diff --git a/chapters/shaders.adoc b/chapters/shaders.adoc index 3aa83d03b..1ff9b6f38 100644 --- a/chapters/shaders.adoc +++ b/chapters/shaders.adoc @@ -416,10 +416,12 @@ endif::VK_NV_mesh_shader,VK_EXT_mesh_shader[] sname:VkPhysicalDeviceLimits::pname:maxCullDistances * [[VUID-VkShaderCreateInfoEXT-pCode-08450]] If pname:codeType is ename:VK_SHADER_CODE_TYPE_SPIRV_EXT, and the - identified entry point includes any variables in its interface that are - declared with the code:ClipDistance or code:CullDistance code:BuiltIn - decoration, those variables must: not have array sizes which sum to more - than sname:VkPhysicalDeviceLimits::pname:maxCombinedClipAndCullDistances + identified entry point includes variables in its interface that are + declared with the code:ClipDistance code:BuiltIn decoration and + variables in its interface that are declared with the code:CullDistance + code:BuiltIn decoration, those variables must: not have array sizes + which sum to more than + sname:VkPhysicalDeviceLimits::pname:maxCombinedClipAndCullDistances * [[VUID-VkShaderCreateInfoEXT-pCode-08451]] If pname:codeType is ename:VK_SHADER_CODE_TYPE_SPIRV_EXT, and the identified entry point includes any variable in its interface that is @@ -1021,10 +1023,11 @@ have been called in the command buffer prior to drawing: * flink:vkCmdSetProvokingVertexModeEXT endif::VK_EXT_provoking_vertex[] -ifdef::VK_EXT_line_rasterization[] -If the `apiext:VK_EXT_line_rasterization` extension is enabled on the -device, and pname:rasterizerDiscardEnable is ename:VK_FALSE, and if -pname:polygonMode is ename:VK_POLYGON_MODE_LINE or a shader is bound to the +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] +If the `apiext:VK_KHR_line_rasterization` or +`apiext:VK_EXT_line_rasterization` extension is enabled on the device, and +pname:rasterizerDiscardEnable is ename:VK_FALSE, and if pname:polygonMode is +ename:VK_POLYGON_MODE_LINE or a shader is bound to the ename:VK_SHADER_STAGE_VERTEX_BIT stage and pname:primitiveTopology is a line topology or a shader which outputs line primitives is bound to the ename:VK_SHADER_STAGE_TESSELLATION_EVALUATION_BIT or @@ -1033,9 +1036,9 @@ been called in the command buffer prior to drawing: * flink:vkCmdSetLineRasterizationModeEXT * flink:vkCmdSetLineStippleEnableEXT - * flink:vkCmdSetLineStippleEXT, if pname:stippledLineEnable is + * flink:vkCmdSetLineStippleKHR, if pname:stippledLineEnable is ename:VK_TRUE -endif::VK_EXT_line_rasterization[] +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] ifdef::VK_EXT_depth_clip_control[] If the <> feature is @@ -2930,6 +2933,18 @@ size groups of invocations and the cluster size must: be known at pipeline creation time. The operations supported are add, mul, min, max, and, or, xor. +[[shaders-group-operations-rotate]] +=== Rotate Group Operations + +The rotate group operations allow invocations to read values from other +invocations within the group relative to the current invocation and modulo +the size of the group. +Clustered rotate group operations perform the same operation within +individual partitions of a group. + +The partitions for clustered rotate group operations are consecutive +power-of-two size groups of invocations and the cluster size must: be known +at pipeline creation time. [[shaders-quad-operations]] == Quad Group Operations @@ -2941,8 +2956,9 @@ Whilst these instructions do include a code:Scope parameter, this scope is always overridden; only the <> is included in its execution scope. -Fragment shaders that statically execute quad group operations must: launch -sufficient invocations to ensure their correct operation; additional +Fragment shaders that statically execute either +code:OpGroupNonUniformQuadBroadcast or code:OpGroupNonUniformQuadSwap must: +launch sufficient invocations to ensure their correct operation; additional <> are launched for framebuffer locations not covered by rasterized fragments if necessary. @@ -2964,22 +2980,36 @@ Derivative operations calculate the partial derivative for an expression Derivative operations operate on a set of invocations known as a _derivative group_ as defined in the <>. -A derivative group is equivalent to + +A derivative group in a fragment shader is equivalent to the +ifdef::VK_KHR_shader_quad_control[] +<> if the code:QuadDerivativesKHR +execution mode is specified, otherwise it is equivalent to the +endif::VK_KHR_shader_quad_control[] +<>. ifdef::VK_NV_compute_shader_derivatives[] -the <> for a compute shader -invocation, or +A derivative group in a compute shader is equivalent to the +<>. endif::VK_NV_compute_shader_derivatives[] -the <> for a fragment -shader invocation. Derivatives are calculated assuming that [eq]#P# is piecewise linear and continuous within the derivative group. -All dynamic instances of explicit derivative instructions (code:OpDPdx*, -code:OpDPdy*, and code:OpFwidth*) must: be executed in control flow that is -uniform within a derivative group. -For other derivative operations, results are undefined: if a dynamic -instance is executed in control flow that is not uniform within the -derivative group. + +The following control-flow restrictions apply to derivative operations: + +ifdef::VK_KHR_shader_quad_control[] + * If the code:QuadDerivativesKHR execution mode is specified, dynamic + instances of any derivative operations must: be executed in control flow + that is uniform within the current <>. + * If the code:QuadDerivativesKHR execution mode is not specified: +endif::VK_KHR_shader_quad_control[] + ** dynamic instances of explicit derivative instructions (code:OpDPdx*, + code:OpDPdy*, and code:OpFwidth*) must: be executed in control flow + that is uniform within a derivative group. + ** dynamic instances of implicit derivative operations can: be executed in + control flow that is not uniform within the derivative group, but + results are undefined:. Fragment shaders that statically execute derivative operations must: launch sufficient invocations to ensure their correct operation; additional @@ -3089,18 +3119,24 @@ behave more like code:Private variables for the duration of the shader invocation. ==== -For <> other than -<> ifdef::VK_VERSION_1_1[] -and <> +ifdef::VK_KHR_shader_maximal_reconvergence[] +If the code:MaximallyReconvergesKHR execution mode is applied to the entry +point, helper invocations must: remain active for all instructions for the +lifetime of the quad scope instance they are a part of. +If the code:MaximallyReconvergesKHR execution mode is not applied to the +entry point, helper +endif::VK_KHR_shader_maximal_reconvergence[] +ifndef::VK_KHR_shader_maximal_reconvergence[] +Helper +endif::VK_KHR_shader_maximal_reconvergence[] +invocations may: be considered inactive for <> other than <> +and <> operations. +All invocations in a quad scope instance may: become permanently inactive at +any point once the only remaining invocations in that quad scope instance +are helper invocations. endif::VK_VERSION_1_1[] -operations, helper invocations may: be treated as inactive even if they -would be considered otherwise active. - -ifdef::VK_VERSION_1_3,VK_EXT_shader_demote_to_helper_invocation[] -Helper invocations may: become permanently inactive if all invocations in a -quad scope instance become helper invocations. -endif::VK_VERSION_1_3,VK_EXT_shader_demote_to_helper_invocation[] ifdef::VK_NV_cooperative_matrix,VK_KHR_cooperative_matrix[] diff --git a/chapters/sparsemem.adoc b/chapters/sparsemem.adoc index 06275dfb1..8f5c7ff52 100644 --- a/chapters/sparsemem.adoc +++ b/chapters/sparsemem.adoc @@ -922,8 +922,9 @@ or more elink:VkSparseImageFormatFlagBits. -- fname:vkGetPhysicalDeviceSparseImageFormatProperties returns an array of slink:VkSparseImageFormatProperties. -Each element will describe properties for one set of image aspects that are -bound simultaneously in the image. +Each element describes properties for one set of image aspects that are +bound simultaneously for a sname:VkImage created with the provided image +creation parameters. This is usually one element for each aspect in the image, but for interleaved depth/stencil images there is only one element describing the combined aspects. @@ -973,8 +974,6 @@ ename:VK_IMAGE_ASPECT_STENCIL_BIT. set in sname:VkImageFormatProperties::pname:sampleCounts returned by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format, pname:type, pname:tiling, and pname:usage equal to those in this command - and pname:flags equal to the value that is set in - slink:VkImageCreateInfo::pname:flags when the image is created **** include::{generated}/validity/protos/vkGetPhysicalDeviceSparseImageFormatProperties.adoc[] @@ -985,8 +984,9 @@ ifdef::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[] -- fname:vkGetPhysicalDeviceSparseImageFormatProperties2 returns an array of slink:VkSparseImageFormatProperties2. -Each element will describe properties for one set of image aspects that are -bound simultaneously in the image. +Each element describes properties for one set of image aspects that are +bound simultaneously for a sname:VkImage created with the provided image +creation parameters. This is usually one element for each aspect in the image, but for interleaved depth/stencil images there is only one element describing the combined aspects. @@ -1048,8 +1048,6 @@ endif::VK_KHR_get_physical_device_properties2[] set in sname:VkImageFormatProperties::pname:sampleCounts returned by fname:vkGetPhysicalDeviceImageFormatProperties with pname:format, pname:type, pname:tiling, and pname:usage equal to those in this command - and pname:flags equal to the value that is set in - slink:VkImageCreateInfo::pname:flags when the image is created **** include::{generated}/validity/structs/VkPhysicalDeviceSparseImageFormatInfo2.adoc[] diff --git a/chapters/synchronization.adoc b/chapters/synchronization.adoc index 63d5ce1f6..92d1ac3d4 100644 --- a/chapters/synchronization.adoc +++ b/chapters/synchronization.adoc @@ -5508,6 +5508,9 @@ ifdef::VK_VERSION_1_3,VK_KHR_synchronization2[] * [[VUID-vkSetEvent-event-03941]] pname:event must: not have been created with ename:VK_EVENT_CREATE_DEVICE_ONLY_BIT + * [[VUID-vkSetEvent-event-09543]] + pname:event must: not be waited on by a command buffer in the + <> **** endif::VK_VERSION_1_3,VK_KHR_synchronization2[] diff --git a/chapters/vertexpostproc.adoc b/chapters/vertexpostproc.adoc index b0d792fc5..726d8fe91 100644 --- a/chapters/vertexpostproc.adoc +++ b/chapters/vertexpostproc.adoc @@ -1299,11 +1299,11 @@ structure used in pipeline creation. [eq]#x~f~# and [eq]#y~f~# have limited precision, where the number of fractional bits retained is specified by sname:VkPhysicalDeviceLimits::pname:subPixelPrecisionBits. -ifdef::VK_EXT_line_rasterization[] +ifdef::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] When rasterizing <>, the number of fractional bits is specified by -sname:VkPhysicalDeviceLineRasterizationPropertiesEXT::pname:lineSubPixelPrecisionBits. -endif::VK_EXT_line_rasterization[] +sname:VkPhysicalDeviceLineRasterizationPropertiesKHR::pname:lineSubPixelPrecisionBits. +endif::VK_KHR_line_rasterization,VK_EXT_line_rasterization[] [open,refpage='VkPipelineViewportStateCreateInfo',desc='Structure specifying parameters of a newly created pipeline viewport state',type='structs'] -- diff --git a/proposals/VK_KHR_cooperative_matrix.asciidoc b/proposals/VK_KHR_cooperative_matrix.adoc similarity index 100% rename from proposals/VK_KHR_cooperative_matrix.asciidoc rename to proposals/VK_KHR_cooperative_matrix.adoc diff --git a/proposals/VK_KHR_dynamic_rendering_local_read.adoc b/proposals/VK_KHR_dynamic_rendering_local_read.adoc new file mode 100644 index 000000000..0bfb85531 --- /dev/null +++ b/proposals/VK_KHR_dynamic_rendering_local_read.adoc @@ -0,0 +1,300 @@ +// Copyright 2021-2024 The Khronos Group Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + += VK_KHR_dynamic_rendering_local_read +:toc: left +:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/ +:sectnums: + +This extension enables reads from attachments and resources written by previous fragment shaders within a dynamic render pass. + + +== Problem Statement + +link:{refpage}VK_KHR_dynamic_rendering.adoc[VK_KHR_dynamic_rendering] enabled a much more straightforward method for applications to setup rendering code without the need for a large dedicated object up front. +That extension enabled a number of applications that do not use multiple subpasses to use a more streamlined method for getting rendering started. + +However, applications using multiple subpasses or wanting to do things like order independent transparency or simple deferred rendering cannot make use of link:{refpage}VK_KHR_dynamic_rendering.adoc[VK_KHR_dynamic_rendering], as there is no path for subpass dependencies to be expressed without breaking rendering across multiple separate render passes. + +Adding a method for applications using these techniques to express these in dynamic rendering would enable more developers to take advantage of this functionality without the complexity of setting up render pass objects. + + +== Solution Space + +The solution to this problem has to involve some way of allowing the addition of local attachment reads to dynamic rendering, and the following additional constraints also exist: + + - The solution has to remain easy to use in keeping with dynamic rendering's core goals. + - The solution should require minimal deviation from multi-pass code using render pass objects to enable easier porting. + - The solution should be implementable efficiently across all platforms, but allow space for vendor fast paths. + + +== Proposal + + +=== Features + +The following feature advertises the full functionality of this extension: + +[source,c] +---- +typedef struct VkPhysicalDeviceDynamicRenderingLocalReadFeaturesKHR { + VkStructureType sType; + const void* pNext; + VkBool32 dynamicRenderingLocalRead; +} VkPhysicalDeviceDynamicRenderingLocalReadFeaturesKHR; +---- + + +=== Dynamic Rendering Self-Dependencies + +If the `dynamicRenderingLocalReads` feature is enabled, pipeline barriers are now allowed within dynamic rendering if they include `VK_DEPENDENCY_BY_REGION_BIT`, and source and destination stages are all framebuffer-space stages. +When such a pipeline barrier is provided, any resources specified (or all if a memory barrier is used) can be read by a subsequent fragment shader in the same render pass if they were written to by any overlapping fragment location (x,y,layer/view,sample). +These pipeline barriers cannot perform layout transitions or queue family transfers. +Reading data outside of values written by a previous fragment shader has undefined behavior. + +[NOTE] +.Note +==== +When writing to storage resources the actual location in the resource is not relevant - only the fragment locations accessing the values. +For instance, if a fragment at position (x=5,y=5) wrote to a storage image at position (x=6,y=6) and (x=21,y=700), then a subsequent fragment at (x=5,y=5) would be able to read (x=6,y=6) and (x=21,y=700) from the same storage image with an appropriate barrier between the accesses. +In this same example, reading from (x=5,y=5) in the storage image would be a data race if any other fragment wrote to it. +This allows applications to associate arbitrary amounts of data with a given pixel, and extends to the use of buffers or device addresses as well. +==== + +Images used for this purpose must be in either the `VK_IMAGE_LAYOUT_GENERAL` layout, or a new dedicated layout: + +[source,c] +---- +VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR = 1000232000; +---- + +This layout can be used for storage images, and render pass color, depth/stencil, and input attachments. +Writes to attachments can only be made visible in this way via input attachments, and writes via other resource types will not be made visible via input attachments. + +[NOTE] +.Note +==== +While the same layout can be used for storage images and all attachments, there is still no way to write through one type of resource and then read through another in the same render pass instance. +==== + + +=== Color Attachment Remapping + +In order to facilitate applications porting multi-pass rendering to dynamic rendering, the following functionality is added to allow remapping of color attachment locations during rendering: + +[source,c] +---- +typedef struct VkRenderingAttachmentLocationInfoKHR { + VkStructureType sType; + const void* pNext; + const uint32_t colorAttachmentCount; + const uint32_t* pColorAttachmentLocations; +} VkRenderingAttachmentLocationInfoKHR; + +void vkCmdSetRenderingAttachmentLocationsKHR( + VkCommandBuffer commandBuffer, + const VkRenderingAttachmentLocationInfoKHR* pLocationInfo); +---- + +As with render pass objects, this information must be provided both when creating a pipeline and during rendering, and must match between the two in order to be valid. + +This information can be provided during pipeline creation by chaining `VkRenderingAttachmentLocationInfoKHR` to link:{refpage}VkGraphicsPipelineCreateInfo.html[VkGraphicsPipelineCreateInfo] when the fragment output state subset is required. +If this structure is not provided for pipeline creation, it is equivalent to setting the value of each element of `pColorAttachmentLocations` to the value of its index within the array. + +`vkCmdSetRenderingAttachmentLocationsKHR` must only be called within a dynamic render pass instance. +If this command is not called, the default state is that each element of `pColorAttachmentLocations` is equal to the value of its index within the array. + +The index of each element of `pColorAttachmentLocations` corresponds to the same index of a color attachment in a dynamic render pass, and the value of that element becomes the location that refers to it, providing a way to remap color attachment locations. +This does not allow an application to wholesale swap out color attachments, but if an application can specify all color attachments that would be used during dynamic rendering as a superset, fragment shaders written for render pass objects can be reused without modification when porting to this extension, simply by remapping the attachments. +Values in `pColorAttachmentLocations` must each be unique. + +[NOTE] +.Note +==== +The color attachment remapping does not affect things like blend state or format mappings - these always correspond 1:1 with the render pass attachments. +This means when porting from render pass objects, care must be taken to ensure these are reordered correctly, where before the values mapped to the reordered elements in the subpass. +==== + +When issuing a draw call, the location mapping must match between the currently bound graphics pipeline and the command buffer state set by `vkCmdSetRenderingAttachmentLocationsKHR`. + +`VkRenderingAttachmentLocationInfoKHR` can also be chained to link:{refpage}VkCommandBufferInheritanceInfo.html[VkCommandBufferInheritanceInfo] when using secondary command buffers, to specify the color attachment location mapping in the primary command buffer when link:{refpage}vkCmdExecuteCommands.html[vkCmdExecuteCommands] is called. +If `VkRenderingAttachmentLocationInfoKHR` is not provided in the inheritance info, it is equivalent to providing it with the value of each element of `pColorAttachmentLocations` set to the value of its index within the array. +This information must match between the inheritance info and the state when link:{refpage}vkCmdExecuteCommands.html[vkCmdExecuteCommands] is called if there is a currently active render pass instance. + +NOTE: This functionality is provided primarily for porting existing content to the new API; new applications should maintain a consistent location for all attachments in their shaders during a render pass; this functionality can be considered immediately deprecated. + +While an attachment is mapped to `VK_ATTACHMENT_UNUSED` in command buffer state (either via `vkCmdSetRenderingAttachmentLocationsKHR` or inheritance state), it must not be cleared by link:{refpage}vkCmdClearAttachments.html[vkCmdClearAttachments]. +Some implementations will update the render pass attachment bindings when remapping occurs, leaving unmapped attachments unavailable to be written to via the path that vkCmdClearAttachments would use. +This is in line with render pass objects, where applications would not be able to clear an attachment outside of the current subpass. + + +=== Input Attachment Mapping + +There are two ways to map input attachments to other attachments during dynamic rendering; the simplest is to rely on the `InputAttachmentIndex` qualifier matching the location of the corresponding color attachment, or being omitted for a depth/stencil attachment. +By default, a color attachment specified at index _i_ in the API will be associated with an input attachment with `InputAttachmentIndex` equal to _i_. +This mapping is not affected by the mappings set by `VkRenderingAttachmentLocationInfoKHR`. +Any input attachment without an `InputAttachmentIndex` will be associated with the depth/stencil attachment. +For applications where writing new shaders is viable, this allows a simple mapping without API intervention. + +For applications porting existing content from render pass objects where modifying shaders is not straightforward, functionality similar to `VkRenderingAttachmentLocationInfoKHR` is provided to allow remapping the input attachments to different attachments: + +[source,c] +---- +typedef struct VkRenderingInputAttachmentIndexInfoKHR { + VkStructureType sType; + const void* pNext; + const uint32_t colorAttachmentCount; + const uint32_t* pColorAttachmentInputIndices; + uint32_t depthInputAttachmentIndex; + uint32_t stencilInputAttachmentIndex; +} VkRenderingInputAttachmentIndexInfoKHR; + +void vkCmdSetRenderingInputAttachmentIndicesKHR( + VkCommandBuffer commandBuffer, + const VkRenderingInputAttachmentIndexInfoKHR* pInputAttachmentIndexInfo); +---- + +This information can be provided during pipeline creation by chaining `VkRenderingInputAttachmentIndexInfoKHR` to link:{refpage}VkGraphicsPipelineCreateInfo.html[VkGraphicsPipelineCreateInfo] when the fragment shader state subset is required. +If this structure is not provided for pipeline creation, it is equivalent to setting the value of each element of `pColorAttachmentInputIndices` to the value of its index within the array, and `pDepthInputAttachmentIndex` and `pStencilInputAttachmentIndex` are set to `NULL`. + +`vkCmdSetRenderingInputAttachmentIndicesKHR` must only be called within a dynamic render pass instance. +If this command is not called, the default state is that each element of `pColorAttachmentInputIndices` to the value of its index within the array, and `pDepthInputAttachmentIndex` and `pStencilInputAttachmentIndex` are set to `NULL`. + +The index of each element of `pColorAttachmentInputIndices` corresponds to the same index of a color attachment in a dynamic render pass, and the value of that element becomes the `InputAttachmentIndex` that refers to it, providing a way to remap input attachments to color attachments. +Values in `pColorAttachmentInputIndices` must each be unique. + +If either of `pDepthInputAttachmentIndex` or `pStencilInputAttachmentIndex` are set to `NULL` it means that these are only accessible in the shader if the shader does not associate these input attachments with an `InputAttachmentIndex`. + +If `pDepthInputAttachmentIndex`, `pStencilInputAttachmentIndex`, or any element of `pColorAttachmentInputIndices` is set to `VK_ATTACHMENT_UNUSED` it indicates that the respective attachment is not associated with an input attachment index, and cannot be accessed as an input attachment in the shader. + +When issuing a draw call, the input attachment index mapping must match between the currently bound graphics pipeline and the command buffer state set by `vkCmdSetRenderingInputAttachmentIndicesKHR`. + +`VkRenderingInputAttachmentIndexInfoKHR` can also be chained to link:{refpage}VkCommandBufferInheritanceInfo.html[VkCommandBufferInheritanceInfo] when using secondary command buffers, to specify the input attachment index mapping in the primary command buffer when link:{refpage}vkCmdExecuteCommands.html[vkCmdExecuteCommands] is called. +If `VkRenderingInputAttachmentIndexInfoKHR` is not provided in the inheritance info, it is equivalent to providing it with the value of each element of `pColorAttachmentInputIndices` set to the value of its index within the array, and `pDepthInputAttachmentIndex` and `pStencilInputAttachmentIndex` set to `NULL`. +This information must match between the inheritance info and the state when link:{refpage}vkCmdExecuteCommands.html[vkCmdExecuteCommands] is called if there is a currently active render pass instance. + +NOTE: The remapping functionality is provided primarily for porting existing content to the new API; new applications should set their index attachment indices consistently for all attachments in their shaders during a render pass; this functionality can be considered immediately deprecated. + + +=== Read-only Input Attachments + +One quirk of render pass objects is that users can specify input attachments that are only used as input attachments. +For dynamic rendering, these cannot be specified by tagging them as another attachment type as enabled by the above structures. + +Rather than specifying them in the render pass, as they must be associated with a descriptor, implementations will unconditionally fetch values from the input attachment descriptor if the `InputAttachmentIndex` is not mapped to another attachment. + +NOTE: Some implementations may have to now provide a real descriptor when advertising this extension where they did not before - which may affect things like link:{refpage}VK_EXT_descriptor_buffer.html[VK_EXT_descriptor_buffer], where the size of the descriptor is advertised. + + +=== Interactions with link:{refpage}VK_EXT_shader_object.html[VK_EXT_shader_object] + +If link:{refpage}VK_EXT_shader_object.html[VK_EXT_shader_object] is enabled, `vkCmdSetRenderingAttachmentLocationsKHR` and `vkCmdSetRenderingInputAttachmentIndicesKHR` are the the only way to set the remapping state; the respective structures do not need to be chained to shader object creation or match any static state. + + +=== Interactions with link:{refpage}VK_EXT_rasterization_order_attachment_access.html[VK_EXT_rasterization_order_attachment_access] + +If link:{refpage}VK_EXT_rasterization_order_attachment_access.html[VK_EXT_rasterization_order_attachment_access] is enabled, the pipeline depth/stencil state and color blend state bits can be used with dynamic rendering, with the same effect on input attachment reads as when used with render pass objects. +Specifically, this allows local reads from input attachments to read values from previous fragments at overlapping locations within the same render pass (even the same draw), without a barrier. +This interaction does not enable local reads between non-attachment resources without a barrier. + + +=== GLSL Changes + +A small change is made to GLSL to allow the `input_attachment_index` qualifier to be omitted when specifying a subpass input. + + +=== HLSL Changes + +HLSL's SPIR-V translation currently requires subpass inputs to specify the `vk::input_attachment_index()` attribute on `SubpassInput` variables, and this will be relaxed to allow it to be omitted. + + +== Example: Porting + +With a few lines of API code changes, it should be possible to trivially port most code using render pass objects to use dynamic rendering. +There are some exceptions - code which would use more color attachments than fit within the limit for a single subpass or dynamic rendering, switch depth/stencil attachments, or use non-framebuffer-space subpass dependencies cannot be expressed this way, and must be split into multiple dynamic render passes. +As an example, the following two pieces of code specify the same outcome: + + +==== Multiple Subpasses + +[source,c] +---- +// Write out the setup code. + +vkCmdBeginRenderPass2(...); + +vkCmdDraw(...); + +vkCmdNextSubpass2(...); + +vkCmdDraw(...); + +vkCmdEndRenderPass2(...); +---- + + +==== Dynamic Rendering Dependencies + +[source,c] +---- +// Write the setup code + +vkCmdBeginRendering(...); + +vkCmdDraw(...); + +vkCmdPipelineBarrier(...); + +vkCmdDraw(...); + +vkCmdEndRendering(...); +---- + + +== Issues + +==== Why is color attachment location reordering included? + +With multiple subpasses in a render pass, applications can reassociate the locations between different subpasses, and this is included to enable simple porting of shaders that do this to this extension. +It could be omitted but this would require pre-processing of shader code to replace the color indices to achieve the same effect, which is a big burden if an app is not already set up to do it. +It is a small concession for developers to make it significantly easier to port code, without adding much burden on implementers. + + +==== Why are some of the functions of multiple subpasses not exposed? + +These extra bits of functionality require implementations to jump through hoops that may require splitting render passes internally; this extension is deliberately limited to functionality that all vendors can support without resorting to that, as it would increase the complexity of the API massively, particularly given this cannot be pre-computed without a dedicated object. + + +==== Should input attachment descriptors be required? + +Several vendors (including those considered tilers) need a separate descriptor to read these images, and not having them would increase driver complexity and may decrease performance - but we could revisit this. + +Note: `TRANSIENT` attachments still work with this extension, allowing a path to avoid the memory allocation, just as with render pass objects. + + +==== Should this extension include the ability for fragment shaders to reinterpret the format of a color/input attachment during rendering? + +Proposed: Separate extension. + +To make this work, something as simple as a decoration on a color output or input attachment stating that the format is ignored and raw bits are written would suffice, but that might be beyond the scope of this extension, and may not be supportable by all implementers. +This would allow applications to port code using the OpenGL ES pixel local storage extensions to Vulkan, and would also allow more code using more attachments than are available to work by aliasing discarded attachments (though this might also necessitate explicit load/store commands). + + +==== Should this extension advertise local reads between fragments in the same draw call? + +This is not efficient or easily implementable in all cases for many vendors. +For implementations that do support it, that feature is provided as an interaction with link:{refpage}VK_EXT_rasterization_order_attachment_access.adoc[VK_EXT_rasterization_order_attachment_access]. + + +==== Should this extension allow applications to access local data from resources other than attachments? + +Yes, this allows more flexibility for applications to implement functionality between fragments. +This should not be a significant implementation burden, but it could be removed if that assumption turns out to be false. + + +==== Should read-only input attachments be specified in `vkCmdBeginRendering` to enable pre-fetch in tilers? + +This would make the API more complex for what is likely minimal gain. +Applications can emulate this themselves by putting such data into a placeholder attachment that is never written, if there is space for another attachment. +If there is not space for another attachment, the implementation would not be able to prefetch anyway. diff --git a/proposals/VK_KHR_load_store_op_none.adoc b/proposals/VK_KHR_load_store_op_none.adoc new file mode 100644 index 000000000..7953f8b70 --- /dev/null +++ b/proposals/VK_KHR_load_store_op_none.adoc @@ -0,0 +1,51 @@ +// Copyright 2023-2024 The Khronos Group, Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + += VK_KHR_load_store_op_none +:toc: left +:refpage: https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/ +:sectnums: + +This document describes useful load and store ops that did not exist in Vulkan 1.0. + +== Problem Statement + +=== No-op Store Op + +In Vulkan 1.0, there exist two `VkAttachmentStoreOp` values: `VK_ATTACHMENT_STORE_OP_STORE` and `VK_ATTACHMENT_STORE_OP_DONT_CARE`. +The former causes the attachment contents to be written back to the image at the end of the render pass, and the latter causes the contents to be discarded. +Both these operations are write operations. +As a result: + +- The application needs to synchronize with these operations as write operations +- The application needs to consume expensive bandwidth on some devices by using `VK_ATTACHMENT_STORE_OP_STORE` even if the attachment contents have not been modified. + +In some cases, for example for a depth/stencil attachment that is being used as read-only, the contents of the attachment are not modified, yet should not be discarded either. +There is thus a need for another store operation to retain the contents of the attachment without a write. + +=== No-op Load Op + +In Vulkan 1.0, there exist three `VkAttachmentLoadOp` values: `VK_ATTACHMENT_LOAD_OP_LOAD`, `VK_ATTACHMENT_LOAD_OP_CLEAR`, and `VK_ATTACHMENT_LOAD_OP_DONT_CARE`. +In some scenarios, a render pass subpass may not actually use an attachment. +Using `VK_ATTACHMENT_LOAD_OP_LOAD` (followed by `VK_ATTACHMENT_STORE_OP_NONE_KHR`) can be detrimental to performance on some devices. +Note that `VK_ATTACHMENT_LOAD_OP_DONT_CARE` is not usable as it is a write operation and may corrupt the contents of the attachment. +In Vulkan 1.0, these attachments should be placed in a "preserve attachment" (i.e. `VkSubpassDescription::pPreserveAttachments). + +This is not always possible however, in software where usage of attachments is not a priori known. +This is the case in OpenGL emulation layers for example, and certain game engines. +Due to the render pass compatibility rules, the application is not allowed to assume all attachments are used, only to move some to preserve attachments at the end of a logical render pass (where the Vulkan render pass is created). + +The `VK_KHR_dynamic_rendering` extension solves this problem by allowing the application to provide `VK_NULL_HANDLE` in `VkRenderingAttachmentInfo::imageView`. +The applications can thus simply avoid providing the view of the attachments that need to be preserved. +For applications using legacy render passes however, the problem remains. + +== Proposal + +The `VK_QCOM_render_pass_store_ops` extension introduced `VK_ATTACHMENT_STORE_OP_NONE_QCOM`, which was later simultaneously adopted in the `VK_EXT_load_store_op_none` and `VK_KHR_dynamic_rendering` extensions. +This store op indicates to the driver that an attachment was not written to during a render pass, and thus it is not required to be updated after the render pass. +This is not a write operation and no such synchronization is necessary with this op. + +The `VK_EXT_load_store_op_none` extension introduced `VK_ATTACHMENT_LOAD_OP_NONE_EXT`, analogous to `VK_ATTACHMENT_STORE_OP_NONE_EXT`. +This load op indicates to the driver that an attachment does not need loading. +Together with `VK_ATTACHMENT_STORE_OP_NONE_EXT`, this load op can be used to effectively turn an attachment into a preserve attachment without having to place it in `VkSubpassDescription::pPreserveAttachments`. diff --git a/proposals/VK_KHR_shader_expect_assume.adoc b/proposals/VK_KHR_shader_expect_assume.adoc new file mode 100644 index 000000000..9cfe62c23 --- /dev/null +++ b/proposals/VK_KHR_shader_expect_assume.adoc @@ -0,0 +1,93 @@ +// Copyright 2021-2024 The Khronos Group, Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + += VK_KHR_shader_expect_assume +:toc: left +:refpage: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/ +:sectnums: + +This document proposes adding support for expect/assume SPIR-V instructions +to guide shader program optimizations. + +== Problem Statement + +Shader writers or generators as well as other SPIR-V producers (e.g. Machine +Learning compilers) often have access to information that could enable the SPIR-V +consumers in Vulkan implementations to make better optimization decisions, such +as knowledge of the likely value of objects or whether a given condition holds, +but which they cannot communicate to a Vulkan SPIR-V consumer using existing features. + +== Solution Space + +SPIR-V already provides some mechanisms for producers to give hints to consumers +in a limited number of scenarios: + +- `OpBranchConditional` can accept branch weights that enable producers to +indicate the likelihood of each path. This does not however generalize +to `OpSwitch` constructs. + +- Various so called _Loop Controls_ make it possible for producers to provide +metadata about the iteration count of loops or desired unrolling behaviour. + +There is however no exposed generic mechanism for SPIR-V producers to communicate +optimisation information to consumers. SPIR-V does support dedicated instructions, +introduced by the +http://htmlpreview.github.io/?https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/KHR/SPV_KHR_expect_assume.html[SPV_KHR_expect_assume] +extension, that make it possible for producers to communicate to consumers the +likely value of an object or whether a given condition holds, but this extension +is currently not exposed in Vulkan. + +== Proposal + +Expose the +http://htmlpreview.github.io/?https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/KHR/SPV_KHR_expect_assume.html[SPV_KHR_expect_assume] +extension in Vulkan. + +The `SPV_KHR_expect_assume` extension introduces two new instructions: + +- `OpExpectKHR` makes it possible to state the most probable value of its input. +- `OpAssumeTrueKHR` enables the optimizer to assume that the provided condition is +always true. + +== Examples + +As an illustration, consider the following pseudocode example: + +[source] +---- +c = 20 +d = 2 +b = c / d + +if (a - b > 0) { + ... +} else { + ... +} +---- + +The writer or producer may know that a > 10. This knowledge makes it possible +to completely remove the `else` branch. In this case, the producer could perform +that optimisation alone. However, if the producer only knows that `a` is greater +than _some_ value provided, say with a specialization constant, it can no longer +perform the optimisation. Adding that information to the SPIR-V module would +enable the SPIR-V consumer to do it. + +Another possible use could be to provide guarantees that a particular value +is not NaN or infinite: + +[source] +---- +value = load(...) +assume(!isnan(value)) +---- + +== Issues + +1) What shader stages should the instructions introduced by this extension +be allowed in? + +*PROPOSED*: No restrictions are placed on the shader stages the instructions can +be used in. + diff --git a/proposals/VK_KHR_shader_float_controls2.adoc b/proposals/VK_KHR_shader_float_controls2.adoc new file mode 100644 index 000000000..7da797092 --- /dev/null +++ b/proposals/VK_KHR_shader_float_controls2.adoc @@ -0,0 +1,80 @@ +// Copyright 2024 The Khronos Group Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + += VK_KHR_shader_float_controls2 +:toc: left +:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/ +:sectnums: + +== Problem Statement + +Vulkan currently only allows somewhat restricted control over how floating-point operations +should be performed by the implementation. +This causes missed opportunities for optimisation in certain types of shader, which are +forced to disable more relaxations than are really required. + +The controls in VK_KHR_shader_float_controls must be applied entry-point wide, which makes +it impossible to mix functions that require strict conformance with other functions that +can benefit from the optimisations that result from assuming that this is not true. + +Many instructions currently are not affected by the controls from VK_KHR_shader_float_controls, +meaning that they cannot be used at all in shaders that require strict floating-point support. + +The NoContraction decoration, which is used to control IEEE conformance in floating-point +expression evaluation, only supports two states, one of which is full strictness and the +other is less strict than is typically allowed by -ffast-math in CPU compilers. This means +that any code for which this relaxed state is not sufficient must enable the strictest mode +and pay the cost associated with that. + +Additionally, SPIR-V already contains decorations to give finer-grained control over +floating-point operations which are used by other APIs. Using different control mechanisms +gives an unnecessary incompatibility between SPIR-V modules for different APIs and adds +an associated cost to tooling. + +This proposal aims to provide more flexible and wider ranging control over floating-point +evaluation. + +== Proposal + +Allow use of SPV_KHR_float_controls2 in Vulkan. The SPIR-V extension adopts and extends +the floating-point controls that are used for Kernel SPIR-V. This eliminates the +difference in how these controls are specified between APIs, simplifying SPIR-V and, in +the long-term, reducing tooling costs. + +The floating-point controls are specified per-instruction, so code requiring varying +strictness can be freely mixed and the appropriate optimisations applied to all of it. + +The controls are finer-grained so that code that requires stricter evaluation than the +Vulkan default is not forced to disable larger classes of optimisation than may be +required. + +Float controls may be added to a much wider class of instructions, allowing the use of +more builtin functions more often. + +== Issues + +=== Should support for all combinations of float controls be required? + +This proposal is aimed at increasing the flexibility of float controls, not raising the +minimum support. In order that this can be implemented everywhere, if the existing +features are not supported then the related fine-grained controls must: not be set. + + +=== Which extended instructions should support float controls? + +The simplest answer and the one that provides the best solution to the problem of these +instructions not being usable in shaders that require high precision is to support the +controls on all of them. That is what is proposed here, although this does add an +implementation requirement to support infinities and NaNs in these instructions. + +Since the utility of this extension is greatly decreased if developers have to support +both the existing and the new way of specifying float controls, getting wide adoption +is an important part of solving all the problems. Therefore, if the increased +implementation requirement blocks or delays adoption, it should be dropped. This could +be done by requiring that apps not change the execution mode of these instructions, +allowing future extension to relax the restriction. + +It should be noted that the Vulkan precision requirements for many of these extended +instructions do not make generation of infinities and NaNs reliable and this extension +does not address that. diff --git a/proposals/VK_KHR_shader_maximal_reconvergence.adoc b/proposals/VK_KHR_shader_maximal_reconvergence.adoc new file mode 100644 index 000000000..7b361e4e0 --- /dev/null +++ b/proposals/VK_KHR_shader_maximal_reconvergence.adoc @@ -0,0 +1,162 @@ +// Copyright 2024 The Khronos Group, Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + += VK_KHR_shader_maximal_reconvergence +:toc: left +:refpage: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/ +:sectnums: + +== Problem Statement + +The SPIR-V specification defines several types of instructions as communicating between invocations. +It refers to these instructions as +https://www.khronos.org/registry/SPIR-V/specs/unified1/SPIRV.html#tangled_instruction[tangled +instructions]. +Tangled instructions include very useful instructions such as subgroup +operations and derivatives. +In order to correctly reason about their programs, shader authors need to be +able to understand, and be provided some guarantees, about which invocations +will be tangled together. +Unfortunately, SPIR-V does not provide strong guarantees surrounding the +divergence and reconvergence of invocations. +The +https://www.khronos.org/registry/SPIR-V/specs/unified1/SPIRV.html#uniform_control_flow[guarantees] +it does provide are rather weak and lead to unreliable behaviour across +different devices (or even different drivers of the same device). + +VK_KHR_shader_subgroup_uniform_control_flow provides stronger guarantees, but +still has some drawbacks from a shader author's point of view. +Shader authors would like to be able to reason about the divergence and +reconvergence of invocations executing shaders written in a HLL and have that +reasoning translate faithfully into SPIR-V. + +== Solution Space + +The following options were considered to address this issue: + +1. Add new mechanisms to SPIR-V, and optionally HLLs, that provide explicit + divergence and reconvergence information directly in the shader. +2. Add new guarantees to SPIR-V (through a new execution mode) that guarantee + divergence and reconvergence in SPIR-V maps intuitively from the shader's + representation in a HLL. + +The main advantage of option 1 is that is completely explicit. +The main disadvantage is it likely requires additional changes in HLL +(otherwise just use option 2) and that it requires shader authors to write more +verbose code to achieve what should, intuitively, be obvious behavior. + +The main advantage of option 2 is that there is almost no burden placed on +shader authors (beyond requesting the new style of execution). +Their code works how they expect across different devices. +The main disadvantage is that drivers must be cautious to preserve the +information implicitly encoded in the SPIR-V control flow graph throughout +internal transformations in order to guarantee the expected divergence and +reconvergence. +Option 2 is a clear win for shader authors and the difficulty for +implementations is expected to be manageable. + +== Proposal + +=== SPV_KHR_maximal_reconvergence + +This extension exposes the ability to use the SPIR-V extension, which provides +extra guarantees surrounding divergence and reconvergence. + +The extension introduces the idea of a tangle, which is the set of invocations +that execute a specific dynamic instruction instance and provides a set of +rules to reason about which invocations are included in each tangle. + +The rules are designed to match shader author intuition of divergence and +reconvergence in an HLL. +That is, divergence and reconvergence information is inferred directly from the +control flow graph of the SPIR-V module. + +=== Examples + +[source,c] +---- +uint myMaterialIndex = ...; +for (;;) { + uint materialIndex = subgroupBroadcastFirst(myMaterialIndex); + if (myMaterialIndex == materialIndex) { + // Vulkan specification requires uniform access to the resource. + vec4 diffuse = texture(diffuseSamplers[materialIndex], uv); + + // ... + + break; + } +} +---- + +In the above example, the shader author relies on invocations executing +different loop iterations being diverged from each other; however, SPIR-V does +not guarantee this to be the case. +Without maximal reconvergence, an implementation may interleave invocations +among different iterations of the loop, inadvertently breaking the uniform +access. +Another potential problem is that implementations may treat the resource access +as occurring outside the loop altogether depending on how the compiler analyzes +the program. +With maximal reconvergence, invocations are executing different loop iterations +are never in the same tangle and the break block is always considered to be +inside the loop. +With those restrictions, this example behaves as the shader author expects. + +[source,c] +---- +// Free should be initialized to 0. +layout(set=0, binding=0) buffer BUFFER { uint free; uint data[]; } b; +void main() { + bool needs_space = false; + ... + if (needs_space) { + // gl_SubgroupSize may be larger than the actual subgroup size so + // calculate the actual subgroup size. + uvec4 mask = subgroupBallot(needs_space); + uint size = subgroupBallotBitCount(mask); + uint base = 0; + if (subgroupElect()) { + // "free" tracks the next free slot for writes. + // The first invocation in the subgroup allocates space + // for each invocation in the subgroup that requires it. + base = atomicAdd(b.free, size); + } + + // Broadcast the base index to other invocations in the subgroup. + base = subgroupBroadcastFirst(base); + // Calculate the offset from "base" for each invocation. + uint offset = subgroupBallotExclusiveBitCount(mask); + + // Write the data in the allocated slot for each invocation that + // requested space. + b.data[base + offset] = ...; + } + ... +} +---- + +This example is borrowed from the +https://github.com/KhronosGroup/Vulkan-Guide/blob/master/chapters/extensions/VK_KHR_shader_subgroup_uniform_control_flow.adoc[guide +for VK_KHR_shader_subgroup_uniform_control flow]. +Even with subgroup uniform control flow the rewritten example had a caveat that +the code could only be executed from subgroup uniform control flow. +With maximal reconvergence, the unaltered version of code (as listed above) can +be used directly to perform atomic compaction. +The extra subgroup operations required by subgroup uniform control flow are no longer required. +Maximal reconvergence guarantees that the election, broadcast and bit count all +operate on the same tangle. + +== Issues + +=== RESOLVED: Can a single behavior be provided for switch statements? + +Unfortunately, maximal reconvergence cannot guarantee a single behavior for +switch statements. +There are too many different implementations for a switch statement, +restricting the divergence and reconvergence behavior would have serious +negative performance impacts on some implementations. +Instead, shader authors should avoid switch statements in favour of if/else +statements if they require guarantees about divergence and reconvergence. + diff --git a/proposals/VK_KHR_shader_quad_control.adoc b/proposals/VK_KHR_shader_quad_control.adoc new file mode 100644 index 000000000..63da30ce8 --- /dev/null +++ b/proposals/VK_KHR_shader_quad_control.adoc @@ -0,0 +1,236 @@ +// Copyright 2021-2024 The Khronos Group Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + += VK_KHR_shader_quad_control +:toc: left +:refpage: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/ +:sectnums: + +This document proposes an extension giving applications better guarantees about the uniformity of sampling and derivative operations in fragment shaders, and provides features to manage these guarantees. +The primary features are a new `QuadDerivativesKHR` execution mode in SPIR-V which allows derivatives to be used in quad-uniform control flow, new quad Any/All operations, and guaranteed helper invocation participation in group operations. + + +== Problem Statement + +When using derivatives in fragment shader, either implicitly through sampling or explicitly, applications currently have to ensure that control flow is uniform across a primitive to avoid undefined results. +In many cases, the only way to guarantee this is to ensure fully uniform control flow for the entire draw command. +In practice, many applications do not do this, which can result in subtle (and hard to debug) visual glitches when rendering. + +Many applications assume that derivatives are performed within a quad, which intuitively makes sense. +However, when the slope of a primitive is uniform across the primitive, some vendors can perform derivative calculations per-triangle instead of per-quad. + +Even if derivative calculations are guaranteed per-quad, it is not trivial for an application to ensure uniform control flow across a quad. At the moment the most portable method for doing this at a conditional statement requires four group operations: + +* OpGroupNonUniformQuadBroadcast four times at each index, broadcasting the results of a conditional check before actually branching on it +* OpAny to detect if any of the values are true + +This would need to be repeated for each conditional statement at every step of the way to the derivative calculation - and the extra calculations can quickly add up to slow down a shader. + +If clustered operations are supported, an application could theoretically use link:https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#OpGroupNonUniformBitwiseOr[`OpGroupNonUniformBitwiseOr`] with a cluster size of 4 instead, but helper invocations are not guaranteed to participate in group operations that are not explicitly quad operations, so this would be unreliable. + +Helper invocation participation in group operations has historically been ambiguous for the Vulkan spec, but this was fixed in link:{refpage}VK_KHR_shader_maximal_reconvergence.html[VK_KHR_shader_maximal_reconvergence]. + + +== Solution Space + +Any solution needs to address these problems by adding a way to require that derivatives are calculated at quad scope, and providing a way to maintain quad uniform control flow for derivative calculations. + +Forcing per-quad derivatives has to be an implementation change - there needs to be something to tell an implementation to perform a derivative calculation at quad scope, as there is no reliable way to do that currently. +This could be anything from a device-wide switch to a per-instruction indicator, but something has to be there. +A device-wide switch could be a problem, as it will slow down _all_ shaders if an implementation is otherwise using an optimisation. +A per-instruction indicator would probably just bloat shader code unnecessarily - the expectation is that a single shader (or set of shaders) will either require quad derivatives throughout or they will not. +A per-shader switch should be a pragmatic choice, enabling individual shaders to make the switch as codebases are updated without either bloating that shader or affecting performance. + +As for quad uniform control flow, no solution is strictly necessary as applications can maintain quad uniform control flow as described in the problem statement, however this is a heavy handed approach, and we expect vendors can do better if they have more semantic information about the operation, with less performance impact. +Adding some way to perform an explicit quad-wide `OpGroupNonUniformAny` with guarantees that helpers participate in those calculations would be the most straightforward way to solve this. + +Adding a new scope would be one way to get enable quad operations, but this would be redundant in most operations, as quads have a strict mapping to subgroups; so clustered operations can effectively already operate at quad scope. +Any/all operations are not clustered however, so for these, the simplest fix is to simply add new variants of those instructions to enable the desired functionality. + + +== Proposal + +=== Requirements + +This extension requires link:{refpage} link:{refpage}VK_VERSION_1_1.html[Vulkan Version 1.1], link:{refpage} link:{refpage}VK_KHR_vulkan_memory_model.html[VK_KHR_vulkan_memory_model], link:{refpage}VK_KHR_shader_maximal_reconvergence.html[VK_KHR_shader_maximal_reconvergence]. + +=== API + +A new feature struct is added to the API: + +[source,c] +---- +typedef struct VkPhysicalDeviceShaderQuadControlFeaturesKHR { + VkStructureType sType; + void* pNext; + VkBool32 shaderQuadControl; +} VkPhysicalDeviceShaderQuadControlFeaturesKHR; +---- + +When enabled, shaders can use the `QuadControlKHR` capability in shaders. + + +=== SPIR-V + +A new capability is added to SPIR-V: + +[cols="1,10,6",options="header"] +|==== +2+^| Capability ^| Implicitly Declares +| 5087 | *QuadControlKHR* + +Module uses the _QuadDerivativesKHR_ or _RequireFullQuadsKHR_ execution modes, or the *OpGroupNonUniformQuadAllKHR* or *OpGroupNonUniformQuadAllKHR* instructions. +| +|==== + +Two new execution modes are provided: + +[cols="^2,22,3*3,22",options="header",width = "100%"] +|==== +2+^.^| Execution Mode 3+<.^| Extra Operands | Enabling Capabilities +| 5088 | *QuadDerivativesKHR* + +The derivative group must be equivalent to the quad groups. 3+| |*QuadControlKHR* +| 5089 | *RequireFullQuadsKHR* + +Helper invocations must be spawned such that all quad groups start with four active invocations. Only valid with the *Fragment* _Execution Model_. 3+| |*QuadControlKHR* +|==== + +Two new instructions are added: + +[cols="5*1",width="100%"] +|===== +4+|[[OpGroupNonUniformQuadAllKHR]]*OpGroupNonUniformQuadAllKHR* + + + +Evaluates a predicate for all active invocations in the group, resulting in *true* if predicate evaluates to *true* for all active invocations in the group, otherwise the result is *false*. + + + +_Result Type_ must be a _Boolean Type_. + + + +_Predicate_ must be a _Boolean Type_. +1+|Capability: + +*QuadControlKHR* +1+| 4 | 5110 +| __ + +_Result Type_ +| _Result _ +| __ + +_Predicate_ +|===== + +[cols="5*1",width="100%"] +|===== +4+|[[OpGroupNonUniformQuadAnyKHR]]*OpGroupNonUniformQuadAnyKHR* + + + +Evaluates a predicate for all active invocations in the group, resulting in *true* if predicate evaluates to *true* for any active invocation in the group, otherwise the result is *false*. + + + +_Result Type_ must be a _Boolean Type_. + + + +_Predicate_ must be a _Boolean Type_. +1+|Capability: + +*QuadControlKHR* +1+| 4 | 5111 +| __ + +_Result Type_ +| _Result _ +| __ + +_Predicate_ +|===== + + +=== GLSL + +The GLSL_EXT_shader_quad extension is added to glslang, providing quad operations and +built-ins mapping to the subgroup operations roughly as follows: + +[source,glsl] +---- + + layout (quad_derivatives) in; -> QuadDerivativesKHR execution mode + layout (full_quads) in; -> RequireFullQuadsKHR execution mode + + subgroupQuadAll(value) -> OpGroupNonUniformQuadAll( + /*Predicate*/value) + + subgroupQuadAny(value) -> OpGroupNonUniformQuadAny( + /*Predicate*/value) +---- + +These operations function identically to their subgroup counterparts, but operating at quad scope. + + +=== HLSL + +The new quad/helper related functionality of shader model 6.7 should neatly map to this extension: https://devblogs.microsoft.com/directx/in-the-works-hlsl-shader-model-6-7/ + +`QuadAny`/`QuadAll` will map to `OpGroupNonUniformQuadAny/All`, and using either of these functions will result in the `QuadDerivativesKHR` execution mode being used. +If `MaximallyReconvergesKHR` is not already specified by other means, it will be added when using either of `QuadAny`/`QuadAll`, or if the `[WaveOpsIncludeHelperLanes]` entry function attribute is specified for a pixel shader. +`IsHelperLane()` will map to the existing `HelperInvocation` Built-In. + + +== Examples + +A shader author might write something like the following fragment shader, +expecting the texture to only be loaded when necessary: + +[source,glsl] +---- +void main() +{ + ... + + fragColor = vec4(1.0); + + if (nonuniform_condition) { + fragColor = texture(colorTexture, uv); + } +} +---- + +However, because of the implicit derivatives the `texture` function has to +generate, the result has an undefined LoD selected. + +Without this extension, working around this would require performing the +texture load if any fragment in the same primitive needed the result; which +is not a trivial condition to check for, and has significant additional +bandwidth requirements compared to the desired operation. + +This extension, in combination with maximal reconvergence, lets shader +authors perform a significantly tighter check to get the right results; +guaranteeing derivatives are calculated within a quad, and providing the +ability to check conditions on a per-quad basis: + +[source,glsl] +---- +... +#extension GL_EXT_maximal_reconvergence : enable +#extension GL_EXT_shader_quad : enable +... + +void main() +{ + ... + + fragColor = vec4(1.0); + + if (subgroupQuadAny(nonuniform_condition)) { + vec4 color = texture(colorTexture, uv); + + if (nonuniform_condition) { + fragColor = color; + } + } +} +---- + +This second example now has well-defined behavior, whilst minimizing texture +bandwidth - loads are only performed by quads passing the condition. + + +== Issues + +=== RESOLVED: Do the new quad operations invoke helpers automatically? + +As a new execution mode is added to cover this, they do not. + + +=== RESOLVED: Why do the new quad operations not have execution scopes? + +This parameter was deemed redundant in recent discussions on existing quad operations; it has no meaning for quad operations. diff --git a/proposals/VK_KHR_shader_subgroup_rotate.adoc b/proposals/VK_KHR_shader_subgroup_rotate.adoc new file mode 100644 index 000000000..83eb8646c --- /dev/null +++ b/proposals/VK_KHR_shader_subgroup_rotate.adoc @@ -0,0 +1,150 @@ +// Copyright 2021-2024 The Khronos Group, Inc. +// +// SPDX-License-Identifier: CC-BY-4.0 + +# Subgroup rotation instruction +:toc: left +:refpage: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/ +:sectnums: + +## Problem Statement + +Subgroup operations are useful in the implementation of many compute algorithms. +Rotating values across invocations within a subgroup in particular can be useful +in the implementation of the convolution routines used in neural network inference. + +A rotation by N rotates values "down" N invocations within the subgroup. + +A rotation by (SubgroupSize - N) rotates values "up" N invocations +within the subgroup. + +Taking the example of a subgroup of size 16, a rotation by 2 would, +when executed by the invocation identified by id 0, return the value from the +invocation identified by id 2. The same rotation instruction, when executed +by the invocation identified by id 14, would return the value from the invocation +identified by id 0. + +While this rotation operation can be built on top of existing subgroup instructions, +doing so results in far from optimal performance on some implementations. + +## Solution Space + +### Using existing broadcast instruction + +It is possible to broadcast the value for each invocation to all other invocations +and for each invocation to calculate the id of the invocation whose value it needs +to retain. This is very inefficient and the cost of the rotation operation as a +whole grows linearly with the size of the subgroup. It is included here only for +the sake of completeness. + +### Using existing shuffle instruction + +The rotation operation above can be built on top of the *OpGroupNonUniformShuffle* +instruction, here abbreviated as `Shuffle`, as follows: + +``` +ShuffleRotate(value, amount) = Shuffle(value, ((amount + LocalId) & (SubgroupSize - 1))) +``` + +*OpGroupNonUniformShuffle* does not require the source +invocation's id to be dynamically uniform within the subgroup which results in +inefficient code for implementations that can optimise the case where the source +ID is dynamically uniform. Admittedly, it is possible for applications to decorate +the calculated source id with `Uniform` and implementations to detect that pattern +and emit optimised code but this approach can be complex and costly to implement as +well as brittle, especially without introducing a new high-level language construct. + +### Using existing relative shuffle instruction + +It is similarly possible to implement the rotation operation using the +*OpGroupNonUniformShuffleUp* or *OpGroupNonUniformShuffleDown* relative shuffle +instruction that are more efficient on some implementations. However, these +instructions also do not require the source invocation id to be dynamically +uniform and their relative nature makes calculating the source invocation ID +required for a rotation operation more complex than with a general shuffle. + +### New shuffle features + +Another solution that was considered is the addition of new subgroup features +that only enable shuffle instructions for cases where the source invocation ID +is dynamically uniform. While this would be a significant step toward enabling a +more efficient implementation of the rotation operation described here on +implementations that can optimise this case, it would not solve the implementation +complexity issues mentioned above. + +This functionality would however be otherwise useful and could be added to the +current proposal or be the object of a separate proposal. + +### New dedicated SPIR-V instruction + +Introduce a new dedicated SPIR-V instruction that performs subgroup rotation +operations and requires the rotation distance to be dynamically uniform. + +## Proposal + +Expose a new dedicated SPIR-V instruction, as defined by +http://htmlpreview.github.io/?https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/KHR/SPV_KHR_subgroup_rotate.html[SPV_KHR_subgroup_rotate] +to express rotating values across the invocations of a subgroup that requires +the rotation amount to be dynamically uniform within the subgroup. + +Specify new built-in functions to expose the SPIR-V instruction in GLSL: + +``` +genType subgroupRotate(genType value, uint delta); +genIType subgroupRotate(genIType value, uint delta); +genUType subgroupRotate(genUType value, uint delta); +genBType subgroupRotate(genBType value, uint delta); +genDType subgroupRotate(genDType value, uint delta); + +genType subgroupClusteredRotate(genType value, uint delta, uint clusterSize); +genIType subgroupClusteredRotate(genIType value, uint delta, uint clusterSize); +genUType subgroupClusteredRotate(genUType value, uint delta, uint clusterSize); +genBType subgroupClusteredRotate(genBType value, uint delta, uint clusterSize); +genDType subgroupClusteredRotate(genDType value, uint delta, uint clusterSize); + +If GL_EXT_shader_subgroup_extended_types_int8 is enabled: + +genI8Type subgroupRotate(genI8Type value, uint delta); +genU8Type subgroupRotate(genU8Type value, uint delta); + +genI8Type subgroupClusteredRotate(genI8Type value, uint delta, uint clusterSize); +genU8Type subgroupClusteredRotate(genU8Type value, uint delta, uint clusterSize); + +If GL_EXT_shader_subgroup_extended_types_int16 is enabled: + +genI16Type subgroupRotate(genI16Type value, uint delta); +genU16Type subgroupRotate(genU16Type value, uint delta); + +genI16Type subgroupClusteredRotate(genI16Type value, uint delta, uint clusterSize); +genU16Type subgroupClusteredRotate(genU16Type value, uint delta, uint clusterSize); + +If GL_EXT_shader_subgroup_extended_types_int64 is enabled: + +genI64Type subgroupRotate(genI64Type value, uint delta); +genU64Type subgroupRotate(genU64Type value, uint delta); + +genI64Type subgroupClusteredRotate(genI64Type value, uint delta, uint clusterSize); +genU64Type subgroupClusteredRotate(genU64Type value, uint delta, uint clusterSize); + +If GL_EXT_shader_subgroup_extended_types_float16 is enabled: + +genF16Type subgroupRotate(genF16Type value, uint delta); + +genF16Type subgroupClusteredRotate(genF16Type value, uint delta, uint clusterSize); + +``` + +Each of the rotate functions shuffles `value` to the invocation with a `gl_SubgroupInvocationID` equal to `(gl_SubgroupInvocationID + delta) % gl_SubgroupSize` for `subgroupRotate`, or to the invocation with a `gl_SubgroupInvocationID` equal to `(gl_SubgroupInvocationID - (gl_SubgroupInvocationID % clusterSize)) + ((gl_SubgroupInvocationID % clusterSize + delta) % clusterSize)` for `subgroupClusteredRotate` functions. + +## Examples + +``` +OpCapability GroupNonUniformShuffleRotateKHR +... +%result = OpGroupNonUniformShuffleRotateKHR %result_type Subgroup %value %amount +``` + +## Further Functionality + +See the above description for new shuffle features that would require the +source invocation id to be dynamically uniform. diff --git a/proposals/VK_KHR_video_decode_queue.adoc b/proposals/VK_KHR_video_decode_queue.adoc index edefec9d1..5cb27407d 100644 --- a/proposals/VK_KHR_video_decode_queue.adoc +++ b/proposals/VK_KHR_video_decode_queue.adoc @@ -419,7 +419,7 @@ formatInfo.imageUsage = VK_IMAGE_USAGE_VIDEO_DECODE_DST_BIT_KHR; vkGetPhysicalDeviceVideoFormatPropertiesKHR(physicalDevice, &formatInfo, &formatCount, NULL); formatProps = calloc(formatCount, sizeof(VkVideoFormatPropertiesKHR)); for (uint32_t i = 0; i < formatCount; ++i) { - formatProps.sType = VK_STRUCTURE_TYPE_VIDEO_FORMAT_PROPERTIES_KHR; + formatProps[i].sType = VK_STRUCTURE_TYPE_VIDEO_FORMAT_PROPERTIES_KHR; } vkGetPhysicalDeviceVideoFormatPropertiesKHR(physicalDevice, &formatInfo, &formatCount, formatProps); @@ -441,7 +441,7 @@ if ((decodeCapabilities.flags & VK_VIDEO_DECODE_CAPABILITY_DPB_AND_OUTPUT_DISTIN vkGetPhysicalDeviceVideoFormatPropertiesKHR(physicalDevice, &formatInfo, &formatCount, NULL); formatProps = calloc(formatCount, sizeof(VkVideoFormatPropertiesKHR)); for (uint32_t i = 0; i < formatCount; ++i) { - formatProps.sType = VK_STRUCTURE_TYPE_VIDEO_FORMAT_PROPERTIES_KHR; + formatProps[i].sType = VK_STRUCTURE_TYPE_VIDEO_FORMAT_PROPERTIES_KHR; } vkGetPhysicalDeviceVideoFormatPropertiesKHR(physicalDevice, &formatInfo, &formatCount, formatProps); diff --git a/proposals/VK_KHR_video_encode_queue.adoc b/proposals/VK_KHR_video_encode_queue.adoc index 50901cfc9..dcd7d4df8 100644 --- a/proposals/VK_KHR_video_encode_queue.adoc +++ b/proposals/VK_KHR_video_encode_queue.adoc @@ -658,7 +658,7 @@ formatInfo.imageUsage = VK_IMAGE_USAGE_VIDEO_ENCODE_SRC_BIT_KHR; vkGetPhysicalDeviceVideoFormatPropertiesKHR(physicalDevice, &formatInfo, &formatCount, NULL); formatProps = calloc(formatCount, sizeof(VkVideoFormatPropertiesKHR)); for (uint32_t i = 0; i < formatCount; ++i) { - formatProps.sType = VK_STRUCTURE_TYPE_VIDEO_FORMAT_PROPERTIES_KHR; + formatProps[i].sType = VK_STRUCTURE_TYPE_VIDEO_FORMAT_PROPERTIES_KHR; } vkGetPhysicalDeviceVideoFormatPropertiesKHR(physicalDevice, &formatInfo, &formatCount, formatProps); @@ -674,7 +674,7 @@ formatInfo.imageUsage = VK_IMAGE_USAGE_VIDEO_ENCODE_DPB_BIT_KHR; vkGetPhysicalDeviceVideoFormatPropertiesKHR(physicalDevice, &formatInfo, &formatCount, NULL); formatProps = calloc(formatCount, sizeof(VkVideoFormatPropertiesKHR)); for (uint32_t i = 0; i < formatCount; ++i) { - formatProps.sType = VK_STRUCTURE_TYPE_VIDEO_FORMAT_PROPERTIES_KHR; + formatProps[i].sType = VK_STRUCTURE_TYPE_VIDEO_FORMAT_PROPERTIES_KHR; } vkGetPhysicalDeviceVideoFormatPropertiesKHR(physicalDevice, &formatInfo, &formatCount, formatProps); diff --git a/proposals/VK_KHR_video_queue.adoc b/proposals/VK_KHR_video_queue.adoc index 62f2bb392..cde591667 100644 --- a/proposals/VK_KHR_video_queue.adoc +++ b/proposals/VK_KHR_video_queue.adoc @@ -697,7 +697,7 @@ vkGetPhysicalDeviceVideoFormatPropertiesKHR(physicalDevice, &formatInfo, &format VkVideoFormatPropertiesKHR* formatProps = calloc(formatCount, sizeof(VkVideoFormatPropertiesKHR)); for (uint32_t i = 0; i < formatCount; ++i) { - formatProps.sType = VK_STRUCTURE_TYPE_VIDEO_FORMAT_PROPERTIES_KHR; + formatProps[i].sType = VK_STRUCTURE_TYPE_VIDEO_FORMAT_PROPERTIES_KHR; } vkGetPhysicalDeviceVideoFormatPropertiesKHR(physicalDevice, &formatInfo, &formatCount, formatProps); @@ -744,7 +744,7 @@ vkGetVideoSessionMemoryRequirementsKHR(device, videoSession, &memReqCount, NULL) VkVideoSessionMemoryRequirementsKHR* memReqs = calloc(memReqCount, sizeof(VkVideoSessionMemoryRequirementsKHR)); for (uint32_t i = 0; i < memReqCount; ++i) { - memReqs.sType = VK_STRUCTURE_TYPE_VIDEO_SESSION_MEMORY_REQUIREMENTS_KHR; + memReqs[i].sType = VK_STRUCTURE_TYPE_VIDEO_SESSION_MEMORY_REQUIREMENTS_KHR; } vkGetVideoSessionMemoryRequirementsKHR(device, videoSession, &memReqCount, memReqs); diff --git a/scripts/check_spec_links.py b/scripts/check_spec_links.py index f4ae23213..e5ca207f4 100755 --- a/scripts/check_spec_links.py +++ b/scripts/check_spec_links.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik # # Purpose: This file performs some basic checks of the custom macros # used in the AsciiDoctor source for the spec, especially diff --git a/scripts/comment_convert.py b/scripts/comment_convert.py index f1fa938ce..518eb5806 100755 --- a/scripts/comment_convert.py +++ b/scripts/comment_convert.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik # # Purpose: This script converts leading comments on some Python # classes and functions into docstrings. diff --git a/scripts/genvk.py b/scripts/genvk.py index 8315641c7..a4d55cd02 100755 --- a/scripts/genvk.py +++ b/scripts/genvk.py @@ -16,28 +16,8 @@ sys.path.append(os.path.abspath(os.path.dirname(__file__))) from cgenerator import CGeneratorOptions, COutputGenerator -# Vulkan SC modules -from json_parser import JSONParserGenerator, JSONParserOptions -from schema_generator import SchemaGeneratorOptions, SchemaOutputGenerator -from json_generator import JSONGeneratorOptions, JSONOutputGenerator -from json_h_generator import JSONHeaderOutputGenerator, JSONHeaderGeneratorOptions -from json_c_generator import JSONCOutputGenerator, JSONCGeneratorOptions - -from docgenerator import DocGeneratorOptions, DocOutputGenerator -from extensionmetadocgenerator import (ExtensionMetaDocGeneratorOptions, - ExtensionMetaDocOutputGenerator) -from interfacedocgenerator import InterfaceDocGenerator -from generator import write -from spirvcapgenerator import SpirvCapabilityOutputGenerator -from hostsyncgenerator import HostSynchronizationOutputGenerator -from formatsgenerator import FormatsOutputGenerator -from syncgenerator import SyncOutputGenerator -from jsgenerator import JSOutputGenerator -from pygenerator import PyOutputGenerator -from rubygenerator import RubyOutputGenerator from reflib import logDiag, logWarn, logErr, setLogFile from reg import Registry -from validitygenerator import ValidityOutputGenerator from apiconventions import APIConventions # Simple timer functions @@ -107,10 +87,10 @@ def makeGenOpts(args): genpath = args.genpath # Generate MISRA C-friendly headers - misracstyle = args.misracstyle; + misracstyle = args.misracstyle # Generate MISRA C++-friendly headers - misracppstyle = args.misracppstyle; + misracppstyle = args.misracppstyle # Descriptive names for various regexp patterns used to select # versions and extensions @@ -162,234 +142,252 @@ def makeGenOpts(args): isCTS = args.isCTS - # API include files for spec and ref pages - # Overwrites include subdirectories in spec source tree - # The generated include files do not include the calling convention - # macros (apientry etc.), unlike the header files. - # Because the 1.0 core branch includes ref pages for extensions, - # all the extension interfaces need to be generated, even though - # none are used by the core spec itself. - genOpts['apiinc'] = [ - DocOutputGenerator, - DocGeneratorOptions( - conventions = conventions, - filename = 'timeMarker', - directory = directory, - genpath = genpath, - apiname = defaultAPIName, - profile = None, - versions = featuresPat, - emitversions = featuresPat, - defaultExtensions = None, - addExtensions = addExtensionsPat, - removeExtensions = removeExtensionsPat, - emitExtensions = emitExtensionsPat, - prefixText = prefixStrings + vkPrefixStrings, - apicall = '', - apientry = '', - apientryp = '*', - alignFuncParam = 48, - expandEnumerants = False) - ] + # Try to set up specification generators if the needed modules are available + try: + from docgenerator import DocGeneratorOptions, DocOutputGenerator + from jsgenerator import JSOutputGenerator + from pygenerator import PyOutputGenerator + from rubygenerator import RubyOutputGenerator + from validitygenerator import ValidityOutputGenerator + from hostsyncgenerator import HostSynchronizationOutputGenerator + from extensionmetadocgenerator import (ExtensionMetaDocGeneratorOptions, + ExtensionMetaDocOutputGenerator) + from interfacedocgenerator import InterfaceDocGenerator + from spirvcapgenerator import SpirvCapabilityOutputGenerator + from formatsgenerator import FormatsOutputGenerator + from syncgenerator import SyncOutputGenerator + + # API include files for spec and ref pages + # Overwrites include subdirectories in spec source tree + # The generated include files do not include the calling convention + # macros (apientry etc.), unlike the header files. + # Because the 1.0 core branch includes ref pages for extensions, + # all the extension interfaces need to be generated, even though + # none are used by the core spec itself. + genOpts['apiinc'] = [ + DocOutputGenerator, + DocGeneratorOptions( + conventions = conventions, + filename = 'timeMarker', + directory = directory, + genpath = genpath, + apiname = defaultAPIName, + profile = None, + versions = featuresPat, + emitversions = featuresPat, + defaultExtensions = None, + addExtensions = addExtensionsPat, + removeExtensions = removeExtensionsPat, + emitExtensions = emitExtensionsPat, + prefixText = prefixStrings + vkPrefixStrings, + apicall = '', + apientry = '', + apientryp = '*', + alignFuncParam = 48, + expandEnumerants = False) + ] - # JavaScript, Python, and Ruby representations of API information, used - # by scripts that do not need to load the full XML. - genOpts['apimap.cjs'] = [ - JSOutputGenerator, - DocGeneratorOptions( - conventions = conventions, - filename = 'apimap.cjs', - directory = directory, - genpath = None, - apiname = defaultAPIName, - profile = None, - versions = featuresPat, - emitversions = featuresPat, - defaultExtensions = None, - addExtensions = addExtensionsPat, - removeExtensions = removeExtensionsPat, - emitExtensions = emitExtensionsPat, - reparentEnums = False) - ] + # JavaScript, Python, and Ruby representations of API information, used + # by scripts that do not need to load the full XML. + genOpts['apimap.cjs'] = [ + JSOutputGenerator, + DocGeneratorOptions( + conventions = conventions, + filename = 'apimap.cjs', + directory = directory, + genpath = None, + apiname = defaultAPIName, + profile = None, + versions = featuresPat, + emitversions = featuresPat, + defaultExtensions = None, + addExtensions = addExtensionsPat, + removeExtensions = removeExtensionsPat, + emitExtensions = emitExtensionsPat, + reparentEnums = False) + ] - genOpts['apimap.py'] = [ - PyOutputGenerator, - DocGeneratorOptions( - conventions = conventions, - filename = 'apimap.py', - directory = directory, - genpath = None, - apiname = defaultAPIName, - profile = None, - versions = featuresPat, - emitversions = featuresPat, - defaultExtensions = None, - addExtensions = addExtensionsPat, - removeExtensions = removeExtensionsPat, - emitExtensions = emitExtensionsPat, - reparentEnums = False) - ] + genOpts['apimap.py'] = [ + PyOutputGenerator, + DocGeneratorOptions( + conventions = conventions, + filename = 'apimap.py', + directory = directory, + genpath = None, + apiname = defaultAPIName, + profile = None, + versions = featuresPat, + emitversions = featuresPat, + defaultExtensions = None, + addExtensions = addExtensionsPat, + removeExtensions = removeExtensionsPat, + emitExtensions = emitExtensionsPat, + reparentEnums = False) + ] - genOpts['apimap.rb'] = [ - RubyOutputGenerator, - DocGeneratorOptions( - conventions = conventions, - filename = 'apimap.rb', - directory = directory, - genpath = None, - apiname = defaultAPIName, - profile = None, - versions = featuresPat, - emitversions = featuresPat, - defaultExtensions = None, - addExtensions = addExtensionsPat, - removeExtensions = removeExtensionsPat, - emitExtensions = emitExtensionsPat, - reparentEnums = False) - ] + genOpts['apimap.rb'] = [ + RubyOutputGenerator, + DocGeneratorOptions( + conventions = conventions, + filename = 'apimap.rb', + directory = directory, + genpath = None, + apiname = defaultAPIName, + profile = None, + versions = featuresPat, + emitversions = featuresPat, + defaultExtensions = None, + addExtensions = addExtensionsPat, + removeExtensions = removeExtensionsPat, + emitExtensions = emitExtensionsPat, + reparentEnums = False) + ] + # API validity files for spec + # + # requireCommandAliases is set to True because we need validity files + # for the command something is promoted to even when the promoted-to + # feature is not included. This avoids wordy includes of validity files. + genOpts['validinc'] = [ + ValidityOutputGenerator, + DocGeneratorOptions( + conventions = conventions, + filename = 'timeMarker', + directory = directory, + genpath = None, + apiname = defaultAPIName, + profile = None, + versions = featuresPat, + emitversions = featuresPat, + defaultExtensions = None, + addExtensions = addExtensionsPat, + removeExtensions = removeExtensionsPat, + emitExtensions = emitExtensionsPat, + requireCommandAliases = True, + ) + ] - # API validity files for spec - # - # requireCommandAliases is set to True because we need validity files - # for the command something is promoted to even when the promoted-to - # feature is not included. This avoids wordy includes of validity files. - genOpts['validinc'] = [ - ValidityOutputGenerator, - DocGeneratorOptions( - conventions = conventions, - filename = 'timeMarker', - directory = directory, - genpath = None, - apiname = defaultAPIName, - profile = None, - versions = featuresPat, - emitversions = featuresPat, - defaultExtensions = None, - addExtensions = addExtensionsPat, - removeExtensions = removeExtensionsPat, - emitExtensions = emitExtensionsPat, - requireCommandAliases = True, - ) - ] + # API host sync table files for spec + genOpts['hostsyncinc'] = [ + HostSynchronizationOutputGenerator, + DocGeneratorOptions( + conventions = conventions, + filename = 'timeMarker', + directory = directory, + genpath = None, + apiname = defaultAPIName, + profile = None, + versions = featuresPat, + emitversions = featuresPat, + defaultExtensions = None, + addExtensions = addExtensionsPat, + removeExtensions = removeExtensionsPat, + emitExtensions = emitExtensionsPat, + reparentEnums = False) + ] - # API host sync table files for spec - genOpts['hostsyncinc'] = [ - HostSynchronizationOutputGenerator, - DocGeneratorOptions( - conventions = conventions, - filename = 'timeMarker', - directory = directory, - genpath = None, - apiname = defaultAPIName, - profile = None, - versions = featuresPat, - emitversions = featuresPat, - defaultExtensions = None, - addExtensions = addExtensionsPat, - removeExtensions = removeExtensionsPat, - emitExtensions = emitExtensionsPat, - reparentEnums = False) - ] + # Extension metainformation for spec extension appendices + # Includes all extensions by default, but only so that the generated + # 'promoted_extensions_*' files refer to all extensions that were + # promoted to a core version. + genOpts['extinc'] = [ + ExtensionMetaDocOutputGenerator, + ExtensionMetaDocGeneratorOptions( + conventions = conventions, + filename = 'timeMarker', + directory = directory, + genpath = None, + apiname = defaultAPIName, + profile = None, + versions = featuresPat, + emitversions = None, + defaultExtensions = defaultExtensions, + addExtensions = addExtensionsPat, + removeExtensions = None, + emitExtensions = emitExtensionsPat) + ] - # Extension metainformation for spec extension appendices - # Includes all extensions by default, but only so that the generated - # 'promoted_extensions_*' files refer to all extensions that were - # promoted to a core version. - genOpts['extinc'] = [ - ExtensionMetaDocOutputGenerator, - ExtensionMetaDocGeneratorOptions( - conventions = conventions, - filename = 'timeMarker', - directory = directory, - genpath = None, - apiname = defaultAPIName, - profile = None, - versions = featuresPat, - emitversions = None, - defaultExtensions = defaultExtensions, - addExtensions = addExtensionsPat, - removeExtensions = None, - emitExtensions = emitExtensionsPat) - ] + # Version and extension interface docs for version/extension appendices + # Includes all extensions by default. + genOpts['interfaceinc'] = [ + InterfaceDocGenerator, + DocGeneratorOptions( + conventions = conventions, + filename = 'timeMarker', + directory = directory, + genpath = None, + apiname = defaultAPIName, + profile = None, + versions = featuresPat, + emitversions = featuresPat, + defaultExtensions = None, + addExtensions = addExtensionsPat, + removeExtensions = removeExtensionsPat, + emitExtensions = emitExtensionsPat, + reparentEnums = False) + ] - # Version and extension interface docs for version/extension appendices - # Includes all extensions by default. - genOpts['interfaceinc'] = [ - InterfaceDocGenerator, - DocGeneratorOptions( - conventions = conventions, - filename = 'timeMarker', - directory = directory, - genpath = None, - apiname = defaultAPIName, - profile = None, - versions = featuresPat, - emitversions = featuresPat, - defaultExtensions = None, - addExtensions = addExtensionsPat, - removeExtensions = removeExtensionsPat, - emitExtensions = emitExtensionsPat, - reparentEnums = False) - ] + genOpts['spirvcapinc'] = [ + SpirvCapabilityOutputGenerator, + DocGeneratorOptions( + conventions = conventions, + filename = 'timeMarker', + directory = directory, + genpath = None, + apiname = defaultAPIName, + profile = None, + versions = featuresPat, + emitversions = featuresPat, + defaultExtensions = None, + addExtensions = addExtensionsPat, + removeExtensions = removeExtensionsPat, + emitExtensions = emitExtensionsPat, + emitSpirv = emitSpirvPat, + reparentEnums = False) + ] - genOpts['spirvcapinc'] = [ - SpirvCapabilityOutputGenerator, - DocGeneratorOptions( - conventions = conventions, - filename = 'timeMarker', - directory = directory, - genpath = None, - apiname = defaultAPIName, - profile = None, - versions = featuresPat, - emitversions = featuresPat, - defaultExtensions = None, - addExtensions = addExtensionsPat, - removeExtensions = removeExtensionsPat, - emitExtensions = emitExtensionsPat, - emitSpirv = emitSpirvPat, - reparentEnums = False) - ] + # Used to generate various format chapter tables + genOpts['formatsinc'] = [ + FormatsOutputGenerator, + DocGeneratorOptions( + conventions = conventions, + filename = 'timeMarker', + directory = directory, + genpath = None, + apiname = defaultAPIName, + profile = None, + versions = featuresPat, + emitversions = featuresPat, + defaultExtensions = None, + addExtensions = addExtensionsPat, + removeExtensions = removeExtensionsPat, + emitExtensions = emitExtensionsPat, + emitFormats = emitFormatsPat, + reparentEnums = False) + ] - # Used to generate various format chapter tables - genOpts['formatsinc'] = [ - FormatsOutputGenerator, - DocGeneratorOptions( - conventions = conventions, - filename = 'timeMarker', - directory = directory, - genpath = None, - apiname = defaultAPIName, - profile = None, - versions = featuresPat, - emitversions = featuresPat, - defaultExtensions = None, - addExtensions = addExtensionsPat, - removeExtensions = removeExtensionsPat, - emitExtensions = emitExtensionsPat, - emitFormats = emitFormatsPat, - reparentEnums = False) - ] + # Used to generate various synchronization chapter tables + genOpts['syncinc'] = [ + SyncOutputGenerator, + DocGeneratorOptions( + conventions = conventions, + filename = 'timeMarker', + directory = directory, + genpath = None, + apiname = defaultAPIName, + profile = None, + versions = featuresPat, + emitversions = featuresPat, + defaultExtensions = None, + addExtensions = addExtensionsPat, + removeExtensions = removeExtensionsPat, + emitExtensions = emitExtensionsPat, + reparentEnums = False) + ] - # Used to generate various synchronization chapter tables - genOpts['syncinc'] = [ - SyncOutputGenerator, - DocGeneratorOptions( - conventions = conventions, - filename = 'timeMarker', - directory = directory, - genpath = None, - apiname = defaultAPIName, - profile = None, - versions = featuresPat, - emitversions = featuresPat, - defaultExtensions = None, - addExtensions = addExtensionsPat, - removeExtensions = removeExtensionsPat, - emitExtensions = emitExtensionsPat, - reparentEnums = False) - ] + except ImportError: + # Module dependencies are not available for spec generation + pass # Platform extensions, in their own header files # Each element of the platforms[] array defines information for @@ -602,47 +600,82 @@ def makeGenOpts(args): misracppstyle = misracppstyle) ] - genOpts['vk.json'] = [ - SchemaOutputGenerator, - SchemaGeneratorOptions( - conventions = conventions, - filename = 'vk.json', - directory = directory, - apiname = 'vulkansc', - profile = None, - versions = scVersions, - emitversions = scVersions, - defaultExtensions = 'vulkansc', - addExtensions = addExtensionsPat, - removeExtensions = removeExtensionsPat, - emitExtensions = emitExtensionsPat, - prefixText = prefixStrings + vkPrefixStrings, - genFuncPointers = True, - protectFile = protectFile, - protectFeature = False, - protectProto = '#ifndef', - protectProtoStr = 'VK_NO_PROTOTYPES', - apicall = 'VKAPI_ATTR ', - apientry = 'VKAPI_CALL ', - apientryp = 'VKAPI_PTR *', - alignFuncParam = 48) - ] + # Try to set up Vulkan SC JSON generators if the needed modules are available + try: + from json_parser import JSONParserGenerator, JSONParserOptions + from schema_generator import SchemaGeneratorOptions, SchemaOutputGenerator + from json_generator import JSONGeneratorOptions, JSONOutputGenerator + from json_h_generator import JSONHeaderOutputGenerator, JSONHeaderGeneratorOptions + from json_c_generator import JSONCOutputGenerator, JSONCGeneratorOptions + + genOpts['vk.json'] = [ + SchemaOutputGenerator, + SchemaGeneratorOptions( + conventions = conventions, + filename = 'vk.json', + directory = directory, + apiname = 'vulkansc', + profile = None, + versions = scVersions, + emitversions = scVersions, + defaultExtensions = 'vulkansc', + addExtensions = addExtensionsPat, + removeExtensions = removeExtensionsPat, + emitExtensions = emitExtensionsPat, + prefixText = prefixStrings + vkPrefixStrings, + genFuncPointers = True, + protectFile = protectFile, + protectFeature = False, + protectProto = '#ifndef', + protectProtoStr = 'VK_NO_PROTOTYPES', + apicall = 'VKAPI_ATTR ', + apientry = 'VKAPI_CALL ', + apientryp = 'VKAPI_PTR *', + alignFuncParam = 48) + ] - if vulkanLayer: - genOpts['vulkan_json_data.hpp'] = [ + if vulkanLayer: + genOpts['vulkan_json_data.hpp'] = [ + JSONOutputGenerator, + JSONGeneratorOptions( + conventions = conventions, + filename = 'vulkan_json_data.hpp', + directory = directory, + apiname = 'vulkan', + profile = None, + versions = featuresPat, + emitversions = featuresPat, + defaultExtensions = None, + addExtensions = addExtensionsPat, + removeExtensions = None, + emitExtensions = None, + vulkanLayer = vulkanLayer, + prefixText = prefixStrings + vkPrefixStrings, + genFuncPointers = True, + protectFile = protectFile, + protectFeature = False, + protectProto = '#ifndef', + protectProtoStr = 'VK_NO_PROTOTYPES', + apicall = 'VKAPI_ATTR ', + apientry = 'VKAPI_CALL ', + apientryp = 'VKAPI_PTR *', + alignFuncParam = 48) + ] + else: + genOpts['vulkan_json_data.hpp'] = [ JSONOutputGenerator, JSONGeneratorOptions( conventions = conventions, filename = 'vulkan_json_data.hpp', directory = directory, - apiname = 'vulkan', + apiname = 'vulkansc', profile = None, - versions = featuresPat, - emitversions = featuresPat, - defaultExtensions = None, + versions = scVersions, + emitversions = scVersions, + defaultExtensions = 'vulkansc', addExtensions = addExtensionsPat, - removeExtensions = None, - emitExtensions = None, + removeExtensions = removeExtensionsPat, + emitExtensions = emitExtensionsPat, vulkanLayer = vulkanLayer, prefixText = prefixStrings + vkPrefixStrings, genFuncPointers = True, @@ -653,122 +686,98 @@ def makeGenOpts(args): apicall = 'VKAPI_ATTR ', apientry = 'VKAPI_CALL ', apientryp = 'VKAPI_PTR *', + isCTS = isCTS, alignFuncParam = 48) ] - else: - genOpts['vulkan_json_data.hpp'] = [ - JSONOutputGenerator, - JSONGeneratorOptions( - conventions = conventions, - filename = 'vulkan_json_data.hpp', - directory = directory, - apiname = 'vulkansc', - profile = None, - versions = scVersions, - emitversions = scVersions, - defaultExtensions = 'vulkansc', - addExtensions = addExtensionsPat, - removeExtensions = removeExtensionsPat, - emitExtensions = emitExtensionsPat, - vulkanLayer = vulkanLayer, - prefixText = prefixStrings + vkPrefixStrings, - genFuncPointers = True, - protectFile = protectFile, - protectFeature = False, - protectProto = '#ifndef', - protectProtoStr = 'VK_NO_PROTOTYPES', - apicall = 'VKAPI_ATTR ', - apientry = 'VKAPI_CALL ', - apientryp = 'VKAPI_PTR *', - isCTS = isCTS, - alignFuncParam = 48) - ] - # keep any relevant platform extensions for the following generators - # (needed for e.g. the vulkan_sci extensions) - explicitRemoveExtensionsPat = makeREstring( - removeExtensions, None, strings_are_regex=True) + # keep any relevant platform extensions for the following generators + # (needed for e.g. the vulkan_sci extensions) + explicitRemoveExtensionsPat = makeREstring( + removeExtensions, None, strings_are_regex=True) - # Raw C header file generator. - genOpts['vulkan_json_gen.h'] = [ - JSONHeaderOutputGenerator, - JSONHeaderGeneratorOptions( - conventions = conventions, - filename = 'vulkan_json_gen.h', - directory = directory, - apiname = 'vulkansc', - profile = None, - versions = scVersions, - emitversions = scVersions, - defaultExtensions = 'vulkansc', - addExtensions = addExtensionsPat, - removeExtensions = explicitRemoveExtensionsPat, - emitExtensions = emitExtensionsPat, - prefixText = prefixStrings + vkPrefixStrings, - genFuncPointers = True, - protectFile = protectFile, - protectFeature = False, - protectProto = '#ifndef', - protectProtoStr = 'VK_NO_PROTOTYPES', - apicall = 'VKAPI_ATTR ', - apientry = 'VKAPI_CALL ', - apientryp = 'VKAPI_PTR *', - alignFuncParam = 48) - ] + # Raw C header file generator. + genOpts['vulkan_json_gen.h'] = [ + JSONHeaderOutputGenerator, + JSONHeaderGeneratorOptions( + conventions = conventions, + filename = 'vulkan_json_gen.h', + directory = directory, + apiname = 'vulkansc', + profile = None, + versions = scVersions, + emitversions = scVersions, + defaultExtensions = 'vulkansc', + addExtensions = addExtensionsPat, + removeExtensions = explicitRemoveExtensionsPat, + emitExtensions = emitExtensionsPat, + prefixText = prefixStrings + vkPrefixStrings, + genFuncPointers = True, + protectFile = protectFile, + protectFeature = False, + protectProto = '#ifndef', + protectProtoStr = 'VK_NO_PROTOTYPES', + apicall = 'VKAPI_ATTR ', + apientry = 'VKAPI_CALL ', + apientryp = 'VKAPI_PTR *', + alignFuncParam = 48) + ] - # Raw C source file generator. - genOpts['vulkan_json_gen.c'] = [ - JSONCOutputGenerator, - JSONCGeneratorOptions( - conventions = conventions, - filename = 'vulkan_json_gen.c', - directory = directory, - apiname = 'vulkansc', - profile = None, - versions = scVersions, - emitversions = scVersions, - defaultExtensions = 'vulkansc', - addExtensions = addExtensionsPat, - removeExtensions = explicitRemoveExtensionsPat, - emitExtensions = emitExtensionsPat, - prefixText = prefixStrings + vkPrefixStrings, - genFuncPointers = True, - protectFile = protectFile, - protectFeature = False, - protectProto = '#ifndef', - protectProtoStr = 'VK_NO_PROTOTYPES', - apicall = 'VKAPI_ATTR ', - apientry = 'VKAPI_CALL ', - apientryp = 'VKAPI_PTR *', - alignFuncParam = 48) - ] + # Raw C source file generator. + genOpts['vulkan_json_gen.c'] = [ + JSONCOutputGenerator, + JSONCGeneratorOptions( + conventions = conventions, + filename = 'vulkan_json_gen.c', + directory = directory, + apiname = 'vulkansc', + profile = None, + versions = scVersions, + emitversions = scVersions, + defaultExtensions = 'vulkansc', + addExtensions = addExtensionsPat, + removeExtensions = explicitRemoveExtensionsPat, + emitExtensions = emitExtensionsPat, + prefixText = prefixStrings + vkPrefixStrings, + genFuncPointers = True, + protectFile = protectFile, + protectFeature = False, + protectProto = '#ifndef', + protectProtoStr = 'VK_NO_PROTOTYPES', + apicall = 'VKAPI_ATTR ', + apientry = 'VKAPI_CALL ', + apientryp = 'VKAPI_PTR *', + alignFuncParam = 48) + ] - genOpts['vulkan_json_parser.hpp'] = [ - JSONParserGenerator, - JSONParserOptions( - conventions = conventions, - filename = 'vulkan_json_parser.hpp', - directory = directory, - apiname = 'vulkansc', - profile = None, - versions = scVersions, - emitversions = scVersions, - defaultExtensions = 'vulkansc', - addExtensions = addExtensionsPat, - removeExtensions = explicitRemoveExtensionsPat, - emitExtensions = emitExtensionsPat, - prefixText = prefixStrings + vkPrefixStrings, - genFuncPointers = True, - protectFile = protectFile, - protectFeature = False, - protectProto = '#ifndef', - protectProtoStr = 'VK_NO_PROTOTYPES', - apicall = 'VKAPI_ATTR ', - apientry = 'VKAPI_CALL ', - apientryp = 'VKAPI_PTR *', - isCTS = isCTS, - alignFuncParam = 48) - ] + genOpts['vulkan_json_parser.hpp'] = [ + JSONParserGenerator, + JSONParserOptions( + conventions = conventions, + filename = 'vulkan_json_parser.hpp', + directory = directory, + apiname = 'vulkansc', + profile = None, + versions = scVersions, + emitversions = scVersions, + defaultExtensions = 'vulkansc', + addExtensions = addExtensionsPat, + removeExtensions = explicitRemoveExtensionsPat, + emitExtensions = emitExtensionsPat, + prefixText = prefixStrings + vkPrefixStrings, + genFuncPointers = True, + protectFile = protectFile, + protectFeature = False, + protectProto = '#ifndef', + protectProtoStr = 'VK_NO_PROTOTYPES', + apicall = 'VKAPI_ATTR ', + apientry = 'VKAPI_CALL ', + apientryp = 'VKAPI_PTR *', + isCTS = isCTS, + alignFuncParam = 48) + ] + except ImportError: + # Module dependencies are not available for Vulkan SC JSON generation + pass # Unused - vulkan10.h target. # It is possible to generate a header with just the Vulkan 1.0 + @@ -969,6 +978,7 @@ def genTarget(args): options = genOpts[args.target][1] logDiag('* Building', options.filename) + logDiag('* options.apiname =', options.apiname) logDiag('* options.versions =', options.versions) logDiag('* options.emitversions =', options.emitversions) logDiag('* options.defaultExtensions =', options.defaultExtensions) diff --git a/scripts/spec_tools/__init__.py b/scripts/spec_tools/__init__.py index 34c01f392..553ec1ab6 100644 --- a/scripts/spec_tools/__init__.py +++ b/scripts/spec_tools/__init__.py @@ -4,4 +4,4 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik diff --git a/scripts/spec_tools/algo.py b/scripts/spec_tools/algo.py index e9dff4a13..e45aaa8eb 100644 --- a/scripts/spec_tools/algo.py +++ b/scripts/spec_tools/algo.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik """RecursiveMemoize serves as a base class for a function modeled as a dictionary computed on-the-fly.""" diff --git a/scripts/spec_tools/base_printer.py b/scripts/spec_tools/base_printer.py index f48905acd..a3e0a4a45 100644 --- a/scripts/spec_tools/base_printer.py +++ b/scripts/spec_tools/base_printer.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik from abc import ABC, abstractmethod from pathlib import Path diff --git a/scripts/spec_tools/consistency_tools.py b/scripts/spec_tools/consistency_tools.py index eab6d470a..74365e1f3 100644 --- a/scripts/spec_tools/consistency_tools.py +++ b/scripts/spec_tools/consistency_tools.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik """Provides utilities to write a script to verify XML registry consistency.""" import re diff --git a/scripts/spec_tools/console_printer.py b/scripts/spec_tools/console_printer.py index 7d69aac21..2b46a4f71 100644 --- a/scripts/spec_tools/console_printer.py +++ b/scripts/spec_tools/console_printer.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik from sys import stdout diff --git a/scripts/spec_tools/data_structures.py b/scripts/spec_tools/data_structures.py index f2808cf1e..008d1405f 100644 --- a/scripts/spec_tools/data_structures.py +++ b/scripts/spec_tools/data_structures.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik """Provides general-purpose data structures.""" diff --git a/scripts/spec_tools/entity_db.py b/scripts/spec_tools/entity_db.py index a6850069c..f79f62679 100644 --- a/scripts/spec_tools/entity_db.py +++ b/scripts/spec_tools/entity_db.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik from abc import ABC, abstractmethod diff --git a/scripts/spec_tools/file_process.py b/scripts/spec_tools/file_process.py index f0d4c6081..bfc1e0c9b 100644 --- a/scripts/spec_tools/file_process.py +++ b/scripts/spec_tools/file_process.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik "Utilities for processing files." from pathlib import Path diff --git a/scripts/spec_tools/html_printer.py b/scripts/spec_tools/html_printer.py index 3ec87afee..79b5a1cf0 100644 --- a/scripts/spec_tools/html_printer.py +++ b/scripts/spec_tools/html_printer.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik import html import re diff --git a/scripts/spec_tools/macro_checker.py b/scripts/spec_tools/macro_checker.py index a8a75aa81..fe150341e 100644 --- a/scripts/spec_tools/macro_checker.py +++ b/scripts/spec_tools/macro_checker.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik from io import StringIO import re diff --git a/scripts/spec_tools/macro_checker_file.py b/scripts/spec_tools/macro_checker_file.py index f2d6784b6..cd45bf3fb 100644 --- a/scripts/spec_tools/macro_checker_file.py +++ b/scripts/spec_tools/macro_checker_file.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik import logging import re diff --git a/scripts/spec_tools/main.py b/scripts/spec_tools/main.py index e035ce36d..c8dc7e9f5 100644 --- a/scripts/spec_tools/main.py +++ b/scripts/spec_tools/main.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik import argparse diff --git a/scripts/spec_tools/shared.py b/scripts/spec_tools/shared.py index 458632e8a..7bb752a54 100644 --- a/scripts/spec_tools/shared.py +++ b/scripts/spec_tools/shared.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik import platform from collections import namedtuple diff --git a/scripts/test_check_spec_links.py b/scripts/test_check_spec_links.py index fcc97f8bd..352b1d560 100644 --- a/scripts/test_check_spec_links.py +++ b/scripts/test_check_spec_links.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik # # Purpose: This file contains tests for check_spec_links.py diff --git a/scripts/test_check_spec_links_api_specific.py b/scripts/test_check_spec_links_api_specific.py index 587eed386..9fa14a730 100644 --- a/scripts/test_check_spec_links_api_specific.py +++ b/scripts/test_check_spec_links_api_specific.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik # # Purpose: This file contains tests for check_spec_links.py # that depend on the API being used. diff --git a/scripts/test_entity_db.py b/scripts/test_entity_db.py index ef08794c0..1b13f2f1e 100644 --- a/scripts/test_entity_db.py +++ b/scripts/test_entity_db.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik import pytest diff --git a/scripts/xml_consistency.py b/scripts/xml_consistency.py index e52f5e4f8..e1e4b19f8 100755 --- a/scripts/xml_consistency.py +++ b/scripts/xml_consistency.py @@ -4,7 +4,7 @@ # # SPDX-License-Identifier: Apache-2.0 # -# Author(s): Ryan Pavlik +# Author(s): Rylie Pavlik # # Purpose: This script checks some "business logic" in the XML registry. @@ -40,6 +40,7 @@ 'VK_KHR_external_fence_win32', 'VK_KHR_external_memory_win32', 'VK_KHR_external_semaphore_win32', + 'VK_KHR_index_type_uint8', 'VK_KHR_shader_atomic_int64', 'VK_KHR_shader_float16_int8', 'VK_KHR_spirv_1_4', diff --git a/xml/profiles/VP_KHR_roadmap_2022.json b/xml/profiles/VP_KHR_roadmap.json similarity index 79% rename from xml/profiles/VP_KHR_roadmap_2022.json rename to xml/profiles/VP_KHR_roadmap.json index d950e7748..e7a850055 100644 --- a/xml/profiles/VP_KHR_roadmap_2022.json +++ b/xml/profiles/VP_KHR_roadmap.json @@ -1,5 +1,5 @@ { - "$schema": "https://schema.khronos.org/vulkan/profiles-0.8.1-204.json#", + "$schema": "https://schema.khronos.org/vulkan/profiles-0.8.2-276.json#", "capabilities": { "vulkan10requirements": { "features": { @@ -8,6 +8,71 @@ } } }, + "vulkan11requirements": { + "features": { + "VkPhysicalDeviceVulkan11Features": { + "multiview": true + } + }, + "properties": { + "VkPhysicalDeviceVulkan11Properties": { + "maxMultiviewViewCount": 6, + "maxMultiviewInstanceIndex": 134217727 + } + } + }, + "vulkan12requirements": { + "features": { + "VkPhysicalDeviceVulkan12Features": { + "uniformBufferStandardLayout": true, + "subgroupBroadcastDynamicId": true, + "imagelessFramebuffer": true, + "separateDepthStencilLayouts": true, + "hostQueryReset": true, + "timelineSemaphore": true, + "shaderSubgroupExtendedTypes": true + } + }, + "properties": { + "VkPhysicalDeviceVulkan12Properties": { + "maxTimelineSemaphoreValueDifference": 2147483647 + } + } + }, + "vulkan13requirements": { + "features": { + "VkPhysicalDeviceVulkan12Features": { + "vulkanMemoryModel": true, + "vulkanMemoryModelDeviceScope": true, + "bufferDeviceAddress": true + }, + "VkPhysicalDeviceVulkan13Features": { + "robustImageAccess": true, + "shaderTerminateInvocation": true, + "shaderZeroInitializeWorkgroupMemory": true, + "synchronization2": true, + "shaderIntegerDotProduct": true, + "maintenance4": true, + "pipelineCreationCacheControl": true, + "subgroupSizeControl": true, + "computeFullSubgroups": true, + "shaderDemoteToHelperInvocation": true, + "inlineUniformBlock": true, + "dynamicRendering": true + } + }, + "properties": { + "VkPhysicalDeviceVulkan13Properties": { + "maxBufferSize": 1073741824, + "maxInlineUniformBlockSize": 256, + "maxPerStageDescriptorInlineUniformBlocks": 4, + "maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks": 4, + "maxDescriptorSetInlineUniformBlocks": 4, + "maxDescriptorSetUpdateAfterBindInlineUniformBlocks": 4, + "maxInlineUniformTotalSize": 256 + } + } + }, "vulkan10requirements_roadmap2022": { "features": { "VkPhysicalDeviceFeatures": { @@ -76,19 +141,6 @@ } } }, - "vulkan11requirements": { - "features": { - "VkPhysicalDeviceVulkan11Features": { - "multiview": true - } - }, - "properties": { - "VkPhysicalDeviceVulkan11Properties": { - "maxMultiviewViewCount": 6, - "maxMultiviewInstanceIndex": 134217727 - } - } - }, "vulkan11requirements_roadmap2022": { "features": { "VkPhysicalDeviceVulkan11Features": { @@ -103,24 +155,6 @@ } } }, - "vulkan12requirements": { - "features": { - "VkPhysicalDeviceVulkan12Features": { - "uniformBufferStandardLayout": true, - "subgroupBroadcastDynamicId": true, - "imagelessFramebuffer": true, - "separateDepthStencilLayouts": true, - "hostQueryReset": true, - "timelineSemaphore": true, - "shaderSubgroupExtendedTypes": true - } - }, - "properties": { - "VkPhysicalDeviceVulkan12Properties": { - "maxTimelineSemaphoreValueDifference": 2147483647 - } - } - }, "vulkan12requirements_roadmap2022": { "features": { "VkPhysicalDeviceVulkan12Features": { @@ -168,52 +202,103 @@ } } }, - "vulkan13requirements": { + "vulkan13requirements_roadmap2022": { + "extensions": { + "VK_KHR_global_priority": 1 + }, "features": { - "VkPhysicalDeviceVulkan12Features": { - "vulkanMemoryModel": true, - "vulkanMemoryModelDeviceScope": true, - "bufferDeviceAddress": true - }, "VkPhysicalDeviceVulkan13Features": { - "robustImageAccess": true, - "shaderTerminateInvocation": true, - "shaderZeroInitializeWorkgroupMemory": true, - "synchronization2": true, - "shaderIntegerDotProduct": true, - "maintenance4": true, - "pipelineCreationCacheControl": true, - "subgroupSizeControl": true, - "computeFullSubgroups": true, - "shaderDemoteToHelperInvocation": true, - "inlineUniformBlock": true, - "dynamicRendering": true + "descriptorBindingInlineUniformBlockUpdateAfterBind": true + } + } + }, + "vulkan10requirements_roadmap2024": { + "features": { + "VkPhysicalDeviceFeatures": { + "multiDrawIndirect": true, + "shaderInt16": true, + "shaderImageGatherExtended": true } }, "properties": { - "VkPhysicalDeviceVulkan13Properties": { - "maxBufferSize": 1073741824, - "maxInlineUniformBlockSize": 256, - "maxPerStageDescriptorInlineUniformBlocks": 4, - "maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks": 4, - "maxDescriptorSetInlineUniformBlocks": 4, - "maxDescriptorSetUpdateAfterBindInlineUniformBlocks": 4, - "maxInlineUniformTotalSize": 256 + "VkPhysicalDeviceProperties": { + "limits": { + "timestampComputeAndGraphics": true, + "maxColorAttachments": 8, + "maxBoundDescriptorSets": 7 + } } } }, - "vulkan13requirements_roadmap2022": { - "extensions": { - "VK_KHR_global_priority": 1 + "vulkan11requirements_roadmap2024": { + "features": { + "VkPhysicalDeviceVulkan11Features": { + "shaderDrawParameters": true, + "storageBuffer16BitAccess": true + } + } + }, + "vulkan12requirements_roadmap2024": { + "features": { + "VkPhysicalDeviceVulkan12Features": { + "shaderInt8": true, + "shaderFloat16": true, + "storageBuffer8BitAccess": true + } }, + "properties": { + "VkPhysicalDeviceVulkan12Properties": { + "shaderRoundingModeRTEFloat16": true, + "shaderRoundingModeRTEFloat32": true + } + } + }, + "vulkan13requirements_roadmap2024": { "features": { "VkPhysicalDeviceVulkan13Features": { - "descriptorBindingInlineUniformBlockUpdateAfterBind": true } + }, + "properties": { + "VkPhysicalDeviceVulkan13Properties": { + } + } + }, + "vulkanextensionrequirements_roadmap2024": { + "extensions": { + "VK_KHR_dynamic_rendering_local_read": 1, + "VK_KHR_load_store_op_none": 1, + "VK_KHR_shader_quad_control": 1, + "VK_KHR_shader_maximal_reconvergence": 1, + "VK_KHR_shader_subgroup_uniform_control_flow": 1, + "VK_KHR_shader_subgroup_rotate": 1, + "VK_KHR_shader_float_controls2": 1, + "VK_KHR_shader_expect_assume": 1, + "VK_KHR_line_rasterization": 1, + "VK_KHR_vertex_attribute_divisor": 1, + "VK_KHR_index_type_uint8": 1, + "VK_KHR_map_memory2": 1, + "VK_KHR_maintenance5": 1, + "VK_KHR_push_descriptor": 1 } } }, "profiles": { + "VP_KHR_roadmap_2024": { + "version": 1, + "api-version": "1.3.276", + "label": "Khronos Vulkan Roadmap 2024 profile", + "description": "This roadmap profile is intended to be supported by newer devices shipping in 2024 across mainstream smartphone, tablet, laptops, console and desktop devices.", + "profiles": [ + "VP_KHR_roadmap_2022" + ], + "capabilities": [ + "vulkan10requirements_roadmap2024", + "vulkan11requirements_roadmap2024", + "vulkan12requirements_roadmap2024", + "vulkan13requirements_roadmap2024", + "vulkanextensionrequirements_roadmap2024" + ] + }, "VP_KHR_roadmap_2022": { "version": 1, "api-version": "1.3.204", @@ -232,6 +317,12 @@ } }, "history": [ + { + "revision": 9, + "date": "2024-01-16", + "author": "Tobias Hector", + "comment": "Add Roadmap 2024 profile" + }, { "revision": 8, "date": "2023-11-02", diff --git a/xml/vk.xml b/xml/vk.xml old mode 100644 new mode 100755 index fa397281d..82ec5eb12 --- a/xml/vk.xml +++ b/xml/vk.xml @@ -175,7 +175,7 @@ branch of the member gitlab server. #define VKSC_API_VERSION_1_0 VK_MAKE_API_VERSION(VKSC_API_VARIANT, 1, 0, 0)// Patch version should always be set to 0 // Version of this file -#define VK_HEADER_VERSION 275 +#define VK_HEADER_VERSION 276 // Complete version of this file #define VK_HEADER_VERSION_COMPLETE VK_MAKE_API_VERSION(0, 1, 3, VK_HEADER_VERSION) // Version of this file @@ -732,7 +732,8 @@ typedef void* MTLSharedEvent_id; - + + @@ -3882,7 +3883,7 @@ typedef void* MTLSharedEvent_id; VkDebugUtilsMessengerCallbackDataFlagsEXT flags const char* pMessageIdName int32_t messageIdNumber - const char* pMessage + const char* pMessage uint32_t queueLabelCount const VkDebugUtilsLabelEXT* pQueueLabels uint32_t cmdBufLabelCount @@ -5016,7 +5017,7 @@ typedef void* MTLSharedEvent_id; void* pNext VkShaderStageFlags cooperativeMatrixSupportedStages - + VkStructureType sType void* pNext uint32_t MSize @@ -5231,11 +5232,12 @@ typedef void* MTLSharedEvent_id; VkBool32 shaderSubgroupClock VkBool32 shaderDeviceClock - - VkStructureType sType + + VkStructureType sType void* pNext VkBool32 indexTypeUint8 + VkStructureType sType void* pNext @@ -5401,8 +5403,8 @@ typedef void* MTLSharedEvent_id; VkDeviceMemory memory - - VkStructureType sType + + VkStructureType sType void* pNext VkBool32 rectangularLines VkBool32 bresenhamLines @@ -5411,19 +5413,22 @@ typedef void* MTLSharedEvent_id; VkBool32 stippledBresenhamLines VkBool32 stippledSmoothLines - - VkStructureType sType + + + VkStructureType sType void* pNext uint32_t lineSubPixelPrecisionBits - - VkStructureType sType - const void* pNext - VkLineRasterizationModeEXT lineRasterizationMode + + + VkStructureType sType + const void* pNext + VkLineRasterizationModeKHR lineRasterizationMode VkBool32 stippledLineEnable uint32_t lineStippleFactor uint16_t lineStipplePattern + VkStructureType sType void* pNext @@ -6227,7 +6232,7 @@ typedef void* MTLSharedEvent_id; VkFragmentShadingRateNV shadingRate VkFragmentShadingRateCombinerOpKHR combinerOps[2] - + VkStructureType sType const void* pNext VkDeviceSize accelerationStructureSize @@ -7601,7 +7606,7 @@ typedef void* MTLSharedEvent_id; const void* pNext zx_handle_t collectionToken - + VkStructureType sType void* pNext uint32_t memoryTypeBits @@ -8084,7 +8089,7 @@ typedef void* MTLSharedEvent_id; VkMicromapEXT micromap - + VkStructureType sType void* pNext uint8_t pipelineIdentifier[VK_UUID_SIZE] @@ -8347,7 +8352,7 @@ typedef void* MTLSharedEvent_id; uint32_t vendorInfoCount VkDeviceSize vendorBinarySizeSpecified in bytes - + VkStructureType sType void* pNext char description[VK_MAX_DESCRIPTION_SIZE]Free-form description of the fault @@ -8663,7 +8668,7 @@ typedef void* MTLSharedEvent_id; VkBool32 cooperativeMatrix VkBool32 cooperativeMatrixRobustBufferAccess - + VkStructureType sType void* pNext uint32_t MSize @@ -8990,6 +8995,51 @@ typedef void* MTLSharedEvent_id; uint32_t stripeSemaphoreInfoCount const VkSemaphoreSubmitInfo* pStripeSemaphoreInfos + + VkStructureType sType + void* pNext + VkBool32 shaderMaximalReconvergence + + + VkStructureType sType + void* pNext + VkBool32 shaderSubgroupRotate + VkBool32 shaderSubgroupRotateClustered + + + VkStructureType sType + void* pNext + VkBool32 shaderExpectAssume + + + VkStructureType sType + void* pNext + VkBool32 shaderFloatControls2 + + + VkStructureType sType + void* pNext + VkBool32 dynamicRenderingLocalRead + + + VkStructureType sType + const void* pNext + uint32_t colorAttachmentCount + const uint32_t* pColorAttachmentLocations + + + VkStructureType sType + const void* pNext + uint32_t colorAttachmentCount + const uint32_t* pColorAttachmentInputIndices + const uint32_t* pDepthInputAttachmentIndex + const uint32_t* pStencilInputAttachmentIndex + + + VkStructureType sType + void* pNext + VkBool32 shaderQuadControl + @@ -10414,11 +10464,15 @@ typedef void* MTLSharedEvent_id; - - - - - + + + + + + + + + @@ -13964,11 +14018,12 @@ typedef void* MTLSharedEvent_id; VkPipelineExecutableInternalRepresentationKHR* pInternalRepresentations - void vkCmdSetLineStippleEXT + void vkCmdSetLineStippleKHR VkCommandBuffer commandBuffer uint32_t lineStippleFactor uint16_t lineStipplePattern + VkResult vkGetFaultData VkDevice device @@ -15097,7 +15152,7 @@ typedef void* MTLSharedEvent_id; void vkDestroyShaderEXT VkDevice device - VkShaderEXT shader + VkShaderEXT shader const VkAllocationCallbacks* pAllocator @@ -15230,6 +15285,16 @@ typedef void* MTLSharedEvent_id; VkQueue queue const VkOutOfBandQueueTypeInfoNV* pQueueTypeInfo + + void vkCmdSetRenderingAttachmentLocationsKHR + VkCommandBuffer commandBuffer + const VkRenderingAttachmentLocationInfoKHR* pLocationInfo + + + void vkCmdSetRenderingInputAttachmentIndicesKHR + VkCommandBuffer commandBuffer + const VkRenderingInputAttachmentIndexInfoKHR* pLocationInfo + @@ -20026,10 +20091,19 @@ typedef void* MTLSharedEvent_id; - + - - + + + + + + + + + + + @@ -20046,10 +20120,12 @@ typedef void* MTLSharedEvent_id; - + - - + + + + @@ -20342,10 +20418,10 @@ typedef void* MTLSharedEvent_id; - - - - + + + + @@ -20388,12 +20464,12 @@ typedef void* MTLSharedEvent_id; - + - - + + @@ -22264,11 +22340,11 @@ typedef void* MTLSharedEvent_id; - + - - + + @@ -22394,10 +22470,12 @@ typedef void* MTLSharedEvent_id; - + - - + + + + @@ -22581,10 +22659,12 @@ typedef void* MTLSharedEvent_id; - + - - + + + + @@ -22751,7 +22831,6 @@ typedef void* MTLSharedEvent_id; - @@ -22762,21 +22841,10 @@ typedef void* MTLSharedEvent_id; - - - - - - - - - - - @@ -22787,15 +22855,45 @@ typedef void* MTLSharedEvent_id; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -23277,15 +23375,31 @@ typedef void* MTLSharedEvent_id; + + + + + + + + + + + + + + + + @@ -23750,10 +23864,12 @@ typedef void* MTLSharedEvent_id; - + - - + + + + @@ -23762,10 +23878,12 @@ typedef void* MTLSharedEvent_id; - + - - + + + + @@ -23807,16 +23925,28 @@ typedef void* MTLSharedEvent_id; - + - - + + + + + - + - - + + + + + + + + + + + @@ -23878,10 +24008,12 @@ typedef void* MTLSharedEvent_id; - + - - + + + + @@ -23984,6 +24116,24 @@ typedef void* MTLSharedEvent_id; + + + + + + + + + + + + + + + + + + @@ -25612,6 +25762,21 @@ typedef void* MTLSharedEvent_id; + + + + + + + + + + + + + + + @@ -26107,6 +26272,18 @@ typedef void* MTLSharedEvent_id; + + + + + + + + + + + +