-
Notifications
You must be signed in to change notification settings - Fork 475
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Change log for September 26, 2024 Vulkan 1.3.296 spec update:
Public Issues * Fix spelling of StdVideoH264SpsVuiFlags::color_description_present_flag member in video.xml (public issue 2428). * Fix copy-paste typo in vkAcquireNextImageKHR VU 07783 (public issue 2433). * Document support for the `stride` XML attribute for array pointers in both command `<param>` and structure `<member>` tags (public issue 2435). Internal Issues * Add accuracy and denorm specifications for SPIR-V OpSubgroupAllEqualKHR and OpGroupNonUniformAllEqual to the <<spirvenv-precision-operation, Precision and Operation of SPIR-V Instructions>> section (internal issue 3902). * Clean up markup and description of the Cube Map Derivative Transformation equations (internal issue 4010). * Add new `Required_Limits` refpage containing the tables from the <<limits-minmax, Limit Requirements>> section (internal issue 4014). * Move the description of VkResult code VK_ERROR_NOT_ENOUGH_SPACE_KHR to the <<fundamentals-errorcodes, Error Codes>> list instead of the Success Codes list (internal issue 4017). * Fix some VUs for VK_EXT_swapchain_maintenance1 (internal MR 6199). * Reword the first synchronization scope description for <<synchronization-semaphores-waiting, Semaphore Waiting>> to be more clear and explicit (internal MR 6835). * Coalesce decode output variants in XML `<videoformat>` tags (internal MR 6850). * Fix some structure names in new 'require' / 'feature' tags (internal MR 6852). * Move VK_KHR_compute_shader_derivatives feature requirement to vk.xml (internal MR 6854). * Remove redundant VkDrawIndirectCommand VU 00500 and VkDrawIndexedIndirectCommand VU 00552 (internal MR 6856). * Add SPIR-V definition for "`<<spirvenv-correct-result, Correct Result>>`" and use it to not imply rounding for exact operations in the <<spirvenv-precision-core-table, Precision of core SPIR-V Instructions>> table (internal MR 6859). * Remove asciidoctor-generated footer text from spec outputs (internal MR 6860). * Require OpFDiv to respect SignedZeroInfNanPreserve in the <<spirvenv-precision-operation, Precision and Operation of SPIR-V Instructions>> section (internal MR 6862). * Add feature tags to vk.xml that were tested in CTS already but not mentioned in the specification (internal MR 6864). * Improve API code version refpages by including the automatically-generated API interface content from the version appendix of the specification that was previously omitted (internal MR 6865). * Merge common draw VUs for shader object and pipeline viewport scaling when VK_NV_clip_space_w_scaling is enabled (internal MR 6871). * Merge common draw VUs for shader object and pipeline viewport rate palette when VK_NV_shading_rate_image is enabled (internal MR 6872). * Merge common draw vertex binding VUs for shader object and pipeline patch control and update corresponding language in the shader object <<shaders-objects-state Setting State>> section (internal MR 6876). * Fix definition of the built-in variable <<interfaces-builtin-variables-viewindex, ViewIndex>> to specify it returns bit indexes, not bit values (internal MR 6877). * Add pipeline coarse sample order to shader object common draw VU 09233 when VK_NV_shading_rate_image is enabled (internal MR 6882). * Add missing XML `feature` tags for AMD vendor extensions (internal MR 6889). * Fix common draw VU interactions with dynamic rasterization samples state from VK_EXT_sample_locations (internal MR 6896). New Extensions * VK_EXT_depth_clamp_control * VK_EXT_device_generated_commands
- Loading branch information
Showing
123 changed files
with
6,151 additions
and
1,697 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,71 @@ | ||
// Copyright 2021-2024 The Khronos Group Inc. | ||
// | ||
// SPDX-License-Identifier: CC-BY-4.0 | ||
|
||
include::{generated}/meta/{refprefix}VK_EXT_depth_clamp_control.adoc[] | ||
|
||
=== Other Extension Metadata | ||
|
||
*Last Modified Date*:: | ||
2024-07-15 | ||
*Contributors*:: | ||
- Jules Blok, Independent | ||
|
||
=== Description | ||
|
||
This extension allows the application to control the viewport depth clamp | ||
range separately from the viewport pname:minDepth and pname:maxDepth. | ||
This gives the ability for the application to restrict depth values to an | ||
application-defined range rather than | ||
ifdef::VK_EXT_depth_clamp_zero_one[] | ||
the viewport depth range or the range defined in the | ||
apiext:VK_EXT_depth_clamp_zero_one extension. | ||
endif::VK_EXT_depth_clamp_zero_one[] | ||
ifndef::VK_EXT_depth_clamp_zero_one[] | ||
the viewport depth range. | ||
endif::VK_EXT_depth_clamp_zero_one[] | ||
|
||
It can be used to set a smaller or larger clamping range than the viewport | ||
depth range without affecting the depth mapping of the viewport transform. | ||
ifdef::VK_EXT_depth_clamp_zero_one[] | ||
Another possible use of this extension is to restrict depth values beyond | ||
the viewport depth range to a clamping range other than the [0, 1] range | ||
defined in the apiext:VK_EXT_depth_clamp_zero_one extension. | ||
endif::VK_EXT_depth_clamp_zero_one[] | ||
|
||
include::{generated}/interfaces/VK_EXT_depth_clamp_control.adoc[] | ||
|
||
=== Issues | ||
|
||
1) Should the depth clamp range be a per-viewport parameter? | ||
|
||
*RESOLVED*: No. | ||
Because the depth clamp range was previously defined to be equal to the | ||
viewport depth range, conformant runtimes are already handling the depth | ||
clamp range as a per-viewport parameter. | ||
However because of complexities from interactions with multiple viewports a | ||
per-viewport clamp range is left to a future extensions if a use case | ||
arises. | ||
|
||
2) Should this pipeline state be dynamic? | ||
|
||
*RESOLVED*: Yes. | ||
Since the viewport depth range can already be a dynamic state conformant | ||
runtimes are already able to handle the depth clamp range as a dynamic | ||
state. | ||
|
||
3) Can the depth clamp range be ignored when depth clamping is disabled? | ||
|
||
*RESOLVED*: Yes. | ||
This extension overrides the clamping range used only when depth clamping is | ||
enabled. | ||
The alternative would be highly unintuitive. | ||
ifdef::VK_EXT_depth_clip_enable[] | ||
As a consequence the apiext:VK_EXT_depth_clip_enable extension is required | ||
if depth clipping is desired in combination with this extension. | ||
endif::VK_EXT_depth_clip_enable[] | ||
|
||
=== Version History | ||
|
||
* Revision 1, 2024-02-13 (Jules Blok) | ||
** Initial draft |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,142 @@ | ||
// Copyright (c) 2024 Valve Corporation | ||
// | ||
// SPDX-License-Identifier: CC-BY-4.0 | ||
|
||
include::{generated}/meta/{refprefix}VK_EXT_device_generated_commands.adoc[] | ||
|
||
=== Other Extension Metadata | ||
|
||
*Last Modified Date*:: | ||
2024-02-23 | ||
*Interactions and External Dependencies*:: | ||
- This extension requires Vulkan 1.1 | ||
- This extension requires `VK_EXT_buffer_device_address` or | ||
`VK_KHR_buffer_device_address` or Vulkan 1.2 for the ability to bind | ||
vertex and index buffers on the device. | ||
- This extension requires `VK_KHR_maintenance5` for the ability to use | ||
VkPipelineCreateFlags2KHR. | ||
- This extension interacts with `VK_NV_mesh_shader`. | ||
If the latter extension is not supported, remove the command tokens to | ||
initiate NV mesh tasks drawing in this extension. | ||
- This extension interacts with `VK_EXT_mesh_shader`. | ||
If the latter extension is not supported, remove the command tokens to | ||
initiate EXT mesh tasks drawing in this extension. | ||
- This extension interacts with `VK_KHR_ray_tracing_pipeline`. | ||
If the latter extension is not supported, remove the command tokens to | ||
initiate ray tracing in this extension. | ||
- This extension interacts with `VK_EXT_shader_object`. | ||
If the latter extension is not supported, remove references to shader | ||
objects in this extension. | ||
*Contributors*:: | ||
- Mike Blumenkrantz, VALVE | ||
- Hans-Kristian Arntzen, VALVE | ||
- Jan-Harald Fredriksen, ARM | ||
- Spencer Fricke, LunarG | ||
- Ricardo Garcia, Igalia | ||
- Tobias Hector, AMD | ||
- Baldur Karlsson, VALVE | ||
- Christoph Kubisch, NVIDIA | ||
- Lionel Landwerlin, INTEL | ||
- Jon Leech, Khronos | ||
- Ting Wei, ARM | ||
- Ken Shanyi Zhang, AMD | ||
- Faith Ekstrand, Collabora | ||
- Vikram Kushwaha, NVIDIA | ||
- Connor Abbott, VALVE | ||
- Samuel Pitoiset, VALVE | ||
|
||
=== Description | ||
|
||
This extension allows the device to generate a number of commands for | ||
command buffers. | ||
It provides a subset of functionality from both | ||
`VK_NV_device_generated_commands` and | ||
`VK_NV_device_generated_commands_compute` as well as some new features. | ||
|
||
When rendering a large number of objects, the device can be leveraged to | ||
implement a number of critical functions, like updating matrices, or | ||
implementing occlusion culling, frustum culling, front to back sorting, etc. | ||
Implementing those on the device does not require any special extension, | ||
since an application is free to define its own data structures, and just | ||
process them using shaders. | ||
|
||
To render objects which have been processed on the device, Vulkan has | ||
several ways to perform indirect rendering, from the most basic | ||
`vkCmdDrawIndirect` with one indirect draw to `vkCmdDrawIndirectCount` which | ||
supports multiple indirect draws batched together, with a way to determine | ||
number of draws at device execution time. | ||
|
||
However, if rendering state needs to change between the indirect draws, then | ||
unextended Vulkan forces the application to speculatively record a | ||
prohibitive number of redundant indirect commands covering all possible | ||
state combinations - | ||
which could end up processing nothing after culling - | ||
or read back the processed stream and issue graphics command from the host. | ||
For very large scenes, the synchronization overhead and cost to generate the | ||
command buffer can become the bottleneck. | ||
This extension allows an application to generate a device side stream of | ||
state changes and commands, and convert it efficiently into a command buffer | ||
without having to read it back to the host. | ||
|
||
Furthermore, it allows incremental changes to such command buffers by | ||
manipulating only partial sections of a command stream -- for example | ||
pipeline and shader object bindings. | ||
Unextended Vulkan requires re-creation of entire command buffers in such a | ||
scenario, or updates synchronized on the host. | ||
|
||
The intended usage for this extension is for the application to: | ||
|
||
* create sname:VkBuffer objects and retrieve physical addresses from them | ||
via flink:vkGetBufferDeviceAddress | ||
* create a sname:VkIndirectExecutionSetEXT for the ability to change | ||
shaders on the device. | ||
* create a slink:VkIndirectCommandsLayoutEXT, which lists the | ||
elink:VkIndirectCommandsTokenTypeEXT it wants to dynamically execute as | ||
an atomic command sequence. | ||
This step likely involves some internal device code compilation, since | ||
the intent is for the GPU to generate the command buffer based on the | ||
layout. | ||
* fill the input stream buffers with the data for each of the inputs it | ||
needs. | ||
Each input is an array that will be filled with token-dependent data. | ||
* set up a preprocess sname:VkBuffer that uses memory according to the | ||
information retrieved via | ||
flink:vkGetGeneratedCommandsMemoryRequirementsEXT. | ||
* optionally preprocess the generated content using | ||
flink:vkCmdPreprocessGeneratedCommandsEXT, for example on an | ||
asynchronous compute queue, or for the purpose of re-using the data in | ||
multiple executions. | ||
* call flink:vkCmdExecuteGeneratedCommandsEXT to create and execute the | ||
actual device commands for all sequences based on the inputs provided. | ||
|
||
For each draw in a sequence, the following can be specified: | ||
|
||
* a number of vertex buffer bindings | ||
* a different index buffer, with an optional dynamic offset and index type | ||
* a number of different push constants | ||
* updates to bound shader stages | ||
|
||
For each dispatch in a sequence, the following can be specified: | ||
|
||
* a number of different push constants | ||
* updates to bound shader stages | ||
|
||
For each trace rays in a sequence, the following can be specified: | ||
* a number of different push constants | ||
* updates to bound shader stages | ||
|
||
While the GPU can be faster than a CPU to generate the commands, it will not | ||
happen asynchronously to the device, therefore the primary use case is | ||
generating "`less`" total work (occlusion culling, classification to use | ||
specialized shaders, etc.). | ||
|
||
include::{generated}/interfaces/VK_EXT_device_generated_commands.adoc[] | ||
|
||
=== Example Code | ||
|
||
TODO | ||
|
||
=== Version History | ||
|
||
* Revision 1, 2024-02-23 (Mike Blumenkrantz) | ||
** Initial version |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.