层与扩展（信息性）

Vulkan API 的扩展可以由作者、作者组和 Khronos Vulkan 工作组定义。为了不影响 Vulkan 规范的可读性，核心规范不包含大多数扩展。在线扩展注册表可在 URL 获取：

https://registry.khronos.org/vulkan/

并允许生成包含不同扩展的规范版本。

创建扩展和层的作者必须遵循Vulkan 文档和扩展文档中描述的强制程序。

本附录的其余部分记录了构建此文档时选择的一组扩展。注册表中发布的规范版本包括

  • 核心 API + 所有 Vulkan 实现所需的强制扩展。

  • 核心 API + 所有已注册和发布的 Khronos (KHR) 扩展。

  • 核心 API + 所有已注册和发布的扩展。

扩展按 Khronos KHR、多厂商 EXT 分组，然后按作者 ID 字母顺序排列。在每个组内，扩展按其名称的字母顺序排列。

扩展依赖

依赖于特定核心版本或其他扩展的扩展将列出此类依赖关系。

对于核心版本，必须在运行时支持指定的版本。所有扩展都隐式要求支持 Vulkan 1.0。

对于设备扩展，使用该扩展定义的任何设备级功能需要启用该扩展所依赖的任何扩展。

对于任何扩展，使用该扩展定义的任何实例级功能仅需要在运行时支持该扩展所依赖的任何扩展。

扩展交互

某些扩展定义了仅在运行时支持其他扩展或核心版本时才支持的 API。此类交互被标记为“API 交互”。

当前扩展列表

VK_KHR_acceleration_structure

名称字符串

VK_KHR_acceleration_structure

扩展类型

设备扩展

注册扩展号

151

修订

13

批准状态

已批准

扩展和版本依赖关系

         Vulkan 版本 1.1
        和
         VK_EXT_descriptor_indexing
        和
         VK_KHR_buffer_device_address
    或
     Vulkan 版本 1.2
和
VK_KHR_deferred_host_operations

API 交互

  • 与 VK_VERSION_1_2 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_EXT_debug_report 交互

  • 与 VK_KHR_format_feature_flags2 交互

联系方式

其他扩展元数据

上次修改日期

2021-09-30

贡献者

  • Samuel Bourasseau, Adobe

  • Matthäus Chajdas, AMD

  • Greg Grebe, AMD

  • Nicolai Hähnle, AMD

  • Tobias Hector, AMD

  • Dave Oldcorn, AMD

  • Skyler Saleh, AMD

  • Mathieu Robart, Arm

  • Marius Bjorge, Arm

  • Tom Olson, Arm

  • Sebastian Tafuri, EA

  • Henrik Rydgard, Embark

  • Juan Cañada, Epic Games

  • Patrick Kelly, Epic Games

  • Yuriy O’Donnell, Epic Games

  • Michael Doggett, Facebook/Oculus

  • Ricardo Garcia, Igalia

  • Andrew Garrard, Imagination

  • Don Scorgie, Imagination

  • Dae Kim, Imagination

  • Joshua Barczak, Intel

  • Slawek Grajewski, Intel

  • Jeff Bolz, NVIDIA

  • Pascal Gautron, NVIDIA

  • Daniel Koch, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Ashwin Lele, NVIDIA

  • Robert Stepinski, NVIDIA

  • Martin Stich, NVIDIA

  • Nuno Subtil, NVIDIA

  • Eric Werness, NVIDIA

  • Jon Leech, Khronos

  • Jeroen van Schijndel, OTOY

  • Juul Joosten, OTOY

  • Alex Bourd, Qualcomm

  • Roman Larionov, Qualcomm

  • David McAllister, Qualcomm

  • Lewis Gordon, Samsung

  • Ralph Potter, Samsung

  • Jasper Bekkers, Traverse Research

  • Jesse Barker, Unity

  • Baldur Karlsson, Valve

描述

为了提高效率，光线追踪等渲染技术需要一种快速方法来识别哪些图元可能与遍历几何体的光线相交。加速结构是表示空间排序几何体的最常见方法，以便快速识别此类潜在的交点。

此扩展添加了新功能

  • 加速结构对象和构建命令

  • 描述加速结构构建的几何体输入的结构

  • 加速结构复制命令

新对象类型

新命令

新结构

新联合体

新枚举

新位掩码

新枚举常量

  • VK_KHR_ACCELERATION_STRUCTURE_EXTENSION_NAME

  • VK_KHR_ACCELERATION_STRUCTURE_SPEC_VERSION

  • 扩展 VkAccessFlagBits

    • VK_ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR

    • VK_ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_KHR

  • 扩展 VkBufferUsageFlagBits

    • VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_BIT_KHR

    • VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_STORAGE_BIT_KHR

  • 扩展 VkCopyAccelerationStructureModeKHR

    • VK_COPY_ACCELERATION_STRUCTURE_MODE_DESERIALIZE_KHR

    • VK_COPY_ACCELERATION_STRUCTURE_MODE_SERIALIZE_KHR

  • 扩展 VkDescriptorType

    • VK_DESCRIPTOR_TYPE_ACCELERATION_STRUCTURE_KHR

  • 扩展 VkFormatFeatureFlagBits

    • VK_FORMAT_FEATURE_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR

  • 扩展 VkIndexType

    • VK_INDEX_TYPE_NONE_KHR

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_ACCELERATION_STRUCTURE_KHR

  • 扩展 VkPipelineStageFlagBits

    • VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR

  • 扩展 VkQueryType

    • VK_QUERY_TYPE_ACCELERATION_STRUCTURE_COMPACTED_SIZE_KHR

    • VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SERIALIZATION_SIZE_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_BUILD_GEOMETRY_INFO_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_BUILD_SIZES_INFO_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_DEVICE_ADDRESS_INFO_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_AABBS_DATA_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_INSTANCES_DATA_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_TRIANGLES_DATA_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_VERSION_INFO_KHR

    • VK_STRUCTURE_TYPE_COPY_ACCELERATION_STRUCTURE_INFO_KHR

    • VK_STRUCTURE_TYPE_COPY_ACCELERATION_STRUCTURE_TO_MEMORY_INFO_KHR

    • VK_STRUCTURE_TYPE_COPY_MEMORY_TO_ACCELERATION_STRUCTURE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_ACCELERATION_STRUCTURE_KHR

如果支持 VK_EXT_debug_report

如果支持 VK_KHR_format_feature_flags2 或 Vulkan 1.3 版本

问题

(1) 此扩展与 VK_NV_ray_tracing 有何不同？

讨论:

以下是 VK_KHR_acceleration_structure 和 VK_NV_ray_tracing 之间主要功能差异的总结

(2) 您能否更详细地比较 VK_NV_ray_tracing 和 VK_KHR_acceleration_structure 之间的异同？

讨论:

以下是对哪些命令、结构和枚举进行了别名、更改或删除的更详细的比较。

(3) 公开的临时版本（VK_KHR_ray_tracing v8）和内部临时版本（VK_KHR_ray_tracing v9）之间有哪些变化？

(4) 内部临时版本（VK_KHR_ray_tracing v9）和最终版本（VK_KHR_acceleration_structure v11）之间有哪些变化？

  • 将 VK_KHR_ray_tracing 重构为 3 个扩展，从而实现实现灵活性，并将光线查询支持与光线管道分离

  • 澄清光线跟踪的缓冲区使用标志

    • VK_BUFFER_USAGE_RAY_TRACING_BIT_NV 在 VK_NV_ray_tracing 中保持不变（在 scratch 和 instanceData 上需要）

    • 在 VK_KHR_ray_tracing_pipeline 中，将 VK_BUFFER_USAGE_SHADER_BINDING_TABLE_BIT_KHR 添加为 VK_BUFFER_USAGE_RAY_TRACING_BIT_NV 的别名，并且在着色器绑定表缓冲区上需要

    • 在 VK_KHR_acceleration_structure 中添加了 VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_BIT_KHR，用于设备构建命令引用的所有顶点、索引、变换、AABB 和实例缓冲区数据

    • VK_BUFFER_USAGE_STORAGE_BUFFER_BIT 用于 scratchData

  • 在 vkCmdBuildAccelerationStructuresIndirectKHR 中添加了最大图元计数 (ppMaxPrimitiveCounts)

  • 从 VkBuffers 分配加速结构，并添加一种模式来约束设备地址

    • 取消 VkBindAccelerationStructureMemoryInfoNV 和 vkBindAccelerationStructureMemoryNV 的别名，并移除 VkBindAccelerationStructureMemoryInfoKHR、VkAccelerationStructureMemoryRequirementsInfoKHR 和 vkGetAccelerationStructureMemoryRequirementsKHR。

    • 现在，加速结构在创建时需要一个 VkBuffer 和偏移量来指定内存位置。

    • 为这些缓冲区添加一个新的 VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_STORAGE_BIT_KHR 缓冲区用途。

    • 添加一个新的 VK_ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR 加速结构类型用于分层。

  • 将 VK_GEOMETRY_TYPE_INSTANCES_KHR 移到主枚举中，而不是通过扩展添加。

  • 使构建命令更加一致 - 现在所有命令都构建多个加速结构，并且名称使用复数形式 ( vkCmdBuildAccelerationStructuresIndirectKHR, vkCmdBuildAccelerationStructuresKHR, vkBuildAccelerationStructuresKHR )。

  • 添加与 VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT 对于加速结构的交互，包括一个新特性 (descriptorBindingAccelerationStructureUpdateAfterBind) 和 3 个新属性 (maxPerStageDescriptorAccelerationStructures、maxPerStageDescriptorUpdateAfterBindAccelerationStructures、maxDescriptorSetUpdateAfterBindAccelerationStructures)。

  • 此扩展不再是临时的。

  • 定义构建、跟踪和复制的同步要求。

  • 定义 AS 构建输入和间接构建缓冲区的同步要求。

(5) VK_ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR 的用途是什么？

已解决：它主要用于 API 分层。在 DXR 中，加速结构基本上只是一个特殊布局的缓冲区，并且在创建时您不知道它将用作顶层还是底层加速结构。因此，我们添加了一种通用加速结构类型，其类型在创建时未知，而是在构建时指定。直接为 Vulkan 编写的应用程序不应使用它。

版本历史

  • 修订版 1，2019-12-05 (Vulkan 光线追踪 TSG 成员)

    • 内部修订 (从 VK_NV_ray_tracing 分叉而来)

  • 修订版 2，2019-12-20 (Daniel Koch, Eric Werness)

    • 添加 DeviceOrHostAddress 的常量版本 (!3515)

    • 添加 VU 以澄清只有当前管道中的句柄有效 (!3518)

    • 恢复一些丢失的 VU 并添加就地更新语言 (#1902, !3522)

    • 将 VkAccelerationStructureInstanceKHR 成员从 accelerationStructure 重命名为 accelerationStructureReference，以更好地匹配其类型 (!3523)

    • 如果无法重用着色器组句柄，则允许在管道创建时出现 VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS (!3523)

    • 更新 VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS 错误代码的文档，并为 VK_KHR_deferred_host_operations 的新返回代码添加缺失的文档 (!3523)

    • 列出 VK_KHR_ray_tracing 的新查询类型 (!3523)

    • 修复 VkAccelerationStructureGeometryKHR 的 VU 语句，使其引用正确的联合成员，并更新为使用更当前的措辞 (!3523)

  • 修订版 3，2020-01-10 (Daniel Koch, Jon Leech, Christoph Kubisch)

    • 修复“instance of”和“that/which contains/defines”标记问题 (!3528)

    • 将 VK_KHR_pipeline_library 分解为独立的扩展 (!3540)

    • 解决 Vulkan-hpp 问题 (!3543)

      • 添加 VkGeometryInstanceFlagsKHR 的缺失 require

      • 取消 VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_INFO_NV 的别名，因为 KHR 结构不再等效

      • 为 vkWriteAccelerationStructuresPropertiesKHR 的 pDataSize 属性添加 len

  • 修订版 4，2020-01-23 (Daniel Koch, Eric Werness)

    • 改进 vkWriteAccelerationStructuresPropertiesKHR，添加返回值和 VU (#1947)

    • 澄清语言以允许多个 raygen 着色器 (#1959)

    • 各种编辑反馈 (!3556)

    • 添加语言以帮助处理循环自相交扇形 (#1901)

    • 将 vkCmdTraceRays{,Indirect}KHR 参数更改为指针 (!3559)

    • 添加暂存地址验证语言 (#1941, !3551)

    • 修复着色器调用范围的定义并添加层次结构信息 (#1977, !3571)

  • 修订版 5，2020-02-04 (Eric Werness, Jeff Bolz, Daniel Koch)

    • 删除残余的 accelerationStructureUUID (!3582)

    • 更新重打包指令的定义并改进内存模型交互 (#1910, #1913, !3584)

    • 修复 VkPhysicalDeviceRayTracingFeaturesKHR 的错误 sType (#1988)

    • 使用临时的 SPIR-V 功能 (#1987)

    • 如果支持 rayQuery，则需要 rayTraversalPrimitiveCulling (#1927)

    • Miss 着色器没有对象参数 (!3592)

    • 修复 XML 中缺失的必需类型 (!3592)

    • 澄清更新的匹配条件 (!3592)

    • 添加主机和设备构建应该相似的目标 (!3592)

    • 澄清 maxPrimitiveCount 限制应适用于三角形和 AABB (!3592)

    • 需要实例指针数组的对齐 (!3592)

    • 零是实例标志的有效值 (!3592)

    • 添加一些在重构中丢失的对齐 VU (!3592)

    • 建议使用 TMin epsilon 而不是剔除 (!3592)

    • 从点积而不是叉积获取角度 (!3592)

    • 澄清 AH 可以访问有效负载和属性 (!3592)

    • 匹配 DXR 的非活动图元定义行为 (!3592)

    • 对非活动使用更通用的术语而不是退化，以避免混淆 (!3592)

  • 修订版 6，2020-02-20 (Daniel Koch)

    • 修复一些悬空的 NV 引用 (#1996)

    • 将 VkCmdTraceRaysIndirectCommandKHR 重命名为 VkTraceRaysIndirectCommandKHR (!3607)

    • 更新贡献者列表 (!3611)

    • 在 VkAccelerationStructureInstanceKHR 中使用 uint64_t 而不是 VkAccelerationStructureReferenceKHR (#2004)

  • 修订版 7，2020-02-28 (Tobias Hector)

    • 删除 HitTKHR SPIR-V 内置函数 (spirv/spirv-extensions#7)

  • 修订版 8，2020-03-06 (Tobias Hector, Dae Kim, Daniel Koch, Jeff Bolz, Eric Werness)

    • 明确指出当接受新的最近交点时 Tmax 会更新 (#2020,!3536)

    • 使对最小和最大 t 值的引用保持一致 (!3644)

    • 完成在问题 (1) 和 (2) 中相对于 VK_NV_ray_tracing 枚举差异 (#1974,!3642)

    • 修复一些数学方程式中的格式错误 (!3642)

    • 将 OpReportIntersectionKHR 的 Hit Kind 操作数限制为 7 位 (spirv/spirv-extensions#8,!3646)

    • 说光线追踪“应该”是水密的 (#2008,!3631)

    • 澄清光线追踪缓冲区的内存要求 (#2005,!3649)

    • 添加可调用的大小限制 (#1997,!3652)

  • 修订版 9，2020-04-15 (Eric Werness, Daniel Koch, Tobias Hector, Joshua Barczak)

    • 在加速结构创建中添加几何标志 (!3672)

    • 添加构建暂存内存对齐 (minAccelerationStructureScratchOffsetAlignment) (#2065,!3725)

    • 修复命名并从 vkGetDeviceAccelerationStructureCompatibilityKHR 返回枚举 (#2051,!3726)

    • 需要 SPIR-V 1.4 (#2096,!3777)

    • 添加了创建时捕获/重放标志 (#2104,!3774)

    • 需要 Vulkan 1.1 (#2133,!3806)

    • 对光线追踪命令使用设备地址而不是 VkBuffer (#2074,!3815)

    • 添加与 Vulkan 1.2 和 VK_KHR_vulkan_memory_model 的交互 (#2133,!3830)

    • 使 VK_KHR_pipeline_library 成为交互而不是必需 (#2045,#2108,!3830)

    • 使 VK_KHR_deferred_host_operations 成为交互而不是必需 (#2045,!3830)

    • 删除了 maxCallableSize 并为光线管道添加了显式堆栈大小管理 (#1997,!3817,!3772,!3844)

    • 改进了 VkAccelerationStructureVersionInfoKHR 的文档 (#2135,3835)

    • 将 VkAccelerationStructureBuildOffsetInfoKHR 重命名为 VkAccelerationStructureBuildRangeInfoKHR (#2058,!3754)

    • 重新统一构建和创建之间的几何描述 (!3754)

    • 修复 ppGeometries 的歧义，添加 pGeometries (#2032,!3811)

    • 添加与 VK_EXT_robustness2 的交互，并允许对加速结构使用 nullDescriptor 支持 (#1920,!3848)

    • 为 AS 更新添加了未来可扩展性 (#2114,!3849)

    • 修复 dispatchrays 的 VU 并添加对完整网格大小的限制 (#2160,!3851)

    • 添加 shaderGroupHandleAlignment 属性 (#2180,!3875)

    • 澄清管道创建的延迟主机操作 (#2067,!3813)

    • 将加速结构构建更改为始终调整大小 (#2131,#2197,#2198,!3854,!3883,!3880)

  • 修订版 10，2020-07-03 (Mathieu Robart, Daniel Koch, Eric Werness, Tobias Hector)

    • 将规范从 VK_KHR_ray_tracing 分解为 VK_KHR_acceleration_structure (#1918,!3912)

    • 澄清光线追踪的缓冲区使用标志 (#2181,!3939)

    • 向构建间接命令添加最大图元计数 (#2233,!3944)

    • 从 VkBuffers 分配加速结构并添加约束设备地址的模式 (#2131,!3936)

    • 将 VK_GEOMETRY_TYPE_INSTANCES_KHR 移动到主枚举 (#2243,!3952)

    • 使构建命令更加一致 (#2247,!3958)

    • 添加与 UPDATE_AFTER_BIND 的交互 (#2128,!3986)

    • 更正和扩展构建命令 VUs (!4020)

    • 修复复制命令 VUs (!4018)

    • 添加了各种对齐要求 (#2229,!3943)

    • 修复 geometryCount 项目数组的有效用法 (#2198,!4010)

    • 定义允许在 RTAS 更新上更改的内容和相关的 VUs (#2177,!3961)

  • 修订版 11，2020-11-12 (Eric Werness, Josh Barczak, Daniel Koch, Tobias Hector)

    • 取消 NV 和 KHR 加速结构类型及相关命令的别名 (#2271,!4035)

    • 指定主机复制命令的对齐方式 (#2273,!4037)

    • 记录 VK_FORMAT_FEATURE_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR

    • 指定加速结构是非线性的 (#2289,!4068)

    • 为步幅、vertexFormat 和 indexType 添加几个缺失的 VUs (#2315,!4069)

    • 恢复 VkAccelerationStructureBuildGeometryInfoKHR 的 VUs (#2337,!4098)

    • 禁止主机操作的多实例内存 (#2324,!4102)

    • 允许 vkGetAccelerationStructureBuildSizesKHR 的 dstAccelerationStructure 为 null (#2330,!4111)

    • 更多构建 VU 清理 (#2138,#4130)

    • 指定 AS 序列化的主机字节序 (#2261,!4136)

    • 添加可逆变换矩阵 VU (#1710,!4140)

    • 要求 TLAS 构建的 geometryCount 为 1 (!4145)

    • 改进构建地址的有效性条件 (#4142)

    • 添加单语句 SPIR-V VUs，构建限制 VUs (!4158)

    • 记录顶点和 AABB 步幅的限制 (#2390,!4184)

    • 指定 VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR 应用于 AS 副本 (#2382,#4173)

    • 定义 AS 构建输入和间接缓冲区的同步 (#2407,!4208)

  • 修订版 12，2021-08-06 (Samuel Bourasseau)

    • 将 VK_GEOMETRY_INSTANCE_TRIANGLE_FRONT_COUNTERCLOCKWISE_BIT_KHR 重命名为 VK_GEOMETRY_INSTANCE_TRIANGLE_FLIP_FACING_BIT_KHR（保留之前的别名）。

    • 澄清描述并添加注释。

  • 修订版 13，2021-09-30 (Jon Leech)

VK_KHR_android_surface

名称字符串

VK_KHR_android_surface

扩展类型

实例扩展

注册扩展号

9

修订

6

批准状态

已批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

其他扩展元数据

上次修改日期

2016-01-14

IP 状态

没有已知的 IP 声明。

贡献者

  • Patrick Doane, Blizzard

  • Faith Ekstrand, Intel

  • Ian Elliott, LunarG

  • Courtney Goeltzenleuchter, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Antoine Labour, Google

  • Jon Leech, Khronos

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Ray Smith, ARM

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

描述

VK_KHR_android_surface 扩展是一个实例扩展。它提供了一种创建 VkSurfaceKHR 对象（由 VK_KHR_surface 扩展定义）的机制，该对象引用 Android 的原生表面类型 ANativeWindow。ANativeWindow 表示任何缓冲区队列的生产者端点，无论消费者端点如何。ANativeWindows 的常见消费者端点是系统窗口合成器、视频编码器以及通过 SurfaceTexture 导入图像的特定于应用程序的合成器。

新基本类型

  • ANativeWindow

新命令

新结构

新位掩码

新枚举常量

  • VK_KHR_ANDROID_SURFACE_EXTENSION_NAME

  • VK_KHR_ANDROID_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ANDROID_SURFACE_CREATE_INFO_KHR

问题

1) Android 是否需要一种方法来查询特定物理设备（和队列族？）与特定 Android 显示器之间的兼容性？

已解决：否。目前，在 Android 上，任何物理设备都应该能够呈现到系统合成器，并且所有队列族都必须支持必要的图像布局转换和同步操作。

版本历史

  • 修订版 1，2015-09-23 (Jesse Hall)

    • 初始草案。

  • 修订版 2，2015-10-26 (Ian Elliott)

    • 从 VK_EXT_KHR_android_surface 重命名为 VK_KHR_android_surface。

  • 修订版 3，2015-11-03 (Daniel Rakos)

    • 向表面创建函数添加了分配回调。

  • 修订版 4，2015-11-10 (Jesse Hall)

    • 删除了 VK_ERROR_INVALID_ANDROID_WINDOW_KHR。

  • 修订版 5，2015-11-28 (Daniel Rakos)

    • 更新了表面创建函数以采用 pCreateInfo 结构。

  • 修订版 6，2016-01-14 (James Jones)

    • 将 VK_ERROR_NATIVE_WINDOW_IN_USE_KHR 从 VK_KHR_android_surface 移动到 VK_KHR_surface 扩展。

VK_KHR_calibrated_timestamps

名称字符串

VK_KHR_calibrated_timestamps

扩展类型

设备扩展

注册扩展号

544

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式
扩展提案

VK_EXT_calibrated_timestamps

其他扩展元数据

上次修改日期

2023-07-12

IP 状态

没有已知的 IP 声明。

贡献者

  • Matthaeus G. Chajdas, AMD

  • Alan Harrison, AMD

  • Derrick Owens, AMD

  • Daniel Rakos, RasterGrid

  • Faith Ekstrand, Intel

  • Keith Packard, Valve

描述

此扩展提供了一个接口，用于查询从两个时间域准同时获得的校准时间戳。

新命令

新结构

新枚举

新枚举常量

  • VK_KHR_CALIBRATED_TIMESTAMPS_EXTENSION_NAME

  • VK_KHR_CALIBRATED_TIMESTAMPS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_CALIBRATED_TIMESTAMP_INFO_KHR

版本历史

  • 修订版 1，2023-07-12 (Daniel Rakos)

    • 初始草案。

VK_KHR_compute_shader_derivatives

名称字符串

VK_KHR_compute_shader_derivatives

扩展类型

设备扩展

注册扩展号

512

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2

SPIR-V 依赖项
联系方式
扩展提案

VK_KHR_compute_shader_derivatives

其他扩展元数据

上次修改日期

2024-06-26

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Jean-Noe Morissette, Epic Games

  • Daniel Koch, NVIDIA

  • Pat Brown, NVIDIA

  • Stu Smith, AMD

  • Jan-Harald Fredriksen, Arm

  • Tobias Hector, AMD

  • Ralph Potter, Samsung

  • Pan Gao, Huawei

  • Samuel (Sheng-Wen) Huang, MediaTek

  • Graeme Leese, Broadcom

  • Hans-Kristian Arntzen, Valve

  • Matthew Netsh, Qualcomm

描述

此扩展为 SPV_KHR_compute_shader_derivatives SPIR-V 扩展添加了 Vulkan 支持。

SPIR-V 扩展提供了两种新的执行模式，这两种模式都允许具有定义的工作组的执行模型使用显式或隐式评估导数的内置函数。导数将通过着色器调用的 2x2 组的差分来计算。DerivativeGroupQuadsKHR 执行模式将着色器调用组合成 2x2 组，其中每组的局部调用 ID 的 x 和 y 坐标形式为 (2m+{0,1}, 2n+{0,1})。DerivativeGroupLinearKHR 执行模式将着色器调用组合成 2x2 组，其中每组的局部调用索引值的形式为 4m+{0,1,2,3}。

新的执行模式在计算着色器中受支持，并且可以选择（请参阅 meshAndTaskShaderDerivatives）在网格和任务着色器中受支持。

新结构

新枚举常量

  • VK_KHR_COMPUTE_SHADER_DERIVATIVES_EXTENSION_NAME

  • VK_KHR_COMPUTE_SHADER_DERIVATIVES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_SHADER_DERIVATIVES_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_SHADER_DERIVATIVES_PROPERTIES_KHR

新 SPIR-V 功能

示例

无。

版本历史

  • 修订版 1，2023-02-27 (Jean-Noe Morissette)

    • 初始草案

    • 添加属性并澄清网格和任务支持 (Daniel Koch)

VK_KHR_cooperative_matrix

名称字符串

VK_KHR_cooperative_matrix

扩展类型

设备扩展

注册扩展号

507

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式
扩展提案

VK_KHR_cooperative_matrix

其他扩展元数据

上次修改日期

2023-05-03

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

  • Markus Tavenrath, NVIDIA

  • Daniel Koch, NVIDIA

  • Kevin Petit, Arm Ltd.

  • Boris Zanin, AMD

描述

此扩展添加了对在 SPIR-V 中使用协同矩阵类型的支持。协同矩阵类型是中等大小的矩阵，主要在计算着色器中支持，其中矩阵的存储分布在某个范围（通常是子组）内的所有调用中，并且这些调用协同工作以有效地执行矩阵乘法。

协同矩阵类型由 SPV_KHR_cooperative_matrix SPIR-V 扩展定义，并且可以与 GLSL_KHR_cooperative_matrix GLSL 扩展一起使用。

此扩展包括对枚举实现支持的矩阵类型和维度的支持。

新命令

新结构

新枚举

新枚举常量

  • VK_KHR_COOPERATIVE_MATRIX_EXTENSION_NAME

  • VK_KHR_COOPERATIVE_MATRIX_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_COOPERATIVE_MATRIX_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_PROPERTIES_KHR

新 SPIR-V 功能

问题

版本历史

  • 修订版 2，2023-05-03 (Kevin Petit)

    • 第一个 KHR 修订版

  • 修订版 1，2019-02-05 (Jeff Bolz)

    • NVIDIA 供应商扩展

VK_KHR_deferred_host_operations

名称字符串

VK_KHR_deferred_host_operations

扩展类型

设备扩展

注册扩展号

269

修订

4

批准状态

已批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2020-11-12

IP 状态

没有已知的 IP 声明。

贡献者

  • Joshua Barczak, Intel

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

  • Slawek Grajewski, Intel

  • Tobias Hector, AMD

  • Yuriy O’Donnell, Epic

  • Eric Werness, NVIDIA

  • Baldur Karlsson, Valve

  • Jesse Barker, Unity

  • VK_KHR_acceleration_structure，VK_KHR_ray_tracing_pipeline 的贡献者

描述

VK_KHR_deferred_host_operations 扩展定义了可延迟命令的基础设施和使用模式，但没有将任何命令指定为可延迟的。这留给其他依赖扩展。除非依赖于 VK_KHR_deferred_host_operations 的另一个扩展明确允许延迟，否则**不得**延迟命令。

新对象类型

新命令

新枚举常量

  • VK_KHR_DEFERRED_HOST_OPERATIONS_EXTENSION_NAME

  • VK_KHR_DEFERRED_HOST_OPERATIONS_SPEC_VERSION

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_DEFERRED_OPERATION_KHR

  • 扩展 VkResult

    • VK_OPERATION_DEFERRED_KHR

    • VK_OPERATION_NOT_DEFERRED_KHR

    • VK_THREAD_DONE_KHR

    • VK_THREAD_IDLE_KHR

代码示例

以下示例将使用假设的示例说明可延迟操作的概念。命令 vkDoSomethingExpensive 表示可延迟命令。

以下示例说明了 vulkan 应用程序如何请求延迟昂贵的操作

// create a deferred operation
VkDeferredOperationKHR hOp;
VkResult result = vkCreateDeferredOperationKHR(device, pCallbacks, &hOp);
assert(result == VK_SUCCESS);

result = vkDoSomethingExpensive(device, hOp, ...);
assert( result == VK_OPERATION_DEFERRED_KHR );

// operation was deferred.  Execute it asynchronously
std::async::launch(
    [ hOp ] ( )
    {
        vkDeferredOperationJoinKHR(device, hOp);

        result = vkGetDeferredOperationResultKHR(device, hOp);

        // deferred operation is now complete.  'result' indicates success or failure

        vkDestroyDeferredOperationKHR(device, hOp, pCallbacks);
    }
);

以下示例说明了如何从单个延迟操作中提取并发性

// create a deferred operation
VkDeferredOperationKHR hOp;
VkResult result = vkCreateDeferredOperationKHR(device, pCallbacks, &hOp);
assert(result == VK_SUCCESS);

result = vkDoSomethingExpensive(device, hOp, ...);
assert( result == VK_OPERATION_DEFERRED_KHR );

// Query the maximum amount of concurrency and clamp to the desired maximum
uint32_t numLaunches = std::min(vkGetDeferredOperationMaxConcurrencyKHR(device, hOp), maxThreads);

std::vector<std::future<void> > joins;

for (uint32_t i = 0; i < numLaunches; i++) {
  joins.emplace_back(std::async::launch(
    [ hOp ] ( )
    {
        vkDeferredOperationJoinKHR(device, hOp);
                // in a job system, a return of VK_THREAD_IDLE_KHR should queue another
                // job, but it is not functionally required
    }
  ));
}

for (auto &f : joins) {
  f.get();
}

result = vkGetDeferredOperationResultKHR(device, hOp);

// deferred operation is now complete.  'result' indicates success or failure

vkDestroyDeferredOperationKHR(device, hOp, pCallbacks);

以下示例展示了一个子程序，该子程序在存在多个工作线程的情况下，保证延迟操作的完成，并返回操作的结果。

VkResult FinishDeferredOperation(VkDeferredOperationKHR hOp)
{
    // Attempt to join the operation until the implementation indicates that we should stop

    VkResult result = vkDeferredOperationJoinKHR(device, hOp);
    while( result == VK_THREAD_IDLE_KHR )
    {
        std::this_thread::yield();
        result = vkDeferredOperationJoinKHR(device, hOp);
    }

    switch( result )
    {
    case VK_SUCCESS:
        {
            // deferred operation has finished.  Query its result.
            result = vkGetDeferredOperationResultKHR(device, hOp);
        }
        break;

    case VK_THREAD_DONE_KHR:
        {
            // deferred operation is being wrapped up by another thread
            //  wait for that thread to finish
            do
            {
                std::this_thread::yield();
                result = vkGetDeferredOperationResultKHR(device, hOp);
            } while( result == VK_NOT_READY );
        }
        break;

    default:
        assert(false); // other conditions are illegal.
        break;
    }

    return result;
}

问题

  1. 此扩展是否应该具有 VkPhysicalDevice*FeaturesKHR 结构？

已解决：否。此扩展本身不添加任何功能，并且需要依赖扩展才能实际启用功能，因此添加功能结构没有价值。如有必要，任何依赖扩展都可以添加一个功能布尔值，以指示它正在添加可选的延迟支持。

版本历史

  • 修订版 1，2019-12-05 (Josh Barczak, Daniel Koch)

    • 初始草案。

  • 修订版 2，2020-03-06 (Daniel Koch, Tobias Hector)

    • 添加缺失的 VK_OBJECT_TYPE_DEFERRED_OPERATION_KHR 枚举

    • 修复示例代码

    • 澄清了延迟操作参数的生命周期 (#2018,!3647)

  • 修订版 3，2020-05-15 (Josh Barczak)

    • 澄清 vkGetDeferredOperationMaxConcurrencyKHR 的行为，允许在操作完成时返回 0 (#2036,!3850)

  • 修订版 4，2020-11-12 (Tobias Hector, Daniel Koch)

    • 删除 VkDeferredOperationInfoKHR，并更改使用延迟主机操作时的返回值语义 (#2067,3813)

    • 澄清 vkGetDeferredOperationResultKHR 的返回值 (#2339,!4110)

VK_KHR_depth_clamp_zero_one

名称字符串

VK_KHR_depth_clamp_zero_one

扩展类型

设备扩展

注册扩展号

605

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2024-09-10

贡献者

  • Graeme Leese, Broadcom

描述

此扩展基于 VK_EXT_depth_clamp_zero_one 扩展。此扩展为最终超出常规 [0, 1] 范围的片段深度值提供了明确的行为。它可用于确保在深度偏移等功能的边缘情况下的可移植性。选择的特定行为与 OpenGL 匹配，以帮助移植或模拟。

新结构

新枚举常量

  • VK_KHR_DEPTH_CLAMP_ZERO_ONE_EXTENSION_NAME

  • VK_KHR_DEPTH_CLAMP_ZERO_ONE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLAMP_ZERO_ONE_FEATURES_KHR

版本历史

  • 修订版 1，2024-09-10 (Graeme Leese)

    • 内部修订

VK_KHR_display

名称字符串

VK_KHR_display

扩展类型

实例扩展

注册扩展号

3

修订

23

批准状态

已批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

其他扩展元数据

上次修改日期

2017-03-13

IP 状态

没有已知的 IP 声明。

贡献者

  • James Jones, NVIDIA

  • Norbert Nopper, Freescale

  • Jeff Vigil, Qualcomm

  • Daniel Rakos, AMD

描述

此扩展提供了枚举给定设备上的显示器和可用模式的 API。

新对象类型

新命令

新结构

新枚举

新位掩码

新枚举常量

  • VK_KHR_DISPLAY_EXTENSION_NAME

  • VK_KHR_DISPLAY_SPEC_VERSION

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_DISPLAY_KHR

    • VK_OBJECT_TYPE_DISPLAY_MODE_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DISPLAY_MODE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_SURFACE_CREATE_INFO_KHR

问题

1) 模式的哪些属性应在模式信息中固定，而不是在设置模式时在其他函数中设置？例如，我们是否需要将模式池的大小加倍，以包括立体和非立体模式？YUV 和 RGB 扫描输出，即使它们都采用 RGB 输入图像？BGR 与 RGB 输入？等等。

已解决：许多现代显示器原生最多支持少数几种分辨率和时序。其他“模式”预计将使用显示引擎或 GPU 上的缩放硬件来支持。其他属性，例如旋转和镜像，不应仅为了表达所有组合而需要复制硬件模式。此外，这些属性可以在每个显示器或每个覆盖层的粒度上实现。

为了避免像 EGLConfig/WGL 像素格式/GLXFBConfig 那样随着可变属性的添加而导致的模式指数级增长，此规范应将硬件属性和可配置状态分离为单独的对象。模式和覆盖层平面将表达硬件的功能，而单独的结构将允许应用程序为给定的交换链配置缩放、旋转、镜像、颜色键、LUT 值、Alpha 掩码等，而与所使用的模式无关。这些设置的约束将由不可变对象的属性建立。

请注意，此问题的解决方法也可能会影响问题 5。

2) 显示器本身的哪些属性是有用的？

已解决：此问题过于宽泛。它旨在引发一般性讨论，但解决此问题相当于完成此规范。应包括所有有趣的属性。该问题将保留为占位符，因为删除它将使解析按编号引用问题的现有讨论记录变得困难。

3) 如何枚举显示器或模式中的多个覆盖层平面？

已解决：它们通过索引引用。每个显示器将报告其包含的覆盖层平面的数量。

4) 交换链应相对于模式还是显示器创建？

已解决：当使用此扩展时，交换链是相对于模式和平面创建的。该模式暗示交换链将呈现到的显示对象。如果指定的模式不是显示器的当前模式，则当第一张图像呈现给交换链时，将应用新模式，并且当交换链被销毁时，将恢复默认的操作系统模式（如果有）。

5) 用户是否应该从显示器查询通用范围，并使用这些约束显式构造自己的模式，而不是查询一组固定的模式（如今，大多数显示器只有一个真正的“模式”，即使许多显示器支持相对任意的缩放，无论是在显示器侧还是在 GPU 显示引擎中，这使得“模式”有点像是遗留物/兼容性结构）。

已解决：同时公开两者。显示信息结构将公开一组预定义的模式，以及构造自定义模式所需的任何属性。

6) 如果我们在用于查询其属性的结构中返回显示器和显示模式句柄，这是否可以？

已解决：可以。

7) 设备的并非所有显示器都与设备的所有呈现队列一起工作是否有可能？如果是，我们如何确定哪些显示器与哪些呈现队列一起工作？

已解决：没有已知的硬件存在此类限制，但是使用现有的 VK_KHR_surface 和 VK_KHR_swapchain 查询机制可以自动支持确定此类限制。

8) 所有呈现都需要相对于一个覆盖层平面进行，还是可以单独使用显示模式+显示器来定位输出？

已解决：需要显式指定一个平面。

9) 显示器是否应具有关联的窗口系统显示，例如 HDC 或 Display*？

已解决：否。显示器独立于系统上使用的任何窗口系统。此外，HDC 和 Display* 都不指代物理显示对象。

10) 显示器是从物理 GPU 查询还是从设备实例查询？

已解决：开发人员更喜欢直接从物理 GPU 查询模式，以便在创建设备之前将显示信息用作设备选择算法的输入。这避免了创建占位符设备实例来枚举显示器的需要。

在支持此用法之前，驱动程序供应商必须执行额外的初始化，才能实现此偏好，必须权衡这一偏好。

11) 显示器和/或模式是否应为可调度对象？如果函数要将显示器、覆盖层或模式作为其第一个参数，则它们必须是 Khronos 错误 13529 中定义的可调度对象。如果它们未添加到可调度对象列表中，则对它们进行操作的函数必须将某个更高级别的对象作为其第一个参数。没有任何性能案例反对将它们设为可调度对象，但它们将是第一个可调度的扩展对象。

已解决：不要将显示器或模式设为可调度的。它们将基于其关联的物理设备进行调度。

12) 是否应公开硬件光标功能？

已解决：推迟。这可能是基于基本 WSI 规范的单独扩展。

13) 对于“平铺”显示设备，应枚举多少个显示对象？较低级别的显示 API 作者正在进行关于如何暴露显示器的设计讨论，如果它们对于最终用户来说是一个物理显示设备，但在内部可能会使用与两个物理独立的显示设备相同的显示引擎（有时使用相同的布线）资源实现为两个并排显示器。

已解决：平铺显示将在本 API 中显示为单个显示对象。

14) 原始 EDID 数据是否应包含在显示信息中？

已解决：否。如果需要，可以添加未来的扩展来报告 EDID。问题 13 的结果可能会使这变得复杂。

15) 是否应公开覆盖层的最小和最大缩放因子功能？

已解决：是。当使用特定的模式和覆盖层对时，允许应用程序查询显示引擎从中获取图像内容的源区域和目标区域的最小/最大位置和范围，从而间接公开此功能。

16) 设备是否应该能够暴露可以在显示器之间移动的平面？如果是，如何实现？

已解决：是。应用程序可以使用 vkGetDisplayPlaneSupportedDisplaysKHR 确定给定平面支持哪些显示器。

17) 是否应该有一种方法可以销毁显示模式？如果是，它是否支持销毁“内置”模式？

已解决：在此扩展中不实现。未来的扩展可以添加此功能。

18) 显示器和内置显示模式对象的生命周期应该是什么？

已解决：实例的生命周期。这些对象无法销毁。可能会添加未来的扩展以公开一种销毁这些对象和/或支持显示器热插拔的方法。

19) 对于智能面板，应在交换链创建时还是在每次呈现时启用/禁用持久模式？

已解决：在每次呈现时。

示例

VK_KHR_display 和 VK_KHR_display_swapchain 扩展的示例代码在修订版 1.0.43 之后已从附录中删除。显示器枚举示例代码已移植到官方 Khronos SDK 附带的 cube 演示中，并在该位置保持最新（请参阅：https://github.com/KhronosGroup/Vulkan-Tools/blob/main/cube/cube.c）。

版本历史

  • 修订版 1，2015-02-24 (James Jones)

    • 初始草案

  • 修订版 2，2015-03-12 (Norbert Nopper)

    • 为显示器添加了覆盖层枚举。

  • 修订版 3，2015-03-17 (Norbert Nopper)

    • 修复了 Bugzilla 中讨论的拼写错误和命名。

    • 重新排序并分组了函数。

    • 添加了用于查询显示器、模式和覆盖层数量的函数。

    • 添加了本机显示句柄，某些平台上可能需要此句柄来创建本机窗口。

  • 修订版 4，2015-03-18 (Norbert Nopper)

    • 删除了 primary 和 virtualPostion 成员（请参阅 Bugzilla 中 James Jones 的评论）。

    • 向信息结构添加了本机覆盖层句柄。

    • 在结构中用 ; 替换了 ,。

  • 修订版 6，2015-03-18 (Daniel Rakos)

    • 向所有项添加了 WSI 扩展后缀。

    • 使整个 API 更“Vulkan 化”。

    • 用单个 vkGetDisplayInfoKHR 函数替换了所有函数，以更好地匹配 API 的其余部分。

    • 使显示器、显示模式和覆盖层对象成为一等对象，而不是 VkBaseObject 的子类，因为它们无论如何都不支持通用函数。

    • 将 *Info 结构重命名为 *Properties。

    • 从 VkOverlayProperties 中删除了 overlayIndex 字段，因为作为移动到“Vulkan 化”API 的结果，已经存在隐式索引。

    • 显示器不是通过设备获取，而是通过物理 GPU 获取，以匹配 Vulkan API 的其余部分。这也是 ISV 明确要求的。

    • 添加了问题 (6) 和 (7)。

  • 修订版 7，2015-03-25 (James Jones)

    • 添加了问题部分

    • 添加了旋转和镜像标志

  • 修订版 8，2015-03-25 (James Jones)

    • 合并了上次更改中引入的重复问题部分。

    • 为几个问题添加了拟议的解决方案。

  • 修订版 9，2015-04-01 (Daniel Rakos)

    • 针对 Vulkan 0.82.0 重新调整了扩展

  • 修订版 10，2015-04-01 (James Jones)

    • 添加了问题 (10) 和 (11)。

    • 添加了更多暂定问题解决方案，并清理了问题 (4) 的拟议解决方案。

    • 更新了旋转和镜像枚举以具有正确的位掩码语义。

  • 修订版 11，2015-04-15 (James Jones)

    • 为问题 (1) 和 (2) 添加了拟议的解决方案。

    • 添加了问题 (12)、(13)、(14) 和 (15)

    • 从覆盖层结构中删除了 pNativeHandle 字段。

    • 修复了示例代码中的小型编译错误。

  • 修订版 12，2015-07-29 (James Jones)

    • 针对最新的 WSI 交换链规范和最新的 Vulkan API 重写了扩展的内部结构。

    • 通过索引而不是对象句柄来寻址覆盖层平面，并将它们称为“平面”而不是“覆盖层”，以便更清楚地表明即使没有“覆盖层”的显示器仍然至少有一个可以显示图像的基本“平面”。

    • 更新了大多数问题。

    • 向规范标头添加了“扩展类型”部分。

    • 重用了 VK_EXT_KHR_surface 表面转换枚举，而不是在此处重新定义它们。

    • 更新了示例代码以使用新的语义。

  • 修订版 13，2015-08-21 (Ian Elliott)

    • 重命名了此扩展及其所有枚举、类型、函数等。这使其符合拟议的 Vulkan 扩展标准。

    • 从“修订版”切换到“版本”，包括在头文件中使用 VK_MAKE_VERSION 宏。

  • 修订版 14，2015-09-01 (James Jones)

    • 恢复了单字段修订号。

  • 修订版 15，2015-09-08 (James Jones)

    • 添加了 alpha 标志枚举。

    • 添加了预乘 alpha 支持。

  • 修订版 16，2015-09-08 (James Jones)

    • 向规范添加了描述部分。

    • 添加了问题 16 - 18。

  • 修订版 17，2015-10-02 (James Jones)

    • 平面现在是整个设备的属性，而不是单个显示器的属性。这允许在支持的设备上在多个显示器之间移动平面。

    • 添加了一个函数来创建描述显示平面和模式的 VkSurfaceKHR 对象，以符合新的每平台表面创建约定。

    • 移除了详细的模式时序数据。大家一致认为，模式范围和刷新率足以满足当前的用例。如果将来需要，其他信息可以作为扩展添加回来。

    • 增加了对智能/持久/缓冲显示设备的支持。

  • 修订版 18，2015-10-26 (Ian Elliott)

    • 从 VK_EXT_KHR_display 重命名为 VK_KHR_display。

  • 修订版 19，2015-11-02 (James Jones)

    • 更新了示例代码以匹配修订版 17 的更改。

  • 修订版 20，2015-11-03 (Daniel Rakos)

    • 向创建函数添加了分配回调。

  • 修订版 21，2015-11-10 (Jesse Hall)

    • 添加了 VK_DISPLAY_PLANE_ALPHA_OPAQUE_BIT_KHR，并为 VkDisplayPlanePropertiesKHR::alphaMode 使用 VkDisplayPlaneAlphaFlagBitsKHR，而不是 VkDisplayPlaneAlphaFlagsKHR，因为它只表示一种模式。

    • 向 VkDisplayPlanePropertiesKHR 添加了保留的标志位掩码。

    • 使用 VkSurfaceTransformFlagBitsKHR 代替已过时的 VkSurfaceTransformKHR。

    • 为了清晰起见，重命名了 vkGetDisplayPlaneSupportedDisplaysKHR 参数。

  • 修订版 22，2015-12-18 (James Jones)

    • 在 vkGetDisplayPlaneSupportedDisplaysKHR() 中添加了缺少的 “planeIndex” 参数

  • 修订版 23，2017-03-13 (James Jones)

    • 关闭了所有剩余的问题。规范和实现已经按照提议的解决方案发布了一段时间。

    • 移除了示例代码，并指出它已集成到官方 Vulkan SDK cube 演示中。

VK_KHR_display_swapchain

名称字符串

VK_KHR_display_swapchain

扩展类型

设备扩展

注册扩展号

4

修订

10

批准状态

已批准

扩展和版本依赖关系

VK_KHR_swapchain
和
VK_KHR_display

联系方式

其他扩展元数据

上次修改日期

2017-03-13

IP 状态

没有已知的 IP 声明。

贡献者

  • James Jones, NVIDIA

  • Jeff Vigil, Qualcomm

  • Jesse Hall, Google

描述

此扩展提供了一个 API，可以直接在设备的显示屏上创建交换链，而无需任何底层窗口系统。

新命令

新结构

新枚举常量

  • VK_KHR_DISPLAY_SWAPCHAIN_EXTENSION_NAME

  • VK_KHR_DISPLAY_SWAPCHAIN_SPEC_VERSION

  • 扩展 VkResult

    • VK_ERROR_INCOMPATIBLE_DISPLAY_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DISPLAY_PRESENT_INFO_KHR

问题

1) 共享图像的交换链是否应该各自持有对图像的引用，还是应该由应用程序以避免引用计数的顺序销毁交换链和图像？

已解决：获取引用。可呈现图像的生命周期已经足够复杂了。

2) srcRect 和 dstRect 参数应该作为呈现命令的一部分指定，还是在交换链创建时指定？

已解决：作为呈现命令的一部分。这样可以在屏幕上移动和缩放图像，而无需重新指定模式或创建新的交换链和可呈现图像。

3) srcRect 和 dstRect 应该指定为矩形，还是单独的偏移量/范围值？

已解决：作为矩形。单独指定它们可能使硬件更容易公开对一个而不是另一个的支持，但在这种情况下，应用程序必须注意遵守报告的功能，并且不使用需要缩放的非零偏移量或范围（视情况而定）。

4) 应用程序如何创建使用相同图像的多个交换链？

已解决：通过调用 vkCreateSharedSwapchainsKHR。

早期的一个解决方案是使用 vkCreateSwapchainKHR，通过 pNext 链接多个 VkSwapchainCreateInfoKHR 结构。为了允许每个交换链也允许其他扩展结构，使用了一个间接层：VkSwapchainCreateInfoKHR::pNext 指向一个不同的结构，该结构同时具有 sType 和 pNext 成员用于其他扩展，并且还具有指向下一个 VkSwapchainCreateInfoKHR 结构的指针。要创建的交换链的数量只能通过遍历这个交替结构的链表找到，并且 pSwapchains 输出参数被重新解释为 VkSwapchainKHR 句柄的数组。

另一个考虑的选择是在创建新交换链时指定一个“共享”交换链的方法，这样就可以一次构建使用相同图像的交换链组。这被认为不可用，因为驱动程序需要知道图像将用于哪些显示器，以便确定该图像使用的内部格式和布局。

示例

在修订版 1.0.43 之后，从附录中删除了 VK_KHR_display 和 VK_KHR_display_swapchain 扩展的示例代码。显示交换链创建示例代码已移植到官方 Khronos SDK 附带的 cube 演示中，并在该位置保持最新（请参阅：https://github.com/KhronosGroup/Vulkan-Tools/blob/main/cube/cube.c）。

版本历史

  • 修订版 1，2015-07-29 (James Jones)

    • 初始草案

  • 修订版 2，2015-08-21 (Ian Elliott)

    • 重命名了此扩展及其所有枚举、类型、函数等。这使其符合拟议的 Vulkan 扩展标准。

    • 从“修订版”切换到“版本”，包括在头文件中使用 VK_MAKE_VERSION 宏。

  • 修订版 3，2015-09-01 (James Jones)

    • 恢复了单字段修订号。

  • 修订版 4，2015-09-08 (James Jones)

    • 允许使用对 vkCreateSwapchainKHR() 的单个调用创建共享相同图像的多个交换链。

  • 修订版 5，2015-09-10 (Alon Or-bach)

    • 从两个枚举中删除了 SWAP_CHAIN 中的下划线。

  • 修订版 6，2015-10-02 (James Jones)

    • 添加了对智能面板/缓冲显示器的支持。

  • 修订版 7，2015-10-26 (Ian Elliott)

    • 从 VK_EXT_KHR_display_swapchain 重命名为 VK_KHR_display_swapchain。

  • 修订版 8，2015-11-03 (Daniel Rakos)

    • 根据对 VK_KHR_swapchain 的更改更新了示例代码。

  • 修订版 9，2015-11-10 (Jesse Hall)

    • 用 vkCreateSharedSwapchainsKHR 替换了 VkDisplaySwapchainCreateInfoKHR，更改了问题 #4 的解决方案。

  • 修订版 10，2017-03-13 (James Jones)

    • 关闭了所有剩余的问题。规范和实现已经按照提议的解决方案发布了一段时间。

    • 移除了示例代码，并指出它已集成到官方 Vulkan SDK cube 演示中。

VK_KHR_external_fence_fd

名称字符串

VK_KHR_external_fence_fd

扩展类型

设备扩展

注册扩展号

116

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_fence
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2017-05-08

IP 状态

没有已知的 IP 声明。

贡献者

描述

使用外部内存的应用程序可能希望使用栅栏来同步对该内存的访问。此扩展使应用程序能够将栅栏有效负载导出到 POSIX 文件描述符并从中导入栅栏有效负载。

新命令

新结构体

新枚举常量

  • VK_KHR_EXTERNAL_FENCE_FD_EXTENSION_NAME

  • VK_KHR_EXTERNAL_FENCE_FD_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_FENCE_GET_FD_INFO_KHR

    • VK_STRUCTURE_TYPE_IMPORT_FENCE_FD_INFO_KHR

问题

此扩展借鉴了 VK_KHR_external_semaphore_fd 的概念、语义和语言。该扩展的问题同样适用于此扩展。

版本历史

  • 修订版 1，2017-05-08 (Jesse Hall)

    • 初始修订版

VK_KHR_external_fence_win32

名称字符串

VK_KHR_external_fence_win32

扩展类型

设备扩展

注册扩展号

115

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_fence

联系方式

其他扩展元数据

上次修改日期

2017-05-08

IP 状态

没有已知的 IP 声明。

贡献者

描述

使用外部内存的应用程序可能希望使用围栏来同步对该内存的访问。此扩展使应用程序能够将围栏有效负载导出到 Windows 句柄，并从 Windows 句柄导入围栏有效负载。

新命令

新结构体

新枚举常量

  • VK_KHR_EXTERNAL_FENCE_WIN32_EXTENSION_NAME

  • VK_KHR_EXTERNAL_FENCE_WIN32_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXPORT_FENCE_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_FENCE_GET_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_IMPORT_FENCE_WIN32_HANDLE_INFO_KHR

问题

此扩展借鉴了 VK_KHR_external_semaphore_win32 的概念、语义和语言。该扩展的问题同样适用于此扩展。

1) 是否应该像信号量一样支持 D3D12 围栏句柄类型？

已解决：否。这样做需要扩展围栏信号和等待操作，以提供信号/等待的值，就像 VkD3D12FenceSubmitInfoKHR 所做的那样。可以通过将其导入到 VkSemaphore 而不是 VkFence 来发出 D3D12 围栏的信号，并且应用程序可以使用非 Vulkan API 检查状态或等待 D3D12 围栏。能够在 VkFence 对象上执行这些操作的便利性并不能证明额外的 API 复杂性是合理的。

版本历史

  • 修订版 1，2017-05-08 (Jesse Hall)

    • 初始修订版

VK_KHR_external_memory_fd

名称字符串

VK_KHR_external_memory_fd

扩展类型

设备扩展

注册扩展号

75

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_memory
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2016-10-21

IP 状态

没有已知的 IP 声明。

贡献者

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

描述

应用程序可能希望在多个 Vulkan 逻辑设备或实例、多个进程和/或多个 API 中引用设备内存。此扩展使应用程序能够从 Vulkan 内存对象导出 POSIX 文件描述符句柄，并从其他 Vulkan 内存对象或来自其他 API 中类似资源导出的 POSIX 文件描述符句柄导入 Vulkan 内存对象。

新命令

新结构体

新枚举常量

  • VK_KHR_EXTERNAL_MEMORY_FD_EXTENSION_NAME

  • VK_KHR_EXTERNAL_MEMORY_FD_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMPORT_MEMORY_FD_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_FD_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_MEMORY_GET_FD_INFO_KHR

问题

1) 应用程序是否需要关闭 vkGetMemoryFdKHR 返回的文件描述符？

已解决：是，除非将其传回驱动程序实例以导入内存。成功的 get 调用将文件描述符的所有权转移给应用程序，而成功的导入将其转移回驱动程序。销毁原始内存对象不会关闭文件描述符或删除其对与之关联的底层内存资源的引用。

2) 驱动程序是否需要为每个内存对象公开多个文件描述符？

已解决：否。这将表明实际上有多个内存对象，而不是单个内存对象。

3) 如何指定在 Vulkan 之外创建的 POSIX 文件描述符内存句柄的有效大小和内存类型？

已解决：有效的内存类型直接从外部句柄查询。大小将由未来引入此类外部内存句柄类型的扩展指定。

版本历史

  • 修订版 1，2016-10-21 (James Jones)

    • 初始修订版

VK_KHR_external_memory_win32

名称字符串

VK_KHR_external_memory_win32

扩展类型

设备扩展

注册扩展号

74

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_memory
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2016-10-21

IP 状态

没有已知的 IP 声明。

贡献者

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Carsten Rohde, NVIDIA

描述

应用程序可能希望在多个 Vulkan 逻辑设备或实例、多个进程和/或多个 API 中引用设备内存。此扩展使应用程序能够从 Vulkan 内存对象导出 Windows 句柄，并从其他 Vulkan 内存对象或来自其他 API 中类似资源导出的 Windows 句柄导入 Vulkan 内存对象。

新命令

新结构体

新枚举常量

  • VK_KHR_EXTERNAL_MEMORY_WIN32_EXTENSION_NAME

  • VK_KHR_EXTERNAL_MEMORY_WIN32_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_GET_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_WIN32_HANDLE_PROPERTIES_KHR

问题

1) 当 handleType 为 VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR 时，应用程序是否需要在从 vkGetMemoryWin32HandleKHR 返回的值上调用 CloseHandle()？

已解决：是。成功的 get 调用将句柄的所有权转移给应用程序。销毁内存对象不会销毁句柄或句柄对底层内存资源的引用。与文件描述符不透明句柄不同，win32 不透明句柄的所有权不能通过导入操作转移回驱动程序。

2) 关于 KMT/Windows 7 句柄的语言是否应该移到单独的扩展中，以便可以随着时间的推移将其弃用？

已解决：可以由驱动程序自行决定是否弃用对它们的支持，方法是在实例级别的查询中不再返回它们作为支持的句柄类型。

3) 对于在 Vulkan 外部创建的 Windows 内存句柄，应该如何指定其有效大小和内存类型？

已解决：有效的内存类型直接从外部句柄查询。大小由需要专用分配的外部句柄类型关联的图像或缓冲区内存需求确定，对于其他外部句柄类型，则由导出句柄的对象创建时指定的大小确定。

版本历史

  • 修订版 1，2016-10-21 (James Jones)

    • 初始修订版

VK_KHR_external_semaphore_fd

名称字符串

VK_KHR_external_semaphore_fd

扩展类型

设备扩展

注册扩展号

80

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_semaphore
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2016-10-21

IP 状态

没有已知的 IP 声明。

贡献者

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Carsten Rohde, NVIDIA

描述

使用外部内存的应用程序可能希望使用信号量同步对该内存的访问。此扩展使应用程序能够将信号量有效负载导出到 POSIX 文件描述符，并从 POSIX 文件描述符导入信号量有效负载。

新命令

新结构体

新枚举常量

  • VK_KHR_EXTERNAL_SEMAPHORE_FD_EXTENSION_NAME

  • VK_KHR_EXTERNAL_SEMAPHORE_FD_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_FD_INFO_KHR

    • VK_STRUCTURE_TYPE_SEMAPHORE_GET_FD_INFO_KHR

问题

1) 应用程序是否需要关闭由 vkGetSemaphoreFdKHR 返回的文件描述符？

已解决：是的，除非将其传递回驱动程序实例以导入信号量。成功的获取调用会将文件描述符的所有权转移给应用程序，而成功的导入则将其转移回驱动程序。销毁原始信号量对象不会关闭文件描述符或删除其对底层信号量资源的引用。

版本历史

  • 修订版 1，2016-10-21 (Jesse Hall)

    • 初始修订版

VK_KHR_external_semaphore_win32

名称字符串

VK_KHR_external_semaphore_win32

扩展类型

设备扩展

注册扩展号

79

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_semaphore

联系方式

其他扩展元数据

上次修改日期

2016-10-21

IP 状态

没有已知的 IP 声明。

贡献者

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Carsten Rohde, NVIDIA

描述

使用外部内存的应用程序可能希望使用信号量同步对该内存的访问。此扩展使应用程序能够将信号量有效负载导出到 Windows 句柄，并从 Windows 句柄导入信号量有效负载。

新命令

新结构体

新枚举常量

  • VK_KHR_EXTERNAL_SEMAPHORE_WIN32_EXTENSION_NAME

  • VK_KHR_EXTERNAL_SEMAPHORE_WIN32_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_D3D12_FENCE_SUBMIT_INFO_KHR

    • VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_SEMAPHORE_GET_WIN32_HANDLE_INFO_KHR

问题

1) 当 handleType 为 VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR 时，应用程序是否需要在从 vkGetSemaphoreWin32HandleKHR 返回的值上调用 CloseHandle()？

已解决：是的。成功的获取调用会将句柄的所有权转移给应用程序。销毁信号量对象不会销毁句柄或句柄对底层信号量资源的引用。与文件描述符不透明句柄不同，win32 不透明句柄的所有权不能通过导入操作转移回驱动程序。

2) 关于 KMT/Windows 7 句柄的语言是否应该移到单独的扩展中，以便可以随着时间的推移将其弃用？

已解决：可以由驱动程序自行决定是否弃用对它们的支持，方法是在实例级别的查询中不再返回它们作为支持的句柄类型。

3) 是否应允许应用程序为共享句柄指定其他对象属性？

已解决：是的。将允许应用程序提供与它们用于任何其他句柄创建 API 类似的属性。

4) 应用程序如何与基于 D3D12_FENCE 的 Vulkan 信号量通信要使用的期望的栅栏值？

已解决：有几种选择。可以在创建对象时提前传递已发出信号和重置状态的值，并在 Vulkan 信号量的生命周期内保持静态，或者可以在提交信号量信号和等待操作时使用辅助结构指定它们，类似于键控互斥扩展的做法。后者更灵活，并且与键控互斥的使用一致，但前者是更简单的 API。

由于 Vulkan 倾向于在灵活性和一致性方面优于简单性，因此将指定 D3D12 栅栏获取和释放值的新结构添加到 vkQueueSubmit 函数中。

版本历史

  • 修订版 1，2016-10-21 (James Jones)

    • 初始修订版

VK_KHR_fragment_shader_barycentric

名称字符串

VK_KHR_fragment_shader_barycentric

扩展类型

设备扩展

注册扩展号

323

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

  • Stu Smith

扩展提案

VK_KHR_fragment_shader_barycentric

其他扩展元数据

上次修改日期

2022-03-10

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Stu Smith, AMD

  • Tobias Hector, AMD

  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, Arm

  • Slawek Grajewski, Intel

  • Pat Brown, NVIDIA

  • Hans-Kristian Arntzen, Valve

  • VK_NV_fragment_shader_barycentric 规范的贡献者

描述

此扩展基于 VK_NV_fragment_shader_barycentric 扩展，并在 Vulkan 中增加了对以下 SPIR-V 扩展的支持

该扩展提供了对 SPIR-V 中三个附加片段着色器变量修饰符的访问

  • PerVertexKHR，指示片段着色器输入不会具有插值，而是必须使用额外的数组索引进行访问，该数组索引标识生成片段的图元的顶点之一

  • BaryCoordKHR，指示该变量是一个三组件浮点向量，保存使用透视插值生成的片段的重心权重

  • BaryCoordNoPerspKHR，指示该变量是一个三组件浮点向量，保存使用线性插值生成的片段的重心权重

使用基于 GLSL 源的着色器语言时，GL_EXT_fragment_shader_barycentric 中的以下变量映射到这些 SPIR-V 内置修饰符

  • in vec3 gl_BaryCoordEXT; → BaryCoordKHR

  • in vec3 gl_BaryCoordNoPerspEXT; → BaryCoordNoPerspKHR

使用 pervertexEXT GLSL 限定符声明的 GLSL 变量预计将使用 SPIR-V 中的 PerVertexKHR 进行修饰。

新结构体

新枚举常量

  • VK_KHR_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME

  • VK_KHR_FRAGMENT_SHADER_BARYCENTRIC_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_PROPERTIES_KHR

新内置变量

新 SPIR-V 修饰符

新 SPIR-V 功能

问题

1) 与 MSAA 的交互是什么，以及如何插值 BaryCoordKHR 和 BaryCoordNoPerspKHR？

已解决：使用 BaryCoordKHR 或 BaryCoordNoPerspKHR 修饰的输入可能也会使用 Centroid 或 Sample 限定符进行修饰，以指定插值，就像任何其他片元着色器输入一样。如果启用了shaderSampleRateInterpolationFunctions 功能，则 GLSL.std.450 中的扩展指令 InterpolateAtCentroid、InterpolateAtOffset 和 InterpolateAtSample 也可能与使用 BaryCoordKHR 或 BaryCoordNoPerspKHR 修饰的输入一起使用。

版本历史

  • 修订版 1，2022-03-10 (Stu Smith)

    • 初始修订版

VK_KHR_fragment_shading_rate

名称字符串

VK_KHR_fragment_shading_rate

扩展类型

设备扩展

注册扩展号

227

修订

2

批准状态

已批准

扩展和版本依赖关系

         VK_KHR_get_physical_device_properties2
         或
         Vulkan 版本 1.1
     和
     VK_KHR_create_renderpass2
或
Vulkan 版本 1.2

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_dynamic_rendering 交互

  • 与 VK_KHR_format_feature_flags2 交互

SPIR-V 依赖项
联系方式
扩展提案

VK_KHR_fragment_shading_rate

其他扩展元数据

上次修改日期

2021-09-30

交互和外部依赖
贡献者

  • Tobias Hector, AMD

  • Guennadi Riguer, AMD

  • Matthaeus Chajdas, AMD

  • Pat Brown, Nvidia

  • Matthew Netsch, Qualcomm

  • Slawomir Grajewski, Intel

  • Jan-Harald Fredriksen, Arm

  • Jeff Bolz, Nvidia

  • Arseny Kapoulkine, Roblox

  • VK_NV_shading_rate_image 规范的贡献者

  • VK_EXT_fragment_density_map 规范的贡献者

描述

此扩展增加了更改片元着色速率的能力。不再是通常的每个图元覆盖的像素的单个片元调用，而是可以通过单个片元着色器调用对多个像素进行着色。

应用程序可以使用多达三种方法来更改片元着色速率

此外，可以指定并组合所有这些速率，以便调整图像中每个点的整体细节。

此功能可用于将着色工作集中在场景某些部分需要更高细节的地方，而其他部分则不需要。这在高分辨率渲染或 XR 环境中尤其有用。

此扩展还增加了对 SPV_KHR_fragment_shading_rate 扩展的支持，该扩展允许设置图元片元着色速率，并允许从片元着色器查询最终着色速率。

新命令

新结构

如果支持 Vulkan 版本 1.3 或 VK_KHR_dynamic_rendering

新枚举

新枚举常量

  • VK_KHR_FRAGMENT_SHADING_RATE_EXTENSION_NAME

  • VK_KHR_FRAGMENT_SHADING_RATE_SPEC_VERSION

  • 扩展 VkAccessFlagBits

    • VK_ACCESS_FRAGMENT_SHADING_RATE_ATTACHMENT_READ_BIT_KHR

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_FRAGMENT_SHADING_RATE_KHR

  • 扩展 VkFormatFeatureFlagBits

    • VK_FORMAT_FEATURE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR

  • 扩展 VkImageLayout

    • VK_IMAGE_LAYOUT_FRAGMENT_SHADING_RATE_ATTACHMENT_OPTIMAL_KHR

  • 扩展 VkImageUsageFlagBits

    • VK_IMAGE_USAGE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR

  • 扩展 VkPipelineStageFlagBits

    • VK_PIPELINE_STAGE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_FRAGMENT_SHADING_RATE_ATTACHMENT_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_FRAGMENT_SHADING_RATE_STATE_CREATE_INFO_KHR

如果支持 VK_KHR_format_feature_flags2 或 Vulkan 1.3 版本

如果支持 Vulkan 版本 1.3 或 VK_KHR_dynamic_rendering

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_RENDERING_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR

    • VK_PIPELINE_RASTERIZATION_STATE_CREATE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_RENDERING_FRAGMENT_SHADING_RATE_ATTACHMENT_INFO_KHR

版本历史

  • 修订版 1，2020-05-06 (Tobias Hector)

    • 初始修订版

  • 修订版 2，2021-09-30 (Jon Leech)

VK_KHR_get_display_properties2

名称字符串

VK_KHR_get_display_properties2

扩展类型

实例扩展

注册扩展号

122

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_display

联系方式

其他扩展元数据

上次修改日期

2017-02-21

IP 状态

没有已知的 IP 声明。

贡献者

  • Ian Elliott, Google

  • James Jones, NVIDIA

描述

此扩展提供新的设备显示属性和功能查询，这些查询可以很容易地被其他扩展扩展，而无需引入任何其他查询。此扩展可以被认为是 VK_KHR_display 扩展的等效于 VK_KHR_get_physical_device_properties2 扩展。

新命令

新结构

新枚举常量

  • VK_KHR_GET_DISPLAY_PROPERTIES_2_EXTENSION_NAME

  • VK_KHR_GET_DISPLAY_PROPERTIES_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DISPLAY_MODE_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_PLANE_CAPABILITIES_2_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_PLANE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_PLANE_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_PROPERTIES_2_KHR

问题

1) 此扩展应该命名为什么？

已解决: VK_KHR_get_display_properties2。其他备选方案

  • VK_KHR_display2

  • 一个扩展，与 VK_KHR_surface_capabilites2 结合使用。

2) 是否应该为这些新函数添加可扩展的输入结构体？

已解决:

3) 是否应该扩展其他显示查询函数？

已解决:

版本历史

  • 版本 1，2017-02-21 (James Jones)

    • 初始草案。

VK_KHR_get_surface_capabilities2

名称字符串

VK_KHR_get_surface_capabilities2

扩展类型

实例扩展

注册扩展号

120

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

其他扩展元数据

上次修改日期

2017-02-27

IP 状态

没有已知的 IP 声明。

贡献者

  • Ian Elliott, Google

  • James Jones, NVIDIA

  • Alon Or-bach, Samsung

描述

此扩展提供了新的设备表面功能查询，这些查询可以很容易地被其他扩展扩展，而无需引入任何其他查询。此扩展可以被认为是 VK_KHR_surface 扩展的等效于 VK_KHR_get_physical_device_properties2 扩展。

新命令

新结构体

新枚举常量

  • VK_KHR_GET_SURFACE_CAPABILITIES_2_EXTENSION_NAME

  • VK_KHR_GET_SURFACE_CAPABILITIES_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SURFACE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_KHR

    • VK_STRUCTURE_TYPE_SURFACE_FORMAT_2_KHR

问题

1) 此扩展应该命名为什么？

已解决: VK_KHR_get_surface_capabilities2。其他备选方案

  • VK_KHR_surface2

  • 一个扩展，结合了单独的显示特定查询扩展。

2) 是否应该扩展其他 WSI 查询函数？

已解决:

版本历史

  • 版本 1，2017-02-27 (James Jones)

    • 初始草案。

VK_KHR_incremental_present

名称字符串

VK_KHR_incremental_present

扩展类型

设备扩展

注册扩展号

85

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_swapchain

联系方式

其他扩展元数据

上次修改日期

2016-11-02

IP 状态

没有已知的 IP 声明。

贡献者

  • Ian Elliott, Google

  • Jesse Hall, Google

  • Alon Or-bach, Samsung

  • James Jones, NVIDIA

  • Daniel Rakos, AMD

  • Ray Smith, ARM

  • Mika Isojarvi，谷歌

  • Jeff Juliano, NVIDIA

  • Jeff Bolz, NVIDIA

描述

此设备扩展扩展了 VK_KHR_swapchain 扩展中的 vkQueuePresentKHR，允许应用程序指定要呈现的每个图像的矩形修改区域列表。这应该在应用程序仅更改交换链中可呈现图像的一小部分时使用，因为它使演示引擎能够避免浪费时间呈现未更改的表面部分。

此扩展是从 EGL_KHR_swap_buffers_with_damage 扩展中衍生出来的。

新结构体

新枚举常量

  • VK_KHR_INCREMENTAL_PRESENT_EXTENSION_NAME

  • VK_KHR_INCREMENTAL_PRESENT_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PRESENT_REGIONS_KHR

问题

1) 我们应该如何处理立体3D交换链？我们需要为每个矩形添加一个层。一种方法是创建另一个包含 VkRect2D 加层的结构体，并让 VkPresentRegionsKHR 指向该结构体的数组。另一种方法是使用两个并行数组，pRectangles 和 pLayers，其中 pRectangles[i] 和 pLayers[i] 必须一起使用。我们应该使用哪种方法，如果是新结构体的数组，应该如何命名？

已解决: 创建一个新的结构体，它是 VkRect2D 加一个层，将被称为 VkRectLayerKHR。

2) VkRectLayerKHR 的原点在哪里？

已解决: 交换链的可呈现图像的左上角，根据帧缓冲坐标的定义。

3) 矩形区域 VkRectLayerKHR 指定的是交换链的图像像素，还是表面的像素？

已解决: 图像的像素。某些演示引擎可能会将交换链的图像像素缩放到表面大小。交换链的图像大小将保持一致，而表面大小可能会随时间变化。

4) 如果给定交换链的所有矩形都包含宽度和/或高度为零的值，会发生什么情况？

已解决: 应用程序表示自上次呈现以来没有像素发生更改。演示引擎可以使用这样的提示，并且不更新交换链的任何像素。但是，vkQueuePresentKHR 的所有其他语义仍然必须遵守，包括等待信号量发出信号。

5) 当交换链的创建方式是将 VkSwapchainCreateInfoKHR::preTransform 设置为 VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR 以外的值时，矩形区域 VkRectLayerKHR 是否应进行转换以与 preTransform 对齐？

已解决: 否。VkRectLayerKHR 中的矩形区域不应进行转换。因此，它可能与交换链图像的范围不对齐。转换矩形区域是演示引擎的责任。这与 Android 演示引擎的行为相匹配，后者设定了先例。

版本历史

  • 修订版 1, 2016-11-02 (Ian Elliott)

    • 内部修订

  • 修订版 2, 2021-03-18 (Ian Elliott)

    • 澄清了对支持转换交换链的演示引擎的矩形对齐。

VK_KHR_maintenance7

名称字符串

VK_KHR_maintenance7

扩展类型

设备扩展

注册扩展号

563

修订

1

批准状态

已批准

扩展和版本依赖关系

Vulkan 版本 1.1

联系方式

  • Mike Blumenkrantz zmike

扩展提案

VK_KHR_maintenance7

其他扩展元数据

上次修改日期

2024-01-30

交互和外部依赖
贡献者

  • Mike Blumenkrantz, Valve

  • Hans-Kristian Arntzen, Valve

  • Pan Gao, Huawei

  • Tobias Hector, AMD

  • Jon Leech, Khronos

  • Daniel Story, Nintendo

  • Shahbaz Youssefi, Google

  • Yiwei Zhang, Google

  • Matthew Netsch, Qualcomm

描述

VK_KHR_maintenance7 添加了一系列小的功能，这些功能本身都不足以构成一个单独的扩展。

提议的新功能如下

  • 添加一个属性查询，以确定帧缓冲写入深度或模板方面是否不会触发同级方面的写入访问。例如，这允许在渲染到同级深度附件的同时将模板方面采样为纹理，反之亦然，前提是使用适当的图像布局。

  • 添加一种方法来查询在通过分层实现提供 Vulkan 实现的环境中有关底层设备的信息。例如，在 Mesa/Venus 上运行时，驱动程序 ID 返回为 VK_DRIVER_ID_MESA_VENUS，但可能需要知道底层真正的驱动程序是什么。新的 VkPhysicalDeviceLayeredApiPropertiesKHR 结构可用于收集有关顶层物理设备下的层的信息。

  • 将 VK_RENDERING_CONTENTS_INLINE_BIT_EXT 和 VK_SUBPASS_CONTENTS_INLINE_AND_SECONDARY_COMMAND_BUFFERS_EXT 提升为 KHR

  • 添加一个限制，以报告可以包含在管线布局中的动态统一缓冲区和动态存储缓冲区的最大总数。

  • 要求对于无符号整数查询，32 位结果值必须等于等效 64 位结果值的 32 个最低有效位。

  • 添加在使用片段着色率附件时对稳健访问支持的查询

新结构

新枚举

新枚举常量

  • VK_KHR_MAINTENANCE_7_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_7_SPEC_VERSION

  • 扩展 VkRenderingFlagBits

    • VK_RENDERING_CONTENTS_INLINE_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LAYERED_API_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LAYERED_API_PROPERTIES_LIST_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LAYERED_API_VULKAN_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_7_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_7_PROPERTIES_KHR

  • 扩展 VkSubpassContents

    • VK_SUBPASS_CONTENTS_INLINE_AND_SECONDARY_COMMAND_BUFFERS_KHR

问题

无。

版本历史

  • 修订版 1, 2024-01-30 (Jon Leech)

    • 初始修订版

VK_KHR_maintenance8

名称字符串

VK_KHR_maintenance8

扩展类型

设备扩展

注册扩展号

575

修订

1

批准状态

已批准

扩展和版本依赖关系

Vulkan 版本 1.1

联系方式

  • Mike Blumenkrantz zmike

扩展提案

VK_KHR_maintenance8

其他扩展元数据

上次修改日期

2025-01-07

交互和外部依赖
贡献者

  • Jon Leech, Khronos

  • Mike Blumenkrantz, Valve

  • Spencer Fricke, LunarG

  • Jan-Harald Fredriksen, ARM

  • Piers Daniell, NVIDIA

  • Matthew Netsch, Qualcomm

  • Ricardo Garcia, Igalia

  • Lionel Landwerlin, Intel

  • Rick Hammerstone, Qualcomm

  • Daniel Story, Nintendo

  • Hans-Kristian Arntzen, Valve

描述

VK_KHR_maintenance8 添加了一系列小的功能，这些功能本身都不足以构成一个单独的扩展。

新功能如下

  • 允许在深度/模板附件和“匹配”的颜色附件之间进行复制

  • 允许 vkMergePipelineCaches 中的 dstCache 被隐式同步。

  • 要求在进行队列族所有权转移时，src/dst 同步范围正常工作

  • 支持在纹理采样和获取操作中使用 Offset（作为 ConstOffset 的替代）图像操作数

  • 使用 OpSRem 和 OpSMod 的 SPIR-V 定义，使这些操作为负操作数产生明确定义的结果

  • 在从 3D 图像拼合到其他图像类型时放宽层限制

  • 为用于 VkMemoryBarrier2、VkBufferMemoryBarrier2 和 VkImageMemoryBarrier2 的其他 64 个访问标志添加空间

新结构

新枚举

新位掩码

新枚举常量

  • VK_KHR_MAINTENANCE_8_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_8_SPEC_VERSION

  • 扩展 VkDependencyFlagBits

    • VK_DEPENDENCY_QUEUE_FAMILY_OWNERSHIP_TRANSFER_USE_ALL_STAGES_BIT_KHR

  • 扩展 VkPipelineCacheCreateFlagBits

    • VK_PIPELINE_CACHE_CREATE_INTERNALLY_SYNCHRONIZED_MERGE_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_MEMORY_BARRIER_ACCESS_FLAGS_3_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_8_FEATURES_KHR

问题

无。

版本历史

  • 修订版 1, 2024-06-20 (Jon Leech)

    • 初始修订版

VK_KHR_performance_query

名称字符串

VK_KHR_performance_query

扩展类型

设备扩展

注册扩展号

117

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

其他扩展元数据

上次修改日期

2019-10-08

IP 状态

没有已知的 IP 声明。

贡献者

  • Jesse Barker, Unity Technologies

  • Kenneth Benzie, Codeplay

  • Jan-Harald Fredriksen, ARM

  • Jeff Leger, Qualcomm

  • Jesse Hall, Google

  • Tobias Hector, AMD

  • Neil Henning, Codeplay

  • Baldur Karlsson

  • Lionel Landwerlin, Intel

  • Peter Lohrmann, AMD

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Niklas Smedberg, Unity Technologies

  • Igor Ostrowski, Intel

描述

VK_KHR_performance_query 扩展添加了一种机制，允许查询性能计数器，以供应用程序和分析工具使用。

每个队列族可以公开可以在该族的队列上启用的计数器。我们扩展 VkQueryType 以添加一种新的性能查询的查询类型，并在 VkQueryPoolCreateInfo 上链接一个结构来指定要启用的性能查询。

新命令

新结构

新联合体

新枚举

新位掩码

新枚举常量

  • VK_KHR_PERFORMANCE_QUERY_EXTENSION_NAME

  • VK_KHR_PERFORMANCE_QUERY_SPEC_VERSION

  • 扩展 VkQueryType

    • VK_QUERY_TYPE_PERFORMANCE_QUERY_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ACQUIRE_PROFILING_LOCK_INFO_KHR

    • VK_STRUCTURE_TYPE_PERFORMANCE_COUNTER_DESCRIPTION_KHR

    • VK_STRUCTURE_TYPE_PERFORMANCE_COUNTER_KHR

    • VK_STRUCTURE_TYPE_PERFORMANCE_QUERY_SUBMIT_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PERFORMANCE_QUERY_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PERFORMANCE_QUERY_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_QUERY_POOL_PERFORMANCE_CREATE_INFO_KHR

问题

1) 此扩展是否应包含一种机制，以在命令缓冲区 A 中开始查询，并在命令缓冲区 B 中结束查询？

已解决 否 - 查询与命令缓冲区的创建绑定，因此必须封装在单个命令缓冲区中。

2) 此扩展是否应包含一种机制，以在队列上全局开始和结束查询，而不是使用现有的命令缓冲区命令？

已解决 否 - 与问题 1 的解决方案相同的理由。

3) 此扩展是否应公开需要多次传递的计数器？

已解决 是 - 用户应多次重新提交具有相同命令的命令缓冲区，在 VkPerformanceQuerySubmitInfoKHR 中将要计数的传递指定为查询参数。

4) 如何处理跨并行工作负载的计数器？

已解决 本着 Vulkan 的精神，计数器描述标志 VK_PERFORMANCE_COUNTER_DESCRIPTION_CONCURRENTLY_IMPACTED_BIT_KHR 表示计数器结果的准确性会受到并行工作负载的影响。

5) 如何处理辅助命令缓冲区？

已解决 辅助命令缓冲区继承父主要命令缓冲区中指定的任何计数器传递索引。注意：在问题 10 的解决方案更改后，这不再是一个问题

6) 性能分析锁必须为哪些命令持有？

已解决 对于正在使用性能查询池进行查询的任何命令缓冲区，在命令缓冲区处于记录、可执行或挂起状态时，必须持有性能分析锁。

7) 我们是否应该支持 vkCmdCopyQueryPoolResults？

已解决 是。

8) 我们是否应该允许性能查询与多视图交互？

已解决 是，但必须对每个视图的每次传递执行一次性能查询。

9) queryCount > 1 是否可用于性能查询？

已解决 是。一些供应商将具有昂贵的性能计数器查询池创建，并且如果某些计数器要多次使用，则希望使用 queryCount > 1 来分摊实例化成本。

10) 我们是否应该引入一种间接机制来设置计数器传递索引？

已解决 改为在提交时指定计数器传递索引，以避免在需要多个计数器传递时重新记录命令缓冲区。

示例

以下示例演示如何查找队列族支持哪些性能计数器，设置查询池以记录这些性能计数器，如何将查询池添加到命令缓冲区以记录信息，以及如何从查询池获取结果。

// A previously created physical device
VkPhysicalDevice physicalDevice;

// One of the queue families our device supports
uint32_t queueFamilyIndex;

uint32_t counterCount;

// Get the count of counters supported
vkEnumeratePhysicalDeviceQueueFamilyPerformanceQueryCountersKHR(
  physicalDevice,
  queueFamilyIndex,
  &counterCount,
  NULL,
  NULL);

VkPerformanceCounterKHR* counters =
  malloc(sizeof(VkPerformanceCounterKHR) * counterCount);
VkPerformanceCounterDescriptionKHR* counterDescriptions =
  malloc(sizeof(VkPerformanceCounterDescriptionKHR) * counterCount);

// Get the counters supported
vkEnumeratePhysicalDeviceQueueFamilyPerformanceQueryCountersKHR(
  physicalDevice,
  queueFamilyIndex,
  &counterCount,
  counters,
  counterDescriptions);

// Try to enable the first 8 counters
uint32_t enabledCounters[8];

const uint32_t enabledCounterCount = min(counterCount, 8));

for (uint32_t i = 0; i < enabledCounterCount; i++) {
  enabledCounters[i] = i;
}

// A previously created device that had the performanceCounterQueryPools feature
// set to VK_TRUE
VkDevice device;

VkQueryPoolPerformanceCreateInfoKHR performanceQueryCreateInfo = {
  .sType = VK_STRUCTURE_TYPE_QUERY_POOL_PERFORMANCE_CREATE_INFO_KHR,
  .pNext = NULL,

  // Specify the queue family that this performance query is performed on
  .queueFamilyIndex = queueFamilyIndex,

  // The number of counters to enable
  .counterIndexCount = enabledCounterCount,

  // The array of indices of counters to enable
  .pCounterIndices = enabledCounters
};


// Get the number of passes our counters will require.
uint32_t numPasses;

vkGetPhysicalDeviceQueueFamilyPerformanceQueryPassesKHR(
  physicalDevice,
  &performanceQueryCreateInfo,
  &numPasses);

VkQueryPoolCreateInfo queryPoolCreateInfo = {
  .sType = VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO,
  .pNext = &performanceQueryCreateInfo,
  .flags = 0,
  // Using our new query type here
  .queryType = VK_QUERY_TYPE_PERFORMANCE_QUERY_KHR,
  .queryCount = 1,
  .pipelineStatistics = 0
};

VkQueryPool queryPool;

VkResult result = vkCreateQueryPool(
  device,
  &queryPoolCreateInfo,
  NULL,
  &queryPool);

assert(VK_SUCCESS == result);

// A queue from queueFamilyIndex
VkQueue queue;

// A command buffer we want to record counters on
VkCommandBuffer commandBuffer;

VkCommandBufferBeginInfo commandBufferBeginInfo = {
  .sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO,
  .pNext = NULL,
  .flags = 0,
  .pInheritanceInfo = NULL
};

VkAcquireProfilingLockInfoKHR lockInfo = {
  .sType = VK_STRUCTURE_TYPE_ACQUIRE_PROFILING_LOCK_INFO_KHR,
  .pNext = NULL,
  .flags = 0,
  .timeout = UINT64_MAX // Wait forever for the lock
};

// Acquire the profiling lock before we record command buffers
// that will use performance queries

result = vkAcquireProfilingLockKHR(device, &lockInfo);

assert(VK_SUCCESS == result);

result = vkBeginCommandBuffer(commandBuffer, &commandBufferBeginInfo);

assert(VK_SUCCESS == result);

vkCmdResetQueryPool(
  commandBuffer,
  queryPool,
  0,
  1);

vkCmdBeginQuery(
  commandBuffer,
  queryPool,
  0,
  0);

// Perform the commands you want to get performance information on
// ...

// Perform a barrier to ensure all previous commands were complete before
// ending the query
vkCmdPipelineBarrier(commandBuffer,
  VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT,
  VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT,
  0,
  0,
  NULL,
  0,
  NULL,
  0,
  NULL);

vkCmdEndQuery(
  commandBuffer,
  queryPool,
  0);

result = vkEndCommandBuffer(commandBuffer);

assert(VK_SUCCESS == result);

for (uint32_t counterPass = 0; counterPass < numPasses; counterPass++) {

  VkPerformanceQuerySubmitInfoKHR performanceQuerySubmitInfo = {
    VK_STRUCTURE_TYPE_PERFORMANCE_QUERY_SUBMIT_INFO_KHR,
    NULL,
    counterPass
  };


  // Submit the command buffer and wait for its completion
  // ...
}

// Release the profiling lock after the command buffer is no longer in the
// pending state.
vkReleaseProfilingLockKHR(device);

result = vkResetCommandBuffer(commandBuffer, 0);

assert(VK_SUCCESS == result);

// Create an array to hold the results of all counters
VkPerformanceCounterResultKHR* recordedCounters = malloc(
  sizeof(VkPerformanceCounterResultKHR) * enabledCounterCount);

result = vkGetQueryPoolResults(
  device,
  queryPool,
  0,
  1,
  sizeof(VkPerformanceCounterResultKHR) * enabledCounterCount,
  recordedCounters,
  sizeof(VkPerformanceCounterResultKHR) * enabledCounterCount,
  NULL);

// recordedCounters is filled with our counters, we will look at one for posterity
switch (counters[0].storage) {
  case VK_PERFORMANCE_COUNTER_STORAGE_INT32:
    // use recordCounters[0].int32 to get at the counter result!
    break;
  case VK_PERFORMANCE_COUNTER_STORAGE_INT64:
    // use recordCounters[0].int64 to get at the counter result!
    break;
  case VK_PERFORMANCE_COUNTER_STORAGE_UINT32:
    // use recordCounters[0].uint32 to get at the counter result!
    break;
  case VK_PERFORMANCE_COUNTER_STORAGE_UINT64:
    // use recordCounters[0].uint64 to get at the counter result!
    break;
  case VK_PERFORMANCE_COUNTER_STORAGE_FLOAT32:
    // use recordCounters[0].float32 to get at the counter result!
    break;
  case VK_PERFORMANCE_COUNTER_STORAGE_FLOAT64:
    // use recordCounters[0].float64 to get at the counter result!
    break;
}

版本历史

  • 修订版 1，2019-10-08

VK_KHR_pipeline_binary

名称字符串

VK_KHR_pipeline_binary

扩展类型

设备扩展

注册扩展号

484

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_maintenance5

联系方式
扩展提案

VK_KHR_pipeline_binary

其他扩展元数据

上次修改日期

2024-07-01

贡献者

  • Stu Smith, AMD

  • Tobias Hector, AMD

  • Alan Harrison, AMD

  • Maciej Jesionowski, AMD

  • Younggwan Kim, Arm

  • Jan-Harald Fredriksen, Arm

  • Ting Wei, Arm

  • Chris Glover, Google

  • Shahbaz Youssefi, Google

  • Jakub Kuderski, Google

  • Piotr Byszewski, Mobica

  • Piers Daniell, NVIDIA

  • Ralph Potter, Samsung

  • Matthew Netsch, Qualcomm

  • Hans-Kristian Arntzen, Valve

  • Samuel Pitoiset, Valve

  • Tatsuyuki Ishi, Valve

描述

此扩展提供了一种获取与单个管道关联的二进制数据的方法，以便应用程序可以自己管理缓存，而不是使用 VkPipelineCache 对象。

新对象类型

新命令

新结构体

新枚举常量

  • VK_KHR_PIPELINE_BINARY_EXTENSION_NAME

  • VK_KHR_PIPELINE_BINARY_SPEC_VERSION

  • VK_MAX_PIPELINE_BINARY_KEY_SIZE_KHR

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_PIPELINE_BINARY_KHR

  • 扩展 VkPipelineCreateFlagBits2

    • VK_PIPELINE_CREATE_2_CAPTURE_DATA_BIT_KHR

  • 扩展 VkResult

    • VK_ERROR_NOT_ENOUGH_SPACE_KHR

    • VK_PIPELINE_BINARY_MISSING_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_PIPELINE_BINARY_INTERNAL_CACHE_CONTROL_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_BINARY_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_BINARY_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_BINARY_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_BINARY_DATA_INFO_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_BINARY_HANDLES_INFO_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_BINARY_INFO_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_BINARY_KEY_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_RELEASE_CAPTURED_PIPELINE_DATA_INFO_KHR

版本历史

  • 修订版 1，2021-12-10 (Chris Glover)

    • 初始草案。

VK_KHR_pipeline_executable_properties

名称字符串

VK_KHR_pipeline_executable_properties

扩展类型

设备扩展

注册扩展号

270

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

其他扩展元数据

上次修改日期

2019-05-28

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Faith Ekstrand, Intel

  • Ian Romanick, Intel

  • Kenneth Graunke, Intel

  • Baldur Karlsson, Valve

  • Jesse Hall, Google

  • Jeff Bolz, Nvidia

  • Piers Daniel, Nvidia

  • Tobias Hector, AMD

  • Jan-Harald Fredriksen, ARM

  • Tom Olson, ARM

  • Daniel Koch, Nvidia

  • Spencer Fricke, Samsung

描述

当创建一个管线时，其状态和着色器会被编译成零个或多个设备特定的可执行文件，这些可执行文件在针对该管线执行命令时使用。此扩展添加了一种机制，用于查询有关管线编译过程产生的不同可执行文件的属性和统计信息。这旨在供调试和性能工具使用，以便它们向用户提供更详细的信息。通过此扩展提供的某些编译时着色器统计信息可能对开发人员进行调试或性能分析很有用。

新命令

新结构体

新联合体

新枚举

新枚举常量

  • VK_KHR_PIPELINE_EXECUTABLE_PROPERTIES_EXTENSION_NAME

  • VK_KHR_PIPELINE_EXECUTABLE_PROPERTIES_SPEC_VERSION

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_CAPTURE_INTERNAL_REPRESENTATIONS_BIT_KHR

    • VK_PIPELINE_CREATE_CAPTURE_STATISTICS_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_EXECUTABLE_PROPERTIES_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_INFO_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_INTERNAL_REPRESENTATION_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_STATISTIC_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_INFO_KHR

问题

1) 我们应该如何称呼由编译过程生成并可以查询属性和统计信息的管线片段？

已解决：称它们为“可执行文件”。该扩展的早期草案中使用了名称“二进制文件”，但确定“管线二进制文件”可能具有相当广泛的含义（例如，整个管线的二进制序列化形式），并且对于此扩展的非常具体的需求来说，命名空间太大了。

版本历史

  • 修订版 1，2019-05-28（Faith Ekstrand）

    • 初始草案

VK_KHR_pipeline_library

名称字符串

VK_KHR_pipeline_library

扩展类型

设备扩展

注册扩展号

291

修订

1

批准状态

已批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2020-01-08

IP 状态

没有已知的 IP 声明。

贡献者

描述

管线库是一种特殊的管线，不能绑定，而是定义一组着色器和着色器组，这些着色器和着色器组可以链接到其他管线中。此扩展定义了管线库的基础结构，但未指定管线库的创建或用法。这留给其他依赖扩展处理。

新结构体

新枚举常量

  • VK_KHR_PIPELINE_LIBRARY_EXTENSION_NAME

  • VK_KHR_PIPELINE_LIBRARY_SPEC_VERSION

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_LIBRARY_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PIPELINE_LIBRARY_CREATE_INFO_KHR

版本历史

  • 修订版 1，2020-01-08 (Christoph Kubisch)

    • 初始草案。

VK_KHR_portability_enumeration

名称字符串

VK_KHR_portability_enumeration

扩展类型

实例扩展

注册扩展号

395

修订

1

批准状态

已批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2021-06-02

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Lenny Komow, LunarG

  • Charles Giessen, LunarG

描述

此扩展允许应用程序控制是否在物理设备枚举的结果中包含暴露 VK_KHR_portability_subset 扩展的设备。由于支持 VK_KHR_portability_subset 扩展的设备并非完全符合 Vulkan 实现，因此除非应用程序明确要求，否则 Vulkan 加载器不会报告这些设备。这可以防止可能不知道不符合规范的设备的应用程序意外使用它们，因为任何支持 VK_KHR_portability_subset 扩展的设备都强制要求如果使用该设备，则必须启用该扩展。

此扩展在加载器中实现。

新枚举常量

  • VK_KHR_PORTABILITY_ENUMERATION_EXTENSION_NAME

  • VK_KHR_PORTABILITY_ENUMERATION_SPEC_VERSION

  • 扩展 VkInstanceCreateFlagBits

    • VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR

版本历史

  • 修订版 1，2021-06-02 (Lenny Komow)

    • 初始版本

VK_KHR_present_id

名称字符串

VK_KHR_present_id

扩展类型

设备扩展

注册扩展号

295

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_swapchain
和
VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2019-05-15

IP 状态

没有已知的 IP 声明。

贡献者

  • Keith Packard, Valve

  • Ian Elliott, Google

  • Alon Or-bach, Samsung

描述

此设备扩展允许使用 VK_KHR_swapchain 扩展的应用程序为交换链上的 present 操作提供标识符。应用程序可以使用它来引用其他扩展中的特定 present 操作。

新结构体

新枚举常量

  • VK_KHR_PRESENT_ID_EXTENSION_NAME

  • VK_KHR_PRESENT_ID_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_ID_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PRESENT_ID_KHR

问题

无。

示例

版本历史

  • 修订版 1，2019-05-15 (Keith Packard)

    • 初始版本

VK_KHR_present_wait

名称字符串

VK_KHR_present_wait

扩展类型

设备扩展

注册扩展号

249

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_swapchain
和
VK_KHR_present_id

联系方式

其他扩展元数据

上次修改日期

2019-05-15

IP 状态

没有已知的 IP 声明。

贡献者

  • Keith Packard, Valve

  • Ian Elliott, Google

  • Tobias Hector, AMD

  • Daniel Stone, Collabora

描述

此设备扩展允许使用 VK_KHR_swapchain 扩展的应用程序等待 present 操作完成。应用程序可以使用它来监视和控制应用程序的步调，方法是管理尚未呈现的待处理图像的数量。

新命令

新结构体

新枚举常量

  • VK_KHR_PRESENT_WAIT_EXTENSION_NAME

  • VK_KHR_PRESENT_WAIT_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_WAIT_FEATURES_KHR

问题

1) 等待何时完成？

已解决。当用户看到 present 时，等待将完成。新图像中第一个像素呈现给用户的时间之间没有精确的时序关系要求，但实现应该在尽可能接近将新图像中的第一个像素呈现给用户时发出等待信号。

2) 这应该使用围栏还是其他现有的同步机制。

已解决。由于显示和渲染通常在单独的驱动程序中实现，因此此扩展将提供单独的同步 API。

3) 此扩展是否应与其他扩展共享 present 标识？

已解决。是的。应该创建一个新的扩展 VK_KHR_present_id，为呈现标识符提供一个共享结构。

4) 当呈现完成的顺序与 vkQueuePresent 的调用顺序不一致时会发生什么？如果呈现的信号量就绪顺序不一致，则可能会发生这种情况。

选项 A：要求当设置 PresentId 时，驱动程序确保图像始终按照 vkQueuePresent 的调用顺序呈现。

选项 B：当最早的呈现完成时，完成两次等待。这将使稍后的呈现等待早于实际呈现完成。这应该是最容易实现的，因为驱动程序只需要跟踪已完成的最大 present ID。这也是解释现有 vkWaitForPresentKHR 规范的“自然”结果。

选项 C：当两者都完成时，完成两次等待。这将使较早的呈现晚于实际呈现时间完成。当前规范允许这样做，因为对于 presentId 值的更新时间没有精确的时间要求。这需要在驱动程序中增加一些复杂性，因为它需要跟踪所有未完成的 presentId 值。

示例

版本历史

  • 修订版 1，2019-02-19（Keith Packard）

    • 初始版本

VK_KHR_ray_query

名称字符串

VK_KHR_ray_query

扩展类型

设备扩展

注册扩展号

349

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_spirv_1_4
和
VK_KHR_acceleration_structure

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2020-11-12

交互和外部依赖
贡献者

  • Matthäus Chajdas, AMD

  • Greg Grebe, AMD

  • Nicolai Hähnle, AMD

  • Tobias Hector, AMD

  • Dave Oldcorn, AMD

  • Skyler Saleh, AMD

  • Mathieu Robart, Arm

  • Marius Bjorge, Arm

  • Tom Olson, Arm

  • Sebastian Tafuri, EA

  • Henrik Rydgard, Embark

  • Juan Cañada, Epic Games

  • Patrick Kelly, Epic Games

  • Yuriy O’Donnell, Epic Games

  • Michael Doggett, Facebook/Oculus

  • Andrew Garrard, Imagination

  • Don Scorgie, Imagination

  • Dae Kim, Imagination

  • Joshua Barczak, Intel

  • Slawek Grajewski, Intel

  • Jeff Bolz, NVIDIA

  • Pascal Gautron, NVIDIA

  • Daniel Koch, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Ashwin Lele, NVIDIA

  • Robert Stepinski, NVIDIA

  • Martin Stich, NVIDIA

  • Nuno Subtil, NVIDIA

  • Eric Werness, NVIDIA

  • Jon Leech, Khronos

  • Jeroen van Schijndel, OTOY

  • Juul Joosten, OTOY

  • Alex Bourd, Qualcomm

  • Roman Larionov, Qualcomm

  • David McAllister, Qualcomm

  • Spencer Fricke, Samsung

  • Lewis Gordon, Samsung

  • Ralph Potter, Samsung

  • Jasper Bekkers, Traverse Research

  • Jesse Barker, Unity

  • Baldur Karlsson, Valve

描述

光栅化一直是生成交互式图形的主要方法，但是图形硬件性能的提高使得光线追踪成为交互式渲染的可行选择。能够将光线追踪与传统的光栅化集成，使得应用程序可以更容易地将光线追踪效果逐步添加到现有应用程序中，或者采用混合方法，使用光栅化进行主要可见性计算，而使用光线追踪进行辅助查询。

光线查询适用于所有着色器类型，包括图形、计算和光线追踪管线。光线查询无法启动额外的着色器，而是将遍历结果返回给调用着色器。

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

  • SPV_KHR_ray_query

新结构

新枚举常量

  • VK_KHR_RAY_QUERY_EXTENSION_NAME

  • VK_KHR_RAY_QUERY_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_QUERY_FEATURES_KHR

新的 SPIR-V 功能

示例代码

GLSL 着色器中光线查询的示例，说明如何使用光线查询通过追踪射向光源的光线，并检查是否存在任何遮挡光源的几何体的相交，来确定给定位置（在光线原点）是否在阴影中。

rayQueryEXT rq;

rayQueryInitializeEXT(rq, accStruct, gl_RayFlagsTerminateOnFirstHitEXT, cullMask, origin, tMin, direction, tMax);

// Traverse the acceleration structure and store information about the first intersection (if any)
rayQueryProceedEXT(rq);

if (rayQueryGetIntersectionTypeEXT(rq, true) == gl_RayQueryCommittedIntersectionNoneEXT) {
    // Not in shadow
}

问题

(1) 公共临时版本 (VK_KHR_ray_tracing v8) 和最终版本 (VK_KHR_acceleration_structure v11 / VK_KHR_ray_query v1) 之间的更改是什么？

  • 将 VK_KHR_ray_tracing 重构为 3 个扩展，从而实现实现灵活性，并将光线查询支持与光线管道分离

  • 更新 SPIRV 功能以使用 RayQueryKHR

  • 此扩展不再是临时的。

版本历史

  • 修订版 1，2020-11-12（Mathieu Robart，Daniel Koch，Andrew Garrard）

    • 将规范从 VK_KHR_ray_tracing 分解为 VK_KHR_ray_query (#1918,!3912)

    • 更新以使用 RayQueryKHR SPIR-V 功能

    • 为光线参数添加数值限制 (#2235,!3960)

    • 放宽光线相交候选确定的公式 (#2322,!4080)

    • 将追踪限制为 TLAS (#2239,!4141)

    • 要求 HitT 在 OpRayQueryGenerateIntersectionKHR 的光线间隔内 (#2359,!4146)

    • 为 AS 读取位添加光线查询着色器阶段 (#2407,!4203)

VK_KHR_ray_tracing_maintenance1

名称字符串

VK_KHR_ray_tracing_maintenance1

扩展类型

设备扩展

注册扩展号

387

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_acceleration_structure

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_EXT_device_generated_commands 交互

  • 与 VK_KHR_ray_tracing_pipeline 交互

  • 与 VK_KHR_synchronization2 交互

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2022-02-21

交互和外部依赖
贡献者

  • Stu Smith, AMD

  • Tobias Hector, AMD

  • Marius Bjorge, Arm

  • Tom Olson, Arm

  • Yuriy O’Donnell, Epic Games

  • Yunpeng Zhu，华为

  • Andrew Garrard, Imagination

  • Dae Kim, Imagination

  • Joshua Barczak, Intel

  • Lionel Landwerlin, Intel

  • Daniel Koch, NVIDIA

  • Eric Werness, NVIDIA

  • Spencer Fricke, Samsung

描述

VK_KHR_ray_tracing_maintenance1 添加了一系列小的光线追踪功能，这些功能本身都不足以构成一个完整的扩展。

新功能如下

  • 添加了对 Vulkan 中 SPV_KHR_ray_cull_mask SPIR-V 扩展的支持。此扩展提供了对内置 CullMaskKHR 着色器变量的访问，该变量包含 OpTrace* Cull Mask 参数的值。这个新的着色器变量可以在相交、任何命中、最近命中和未命中着色器阶段访问。

  • 基于 VK_KHR_synchronization2 之上添加了新的管线阶段和访问掩码

    • VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_COPY_BIT_KHR 指定 加速结构复制命令 的执行

    • VK_ACCESS_2_SHADER_BINDING_TABLE_READ_BIT_KHR 指定在任何着色器管线阶段对 着色器绑定表 的读取访问

  • 添加了两个新的加速结构查询参数

    • VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SIZE_KHR 用于查询设备时间线上加速结构的大小

    • VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SERIALIZATION_BOTTOM_LEVEL_POINTERS_KHR 用于查询序列化时底层加速结构指针的数量

  • 添加了一个可选的新间接光线追踪调度命令 vkCmdTraceRaysIndirect2KHR，该命令从设备获取着色器绑定表参数以及调度维度。 rayTracingPipelineTraceRaysIndirect2 功能指示是否支持此功能。

新命令

如果支持 VK_KHR_ray_tracing_pipeline

新结构

如果支持 VK_KHR_ray_tracing_pipeline

新枚举常量

  • VK_KHR_RAY_TRACING_MAINTENANCE_1_EXTENSION_NAME

  • VK_KHR_RAY_TRACING_MAINTENANCE_1_SPEC_VERSION

  • 扩展 VkQueryType

    • VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SERIALIZATION_BOTTOM_LEVEL_POINTERS_KHR

    • VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SIZE_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_MAINTENANCE_1_FEATURES_KHR

如果支持 VK_KHR_synchronization2 或 Vulkan 版本 1.3 和 VK_KHR_ray_tracing_pipeline

如果支持 VK_EXT_device_generated_commands

如果支持 VK_KHR_synchronization2 或 Vulkan 版本 1.3

新的内置变量

新的 SPIR-V 功能

问题

目前没有！

版本历史

  • 修订版 1，2022-02-21 (Vulkan 光线追踪 TSG 成员)

    • 内部修订

VK_KHR_ray_tracing_pipeline

名称字符串

VK_KHR_ray_tracing_pipeline

扩展类型

设备扩展

注册扩展号

348

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_spirv_1_4
和
VK_KHR_acceleration_structure

API 交互

  • 与 VK_KHR_ray_query 交互

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2020-11-12

交互和外部依赖
贡献者

  • Matthäus Chajdas, AMD

  • Greg Grebe, AMD

  • Nicolai Hähnle, AMD

  • Tobias Hector, AMD

  • Dave Oldcorn, AMD

  • Skyler Saleh, AMD

  • Mathieu Robart, Arm

  • Marius Bjorge, Arm

  • Tom Olson, Arm

  • Sebastian Tafuri, EA

  • Henrik Rydgard, Embark

  • Juan Cañada, Epic Games

  • Patrick Kelly, Epic Games

  • Yuriy O’Donnell, Epic Games

  • Michael Doggett, Facebook/Oculus

  • Andrew Garrard, Imagination

  • Don Scorgie, Imagination

  • Dae Kim, Imagination

  • Joshua Barczak, Intel

  • Slawek Grajewski, Intel

  • Jeff Bolz, NVIDIA

  • Pascal Gautron, NVIDIA

  • Daniel Koch, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Ashwin Lele, NVIDIA

  • Robert Stepinski, NVIDIA

  • Martin Stich, NVIDIA

  • Nuno Subtil, NVIDIA

  • Eric Werness, NVIDIA

  • Jon Leech, Khronos

  • Jeroen van Schijndel, OTOY

  • Juul Joosten, OTOY

  • Alex Bourd, Qualcomm

  • Roman Larionov, Qualcomm

  • David McAllister, Qualcomm

  • Spencer Fricke, Samsung

  • Lewis Gordon, Samsung

  • Ralph Potter, Samsung

  • Jasper Bekkers, Traverse Research

  • Jesse Barker, Unity

  • Baldur Karlsson, Valve

描述

光栅化一直是生成交互式图形的主要方法，但是图形硬件性能的提高使得光线追踪成为交互式渲染的可行选择。能够将光线追踪与传统的光栅化集成，使得应用程序可以更容易地将光线追踪效果逐步添加到现有应用程序中，或者采用混合方法，使用光栅化进行主要可见性计算，而使用光线追踪进行辅助查询。

为了启用光线追踪，此扩展添加了几个不同类别的新功能

  • 具有新的着色器域的新光线追踪管线类型：光线生成、相交、任意命中、最近命中、未命中和可调用

  • 一个着色器绑定间接表，用于将着色器组与加速结构项链接

  • 光线追踪命令，根据满足的遍历条件，启动光线管线遍历和各种新着色器域的调用

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

  • SPV_KHR_ray_tracing

新命令

新结构

新枚举

新枚举常量

  • VK_KHR_RAY_TRACING_PIPELINE_EXTENSION_NAME

  • VK_KHR_RAY_TRACING_PIPELINE_SPEC_VERSION

  • VK_SHADER_UNUSED_KHR

  • 扩展 VkBufferUsageFlagBits

    • VK_BUFFER_USAGE_SHADER_BINDING_TABLE_BIT_KHR

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_RAY_TRACING_PIPELINE_STACK_SIZE_KHR

  • 扩展 VkPipelineBindPoint

    • VK_PIPELINE_BIND_POINT_RAY_TRACING_KHR

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_ANY_HIT_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_CLOSEST_HIT_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_INTERSECTION_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_MISS_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_RAY_TRACING_SHADER_GROUP_HANDLE_CAPTURE_REPLAY_BIT_KHR

    • VK_PIPELINE_CREATE_RAY_TRACING_SKIP_AABBS_BIT_KHR

    • VK_PIPELINE_CREATE_RAY_TRACING_SKIP_TRIANGLES_BIT_KHR

  • 扩展 VkPipelineStageFlagBits

    • VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_KHR

  • 扩展 VkShaderStageFlagBits

    • VK_SHADER_STAGE_ANY_HIT_BIT_KHR

    • VK_SHADER_STAGE_CALLABLE_BIT_KHR

    • VK_SHADER_STAGE_CLOSEST_HIT_BIT_KHR

    • VK_SHADER_STAGE_INTERSECTION_BIT_KHR

    • VK_SHADER_STAGE_MISS_BIT_KHR

    • VK_SHADER_STAGE_RAYGEN_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_PIPELINE_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_PIPELINE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_RAY_TRACING_PIPELINE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_RAY_TRACING_PIPELINE_INTERFACE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_RAY_TRACING_SHADER_GROUP_CREATE_INFO_KHR

新的或修改的内置变量

新的 SPIR-V 功能

问题

(1) 此扩展与 VK_NV_ray_tracing 有何不同？

讨论:

以下是 VK_KHR_ray_tracing_pipeline 和 VK_NV_ray_tracing 之间主要功能差异的摘要

  • 增加了对间接光线追踪的支持 (vkCmdTraceRaysIndirectKHR)

  • 使用 SPV_KHR_ray_tracing 而不是 SPV_NV_ray_tracing

    • 引用 KHR SPIR-V 枚举，而不是 NV SPIR-V 枚举（它们在功能上等效并别名为相同的值）。

    • 添加了 RayGeometryIndexKHR 内置变量

  • 删除了 vkCompileDeferredNV 编译功能，并用 延迟主机操作 交互来代替光线追踪

  • 添加了 VkPhysicalDeviceRayTracingPipelineFeaturesKHR 结构

  • 扩展了 VkPhysicalDeviceRayTracingPipelinePropertiesKHR 结构

    • 将 maxRecursionDepth 重命名为 maxRayRecursionDepth，其最小值从 31 变为 1

    • 要求 shaderGroupHandleSize 为 32 字节

    • 添加了 maxRayDispatchInvocationCount、shaderGroupHandleAlignment 和 maxRayHitAttributeSize

  • 重构了几何结构，以便更好地在设备、主机和间接构建之间共享

  • 将 SBT 参数更改为结构并添加了大小 (VkStridedDeviceAddressRegionKHR)

  • 添加了请求主机和/或设备构建的内存要求的参数

  • 增加了对光线追踪的 管线库 支持

  • 增加了 水密性保证

  • 添加了无空着色器管线标志 (VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_*_SHADERS_BIT_KHR)

  • 增加了与光线追踪的内存模型交互，并定义了子组如何工作以及如何重新打包

(2) 您能否更详细地比较 VK_NV_ray_tracing 和 VK_KHR_ray_tracing_pipeline 之间的差异和相似之处？

讨论:

以下是对哪些命令、结构和枚举进行了别名、更改或删除的更详细的比较。

(3) 公开的临时版本（VK_KHR_ray_tracing v8）和内部临时版本（VK_KHR_ray_tracing v9）之间有哪些变化？

(4) 内部临时版本（VK_KHR_ray_tracing v9）和最终版本（VK_KHR_acceleration_structure v11 / VK_KHR_ray_tracing_pipeline v1）之间有哪些变化？

  • 将 VK_KHR_ray_tracing 重构为 3 个扩展，从而实现实现灵活性，并将光线查询支持与光线管道分离

  • 对于光线生成、最近命中、未命中、相交和可调用着色器阶段中的以下内置变量，需要 Volatile 修饰符

    • SubgroupSize, SubgroupLocalInvocationId, SubgroupEqMask, SubgroupGeMask, SubgroupGtMask, SubgroupLeMask, SubgroupLtMask

    • SMIDNV, WarpIDNV

  • 澄清光线跟踪的缓冲区使用标志

    • VK_BUFFER_USAGE_SHADER_BINDING_TABLE_BIT_KHR 作为 VK_BUFFER_USAGE_RAY_TRACING_BIT_NV 的别名添加，并且在着色器绑定表缓冲区上是必需的

    • VK_BUFFER_USAGE_STORAGE_BUFFER_BIT 在 VK_KHR_acceleration_structure 中用于 scratchData

  • 将 maxRecursionDepth 重命名为 maxRayPipelineRecursionDepth（管线创建）和 maxRayRecursionDepth（限制），以减少混淆

  • 添加可查询的 maxRayHitAttributeSize 限制，并将 VkRayTracingPipelineInterfaceCreateInfoKHR 的成员重命名为 maxPipelineRayPayloadSize 和 maxPipelineRayHitAttributeSize，以提高清晰度

  • 更新 SPIRV 功能以使用 RayTracingKHR

  • 此扩展不再是临时的。

  • 定义间接光线追踪和间接缓冲区的同步要求

(5) 此扩展为相交、任何命中和最近命中着色器添加了 gl_InstanceID，但在 KHR_vulkan_glsl 中，gl_InstanceID 被 gl_InstanceIndex 替换。在此扩展中，Vulkan 应该使用哪个？

已解决：此扩展使用 gl_InstanceID 并将其映射到 SPIR-V 中的 InstanceId。承认这与 Vulkan 中其他着色器阶段不同。这里存在差异的主要原因有两个

  • 与 gl_PrimitiveID 对称，后者也在这些着色器中可用

  • 这些着色器没有相关的“baseInstance”，因此 ID 更能明确地表示它是从零开始的。

(6) 为什么 VK_KHR_pipeline_library 是一种交互，而不是必需的依赖项，特别是在“功能要求”部分说无论如何都需要支持它时？

已解决：如果 VK_KHR_pipeline_library 扩展是必需的依赖项，那么每个应用程序都需要启用该扩展，无论它们是否真的想使用管线库功能。开发人员发现这很烦人且不友好。我们确实希望所有**实现**都支持它，因此它列在功能要求部分。

示例代码

示例光线生成 GLSL 着色器

#version 450 core
#extension GL_EXT_ray_tracing : require
layout(set = 0, binding = 0, rgba8) uniform image2D image;
layout(set = 0, binding = 1) uniform accelerationStructureEXT as;
layout(location = 0) rayPayloadEXT float payload;

void main()
{
   vec4 col = vec4(0, 0, 0, 1);

   vec3 origin = vec3(float(gl_LaunchIDEXT.x)/float(gl_LaunchSizeEXT.x), float(gl_LaunchIDEXT.y)/float(gl_LaunchSizeEXT.y), 1.0);
   vec3 dir = vec3(0.0, 0.0, -1.0);

   traceRayEXT(as, 0, 0xff, 0, 1, 0, origin, 0.0, dir, 1000.0, 0);

   col.y = payload;

   imageStore(image, ivec2(gl_LaunchIDEXT.xy), col);
}

版本历史

  • 修订版 1，2020-11-12（Mathieu Robart，Daniel Koch，Eric Werness，Tobias Hector）

    • 规范的分解，从 VK_KHR_ray_tracing 到 VK_KHR_ray_tracing_pipeline (#1918,!3912)

    • 要求某些子组和 sm_shader_builtin 着色器内置变量在光线生成、最近命中、未命中、相交和可调用阶段被装饰为 volatile (#1924,!3903,!3954)

    • 澄清光线追踪的缓冲区使用标志 (#2181,!3939)

    • 将 maxRecursionDepth 重命名为 maxRayPipelineRecursionDepth 和 maxRayRecursionDepth (#2203,!3937)

    • 添加可查询的 maxRayHitAttributeSize 并重命名 VkRayTracingPipelineInterfaceCreateInfoKHR 的成员 (#2102,!3966)

    • 更新为使用 RayTracingKHR SPIR-V 功能

    • 添加用于匹配命中组类型与几何类型的 VU (#2245,!3994)

    • 要求 RayTMaxKHR 在相交着色器中是 volatile 的 (#2268,!4030)

    • 为光线参数添加数值限制 (#2235,!3960)

    • 修复设备地址的 SBT 索引规则 (#2308,!4079)

    • 放宽光线相交候选确定的公式 (#2322,!4080)

    • 添加有关 ShaderRecordBufferKHR 变量的更多详细信息 (#2230,!4083)

    • 澄清 InstanceCustomIndexKHR 的有效位 (GLSL/GLSL#19,!4128)

    • 最多允许一个 IncomingRayPayloadKHR，IncomingCallableDataKHR 和 HitAttributeKHR (!4129)

    • 添加 maxShaderGroupStride 的最小值 (#2353,!4131)

    • 要求支持 VK_KHR_pipeline_library 扩展 (#2348,!4135)

    • 澄清“几何索引”的含义 (#2272,!4137)

    • 将追踪限制为 TLAS (#2239,!4141)

    • 添加关于 maxPipelineRayPayloadSize 的注释 (#2383,!4172)

    • 不需要管线库中的 raygen 着色器 (!4185)

    • 为间接光线追踪和间接缓冲区定义同步 (#2407,!4208)

VK_KHR_ray_tracing_position_fetch

名称字符串

VK_KHR_ray_tracing_position_fetch

扩展类型

设备扩展

注册扩展号

482

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_acceleration_structure

SPIR-V 依赖项
联系方式

  • Eric Werness

扩展提案

VK_KHR_ray_tracing_position_fetch

其他扩展元数据

上次修改日期

2023-02-17

交互和外部依赖
贡献者

  • Eric Werness, NVIDIA

  • Stu Smith, AMD

  • Yuriy O’Donnell, Epic Games

  • Ralph Potter, Samsung

  • Joshua Barczak, Intel

  • Lionel Landwerlin, Intel

  • Andrew Garrard，Imagination Technologies

  • Alex Bourd, Qualcomm

  • Yunpeng Zhu，华为技术

  • Marius Bjorge, Arm

  • Daniel Koch, NVIDIA

描述

VK_KHR_ray_tracing_position_fetch 添加了从着色器中获取命中三角形的顶点位置的能力，就像存储在加速结构中一样。

应用程序在构建时向加速结构添加 VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DATA_ACCESS_KHR。然后，如果命中是三角形几何体，着色器（光线管道的任何命中或最近命中，或者使用光线查询）可以获取被命中的三角形在对象空间中的三个三维顶点位置。

新结构

新枚举常量

  • VK_KHR_RAY_TRACING_POSITION_FETCH_EXTENSION_NAME

  • VK_KHR_RAY_TRACING_POSITION_FETCH_SPEC_VERSION

  • 扩展 VkBuildAccelerationStructureFlagBitsKHR

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DATA_ACCESS_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_POSITION_FETCH_FEATURES_KHR

新内置变量

新 SPIR-V 功能

问题

目前没有！

版本历史

  • 修订版 1，2023-02-17 (Eric Werness)

    • 内部修订

VK_KHR_shader_clock

名称字符串

VK_KHR_shader_clock

扩展类型

设备扩展

注册扩展号

182

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2019-4-25

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Aaron Hagan, AMD

  • Daniel Koch, NVIDIA

描述

此扩展为 Vulkan 公告 SPIR-V ShaderClockKHR 功能，该功能允许着色器在子组级别或设备级别查询实时或单调递增的计数器。 OpReadClockKHR 的两个有效 SPIR-V 范围是 Subgroup 和 Device。

当使用基于 GLSL 源的着色语言时，clockRealtime*EXT() 定时函数映射到范围为 Device 的 OpReadClockKHR 指令，而 clock*ARB() 定时函数映射到范围为 Subgroup 的 OpReadClockKHR 指令。

新结构

新枚举常量

  • VK_KHR_SHADER_CLOCK_EXTENSION_NAME

  • VK_KHR_SHADER_CLOCK_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CLOCK_FEATURES_KHR

新 SPIR-V 功能

版本历史

  • 修订版 1，2019-4-25 (Aaron Hagan)

    • 初始修订版

VK_KHR_shader_maximal_reconvergence

名称字符串

VK_KHR_shader_maximal_reconvergence

扩展类型

设备扩展

注册扩展号

435

修订

1

批准状态

已批准

扩展和版本依赖关系

Vulkan 版本 1.1

SPIR-V 依赖项
联系方式
扩展提案

VK_KHR_shader_maximal_reconvergence

其他扩展元数据

上次修改日期

2021-11-12

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Alan Baker, Google

描述

此扩展允许在着色器模块中使用 SPV_KHR_maximal_reconvergence SPIR-V 扩展。SPV_KHR_maximal_reconvergence 提供更强的保证，即发散的子组将重新收敛。这些保证应与着色器作者关于基于 HLL 代码结构的调用发散和重新收敛的直觉相匹配。

如果开发者需要比核心规范或 SPV_KHR_subgroup_uniform_control_flow 更强的关于重新收敛的保证，则应使用此扩展。此扩展将定义控制调用如何发散和重新收敛的规则，这些规则应与开发人员的直觉相匹配。它允许编写可靠的程序，依赖于子组操作和其他复杂的指令。

新结构

新枚举常量

  • VK_KHR_SHADER_MAXIMAL_RECONVERGENCE_EXTENSION_NAME

  • VK_KHR_SHADER_MAXIMAL_RECONVERGENCE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_MAXIMAL_RECONVERGENCE_FEATURES_KHR

版本历史

  • 修订版 1，2021-11-12 (Alan Baker)

    • 内部草稿版本

VK_KHR_shader_quad_control

名称字符串

VK_KHR_shader_quad_control

扩展类型

设备扩展

注册扩展号

236

修订

1

批准状态

已批准

扩展和版本依赖关系

Vulkan 版本 1.1
和
VK_KHR_vulkan_memory_model
和
VK_KHR_shader_maximal_reconvergence

SPIR-V 依赖项
联系方式
扩展提案

VK_KHR_shader_quad_control

其他扩展元数据

上次修改日期

2023-11-01

IP 状态

没有已知的 IP 声明。

贡献者

  • 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

描述

此扩展添加了新的四边形任何/全部操作，要求导数在四边形统一控制流中定义良好，并增加了要求辅助调用参与组操作的能力。

新结构

新枚举常量

  • VK_KHR_SHADER_QUAD_CONTROL_EXTENSION_NAME

  • VK_KHR_SHADER_QUAD_CONTROL_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_QUAD_CONTROL_FEATURES_KHR

新 SPIR-V 功能

版本历史

  • 修订版 1，2023-11-01 (Tobias Hector)

    • 初始草案

VK_KHR_shader_relaxed_extended_instruction

名称字符串

VK_KHR_shader_relaxed_extended_instruction

扩展类型

设备扩展

注册扩展号

559

修订

1

批准状态

已批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式
扩展提案

VK_KHR_shader_relaxed_extended_instruction

其他扩展元数据

上次修改日期

2024-01-24

IP 状态

没有已知的 IP 声明。

贡献者

  • Alan Baker, Google LLC

  • Nathan Gauër, Google LLC

描述

此扩展允许在 SPIR-V 着色器模块中使用 SPV_KHR_relaxed_extended_instruction 扩展。

它添加了一个新的 SPIR-V 指令，该指令允许在非语义指令集中使用前向引用。此扩展与 SPV_KHR_non_semantic_info 扩展交互，因此与 VK_KHR_shader_non_semantic_info 交互。

新结构

新枚举常量

  • VK_KHR_SHADER_RELAXED_EXTENDED_INSTRUCTION_EXTENSION_NAME

  • VK_KHR_SHADER_RELAXED_EXTENDED_INSTRUCTION_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_RELAXED_EXTENDED_INSTRUCTION_FEATURES_KHR

版本历史

  • 修订版 1，2024-01-24 (Nathan Gauër)

    • 初始修订版

VK_KHR_shader_subgroup_uniform_control_flow

名称字符串

VK_KHR_shader_subgroup_uniform_control_flow

扩展类型

设备扩展

注册扩展号

324

修订

1

批准状态

已批准

扩展和版本依赖关系

Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2020-08-27

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Alan Baker, Google

  • Jeff Bolz, NVIDIA

描述

此扩展允许在着色器模块中使用 SPV_KHR_subgroup_uniform_control_flow SPIR-V 扩展。SPV_KHR_subgroup_uniform_control_flow 提供更强的保证，即发散的子组将重新收敛。

如果开发者使用子组操作来减少统一子组执行的工作量，则应使用此扩展。此扩展将保证统一子组的重新收敛方式与调用组相同（请参阅Khronos SPIR-V 规范中的“统一控制流”）。

新结构

新枚举常量

  • VK_KHR_SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_EXTENSION_NAME

  • VK_KHR_SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_FEATURES_KHR

版本历史

  • 修订版 1，2020-08-27 (Alan Baker)

    • 内部草稿版本

VK_KHR_shared_presentable_image

名称字符串

VK_KHR_shared_presentable_image

扩展类型

设备扩展

注册扩展号

112

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_swapchain
和
VK_KHR_get_surface_capabilities2
和
     VK_KHR_get_physical_device_properties2
    或
     Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2017-03-20

IP 状态

没有已知的 IP 声明。

贡献者

  • Alon Or-bach, Samsung Electronics

  • Ian Elliott, Google

  • Jesse Hall, Google

  • Pablo Ceballos, Google

  • Chris Forbes, Google

  • Jeff Juliano, NVIDIA

  • James Jones, NVIDIA

  • Daniel Rakos, AMD

  • Tobias Hector, Imagination Technologies

  • Graham Connor, Imagination Technologies

  • Michael Worcester, Imagination Technologies

  • Cass Everitt, Oculus

  • Johannes Van Waveren, Oculus

描述

此扩展扩展了 VK_KHR_swapchain 以启用共享可呈现图像的创建。这允许应用程序在使用图像时，同时呈现引擎也在访问图像，以减少渲染和呈现之间的延迟。

新命令

新结构

新枚举常量

  • VK_KHR_SHARED_PRESENTABLE_IMAGE_EXTENSION_NAME

  • VK_KHR_SHARED_PRESENTABLE_IMAGE_SPEC_VERSION

  • 扩展 VkImageLayout

    • VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR

  • 扩展 VkPresentModeKHR

    • VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR

    • VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_SHARED_PRESENT_SURFACE_CAPABILITIES_KHR

问题

1) 我们是否应该允许 Vulkan WSI 交换链在正常使用和共享呈现使用之间切换？

已解决：否。WSI 交换链通常使用新的属性重新创建，而不是更改其属性。这还可以节省资源，假设共享呈现需要更少的图像，并且假设大多数 VR 应用程序不需要在正常使用和共享使用之间切换。

2) 我们是否应该有一个查询来确定呈现引擎的刷新是如何触发的？

已解决：是。这是通过表面支持的呈现模式来实现的。

3) 表示共享可呈现图像的对象应该是一个 VkSwapchainKHR 的扩展还是一个单独的对象？

已解决：由于创建属性的重叠，以及为了允许共享和正常可呈现图像和交换链之间的通用功能，它是交换链的扩展。

4) 我们应该如何命名扩展及其创建的新结构？

已解决：共享可呈现图像 / 共享呈现。

5) VkSwapchainCreateInfoKHR 的 minImageCount 和 presentMode 值应该被忽略，还是需要兼容的值？

已解决：minImageCount 必须为 1，并且 presentMode 应设置为 VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR 或 VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR。

6) 共享可呈现图像的布局应该是什么？

已解决：在获取共享可呈现图像后，应用程序必须将其转换为 VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR 布局才能使用。在此初始转换之后，在交换链创建期间请求的任何图像使用都可以在图像上执行，而无需执行布局转换。

7) 我们是否需要一个新的 API 来触发刷新新内容？

已解决：使用 vkQueuePresentKHR 作为触发刷新的 API，因为这将允许与其他兼容的 vkQueuePresentKHR 扩展组合使用。

8) 在使用 VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR 呈现模式的交换链上，应用程序应该如何检测到 VK_ERROR_OUT_OF_DATE_KHR 错误？

已解决：引入 vkGetSwapchainStatusKHR，以允许应用程序查询使用共享呈现模式的交换链的状态。

9) 对于 VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR 交换链，后续调用 vkQueuePresentKHR 的定义应该是什么？

已解决：声明实现可以使用它作为更新内容的提示。

10) 共享可呈现图像的所有权可以转移到不同的队列吗？

已解决：否。在呈现之后，无法转移从使用 VK_SHARING_MODE_EXCLUSIVE 创建的交换链获得的共享可呈现图像的所有权。

11) 如果命令缓冲区使用来自 VK_ERROR_OUT_OF_DATE_KHR 交换链的图像，则 vkQueueSubmit 的行为应该是什么？

已解决：vkQueueSubmit 应该返回 VK_ERROR_DEVICE_LOST 错误。

12) Vulkan 能否保证渲染顺序，以实现光束追踪？

已解决：这可以通过使用渲染通道来确保条带渲染来实现。

版本历史

  • 修订版 1，2017-03-20 (Alon Or-bach)

    • 内部修订

VK_KHR_surface

名称字符串

VK_KHR_surface

扩展类型

实例扩展

注册扩展号

1

修订

25

批准状态

已批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2016-08-25

IP 状态

没有已知的 IP 声明。

贡献者

  • Patrick Doane, Blizzard

  • Ian Elliott, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

  • Faith Ekstrand, Intel

描述

VK_KHR_surface 扩展是一个实例扩展。它引入了 VkSurfaceKHR 对象，这些对象抽象了用于 Vulkan 的原生平台表面或窗口对象。它还提供了一种方法来确定物理设备中的队列族是否支持呈现到特定表面。

每个平台的单独扩展提供了创建 VkSurfaceKHR 对象的机制，但一旦创建，它们就可以在此和其他与平台无关的扩展中使用，特别是 VK_KHR_swapchain 扩展。

新的对象类型

新的命令

新的结构体

新的枚举

新的位掩码

新的枚举常量

  • VK_KHR_SURFACE_EXTENSION_NAME

  • VK_KHR_SURFACE_SPEC_VERSION

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_SURFACE_KHR

  • 扩展 VkResult

    • VK_ERROR_NATIVE_WINDOW_IN_USE_KHR

    • VK_ERROR_SURFACE_LOST_KHR

示例

在修订版 1.0.29 之后，VK_KHR_surface 和 VK_KHR_swapchain 扩展的示例代码已从附录中删除。此 WSI 示例代码已移植到官方 Khronos SDK 附带的立方体演示中，并在此位置保持更新（请参阅：https://github.com/KhronosGroup/Vulkan-Tools/blob/main/cube/cube.c）。

问题

1) 此扩展是否应包含一种方法来查询物理设备是否支持在给定平台上呈现到特定窗口或原生表面？

已解决：是。如果没有这个，应用程序将需要创建一个设备实例来确定是否可以将特定的窗口呈现到。知道一个设备总体上支持向平台呈现是不够的，因为一台机器可能支持多个座位，或使用不同底层物理平台的平台实例。此外，在某些平台上，例如 X Window System，不同的驱动程序和设备可能会用于不同的窗口，具体取决于它们在桌面的哪个部分上。

2) vkGetPhysicalDeviceSurfaceCapabilitiesKHR、vkGetPhysicalDeviceSurfaceFormatsKHR 和 vkGetPhysicalDeviceSurfacePresentModesKHR 函数是否应该在此扩展中操作物理设备，而不是在 VK_KHR_swapchain（即设备扩展）中并依赖于 VkDevice？

已解决：是。虽然依赖于 VkDevice（因此也依赖于启用的扩展和功能）进行查询可能很有用，但 Vulkan 仅发布了 VkPhysicalDevice 版本。许多情况可以通过“有效使用”语句来解决，或者通过给定扩展或参数的查询结构的单独的 pNext 链版本来解决，通过查询的可扩展版本：vkGetPhysicalDeviceSurfacePresentModes2EXT、vkGetPhysicalDeviceSurfaceCapabilities2KHR 和 vkGetPhysicalDeviceSurfaceFormats2KHR。

3) Vulkan 是否应支持 Xlib 或 XCB 作为访问 X Window System 平台的 API？

已解决：两者都支持。XCB 是一个更现代、更高效的 API，但 Xlib 的使用在许多应用程序中根深蒂固，并且在可预见的未来可能仍将继续使用。并非所有驱动程序都必须支持两者，但在核心规范中同时包含两者作为选项可能会鼓励支持，这反过来应该可以简化 Vulkan API 在较旧代码库中的采用。此外，XCB 可能实现的性能改进可能不会对 Vulkan 演示和此处定义的其他最小窗口系统交互的性能产生可衡量的影响。

4) GBM 平台是否应包含在平台枚举列表中？

已解决：推迟，将在未来编写的特定于平台的扩展中解决。

版本历史

  • 修订版 1，2015-05-20 (James Jones)

    • 基于 LunarG KHR 规范、其他 KHR 规范、附加到错误的补丁的初始草案。

  • 修订版 2，2015-05-22 (Ian Elliott)

    • 创建了初始的“描述”部分。

    • 删除了查询平台是否需要使用队列进行演示的查询，因为已决定演示将始终被建模为队列的一部分。

    • 修复了拼写错误和其他小错误。

  • 修订版 3，2015-05-26 (Ian Elliott)

    • 改进了“描述”部分。

  • 修订版 4，2015-05-27 (James Jones)

    • 修复了示例代码中的编译错误。

  • 修订版 5，2015-06-01 (James Jones)

    • 添加了问题 1 和 2 并进行了相关的规范更新。

  • 修订版 6，2015-06-01 (James Jones)

    • 将先前从 VK_KHR_swapchain 中删除的平台类型映射表与此规范中的平台描述表合并。

    • 添加了问题 3 和 4，记录了构建初始支持原生平台列表时做出的选择。

  • 修订版 7，2015-06-11 (Ian Elliott)

    • 根据 KHR TSG 的输入更新了表 1。

    • 根据与 Daniel Stone 的讨论更新了问题 4 (GBM)。他将在未来的某个时候创建一个特定于平台的扩展。

  • 修订版 8，2015-06-17 (James Jones)

    • 使用新约定更新了枚举扩展值。

    • 修复了 VK_SURFACE_PLATFORM_INFO_TYPE_SUPPORTED_KHR 的值。

  • 修订版 9，2015-06-17 (James Jones)

    • 基于 Vulkan API 版本 126 重新制定。

  • 修订版 10，2015-06-18 (James Jones)

    • 将问题 2 和 3 标记为已解决。

  • 修订版 11，2015-06-23 (Ian Elliott)

    • 示例现在显示了扩展函数使用函数指针。

    • 消除了多余的空格。

  • 修订版 12，2015-07-07 (Daniel Rakos)

    • 添加了错误部分，描述了预计报告每个错误的时间。

    • 在规范中将“队列节点索引”术语替换为“队列族索引”，因为这是在最新版本的核心头文件和规范中约定使用的术语。

    • 将 bool32_t 替换为 VkBool32。

  • 修订版 13，2015-08-06 (Daniel Rakos)

    • 根据最新的核心 API 头文件版本更新了规范。

  • 修订版 14，2015-08-20 (Ian Elliott)

    • 重命名了此扩展及其所有枚举、类型、函数等。这使其符合拟议的 Vulkan 扩展标准。

    • 从“修订版”切换到“版本”，包括在头文件中使用 VK_MAKE_VERSION 宏。

    • 进行了各种清理等操作。

  • 修订版 15，2015-08-20 (Ian Elliott—移植了 James Jones 于 2015-07-29 的更改)

    • 将表面变换枚举从 VK_WSI_swapchain 移动到此处，以便 VK_WSI_display 可以重用它们。

  • 修订版 16，2015-09-01 (James Jones)

    • 恢复了单字段修订号。

  • 修订版 17，2015-09-01 (James Jones)

    • 修复示例代码编译错误。

  • 修订版 18，2015-09-26 (Jesse Hall)

    • 将 VkSurfaceDescriptionKHR 替换为 VkSurfaceKHR 对象，该对象通过分层扩展创建。添加了 VkDestroySurfaceKHR。

  • 修订版 19，2015-09-28 (Jesse Hall)

    • 从 VK_EXT_KHR_swapchain 重命名为 VK_EXT_KHR_surface。

  • 修订版 20，2015-09-30 (Jeff Vigil)

    • 添加错误结果 VK_ERROR_SURFACE_LOST_KHR。

  • 修订版 21，2015-10-15 (Daniel Rakos)

    • 更新了问题 #2 的解决方案，并将表面功能查询包含在此扩展中。

    • 将 SurfaceProperties 重命名为 SurfaceCapabilities，因为它更好地反映了返回的值是特定设备上表面的功能。

    • 其他次要的清理和一致性更改。

  • 修订版 22，2015-10-26 (Ian Elliott)

    • 从 VK_EXT_KHR_surface 重命名为 VK_KHR_surface。

  • 修订版 23，2015-11-03 (Daniel Rakos)

    • 向 vkDestroySurfaceKHR 添加了分配回调。

  • 修订版 24，2015-11-10 (Jesse Hall)

    • 删除了 VkSurfaceTransformKHR。请改用 VkSurfaceTransformFlagBitsKHR。

    • 将 VkSurfaceCapabilitiesKHR 成员 maxImageArraySize 重命名为 maxImageArrayLayers。

  • 修订版 25，2016-01-14 (James Jones)

    • 将 VK_ERROR_NATIVE_WINDOW_IN_USE_KHR 从 VK_KHR_android_surface 移动到 VK_KHR_surface 扩展。

  • 2016-08-23 (Ian Elliott)

    • 更新了示例代码，以减少每行字符数，并拆分出一个新的示例来演示如何获取函数指针。

  • 2016-08-25 (Ian Elliott)

    • 在示例代码的开头添加了一个注释，声明它将从附录的未来版本中删除。

VK_KHR_surface_protected_capabilities

名称字符串

VK_KHR_surface_protected_capabilities

扩展类型

实例扩展

注册扩展号

240

修订

1

批准状态

已批准

扩展和版本依赖关系

Vulkan 版本 1.1
和
VK_KHR_get_surface_capabilities2

联系方式

其他扩展元数据

上次修改日期

2018-12-18

IP 状态

没有已知的 IP 声明。

贡献者

  • Sandeep Shinde，NVIDIA

  • James Jones, NVIDIA

  • Daniel Koch, NVIDIA

描述

此扩展扩展了 VkSurfaceCapabilities2KHR，为应用程序提供了一种查询是否可以使用设置的 VK_SWAPCHAIN_CREATE_PROTECTED_BIT_KHR 标志创建交换链的方法。

Vulkan 1.1 添加了对保护内存和保护资源（包括缓冲区 (VK_BUFFER_CREATE_PROTECTED_BIT)、图像 (VK_IMAGE_CREATE_PROTECTED_BIT) 和交换链 (VK_SWAPCHAIN_CREATE_PROTECTED_BIT_KHR)）的可选支持。但是，在支持多个窗口系统的实现上，并非所有窗口系统都可能能够提供受保护的显示路径。

此扩展提供了一种查询是否可以显示为表面（因此是特定窗口系统）创建的受保护交换链的方法。它使用新的 VkSurfaceProtectedCapabilitiesKHR 结构扩展了现有的 VkSurfaceCapabilities2KHR 结构，应用程序可以从中通过 vkGetPhysicalDeviceSurfaceCapabilities2KHR 获取有关支持创建受保护交换链的信息。

新结构

新枚举常量

  • VK_KHR_SURFACE_PROTECTED_CAPABILITIES_EXTENSION_NAME

  • VK_KHR_SURFACE_PROTECTED_CAPABILITIES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_SURFACE_PROTECTED_CAPABILITIES_KHR

版本历史

  • 修订版 1，2018-12-18 (Sandeep Shinde, Daniel Koch)

    • 内部修订。

VK_KHR_swapchain

名称字符串

VK_KHR_swapchain

扩展类型

设备扩展

注册扩展号

2

修订

70

批准状态

已批准

扩展和版本依赖关系

VK_KHR_surface

API 交互

  • 与 VK_VERSION_1_1 交互

联系方式

其他扩展元数据

上次修改日期

2017-10-06

IP 状态

没有已知的 IP 声明。

交互和外部依赖

  • 与 Vulkan 1.1 交互

贡献者

  • Patrick Doane, Blizzard

  • Ian Elliott, LunarG

  • Jesse Hall, Google

  • Mathias Heyer，NVIDIA

  • James Jones, NVIDIA

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

  • Faith Ekstrand, Intel

  • Matthaeus G. Chajdas, AMD

  • Ray Smith, ARM

描述

VK_KHR_swapchain 扩展是设备级的伴侣扩展，对应于 VK_KHR_surface 扩展。它引入了 VkSwapchainKHR 对象，这些对象提供了将渲染结果呈现到表面的能力。

新对象类型

新命令

如果支持 Vulkan 版本 1.1

新结构

如果支持 Vulkan 版本 1.1

新枚举

如果支持 Vulkan 版本 1.1

新位掩码

如果支持 Vulkan 版本 1.1

新枚举常量

  • VK_KHR_SWAPCHAIN_EXTENSION_NAME

  • VK_KHR_SWAPCHAIN_SPEC_VERSION

  • 扩展 VkImageLayout

    • VK_IMAGE_LAYOUT_PRESENT_SRC_KHR

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_SWAPCHAIN_KHR

  • 扩展 VkResult

    • VK_ERROR_OUT_OF_DATE_KHR

    • VK_SUBOPTIMAL_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PRESENT_INFO_KHR

    • VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR

如果支持 Vulkan 版本 1.1

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ACQUIRE_NEXT_IMAGE_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_SWAPCHAIN_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_SWAPCHAIN_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_IMAGE_SWAPCHAIN_CREATE_INFO_KHR

  • 扩展 VkSwapchainCreateFlagBitsKHR

    • VK_SWAPCHAIN_CREATE_PROTECTED_BIT_KHR

    • VK_SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR

问题

1) 此扩展是否允许应用程序指定可呈现图像的内存后备？

已解决：否。与标准图像不同，实现将分配可呈现图像的内存后备。

2) 可呈现图像允许执行哪些操作？

已解决：这由创建可呈现图像的交换链时指定的图像使用标志确定。

3) 此扩展是否支持 MSAA 可呈现图像？

已解决：否。可呈现图像始终是单采样的。多采样渲染必须使用常规图像。要呈现渲染结果，应用程序必须在呈现之前手动将多采样图像解析为单采样可呈现图像。

4) 此扩展是否支持立体/多视图可呈现图像？

已解决：是。与可呈现图像关联的视图数量由创建交换链时指定的 imageArrayLayers 确定。给定交换链中的所有可呈现图像都使用相同的大小。

5) 立体可呈现图像的图层是否是半尺寸的？

已解决：否。图像范围始终与应用程序请求的范围匹配。

6) “呈现”和“获取下一图像”命令是否在队列上操作？如果不是，它们是否需要包含显式信号量对象以使它们与队列操作互锁？

已解决: 当前命令作用于一个队列。它所代表的图像所有权操作会按顺序与队列上的其他操作一起执行，因此不需要显式的信号量对象来同步其动作。

应用程序可能希望在与管理队列的线程不同的线程中，或在多个线程中获取下一个图像。为了使这种使用更容易，获取下一个图像命令使用一个信号量来作为显式同步的方法进行信号通知。应用程序稍后必须在队列中使用该图像的任何命令之前，将等待此信号量的操作排入队列。

7) 如果没有可用的图像，vkAcquireNextImageKHR 是否会阻塞？

已解决: 该命令接受一个超时参数。超时的特殊值为 0，这使调用成为非阻塞操作，UINT64_MAX 则无限期阻塞。介于两者之间的值将阻塞至指定的时间。当图像可用或发生错误时，调用将返回。如果交换链过时，它可能会（但不是必须的）在指定的超时时间到期之前返回。

8) 可以使用一个 vkQueuePresentKHR 调用排队多个呈现吗？

已解决: 可以。VkPresentInfoKHR 包含一个交换链列表和将要呈现的相应图像索引。如果支持，则使用单个 vkQueuePresentKHR 调用排队的所有呈现将作为一个操作以原子方式应用。同一个交换链在列表中不能出现多次。以后的扩展可能会为这种呈现操作提供更强的原子性保证，和/或允许它们查询是否可以原子地呈现特定组的交换链。

9) 呈现和获取下一个图像函数如何通知应用程序目标表面已更改？

已解决: 为此引入了两个新的结果代码

  • VK_SUBOPTIMAL_KHR - 呈现仍然会成功，但受窗口调整大小行为的影响，交换链不再针对其目标表面进行最佳配置。应用程序应查询更新的表面信息，并在下一个方便的时机重新创建其交换链。

  • VK_ERROR_OUT_OF_DATE_KHR - 失败。交换链不再与其目标表面兼容。应用程序必须查询更新的表面信息，并在呈现成功之前重新创建交换链。

vkAcquireNextImageKHR 和 vkQueuePresentKHR 都可以返回这些结果。

10) vkAcquireNextImageKHR 命令是通过输出参数向应用程序返回信号量，还是接受应用程序作为对象句柄参数来信号通知的信号量？

已解决: 接受作为对象句柄来信号通知的信号量。这避免了需要指定应用程序是否必须销毁信号量，或者该信号量是否归交换链所有，以及如果属于后者，它的生命周期是什么，以及在从 vkAcquireNextImageKHR 接收到后是否可以将其重用于其他操作。

11) 应该公开哪些类型的交换链队列行为？选项包括交换间隔规范、邮箱/最近与 FIFO 队列管理、针对特定垂直消隐间隔或给定呈现操作的绝对时间，以及其他可能的情况。对于其中一些，需要在交换链创建时指定还是作为每个呈现的参数来指定也需要确定。

已解决: 基本交换链扩展将公开 3 种可能的行为（其中，始终支持 FIFO）

  • 立即呈现：不等待垂直消隐期来更新当前图像，很可能导致可见的撕裂。不使用内部队列。呈现请求会立即应用。

  • 邮箱队列：等待下一个垂直消隐期来更新当前图像。不应观察到撕裂。使用内部单项队列来保存挂起的呈现请求。如果当接收到新的呈现请求时队列已满，则新请求会替换现有条目，并且与先前条目关联的任何图像都可供应用程序重用。

  • FIFO 队列：等待下一个垂直消隐期来更新当前图像。不应观察到撕裂。使用一个包含 numSwapchainImages - 1 个条目的内部队列来保存挂起的呈现请求。新请求追加到队列的末尾，并且在队列不为空的每个垂直消隐期中，从队列开头删除一个请求并进行处理。

并非所有表面都支持所有这些模式，因此将使用表面信息查询返回支持的模式。所有表面都必须支持 FIFO 队列模式。应用程序在创建交换链时必须预先选择其中一种模式。可以通过重新创建交换链来实现切换模式。

12) VK_PRESENT_MODE_MAILBOX_KHR 是否可以为 vkAcquireNextImageKHR 提供非阻塞保证？ 如果是，正确的标准是什么？

已解决: 可以。这里的困难并非显而易见。粗略地说，如果请求至少 3 个图像，则如果应用程序在调用 vkAcquireNextImageKHR 时未拥有任何图像，则邮箱模式应该始终为应用程序提供一个可用的图像。但是，某些呈现引擎可能具有多个“当前”图像，并且在某些情况下仍然需要阻塞。正确的条件似乎是，如果应用程序分配了表面的最小图像数量 + 1，则当它当前未拥有任何图像时，保证其非阻塞行为。

13) 是否有一种方法可以为生成 VK_SUBOPTIMAL_KHR 返回代码的表面创建和初始化新的交换链，同时仍然使用旧的交换链？

已解决: 不作为此规范的一部分。这可能有助于允许应用程序创建“最佳”替换交换链，并在后台线程中使用它以低优先级重建所有命令缓冲区，同时继续在主线程中使用“次优”交换链。它可以使用与重新创建直接到设备交换链而不会导致模式切换的相同的“原子替换”语义。但是，经过讨论，确定某些平台可能无法支持同一表面的并发交换链，因此这将从基本 KHR 扩展中删除。将来的扩展可以为支持它的平台添加此功能。

14) VkSurfaceCapabilitiesKHR::maxImageCount 是否应该有一个特殊值来指示交换链中的图像数量没有实际限制？

已解决：是的。通常情况下，交换链中的图像数量实际上没有限制，除了系统中可用的资源（即内存）之外。尝试从诸如内存大小之类的因素推导出硬性限制是容易失败的。在这种情况下，最好让应用程序通过试错迭代来找出这些软限制。

15) VkSurfaceCapabilitiesKHR::currentExtent 是否应该有一个特殊值来表示平台表面的大小是未定义的？

已解决：是的。在某些平台上（例如 Wayland），表面大小由呈现给它的图像定义，而不是反过来。

16) VkSurfaceCapabilitiesKHR::maxImageExtent 是否应该有一个特殊值来表示表面大小实际上没有限制？

已解决：否。似乎不太可能存在这样的系统。可以使用 0 来表示平台对范围没有限制，除了 Vulkan 对普通图像施加的限制之外，但是此查询同样可以返回相同的限制，因此对于此字段来说，特殊的“无限制”值似乎没有用处。

17) 应如何向应用程序公开表面旋转和镜像？它们如何指定在呈现之前应用的旋转和镜像变换？

已解决：应用程序可以查询表面的支持变换和当前变换。两者都是相对于设备的“自然”显示旋转和方向指定的。支持的变换指示呈现引擎接受图像的方向。例如，一个不支持在呈现时转换表面的呈现引擎，并且正在呈现到一个以 90 度旋转显示的表面，将只返回一个支持的变换位：VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR。应用程序必须在创建交换链时，通过 preTransform 字段指定变换，并根据该变换进行渲染。

18) 表面是否可以不支持 VK_MIRROR_NONE？它们是否可以同时支持垂直和水平镜像？相关地，VK_MIRROR_NONE[_BIT] 应该是零还是位 1，并且是否允许应用程序指定多个预先和当前的镜像变换位，还是恰好一个？

已解决：由于某些平台可能不支持使用非原生窗口当前变换的其他变换进行呈现，并且预旋转/镜像是相对于设备的自然旋转和方向指定的，而不是相对于表面的当前旋转和方向，因此有必要表达对不镜像的支持不足。为了允许这样做，MIRROR_NONE 枚举必须在标志中占用一位。由于 MIRROR_NONE 必须是位掩码中的一位，而不是没有设置值的位掩码，因此允许在位掩码中设置多个位会使其可以描述未定义的变换，例如 VK_MIRROR_NONE_BIT | VK_MIRROR_HORIZONTAL_BIT，或同时包含“不镜像”和“水平镜像”的变换。因此，最好只允许使用一个位来指定所有支持的镜像变换。那么问题就变成了，是否应该有一个 VK_MIRROR_HORIZONTAL_AND_VERTICAL_BIT 来表示同时的水平和垂直镜像变换？但是，这样的变换等效于 180 度旋转，因此希望支持或使用此类变换的呈现引擎和应用程序可以通过旋转来表达它。因此，3 个互斥的位足以表达所有需要的镜像变换。

19) 是否应该要求支持 sRGB？

已解决：在 UHD 和 HDR 显示设备出现之后，正确的色彩空间信息对于交换链所代表的显示流水线至关重要。应用程序可以发现支持的格式/色彩空间对，并选择最适合其渲染需求的一对。目前仅支持 sRGB 色彩空间，未来的扩展可能会提供对更多色彩空间的支持。请参阅问题 23 和 24。

20) 是否存在使用针对同一表面的新交换链来修改或替换现有交换链的机制？

已解决：是的。这在上面的文本中进行了描述。

21) 在使用 Vulkan 交换链呈现时，是否应该有一种方法可以使用本机 API 设置预旋转和镜像？

已解决：是的。此扩展中可以表达的变换是本机平台上可能实现的变换的子集。如果平台公开一种使用本机方法为给定表面指定呈现图像的变换的方法，并且公开比 Vulkan 支持的更多变换或其他表面属性，则可能无法、难以或不方便使用 Vulkan KHR 扩展来设置某些属性，而使用本机接口来设置另一些属性。为了避免在使用 Vulkan 交换链呈现时覆盖使用本机命令设置的属性，应用程序可以将预变换设置为“继承”，在这种情况下将使用当前本机属性，如果没有任何可用属性，则将使用特定于平台的默认属性。未指定合理的默认值或未提供本机机制来指定此类变换的平台不应在其在 VkSurfaceCapabilitiesKHR 中返回的 supportedTransforms 位掩码中包含继承位。

22) 可呈现图像的内容是否应被遮挡其目标表面的对象裁剪？

已解决：应用程序可以选择他们喜欢的行为。允许裁剪内容可能会在某些平台上实现更高效的呈现方法，但是某些应用程序可能依赖于可呈现图像的内容来执行诸如部分更新或运动模糊之类的技术。

23) 在创建交换链时，指定 VkColorSpaceKHR 以及 VkFormat 的目的是什么？

已解决：虽然 Vulkan 本身与色彩空间无关（例如，即使 R、G、B 和 A 的含义也可以由渲染应用程序自由定义），但交换链最终必须在具有特定颜色再现特性的显示设备上呈现图像。如果需要在显示图像之前进行任何色彩空间转换，则交换链必须知道呈现图像的色彩空间。交换链将仅支持一组受限制的颜色格式和空间对。可以通过 vkGetPhysicalDeviceSurfaceFormatsKHR 发现此集合。由于可以预期大多数显示设备都支持 sRGB 色彩空间，因此必须至少公开一对格式/色彩空间，其中色彩空间为 VK_COLOR_SPACE_SRGB_NONLINEAR_KHR。

24) sRGB 格式和 sRGB 色彩空间之间有什么关系？

已解决：虽然 Vulkan 公开了很多 SRGB 纹理格式，但是使用这些格式并不能保证在特定的色彩空间中工作。它仅仅意味着硬件可以直接支持在读取或写入这些格式的图像时应用 sRGB 标准色彩空间定义的非线性传递函数。尽管如此，交换链不太可能公开 *_SRGB 格式以及除 VK_COLOR_SPACE_SRGB_NONLINEAR_KHR 以外的任何色彩空间。

另一方面，非 *_SRGB 格式很可能与 SRGB 色彩空间配对公开。这意味着，硬件在读取或写入此类图像时不会应用任何传递函数，但它们仍将在具有 sRGB 显示特性的设备上呈现。在这种情况下，应用程序负责应用传递函数，例如通过使用着色器数学。

25) 表面和针对它们的交换链的生命周期之间有什么关系？

已解决：表面必须比针对它的任何交换链都更长寿。VkSurfaceKHR 拥有本机窗口与 Vulkan 驱动程序的绑定。

26) 应用程序如何控制在合成过程中，演示引擎处理交换链图像的 Alpha 分量的方式？

已解决：我们应该添加新的枚举值，以允许应用程序与演示引擎协商在合成过程中如何处理图像 Alpha 值。由于并非所有平台都能通过 Vulkan 驱动程序实际控制这一点，因此提供了 VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR 值，就像用于表面变换一样。

27) vkCreateSwapchainKHR 是否是返回 VK_ERROR_NATIVE_WINDOW_IN_USE_KHR 的正确函数，或者各种特定于平台的 VkSurfaceKHR 工厂函数是否应该更早地捕获此错误？

已解决：对于大多数平台，VkSurfaceKHR 结构是一个简单的容器，其中包含标识本机窗口或代表特定平台上表面的其他对象的数据。为了让表面工厂函数返回此错误，它们可能需要以某种方式在本机显示服务器上注册对本机对象的引用，并确保不存在其他此类引用。表面的目的不是那么重量级。

交换链旨在直接操作本机窗口并与本机演示机制通信的对象。交换链已经需要与本机显示服务器通信，以协商本机表面的可呈现图像的分配和/或演示。因此，在交换链创建时强制执行本机对象独占性更有意义。如果特定平台上的要求有意义，平台可以选择对为同一本机窗口创建的 VkSurfaceKHR 对象数量强制执行进一步的限制，但全局要求仅在交换链级别才合理。

示例

在 1.0.29 版本之后，VK_KHR_surface 和 VK_KHR_swapchain 扩展的示例代码已从附录中删除。此 WSI 示例代码已移植到官方 Khronos SDK 附带的 cube 演示中，并在该位置保持更新（请参阅：https://github.com/KhronosGroup/Vulkan-Tools/blob/main/cube/cube.c）。

版本历史

  • 修订版 1，2015-05-20 (James Jones)

    • 基于 LunarG KHR 规范、其他 KHR 规范、附加到错误的补丁的初始草案。

  • 修订版 2，2015-05-22 (Ian Elliott)

    • 从 2015-05-21 KHR TSG 会议中进行了许多达成一致的更改。这包括仅使用一个队列进行演示，并使用显式函数来获取下一个图像。

    • 修复了拼写错误和其他小错误。

  • 修订版 3，2015-05-26 (Ian Elliott)

    • 改进了“描述”部分。

    • 添加或解决了在改进描述时发现的问题。例如，始终使用 pSurfaceDescription，而不是有时使用 pSurface。

  • 修订版 4，2015-05-27 (James Jones)

    • 修复了一些语法错误和拼写错误

    • 填写了创建交换链时 imageUseFlags 的描述。

    • 添加了 swapInterval 的描述。

    • 替换了描述队列上图像所有权和演示操作顺序的段落。

  • 修订版 5，2015-05-27（James Jones）

    • 从（已放弃的）vk_wsi_persistent_swapchain_images 扩展导入了相关问题。

    • 添加了关于获取下一个图像和演示命令相对于队列的行为的问题 6 和 7。

    • 更新了规范语言和示例，以与针对问题 6 和 7 的拟议解决方案保持一致。

  • 修订版 6，2015-05-27（James Jones）

    • 添加了关于多个交换链的原子演示的问题 8

    • 更新了规范语言和示例，以与针对问题 8 的拟议解决方案保持一致。

  • 修订版 7，2015-05-27（James Jones）

    • 修复了示例代码中的编译错误，并进行了相关的规范修复。

  • 修订版 8，2015-05-27（James Jones）

    • 添加了问题 9 和相关的 VK_SUBOPTIMAL_KHR 结果代码。

    • 将 VK_OUT_OF_DATE_KHR 重命名为 VK_ERROR_OUT_OF_DATE_KHR。

  • 修订版 9，2015-05-27（James Jones）

    • 对一些 XXX 问题/问题添加了内联的拟议解决方案（标记为 [JRJ]）。如果采用这些建议，则应在后续更新中将这些建议移至问题部分。

  • 修订版 10，2015-05-28（James Jones）

    • 将 vkAcquireNextImageKHR 恢复为非队列操作，该操作使用 VkSemaphore 对象进行显式同步。

    • 添加了问题 10，以确定 vkAcquireNextImageKHR 是否生成或返回信号量，或者它是否对应用程序提供的信号量进行操作。

  • 修订版 11，2015-05-28（James Jones）

    • 将问题 6、7 和 8 标记为已解决。

    • 将 VkSurfaceCapabilityPropertiesKHR 重命名为 VkSurfacePropertiesKHR，以更好地传达其包含的信息的可变性。

  • 修订版 12，2015-05-28（James Jones）

    • 添加了带有拟议解决方案的问题 11 和相关的问题 12。

    • 更新了规范的各个部分，以匹配针对问题 11 的拟议解决方案。

  • 修订版 13，2015-06-01（James Jones）

    • 将一些结构移至 VK_EXT_KHR_swap_chain 以解决规范的问题 1 和 2。

  • 修订版 14，2015-06-01（James Jones）

    • 为示例 4 添加了代码，演示了应用程序如何利用两个不同的演示和获取下一个图像 KHR 结果代码。

    • 添加了问题 13。

  • 修订版 15，2015-06-01（James Jones）

    • 添加了问题 14 - 16 和相关的规范语言。

    • 修复了一些拼写错误。

    • 添加了描述 vkAcquireNextImageKHR 和 vkQueuePresentKHR 有意义的返回值的语言。

  • 修订版 16，2015-06-02（James Jones）

    • 添加了问题 17 和 18，以及相关的规范语言。

    • 删除了上次更新中错误添加的一些文本。

  • 修订版 17，2015-06-15（Ian Elliott）

    • 将特殊值从“-1”更改为“0”，以便数据类型可以是无符号的。

  • 修订版 18，2015-06-15（Ian Elliott）

    • 澄清了 VkSurfacePropertiesKHR::minImageCount 的值和 vkAcquireNextImageKHR 函数的超时参数。

  • 修订版 19，2015-06-17（James Jones）

    • 杂项清理。删除了已解决的内联问题并修复了拼写错误。

    • 修复了版本 18 中对 VkSurfacePropertiesKHR::minImageCount 的澄清。

    • 在规范中使用的术语列表中添加了简短的“图像所有权”定义。

  • 修订版 20，2015-06-17（James Jones）

    • 使用新约定更新了枚举扩展值。

  • 修订版 21，2015-06-17（James Jones）

    • 添加了描述如何使用 VK_IMAGE_LAYOUT_PRESENT_SOURCE_KHR 的语言。

    • 清理了关于 vkQueuePresentKHR 可以用于哪些队列的描述的 XXX 注释。

  • 修订版 22，2015-06-17（James Jones）

    • 基于 Vulkan API 版本 126 重新制定。

  • 修订版 23，2015-06-18（James Jones）

    • 更新了问题 12 的语言，以作为拟议的解决方案读取。

    • 将问题 11、12、13、16 和 17 标记为已解决。

    • 暂时在剩余的未解决问题下添加了指向相关错误的链接。

    • 添加了问题 19 和 20 以及拟议的解决方案。

  • 修订版 24，2015-06-19（Ian Elliott）

    • 将 VkSurfacePropertiesKHR::currentExtent 的特殊值从“0”改回“-1”。此值永远不需要是无符号的，“0”实际上是合法值。

  • 修订版 25，2015-06-23（Ian Elliott）

    • 示例现在显示了扩展函数使用函数指针。

    • 消除了多余的空格。

  • 修订版 26，2015-06-25（Ian Elliott）

    • 根据 KHR TSG 会议解决了问题 9 和 10。

  • 修订版 27，2015-06-25（James Jones）

    • 将 oldSwapchain 成员添加到 VkSwapchainCreateInfoKHR。

  • 修订版 28，2015-06-25（James Jones）

    • 将“继承”位添加到旋转和镜像标志以及相关问题 21。

  • 修订版 29，2015-06-25（James Jones）

    • 将“clipped”标志添加到 VkSwapchainCreateInfoKHR 以及相关问题 22。

    • 指定演示图像不会修改它。

  • 修订版 30，2015-06-25（James Jones）

    • 规范中添加了语言，阐明了当 VkSwapchainCreateInfoKHR 的 oldSwapchain 字段不为 NULL 时 vkCreateSwapchainKHR() 的行为。

  • 修订版 31，2015-06-26 (Ian Elliott)

    • 新的 VkSwapchainCreateInfoKHR 成员“oldSwapchain”和“clipped”的示例。

    • 使用 VkSurfacePropertiesKHR::{min|max}ImageCount 设置 VkSwapchainCreateInfoKHR::minImageCount 的示例。

    • 为了与其他函数保持一致，将 vkGetSurfaceInfoKHR() 的第 4 个参数重命名为 “pDataSize”。

    • 添加带有扩展 C 字符串名称的宏（仅限头文件）。

  • 修订版 32，2015-06-26 (James Jones)

    • 对描述“oldSwapchain”行为的语言进行了细微调整。

    • 修正了我之前两次更新的版本日期。

  • 修订版 33，2015-06-26 (Jesse Hall)

    • 向 VkSwapchainCreateInfoKHR 添加了使用标志。

  • 修订版 34，2015-06-26 (Ian Elliott)

    • 为了与其他函数保持一致，将 vkQueuePresentKHR() 的第 2 个参数重命名为 “pPresentInfo”。

  • 修订版 35，2015-06-26 (Faith Ekstrand)

    • 将 VkRotationFlagBitsKHR 和 VkMirrorFlagBitsKHR 枚举合并为一个 VkSurfaceTransformFlagBitsKHR 枚举。

  • 修订版 36，2015-06-26 (Faith Ekstrand)

    • 添加了非位掩码的 VkSurfaceTransformKHR 枚举。VkSurfaceTransformKHR 中的每个值都直接对应于 VkSurfaceTransformFlagBitsKHR 中的一个位，因此从一个转换为另一个很容易。拥有单独的枚举意味着 currentTransform 和 preTransform 现在在定义上是明确的。

  • 修订版 37，2015-06-29 (Ian Elliott)

    • 更正了 vkAcquireNextImageKHR 的一个签名，该签名的最后两个参数与规范和头文件中的其他位置相反。

  • 修订版 38，2015-06-30 (Ian Elliott)

    • 更正了 vkGetSwapchainInfoKHR() 函数描述中的一个错别字。

    • 更正了 VkPresentInfoKHR::sType 的头文件注释中的一个错别字。

  • 修订版 39，2015-07-07 (Daniel Rakos)

    • 添加了错误部分，描述了预计报告每个错误的时间。

    • 将 bool32_t 替换为 VkBool32。

  • 修订版 40，2015-07-10 (Ian Elliott)

    • 更新为与 `vulkan.h` 头的 138 版本一起使用。这包括使用新的 VK_DEFINE_NONDISP_HANDLE 宏声明 VkSwapchainKHR 类型，并且不再扩展 VkObjectType（已消除）。

  • 修订版 41 2015-07-09 (Mathias Heyer)

    • 添加了颜色空间语言。

  • 修订版 42，2015-07-10 (Daniel Rakos)

    • 更新了查询机制以反映核心规范中所做的约定更改。

    • 从 VK_STRUCTURE_TYPE_QUEUE_PRESENT_INFO_KHR 的名称中删除了“queue”，以与已建立的命名约定保持一致。

    • 删除了对不再存在的 VkObjectType 枚举的引用。

  • 修订版 43，2015-07-17 (Daniel Rakos)

    • 添加了对跨队列族并发共享交换链图像的支持。

    • 根据最近的更改更新了示例代码

  • 修订版 44，2015-07-27 (Ian Elliott)

    • 指出需要支持 VK_PRESENT_MODE_FIFO_KHR。也就是说，ICD 可以选择性地支持 IMMEDIATE 和 MAILBOX，但必须支持 FIFO。

  • 修订版 45，2015-08-07 (Ian Elliott)

    • 更正了规范文件中的一个错别字（VkSwapchainCreateInfoKHR 结构的 imageColorSpace 成员的类型和变量名称的大小写错误）。

    • 更正了头文件中的一个错别字（PFN_vkGetSurfacePropertiesKHR 中的最后一个参数的类型末尾缺少 “KHR”：VkSurfacePropertiesKHR）。

  • 修订版 46，2015-08-20 (Ian Elliott)

    • 重命名了此扩展及其所有枚举、类型、函数等。这使其符合拟议的 Vulkan 扩展标准。

    • 从“修订版”切换到“版本”，包括在头文件中使用 VK_MAKE_VERSION 宏。

    • 对几个描述进行了改进。

    • 将几个问题的状态从 PROPOSED 更改为 RESOLVED，没有留下未解决的问题。

    • 解决了几个 TODO，进行了杂项清理等。

  • 修订版 47，2015-08-20 (Ian Elliott——移植了 James Jones 于 2015-07-29 的更改)

    • 将表面变换枚举移动到 VK_WSI_swapchain，以便 VK_WSI_display 可以重用它们。

  • 修订版 48，2015-09-01 (James Jones)

    • 各种小的清理。

  • 修订版 49，2015-09-01 (James Jones)

    • 恢复了单字段修订号。

  • 修订版 50，2015-09-01 (James Jones)

    • 更新示例 #4 以包含说明如何使用 oldSwapchain 字段的代码。

  • 修订版 51，2015-09-01 (James Jones)

    • 修复示例代码编译错误。

  • 修订版 52，2015-09-08 (Matthaeus G. Chajdas)

    • 更正了一个错别字。

  • 修订版 53，2015-09-10 (Alon Or-bach)

    • 从 VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR 中删除了 SWAP_CHAIN 中的下划线。

  • 修订版 54，2015-09-11 (Jesse Hall)

    • 描述了图像转换到 VK_IMAGE_LAYOUT_PRESENT_SOURCE_KHR 和从 VK_IMAGE_LAYOUT_PRESENT_SOURCE_KHR 转换的执行和内存一致性要求。

  • 修订版 55，2015-09-11 (Ray Smith)

    • 添加了销毁和将内存绑定到可呈现图像的错误。

  • 修订版 56，2015-09-18 (James Jones)

    • 向 vkAcquireNextImageKHR 添加了栅栏参数。

    • 添加了如何根据演示速率计量主机线程的示例。

  • 修订版 57，2015-09-26 (Jesse Hall)

    • 将 VkSurfaceDescriptionKHR 替换为 VkSurfaceKHR。

    • 添加了第 25 号问题及其商定的解决方案。

  • 修订版 58，2015-09-28 (Jesse Hall)

    • 从 VK_EXT_KHR_device_swapchain 重命名为 VK_EXT_KHR_swapchain。

  • 修订版 59，2015-09-29 (Ian Elliott)

    • 将 vkDestroySwapchainKHR() 更改为返回 void。

  • 修订版 60，2015-10-01 (Jeff Vigil)

    • 添加了错误结果 VK_ERROR_SURFACE_LOST_KHR。

  • 修订版 61，2015-10-05 (Faith Ekstrand)

    • 添加了 VkCompositeAlpha 枚举和相应的结构字段。

  • 修订版 62，2015-10-12 (Daniel Rakos)

    • 添加了 VK_PRESENT_MODE_FIFO_RELAXED_KHR。

  • 修订版 63，2015-10-15 (Daniel Rakos)

    • 将表面功能查询移动到 VK_EXT_KHR_surface。

  • 修订版 64，2015-10-26 (Ian Elliott)

    • 从 VK_EXT_KHR_swapchain 重命名为 VK_KHR_swapchain。

  • 修订版 65，2015-10-28 (Ian Elliott)

    • 向 VkPresentInfoKHR 添加了可选的 pResult 成员，以便可以从 vkQueuePresentKHR() 获取每个交换链的结果。

  • 修订版 66，2015-11-03 (Daniel Rakos)

    • 向创建和销毁函数添加了分配回调。

    • 更新了资源转换语言。

    • 更新了示例代码。

  • 修订版 67，2015-11-10 (Jesse Hall)

    • 向 VkSwapchainCreateInfoKHR 添加了保留标志位掩码。

    • 修改了命名和成员排序以匹配 API 样式约定，因此 VkSwapchainCreateInfoKHR 图像属性成员镜像了相应的 VkImageCreateInfo 成员，但带有“image”前缀。

    • 使 VkPresentInfoKHR::pResults 为非 const；它是一个输出数组参数。

    • 使 vkQueuePresentKHR 的 pPresentInfo 参数为 const。

  • 修订版 68，2016-04-05 (Ian Elliott)

    • 将 vkAcquireNextImage 的“validity”包含移动到其正确位置，即在原型和参数列表之后。

    • 阐明了关于可呈现图像的语言，包括如何获取它们、应用程序何时可以使用和不能使用它们等。作为此过程的一部分，删除了关于可呈现图像“所有权”的语言，并用关于应用程序“获取”可呈现图像的更一致的语言替换它。

  • 2016-08-23 (Ian Elliott)

    • 更新示例代码，以使用最终的 API 命令名称，减少每行的字符数，并拆分出一个新的示例来演示如何获取函数指针。此代码与 LunarG “cube”演示程序更相似。

  • 2016-08-25 (Ian Elliott)

    • 在示例代码的开头添加了一个注释，声明它将从附录的未来版本中删除。

  • 修订版 69，2017-09-07 (Tobias Hector)

    • 添加了与 Vulkan 1.1 的交互。

  • 修订版 70，2017-10-06 (Ian Elliott)

    • 更正了与 Vulkan 1.1 的交互。

VK_KHR_swapchain_mutable_format

名称字符串

VK_KHR_swapchain_mutable_format

扩展类型

设备扩展

注册扩展号

201

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_swapchain
和
     VK_KHR_maintenance2
    或
     Vulkan 版本 1.1
和
     VK_KHR_image_format_list
    或
     Vulkan 版本 1.2

联系方式

其他扩展元数据

上次修改日期

2018-03-28

IP 状态

没有已知的 IP 声明。

贡献者

  • Faith Ekstrand, Intel

  • Jan-Harald Fredriksen, ARM

  • Jesse Hall, Google

  • Daniel Rakos, AMD

  • Ray Smith, ARM

描述

此扩展允许以与窗口系统使用的格式不同的格式处理交换链图像，这对于在 sRGB 和线性 RGB 格式之间切换特别有用。

它添加了一个新的交换链创建标志，允许从可呈现图像创建具有与用于创建交换链的格式不同的图像视图。

新枚举常量

  • VK_KHR_SWAPCHAIN_MUTABLE_FORMAT_EXTENSION_NAME

  • VK_KHR_SWAPCHAIN_MUTABLE_FORMAT_SPEC_VERSION

  • 扩展 VkSwapchainCreateFlagBitsKHR

    • VK_SWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR

问题

1) 是否需要任何新的功能？

已解决：否。期望所有公开此扩展的实现都支持交换链图像格式的可变性。

2) 我们是否需要单独的 VK_SWAPCHAIN_CREATE_EXTENDED_USAGE_BIT_KHR？

已解决：否。此扩展需要 VK_KHR_maintenance2，并且使用 VK_SWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR 创建的交换链的可呈现图像在内部以等效于同时指定 VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT 和 VK_IMAGE_CREATE_EXTENDED_USAGE_BIT_KHR 的方式创建。

3) 我们是否需要单独的结构来允许为交换链指定图像格式列表？

已解决：否。我们直接使用由 VK_KHR_image_format_list 引入的相同的 VkImageFormatListCreateInfoKHR 结构。对于使用 VK_SWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR 创建的交换链，该结构必须包含在 VkSwapchainCreateInfoKHR 的 pNext 链中。

版本历史

  • 版本 1，2018-03-28 (Daniel Rakos)

    • 内部修订。

VK_KHR_video_decode_av1

名称字符串

VK_KHR_video_decode_av1

扩展类型

设备扩展

注册扩展号

513

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_video_decode_queue

联系方式
扩展提案

VK_KHR_video_decode_av1

其他扩展元数据

上次修改日期

2024-01-02

IP 状态

没有已知的 IP 声明。

贡献者

  • Ahmed Abdelkhalek, AMD

  • Benjamin Cheng, AMD

  • Ho Hin Lau, AMD

  • Lynne Iribarren, 独立开发者

  • David Airlie, Red Hat, Inc.

  • Ping Liu, Intel

  • Srinath Kumarapuram, NVIDIA

  • Vassili Nikolaev, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Charlie Turner, Igalia

  • Daniel Almeida, Collabora

  • Nicolas Dufresne, Collabora

  • Daniel Rakos, RasterGrid

描述

此扩展基于 VK_KHR_video_decode_queue 扩展，增加了对符合 AV1 视频压缩标准的原始视频流序列的解码支持。

新结构体

新枚举常量

  • VK_KHR_VIDEO_DECODE_AV1_EXTENSION_NAME

  • VK_KHR_VIDEO_DECODE_AV1_SPEC_VERSION

  • VK_MAX_VIDEO_AV1_REFERENCES_PER_FRAME_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_AV1_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_AV1_DPB_SLOT_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_AV1_PICTURE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_AV1_PROFILE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_AV1_SESSION_PARAMETERS_CREATE_INFO_KHR

  • 扩展 VkVideoCodecOperationFlagBitsKHR

    • VK_VIDEO_CODEC_OPERATION_DECODE_AV1_BIT_KHR

版本历史

  • 版本 1，2024-01-02 (Daniel Rakos)

    • 内部修订

VK_KHR_video_decode_h264

名称字符串

VK_KHR_video_decode_h264

扩展类型

设备扩展

注册扩展号

41

修订

9

批准状态

已批准

扩展和版本依赖关系

VK_KHR_video_decode_queue

联系方式
扩展提案

VK_KHR_video_decode_h264

其他扩展元数据

上次修改日期

2023-12-05

IP 状态

没有已知的 IP 声明。

贡献者

  • Ahmed Abdelkhalek, AMD

  • Chunbo Chen, Intel

  • HoHin Lau, AMD

  • Jake Beju, AMD

  • Peter Fang, AMD

  • Ping Liu, Intel

  • Srinath Kumarapuram, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Daniel Rakos, RasterGrid

描述

此扩展基于 VK_KHR_video_decode_queue 扩展，增加了对符合 H.264/AVC 视频压缩标准的原始视频流序列的解码支持。

此扩展从临时扩展 VK_EXT_video_decode_h264 提升为 KHR。

新结构体

新枚举

新位掩码

新枚举常量

  • VK_KHR_VIDEO_DECODE_H264_EXTENSION_NAME

  • VK_KHR_VIDEO_DECODE_H264_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_DPB_SLOT_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_PICTURE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_PROFILE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_SESSION_PARAMETERS_ADD_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_SESSION_PARAMETERS_CREATE_INFO_KHR

  • 扩展 VkVideoCodecOperationFlagBitsKHR

    • VK_VIDEO_CODEC_OPERATION_DECODE_H264_BIT_KHR

版本历史

  • 版本 1，2018-6-11 (Peter Fang)

    • 初始草案

  • 版本 2，2021 年 3 月 29 日 (Tony Zlatinski)

    • 规范和 API 更新

  • 版本 3，2021 年 8 月 1 日 (Srinath Kumarapuram)

    • 按照 Vulkan 命名约定，将 VkVideoDecodeH264FieldLayoutFlagsEXT 重命名为 VkVideoDecodeH264PictureLayoutFlagsEXT，将 VkVideoDecodeH264FieldLayoutFlagBitsEXT 重命名为 VkVideoDecodeH264PictureLayoutFlagBitsEXT (以及它定义的枚举名称)，并将 VkVideoDecodeH264ProfileEXT.fieldLayout 重命名为 VkVideoDecodeH264ProfileEXT.pictureLayout。

  • 版本 4，2022-03-16 (Ahmed Abdelkhalek)

    • 将 Std 标头版本报告/请求从这个扩展移至 VK_KHR_video_queue 扩展。

    • 删除现在为空的 VkVideoDecodeH264SessionCreateInfoEXT。

  • 版本 5，2022-03-31 (Ahmed Abdelkhalek)

    • 对 VkVideoDecodeH264Capabilities.maxLevel 使用 StdVideoH264Level 类型

  • 版本 6，2022-08-09 (Daniel Rakos)

    • 将 VkVideoDecodeH264ProfileEXT 重命名为 VkVideoDecodeH264ProfileInfoEXT

    • 将 VkVideoDecodeH264MvcEXT 重命名为 VkVideoDecodeH264MvcInfoEXT

  • 版本 7，2022-09-18 (Daniel Rakos)

    • 将 VkVideoDecodeH264ProfileInfoEXT::pictureLayout 的类型更改为 VkVideoDecodeH264PictureLayoutFlagBitsEXT

    • 删除 MVC 支持和相关的 VkVideoDecodeH264MvcInfoEXT 结构体

    • 在 VkVideoDecodeH264SessionParametersAddInfoEXT 中，分别将 spsStdCount、pSpsStd、ppsStdCount 和 pPpsStd 重命名为 stdSPSCount、pStdSPSs、stdPPSCount 和 pStdPPSs

    • 在 VkVideoDecodeH264SessionParametersCreateInfoEXT 中，将 maxSpsStdCount 和 maxPpsStdCount 分别重命名为 maxStdSPSCount 和 maxStdPPSCount。

    • 在 VkVideoDecodeH264PictureInfoEXT 中，将 slicesCount 和 pSlicesDataOffsets 分别重命名为 sliceCount 和 pSliceOffsets。

  • 修订版 8，2022-09-29 (Daniel Rakos)

    • 将扩展名从 EXT 更改为 KHR

    • 扩展不再是临时的。

  • 修订版 9，2023-12-05 (Daniel Rakos)

    • 根据 StdVideoDecodeH264PictureInfo::flags.is_reference 的值，调整参考图像的设置。

VK_KHR_video_decode_h265

名称字符串

VK_KHR_video_decode_h265

扩展类型

设备扩展

注册扩展号

188

修订

8

批准状态

已批准

扩展和版本依赖关系

VK_KHR_video_decode_queue

联系方式
扩展提案

VK_KHR_video_decode_h265

其他扩展元数据

上次修改日期

2023-12-05

IP 状态

没有已知的 IP 声明。

贡献者

  • Ahmed Abdelkhalek, AMD

  • HoHin Lau, AMD

  • Jake Beju, AMD

  • Peter Fang, AMD

  • Ping Liu, Intel

  • Srinath Kumarapuram, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Daniel Rakos, RasterGrid

描述

此扩展建立在 VK_KHR_video_decode_queue 扩展之上，增加了对符合 H.265/HEVC 视频压缩标准的视频基本流序列进行解码的支持。

此扩展是从临时扩展 VK_EXT_video_decode_h265 升级到 KHR 的。

新结构体

新枚举常量

  • VK_KHR_VIDEO_DECODE_H265_EXTENSION_NAME

  • VK_KHR_VIDEO_DECODE_H265_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_DPB_SLOT_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_PICTURE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_PROFILE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_SESSION_PARAMETERS_ADD_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_SESSION_PARAMETERS_CREATE_INFO_KHR

  • 扩展 VkVideoCodecOperationFlagBitsKHR

    • VK_VIDEO_CODEC_OPERATION_DECODE_H265_BIT_KHR

版本历史

  • 版本 1，2018-6-11 (Peter Fang)

    • 初始草案

  • 修订版 1.6，2021 年 3 月 29 日 (Tony Zlatinski)

    • 规范和 API 更新。

  • 修订版 2，2022-03-16 (Ahmed Abdelkhalek)

    • 将 Std 标头版本报告/请求从这个扩展移至 VK_KHR_video_queue 扩展。

    • 删除现在为空的 VkVideoDecodeH265SessionCreateInfoEXT。

  • 修订版 3，2022-03-31 (Ahmed Abdelkhalek)

    • 为 VkVideoDecodeH265Capabilities.maxLevel 使用 StdVideoH265Level 类型

  • 修订版 4，2022-08-09 (Daniel Rakos)

    • 将 VkVideoDecodeH265ProfileEXT 重命名为 VkVideoDecodeH265ProfileInfoEXT

  • 修订版 5，2022-09-18 (Daniel Rakos)

    • 在 VkVideoDecodeH265SessionParametersAddInfoEXT 中，将 vpsStdCount、pVpsStd、spsStdCount、pSpsStd、ppsStdCount 和 pPpsStd 分别重命名为 stdVPSCount、pStdVPSs、stdSPSCount、pStdSPSs、stdPPSCount 和 pStdPPSs。

    • 在 VkVideoDecodeH265SessionParametersCreateInfoEXT 中，将 maxVpsStdCount、maxSpsStdCount 和 maxPpsStdCount 分别重命名为 maxStdVPSCount、maxStdSPSCount 和 maxStdPPSCount。

    • 在 VkVideoDecodeH265PictureInfoEXT 中，将 slicesCount 和 pSlicesDataOffsets 分别重命名为 sliceCount 和 pSliceOffsets。

  • 修订版 6，2022-11-14 (Daniel Rakos)

    • 为了更清晰，在 API 中将 slice 重命名为 sliceSegment

  • 修订版 7，2022-11-14 (Daniel Rakos)

    • 将扩展名从 EXT 更改为 KHR

    • 扩展不再是临时的。

  • 修订版 8，2023-12-05 (Daniel Rakos)

    • 根据 StdVideoDecodeH265PictureInfo::flags.IsReference 的值，调整参考图像的设置。

VK_KHR_video_decode_queue

名称字符串

VK_KHR_video_decode_queue

扩展类型

设备扩展

注册扩展号

25

修订

8

批准状态

已批准

扩展和版本依赖关系

VK_KHR_video_queue
和
     VK_KHR_synchronization2
    或
     Vulkan 版本 1.3

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_format_feature_flags2 交互

联系方式
扩展提案

VK_KHR_video_decode_queue

其他扩展元数据

上次修改日期

2023-12-05

IP 状态

没有已知的 IP 声明。

贡献者

  • Ahmed Abdelkhalek, AMD

  • Jake Beju, AMD

  • Olivier Lapicque, NVIDIA

  • Peter Fang, AMD

  • Piers Daniell, NVIDIA

  • Srinath Kumarapuram, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Daniel Rakos, RasterGrid

描述

此扩展建立在 VK_KHR_video_queue 扩展之上，增加了特定于视频解码的通用 API，从而使实现能够公开支持视频解码操作的队列族。

更具体地说，它增加了特定于视频解码的功能和一个新的命令缓冲区命令，允许针对视频会话记录视频解码操作。

此扩展应与其他编解码器特定的视频解码扩展结合使用，这些扩展支持解码特定视频压缩标准的视频序列。

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_KHR_VIDEO_DECODE_QUEUE_EXTENSION_NAME

  • VK_KHR_VIDEO_DECODE_QUEUE_SPEC_VERSION

  • 扩展 VkAccessFlagBits2

    • VK_ACCESS_2_VIDEO_DECODE_READ_BIT_KHR

    • VK_ACCESS_2_VIDEO_DECODE_WRITE_BIT_KHR

  • 扩展 VkBufferUsageFlagBits

    • VK_BUFFER_USAGE_VIDEO_DECODE_DST_BIT_KHR

    • VK_BUFFER_USAGE_VIDEO_DECODE_SRC_BIT_KHR

  • 扩展 VkFormatFeatureFlagBits

    • VK_FORMAT_FEATURE_VIDEO_DECODE_DPB_BIT_KHR

    • VK_FORMAT_FEATURE_VIDEO_DECODE_OUTPUT_BIT_KHR

  • 扩展 VkImageLayout

    • VK_IMAGE_LAYOUT_VIDEO_DECODE_DPB_KHR

    • VK_IMAGE_LAYOUT_VIDEO_DECODE_DST_KHR

    • VK_IMAGE_LAYOUT_VIDEO_DECODE_SRC_KHR

  • 扩展 VkImageUsageFlagBits

    • VK_IMAGE_USAGE_VIDEO_DECODE_DPB_BIT_KHR

    • VK_IMAGE_USAGE_VIDEO_DECODE_DST_BIT_KHR

    • VK_IMAGE_USAGE_VIDEO_DECODE_SRC_BIT_KHR

  • 扩展 VkPipelineStageFlagBits2

    • VK_PIPELINE_STAGE_2_VIDEO_DECODE_BIT_KHR

  • 扩展 VkQueueFlagBits

    • VK_QUEUE_VIDEO_DECODE_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_DECODE_USAGE_INFO_KHR

如果支持 VK_KHR_format_feature_flags2 或 Vulkan 1.3 版本

  • 扩展 VkFormatFeatureFlagBits2

    • VK_FORMAT_FEATURE_2_VIDEO_DECODE_DPB_BIT_KHR

    • VK_FORMAT_FEATURE_2_VIDEO_DECODE_OUTPUT_BIT_KHR

版本历史

  • 版本 1，2018-6-11 (Peter Fang)

    • 初始草案

  • 修订版 1.5，2018 年 11 月 09 日 (Tony Zlatinski)

    • API 更新

  • 修订版 1.6，2020 年 1 月 08 日 (Tony Zlatinski)

    • API 与 video_encode_queue 规范统一

  • 修订版 1.7，2021 年 3 月 29 日 (Tony Zlatinski)

    • 规范和 API 更新。

  • 修订版 2，2021 年 9 月 30 日 (Jon Leech)

  • 修订版 3，2022-02-25 (Ahmed Abdelkhalek)

    • 添加 VkVideoDecodeCapabilitiesKHR，其中包含新标志，以报告对同一图像或不同图像中同时存在的解码 DPB 和输出的支持。

  • 修订版 4，2022-03-31 (Ahmed Abdelkhalek)

    • 删除冗余的 VkVideoDecodeInfoKHR.coded{Offset|Extent}

  • 修订版 5，2022-07-18 (Daniel Rakos)

    • 删除 VkVideoDecodeFlagBitsKHR，因为它现在不包含任何定义的标志

  • 修订版 6，2022-08-12 (Daniel Rakos)

    • 添加 VkVideoDecodeUsageInfoKHR 结构和相关标志

  • 修订版 7，2022-09-29 (Daniel Rakos)

    • 扩展不再是临时的。

  • 修订版 8，2023-12-05 (Daniel Rakos)

    • 要求在所有情况下都指定重建的图像，除非视频会话是在没有 DPB 插槽的情况下创建的，以匹配交付的实现

    • 使 DPB 插槽激活行为特定于编解码器，以便在重建图像始终是强制性的情况下，继续允许应用程序控制参考图像的设置

VK_KHR_video_encode_av1

名称字符串

VK_KHR_video_encode_av1

扩展类型

设备扩展

注册扩展号

514

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_video_encode_queue

联系方式
扩展提案

VK_KHR_video_encode_av1

其他扩展元数据

上次修改日期

2024-09-23

IP 状态

没有已知的 IP 声明。

贡献者

  • Ahmed Abdelkhalek, AMD

  • Benjamin Cheng, AMD

  • Ho Hin Lau, AMD

  • Lynne Iribarren, 独立开发者

  • David Airlie, Red Hat, Inc.

  • Ping Liu, Intel

  • Srinath Kumarapuram, NVIDIA

  • Vassili Nikolaev, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Konda Raju, NVIDIA

  • Charlie Turner, Igalia

  • Daniel Almeida, Collabora

  • Nicolas Dufresne, Collabora

  • Daniel Rakos, RasterGrid

描述

此扩展在 VK_KHR_video_encode_queue 扩展的基础上，增加了对符合 AV1 视频压缩标准的 Elementary 视频流序列编码的支持。

新结构

新枚举

新位掩码

新枚举常量

  • VK_KHR_VIDEO_ENCODE_AV1_EXTENSION_NAME

  • VK_KHR_VIDEO_ENCODE_AV1_SPEC_VERSION

  • VK_MAX_VIDEO_AV1_REFERENCES_PER_FRAME_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_ENCODE_AV1_FEATURES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_DPB_SLOT_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_GOP_REMAINING_FRAME_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_PICTURE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_PROFILE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_QUALITY_LEVEL_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_RATE_CONTROL_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_RATE_CONTROL_LAYER_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_SESSION_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_SESSION_PARAMETERS_CREATE_INFO_KHR

  • 扩展 VkVideoCodecOperationFlagBitsKHR

    • VK_VIDEO_CODEC_OPERATION_ENCODE_AV1_BIT_KHR

版本历史

  • 修订版 1，2024-09-23 (Daniel Rakos)

    • 内部修订

VK_KHR_video_encode_h264

名称字符串

VK_KHR_video_encode_h264

扩展类型

设备扩展

注册扩展号

39

修订

14

批准状态

已批准

扩展和版本依赖关系

VK_KHR_video_encode_queue

联系方式
扩展提案

VK_KHR_video_encode_h264

其他扩展元数据

上次修改日期

2023-12-05

IP 状态

没有已知的 IP 声明。

贡献者

  • Ahmed Abdelkhalek, AMD

  • George Hao，AMD

  • Jake Beju, AMD

  • Peter Fang, AMD

  • Ping Liu, Intel

  • Srinath Kumarapuram, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Ravi Chaudhary，NVIDIA

  • Yang Liu，AMD

  • Daniel Rakos, RasterGrid

  • Aidan Fabius，Core Avionics & Industrial Inc.

  • Lynne Iribarren, 独立开发者

描述

此扩展在 VK_KHR_video_encode_queue 扩展的基础上，增加了对符合 H.264/AVC 视频压缩标准的 Elementary 视频流序列编码的支持。

此扩展已从临时扩展 VK_EXT_video_encode_h264 提升为 KHR。

新结构

新枚举

新位掩码

新枚举常量

  • VK_KHR_VIDEO_ENCODE_H264_EXTENSION_NAME

  • VK_KHR_VIDEO_ENCODE_H264_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_DPB_SLOT_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_GOP_REMAINING_FRAME_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_NALU_SLICE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_PICTURE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_PROFILE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_QUALITY_LEVEL_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_RATE_CONTROL_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_RATE_CONTROL_LAYER_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_PARAMETERS_ADD_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_PARAMETERS_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_PARAMETERS_FEEDBACK_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_PARAMETERS_GET_INFO_KHR

  • 扩展 VkVideoCodecOperationFlagBitsKHR

    • VK_VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_KHR

版本历史

  • 修订版 0，2018-7-23 (Ahmed Abdelkhalek)

    • 初始草案

  • 修订版 0.5，2020-02-13 (Tony Zlatinski)

    • 常规规范清理

    • 添加了 DPB 结构

    • 更改了 VCL 帧编码结构

    • 添加了通用的非 VCL 图片参数结构

  • 修订版 1，2021-03-29 (Tony Zlatinski)

    • 规范和 API 更新

  • 修订版 2，2021 年 8 月 1 日 (Srinath Kumarapuram)

    • 按照 Vulkan 命名约定，将 VkVideoEncodeH264CapabilitiesFlagsEXT 重命名为 VkVideoEncodeH264CapabilityFlagsEXT，并将 VkVideoEncodeH264CapabilitiesFlagsEXT 重命名为 VkVideoEncodeH264CapabilityFlagsEXT。

  • 修订版 3，2021-12-08 (Ahmed Abdelkhalek)

    • 速率控制更新

  • 修订版 4，2022-02-04 (Ahmed Abdelkhalek)

    • 将 VkVideoEncodeH264VclFrameInfoEXT 结构与 VK_EXT_video_encode_h265 扩展中的类似结构对齐

  • 修订版 5，2022-02-10 (Ahmed Abdelkhalek)

    • 编码能力接口的更新

  • 修订版 6，2022-03-16 (Ahmed Abdelkhalek)

    • 将 Std 标头版本报告/请求从这个扩展移至 VK_KHR_video_queue 扩展。

    • 从 VkVideoEncodeH264SessionCreateInfoEXT 中删除冗余的 maxPictureSizeInMbs。

    • 删除现在为空的 VkVideoEncodeH264SessionCreateInfoEXT。

  • 修订版 7，2022-04-06 (Ahmed Abdelkhalek)

    • 添加能力标志以报告在 L1 参考列表中支持使用 B 帧。

    • 添加能力标志以报告支持禁用 SPS direct_8x8_inference_flag。

  • 修订版 8，2022-07-18 (Daniel Rakos)

    • 将 VkVideoEncodeH264RateControlStructureFlagBitsEXT 位枚举替换为 VkVideoEncodeH264RateControlStructureEXT 枚举

    • 将 VkVideoEncodeH264ProfileEXT 重命名为 VkVideoEncodeH264ProfileInfoEXT

    • 将 VkVideoEncodeH264ReferenceListsEXT 重命名为 VkVideoEncodeH264ReferenceListsInfoEXT

    • 将 VkVideoEncodeH264EmitPictureParametersEXT 重命名为 VkVideoEncodeH264EmitPictureParametersInfoEXT

    • 将 VkVideoEncodeH264NaluSliceEXT 重命名为 VkVideoEncodeH264NaluSliceInfoEXT

  • 修订版 9，2022-09-18 (Daniel Rakos)

    • 在 VkVideoEncodeH264SessionParametersAddInfoEXT 中，将 spsStdCount、pSpsStd、ppsStdCount 和 pPpsStd 分别重命名为 stdSPSCount、pStdSPSs、stdPPSCount 和 pStdPPSs

    • 在 VkVideoEncodeH264SessionParametersCreateInfoEXT 中，将 maxSpsStdCount 和 maxPpsStdCount 分别重命名为 maxStdSPSCount 和 maxStdPPSCount

  • 修订版 10，2023-03-06 (Daniel Rakos)

    • 删除了 VkVideoEncodeH264EmitPictureParametersInfoEXT

    • 将 VkVideoEncodeH264CapabilitiesEXT 和 VkVideoEncodeH264ReferenceListsInfoEXT 中的成员类型从 uint8_t 更改为 uint32_t

    • 将 VkVideoEncodeH264RateControlInfoEXT::temporalLayerCount 和 VkVideoEncodeH264RateControlLayerInfoEXT::temporalLayerId 的类型从 uint8_t 更改为 uint32_t

    • 删除了 VkVideoEncodeH264InputModeFlagsEXT 和 VkVideoEncodeH264OutputModeFlagsEXT，因为我们目前只支持帧内帧外模式

    • 在 VkVideoEncodeH264VclFrameInfoEXT 中，将 pCurrentPictureInfo 重命名为 pStdPictureInfo

    • 在 VkVideoEncodeH264NaluSliceInfoEXT 中，将 pSliceHeaderStd 重命名为 pStdSliceHeader

    • 在 VkVideoEncodeH264VclFrameInfoEXT 和 VkVideoEncodeH264NaluSliceInfoEXT 中，将 pReferenceFinalLists 重命名为 pStdReferenceFinalLists

    • 删除了 VkVideoEncodeH264DpbSlotInfoEXT 的 slotIndex 成员，并将其更改为链接到 VkVideoReferenceSlotInfoKHR

    • 将 VkVideoEncodeH264ReferenceListsInfoEXT 替换为新的视频标准头结构 StdVideoEncodeH264ReferenceLists，该结构还包含之前属于现在已删除的 StdVideoEncodeH264RefMemMgmtCtrlOperations 结构的数据。

    • 添加了新的功能标志 VK_VIDEO_ENCODE_H264_CAPABILITY_DIFFERENT_REFERENCE_FINAL_LISTS_BIT_EXT

  • 修订版 11，2023-05-22 (Daniel Rakos)

    • 将 VkVideoEncodeH264VclFrameInfoEXT 重命名为 VkVideoEncodeH264PictureInfoEXT

    • 添加了 VkVideoEncodeH264PictureInfoEXT::generatePrefixNalu 和 VK_VIDEO_ENCODE_H264_CAPABILITY_GENERATE_PREFIX_NALU_BIT_EXT，以便在实现支持时生成 H.264 前缀 NALU

    • 删除了 VkVideoEncodeH264RateControlLayerInfoEXT::temporalLayerId

    • 添加了 expectDyadicTemporalLayerPattern 功能

    • 添加了 VkVideoEncodeH264SessionParametersGetInfoEXT 结构，用于标识要检索编码参数数据的 H.264 参数集，以及 VkVideoEncodeH264SessionParametersFeedbackInfoEXT 结构，用于在使用新的 vkGetEncodedVideoSessionParametersKHR 命令时检索 H.264 参数集覆盖信息。

    • 添加了 VkVideoEncodeH264NaluSliceInfoEXT::constantQp，用于在速率控制模式为 VK_VIDEO_ENCODE_RATE_CONTROL_MODE_DISABLED_BIT_KHR 时指定每个切片的恒定 QP

    • 添加了 VkVideoEncodeH264QualityLevelPropertiesEXT，用于检索 H.264 特定质量级别建议

    • 将 VkVideoEncodeH264RateControlStructureEXT 枚举替换为标志类型 VkVideoEncodeH264RateControlFlagsEXT 以及在 VkVideoEncodeH264RateControlFlagBitsEXT 中定义的位，并添加了 HRD 合规标志

    • 删除了 VkVideoEncodeH264RateControlLayerInfoEXT 的 useInitialRcQp 和 initialRcQp 成员

    • 添加了 prefersGopRemainingFrames 和 requiresGopRemainingFrames，以及新的 VkVideoEncodeH264GopRemainingFrameInfoEXT 结构，以允许指定速率控制 GOP 中每种类型的剩余帧数

    • 添加了 maxTemporalLayers、maxQp 和 minQp 功能

    • 添加了 maxLevelIdc 功能和新的 VkVideoEncodeH264SessionCreateInfoEXT 结构，以指定生成的视频码流的 H.264 级别的上限

    • 将特定于编解码器语法限制的功能标志从 VkVideoEncodeH264CapabilityFlagsEXT 移动到新的 VkVideoEncodeH264StdFlagsEXT，该结构现在作为单独的 stdSyntaxFlags 成员包含在 VkVideoEncodeH264CapabilitiesEXT 中

    • 从 VkVideoEncodeH264CapabilitiesEXT 中删除了编解码器语法覆盖值

    • 删除了 VkVideoEncodeH264NaluSliceInfoEXT::mbCount 和 VK_VIDEO_ENCODE_H264_CAPABILITY_SLICE_MB_COUNT_BIT_EXT

    • 将 VK_VIDEO_ENCODE_H264_CAPABILITY_MULTIPLE_SLICES_PER_FRAME_BIT_EXT 替换为新的 maxSliceCount 功能

    • 删除了功能标志 VK_VIDEO_ENCODE_H264_CAPABILITY_DIFFERENT_REFERENCE_FINAL_LISTS_BIT_EXT，并从 VkVideoEncodeH264PictureInfoEXT 和 VkVideoEncodeH264NaluSliceInfoEXT 结构中删除了 pStdReferenceFinalLists 成员，因为参考列表信息现在包含在 pStdPictureInfo 中

    • 添加了功能标志 VK_VIDEO_ENCODE_H264_CAPABILITY_B_FRAME_IN_L0_LIST_BIT_EXT

  • 修订版 12，2023-07-19 (Daniel Rakos)

    • 添加了视频标准功能标志 VK_VIDEO_ENCODE_H264_STD_SLICE_QP_DELTA_BIT_EXT 和 VK_VIDEO_ENCODE_H264_STD_DIFFERENT_SLICE_QP_DELTA_BIT_EXT

    • 修复了 VkVideoEncodeH264SessionParametersAddInfoEXT 的数组成员的可选性

    • 修复了 VkVideoEncodeH264RateControlInfoEXT::flags 的可选性

  • 修订版 13，2023-09-04 (Daniel Rakos)

    • 将扩展名从 EXT 更改为 KHR

    • 扩展不再是临时的。

  • 修订版 14，2023-12-05 (Daniel Rakos)

    • 根据 StdVideoEncodeH264PictureInfo::flags.is_reference 的值来设置参考图像

VK_KHR_video_encode_h265

名称字符串

VK_KHR_video_encode_h265

扩展类型

设备扩展

注册扩展号

40

修订

14

批准状态

已批准

扩展和版本依赖关系

VK_KHR_video_encode_queue

联系方式
扩展提案

VK_KHR_video_encode_h265

其他扩展元数据

上次修改日期

2023-12-05

IP 状态

没有已知的 IP 声明。

贡献者

  • Ahmed Abdelkhalek, AMD

  • George Hao，AMD

  • Jake Beju, AMD

  • Chunbo Chen, Intel

  • Ping Liu, Intel

  • Srinath Kumarapuram, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Ravi Chaudhary，NVIDIA

  • Daniel Rakos, RasterGrid

  • Aidan Fabius，Core Avionics & Industrial Inc.

  • Lynne Iribarren, 独立开发者

描述

此扩展建立在 VK_KHR_video_encode_queue 扩展的基础上，增加了对符合 H.265/HEVC 视频压缩标准的原始视频流序列进行编码的支持。

此扩展已从临时扩展 VK_EXT_video_encode_h265 提升为 KHR。

新结构

新枚举

新位掩码

新枚举常量

  • VK_KHR_VIDEO_ENCODE_H265_EXTENSION_NAME

  • VK_KHR_VIDEO_ENCODE_H265_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_DPB_SLOT_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_GOP_REMAINING_FRAME_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_NALU_SLICE_SEGMENT_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_PICTURE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_PROFILE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_QUALITY_LEVEL_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_RATE_CONTROL_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_RATE_CONTROL_LAYER_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_PARAMETERS_ADD_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_PARAMETERS_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_PARAMETERS_FEEDBACK_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_PARAMETERS_GET_INFO_KHR

  • 扩展 VkVideoCodecOperationFlagBitsKHR

    • VK_VIDEO_CODEC_OPERATION_ENCODE_H265_BIT_KHR

版本历史

  • 修订版 0，2019-11-14 (Ahmed Abdelkhalek)

    • 初始草案

  • 修订版 0.5，2020-02-13 (Tony Zlatinski)

    • 常规规范清理

    • 添加了 DPB 结构

    • 更改了 VCL 帧编码结构

    • 添加了通用的非 VCL 图片参数结构

  • 修订版 2，2021 年 10 月 10 日（Srinath Kumarapuram）

    • Vulkan 视频编码 h.265 更新和规范编辑

  • 修订版 3，2021-12-08 (Ahmed Abdelkhalek)

    • 速率控制更新

  • 修订版 4，2022-01-11 (Ahmed Abdelkhalek)

    • 将所有出现的“切片”替换为“切片段”，并重命名结构/枚举以反映这一点。

  • 修订版 5，2022-02-10 (Ahmed Abdelkhalek)

    • 编码能力接口的更新

  • 修订版 6，2022-03-16 (Ahmed Abdelkhalek)

    • 将 Std 标头版本报告/请求从这个扩展移至 VK_KHR_video_queue 扩展。

    • 删除现在为空的 VkVideoEncodeH265SessionCreateInfoEXT。

  • 修订版 7，2022-03-24 (Ahmed Abdelkhalek)

    • 添加功能标志以报告禁用变换跳跃的支持以及在 L1 参考列表中使用 B 帧的支持。

  • 修订版 8，2022-07-18 (Daniel Rakos)

    • 将 VkVideoEncodeH265RateControlStructureFlagBitsEXT 位枚举替换为 VkVideoEncodeH265RateControlStructureEXT 枚举

    • 将 VkVideoEncodeH265ProfileEXT 重命名为 VkVideoEncodeH265ProfileInfoEXT

    • 将 VkVideoEncodeH265ReferenceListsEXT 重命名为 VkVideoEncodeH265ReferenceListsInfoEXT

    • 将 VkVideoEncodeH265EmitPictureParametersEXT 重命名为 VkVideoEncodeH265EmitPictureParametersInfoEXT

    • 将 VkVideoEncodeH265NaluSliceSegmentEXT 重命名为 VkVideoEncodeH265NaluSliceSegmentInfoEXT

  • 修订版 9，2022-09-18 (Daniel Rakos)

    • 在 VkVideoEncodeH265SessionParametersAddInfoEXT 中，将 vpsStdCount、pVpsStd、spsStdCount、pSpsStd、ppsStdCount 和 pPpsStd 分别重命名为 stdVPSCount、pStdVPSs、stdSPSCount、pStdSPSs、stdPPSCount 和 pStdPPSs。

    • 在 VkVideoEncodeH265SessionParametersCreateInfoEXT 中，将 maxVpsStdCount、maxSpsStdCount 和 maxPpsStdCount 分别重命名为 maxStdVPSCount、maxStdSPSCount 和 maxStdPPSCount。

  • 修订版 10，2023-03-06 (Daniel Rakos)

    • 移除了 VkVideoEncodeH265EmitPictureParametersInfoEXT。

    • 将 VkVideoEncodeH265CapabilitiesEXT 和 VkVideoEncodeH265ReferenceListsInfoEXT 中的成员类型从 uint8_t 更改为 uint32_t。

    • 将 VkVideoEncodeH265RateControlInfoEXT::subLayerCount 和 VkVideoEncodeH265RateControlLayerInfoEXT::temporalId 的类型从 uint8_t 更改为 uint32_t。

    • 移除了 VkVideoEncodeH265InputModeFlagsEXT 和 VkVideoEncodeH265OutputModeFlagsEXT，因为我们目前仅支持帧内帧外模式。

    • 将 VkVideoEncodeH265VclFrameInfoEXT 中的 pCurrentPictureInfo 重命名为 pStdPictureInfo。

    • 将 VkVideoEncodeH265NaluSliceSegmentInfoEXT 中的 pSliceSegmentHeaderStd 重命名为 pStdSliceSegmentHeader。

    • 将 VkVideoEncodeH265VclFrameInfoEXT 和 VkVideoEncodeH265NaluSliceSegmentInfoEXT 中的 pReferenceFinalLists 重命名为 pStdReferenceFinalLists。

    • 移除了 VkVideoEncodeH265DpbSlotInfoEXT 的 slotIndex 成员，并将其更改为链接到 VkVideoReferenceSlotInfoKHR。

    • 将 VkVideoEncodeH265ReferenceListsInfoEXT 替换为新的视频标准头结构 StdVideoEncodeH265ReferenceLists。

    • 添加了新的能力标志 VK_VIDEO_ENCODE_H265_CAPABILITY_DIFFERENT_REFERENCE_FINAL_LISTS_BIT_EXT。

  • 修订版本 11，2023-05-26 (Daniel Rakos)

    • 将 VkVideoEncodeH265VclFrameInfoEXT 重命名为 VkVideoEncodeH265PictureInfoEXT。

    • 移除了 VkVideoEncodeH265RateControlLayerInfoEXT::temporalId。

    • 添加了 expectDyadicTemporalSubLayerPattern 能力。

    • 添加了 VkVideoEncodeH265SessionParametersGetInfoEXT 结构来标识要检索编码参数数据的 H.265 参数集，以及 VkVideoEncodeH265SessionParametersFeedbackInfoEXT 结构，以便在使用新的 vkGetEncodedVideoSessionParametersKHR 命令时检索 H.265 参数集覆盖信息。

    • 当速率控制模式为 VK_VIDEO_ENCODE_RATE_CONTROL_MODE_DISABLED_BIT_KHR 时，添加了 VkVideoEncodeH265NaluSliceSegmentInfoEXT::constantQp 来指定每个切片段的恒定 QP。

    • 添加了 VkVideoEncodeH265QualityLevelPropertiesEXT，用于检索 H.265 特定质量级别的建议。

    • 将 VkVideoEncodeH265RateControlStructureEXT 枚举替换为标志类型 VkVideoEncodeH265RateControlFlagsEXT，以及在 VkVideoEncodeH265RateControlFlagBitsEXT 中定义的位，并添加了 HRD 合规性标志。

    • 移除了 VkVideoEncodeH265RateControlLayerInfoEXT 的 useInitialRcQp 和 initialRcQp 成员。

    • 添加了 prefersGopRemainingFrames 和 requiresGopRemainingFrames，以及新的 VkVideoEncodeH265GopRemainingFrameInfoEXT 结构，以允许指定速率控制 GOP 中每种类型的剩余帧。

    • 将 maxSubLayersCount 能力重命名为 maxSubLayerCount。

    • 添加了 maxQp 和 minQp 能力。

    • 添加了 maxLevelIdc 能力和新的 VkVideoEncodeH265SessionCreateInfoEXT 结构，以指定生成的视频码流的 H.265 级别的上限。

    • 将特定于编解码器语法限制的能力标志从 VkVideoEncodeH265CapabilityFlagsEXT 移动到新的 VkVideoEncodeH265StdFlagsEXT，现在将其作为 VkVideoEncodeH265CapabilitiesEXT 中的单独的 stdSyntaxFlags 成员包含。

    • 在 VkVideoEncodeH265CapabilitiesEXT 中，为编解码器语法能力添加了 std 前缀。

    • 移除了 VkVideoEncodeH265NaluSliceSegmentInfoEXT::ctbCount 和 VK_VIDEO_ENCODE_H265_CAPABILITY_SLICE_SEGMENT_CTB_COUNT_BIT_EXT。

    • 将 VK_VIDEO_ENCODE_H265_CAPABILITY_MULTIPLE_SLICE_SEGMENTS_PER_FRAME_BIT_EXT 替换为新的 maxSliceSegmentCount 能力。

    • 添加了 maxTiles 能力。

    • 从 VkVideoEncodeH265CapabilitiesEXT 中移除了编解码器语法的最小/最大能力。

    • 移除了能力标志 VK_VIDEO_ENCODE_H265_CAPABILITY_DIFFERENT_REFERENCE_FINAL_LISTS_BIT_EXT，并从 VkVideoEncodeH265PictureInfoEXT 和 VkVideoEncodeH265NaluSliceSegmentInfoEXT 结构中移除了 pStdReferenceFinalLists 成员，因为引用列表信息现在包含在 pStdPictureInfo 中。

    • 添加了能力标志 VK_VIDEO_ENCODE_H265_CAPABILITY_B_FRAME_IN_L0_LIST_BIT_EXT。

  • 修订版 12，2023-07-19 (Daniel Rakos)

    • 添加了视频标准能力标志 VK_VIDEO_ENCODE_H265_STD_SLICE_QP_DELTA_BIT_EXT 和 VK_VIDEO_ENCODE_H265_STD_DIFFERENT_SLICE_QP_DELTA_BIT_EXT。

    • 修复了 VkVideoEncodeH265SessionParametersAddInfoEXT 的数组成员的可选性。

    • 修复了 VkVideoEncodeH265RateControlInfoEXT::flags 的可选性。

  • 修订版 13，2023-09-04 (Daniel Rakos)

    • 将扩展名从 EXT 更改为 KHR

    • 扩展不再是临时的。

  • 修订版 14，2023-12-05 (Daniel Rakos)

    • 基于 StdVideoEncodeH265PictureInfo::flags.is_reference 的值，设置参考图片。

VK_KHR_video_encode_quantization_map

名称字符串

VK_KHR_video_encode_quantization_map

扩展类型

设备扩展

注册扩展号

554

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_video_encode_queue
和
VK_KHR_format_feature_flags2

API 交互

  • 与 VK_KHR_video_encode_av1 交互

  • 与 VK_KHR_video_encode_h264 交互

  • 与 VK_KHR_video_encode_h265 交互

联系方式
扩展提案

VK_KHR_video_encode_quantization_map

其他扩展元数据

上次修改日期

2024-09-23

IP 状态

没有已知的 IP 声明。

贡献者

  • Ahmed Abdelkhalek, AMD

  • Benjamin Cheng, AMD

  • Srinath Kumarapuram, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Ping Liu, Intel

  • Daniel Rakos, RasterGrid

  • Lynne Iribarren, 独立开发者

描述

此扩展建立在 VK_KHR_video_encode_queue 扩展之上，通过在视频编码操作中启用对编解码器特定量化参数的精细控制。

更具体地说，它增加了对量化映射的支持

  • 量化增量映射，用于直接控制所有速率控制模式（包括速率控制禁用时）下每个块的量化参数值的相对值。

  • 强调映射，用于在速率控制未禁用且速率控制模式未配置为实现定义的默认模式时，间接控制每个块上的相对量化参数值。

此扩展应与其他编解码器特定的视频编码扩展一起使用，这些扩展指定这些映射控制的编解码器特定量化参数。

新结构

如果支持 VK_KHR_video_encode_av1

如果支持 VK_KHR_video_encode_h264

如果支持 VK_KHR_video_encode_h265

新枚举

新枚举常量

  • VK_KHR_VIDEO_ENCODE_QUANTIZATION_MAP_EXTENSION_NAME

  • VK_KHR_VIDEO_ENCODE_QUANTIZATION_MAP_SPEC_VERSION

  • 扩展 VkFormatFeatureFlagBits2

    • VK_FORMAT_FEATURE_2_VIDEO_ENCODE_EMPHASIS_MAP_BIT_KHR

    • VK_FORMAT_FEATURE_2_VIDEO_ENCODE_QUANTIZATION_DELTA_MAP_BIT_KHR

  • 扩展 VkImageLayout

    • VK_IMAGE_LAYOUT_VIDEO_ENCODE_QUANTIZATION_MAP_KHR

  • 扩展 VkImageUsageFlagBits

    • VK_IMAGE_USAGE_VIDEO_ENCODE_EMPHASIS_MAP_BIT_KHR

    • VK_IMAGE_USAGE_VIDEO_ENCODE_QUANTIZATION_DELTA_MAP_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_ENCODE_QUANTIZATION_MAP_FEATURES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUANTIZATION_MAP_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUANTIZATION_MAP_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUANTIZATION_MAP_SESSION_PARAMETERS_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_FORMAT_QUANTIZATION_MAP_PROPERTIES_KHR

  • 扩展 VkVideoEncodeCapabilityFlagBitsKHR

    • VK_VIDEO_ENCODE_CAPABILITY_EMPHASIS_MAP_BIT_KHR

    • VK_VIDEO_ENCODE_CAPABILITY_QUANTIZATION_DELTA_MAP_BIT_KHR

  • 扩展 VkVideoEncodeFlagBitsKHR

    • VK_VIDEO_ENCODE_WITH_EMPHASIS_MAP_BIT_KHR

    • VK_VIDEO_ENCODE_WITH_QUANTIZATION_DELTA_MAP_BIT_KHR

  • 扩展 VkVideoSessionCreateFlagBitsKHR

    • VK_VIDEO_SESSION_CREATE_ALLOW_ENCODE_EMPHASIS_MAP_BIT_KHR

    • VK_VIDEO_SESSION_CREATE_ALLOW_ENCODE_QUANTIZATION_DELTA_MAP_BIT_KHR

  • 扩展 VkVideoSessionParametersCreateFlagBitsKHR

    • VK_VIDEO_SESSION_PARAMETERS_CREATE_QUANTIZATION_MAP_COMPATIBLE_BIT_KHR

如果支持 VK_KHR_video_encode_av1

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_QUANTIZATION_MAP_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_FORMAT_AV1_QUANTIZATION_MAP_PROPERTIES_KHR

如果支持 VK_KHR_video_encode_h264

如果支持 VK_KHR_video_encode_h265

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_QUANTIZATION_MAP_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_FORMAT_H265_QUANTIZATION_MAP_PROPERTIES_KHR

  • 扩展 VkVideoEncodeH265CapabilityFlagBitsKHR

    • VK_VIDEO_ENCODE_H265_CAPABILITY_CU_QP_DIFF_WRAPAROUND_BIT_KHR

版本历史

  • 修订版 1，2024-08-21 (Daniel Rakos)

    • 内部修订

  • 修订版 2，2024-09-23 (Daniel Rakos)

    • 添加了与 VK_KHR_video_encode_av1 的交互

VK_KHR_video_encode_queue

名称字符串

VK_KHR_video_encode_queue

扩展类型

设备扩展

注册扩展号

300

修订

12

批准状态

已批准

扩展和版本依赖关系

VK_KHR_video_queue
和
     VK_KHR_synchronization2
    或
     Vulkan 版本 1.3

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_format_feature_flags2 交互

联系方式
扩展提案

VK_KHR_video_encode_queue

其他扩展元数据

上次修改日期

2023-12-05

IP 状态

没有已知的 IP 声明。

贡献者

  • Ahmed Abdelkhalek, AMD

  • Damien Kessler，NVIDIA

  • George Hao，AMD

  • Jake Beju, AMD

  • Peter Fang, AMD

  • Piers Daniell, NVIDIA

  • Srinath Kumarapuram, NVIDIA

  • Thomas J. Meier，NVIDIA

  • Tony Zlatinski, NVIDIA

  • Ravi Chaudhary，NVIDIA

  • Yang Liu，AMD

  • Daniel Rakos, RasterGrid

  • Ping Liu, Intel

  • Aidan Fabius，Core Avionics & Industrial Inc.

  • Lynne Iribarren, 独立开发者

描述

此扩展基于 VK_KHR_video_queue 扩展，添加了特定于视频编码的通用 API，从而使实现能够公开支持视频编码操作的队列族。

更具体地说，它添加了视频编码特定的功能和一个新的命令缓冲区命令，该命令允许针对视频会话记录视频编码操作。

此扩展应与其他特定编解码器的视频编码扩展一起使用，这些扩展支持对特定视频压缩标准的视频序列进行编码。

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_KHR_VIDEO_ENCODE_QUEUE_EXTENSION_NAME

  • VK_KHR_VIDEO_ENCODE_QUEUE_SPEC_VERSION

  • 扩展 VkAccessFlagBits2

    • VK_ACCESS_2_VIDEO_ENCODE_READ_BIT_KHR

    • VK_ACCESS_2_VIDEO_ENCODE_WRITE_BIT_KHR

  • 扩展 VkBufferUsageFlagBits

    • VK_BUFFER_USAGE_VIDEO_ENCODE_DST_BIT_KHR

    • VK_BUFFER_USAGE_VIDEO_ENCODE_SRC_BIT_KHR

  • 扩展 VkFormatFeatureFlagBits

    • VK_FORMAT_FEATURE_VIDEO_ENCODE_DPB_BIT_KHR

    • VK_FORMAT_FEATURE_VIDEO_ENCODE_INPUT_BIT_KHR

  • 扩展 VkImageLayout

    • VK_IMAGE_LAYOUT_VIDEO_ENCODE_DPB_KHR

    • VK_IMAGE_LAYOUT_VIDEO_ENCODE_DST_KHR

    • VK_IMAGE_LAYOUT_VIDEO_ENCODE_SRC_KHR

  • 扩展 VkImageUsageFlagBits

    • VK_IMAGE_USAGE_VIDEO_ENCODE_DPB_BIT_KHR

    • VK_IMAGE_USAGE_VIDEO_ENCODE_DST_BIT_KHR

    • VK_IMAGE_USAGE_VIDEO_ENCODE_SRC_BIT_KHR

  • 扩展 VkPipelineStageFlagBits2

    • VK_PIPELINE_STAGE_2_VIDEO_ENCODE_BIT_KHR

  • 扩展 VkQueryResultStatusKHR

    • VK_QUERY_RESULT_STATUS_INSUFFICIENT_BITSTREAM_BUFFER_RANGE_KHR

  • 扩展 VkQueryType

    • VK_QUERY_TYPE_VIDEO_ENCODE_FEEDBACK_KHR

  • 扩展 VkQueueFlagBits

    • VK_QUEUE_VIDEO_ENCODE_BIT_KHR

  • 扩展 VkResult

    • VK_ERROR_INVALID_VIDEO_STD_PARAMETERS_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_ENCODE_QUALITY_LEVEL_INFO_KHR

    • VK_STRUCTURE_TYPE_QUERY_POOL_VIDEO_ENCODE_FEEDBACK_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUALITY_LEVEL_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUALITY_LEVEL_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_RATE_CONTROL_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_RATE_CONTROL_LAYER_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_SESSION_PARAMETERS_FEEDBACK_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_SESSION_PARAMETERS_GET_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_USAGE_INFO_KHR

  • 扩展 VkVideoCodingControlFlagBitsKHR

    • VK_VIDEO_CODING_CONTROL_ENCODE_QUALITY_LEVEL_BIT_KHR

    • VK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_BIT_KHR

  • 扩展 VkVideoSessionCreateFlagBitsKHR

    • VK_VIDEO_SESSION_CREATE_ALLOW_ENCODE_PARAMETER_OPTIMIZATIONS_BIT_KHR

如果支持 VK_KHR_format_feature_flags2 或 Vulkan 1.3 版本

  • 扩展 VkFormatFeatureFlagBits2

    • VK_FORMAT_FEATURE_2_VIDEO_ENCODE_DPB_BIT_KHR

    • VK_FORMAT_FEATURE_2_VIDEO_ENCODE_INPUT_BIT_KHR

版本历史

  • 修订版 1，2018-07-23 (Ahmed Abdelkhalek)

    • 初始草案

  • 修订版 1.1，2019-10-29 (Tony Zlatinski)

    • 更新了保留的规范令牌并将 VkVideoEncoderKHR 重命名为 VkVideoSessionKHR

  • 修订版 1.6，2020 年 1 月 08 日 (Tony Zlatinski)

    • API 与 video_decode_queue 规范统一

  • 版本 2，2021 年 3 月 29 日 (Tony Zlatinski)

    • 规范和 API 更新。

  • 修订版 3，2021-09-30 (Jon Leech)

  • 修订版 4，2022-02-10 (Ahmed Abdelkhalek)

    • 编码能力接口的更新

  • 版本 5，2022-03-31 (Ahmed Abdelkhalek)

    • 删除冗余的 VkVideoEncodeInfoKHR.codedExtent

  • 修订版 6，2022-07-18 (Daniel Rakos)

    • 删除 VkVideoEncodeRateControlFlagBitsKHR 和 VkVideoEncodeFlagBitsKHR，因为它们现在不包含任何定义的标志

    • 添加 VK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_BIT_KHR 和 VK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_LAYER_BIT_KHR 以指示视频编码控制操作中的速率控制和速率控制层更改请求

  • 修订版 7，2022-08-12 (Daniel Rakos)

    • 添加 VkVideoEncodeUsageInfoKHR 结构体和相关标志

  • 修订版 8，2023-03-06 (Daniel Rakos)

    • 将 VK_QUERY_TYPE_VIDEO_ENCODE_BITSTREAM_BUFFER_RANGE_KHR 查询替换为更通用的 VK_QUERY_TYPE_VIDEO_ENCODE_FEEDBACK_KHR 查询，以便将来可以通过更多反馈值进行扩展

    • 为了与视频解码扩展中的命名约定保持一致，将 VkVideoEncodeInfoKHR 中的 dstBitstreamBuffer、dstBitstreamBufferOffset 和 dstBitstreamBufferMaxRange 重命名为 dstBuffer、dstBufferOffset 和 dstBufferRange

    • 将 VkVideoEncodeCapabilitiesKHR 中 rateControlLayerCount 和 qualityLevelCount 的类型从 uint8_t 更改为 uint32_t，并将它们分别重命名为 maxRateControlLayers 和 maxQualityLevels

    • 将 VkVideoEncodeRateControlLayerInfoKHR 中 averageBitrate 和 maxBitrate 的类型从 uint32_t 更改为 uint64_t

    • 修复了速率控制标志位的定义，并添加了新的 VK_VIDEO_ENCODE_RATE_CONTROL_MODE_DEFAULT_KHR 常量，以指示特定于实现的自动速率控制

    • 将 VkVideoEncodeRateControlInfoKHR::layerCount 的类型从 uint8_t 更改为 uint32_t

    • 将 VkVideoEncodeRateControlInfoKHR 中的 pLayerConfigs 重命名为 pLayers

  • 修订版 9，2023-03-28 (Daniel Rakos)

    • 移除了 VK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_LAYER_BIT_KHR 以及更改各个码率控制层状态的功能。

    • 为视频编码反馈查询添加了新的 VK_VIDEO_ENCODE_FEEDBACK_BITSTREAM_HAS_OVERRIDES_BIT_KHR 标志。

    • 添加了新的视频会话创建标志 VK_VIDEO_SESSION_CREATE_ALLOW_ENCODE_PARAMETER_OPTIMIZATIONS_BIT_KHR，用于选择启用视频会话和编码参数优化。

    • 添加了 vkGetEncodedVideoSessionParametersKHR 命令，用于检索编码的视频会话参数数据。

    • 将 virtualBufferSizeInMs 和 initialVirtualBufferSizeInMs 从 VkVideoEncodeRateControlLayerInfoKHR 移动到 VkVideoEncodeRateControlInfoKHR。

    • 添加了 maxBitrate 功能。

    • 将 inputImageDataFillAlignment 功能重命名为 encodeInputPictureGranularity，以更好地反映其用途。

    • 添加了新的 vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR 命令和相关结构，用于查询视频编码质量级别的建议设置。

    • 添加了 VK_VIDEO_CODING_CONTROL_ENCODE_QUALITY_LEVEL_BIT_KHR 标志和 VkVideoEncodeQualityLevelInfoKHR 结构，以允许控制视频编码质量级别，并从编码操作参数中移除了 qualityLevel。

  • 修订版本 10，2023-07-19 (Daniel Rakos)

    • 添加了 VK_QUERY_RESULT_STATUS_INSUFFICIENT_BITSTREAM_BUFFER_RANGE_KHR 查询结果状态代码以及相关的能力标志 VK_VIDEO_ENCODE_CAPABILITY_INSUFFICIENT_BITSTREAM_BUFFER_RANGE_DETECTION_BIT_KHR。

  • 修订版本 11，2023-09-04 (Daniel Rakos)

    • 扩展不再是临时的。

  • 修订版本 12，2023-12-05 (Daniel Rakos)

    • 要求在所有情况下都指定重建的图像，除非视频会话是在没有 DPB 插槽的情况下创建的，以匹配交付的实现

    • 使 DPB 插槽激活行为特定于编解码器，以便在重建图像始终是强制性的情况下，继续允许应用程序控制参考图像的设置

VK_KHR_video_maintenance1

名称字符串

VK_KHR_video_maintenance1

扩展类型

设备扩展

注册扩展号

516

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_video_queue

联系方式
扩展提案

VK_KHR_video_maintenance1

其他扩展元数据

上次修改日期

2023-07-27

IP 状态

没有已知的 IP 声明。

贡献者

  • Ahmed Abdelkhalek, AMD

  • Aidan Fabius，Core Avionics & Industrial Inc.

  • Ping Liu, Intel

  • Lynne Iribarren, 独立开发者

  • Srinath Kumarapuram, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Daniel Rakos, RasterGrid

描述

VK_KHR_video_maintenance1 添加了一系列小的视频编码功能，其中任何一个都不足以单独成为一个扩展。

新功能如下

  • 允许创建可在视频编码操作中使用的缓冲区，而与使用的视频配置文件无关，使用新的缓冲区创建标志 VK_BUFFER_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR。

  • 允许创建可用作解码输出或编码输入图像的图像，而与使用的视频配置文件无关，使用新的图像创建标志 VK_IMAGE_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR。

  • 允许将视频编码操作使用的查询指定为视频编码命令参数的一部分，而不是在使用新的视频会话创建标志 VK_VIDEO_SESSION_CREATE_INLINE_QUERIES_BIT_KHR 创建视频会话时使用 begin/end 查询。

新结构

新枚举常量

  • VK_KHR_VIDEO_MAINTENANCE_1_EXTENSION_NAME

  • VK_KHR_VIDEO_MAINTENANCE_1_SPEC_VERSION

  • 扩展 VkBufferCreateFlagBits

    • VK_BUFFER_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR

  • 扩展 VkImageCreateFlagBits

    • VK_IMAGE_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_MAINTENANCE_1_FEATURES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_INLINE_QUERY_INFO_KHR

  • 扩展 VkVideoSessionCreateFlagBitsKHR

    • VK_VIDEO_SESSION_CREATE_INLINE_QUERIES_BIT_KHR

版本历史

  • 修订版本 1，2023-07-27 (Daniel Rakos)

    • 内部修订

VK_KHR_video_queue

名称字符串

VK_KHR_video_queue

扩展类型

设备扩展

注册扩展号

24

修订

8

批准状态

已批准

扩展和版本依赖关系

     Vulkan 版本 1.1
     和
     VK_KHR_synchronization2
或
Vulkan 版本 1.3

联系方式
扩展提案

VK_KHR_video_queue

其他扩展元数据

上次修改日期

2022-09-29

IP 状态

没有已知的 IP 声明。

贡献者

  • Ahmed Abdelkhalek, AMD

  • George Hao，AMD

  • Jake Beju, AMD

  • Piers Daniell, NVIDIA

  • Srinath Kumarapuram, NVIDIA

  • Tobias Hector, AMD

  • Tony Zlatinski, NVIDIA

  • Daniel Rakos, RasterGrid

描述

此扩展提供了通用 API，通过引入以下新的对象类型和相关功能，可以公开支持视频编解码器操作的队列族：

  • 视频会话对象，表示和维护执行视频编解码器操作所需的状态。

  • 视频会话参数对象，用作编解码器特定参数的容器。

此外，它还引入了允许应用程序确定视频编码相关功能的查询命令，以及允许针对视频会话记录视频编码操作的命令缓冲区命令。

此扩展应与其他启用特定视频编码操作的扩展一起使用。

新对象类型

新命令

新结构

新枚举

新位掩码

新枚举常量

  • VK_KHR_VIDEO_QUEUE_EXTENSION_NAME

  • VK_KHR_VIDEO_QUEUE_SPEC_VERSION

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_VIDEO_SESSION_KHR

    • VK_OBJECT_TYPE_VIDEO_SESSION_PARAMETERS_KHR

  • 扩展 VkQueryResultFlagBits

    • VK_QUERY_RESULT_WITH_STATUS_BIT_KHR

  • 扩展 VkQueryType

    • VK_QUERY_TYPE_RESULT_STATUS_ONLY_KHR

  • 扩展 VkResult

    • VK_ERROR_IMAGE_USAGE_NOT_SUPPORTED_KHR

    • VK_ERROR_VIDEO_PICTURE_LAYOUT_NOT_SUPPORTED_KHR

    • VK_ERROR_VIDEO_PROFILE_CODEC_NOT_SUPPORTED_KHR

    • VK_ERROR_VIDEO_PROFILE_FORMAT_NOT_SUPPORTED_KHR

    • VK_ERROR_VIDEO_PROFILE_OPERATION_NOT_SUPPORTED_KHR

    • VK_ERROR_VIDEO_STD_VERSION_NOT_SUPPORTED_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BIND_VIDEO_SESSION_MEMORY_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_FORMAT_INFO_KHR

    • VK_STRUCTURE_TYPE_QUEUE_FAMILY_QUERY_RESULT_STATUS_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_QUEUE_FAMILY_VIDEO_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_BEGIN_CODING_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_CODING_CONTROL_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_END_CODING_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_FORMAT_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_PICTURE_RESOURCE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_PROFILE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_PROFILE_LIST_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_REFERENCE_SLOT_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_SESSION_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_SESSION_MEMORY_REQUIREMENTS_KHR

    • VK_STRUCTURE_TYPE_VIDEO_SESSION_PARAMETERS_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_VIDEO_SESSION_PARAMETERS_UPDATE_INFO_KHR

版本历史

  • 修订版 0.1，2019-11-21 (Tony Zlatinski)

    • 初始草案

  • 修订版 0.2，2019-11-27 (Tony Zlatinski)

    • 使Vulkan视频核心在解码和编码之间通用

  • 修订版 1，2021 年 3 月 29 日 (Tony Zlatinski)

    • 规范和 API 更新。

  • 修订版 2，2021 年 8 月 1 日 (Srinath Kumarapuram)

    • 根据 Vulkan 命名约定，将 VkVideoCapabilitiesFlagBitsKHR 重命名为 VkVideoCapabilityFlagBitsKHR （以及它定义的枚举名称），并将 VkVideoCapabilitiesFlagsKHR 重命名为 VkVideoCapabilityFlagsKHR。

  • 修订版 3，2022-03-16 (Ahmed Abdelkhalek)

    • 将 Std 标头版本报告/请求从特定于编解码器操作的扩展移至此扩展。

    • 使 Std 标头版本特定于编解码器操作，而不是仅特定于编解码器。

  • 修订版 4，2022-05-30 (Daniel Rakos)

    • 重构视频格式查询 API 和相关语言

    • 用特定于视频的错误代码扩展 VkResult

  • 修订版 5，2022-08-11 (Daniel Rakos)

    • 添加 VkVideoSessionParametersCreateFlagsKHR

    • 删除 VkVideoCodingQualityPresetFlagsKHR

    • 将 VkQueueFamilyQueryResultStatusProperties2KHR 重命名为 VkQueueFamilyQueryResultStatusPropertiesKHR

    • 将 VkVideoQueueFamilyProperties2KHR 重命名为 VkQueueFamilyVideoPropertiesKHR

    • 将 VkVideoProfileKHR 重命名为 VkVideoProfileInfoKHR

    • 将 VkVideoProfilesKHR 重命名为 VkVideoProfileListInfoKHR

    • 将 VkVideoGetMemoryPropertiesKHR 重命名为 VkVideoSessionMemoryRequirementsKHR

    • 将 VkVideoBindMemoryKHR 重命名为 VkBindVideoSessionMemoryInfoKHR

    • 修复 VkPhysicalDeviceVideoFormatInfoKHR 和 VkVideoSessionMemoryRequirementsKHR 的 pNext 常量性

    • 修复位枚举类型 VkVideoCodecOperationFlagBitsKHR 和 VkVideoChromaSubsamplingFlagBitsKHR 中错误命名的值枚举

    • 从 VkVideoSessionCreateFlagBitsKHR 和 VkVideoCodingControlFlagBitsKHR 中删除不必要的默认值

    • 消除 VkVideoSessionMemoryRequirementsKHR 中的嵌套指针

    • 将 VkVideoPictureResourceKHR 重命名为 VkVideoPictureResourceInfoKHR

    • 将 VkVideoReferenceSlotKHR 重命名为 VkVideoReferenceSlotInfoKHR

  • 修订版 6，2022-09-18 (Daniel Rakos)

    • 将 VkVideoCapabilitiesKHR 和 VkVideoSessionCreateInfoKHR 的 maxReferencePicturesSlotsCount 和 maxReferencePicturesActiveCount 字段分别重命名为 maxDpbSlots 和 maxActiveReferencePictures，以阐明其含义

    • 在 VkVideoCapabilitiesKHR 中将 capabilityFlags 重命名为 flags

    • 在 VkVideoCapabilitiesKHR 中将 videoPictureExtentGranularity 重命名为 pictureAccessGranularity

    • 在 VkVideoCapabilitiesKHR 中将 minExtent 和 maxExtent 分别重命名为 minCodedExtent 和 maxCodedExtent

    • 在 VkVideoSessionCreateInfoKHR 中将 referencePicturesFormat 重命名为 referencePictureFormat

  • 修订版 7，2022-09-26 (Daniel Rakos)

    • 将 VkVideoReferenceSlotInfoKHR::slotIndex 的类型从 int8_t 更改为 int32_t

  • 修订版 8，2022-09-29 (Daniel Rakos)

    • 扩展不再是临时的。

VK_KHR_wayland_surface

名称字符串

VK_KHR_wayland_surface

扩展类型

实例扩展

注册扩展号

7

修订

6

批准状态

已批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

其他扩展元数据

上次修改日期

2015-11-28

IP 状态

没有已知的 IP 声明。

贡献者

  • Patrick Doane, Blizzard

  • Faith Ekstrand, Intel

  • Ian Elliott, LunarG

  • Courtney Goeltzenleuchter, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Antoine Labour, Google

  • Jon Leech, Khronos

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Ray Smith, ARM

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

描述

VK_KHR_wayland_surface 扩展是一个实例扩展。它提供了一种机制来创建一个 VkSurfaceKHR 对象（由 VK_KHR_surface 扩展定义），该对象引用 Wayland wl_surface，以及一个查询来确定是否支持渲染到 Wayland 合成器。

新命令

新结构

新位掩码

新枚举常量

  • VK_KHR_WAYLAND_SURFACE_EXTENSION_NAME

  • VK_KHR_WAYLAND_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_WAYLAND_SURFACE_CREATE_INFO_KHR

问题

1) Wayland 是否需要一种方法来查询特定物理设备与特定 Wayland 显示器之间的兼容性？这将是一个比 vkGetPhysicalDeviceSurfaceSupportKHR 更通用的查询：如果特定于 Wayland 的查询对于 ( VkPhysicalDevice, struct wl_display*) 对返回 VK_TRUE，则可以假定物理设备支持呈现到显示器上表面的任何 VkSurfaceKHR。

已解决：是的。添加了 vkGetPhysicalDeviceWaylandPresentationSupportKHR 以解决此问题。

2) 我们是否应该要求使用 vkCreateWaylandSurfaceKHR 创建的表面支持 VK_PRESENT_MODE_MAILBOX_KHR 呈现模式？

已解决：是的。Wayland 本质上是一个邮箱窗口系统，并且某些 Wayland 合成器交互需要邮箱支持才能按预期工作。虽然使用 VK_PRESENT_MODE_FIFO_KHR 可以处理这些交互，但如果没有死锁则更加困难，并且要求所有 Wayland 应用程序都能够支持仅支持 VK_PRESENT_MODE_FIFO_KHR 的实现会对应用程序开发人员造成繁重的限制。

版本历史

  • 修订版 1，2015-09-23 (Jesse Hall)

    • 基于 VK_EXT_KHR_swapchain（后来重命名为 VK_EXT_KHR_surface）的先前内容的初始草案。

  • 修订版 2，2015-10-02 (James Jones)

    • 添加了 vkGetPhysicalDeviceWaylandPresentationSupportKHR() 以解决问题 #1。

    • 调整了问题 #1 的措辞以匹配商定的解决方案。

    • 将“窗口”参数重命名为“表面”，以匹配 Wayland 约定。

  • 修订版 3，2015-10-26 (Ian Elliott)

    • 从 VK_EXT_KHR_wayland_surface 重命名为 VK_KHR_wayland_surface。

  • 修订版 4，2015-11-03 (Daniel Rakos)

    • 向 vkCreateWaylandSurfaceKHR 添加了分配回调。

  • 修订版 5，2015-11-28 (Daniel Rakos)

    • 更新了表面创建函数以采用 pCreateInfo 结构。

  • 修订版 6，2017-02-08 (Faith Ekstrand)

    • 添加了要求实现支持 VK_PRESENT_MODE_MAILBOX_KHR 的要求。

    • 添加了关于 vkQueuePresentKHR 和发送到合成器的 Wayland 请求之间的交互的措辞。

VK_KHR_win32_keyed_mutex

名称字符串

VK_KHR_win32_keyed_mutex

扩展类型

设备扩展

注册扩展号

76

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_memory_win32

联系方式

其他扩展元数据

上次修改日期

2016-10-21

IP 状态

没有已知的 IP 声明。

贡献者

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Carsten Rohde, NVIDIA

描述

希望将 Direct3D 11 内存对象导入 Vulkan API 的应用程序可能希望使用本机键控互斥机制来同步 Vulkan 和 Direct3D 之间对内存的访问。此扩展提供了一种方法，当应用程序向队列提交命令缓冲区时，可以访问与导入的 Vulkan 内存对象关联的键控互斥锁。

新结构

新枚举常量

  • VK_KHR_WIN32_KEYED_MUTEX_EXTENSION_NAME

  • VK_KHR_WIN32_KEYED_MUTEX_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_KHR

版本历史

  • 修订版 1，2016-10-21 (James Jones)

    • 初始修订版

VK_KHR_win32_surface

名称字符串

VK_KHR_win32_surface

扩展类型

实例扩展

注册扩展号

10

修订

6

批准状态

已批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

其他扩展元数据

上次修改日期

2017-04-24

IP 状态

没有已知的 IP 声明。

贡献者

  • Patrick Doane, Blizzard

  • Faith Ekstrand, Intel

  • Ian Elliott, LunarG

  • Courtney Goeltzenleuchter, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Antoine Labour, Google

  • Jon Leech, Khronos

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Ray Smith, ARM

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

描述

VK_KHR_win32_surface 扩展是一个实例扩展。它提供了一种机制来创建一个 VkSurfaceKHR 对象（由 VK_KHR_surface 扩展定义），该对象引用一个 Win32 HWND，以及一个用于确定是否支持渲染到 Windows 桌面的查询。

新命令

新结构体

新位掩码

新枚举常量

  • VK_KHR_WIN32_SURFACE_EXTENSION_NAME

  • VK_KHR_WIN32_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR

问题

1) Win32 是否需要一种方法来查询特定物理设备和特定屏幕之间的兼容性？物理设备和窗口之间的兼容性通常仅取决于窗口所在的屏幕。但是，在屏幕上没有窗口的情况下，没有明显的方法来识别屏幕。

已解决: 否。 虽然这可能很有用，但在 Win32 上没有明确的方法来执行此操作。但是，添加了一种方法来查询是否支持向整个 Windows 桌面进行演示。

2) 如果一个本地窗口对象 (HWND) 被一个图形 API 使用，然后又被另一个图形 API（其中一个是 Vulkan）使用，这些使用是否会相互干扰？

已解决：可以。

多个图形 API 使用一个窗口对象会导致未定义行为。当使用一个 Vulkan 实现时，这种行为可能会成功，但当使用另一个 Vulkan 实现时则会失败。潜在的失败包括

  • 在窗口对象上创建然后销毁翻转演示模型的 DXGI 交换链可能会阻止在同一窗口对象上成功执行 vkCreateSwapchainKHR。

  • 在窗口对象上创建然后销毁 VkSwapchainKHR 可能会阻止在同一窗口对象上创建位块传输模型的 DXGI 交换链。

  • 在窗口对象上创建然后销毁 VkSwapchainKHR 可以有效地将 SetPixelFormat 设置为与 OpenGL 应用程序选择的格式不同的格式。

  • 在一个 VkPhysicalDevice 上的窗口对象上创建然后销毁 VkSwapchainKHR 可能会阻止在同一窗口对象上成功执行 vkCreateSwapchainKHR，但在与不同的 Vulkan ICD 关联的不同 VkPhysicalDevice 上则不会。

在所有情况下，都可以通过创建一个新的窗口对象来解决该问题。

技术细节包括

  • 在窗口对象上创建 DXGI 交换链可以改变该对象，使其在剩余的生命周期内保持这种状态。即使在 DXGI 交换链被销毁后，这种改变仍然存在。这种改变可能会使符合标准的 Vulkan 实现无法在同一窗口对象上创建 VkSwapchainKHR。有关此更改的说明可以在 MSDN 文档的 DXGI_SWAP_EFFECT 的备注部分中找到。

  • 在窗口对象上调用 GDI 的 SetPixelFormat（OpenGL 的 WGL 层需要）会改变该对象，使其在剩余的生命周期内保持这种状态。SetPixelFormat 的 MSDN 文档解释说，一个窗口对象的像素格式只能设置一次。

  • 在窗口对象上创建 VkSwapchainKHR 可以改变该对象，使其在剩余的生命周期内保持这种状态。上述任何一种更改都可能作为 vkCreateSwapchainKHR 的副作用而发生。

版本历史

  • 修订版 1，2015-09-23 (Jesse Hall)

    • 基于 VK_EXT_KHR_swapchain（后来重命名为 VK_EXT_KHR_surface）的先前内容的初始草案。

  • 修订版 2，2015-10-02 (James Jones)

    • 为 win32 桌面添加了演示支持查询。

  • 修订版 3，2015-10-26 (Ian Elliott)

    • 从 VK_EXT_KHR_win32_surface 重命名为 VK_KHR_win32_surface。

  • 修订版 4，2015-11-03 (Daniel Rakos)

    • 向 vkCreateWin32SurfaceKHR 添加了分配回调。

  • 修订版 5，2015-11-28 (Daniel Rakos)

    • 更新了表面创建函数以采用 pCreateInfo 结构。

  • 修订版 6，2017-04-24 (Jeff Juliano)

    • 添加了问题 2，解决了在不同的图形 API 中或由不同的 Vulkan ICD 重复使用本地窗口对象的问题。

VK_KHR_workgroup_memory_explicit_layout

名称字符串

VK_KHR_workgroup_memory_explicit_layout

扩展类型

设备扩展

注册扩展号

337

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

  • Caio Marcelo de Oliveira Filho cmarcelo

其他扩展元数据

上次修改日期

2020-06-01

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Caio Marcelo de Oliveira Filho, Intel

  • Jeff Bolz, NVIDIA

  • Graeme Leese, Broadcom

  • Faith Ekstrand, Intel

  • Daniel Koch, NVIDIA

描述

此扩展为 SPV_KHR_workgroup_memory_explicit_layout SPIR-V 扩展添加了 Vulkan 支持，该扩展允许着色器显式定义 Workgroup 存储类内存的布局，并在计算着色器中创建来自该存储类的变量之间的别名。

别名功能允许在相同数据上使用不同的“视图”，因此着色器可以使用一种类型（例如，大型向量数组）从另一个存储类批量复制数据，然后使用更特定的类型使用数据。它还允许着色器对生命周期不重叠的数据进行别名，从而减少工作组内存的消耗量。

在 Vulkan 之上分层 OpenCL 也需要显式布局支持和某种形式的别名。

新结构体

新枚举常量

  • VK_KHR_WORKGROUP_MEMORY_EXPLICIT_LAYOUT_EXTENSION_NAME

  • VK_KHR_WORKGROUP_MEMORY_EXPLICIT_LAYOUT_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_WORKGROUP_MEMORY_EXPLICIT_LAYOUT_FEATURES_KHR

新的 SPIR-V 功能

版本历史

  • 修订版 1，2020-06-01 (Caio Marcelo de Oliveira Filho)

    • 初始版本

VK_KHR_xcb_surface

名称字符串

VK_KHR_xcb_surface

扩展类型

实例扩展

注册扩展号

6

修订

6

批准状态

已批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

其他扩展元数据

上次修改日期

2015-11-28

IP 状态

没有已知的 IP 声明。

贡献者

  • Patrick Doane, Blizzard

  • Faith Ekstrand, Intel

  • Ian Elliott, LunarG

  • Courtney Goeltzenleuchter, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Antoine Labour, Google

  • Jon Leech, Khronos

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Ray Smith, ARM

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

描述

VK_KHR_xcb_surface 扩展是一个实例扩展。它提供了一种机制来创建一个 VkSurfaceKHR 对象（由 VK_KHR_surface 扩展定义），该对象引用使用 XCB 客户端库的 X11 Window，以及一个用于确定通过 XCB 进行渲染支持的查询。

新命令

新结构体

新位掩码

新枚举常量

  • VK_KHR_XCB_SURFACE_EXTENSION_NAME

  • VK_KHR_XCB_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_XCB_SURFACE_CREATE_INFO_KHR

问题

1) XCB 是否需要一种方法来查询特定物理设备和特定屏幕之间的兼容性？这将比 vkGetPhysicalDeviceSurfaceSupportKHR 更通用的查询：如果它返回 VK_TRUE，那么可以认为该物理设备支持在屏幕上的任何窗口上进行显示。

已解决：是的，对于那些希望在创建窗口之前创建 VkDevice 的工具包来说，这是必需的。为了确保查询的可靠性，必须针对特定的 X 视觉效果而不是一般的屏幕进行查询。

版本历史

  • 修订版 1，2015-09-23 (Jesse Hall)

    • 基于 VK_EXT_KHR_swapchain（后来重命名为 VK_EXT_KHR_surface）的先前内容的初始草案。

  • 修订版 2，2015-10-02 (James Jones)

    • 为 (xcb_connection_t*, xcb_visualid_t) 对添加了显示支持查询。

    • 从 CreateXcbSurfaceKHR() 中删除了 “root” 参数，因为当指定同一屏幕上的窗口时，该参数是冗余的。

    • 调整了问题 #1 的措辞，并添加了商定的解决方案。

  • 修订版 3，2015-10-14 (Ian Elliott)

    • 再次从 CreateXcbSurfaceKHR() 中删除了 “root” 参数。

  • 修订版 4，2015-10-26 (Ian Elliott)

    • 将名称从 VK_EXT_KHR_xcb_surface 重命名为 VK_KHR_xcb_surface。

  • 修订版 5，2015-10-23 (Daniel Rakos)

    • 为 vkCreateXcbSurfaceKHR 添加了分配回调。

  • 修订版 6，2015-11-28 (Daniel Rakos)

    • 更新了表面创建函数以采用 pCreateInfo 结构。

VK_KHR_xlib_surface

名称字符串

VK_KHR_xlib_surface

扩展类型

实例扩展

注册扩展号

5

修订

6

批准状态

已批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

其他扩展元数据

上次修改日期

2015-11-28

IP 状态

没有已知的 IP 声明。

贡献者

  • Patrick Doane, Blizzard

  • Faith Ekstrand, Intel

  • Ian Elliott, LunarG

  • Courtney Goeltzenleuchter, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Antoine Labour, Google

  • Jon Leech, Khronos

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Ray Smith, ARM

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

描述

VK_KHR_xlib_surface 扩展是一个实例扩展。它提供了一种机制来创建一个 VkSurfaceKHR 对象（由 VK_KHR_surface 扩展定义），该对象引用使用 Xlib 客户端库的 X11 Window，以及一个用于确定通过 Xlib 进行渲染支持的查询。

新命令

新结构体

新位掩码

新枚举常量

  • VK_KHR_XLIB_SURFACE_EXTENSION_NAME

  • VK_KHR_XLIB_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_XLIB_SURFACE_CREATE_INFO_KHR

问题

1) X11 是否需要一种方法来查询特定物理设备和特定屏幕之间的兼容性？这将比 vkGetPhysicalDeviceSurfaceSupportKHR 更通用的查询；如果它返回 VK_TRUE，那么可以认为该物理设备支持在屏幕上的任何窗口上进行显示。

已解决：是的，对于那些希望在创建窗口之前创建 VkDevice 的工具包来说，这是必需的。为了确保查询的可靠性，必须针对特定的 X 视觉效果而不是一般的屏幕进行查询。

版本历史

  • 修订版 1，2015-09-23 (Jesse Hall)

    • 基于 VK_EXT_KHR_swapchain（后来重命名为 VK_EXT_KHR_surface）的先前内容的初始草案。

  • 修订版 2，2015-10-02 (James Jones)

    • 为 (Display*, VisualID) 对添加了显示支持查询。

    • 从 CreateXlibSurfaceKHR() 中删除了 “root” 参数，因为当指定同一屏幕上的窗口时，该参数是冗余的。

    • 添加了适当的 X 错误。

    • 调整了问题 #1 的措辞，并添加了商定的解决方案。

  • 修订版 3，2015-10-14 (Ian Elliott)

    • 将此扩展名从 VK_EXT_KHR_x11_surface 重命名为 VK_EXT_KHR_xlib_surface。

  • 修订版 4，2015-10-26 (Ian Elliott)

    • 将名称从 VK_EXT_KHR_xlib_surface 重命名为 VK_KHR_xlib_surface。

  • 修订版 5，2015-11-03 (Daniel Rakos)

    • 为 vkCreateXlibSurfaceKHR 添加了分配回调。

  • 修订版 6，2015-11-28 (Daniel Rakos)

    • 更新了表面创建函数以采用 pCreateInfo 结构。

VK_EXT_acquire_drm_display

名称字符串

VK_EXT_acquire_drm_display

扩展类型

实例扩展

注册扩展号

286

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_EXT_direct_mode_display

联系方式

其他扩展元数据

上次修改日期

2021-06-09

IP 状态

没有已知的 IP 声明。

贡献者

  • Simon Zeni, Status Holdings, Ltd.

描述

此扩展允许应用程序使用直接渲染管理器 (DRM) 接口独占控制显示器。 获取后，显示器将完全受应用程序控制，直到释放显示器或拔下连接器。

新命令

新枚举常量

  • VK_EXT_ACQUIRE_DRM_DISPLAY_EXTENSION_NAME

  • VK_EXT_ACQUIRE_DRM_DISPLAY_SPEC_VERSION

问题

无。

版本历史

  • 修订版 1，2021-05-11 (Simon Zeni)

    • 初始草案

VK_EXT_acquire_xlib_display

名称字符串

VK_EXT_acquire_xlib_display

扩展类型

实例扩展

注册扩展号

90

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_EXT_direct_mode_display

联系方式

其他扩展元数据

上次修改日期

2016-12-13

IP 状态

没有已知的 IP 声明。

贡献者

  • Dave Airlie, Red Hat

  • Pierre Boudier, NVIDIA

  • James Jones, NVIDIA

  • Damien Leone, NVIDIA

  • Pierre-Loup Griffais, Valve

  • Liam Middlebrook, NVIDIA

  • Daniel Vetter, Intel

描述

此扩展允许应用程序独占控制当前与 X11 屏幕关联的显示器。获取控制权后，显示器将与 X11 屏幕解除关联，直到释放控制权或关闭指定的显示连接。实质上，X11 屏幕的行为将如同显示器已被拔掉，直到控制权被释放。

新命令

新的枚举常量

  • VK_EXT_ACQUIRE_XLIB_DISPLAY_EXTENSION_NAME

  • VK_EXT_ACQUIRE_XLIB_DISPLAY_SPEC_VERSION

问题

1) vkAcquireXlibDisplayEXT 应该接受 RandR 显示 ID 作为输入，还是 Vulkan 显示句柄作为输入？

已解决: Vulkan 显示句柄。否则，将无法指定那些被某些原生平台或特定厂商机制阻止包含在 X11 显示列表中的显示句柄。

2) 应用程序如何确定哪个 RandR 显示对应于哪个 Vulkan 显示？

已解决: 为此目的引入了一个新函数 vkGetRandROutputDisplayEXT。

3) vkGetRandROutputDisplayEXT 应该作为此扩展的一部分，还是作为通用的 Vulkan / RandR 或 Vulkan / Xlib 扩展的一部分？

已解决: 为了避免另一个扩展，将其包含在此扩展中。

版本历史

  • 修订版 1，2016-12-13 (James Jones)

    • 初始草案

VK_EXT_astc_decode_mode

名称字符串

VK_EXT_astc_decode_mode

扩展类型

设备扩展

注册扩展号

68

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2018-08-07

贡献者

  • Jan-Harald Fredriksen, Arm

描述

现有规范要求低动态范围 (LDR) ASTC 纹理每个分量都解压为 FP16 值。在许多情况下，将 LDR 纹理解压为较低精度的中间结果可以获得可接受的图像质量。LDR 纹理的源材料通常以 8 位 UNORM 值编写，因此解码为 FP16 值几乎没有增加价值。另一方面，降低解码结果的精度会减少解压数据的大小，从而可能提高纹理缓存性能并节省功耗。

此扩展的目标是在现有 ASTC 纹理数据上实现这种效率提升。这是通过赋予应用程序选择中间解码精度的能力来实现的。

提供了三个解码选项

  • 解码为 VK_FORMAT_R16G16B16A16_SFLOAT 精度：这是默认值，并且与核心 API 中要求的行为匹配。

  • 解码为 VK_FORMAT_R8G8B8A8_UNORM 精度：在 LDR 模式下作为选项提供。

  • 解码为 VK_FORMAT_E5B9G9R9_UFLOAT_PACK32 精度：在 LDR 和 HDR 模式下都作为选项提供。在此模式下，无法表示负值，并且会将其钳制为零。alpha 分量被忽略，结果就像 alpha 为 1.0 一样。此解码模式是可选的，可以通过物理设备属性查询支持。

新的结构体

新的枚举常量

  • VK_EXT_ASTC_DECODE_MODE_EXTENSION_NAME

  • VK_EXT_ASTC_DECODE_MODE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ASTC_DECODE_FEATURES_EXT

问题

1) 是否允许实现以高于所请求的精度进行解码？

RESOLUTION: No.
If we allow this, then this extension could be exposed on all
implementations that support ASTC.
But developers would have no way of knowing what precision was actually
used, and thus whether the image quality is sufficient at reduced
precision.

2) 解码模式应该是图像视图状态还是采样器状态？

RESOLUTION: Image view state only.
Some implementations treat the different decode modes as different
texture formats.

示例

创建一个解码为 VK_FORMAT_R8G8B8A8_UNORM 精度的图像视图

    VkImageViewASTCDecodeModeEXT decodeMode =
    {
        .sType = VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT,
        .pNext = NULL,
        .decodeMode = VK_FORMAT_R8G8B8A8_UNORM
    };

    VkImageViewCreateInfo createInfo =
    {
        .sType = VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO,
        .pNext = &decodeMode,
        // flags, image, viewType set to application-desired values
        .format = VK_FORMAT_ASTC_8x8_UNORM_BLOCK,
        // components, subresourceRange set to application-desired values
    };

    VkImageView imageView;
    VkResult result = vkCreateImageView(
        device,
        &createInfo,
        NULL,
        &imageView);

版本历史

  • 修订版 1，2018-08-07 (Jan-Harald Fredriksen)

    • 初始修订版

VK_EXT_attachment_feedback_loop_dynamic_state

名称字符串

VK_EXT_attachment_feedback_loop_dynamic_state

扩展类型

设备扩展

注册扩展号

525

修订

1

批准状态

已批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
    或
     Vulkan 版本 1.1
和
VK_EXT_attachment_feedback_loop_layout

特殊用途
联系方式

  • Mike Blumenkrantz zmike

扩展提案

VK_EXT_attachment_feedback_loop_dynamic_state

其他扩展元数据

上次修改日期

2023-04-28

IP 状态

没有已知的 IP 声明。

贡献者

  • Mike Blumenkrantz, Valve

  • Daniel Story, Nintendo

  • Stu Smith, AMD

  • Samuel Pitoiset, Valve

  • Ricardo Garcia, Igalia

描述

此扩展添加了对在命令缓冲区上动态设置附件反馈循环的支持。

新的命令

新的结构体

新的枚举常量

  • VK_EXT_ATTACHMENT_FEEDBACK_LOOP_DYNAMIC_STATE_EXTENSION_NAME

  • VK_EXT_ATTACHMENT_FEEDBACK_LOOP_DYNAMIC_STATE_SPEC_VERSION

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_ATTACHMENT_FEEDBACK_LOOP_ENABLE_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ATTACHMENT_FEEDBACK_LOOP_DYNAMIC_STATE_FEATURES_EXT

版本历史

  • 修订版 1，2023-04-28 (Mike Blumenkrantz)

    • 初始修订版

VK_EXT_attachment_feedback_loop_layout

名称字符串

VK_EXT_attachment_feedback_loop_layout

扩展类型

设备扩展

注册扩展号

340

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式
扩展提案

VK_EXT_attachment_feedback_loop_layout

其他扩展元数据

上次修改日期

2022-04-04

IP 状态

没有已知的 IP 声明。

贡献者

  • Joshua Ashton, Valve

  • Faith Ekstrand, Collabora

  • Bas Nieuwenhuizen, Google

  • Samuel Iglesias Gonsálvez, Igalia

  • Ralph Potter, Samsung

  • Jan-Harald Fredriksen, Arm

  • Ricardo Garcia, Igalia

描述

此扩展添加了一个新的图像布局 VK_IMAGE_LAYOUT_ATTACHMENT_FEEDBACK_LOOP_OPTIMAL_EXT，它允许应用程序拥有一个图像布局，在该布局中，它们能够在给定的渲染过程中渲染和采样/获取图像的相同子资源。

新的结构体

新的枚举常量

  • VK_EXT_ATTACHMENT_FEEDBACK_LOOP_LAYOUT_EXTENSION_NAME

  • VK_EXT_ATTACHMENT_FEEDBACK_LOOP_LAYOUT_SPEC_VERSION

  • 扩展 VkDependencyFlagBits

    • VK_DEPENDENCY_FEEDBACK_LOOP_BIT_EXT

  • 扩展 VkImageLayout

    • VK_IMAGE_LAYOUT_ATTACHMENT_FEEDBACK_LOOP_OPTIMAL_EXT

  • 扩展 VkImageUsageFlagBits

    • VK_IMAGE_USAGE_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_COLOR_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT

    • VK_PIPELINE_CREATE_DEPTH_STENCIL_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ATTACHMENT_FEEDBACK_LOOP_LAYOUT_FEATURES_EXT

版本历史

  • 修订版 2，2022-04-04 (Joshua Ashton)

    • 从 VALVE 重命名为 EXT。

  • 修订版 1，2021-03-09 (Joshua Ashton)

    • 初始草案。

VK_EXT_blend_operation_advanced

名称字符串

VK_EXT_blend_operation_advanced

扩展类型

设备扩展

注册扩展号

149

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2017-06-12

贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展添加了许多“高级”混合操作，这些操作可以用于执行新的颜色混合操作，其中许多操作比未扩展的 Vulkan 提供的标准混合模式更复杂。此扩展需要不同风格的用法，具体取决于硬件支持的级别和启用的功能

在未扩展的 Vulkan 中，混合操作的集合是有限的，并且可以非常简单地表达。VK_BLEND_OP_MIN 和 VK_BLEND_OP_MAX 混合操作只是简单地计算源颜色和目标颜色分量的逐分量最小值或最大值。VK_BLEND_OP_ADD、VK_BLEND_OP_SUBTRACT 和 VK_BLEND_OP_REVERSE_SUBTRACT 模式将源颜色和目标颜色乘以源因子和目标因子，然后将两个乘积相加或相减。这种有限的操作集支持许多常见的混合操作，但排除了在许多专用图像 API 中常见的更复杂的透明度和混合操作的使用。

此扩展提供了一些新的“高级”混合操作。与使用 VK_BLEND_OP_ADD 的传统混合操作不同，这些混合方程式不使用 VkBlendFactor 指定的源因子和目标因子。相反，每个混合操作都基于源颜色和目标颜色指定一个完整的方程式。这些新的混合操作用于 RGB 和 alpha 分量；它们必须不用于执行单独的 RGB 和 alpha 混合（通过颜色和 alpha VkBlendOp 的不同值）。

这些混合操作使用预乘颜色执行，其中 RGB 颜色可以根据 VkPipelineColorBlendAdvancedStateCreateInfoEXT 的 srcPremultiplied 和 dstPremultiplied 成员被认为是预乘或非预乘的 alpha。如果颜色被认为是非预乘的，则 (R,G,B) 颜色分量在混合之前乘以 alpha 分量。对于范围 [0,1] 内的非预乘颜色分量，相应的预乘颜色分量的值将在范围 [0 × A, 1 × A] 内。

许多这些高级混合方程式的公式是，当混合具有部分覆盖的源颜色和目标颜色时，有三个单独的贡献：来自源和目标都覆盖的部分、来自仅由源覆盖的部分，以及来自仅由目标覆盖的部分。混合参数 VkPipelineColorBlendAdvancedStateCreateInfoEXT::blendOverlap 可以用于指定源像素覆盖和目标像素覆盖之间的相关性。如果设置为 VK_BLEND_OVERLAP_CONJOINT_EXT，则认为源和目标具有最大重叠，就像在彼此之上绘制两个对象一样。如果设置为 VK_BLEND_OVERLAP_DISJOINT_EXT，则认为源和目标具有最小重叠，就像在将复杂的 polygon 细分为不相交的单个三角形时一样。如果设置为 VK_BLEND_OVERLAP_UNCORRELATED_EXT，则假设源和目标覆盖在像素内没有空间相关性。

除了在不支持 advancedBlendCoherentOperations 的实现上存在一致性问题外，此扩展还有几个值得注意的限制。首先，新的混合操作可以使用的颜色附件数量有限，如 VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT::advancedBlendMaxColorAttachments 所指示。此外，混合精度可能限制为 16 位浮点数，这可能会导致具有 32 位浮点数分量的帧缓冲格式的精度和动态范围损失，以及具有 12 位和 16 位有符号或无符号归一化整数分量的格式的精度损失。

新结构

新枚举

新枚举常量

  • VK_EXT_BLEND_OPERATION_ADVANCED_EXTENSION_NAME

  • VK_EXT_BLEND_OPERATION_ADVANCED_SPEC_VERSION

  • 扩展 VkAccessFlagBits

    • VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT

  • 扩展 VkBlendOp

    • VK_BLEND_OP_BLUE_EXT

    • VK_BLEND_OP_COLORBURN_EXT

    • VK_BLEND_OP_COLORDODGE_EXT

    • VK_BLEND_OP_CONTRAST_EXT

    • VK_BLEND_OP_DARKEN_EXT

    • VK_BLEND_OP_DIFFERENCE_EXT

    • VK_BLEND_OP_DST_ATOP_EXT

    • VK_BLEND_OP_DST_EXT

    • VK_BLEND_OP_DST_IN_EXT

    • VK_BLEND_OP_DST_OUT_EXT

    • VK_BLEND_OP_DST_OVER_EXT

    • VK_BLEND_OP_EXCLUSION_EXT

    • VK_BLEND_OP_GREEN_EXT

    • VK_BLEND_OP_HARDLIGHT_EXT

    • VK_BLEND_OP_HARDMIX_EXT

    • VK_BLEND_OP_HSL_COLOR_EXT

    • VK_BLEND_OP_HSL_HUE_EXT

    • VK_BLEND_OP_HSL_LUMINOSITY_EXT

    • VK_BLEND_OP_HSL_SATURATION_EXT

    • VK_BLEND_OP_INVERT_EXT

    • VK_BLEND_OP_INVERT_OVG_EXT

    • VK_BLEND_OP_INVERT_RGB_EXT

    • VK_BLEND_OP_LIGHTEN_EXT

    • VK_BLEND_OP_LINEARBURN_EXT

    • VK_BLEND_OP_LINEARDODGE_EXT

    • VK_BLEND_OP_LINEARLIGHT_EXT

    • VK_BLEND_OP_MINUS_CLAMPED_EXT

    • VK_BLEND_OP_MINUS_EXT

    • VK_BLEND_OP_MULTIPLY_EXT

    • VK_BLEND_OP_OVERLAY_EXT

    • VK_BLEND_OP_PINLIGHT_EXT

    • VK_BLEND_OP_PLUS_CLAMPED_ALPHA_EXT

    • VK_BLEND_OP_PLUS_CLAMPED_EXT

    • VK_BLEND_OP_PLUS_DARKER_EXT

    • VK_BLEND_OP_PLUS_EXT

    • VK_BLEND_OP_RED_EXT

    • VK_BLEND_OP_SCREEN_EXT

    • VK_BLEND_OP_SOFTLIGHT_EXT

    • VK_BLEND_OP_SRC_ATOP_EXT

    • VK_BLEND_OP_SRC_EXT

    • VK_BLEND_OP_SRC_IN_EXT

    • VK_BLEND_OP_SRC_OUT_EXT

    • VK_BLEND_OP_SRC_OVER_EXT

    • VK_BLEND_OP_VIVIDLIGHT_EXT

    • VK_BLEND_OP_XOR_EXT

    • VK_BLEND_OP_ZERO_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BLEND_OPERATION_ADVANCED_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BLEND_OPERATION_ADVANCED_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_COLOR_BLEND_ADVANCED_STATE_CREATE_INFO_EXT

问题

无。

版本历史

  • 修订版 1，2017-06-12 (Jeff Bolz)

    • 内部修订

  • 修订版 2，2017-06-12 (Jeff Bolz)

    • 内部修订

VK_EXT_border_color_swizzle

名称字符串

VK_EXT_border_color_swizzle

扩展类型

设备扩展

注册扩展号

412

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_EXT_custom_border_color

特殊用途
联系方式

其他扩展元数据

上次修改日期

2021-10-12

IP 状态

没有已知的 IP 声明。

贡献者

  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, Arm

  • Ricardo Garcia, Igalia

  • Shahbaz Youssefi, Google

  • Stu Smith, AMD

描述

在发布 VK_EXT_custom_border_color 之后，发现当将使用自定义边框颜色的采样器与组件映射不是恒等映射的图像视图组合时，某些实现具有未定义的行为。

由于 VK_EXT_custom_border_color 已经发布，因此创建了这个新的扩展 VK_EXT_border_color_swizzle 来定义自定义边框颜色与非恒等图像视图混洗之间的交互，并为必须预先混洗采样器边框颜色以匹配其组合的图像视图组件映射的实现提供了一种解决方法。

此扩展还定义了具有不透明黑色边框颜色的采样器和具有非恒等组件混洗的图像视图之间的行为，这之前是未定义的。

新结构

新枚举常量

  • VK_EXT_BORDER_COLOR_SWIZZLE_EXTENSION_NAME

  • VK_EXT_BORDER_COLOR_SWIZZLE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BORDER_COLOR_SWIZZLE_FEATURES_EXT

    • VK_STRUCTURE_TYPE_SAMPLER_BORDER_COLOR_COMPONENT_MAPPING_CREATE_INFO_EXT

问题

无。

版本历史

  • 修订版 1，2021-10-12 (Piers Daniell)

    • 内部修订。

VK_EXT_color_write_enable

名称字符串

VK_EXT_color_write_enable

扩展类型

设备扩展

注册扩展号

382

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2020-02-25

IP 状态

没有已知的 IP 声明。

贡献者

  • Sharif Elcott, Google

  • Tobias Hector, AMD

  • Piers Daniell, NVIDIA

描述

此扩展允许通过管道动态状态有选择地启用和禁用对输出颜色附件的写入。

此新状态的预期用例与 colorWriteMask 的用例基本相同，例如选择性禁用写入以避免子通道之间的反馈循环或节省未使用的输出的带宽。通过使状态动态化，一个额外的好处是能够通过着色器减少管线数量和管线切换，这些着色器写入所需数据的超集，其中子集是动态选择的。使用新的状态 colorWriteEnable 而不是使 colorWriteMask 动态的原因是，在许多实现中，colorWriteMask 状态的更灵活的每组件语义无法以高性能的方式实现动态。

新命令

新结构体

新枚举常量

  • VK_EXT_COLOR_WRITE_ENABLE_EXTENSION_NAME

  • VK_EXT_COLOR_WRITE_ENABLE_SPEC_VERSION

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_COLOR_WRITE_ENABLE_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COLOR_WRITE_ENABLE_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_COLOR_WRITE_CREATE_INFO_EXT

版本历史

  • 修订版 1，2020-01-25 (Sharif Elcott)

    • 内部修订

VK_EXT_conditional_rendering

名称字符串

VK_EXT_conditional_rendering

扩展类型

设备扩展

注册扩展号

82

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2018-05-21

IP 状态

没有已知的 IP 声明。

贡献者

  • Vikram Kushwaha, NVIDIA

  • Daniel Rakos, AMD

  • Jesse Hall, Google

  • Jeff Bolz, NVIDIA

  • Piers Daniell, NVIDIA

  • Stuart Smith, Imagination Technologies

描述

此扩展允许一个或多个渲染命令的执行取决于缓冲区内存中的值。这可以帮助应用程序通过有条件地丢弃渲染命令而无需应用程序干预来减少延迟。条件渲染命令仅限于在条件渲染块内的绘制、计算调度和清除附件。

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_EXT_CONDITIONAL_RENDERING_EXTENSION_NAME

  • VK_EXT_CONDITIONAL_RENDERING_SPEC_VERSION

  • 扩展 VkAccessFlagBits

    • VK_ACCESS_CONDITIONAL_RENDERING_READ_BIT_EXT

  • 扩展 VkBufferUsageFlagBits

    • VK_BUFFER_USAGE_CONDITIONAL_RENDERING_BIT_EXT

  • 扩展 VkPipelineStageFlagBits

    • VK_PIPELINE_STAGE_CONDITIONAL_RENDERING_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_CONDITIONAL_RENDERING_INFO_EXT

    • VK_STRUCTURE_TYPE_CONDITIONAL_RENDERING_BEGIN_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CONDITIONAL_RENDERING_FEATURES_EXT

问题

1) 条件渲染是否应影响复制和 Blit 命令？

已解决：条件渲染不应影响复制和 Blit。

2) 当主命令缓冲区中条件渲染处于活动状态时，是否应允许执行辅助命令缓冲区？

已解决：如果 conditionalRenderingEnable 设置为 VK_TRUE，则辅助命令缓冲区中的渲染命令将受主命令缓冲区中活动的条件渲染的影响。如果 conditionalRenderingEnable 为 VK_FALSE，则条件渲染必须不在主命令缓冲区中处于活动状态。

示例

无。

版本历史

  • 修订版 1，2018-04-19 (Vikram Kushwaha)

    • 第一个版本

  • 修订版 2，2018-05-21 (Vikram Kushwaha)

    • 添加新的管线阶段、访问标志，并将条件渲染限制为子通道或整个渲染过程。

VK_EXT_conservative_rasterization

名称字符串

VK_EXT_conservative_rasterization

扩展类型

设备扩展

注册扩展号

102

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2020-06-09

交互和外部依赖

  • 如果使用 VkPhysicalDeviceConservativeRasterizationPropertiesEXT::fullyCoveredFragmentShaderInputVariable 功能，则此扩展需要 SPV_EXT_fragment_fully_covered。

  • 如果使用 VkPhysicalDeviceConservativeRasterizationPropertiesEXT::conservativeRasterizationPostDepthCoverage 功能，则此扩展需要 SPV_KHR_post_depth_coverage。

  • 如果使用 VkPhysicalDeviceConservativeRasterizationPropertiesEXT::fullyCoveredFragmentShaderInputVariable 功能，则此扩展为 GL_NV_conservative_raster_underestimation 提供 API 支持。

贡献者

  • Daniel Koch, NVIDIA

  • Daniel Rakos, AMD

  • Jeff Bolz, NVIDIA

  • Slawomir Grajewski, Intel

  • Stu Smith, Imagination Technologies

描述

此扩展添加了一种称为保守光栅化的新光栅化模式。保守光栅化有两种模式：过估计和低估计。

启用过估计时，如果图元（包括其边缘）的任何部分覆盖矩形像素区域（包括其边）的任何部分，则会生成一个片段，其中所有覆盖样本都已打开。此扩展通过考虑过估计的差异，允许实现中的一些变化，其中生成的图元大小在其每个边缘处增加一些子像素量，以进一步增加保守的像素覆盖率。实现可以允许应用程序指定超出实现已完成的基本过估计的额外过估计。它还允许实现要么剔除退化图元，要么对其进行光栅化。

启用低估计时，仅当矩形像素区域完全被生成的图元覆盖时，才会生成片段。如果实现支持，则当一个像素矩形被完全覆盖时，名为 FullyCoveredEXT 的片段着色器输入变量内置函数将设置为 true。着色器变量在过估计或低估计模式下都起作用。

实现可以通过丢弃退化三角形和线或为其生成保守片段来处理它们。退化三角形是指在光栅化器将它们量化到定点像素网格后最终面积为零的那些三角形。退化线是指在量化后长度为零的那些线。

新结构体

新枚举

新位掩码

新枚举常量

  • VK_EXT_CONSERVATIVE_RASTERIZATION_EXTENSION_NAME

  • VK_EXT_CONSERVATIVE_RASTERIZATION_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CONSERVATIVE_RASTERIZATION_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_CONSERVATIVE_STATE_CREATE_INFO_EXT

新内置变量

新 SPIR-V 功能

版本历史

  • 修订版 1.1，2020-09-06 (Piers Daniell)

    • 添加缺少的 SPIR-V 和 GLSL 依赖项。

  • 修订版 1，2017-08-28 (Piers Daniell)

    • 内部修订

VK_EXT_custom_border_color

名称字符串

VK_EXT_custom_border_color

扩展类型

设备扩展

注册扩展号

288

修订

12

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

其他扩展元数据

上次修改日期

2020-04-16

IP 状态

没有已知的 IP 声明。

贡献者

  • Joshua Ashton, Valve

  • Hans-Kristian Arntzen, Valve

  • Philip Rebohle, Valve

  • Liam Middlebrook, NVIDIA

  • Jeff Bolz, NVIDIA

  • Tobias Hector, AMD

  • Faith Ekstrand, Intel

  • Spencer Fricke, Samsung Electronics

  • Graeme Leese, Broadcom

  • Jesse Hall, Google

  • Jan-Harald Fredriksen, ARM

  • Tom Olson, ARM

  • Stuart Smith, Imagination Technologies

  • Donald Scorgie, Imagination Technologies

  • Alex Walters, Imagination Technologies

  • Peter Quayle, Imagination Technologies

描述

此扩展提供跨供应商的功能，用于指定当采样器寻址模式 VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_BORDER 被使用时使用的自定义边框颜色。

要创建一个使用自定义边框颜色的采样器，请将 VkSamplerCreateInfo::borderColor 设置为以下之一：

  • VK_BORDER_COLOR_FLOAT_CUSTOM_EXT

  • VK_BORDER_COLOR_INT_CUSTOM_EXT

当使用 VK_BORDER_COLOR_FLOAT_CUSTOM_EXT 或 VK_BORDER_COLOR_INT_CUSTOM_EXT 时，应用程序必须在 VkSamplerCreateInfo 的 pNext 链中提供一个 VkSamplerCustomBorderColorCreateInfoEXT。

新结构体

新枚举常量

  • VK_EXT_CUSTOM_BORDER_COLOR_EXTENSION_NAME

  • VK_EXT_CUSTOM_BORDER_COLOR_SPEC_VERSION

  • 扩展 VkBorderColor

    • VK_BORDER_COLOR_FLOAT_CUSTOM_EXT

    • VK_BORDER_COLOR_INT_CUSTOM_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUSTOM_BORDER_COLOR_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUSTOM_BORDER_COLOR_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_SAMPLER_CUSTOM_BORDER_COLOR_CREATE_INFO_EXT

问题

1) 边框颜色值应该使用 VkClearColorValue 还是我们应该有自己的结构体/联合体？我们需要指定组件的输入值的类型吗？如果在这里使用 VkClearColorValue，则更需要考虑这个问题，因为它提供了浮点数、整数和无符号整数类型的联合。

已解决：将重用现有的 VkClearColorValue 结构，以便轻松利用浮点数、整数和无符号整数的 borderColor 类型。

2) 对于支持有限数量边框颜色的硬件，如果超出该数量会发生什么？这应该由驱动程序在应用程序不知情的情况下处理吗？在第 1 版中，我们使用新的对象类型解决了这个问题，但是这可能会导致额外的系统资源消耗，否则是不需要的。

已解决：添加了 VkPhysicalDeviceCustomBorderColorPropertiesEXT::maxCustomBorderColorSamplers 来跟踪特定于实现的限制，以及处理溢出的“有效使用”语句。

3) 这应该完全支持不可变采样器，还是应该通过一个特性位来支持？一些实现可能不支持不可变采样器上的自定义边框颜色 - 对于那些可以支持它的实现来说，启用它值得吗，还是应该完全禁止它？

已解决：禁止创建具有自定义边框颜色的采样器为不可变的。这解决了自定义边框颜色是 LUT 索引而不是直接嵌入到采样器状态的实现的担忧。

4) UINT 和 SINT（无符号整数和有符号整数）边框颜色类型应该分开，还是应该合并为一个通用的 INT（整数）类型？

已解决：分开它们没有多大意义，因为现有的固定边框颜色类型没有这种区别，而且在硬件上没有理由这样做。这种分离也会给应用程序带来不必要的工作和考虑。

版本历史

  • 版本 1, 2019-10-10 (Joshua Ashton)

    • 内部修订。

  • 版本 2, 2019-10-11 (Liam Middlebrook)

    • 移除 VkCustomBorderColor 对象和相关函数

    • 添加有关自定义边框颜色数量的硬件限制的问题

  • 版本 3, 2019-10-12 (Joshua Ashton)

    • 重新暴露唯一边框颜色最大数量的限制

    • 添加有关边框颜色跟踪的额外细节

    • 修复拼写错误

  • 版本 4, 2019-10-12 (Joshua Ashton)

    • 将 maxUniqueCustomBorderColors 从 VkDeviceSize 更改为 uint32_t

  • 版本 5, 2019-10-14 (Liam Middlebrook)

    • 添加了特性位

  • 版本 6, 2019-10-15 (Joshua Ashton)

    • 类型化 VK_BORDER_COLOR_CUSTOM

    • 修复 VkSamplerCustomBorderColorCreateInfoEXT 的 pNext 的常量性

  • 版本 7, 2019-11-26 (Liam Middlebrook)

    • 将 maxUniqueCustomBorderColors 重命名为 maxCustomBorderColors

  • 版本 8, 2019-11-29 (Joshua Ashton)

    • 将 VkSamplerCustomBorderColorCreateInfoEXT 的 borderColor 成员重命名为 customBorderColor

  • 版本 9, 2020-02-19 (Joshua Ashton)

    • 将 maxCustomBorderColors 重命名为 maxCustomBorderColorSamplers

  • 版本 10, 2020-02-21 (Joshua Ashton)

    • 在 VkSamplerCustomBorderColorCreateInfoEXT 中添加了格式和特性位

  • 版本 11, 2020-04-07 (Joshua Ashton)

    • 删除了 UINT/SINT 边框颜色差异，合并了类型

  • 版本 12, 2020-04-16 (Joshua Ashton)

    • 为了保持一致性，将 VK_BORDER_COLOR_CUSTOM_FLOAT_EXT 重命名为 VK_BORDER_COLOR_FLOAT_CUSTOM_EXT

VK_EXT_debug_utils

名称字符串

VK_EXT_debug_utils

扩展类型

实例扩展

注册扩展号

129

修订

2

批准状态

已批准

扩展和版本依赖关系

无

特殊用途
联系方式

其他扩展元数据

上次修改日期

2020-04-03

修订

2

IP 状态

没有已知的 IP 声明。

依赖项

  • 此扩展是针对 Vulkan API 的 1.0 版本编写的。

  • 需要 VkObjectType

贡献者

  • Mark Young, LunarG

  • Baldur Karlsson

  • Ian Elliott, Google

  • Courtney Goeltzenleuchter, Google

  • Karl Schultz, LunarG

  • Mark Lobodzinski, LunarG

  • Mike Schuchardt, LunarG

  • Jaakko Konttinen, AMD

  • Dan Ginsburg, Valve Software

  • Rolando Olivares, Epic Games

  • Dan Baker, Oxide Games

  • Kyle Spagnoli, NVIDIA

  • Jon Ashburn, LunarG

  • Piers Daniell, NVIDIA

描述

由于 Vulkan 接口的性质，开发人员和应用程序可用的错误信息非常少。通过使用 VK_EXT_debug_utils 扩展，开发人员可以获得更多信息。当与验证层结合使用时，将提供有关应用程序使用 Vulkan 的更详细反馈。

此扩展提供以下功能

  • 创建调试消息传递器的能力，它会将调试消息传递到应用程序提供的回调。

  • 使用名称或标签识别特定 Vulkan 对象以改进跟踪的能力。

  • 使用标签识别 VkQueue 或 VkCommandBuffer 中特定部分的能力，以帮助组织和在外部工具中进行离线分析。

此扩展与 VK_EXT_debug_report 和 VK_EXT_debug_marker 的主要区别在于，后两者使用 VkDebugReportObjectTypeEXT 来标识对象。此扩展使用核心的 VkObjectType 来代替 VkDebugReportObjectTypeEXT。进行此更改的主要原因是，自从创建了 VkObjectType 之后，不会再向 VkDebugReportObjectTypeEXT 添加新的对象类型句柄枚举值。

此外，此扩展结合了 VK_EXT_debug_report 和 VK_EXT_debug_marker 的功能，允许将对象名称和调试标记（现在称为标签）返回到应用程序的回调函数。这应有助于阐明调试消息的详细信息，包括：涉及哪些对象，以及消息可能发生在 VkQueue 或 VkCommandBuffer 中的哪个位置。

新对象类型

新命令

新结构体

新函数指针

新枚举

新位掩码

新枚举常量

  • VK_EXT_DEBUG_UTILS_EXTENSION_NAME

  • VK_EXT_DEBUG_UTILS_SPEC_VERSION

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_DEBUG_UTILS_MESSENGER_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT

    • VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CALLBACK_DATA_EXT

    • VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_NAME_INFO_EXT

    • VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_TAG_INFO_EXT

示例

示例 1

VK_EXT_debug_utils 允许应用程序向任何希望报告调试信息的 Vulkan 组件注册多个回调。某些回调可能会将信息记录到文件中，另一些回调可能会导致调试断点或其他应用程序定义的行为。即使没有启用验证层，应用程序也可以注册回调，但它们仅会为加载程序（loader）事件（如果已实现）和驱动程序事件调用。

为了捕获在创建或销毁实例时发生的事件，应用程序可以将 VkDebugUtilsMessengerCreateInfoEXT 结构链接到传递给 vkCreateInstance 的 VkInstanceCreateInfo 结构的 pNext 元素。

示例用法：创建三个回调对象。一个将使用 Windows OutputDebugString 将错误和警告记录到调试控制台。第二个将在发生错误时导致调试器在该回调处中断，第三个将警告记录到标准输出。

    extern VkInstance instance;
    VkResult res;
    VkDebugUtilsMessengerEXT cb1, cb2, cb3;

    // Must call extension functions through a function pointer:
    PFN_vkCreateDebugUtilsMessengerEXT pfnCreateDebugUtilsMessengerEXT = (PFN_vkCreateDebugUtilsMessengerEXT)vkGetInstanceProcAddr(instance, "vkCreateDebugUtilsMessengerEXT");
    PFN_vkDestroyDebugUtilsMessengerEXT pfnDestroyDebugUtilsMessengerEXT = (PFN_vkDestroyDebugUtilsMessengerEXT)vkGetInstanceProcAddr(instance, "vkDestroyDebugUtilsMessengerEXT");

    VkDebugUtilsMessengerCreateInfoEXT callback1 = {
        .sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT,
        .pNext = NULL,
        .flags = 0,
        .messageSeverity = VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT |
                           VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT,
        .messageType= VK_DEBUG_UTILS_MESSAGE_TYPE_GENERAL_BIT_EXT |
                      VK_DEBUG_UTILS_MESSAGE_TYPE_VALIDATION_BIT_EXT,
        .pfnUserCallback = myOutputDebugString,
        .pUserData = NULL
    };
    res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, NULL, &cb1);
    if (res != VK_SUCCESS) {
       // Do error handling for VK_ERROR_OUT_OF_MEMORY
    }

    callback1.messageSeverity = VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT;
    callback1.pfnUserCallback = myDebugBreak;
    callback1.pUserData = NULL;
    res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, NULL, &cb2);
    if (res != VK_SUCCESS) {
       // Do error handling for VK_ERROR_OUT_OF_MEMORY
    }

    VkDebugUtilsMessengerCreateInfoEXT callback3 = {
        .sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT,
        .pNext = NULL,
        .flags = 0,
        .messageSeverity = VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT,
        .messageType = VK_DEBUG_UTILS_MESSAGE_TYPE_GENERAL_BIT_EXT |
                       VK_DEBUG_UTILS_MESSAGE_TYPE_VALIDATION_BIT_EXT,
        .pfnUserCallback = mystdOutLogger,
        .pUserData = NULL
    };
    res = pfnCreateDebugUtilsMessengerEXT(instance, &callback3, NULL, &cb3);
    if (res != VK_SUCCESS) {
       // Do error handling for VK_ERROR_OUT_OF_MEMORY
    }

    ...

    // Remove callbacks when cleaning up
    pfnDestroyDebugUtilsMessengerEXT(instance, cb1, NULL);
    pfnDestroyDebugUtilsMessengerEXT(instance, cb2, NULL);
    pfnDestroyDebugUtilsMessengerEXT(instance, cb3, NULL);

示例 2

为图像关联一个名称，以便在外部工具中或在验证层中更容易进行调试，这些工具和验证层可以在错误消息中引用对象时打印友好的名称。

    extern VkInstance instance;
    extern VkDevice device;
    extern VkImage image;

    // Must call extension functions through a function pointer:
    PFN_vkSetDebugUtilsObjectNameEXT pfnSetDebugUtilsObjectNameEXT = (PFN_vkSetDebugUtilsObjectNameEXT)vkGetInstanceProcAddr(instance, "vkSetDebugUtilsObjectNameEXT");

    // Set a name on the image
    const VkDebugUtilsObjectNameInfoEXT imageNameInfo =
    {
        .sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_NAME_INFO_EXT,
        .pNext = NULL,
        .objectType = VK_OBJECT_TYPE_IMAGE,
        .objectHandle = (uint64_t)image,
        .pObjectName = "Brick Diffuse Texture",
    };

    pfnSetDebugUtilsObjectNameEXT(device, &imageNameInfo);

    // A subsequent error might print:
    //   Image 'Brick Diffuse Texture' (0xc0dec0dedeadbeef) is used in a
    //   command buffer with no memory bound to it.

示例 3

使用命名信息注释工作负载的区域，以便脱机分析工具可以显示更易用的提交命令可视化。

    extern VkInstance instance;
    extern VkCommandBuffer commandBuffer;

    // Must call extension functions through a function pointer:
    PFN_vkQueueBeginDebugUtilsLabelEXT pfnQueueBeginDebugUtilsLabelEXT = (PFN_vkQueueBeginDebugUtilsLabelEXT)vkGetInstanceProcAddr(instance, "vkQueueBeginDebugUtilsLabelEXT");
    PFN_vkQueueEndDebugUtilsLabelEXT pfnQueueEndDebugUtilsLabelEXT = (PFN_vkQueueEndDebugUtilsLabelEXT)vkGetInstanceProcAddr(instance, "vkQueueEndDebugUtilsLabelEXT");
    PFN_vkCmdBeginDebugUtilsLabelEXT pfnCmdBeginDebugUtilsLabelEXT = (PFN_vkCmdBeginDebugUtilsLabelEXT)vkGetInstanceProcAddr(instance, "vkCmdBeginDebugUtilsLabelEXT");
    PFN_vkCmdEndDebugUtilsLabelEXT pfnCmdEndDebugUtilsLabelEXT = (PFN_vkCmdEndDebugUtilsLabelEXT)vkGetInstanceProcAddr(instance, "vkCmdEndDebugUtilsLabelEXT");
    PFN_vkCmdInsertDebugUtilsLabelEXT pfnCmdInsertDebugUtilsLabelEXT = (PFN_vkCmdInsertDebugUtilsLabelEXT)vkGetInstanceProcAddr(instance, "vkCmdInsertDebugUtilsLabelEXT");

    // Describe the area being rendered
    const VkDebugUtilsLabelEXT houseLabel =
    {
        .sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT,
        .pNext = NULL,
        .pLabelName = "Brick House",
        .color = { 1.0f, 0.0f, 0.0f, 1.0f },
    };

    // Start an annotated group of calls under the 'Brick House' name
    pfnCmdBeginDebugUtilsLabelEXT(commandBuffer, &houseLabel);
    {
        // A mutable structure for each part being rendered
        VkDebugUtilsLabelEXT housePartLabel =
        {
            .sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT,
            .pNext = NULL,
            .pLabelName = NULL,
            .color = { 0.0f, 0.0f, 0.0f, 0.0f },
        };

        // Set the name and insert the marker
        housePartLabel.pLabelName = "Walls";
        pfnCmdInsertDebugUtilsLabelEXT(commandBuffer, &housePartLabel);

        // Insert the drawcall for the walls
        vkCmdDrawIndexed(commandBuffer, 1000, 1, 0, 0, 0);

        // Insert a recursive region for two sets of windows
        housePartLabel.pLabelName = "Windows";
        pfnCmdBeginDebugUtilsLabelEXT(commandBuffer, &housePartLabel);
        {
            vkCmdDrawIndexed(commandBuffer, 75, 6, 1000, 0, 0);
            vkCmdDrawIndexed(commandBuffer, 100, 2, 1450, 0, 0);
        }
        pfnCmdEndDebugUtilsLabelEXT(commandBuffer);

        housePartLabel.pLabelName = "Front Door";
        pfnCmdInsertDebugUtilsLabelEXT(commandBuffer, &housePartLabel);

        vkCmdDrawIndexed(commandBuffer, 350, 1, 1650, 0, 0);

        housePartLabel.pLabelName = "Roof";
        pfnCmdInsertDebugUtilsLabelEXT(commandBuffer, &housePartLabel);

        vkCmdDrawIndexed(commandBuffer, 500, 1, 2000, 0, 0);
    }
    // End the house annotation started above
    pfnCmdEndDebugUtilsLabelEXT(commandBuffer);

    // Do other work

    vkEndCommandBuffer(commandBuffer);

    // Describe the queue being used
    const VkDebugUtilsLabelEXT queueLabel =
    {
        .sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT,
        .pNext = NULL,
        .pLabelName = "Main Render Work",
        .color = { 0.0f, 1.0f, 0.0f, 1.0f },
    };

    // Identify the queue label region
    pfnQueueBeginDebugUtilsLabelEXT(queue, &queueLabel);

    // Submit the work for the main render thread
    const VkCommandBuffer cmd_bufs[] = {commandBuffer};
    VkSubmitInfo submit_info =
    {
        .sType = VK_STRUCTURE_TYPE_SUBMIT_INFO,
        .pNext = NULL,
        .waitSemaphoreCount = 0,
        .pWaitSemaphores = NULL,
        .pWaitDstStageMask = NULL,
        .commandBufferCount = 1,
        .pCommandBuffers = cmd_bufs,
        .signalSemaphoreCount = 0,
        .pSignalSemaphores = NULL
    };
    vkQueueSubmit(queue, 1, &submit_info, fence);

    // End the queue label region
    pfnQueueEndDebugUtilsLabelEXT(queue);

问题

1) 我们是否应该将此扩展命名为 VK_EXT_debug_report2？

已解决：否。对结构进行了足够的额外更改，以至于破坏了向后兼容性。因此，决定使用一个新名称，该名称不会表明与先前的扩展有任何交互。

2) 验证层会立即支持所有新功能吗？

已解决：不会立即支持。可以想象，将验证层日志记录转换为新功能涉及大量工作。最初 VK_EXT_debug_report 扩展中看到的基本日志记录将立即提供。但是，添加标签和对象名称将需要时间。由于 Khronos 目前的重点是继续关注 Valid Usage 声明，因此可能需要一段时间才能完全公开新功能。

3) 如果验证层不会立即公开新功能，那么此扩展的意义何在？

已解决：我们需要 VK_EXT_debug_report 的替代品，因为 VkDebugReportObjectTypeEXT 枚举将不再更新，任何新对象都需要使用此扩展提供的新功能进行调试。

4) 是否应将此扩展拆分为两个单独的部分（一个作为实例扩展提供回调功能，另一个作为设备扩展提供常规调试标记和注释功能）？

已解决：否，此扩展的功能过于紧密相关。如果我们拆分扩展，结构和枚举将位于何处，以及如何定义实例扩展中的设备行为只有在启用了设备扩展并且传递了功能时才真正有效。将所有这些都定义为实例扩展更加简洁，而且它还允许应用程序在 vkCreateInstance 期间使用一个启用字符串启用所有提供的调试功能。

版本历史

  • 修订版 1，2017-09-14（Mark Young 和所有列出的贡献者）

  • 修订版 2，2020-04-03（Mark Young 和 Piers Daniell）

    • 更新为允许将 NULL 或空字符串传递给 VkDebugUtilsObjectNameInfoEXT 中的 pObjectName，因为加载程序和各种驱动程序已经支持 NULL。

VK_EXT_depth_bias_control

名称字符串

VK_EXT_depth_bias_control

扩展类型

设备扩展

注册扩展号

284

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式
扩展提案

VK_EXT_depth_bias_control

其他扩展元数据

上次修改日期

2023-02-15

IP 状态

没有已知的 IP 声明。

贡献者

  • Joshua Ashton, VALVE

  • Hans-Kristian Arntzen, VALVE

  • Mike Blumenkrantz, VALVE

  • Georg Lehmann, VALVE

  • Piers Daniell, NVIDIA

  • Lionel Landwerlin, INTEL

  • Tobias Hector, AMD

  • Ricardo Garcia, IGALIA

  • Jan-Harald Fredriksen, ARM

  • Shahbaz Youssefi, GOOGLE

  • Tom Olson, ARM

描述

此扩展添加了一个新的结构体 VkDepthBiasRepresentationInfoEXT，可以将其添加到 VkPipelineRasterizationStateCreateInfo 的 pNext 链中，并允许设置管道的深度偏移的缩放和表示。

此状态也可以通过使用上述新结构体与新的 vkCmdSetDepthBias2EXT 命令相结合动态设置。

新命令

新结构体

新枚举

新枚举常量

  • VK_EXT_DEPTH_BIAS_CONTROL_EXTENSION_NAME

  • VK_EXT_DEPTH_BIAS_CONTROL_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEPTH_BIAS_INFO_EXT

    • VK_STRUCTURE_TYPE_DEPTH_BIAS_REPRESENTATION_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_BIAS_CONTROL_FEATURES_EXT

版本历史

  • 修订版 1, 2022-09-22 (Joshua Ashton)

    • 初始草案。

VK_EXT_depth_clamp_control

名称字符串

VK_EXT_depth_clamp_control

扩展类型

设备扩展

注册扩展号

583

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式
扩展提案

VK_EXT_depth_clamp_control

其他扩展元数据

上次修改日期

2024-07-15

贡献者

  • Jules Blok, 独立开发者

描述

此扩展允许应用程序独立于视口的 minDepth 和 maxDepth 来控制视口深度钳制范围。这使得应用程序能够将深度值限制为应用程序定义的范围，而不是视口深度范围或 VK_EXT_depth_clamp_zero_one 扩展中定义的范围。

它可用于设置比视口深度范围更小或更大的钳制范围，而不会影响视口变换的深度映射。此扩展的另一个可能的用途是将超出视口深度范围的深度值限制为除 VK_EXT_depth_clamp_zero_one 扩展中定义的 [0, 1] 范围之外的钳制范围。

新命令

新结构体

新枚举

新枚举常量

  • VK_EXT_DEPTH_CLAMP_CONTROL_EXTENSION_NAME

  • VK_EXT_DEPTH_CLAMP_CONTROL_SPEC_VERSION

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_DEPTH_CLAMP_RANGE_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLAMP_CONTROL_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_DEPTH_CLAMP_CONTROL_CREATE_INFO_EXT

问题

1) 深度钳制范围应该是每个视口的参数吗？

已解决：否。由于深度钳制范围之前被定义为等于视口深度范围，符合规范的运行时已经在将深度钳制范围作为每个视口的参数处理。然而，由于与多个视口交互的复杂性，每个视口的钳制范围将留给未来的扩展，如果出现用例的话。

2) 此管道状态应该是动态的吗？

已解决：是。由于视口深度范围已经可以是动态状态，符合规范的运行时已经能够将深度钳制范围作为动态状态处理。

3) 当禁用深度钳制时，深度钳制范围可以忽略吗？

已解决：是。此扩展仅在启用深度钳制时才会覆盖所使用的钳制范围。另一种选择将非常不直观。因此，如果希望将深度裁剪与此扩展结合使用，则需要 VK_EXT_depth_clip_enable 扩展。

版本历史

  • 修订版 1, 2024-02-13 (Jules Blok)

    • 初始草案

VK_EXT_depth_clip_control

名称字符串

VK_EXT_depth_clip_control

扩展类型

设备扩展

注册扩展号

356

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

其他扩展元数据

上次修改日期

2021-11-09

贡献者

  • Spencer Fricke, Samsung Electronics

  • Shahbaz Youssefi, Google

  • Ralph Potter, Samsung Electronics

描述

此扩展允许应用程序在 NDC 中使用 OpenGL 深度范围，即深度范围为 [-1, 1]，而不是 Vulkan 的默认值 [0, 1]。此扩展的目的是通过避免在光栅化前着色器阶段进行模拟来实现 OpenGL 在 Vulkan 上的高效分层。这种模拟有效地复制了 gl_Position，但具有不同的深度值，它会消耗 ALU 并消耗实现可能没有多余的着色器输出组件以满足 OpenGL 的最低要求。

新结构体

新枚举常量

  • VK_EXT_DEPTH_CLIP_CONTROL_EXTENSION_NAME

  • VK_EXT_DEPTH_CLIP_CONTROL_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLIP_CONTROL_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_DEPTH_CLIP_CONTROL_CREATE_INFO_EXT

问题

1) 此扩展是否应包括一个原点控制选项，以匹配 ARB_clip_control 中找到的 GL_LOWER_LEFT？

已解决：否。移植原点的修复方法是简单的 y 轴翻转。深度裁剪控制是一个比此扩展旨在解决的问题更难解决的问题。添加与 GL_LOWER_LEFT 等效的功能将需要更多的测试。

2) 此管道状态应该是动态的吗？

已解决：是。此扩展的目的是模拟 OpenGL 深度范围，该范围预计是全局固定的（在 OpenGL ES 的情况下）或很少更改的（使用 OpenGL 中的 glClipControl）。

3) 此扩展中提供的控制是否应为未来可扩展的枚举？

已解决：否。深度范围在未来极不可能更改为 [0, 1] 以外的值。如果发生这种情况，将需要一个新的扩展来扩展此类枚举，并且该扩展也可以添加一个新的结构来链接到 VkPipelineViewportStateCreateInfo::pNext。

版本历史

  • 修订版 0，2020-10-01 (Spencer Fricke)

    • 内部修订

  • 修订版 1，2020-11-26 (Shahbaz Youssefi)

    • 语言修正

VK_EXT_depth_clip_enable

名称字符串

VK_EXT_depth_clip_enable

扩展类型

设备扩展

注册扩展号

103

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

其他扩展元数据

上次修改日期

2018-12-20

贡献者

  • Daniel Rakos, AMD

  • Henri Verbeet, CodeWeavers

  • Jeff Bolz, NVIDIA

  • Philip Rebohle, DXVK

  • Tobias Hector, AMD

描述

此扩展允许深度裁剪操作（通常由 VkPipelineRasterizationStateCreateInfo::depthClampEnable 隐式控制），而是由 VkPipelineRasterizationDepthClipStateCreateInfoEXT::depthClipEnable 显式控制。

这对于转换假定深度钳制始终启用的 DX 内容非常有用，但深度裁剪可以由 DepthClipEnable 光栅化状态 (D3D12_RASTERIZER_DESC) 控制。

新结构

新位掩码

新枚举常量

  • VK_EXT_DEPTH_CLIP_ENABLE_EXTENSION_NAME

  • VK_EXT_DEPTH_CLIP_ENABLE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLIP_ENABLE_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_DEPTH_CLIP_STATE_CREATE_INFO_EXT

版本历史

  • 修订版 1，2018-12-20 (Piers Daniell)

    • 内部修订

VK_EXT_depth_range_unrestricted

名称字符串

VK_EXT_depth_range_unrestricted

扩展类型

设备扩展

注册扩展号

14

修订

1

批准状态

已批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2017-06-22

贡献者

  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

描述

此扩展删除了 VkViewport minDepth 和 maxDepth 必须介于 0.0 和 1.0 之间的限制，包括 0.0 和 1.0。它还删除了 VkPipelineDepthStencilStateCreateInfo minDepthBounds 和 maxDepthBounds 的相同限制。最后，它删除了 VkClearDepthStencilValue 中 depth 值的限制。

新枚举常量

  • VK_EXT_DEPTH_RANGE_UNRESTRICTED_EXTENSION_NAME

  • VK_EXT_DEPTH_RANGE_UNRESTRICTED_SPEC_VERSION

问题

1) VkViewport minDepth 和 maxDepth 在 0.0 到 1.0 范围之外的值如何与图元裁剪交互？

已解决： 图元裁剪 中描述的行为仍然适用。如果禁用深度钳制，则深度值在视口变换之前仍会被裁剪到 0 ≤ zc ≤ wc。如果启用深度钳制，则忽略以上等式，并且深度值会改为钳制到 VkViewport minDepth 和 maxDepth 值，在本扩展的情况下，这些值可以在 0.0 到 1.0 范围之外。

2) 如果生成的深度片段在 0.0 到 1.0 范围之外，并且深度缓冲区是定点而不是浮点，会发生什么？

已解决：这种情况也可能在没有此扩展的情况下发生（例如，当片段着色器替换深度值时），并且此扩展不会更改行为，该行为在片段操作章节的 深度测试 部分中定义。

版本历史

  • 修订版 1，2017-06-22 (Piers Daniell)

    • 内部修订

VK_EXT_descriptor_buffer

名称字符串

VK_EXT_descriptor_buffer

扩展类型

设备扩展

注册扩展号

317

修订

1

批准状态

已批准

扩展和版本依赖关系

                 VK_KHR_get_physical_device_properties2
                 或
                 Vulkan 版本 1.1
             和
             VK_KHR_buffer_device_address
             和
             VK_EXT_descriptor_indexing
         或
         Vulkan 版本 1.2
     和
     VK_KHR_synchronization2
或
Vulkan 版本 1.3

API 交互

  • 与 VK_KHR_acceleration_structure 交互

  • 与 VK_NV_ray_tracing 交互

联系方式
扩展提案

VK_EXT_descriptor_buffer

其他扩展元数据

上次修改日期

2021-06-07

IP 状态

没有已知的 IP 声明。

贡献者

  • Tobias Hector, AMD

  • Stu Smith, AMD

  • Maciej Jesionowski, AMD

  • Boris Zanin, AMD

  • Hans-Kristian Arntzen, Valve

  • Connor Abbott, Valve

  • Baldur Karlsson, Valve

  • Mike Blumenkrantz, Valve

  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, Arm

  • Rodrigo Locatti, NVIDIA

  • Jeff Bolz, NVIDIA

  • Piers Daniell, NVIDIA

  • Jeff Leger, QUALCOMM

  • Lionel Landwerlin, Intel

  • Slawomir Grajewski, Intel

描述

此扩展引入了新命令，可将着色器可访问的描述符直接放入内存中，从而使描述符数据的管理更加明确。

新命令

如果支持 VK_KHR_acceleration_structure 或 VK_NV_ray_tracing

新结构

如果支持 VK_KHR_acceleration_structure 或 VK_NV_ray_tracing

新联合体

新枚举常量

  • VK_EXT_DESCRIPTOR_BUFFER_EXTENSION_NAME

  • VK_EXT_DESCRIPTOR_BUFFER_SPEC_VERSION

  • 扩展 VkAccelerationStructureCreateFlagBitsKHR

    • VK_ACCELERATION_STRUCTURE_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT

  • 扩展 VkAccessFlagBits2

    • VK_ACCESS_2_DESCRIPTOR_BUFFER_READ_BIT_EXT

  • 扩展 VkBufferCreateFlagBits

    • VK_BUFFER_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT

  • 扩展 VkBufferUsageFlagBits

    • VK_BUFFER_USAGE_PUSH_DESCRIPTORS_DESCRIPTOR_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_RESOURCE_DESCRIPTOR_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_SAMPLER_DESCRIPTOR_BUFFER_BIT_EXT

  • 扩展 VkDescriptorSetLayoutCreateFlagBits

    • VK_DESCRIPTOR_SET_LAYOUT_CREATE_DESCRIPTOR_BUFFER_BIT_EXT

    • VK_DESCRIPTOR_SET_LAYOUT_CREATE_EMBEDDED_IMMUTABLE_SAMPLERS_BIT_EXT

  • 扩展 VkImageCreateFlagBits

    • VK_IMAGE_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT

  • 扩展 VkImageViewCreateFlagBits

    • VK_IMAGE_VIEW_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_DESCRIPTOR_BUFFER_BIT_EXT

  • 扩展 VkSamplerCreateFlagBits

    • VK_SAMPLER_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BUFFER_CAPTURE_DESCRIPTOR_DATA_INFO_EXT

    • VK_STRUCTURE_TYPE_DESCRIPTOR_ADDRESS_INFO_EXT

    • VK_STRUCTURE_TYPE_DESCRIPTOR_BUFFER_BINDING_INFO_EXT

    • VK_STRUCTURE_TYPE_DESCRIPTOR_BUFFER_BINDING_PUSH_DESCRIPTOR_BUFFER_HANDLE_EXT

    • VK_STRUCTURE_TYPE_DESCRIPTOR_GET_INFO_EXT

    • VK_STRUCTURE_TYPE_IMAGE_CAPTURE_DESCRIPTOR_DATA_INFO_EXT

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_CAPTURE_DESCRIPTOR_DATA_INFO_EXT

    • VK_STRUCTURE_TYPE_OPAQUE_CAPTURE_DESCRIPTOR_DATA_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_BUFFER_DENSITY_MAP_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_BUFFER_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_BUFFER_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_SAMPLER_CAPTURE_DESCRIPTOR_DATA_INFO_EXT

如果支持 VK_KHR_acceleration_structure 或 VK_NV_ray_tracing

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CAPTURE_DESCRIPTOR_DATA_INFO_EXT

版本历史

  • 修订版 1，2021-06-07 (Stu Smith)

    • 初始修订版

VK_EXT_device_address_binding_report

名称字符串

VK_EXT_device_address_binding_report

扩展类型

设备扩展

注册扩展号

355

修订

1

批准状态

未批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
    或
     Vulkan 版本 1.1
和
VK_EXT_debug_utils

特殊用途
联系方式

  • Ralph Potter r_potter

其他扩展元数据

上次修改日期

2020-11-23

交互和外部依赖

  • 此扩展需要 VK_EXT_debug_utils

贡献者

  • Ralph Potter, Samsung

  • Spencer Fricke, Samsung

  • Jan-Harald Fredriksen, ARM

  • Andrew Ellem, Google

  • Alex Walters, IMG

  • Jeff Bolz, NVIDIA

描述

此扩展使应用程序能够跟踪 GPU 虚拟地址空间区域的绑定，并将这些区域与 Vulkan 对象关联起来。此扩展主要旨在帮助崩溃后分析，在其中应用程序可能希望将发生故障的 GPU 地址映射到 Vulkan 对象。

例如，通过访问 GPU 虚拟地址空间中先前报告为已绑定然后取消绑定的区域内的地址而触发的页面错误可能指示使用后释放错误。类似地，通过访问 GPU 虚拟地址空间的绑定区域限制之外的虚拟地址而产生的错误可能指示索引超出资源的范围。

新结构体

新枚举

新位掩码

新枚举常量

  • VK_EXT_DEVICE_ADDRESS_BINDING_REPORT_EXTENSION_NAME

  • VK_EXT_DEVICE_ADDRESS_BINDING_REPORT_SPEC_VERSION

  • 扩展 VkDebugUtilsMessageTypeFlagBitsEXT

    • VK_DEBUG_UTILS_MESSAGE_TYPE_DEVICE_ADDRESS_BINDING_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_ADDRESS_BINDING_CALLBACK_DATA_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ADDRESS_BINDING_REPORT_FEATURES_EXT

问题

1.) 这应该扩展 VK_EXT_debug_utils 还是 VK_EXT_device_memory_report？

已解决：扩展 VK_EXT_debug_utils。VK_EXT_device_memory_report 侧重于内存分配，通常不会在预期 VK_EXT_device_address_binding_report 的所有情况下触发回调。

2.) 此扩展应该涵盖所有 Vulkan 对象类型，还是仅涵盖缓冲区和图像等资源？

已解决：该扩展涵盖所有 Vulkan 对象，不限于由 VkDeviceMemory 对象支持的对象。

3.) 应该明确标识重新分配，还是作为取消绑定/绑定对？

已解决：重新分配应表示为取消绑定/绑定对。

4.) 多个 Vulkan 对象可以共享重叠的虚拟地址范围吗？

已解决：是的。由于资源别名，可以预期会发生这种情况。

5.) 单个 Vulkan 对象可以同时与多个虚拟地址范围关联吗？

已解决：是的。这些应该通过多次调用报告回调来报告。

6.) 应该报告与内存池等内部分配关联的虚拟地址范围吗？

已解决：仅当内部分配与特定的 Vulkan 对象关联时，才应报告与内部分配关联的虚拟地址范围。在内部池分配的情况下，当池中的资源分配给 Vulkan 对象时，应报告绑定事件；当这些资源返回到池时，应报告取消绑定事件。实现不应报告应用程序开发人员看不到的没有相关 API 对象的虚拟地址范围的绑定或取消绑定。

7.) 实现可以在 VkImage 或 VkImageView 创建时报告虚拟地址范围绑定，而不是响应 vkBindImageMemory 吗？

已解决：是的。应在实现中发生虚拟地址范围绑定的适当点报告它。此扩展不强制规定何时应该发生这种情况，并且应用程序应预期在注册回调后随时接收回调事件。

8.) 可以将绑定/取消绑定的报告延迟到执行命令缓冲区引用资源吗？

已解决：应在尽可能接近实现中发生的位置报告与 Vulkan 对象关联的虚拟地址范围的更改。如果虚拟地址绑定被延迟，则回调也应被延迟以匹配。

9.) 绑定/取消绑定回调是否必须形成匹配对？可以绑定一个大的区域，然后取消绑定子区域，从而导致碎片化吗？

已解决：可能会发生虚拟地址区域的拆分以及不匹配的绑定/取消绑定回调。开发人员应该预料到稀疏内存可能会表现出这种行为。

10.) 规范规定，每当与任何 Vulkan 对象关联的 GPU 虚拟地址范围被绑定或取消绑定时，必须触发回调。我们需要查询或属性来指示哪些 Vulkan 对象将报告绑定修改吗？

已解决：否。此扩展不旨在强制规定实现如何以及何时将虚拟范围绑定到对象。添加查询或属性会限制实现，否则可能会根据使用情况改变虚拟地址绑定的发生方式。

11.) vkAllocateMemory 和 vkFreeMemory 应该触发报告回调吗？

已解决：如果在调用 vkAllocateMemory 时实现绑定了 GPU 虚拟地址范围，则必须触发回调，将虚拟地址范围与 VkDeviceMemory 对象关联。如果随后通过 vkBind*Memory 将设备内存绑定到缓冲区或图像，则应再次触发回调，报告虚拟地址范围与缓冲区/图像之间的关联。

版本历史

  • 修订版 1，2020-09-23 (Ralph Potter)

    • 内部修订

VK_EXT_device_fault

名称字符串

VK_EXT_device_fault

扩展类型

设备扩展

注册扩展号

342

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

  • Ralph Potter r_potter

扩展提案

VK_EXT_device_fault

其他扩展元数据

上次修改日期

2021-03-10

IP 状态

没有已知的 IP 声明。

贡献者

  • Ralph Potter, Samsung

  • Stuart Smith, AMD

  • Jan-Harald Fredriksen, ARM

  • Mark Bellamy, ARM

  • Andrew Ellem, Google

  • Alex Walters, IMG

  • Jeff Bolz, NVIDIA

  • Baldur Karlsson, Valve

描述

设备丢失可能由各种问题触发，包括无效的 API 使用、实现错误或硬件故障。

此扩展引入了一个新的命令：vkGetDeviceFaultInfoEXT，它可以在实现返回 VK_ERROR_DEVICE_LOST 错误代码后调用。此命令允许开发人员查询可能导致设备丢失的 GPU 故障的附加信息，并生成二进制崩溃转储，这些转储可以加载到外部工具中以进行进一步诊断。

新命令

新结构体

新枚举

新枚举常量

  • VK_EXT_DEVICE_FAULT_EXTENSION_NAME

  • VK_EXT_DEVICE_FAULT_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_FAULT_COUNTS_EXT

    • VK_STRUCTURE_TYPE_DEVICE_FAULT_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FAULT_FEATURES_EXT

版本历史

  • 修订版 2，2023-04-05 (Ralph Potter)

    • 恢复了 VkDeviceFaultVendorBinaryHeaderVersionOneEXT 的 XML 定义中丢失的两个成员。规范没有功能性更改。

  • 修订版 1，2020-10-19 (Ralph Potter)

    • 初始修订版

VK_EXT_device_generated_commands

名称字符串

VK_EXT_device_generated_commands

扩展类型

设备扩展

注册扩展号

573

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_buffer_device_address
和
VK_KHR_maintenance5

API 交互

  • 与 VK_EXT_shader_object 交互

联系方式

  • Mike Blumenkrantz zmike

扩展提案

VK_EXT_device_generated_commands

其他扩展元数据

上次修改日期

2024-02-23

交互和外部依赖

  • 此扩展需要 Vulkan 1.1

  • 此扩展需要 VK_EXT_buffer_device_address 或 VK_KHR_buffer_device_address 或 Vulkan 1.2，以便能够在设备上绑定顶点和索引缓冲区。

  • 此扩展需要 VK_KHR_maintenance5 才能使用 VkPipelineCreateFlags2KHR。

  • 此扩展与 VK_NV_mesh_shader 交互。如果不支持后者扩展，请删除在此扩展中启动 NV 网格任务绘制的命令令牌。

  • 此扩展与 VK_EXT_mesh_shader 交互。如果不支持后者扩展，请删除在此扩展中启动 EXT 网格任务绘制的命令令牌。

  • 此扩展与 VK_KHR_ray_tracing_pipeline 交互。如果不支持后者扩展，请删除在此扩展中启动光线追踪的命令令牌。

  • 此扩展与 VK_EXT_shader_object 交互。如果不支持后者扩展，请删除此扩展中对着色器对象的引用。

贡献者

  • 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

描述

此扩展允许设备为命令缓冲区生成多个命令。它提供了 VK_NV_device_generated_commands 和 VK_NV_device_generated_commands_compute 中的部分功能，以及一些新功能。

在渲染大量对象时，可以利用设备来实现许多关键功能，例如更新矩阵，或实现遮挡剔除、视锥剔除、从前到后排序等。在设备上实现这些功能不需要任何特殊的扩展，因为应用程序可以自由定义自己的数据结构，并且只需使用着色器来处理它们即可。

为了渲染已在设备上处理的对象，Vulkan 有几种方法可以执行间接渲染，从最基本的 vkCmdDrawIndirect 与一个间接绘制到 vkCmdDrawIndirectCount，它支持多个批量的间接绘制，并能够在设备执行时确定绘制的数量。

但是，如果间接绘制之间需要更改渲染状态，则未扩展的 Vulkan 会迫使应用程序推测性地记录大量冗余的间接命令，这些命令涵盖所有可能的状态组合 - 这可能在剔除后最终不处理任何内容 - 或者读取回处理后的流并从主机发出图形命令。对于非常大的场景，同步开销和生成命令缓冲区的成本可能会成为瓶颈。此扩展允许应用程序生成设备端的状态更改和命令流，并将其有效地转换为命令缓冲区，而无需将其读回主机。

此外，它允许通过仅操作命令流的部分部分（例如管道和着色器对象绑定）来对这些命令缓冲区进行增量更改。在这种情况未扩展的 Vulkan 中，需要重新创建整个命令缓冲区，或者在主机上同步更新。

此扩展的预期用法是让应用程序

  • 创建 VkBuffer 对象并通过 vkGetBufferDeviceAddress 从它们中检索物理地址

  • 创建一个 VkIndirectExecutionSetEXT 以便能够在设备上更改着色器。

  • 创建一个 VkIndirectCommandsLayoutEXT，它列出了它希望动态执行的 VkIndirectCommandsTokenTypeEXT 作为原子命令序列。此步骤可能涉及一些内部设备代码编译，因为目的是让 GPU 根据布局生成命令缓冲区。

  • 使用它需要的每个输入的​​数据填充输入流缓冲区。每个输入都是一个数组，该数组将填充依赖于令牌的数据。

  • 设置一个预处理 VkBuffer，它使用根据通过 vkGetGeneratedCommandsMemoryRequirementsEXT 检索的信息的内存。

  • 可选地使用 vkCmdPreprocessGeneratedCommandsEXT 预处理生成的内容，例如在异步计算队列上，或者为了在多次执行中重用数据。

  • 调用 vkCmdExecuteGeneratedCommandsEXT 以基于提供的输入为所有序列创建并执行实际的设备命令。

对于序列中的每个绘制，可以指定以下内容

  • 多个顶点缓冲区绑定

  • 一个不同的索引缓冲区，带有可选的动态偏移和索引类型

  • 多个不同的推送常量

  • 更新绑定的着色器阶段

对于序列中的每个调度，可以指定以下内容

  • 多个不同的推送常量

  • 更新绑定的着色器阶段

对于序列中的每个跟踪射线，可以指定以下内容

  • 多个不同的推送常量

  • 更新绑定的着色器阶段

虽然 GPU 生成命令的速度可能比 CPU 快，但它不会异步于设备发生，因此主要用例是生成“更少”的总工作量（遮挡剔除、分类以使用专用着色器等）。

新对象类型

新命令

新结构体

如果支持 VK_EXT_shader_object

新联合体

新枚举

新位掩码

新枚举常量

  • VK_EXT_DEVICE_GENERATED_COMMANDS_EXTENSION_NAME

  • VK_EXT_DEVICE_GENERATED_COMMANDS_SPEC_VERSION

  • 扩展 VkAccessFlagBits

    • VK_ACCESS_COMMAND_PREPROCESS_READ_BIT_EXT

    • VK_ACCESS_COMMAND_PREPROCESS_WRITE_BIT_EXT

  • 扩展 VkBufferUsageFlagBits2

    • VK_BUFFER_USAGE_2_PREPROCESS_BUFFER_BIT_EXT

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_INDIRECT_COMMANDS_LAYOUT_EXT

    • VK_OBJECT_TYPE_INDIRECT_EXECUTION_SET_EXT

  • 扩展 VkPipelineCreateFlagBits2

    • VK_PIPELINE_CREATE_2_INDIRECT_BINDABLE_BIT_EXT

  • 扩展 VkPipelineStageFlagBits

    • VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_EXT

  • 扩展 VkShaderCreateFlagBitsEXT

    • VK_SHADER_CREATE_INDIRECT_BINDABLE_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_GENERATED_COMMANDS_INFO_EXT

    • VK_STRUCTURE_TYPE_GENERATED_COMMANDS_MEMORY_REQUIREMENTS_INFO_EXT

    • VK_STRUCTURE_TYPE_GENERATED_COMMANDS_PIPELINE_INFO_EXT

    • VK_STRUCTURE_TYPE_GENERATED_COMMANDS_SHADER_INFO_EXT

    • VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_TOKEN_EXT

    • VK_STRUCTURE_TYPE_INDIRECT_EXECUTION_SET_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_INDIRECT_EXECUTION_SET_PIPELINE_INFO_EXT

    • VK_STRUCTURE_TYPE_INDIRECT_EXECUTION_SET_SHADER_INFO_EXT

    • VK_STRUCTURE_TYPE_INDIRECT_EXECUTION_SET_SHADER_LAYOUT_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_WRITE_INDIRECT_EXECUTION_SET_PIPELINE_EXT

    • VK_STRUCTURE_TYPE_WRITE_INDIRECT_EXECUTION_SET_SHADER_EXT

示例代码

待办

版本历史

  • 修订版 1, 2024-02-23 (Mike Blumenkrantz)

    • 初始版本

VK_EXT_device_memory_report

名称字符串

VK_EXT_device_memory_report

扩展类型

设备扩展

注册扩展号

285

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

其他扩展元数据

上次修改日期

2021-01-06

IP 状态

没有已知的 IP 声明。

贡献者

  • Yiwei Zhang, Google

  • Jesse Hall, Google

描述

此设备扩展允许在设备创建时注册设备内存事件回调，以便应用程序或中间件可以获得有关内存使用情况以及内存如何与 Vulkan 对象关联的详细信息。此扩展公开实际的底层设备内存使用情况，包括通常对应用程序不可见的分配，例如 vkCreateGraphicsPipelines 所消耗的内存。它主要用于调试工具，而不是用于生产应用程序。

新结构体

新函数指针

新枚举

新位掩码

新枚举常量

  • VK_EXT_DEVICE_MEMORY_REPORT_EXTENSION_NAME

  • VK_EXT_DEVICE_MEMORY_REPORT_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_DEVICE_MEMORY_REPORT_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_DEVICE_MEMORY_REPORT_CALLBACK_DATA_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_MEMORY_REPORT_FEATURES_EXT

问题

1) 将此更好地表达为 VK_EXT_debug_utils 及其通用信使结构的扩展是否更好？

已解决: 否。预期的生命周期截然不同。我们希望将此扩展与设备的生命周期绑定。每个 ICD 仅处理此扩展的自身实现，并且此扩展将仅直接从 ICD 公开。因此，我们可以避免为了适应 VK_EXT_debug_utils 扩展的灵活性而使用的额外实现复杂性。

2) 我们可以扩展并使用现有的内部分配回调，而不是在此扩展中添加新的回调结构吗？

已解决: 否。我们的内存报告层将此信息与它直接收集的其他内存信息（例如，资源到 VkDeviceMemory 的绑定）相结合，必须拦截所有采用 VkAllocationCallbacks 参数的入口点，并注入其自身的 pfnInternalAllocation 和 pfnInternalFree。对于我们知道的扩展，这可能是可行的，但对于我们不知道的扩展则不可行。该提案在面对大多数未知扩展时都可以正常工作。但即使对于我们知道的扩展，由于应用程序可以提供一组不同的回调和用户数据，并且这些回调和用户数据可以由驱动程序保留并在以后使用（特别是对于池对象，但不只是那些对象），我们都必须每次都动态分配拦截 trampoline。这将导致非常不合理的复杂性和（可能）开销。

我们对分配/释放和导入/取消导入都感兴趣。后者对于跟踪（并避免重复计数）交换链图像（对于基于外部内存的“原生交换链”仍然如此）以及媒体/相机互操作非常重要。虽然我们也许可以使用额外的 VkInternalAllocationType 值来处理此问题，但对于导入/导出，我们确实希望能够将其与外部资源绑定，这就是 memoryObjectId 的用途之一。

内部分配/释放回调是不可扩展的，除非通过新的 VkInternalAllocationType 值。此扩展中的 VkDeviceMemoryReportCallbackDataEXT 是可扩展的。这是经过深思熟虑的：我们将来很可能想要获得额外的信息。例如，目前这仅报告物理分配，但我们认为存在一些有趣的案例，可以跟踪该 VA 区域的填充程度。

回调被明确指定为仅在应用程序调用 Vulkan 的上下文中可调用。我们认为在某些情况下，驱动程序可以异步分配设备内存。这是导致 1.0 之前的内部设备内存分配报告设计（这基本上是此扩展试图做的事情）脱轨的棘手问题之一。

VkAllocationCallbacks 在一个名为“主机内存”的部分中描述，其介绍非常明确地关于主机内存。其他回调本质上都与主机内存有关。但是此扩展非常侧重于设备内存。

3) 回调是否应该报告使用了哪个堆？

已解决：是的。对于非 UMA 系统，将所有设备内存分配归因于相应的设备内存堆非常重要。对于内部分配的设备内存，heapIndex 将始终对应于已声明的堆，而不是具有指示未声明堆的魔术值。如果需要，驱动程序可以声明没有任何对应内存类型的堆。

4) 我们应该使用回调数组来让层拦截，而不是在 VkDeviceDeviceMemoryReportCreateInfoEXT 结构的 pNext 中链接多个 VkDeviceCreateInfo 结构吗？

已解决：否。指向 VkDeviceDeviceMemoryReportCreateInfoEXT 结构的指针本身是 const 的，您不能直接将其强制转换掉。因此，我们无法更新结构内部的回调数组。此外，我们也不能删除此 pNext 链，因此复制整个结构也行不通。

5) 我们应该跟踪多个对象之间共享的批量分配吗？

已解决：否。以着色器堆为例。一些实现将允许多个 VkPipeline 对象共享同一个着色器堆。我们不要求实现报告 VK_OBJECT_TYPE_PIPELINE 以及此批量分配的 VK_NULL_HANDLE。相反，此批量分配被认为是此扩展感兴趣的层之下的一层。稍后，当实际的 VkPipeline 对象通过从批量分配中子分配创建时，我们要求实现报告 VkPipeline 对象的有效句柄以及实际的子分配大小和不同的 memoryObjectId。

6) 我们是否可以要求始终在与 Vulkan 命令相同的线程中调用回调？

已解决：否。一些实现可能会选择将来自多个应用程序线程的工作多路复用到单个后端线程中，并作为该流程的一部分执行 JIT 分配。由于这种行为在理论上是合法的，因此我们不能要求始终在与 Vulkan 命令相同的线程中调用回调，并且该注释旨在提醒应用程序正确处理这种情况。

7) 我们是否应该添加一个额外的“分配失败”事件类型，并报告大小和堆索引等信息？

已解决：是的。这与此扩展中添加的回调基础设施非常契合，并且实现会触及相同的代码，并具有与扩展其余部分相同的开销。它可以帮助调试诸如在结束命令缓冲区时出现 VK_ERROR_OUT_OF_HOST_MEMORY 错误之类的问题。现在，分配失败可能发生在记录过程中的任何位置，回调对于了解发生的位置和原因非常有用。

版本历史

  • 修订版 1，2020-08-26 (张益玮)

    • 初始版本

  • 修订版 2，2021-01-06 (张益玮)

    • 次要描述更新

VK_EXT_direct_mode_display

名称字符串

VK_EXT_direct_mode_display

扩展类型

实例扩展

注册扩展号

89

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_display

联系方式

其他扩展元数据

上次修改日期

2016-12-13

IP 状态

没有已知的 IP 声明。

贡献者

  • Pierre Boudier, NVIDIA

  • James Jones, NVIDIA

  • Damien Leone, NVIDIA

  • Pierre-Loup Griffais, Valve

  • Liam Middlebrook, NVIDIA

描述

此扩展以及相关的平台扩展，允许应用程序独占控制与本机窗口系统关联的显示器。这对于希望将 HMD（头戴式显示器）从本机平台的显示管理系统、桌面和/或其他应用程序中隐藏起来的虚拟现实应用程序尤其有用。

新命令

新枚举常量

  • VK_EXT_DIRECT_MODE_DISPLAY_EXTENSION_NAME

  • VK_EXT_DIRECT_MODE_DISPLAY_SPEC_VERSION

问题

1) 此扩展及其相关的特定于平台的扩展是否应利用 VK_KHR_display，还是提供单独的等效接口。

已解决：使用 VK_KHR_display 概念和对象。VK_KHR_display 可用于枚举系统上的所有显示器，包括那些附加到/正在被窗口系统或本机平台使用的显示器，但是 VK_KHR_display_swapchain 将无法在正在使用的显示器上创建交换链。此扩展及其特定于平台的子扩展将允许应用程序从窗口系统和/或本机平台中夺取正在使用的显示器，从而允许它们与 VK_KHR_display_swapchain 一起使用。

2) 是否需要单独的调用来获取显示器并启用直接模式？

已解决：否，这些操作在一个组合命令中发生。获取显示器会将其置于直接模式。

版本历史

  • 修订版 1，2016-12-13 (James Jones)

    • 初始草案

VK_EXT_directfb_surface

名称字符串

VK_EXT_directfb_surface

扩展类型

实例扩展

注册扩展号

347

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

其他扩展元数据

上次修改日期

2020-06-16

IP 状态

没有已知的 IP 声明。

贡献者

  • Nicolas Caramelli

描述

VK_EXT_directfb_surface 扩展是一个实例扩展。它提供了一种创建 VkSurfaceKHR 对象（由 VK_KHR_surface 扩展定义）的机制，该对象引用 DirectFB IDirectFBSurface，以及一个查询以确定通过 DirectFB 进行渲染的支持。

新命令

新结构

新位掩码

新枚举常量

  • VK_EXT_DIRECTFB_SURFACE_EXTENSION_NAME

  • VK_EXT_DIRECTFB_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DIRECTFB_SURFACE_CREATE_INFO_EXT

版本历史

  • 修订版 1，2020-06-16 (Nicolas Caramelli)

    • 初始版本

VK_EXT_discard_rectangles

名称字符串

VK_EXT_discard_rectangles

扩展类型

设备扩展

注册扩展号

100

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2023-01-18

交互和外部依赖
贡献者

  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

描述

此扩展提供在帧缓冲区空间坐标中指定的附加正交对齐的“丢弃矩形”，用于限制所有点、线和三角形的光栅化。

可以同时操作零个到实现相关的限制（由 maxDiscardRectangles 指定）数量的丢弃矩形。当一个或多个丢弃矩形处于活动状态时，如果光栅化片段位于任何活动的丢弃矩形内（VK_DISCARD_RECTANGLE_MODE_INCLUSIVE_EXT 模式），则片段可以保留；如果光栅化片段位于任何活动的丢弃矩形内（VK_DISCARD_RECTANGLE_MODE_EXCLUSIVE_EXT 模式），则片段会被拒绝。

这些丢弃矩形与现有的剪裁测试功能正交运行。通过指定设备掩码并设置丢弃矩形动态状态，设备组中每个物理设备的丢弃矩形可以不同。

此扩展的第 2 版引入了新的动态状态 VK_DYNAMIC_STATE_DISCARD_RECTANGLE_ENABLE_EXT 和 VK_DYNAMIC_STATE_DISCARD_RECTANGLE_MODE_EXT，以及相应的函数 vkCmdSetDiscardRectangleEnableEXT 和 vkCmdSetDiscardRectangleModeEXT。使用这些动态状态的应用程序必须确保实现至少通告此扩展的 specVersion 2。

新命令

新结构

新枚举

新位掩码

新枚举常量

  • VK_EXT_DISCARD_RECTANGLES_EXTENSION_NAME

  • VK_EXT_DISCARD_RECTANGLES_SPEC_VERSION

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_DISCARD_RECTANGLE_ENABLE_EXT

    • VK_DYNAMIC_STATE_DISCARD_RECTANGLE_EXT

    • VK_DYNAMIC_STATE_DISCARD_RECTANGLE_MODE_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DISCARD_RECTANGLE_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_DISCARD_RECTANGLE_STATE_CREATE_INFO_EXT

版本历史

  • 修订版 2，2023-01-18 (Piers Daniell)

    • 为丢弃矩形启用/禁用和模式添加动态状态。

  • 修订版 1，2016-12-22 (Piers Daniell)

    • 内部修订

VK_EXT_display_control

名称字符串

VK_EXT_display_control

扩展类型

设备扩展

注册扩展号

92

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_EXT_display_surface_counter
和
VK_KHR_swapchain

联系方式

其他扩展元数据

上次修改日期

2016-12-13

IP 状态

没有已知的 IP 声明。

贡献者

  • Pierre Boudier, NVIDIA

  • James Jones, NVIDIA

  • Damien Leone, NVIDIA

  • Pierre-Loup Griffais, Valve

  • Daniel Vetter, Intel

描述

此扩展定义了一组用于 VK_KHR_display 和 VK_KHR_display_swapchain 扩展的实用程序函数。

新命令

新结构

新枚举

新枚举常量

  • VK_EXT_DISPLAY_CONTROL_EXTENSION_NAME

  • VK_EXT_DISPLAY_CONTROL_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_EVENT_INFO_EXT

    • VK_STRUCTURE_TYPE_DISPLAY_EVENT_INFO_EXT

    • VK_STRUCTURE_TYPE_DISPLAY_POWER_INFO_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_COUNTER_CREATE_INFO_EXT

问题

1) 此扩展是否应添加显式的 “WaitForVsync” API 或在垂直同步时发出信号的围栏，应用程序可以等待该围栏？

已解决：一个围栏。稍后可以提供一个单独的 API，该 API 允许将围栏导出到本机对象，该对象可以插入到 POSIX 和 Windows 系统上的标准运行循环中。

2) 是否应为垂直同步事件添加回调，或者通常为了监视 Vulkan 中的事件？

已解决：否，应使用围栏。某些事件由内核中管理的 interrupts 生成。为了使用应用程序提供的回调，驱动程序需要让用户空间驱动程序生成线程，这些线程会等待内核事件，因此，考虑到回调会到达外部线程，应用程序可能难以将其与其他工作同步。

3) 是否应公开垂直消隐或扫描线事件？

已解决：垂直消隐事件。扫描线事件可以通过单独的扩展添加，但是处理中断和唤醒用户空间事件的延迟足够高，因此扫描线事件的准确性会相当低。此外，并非所有硬件都支持每扫描线中断。

版本历史

  • 修订版 1，2016-12-13 (James Jones)

    • 初始草案

VK_EXT_display_surface_counter

名称字符串

VK_EXT_display_surface_counter

扩展类型

实例扩展

注册扩展号

91

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_display

联系方式

其他扩展元数据

上次修改日期

2016-12-13

IP 状态

没有已知的 IP 声明。

贡献者

  • Pierre Boudier, NVIDIA

  • James Jones, NVIDIA

  • Damien Leone, NVIDIA

  • Pierre-Loup Griffais, Valve

  • Daniel Vetter, Intel

描述

此扩展定义了与显示表面关联的垂直消隐周期计数器。它提供了一种从 VkSurfaceKHR 对象查询对此类计数器支持的机制。

新命令

新结构

新枚举

新位掩码

新枚举常量

  • VK_EXT_DISPLAY_SURFACE_COUNTER_EXTENSION_NAME

  • VK_EXT_DISPLAY_SURFACE_COUNTER_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES2_EXT

    • VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT

版本历史

  • 修订版 1，2016-12-13 (James Jones)

    • 初始草案

VK_EXT_dynamic_rendering_unused_attachments

名称字符串

VK_EXT_dynamic_rendering_unused_attachments

扩展类型

设备扩展

注册扩展号

500

修订

1

批准状态

已批准

扩展和版本依赖关系

         VK_KHR_get_physical_device_properties2
         或
         Vulkan 版本 1.1
     和
     VK_KHR_dynamic_rendering
或
Vulkan 版本 1.3

联系方式
扩展提案

VK_EXT_dynamic_rendering_unused_attachments

其他扩展元数据

上次修改日期

2023-05-22

IP 状态

没有已知的 IP 声明。

贡献者

  • Daniel Story, Nintendo

  • Hans-Kristian Arntzen, Valve

  • Jan-Harald Fredriksen, Arm

  • James Fitzpatrick, Imagination Technologies

  • Pan Gao, Huawei Technologies

  • Ricardo Garcia, Igalia

  • Stu Smith, AMD

描述

此扩展取消了 VK_KHR_dynamic_rendering 扩展中的一些限制，允许在渲染通道实例和这些渲染通道实例中绑定的管线中，一个指定了未使用的附件，而另一个没有指定。它还允许管线在渲染通道中使用不同的格式，只要附件为 NULL。

新结构

新枚举常量

  • VK_EXT_DYNAMIC_RENDERING_UNUSED_ATTACHMENTS_EXTENSION_NAME

  • VK_EXT_DYNAMIC_RENDERING_UNUSED_ATTACHMENTS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DYNAMIC_RENDERING_UNUSED_ATTACHMENTS_FEATURES_EXT

问题

无。

版本历史

  • 修订版 1，2023-05-22 (Piers Daniell)

    • 内部修订

VK_EXT_extended_dynamic_state3

名称字符串

VK_EXT_extended_dynamic_state3

扩展类型

设备扩展

注册扩展号

456

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

API 交互

  • 与 VK_VERSION_1_1 交互

  • 与 VK_EXT_blend_operation_advanced 交互

  • 与 VK_EXT_conservative_rasterization 交互

  • 与 VK_EXT_depth_clip_control 交互

  • 与 VK_EXT_depth_clip_enable 交互

  • 与 VK_EXT_line_rasterization 交互

  • 与 VK_EXT_provoking_vertex 交互

  • 与 VK_EXT_sample_locations 交互

  • 与 VK_EXT_transform_feedback 交互

  • 与 VK_KHR_maintenance2 交互

  • 与 VK_NV_clip_space_w_scaling 交互

  • 与 VK_NV_coverage_reduction_mode 交互

  • 与 VK_NV_fragment_coverage_to_color 交互

  • 与 VK_NV_framebuffer_mixed_samples 交互

  • 与 VK_NV_representative_fragment_test 交互

  • 与 VK_NV_shading_rate_image 交互

  • 与 VK_NV_viewport_swizzle 交互

  • 与 VkPhysicalDeviceExtendedDynamicState3FeaturesEXT::extendedDynamicState3AlphaToOneEnable 交互

  • 与 VkPhysicalDeviceExtendedDynamicState3FeaturesEXT::extendedDynamicState3DepthClampEnable 交互

  • 与 VkPhysicalDeviceExtendedDynamicState3FeaturesEXT::extendedDynamicState3LogicOpEnable 交互

  • 与 VkPhysicalDeviceExtendedDynamicState3FeaturesEXT::extendedDynamicState3PolygonMode 交互

  • 与 VkPhysicalDeviceExtendedDynamicState3FeaturesEXT::extendedDynamicState3RasterizationStream 交互

  • 与 VkPhysicalDeviceExtendedDynamicState3FeaturesEXT::extendedDynamicState3TessellationDomainOrigin 交互

联系方式
扩展提案

VK_EXT_extended_dynamic_state3

其他扩展元数据

上次修改日期

2022-09-02

IP 状态

没有已知的 IP 声明。

贡献者

  • Daniel Story, Nintendo

  • Jamie Madill，谷歌

  • Jan-Harald Fredriksen, Arm

  • Faith Ekstrand, Collabora

  • Mike Blumenkrantz, Valve

  • Ricardo Garcia, Igalia

  • Samuel Pitoiset, Valve

  • Shahbaz Youssefi, Google

  • Stu Smith, AMD

  • Tapani Pälli，英特尔

描述

此扩展将几乎所有剩余的管线状态添加为动态状态，以帮助应用程序进一步减少它们需要创建和绑定的单体管线的数量。

新命令

如果支持 VK_EXT_blend_operation_advanced

如果支持 VK_EXT_conservative_rasterization

如果支持 VK_EXT_depth_clip_control

如果支持 VK_EXT_depth_clip_enable

如果支持 VK_EXT_line_rasterization

如果支持 VK_EXT_provoking_vertex

如果支持 VK_EXT_sample_locations

如果支持 VK_EXT_transform_feedback

如果支持 VK_KHR_maintenance2 或 Vulkan 版本 1.1

如果支持 VK_NV_clip_space_w_scaling

如果支持 VK_NV_coverage_reduction_mode

如果支持 VK_NV_fragment_coverage_to_color

如果支持 VK_NV_framebuffer_mixed_samples

如果支持 VK_NV_representative_fragment_test

如果支持 VK_NV_shading_rate_image

如果支持 VK_NV_viewport_swizzle

新结构

新枚举常量

  • VK_EXT_EXTENDED_DYNAMIC_STATE_3_EXTENSION_NAME

  • VK_EXT_EXTENDED_DYNAMIC_STATE_3_SPEC_VERSION

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_ALPHA_TO_COVERAGE_ENABLE_EXT

    • VK_DYNAMIC_STATE_ALPHA_TO_ONE_ENABLE_EXT

    • VK_DYNAMIC_STATE_COLOR_BLEND_ENABLE_EXT

    • VK_DYNAMIC_STATE_COLOR_BLEND_EQUATION_EXT

    • VK_DYNAMIC_STATE_COLOR_WRITE_MASK_EXT

    • VK_DYNAMIC_STATE_DEPTH_CLAMP_ENABLE_EXT

    • VK_DYNAMIC_STATE_LOGIC_OP_ENABLE_EXT

    • VK_DYNAMIC_STATE_POLYGON_MODE_EXT

    • VK_DYNAMIC_STATE_RASTERIZATION_SAMPLES_EXT

    • VK_DYNAMIC_STATE_SAMPLE_MASK_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_3_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_3_PROPERTIES_EXT

如果支持 VK_EXT_blend_operation_advanced

如果支持 VK_EXT_conservative_rasterization

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_CONSERVATIVE_RASTERIZATION_MODE_EXT

    • VK_DYNAMIC_STATE_EXTRA_PRIMITIVE_OVERESTIMATION_SIZE_EXT

如果支持 VK_EXT_depth_clip_control

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_DEPTH_CLIP_NEGATIVE_ONE_TO_ONE_EXT

如果支持 VK_EXT_depth_clip_enable

如果支持 VK_EXT_line_rasterization

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_LINE_RASTERIZATION_MODE_EXT

    • VK_DYNAMIC_STATE_LINE_STIPPLE_ENABLE_EXT

如果支持 VK_EXT_provoking_vertex

如果支持 VK_EXT_sample_locations

如果支持 VK_EXT_transform_feedback

如果支持 VK_KHR_maintenance2 或 Vulkan 版本 1.1

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_TESSELLATION_DOMAIN_ORIGIN_EXT

如果支持 VK_NV_clip_space_w_scaling

如果支持 VK_NV_coverage_reduction_mode

如果支持 VK_NV_fragment_coverage_to_color

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_COVERAGE_TO_COLOR_ENABLE_NV

    • VK_DYNAMIC_STATE_COVERAGE_TO_COLOR_LOCATION_NV

如果支持 VK_NV_framebuffer_mixed_samples

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_COVERAGE_MODULATION_MODE_NV

    • VK_DYNAMIC_STATE_COVERAGE_MODULATION_TABLE_ENABLE_NV

    • VK_DYNAMIC_STATE_COVERAGE_MODULATION_TABLE_NV

如果支持 VK_NV_representative_fragment_test

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_REPRESENTATIVE_FRAGMENT_TEST_ENABLE_NV

如果支持 VK_NV_shading_rate_image

如果支持 VK_NV_viewport_swizzle

问题

1) VkPipelineMultisampleStateCreateInfo 状态 sampleShadingEnable 和 minSampleShading 怎么样？

未解决

  • 编译片段着色器时需要 sampleShadingEnable 和 minSampleShading，并且动态设置它们没有意义，因为它们始终需要与片段着色器状态匹配，因此此硬件状态最好直接来自具有片段着色器的管线。

版本历史

  • 修订版 2，2022-07-18 (Piers Daniell)

    • 添加了 rasterizationSamples

  • 修订版 1，2022-05-18 (Piers Daniell)

    • 内部修订

VK_EXT_external_memory_acquire_unmodified

名称字符串

VK_EXT_external_memory_acquire_unmodified

扩展类型

设备扩展

注册扩展号

454

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_memory
或
Vulkan 版本 1.1

联系方式
扩展提案

VK_EXT_external_memory_acquire_unmodified

其他扩展元数据

上次修改日期

2023-03-09

贡献者

  • Lina Versace，谷歌

  • Chia-I Wu，谷歌

  • James Jones, NVIDIA

  • Yiwei Zhang, Google

描述

当从外部队列族获取子资源范围的所有权时，内存屏障**可能**会产生性能损失。如果子资源范围的所有权先前已释放到外部队列族，并且资源的内存在此释放和获取操作之间保持未修改，则此扩展提供 API，**可能**会减少性能损失。

新结构

新枚举常量

  • VK_EXT_EXTERNAL_MEMORY_ACQUIRE_UNMODIFIED_EXTENSION_NAME

  • VK_EXT_EXTERNAL_MEMORY_ACQUIRE_UNMODIFIED_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_ACQUIRE_UNMODIFIED_EXT

版本历史

  • 修订版 1，2023-03-09 (Lina Versace)

    • 初始修订版

VK_EXT_external_memory_dma_buf

名称字符串

VK_EXT_external_memory_dma_buf

扩展类型

设备扩展

注册扩展号

126

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_memory_fd

联系方式

其他扩展元数据

上次修改日期

2017-10-10

IP 状态

没有已知的 IP 声明。

贡献者

  • Lina Versace，谷歌

  • James Jones, NVIDIA

  • Faith Ekstrand, Intel

描述

dma_buf 是由 Linux 内核定义的一种文件描述符，允许跨内核设备驱动程序和跨进程共享内存。此扩展使应用程序能够导入 dma_buf 作为 VkDeviceMemory，导出 VkDeviceMemory 作为 dma_buf，并创建可以绑定到该内存的 VkBuffer 对象。

新枚举常量

  • VK_EXT_EXTERNAL_MEMORY_DMA_BUF_EXTENSION_NAME

  • VK_EXT_EXTERNAL_MEMORY_DMA_BUF_SPEC_VERSION

  • 扩展 VkExternalMemoryHandleTypeFlagBits

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT

问题

1) 当应用程序创建一个打算绑定到包含外部生成的图像的 dma_buf VkDeviceMemory 的 VkImage 时，如何指定 VkImage 的内存布局（例如行距和 DRM 格式修饰符）？换句话说，应用程序如何实现与 EGL_EXT_image_dma_buf_import 和 EGL_EXT_image_dma_buf_import_modifiers 提供的行为相当的行为？

已解决：与 EGL_EXT_image_dma_buf_import 和 EGL_EXT_image_dma_buf_import_modifiers 中的功能相当的功能将由位于此之上的扩展提供。

2) 如果无法指定外部 dma_buf 图像的内存布局，此扩展有什么用？

已解决：此扩展仅提供一个新功能：在 dma_buf 和 VkDeviceMemory 之间导入/导出。此功能，以及 VK_KHR_external_memory_fd 提供的功能，足以将 VkBuffer 绑定到 dma_buf。

版本历史

  • 修订版 1，2017-10-10 (Lina Versace)

    • 压缩内部修订版

VK_EXT_external_memory_host

名称字符串

VK_EXT_external_memory_host

扩展类型

设备扩展

注册扩展号

179

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_memory
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2017-11-10

IP 状态

没有已知的 IP 声明。

贡献者

  • Jaakko Konttinen, AMD

  • David Mao, AMD

  • Daniel Rakos, AMD

  • Tobias Hector, Imagination Technologies

  • Faith Ekstrand, Intel

  • James Jones, NVIDIA

描述

此扩展使应用程序能够将主机分配和主机映射的外部设备内存导入到 Vulkan 内存对象。

新命令

新结构

新枚举常量

  • VK_EXT_EXTERNAL_MEMORY_HOST_EXTENSION_NAME

  • VK_EXT_EXTERNAL_MEMORY_HOST_SPEC_VERSION

  • 扩展 VkExternalMemoryHandleTypeFlagBits

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_ALLOCATION_BIT_EXT

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_MAPPED_FOREIGN_MEMORY_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMPORT_MEMORY_HOST_POINTER_INFO_EXT

    • VK_STRUCTURE_TYPE_MEMORY_HOST_POINTER_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_MEMORY_HOST_PROPERTIES_EXT

问题

1) 必须使用哪种内存类型来导入主机指针？

已解决：取决于实现。应用程序必须使用新的 vkGetMemoryHostPointerPropertiesEXT 命令来查询特定主机指针支持的内存类型。报告的内存类型可能包括来自内存堆的内存类型，该内存堆在其他情况下不可用于常规内存对象分配，因此此类堆的大小可能为零。

2) 应用程序在导入后是否仍可以访问主机分配的内容？

已解决：是的。但是，通常的同步要求适用。

3) 应用程序可以释放主机分配吗？

已解决：否，这违反了有效使用条件。因此，使用从已释放的主机分配导入的内存对象会导致未定义的行为。

4) vkMapMemory 是否应返回导入到内存对象时指定的主机地址？

已解决：否。允许实现返回相同的地址，但这不是必需的。某些实现可能会返回分配的不同虚拟映射，尽管会使用相同的物理页面。

5) 主机指针和/或大小的对齐是否有任何限制？

已解决：是的。地址和大小都必须是 minImportedHostPointerAlignment 的整数倍。此外，某些平台和外部设备可能具有其他限制。

6) 可以将同一主机分配多次导入到给定的物理设备吗？

已解决：否，至少此扩展不能保证。某些平台不允许多次锁定相同的物理页面进行设备访问，因此尝试这样做可能会导致未定义的行为。

7) 此扩展是否支持导出新的句柄类型？

已解决：否。

8) 我们是否应该使用此 API 包含导入主机映射的外部设备内存的可能性？

已解决：是的，通过单独的句柄类型。仍然允许实现仅支持此扩展引入的句柄类型之一，方法是不返回 VkExternalMemoryPropertiesKHR 中返回的特定句柄类型的导入支持。

版本历史

  • 修订版 1，2017-11-10 (Daniel Rakos)

    • 内部修订

VK_EXT_filter_cubic

名称字符串

VK_EXT_filter_cubic

扩展类型

设备扩展

注册扩展号

171

修订

3

批准状态

已批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2019-12-13

贡献者

  • Bill Licea-Kane，高通技术公司。

  • Andrew Garrard，三星

  • Daniel Koch, NVIDIA

  • Donald Scorgie, Imagination Technologies

  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, ARM

  • Jeff Leger，高通技术公司

  • Tobias Hector, AMD

  • Tom Olson, ARM

  • Stuart Smith, Imagination Technologies

描述

VK_EXT_filter_cubic 扩展了 VK_IMG_filter_cubic。

它记录了其他图像视图类型的立方体过滤。它添加了新的结构，这些结构可以添加到 VkPhysicalDeviceImageFormatInfo2 和 VkImageFormatProperties2 的 pNext 链中，这些结构可以用于确定哪些图像类型和哪些图像视图类型支持立方体过滤。

新结构

新枚举常量

  • VK_EXT_FILTER_CUBIC_EXTENSION_NAME

  • VK_EXT_FILTER_CUBIC_SPEC_VERSION

  • 扩展 VkFilter

    • VK_FILTER_CUBIC_EXT

  • 扩展 VkFormatFeatureFlagBits

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_CUBIC_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_FILTER_CUBIC_IMAGE_VIEW_IMAGE_FORMAT_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_VIEW_IMAGE_FORMAT_INFO_EXT

版本历史

  • 修订版 3，2019-12-13 (wwlk)

    • 删除对以 USCALED_PACKED32、SSCALED_PACKED32、UINT_PACK32 和 SINT_PACK32 格式进行立方体过滤的要求（剪切/粘贴错误）

  • 修订版 2，2019-06-05 (wwlk)

    • 澄清 1D 可选

  • 修订版 1，2019-01-24 (wwlk)

    • 初始版本

VK_EXT_fragment_density_map

名称字符串

VK_EXT_fragment_density_map

扩展类型

设备扩展

注册扩展号

219

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_dynamic_rendering 交互

  • 与 VK_KHR_format_feature_flags2 交互

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2021-09-30

交互和外部依赖
贡献者

  • Matthew Netsch，高通技术公司

  • Robert VanReenen，高通技术公司

  • Jonathan Wicks，高通技术公司

  • Tate Hornbeck，高通技术公司

  • Sam Holmes，高通技术公司

  • Jeff Leger，高通技术公司

  • Jan-Harald Fredriksen, ARM

  • Jeff Bolz, NVIDIA

  • Pat Brown, NVIDIA

  • Daniel Rakos, AMD

  • Piers Daniell, NVIDIA

描述

此扩展允许应用程序指定渲染目标区域，在这些区域中，片段着色器可能被调用的次数较少。这些片段被广播到多个像素以覆盖渲染目标。

此扩展的主要用途是减少在可能感知不到较低质量的区域（例如镜头扭曲的边缘或用户注视的外围）中的工作负载。

新结构

如果支持 Vulkan 版本 1.3 或 VK_KHR_dynamic_rendering

新枚举常量

  • VK_EXT_FRAGMENT_DENSITY_MAP_EXTENSION_NAME

  • VK_EXT_FRAGMENT_DENSITY_MAP_SPEC_VERSION

  • 扩展 VkAccessFlagBits

    • VK_ACCESS_FRAGMENT_DENSITY_MAP_READ_BIT_EXT

  • 扩展 VkFormatFeatureFlagBits

    • VK_FORMAT_FEATURE_FRAGMENT_DENSITY_MAP_BIT_EXT

  • 扩展 VkImageCreateFlagBits

    • VK_IMAGE_CREATE_SUBSAMPLED_BIT_EXT

  • 扩展 VkImageLayout

    • VK_IMAGE_LAYOUT_FRAGMENT_DENSITY_MAP_OPTIMAL_EXT

  • 扩展 VkImageUsageFlagBits

    • VK_IMAGE_USAGE_FRAGMENT_DENSITY_MAP_BIT_EXT

  • 扩展 VkImageViewCreateFlagBits

    • VK_IMAGE_VIEW_CREATE_FRAGMENT_DENSITY_MAP_DYNAMIC_BIT_EXT

  • 扩展 VkPipelineStageFlagBits

    • VK_PIPELINE_STAGE_FRAGMENT_DENSITY_PROCESS_BIT_EXT

  • 扩展 VkSamplerCreateFlagBits

    • VK_SAMPLER_CREATE_SUBSAMPLED_BIT_EXT

    • VK_SAMPLER_CREATE_SUBSAMPLED_COARSE_RECONSTRUCTION_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_RENDER_PASS_FRAGMENT_DENSITY_MAP_CREATE_INFO_EXT

如果支持 VK_KHR_format_feature_flags2 或 Vulkan 1.3 版本

如果支持 Vulkan 版本 1.3 或 VK_KHR_dynamic_rendering

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_RENDERING_FRAGMENT_DENSITY_MAP_ATTACHMENT_BIT_EXT

    • VK_PIPELINE_RASTERIZATION_STATE_CREATE_FRAGMENT_DENSITY_MAP_ATTACHMENT_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_RENDERING_FRAGMENT_DENSITY_MAP_ATTACHMENT_INFO_EXT

新的或修改的内置变量

新的 SPIR-V 功能

版本历史

  • 修订版 1，2018-09-25（Matthew Netsch）

    • 初始版本

  • 修订版 2，2021-09-30 (Jon Leech)

VK_EXT_fragment_density_map2

名称字符串

VK_EXT_fragment_density_map2

扩展类型

设备扩展

注册扩展号

333

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_EXT_fragment_density_map

联系方式

其他扩展元数据

上次修改日期

2020-06-16

交互和外部依赖

  • 与 Vulkan 1.1 交互

贡献者

  • Matthew Netsch，高通技术公司

  • Jonathan Tinkham，高通技术公司

  • Jonathan Wicks，高通技术公司

  • Jan-Harald Fredriksen, ARM

描述

此扩展向 VK_EXT_fragment_density_map 添加了其他功能和属性，以减少片段密度映射主机延迟，并改进对子采样采样器实现相关行为的查询。

新结构

新枚举常量

  • VK_EXT_FRAGMENT_DENSITY_MAP_2_EXTENSION_NAME

  • VK_EXT_FRAGMENT_DENSITY_MAP_2_SPEC_VERSION

  • 扩展 VkImageViewCreateFlagBits

    • VK_IMAGE_VIEW_CREATE_FRAGMENT_DENSITY_MAP_DEFERRED_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_2_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_2_PROPERTIES_EXT

版本历史

  • 修订版 1，2020-06-16（Matthew Netsch）

    • 初始版本

VK_EXT_fragment_shader_interlock

名称字符串

VK_EXT_fragment_shader_interlock

扩展类型

设备扩展

注册扩展号

252

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2019-05-02

交互和外部依赖
贡献者

  • Daniel Koch, NVIDIA

  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, Arm

  • Faith Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Ruihao Zhang，高通

  • Slawomir Grajewski, Intel

  • Spencer Fricke, Samsung

描述

此扩展增加了对 Vulkan 中 SPV_EXT_fragment_shader_interlock 扩展的 FragmentShaderPixelInterlockEXT、FragmentShaderSampleInterlockEXT 和 FragmentShaderShadingRateInterlockEXT 功能的支持。

启用这些功能为片段着色器提供了一个关键部分，以避免同时处理重叠的像素，并提供有关重叠像素的片段的片段着色器调用的顺序的某些保证。

此扩展对于需要通过着色器加载和存储访问每个像素数据结构的算法很有用。使用此扩展的算法可以在关键部分访问每个像素数据结构，而无需其他调用访问相同的每个像素数据。此外，排序保证对于片段的 API 排序有意义的情况很有用。例如，应用程序可能能够在片段着色器中执行可编程的混合操作，其中通过图像加载读取目标缓冲区，并通过图像存储写入最终值。

新结构

新枚举常量

  • VK_EXT_FRAGMENT_SHADER_INTERLOCK_EXTENSION_NAME

  • VK_EXT_FRAGMENT_SHADER_INTERLOCK_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_INTERLOCK_FEATURES_EXT

新的 SPIR-V 功能

版本历史

  • 修订版 1，2019-05-24 (Piers Daniell)

    • 内部修订

VK_EXT_frame_boundary

名称字符串

VK_EXT_frame_boundary

扩展类型

设备扩展

注册扩展号

376

修订

1

批准状态

已批准

扩展和版本依赖关系

无

联系方式
扩展提案

VK_EXT_frame_boundary

其他扩展元数据

上次修改日期

2023-06-14

贡献者

  • James Fitzpatrick, Imagination Technologies

  • Hugues Evrard，谷歌

  • Melih Yasin Yalcin，谷歌

  • Andrew Garrard，Imagination Technologies

  • Jan-Harald Fredriksen, Arm

  • Vassili Nikolaev, NVIDIA

  • Ting Wei，华为

描述

VK_EXT_frame_boundary 是一个设备扩展，可以帮助工具（例如调试器）在非平凡场景中按帧对队列提交进行分组，通常当 vkQueuePresentKHR 不是相关的帧边界分隔符时。

新结构

新枚举

新位掩码

新枚举常量

  • VK_EXT_FRAME_BOUNDARY_EXTENSION_NAME

  • VK_EXT_FRAME_BOUNDARY_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_FRAME_BOUNDARY_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAME_BOUNDARY_FEATURES_EXT

版本历史

  • 修订版 0，2022-01-14 (Hugues Evard)

    • 初始提案

  • 修订版 1，2023-06-14 (James Fitzpatrick)

    • 初始草案

VK_EXT_full_screen_exclusive

名称字符串

VK_EXT_full_screen_exclusive

扩展类型

设备扩展

注册扩展号

256

修订

4

批准状态

已批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
    或
     Vulkan 版本 1.1
和
VK_KHR_surface
和
VK_KHR_get_surface_capabilities2
和
VK_KHR_swapchain

API 交互

  • 与 VK_VERSION_1_1 交互

  • 与 VK_KHR_device_group 交互

  • 与 VK_KHR_win32_surface 交互

联系方式

其他扩展元数据

上次修改日期

2019-03-12

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Hans-Kristian Arntzen，ARM

  • Slawomir Grajewski, Intel

  • Tobias Hector, AMD

  • James Jones, NVIDIA

  • Daniel Rakos, AMD

  • Jeff Juliano, NVIDIA

  • Joshua Schnarr，NVIDIA

  • Aaron Hagan, AMD

描述

此扩展允许应用程序设置与全屏访问相关的交换链创建和呈现机制的策略。实现可能能够为覆盖整个屏幕的应用程序窗口获取对特定显示器的独占访问权限。这可以通过绕过合成来提高某些系统上的性能，但是当发生更改时，也可能导致底层窗口系统中的破坏性或昂贵的转换。

应用程序可以选择明确禁止或允许此行为，让实现决定，或使用新的 vkAcquireFullScreenExclusiveModeEXT 和 vkReleaseFullScreenExclusiveModeEXT 命令直接管理此操作模式。

新命令

如果支持 VK_KHR_device_group 或 Vulkan 版本 1.1

新结构

如果支持 VK_KHR_win32_surface

新枚举

新枚举常量

  • VK_EXT_FULL_SCREEN_EXCLUSIVE_EXTENSION_NAME

  • VK_EXT_FULL_SCREEN_EXCLUSIVE_SPEC_VERSION

  • 扩展 VkResult

    • VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_FULL_SCREEN_EXCLUSIVE_EXT

    • VK_STRUCTURE_TYPE_SURFACE_FULL_SCREEN_EXCLUSIVE_INFO_EXT

如果支持 VK_KHR_win32_surface

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_SURFACE_FULL_SCREEN_EXCLUSIVE_WIN32_INFO_EXT

问题

1) 扩展和标志应该叫什么？

已解决: VK_EXT_full_screen_exclusive。

其他考虑的选项（在应用控制模式之前）是

  • VK_EXT_smooth_fullscreen_transition

  • VK_EXT_fullscreen_behavior

  • VK_EXT_fullscreen_preference

  • VK_EXT_fullscreen_hint

  • VK_EXT_fast_fullscreen_transition

  • VK_EXT_avoid_fullscreen_exclusive

2) 我们是否需要比布尔切换更多的东西？

已解决：可以。

使用具有默认/允许/禁止/应用程序控制的枚举，使应用程序能够接受驱动程序默认行为，特别是在任何一个方向上覆盖它，而不会暗示驱动程序始终需要使用全屏独占机制，或显式管理此模式。

3) 这应该是 KHR 还是 EXT 扩展？

已解决: EXT，为了能够更快地发布。

4) 全屏提示是否会影响表面功能，如果是这样，在查询表面功能时是否也应将提示指定为输入？

已解决: 两者都是。

虽然提示不能保证在创建交换链时将使用特定的全屏模式，但有时会暗示将不使用特定的模式。如果驱动程序确定它将根据策略选择不使用特定模式，并且知道如果使用该模式则只能支持某些功能，那么在这种情况下向应用程序报告这些功能充其量会令人困惑。不允许实现向应用程序报告此状态可能会导致应用程序无法确定为什么在指定某些提示值时交换链创建失败的情况，这可能会导致永不终止的表面创建循环。

5) 全屏是一个词还是两个词？

已解决: 两个词。

我的字典中没有“Fullscreen”，并且网络搜索没有找到确凿的证据表明它是一个口语上被接受的复合词。相应的 Windows API 机制的文档含糊不清。文本始终使用连字符，但是，在 DXGI 交换链对象中有一个 SetFullscreenState 方法。鉴于这种不确定的外部指导，最好遵守 Vulkan 样式指南，避免发明新的复合词。

版本历史

  • 修订版 4，2019-03-12 (Tobias Hector)

    • 添加了应用程序控制模式和相关功能

    • 整理了附录

  • 修订版 3，2019-01-03 (James Jones)

    • 重命名为 VK_EXT_full_screen_exclusive

    • 对三态枚举名称进行了相关调整。

  • 修订版 2，2018-11-27 (James Jones)

    • 重命名为 VK_KHR_fullscreen_behavior

    • 从布尔标志切换到三态枚举

  • 修订版 1，2018-11-06 (James Jones)

    • 内部修订

VK_EXT_graphics_pipeline_library

名称字符串

VK_EXT_graphics_pipeline_library

扩展类型

设备扩展

注册扩展号

321

修订

1

批准状态

已批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
    或
     Vulkan 版本 1.1
和
VK_KHR_pipeline_library

联系方式
扩展提案

VK_EXT_graphics_pipeline_library

其他扩展元数据

上次修改日期

2021-08-17

贡献者

  • Tobias Hector, AMD

  • Chris Glover, Google

  • Jeff Leger, Qualcomm

  • Jan-Harald Fredriksen, Arm

  • Piers Daniell, 英伟达

  • Boris Zanin, Mobica

  • Krzysztof Niski, 英伟达

  • Dan Ginsburg, Valve

  • Sebastian Aaltonen, Unity

  • Arseny Kapoulkine, Roblox

  • Calle Lejdfors, 育碧

  • Tiago Rodrigues, 育碧

  • Francois Duranleau, Gameloft

描述

此扩展允许单独编译图形管线的四个不同部分，旨在为在多个管线中重用相同着色器或状态的应用程序加快管线的加载速度。每个部分都可以独立编译到图形管线库中，最后需要一个链接步骤才能创建可绑定到命令缓冲区的可执行管线。

新结构体

新枚举

新位掩码

新枚举常量

  • VK_EXT_GRAPHICS_PIPELINE_LIBRARY_EXTENSION_NAME

  • VK_EXT_GRAPHICS_PIPELINE_LIBRARY_SPEC_VERSION

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_LINK_TIME_OPTIMIZATION_BIT_EXT

    • VK_PIPELINE_CREATE_RETAIN_LINK_TIME_OPTIMIZATION_INFO_BIT_EXT

  • 扩展 VkPipelineLayoutCreateFlagBits

    • VK_PIPELINE_LAYOUT_CREATE_INDEPENDENT_SETS_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_LIBRARY_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GRAPHICS_PIPELINE_LIBRARY_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GRAPHICS_PIPELINE_LIBRARY_PROPERTIES_EXT

版本历史

  • 修订版 1，2021-08-17 (Tobias Hector)

    • 初始草案。

VK_EXT_hdr_metadata

名称字符串

VK_EXT_hdr_metadata

扩展类型

设备扩展

注册扩展号

106

修订

3

批准状态

已批准

扩展和版本依赖关系

VK_KHR_swapchain

联系方式

其他扩展元数据

上次修改日期

2024-03-26

IP 状态

没有已知的 IP 声明。

贡献者

  • Courtney Goeltzenleuchter, Google

  • Sebastian Wick, Red Hat Inc.

  • Tobias Hector, AMD

描述

此扩展定义了两个新结构体和一个函数，用于将 SMPTE（电影与电视工程师协会）2086 元数据和 CTA（消费技术协会）861.3 元数据分配给交换链。

SMPTE 2086 元数据定义了内容针对观看进行了优化的显示器的色域，包括色原色、白点和亮度范围。当在另一个显示器上重现此类内容时，演示引擎可以使用此元数据来改进图像处理。例如，图像中的值可以首先钳制到元数据中描述的色域，然后可以将剩余的值重新映射到演示引擎的色域。

CTA 861.3 元数据还包括内容的最大预期亮度和跨帧的最大平均光照水平。

此扩展不确切定义如何使用此元数据，但是，它只是提供了一种将其提供给演示引擎的机制。演示引擎可能会在显示图像之前根据元数据处理图像，从而导致图像在 Vulkan 之外被修改。例如，将图像中的颜色钳制到色域可能会更改图像本身中的这些值。

元数据不会覆盖或以其他方式影响颜色空间和颜色编码。

新命令

新结构体

新枚举常量

  • VK_EXT_HDR_METADATA_EXTENSION_NAME

  • VK_EXT_HDR_METADATA_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_HDR_METADATA_EXT

问题

1) 我们是否需要一个查询当前指定元数据的函数？

不需要，Vulkan 不会为应用程序可以自行跟踪的状态提供查询。

2) 如果应用程序未指定，我们是否应该指定默认元数据？

不需要，元数据是可选的，并且缺少元数据是明确定义的。

版本历史

  • 修订版 1，2016-12-27 (Courtney Goeltzenleuchter)

    • 初始版本

  • 修订版 2，2018-12-19 (Courtney Goeltzenleuchter)

    • 更正了 VkHdrMetadataEXT 结构的隐式有效性

  • 修订版 3，2024-03-26 (Tobias Hector & Sebastian Wick)

    • 澄清并删除了错误的“参考监视器”术语

VK_EXT_headless_surface

名称字符串

VK_EXT_headless_surface

扩展类型

实例扩展

注册扩展号

257

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

其他扩展元数据

上次修改日期

2019-03-21

IP 状态

没有已知的 IP 声明。

贡献者

  • Ray Smith, Arm

描述

VK_EXT_headless_surface 扩展是一个实例扩展。它提供了一种独立于任何窗口系统或显示设备创建 VkSurfaceKHR 对象的方式。从无头表面创建的交换链的演示操作默认情况下是空操作，不会产生外部可见的结果。

由于没有真正的演示目标，未来的扩展可以在无头表面之上分层，以引入任意或可定制的限制或功能集。这些可以包括诸如保存到文件或限制以模拟特定演示目标的功能。

此功能有望对应用程序和驱动程序开发有用，因为它允许任何平台公开演示引擎的任意或可定制的限制和功能集。这使其成为针对各种演示引擎的应用程序的有用可移植测试目标，其中实际的目标演示引擎可能稀缺、不可用或在用于通用 Vulkan 应用程序开发时不受欢迎或不方便。

新命令

新结构体

新位掩码

新枚举常量

  • VK_EXT_HEADLESS_SURFACE_EXTENSION_NAME

  • VK_EXT_HEADLESS_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_HEADLESS_SURFACE_CREATE_INFO_EXT

版本历史

  • 修订版 1，2019-03-21 (Ray Smith)

    • 初始草案

VK_EXT_image_2d_view_of_3d

名称字符串

VK_EXT_image_2d_view_of_3d

扩展类型

设备扩展

注册扩展号

394

修订

1

批准状态

已批准

扩展和版本依赖关系

     VK_KHR_maintenance1
     和
     VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

  • Mike Blumenkrantz zmike

其他扩展元数据

上次修改日期

2022-02-22

IP 状态

没有已知的 IP 声明。

贡献者

  • Mike Blumenkrantz, Valve

  • Piers Daniell, NVIDIA

  • Spencer Fricke, Samsung

  • Ricardo Garcia, Igalia

  • Graeme Leese, Broadcom

  • Ralph Potter, Samsung

  • Stu Smith, AMD

  • Shahbaz Youssefi, Google

  • Alex Walters, Imagination

描述

此扩展允许将 3D 图像的单个切片用作图像描述符中的 2D 视图，同时匹配 OpenGL 中 layer 参数设置为 true 的 glBindImageTexture 功能以及 EGL_KHR_gl_texture_3D_image 扩展提供的 2D 视图绑定。它主要用于支持 GL 模拟。

新结构体

新枚举常量

  • VK_EXT_IMAGE_2D_VIEW_OF_3D_EXTENSION_NAME

  • VK_EXT_IMAGE_2D_VIEW_OF_3D_SPEC_VERSION

  • 扩展 VkImageCreateFlagBits

    • VK_IMAGE_CREATE_2D_VIEW_COMPATIBLE_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_2D_VIEW_OF_3D_FEATURES_EXT

版本历史

  • 修订版 1，2022-03-25 (Mike Blumenkrantz)

    • 内部修订

VK_EXT_image_compression_control

名称字符串

VK_EXT_image_compression_control

扩展类型

设备扩展

注册扩展号

339

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式
扩展提案

VK_EXT_image_compression_control

其他扩展元数据

上次修改日期

2022-05-02

IP 状态

没有已知的 IP 声明。

贡献者

  • Jan-Harald Fredriksen, Arm

  • Graeme Leese, Broadcom

  • Andrew Garrard, Imagination

  • Lisa Wu, Arm

  • Peter Kohaut, Arm

描述

此扩展启用固定速率图像压缩，并增加了控制何时应用此类压缩的功能。许多实现都支持某种形式的帧缓冲区压缩。由于使用无损压缩方案，这通常对应用程序是透明的。使用固定速率压缩时，压缩以定义的比特率完成。这种压缩算法通常会产生视觉上无损的结果，但与未压缩的结果相比，结果通常不是位精确的。在所有情况下，实现可能无法使用请求的压缩率。此扩展添加了一个查询，可用于确定应用于图像的压缩方案和速率。

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_EXT_IMAGE_COMPRESSION_CONTROL_EXTENSION_NAME

  • VK_EXT_IMAGE_COMPRESSION_CONTROL_SPEC_VERSION

  • 扩展 VkResult

    • VK_ERROR_COMPRESSION_EXHAUSTED_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMAGE_COMPRESSION_CONTROL_EXT

    • VK_STRUCTURE_TYPE_IMAGE_COMPRESSION_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_IMAGE_SUBRESOURCE_2_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_COMPRESSION_CONTROL_FEATURES_EXT

    • VK_STRUCTURE_TYPE_SUBRESOURCE_LAYOUT_2_EXT

版本历史

  • 修订版 1，2022-05-02 (Jan-Harald Fredriksen)

    • 初始草案

VK_EXT_image_compression_control_swapchain

名称字符串

VK_EXT_image_compression_control_swapchain

扩展类型

设备扩展

注册扩展号

438

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_EXT_image_compression_control

联系方式

其他扩展元数据

上次修改日期

2022-05-02

IP 状态

没有已知的 IP 声明。

贡献者

  • Jan-Harald Fredriksen, Arm

  • Graeme Leese, Broadcom

  • Andrew Garrard, Imagination

  • Lisa Wu, Arm

  • Peter Kohaut, Arm

  • Ian Elliott, Google

描述

此扩展启用固定速率图像压缩，并增加了控制何时将此类压缩应用于交换链图像的功能。

新结构体

新枚举常量

  • VK_EXT_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN_EXTENSION_NAME

  • VK_EXT_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN_FEATURES_EXT

版本历史

  • 修订版 1，2022-05-02 (Jan-Harald Fredriksen)

    • 初始草案

VK_EXT_image_drm_format_modifier

名称字符串

VK_EXT_image_drm_format_modifier

扩展类型

设备扩展

注册扩展号

159

修订

2

批准状态

已批准

扩展和版本依赖关系

             VK_KHR_bind_memory2
             和
             VK_KHR_get_physical_device_properties2
             和
             VK_KHR_sampler_ycbcr_conversion
         或
         Vulkan 版本 1.1
     和
     VK_KHR_image_format_list
或
Vulkan 版本 1.2

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_format_feature_flags2 交互

联系方式

其他扩展元数据

上次修改日期

2021-09-30

IP 状态

没有已知的 IP 声明。

贡献者

  • Antoine Labour, Google

  • Bas Nieuwenhuizen, Google

  • Lina Versace，谷歌

  • James Jones, NVIDIA

  • Faith Ekstrand, Intel

  • Jőrg Wagner, ARM

  • Kristian Høgsberg Kristensen, Google

  • Ray Smith, ARM

描述

此扩展提供了对图像使用DRM 格式修饰符的功能，使 Vulkan 能够更好地与 Linux 图形、视频和显示 API 生态系统集成。

它的功能与 EGL_EXT_image_dma_buf_import_modifiers2 和 EGL_MESA_image_dma_buf_export3 非常相似。与 EGL 扩展不同，此扩展不需要使用特定句柄类型（例如 dma_buf）进行外部内存，并且提供了对图像创建的更明确的控制。

DRM 格式修饰符简介

DRM 格式修饰符是一个 64 位、具有供应商前缀的半不透明无符号整数。大多数修饰符表示图像的具体的、供应商特定的平铺格式。一些例外是 DRM_FORMAT_MOD_LINEAR（不是供应商特定的）；DRM_FORMAT_MOD_NONE（由于历史原因，它是 DRM_FORMAT_MOD_LINEAR 的别名）；以及 DRM_FORMAT_MOD_INVALID（不代表平铺格式）。修饰符的供应商前缀由最重要的 8 位组成。修饰符和供应商前缀的规范列表在 Linux 内核源代码的 drm_fourcc.h 中找到。修饰符的另一个主要来源是供应商内核树。

Linux 生态系统中修饰符的一个目标是为每个供应商枚举一组合理大小的平铺格式，这些格式适用于在进程、API 和/或设备之间共享的图像，其中每个参与组件可能来自不同的供应商。一个非目标是枚举所有供应商支持的所有平铺格式。供应商内部使用的一些平铺格式不适合共享；不应为这种平铺格式分配任何修饰符。

修饰符值通常不描述内存布局。更准确地说，修饰符的低 56 位通常没有结构。相反，修饰符命名内存布局；它们命名了一小组用于图像共享的供应商首选布局。因此，在每个供应商命名空间中，修饰符值通常从 1 开始按顺序分配。

每个修饰符通常由单个供应商支持，其名称与模式 {VENDOR}_FORMAT_MOD_* 或 DRM_FORMAT_MOD_{VENDOR}_* 匹配。例如 I915_FORMAT_MOD_X_TILED 和 DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED。例外是 DRM_FORMAT_MOD_LINEAR，它受大多数供应商支持。

Linux 中的许多 API 使用修饰符来协商和指定共享图像的内存布局。例如，Wayland 合成器和 Wayland 客户端可以通过在 Wayland 协议 zwp_linux_dmabuf_v1 上中继修饰符，为共享 wl_buffer 协商供应商特定的平铺格式。客户端可以使用 GBM 为 wl_buffer 分配底层内存，并向 gbm_bo_create_with_modifiers 提供所选的修饰符。然后，客户端可以将 wl_buffer 导入到 Vulkan 中以生成图像内容，将资源的 dma_buf 提供给 VkImportMemoryFdInfoKHR，并将其修饰符提供给 VkImageDrmFormatModifierExplicitCreateInfoEXT。然后，合成器可以将 wl_buffer 导入到 OpenGL 中进行采样，将资源的 dma_buf 和修饰符提供给 eglCreateImage。合成器也可以绕过 OpenGL 并直接将 wl_buffer 提交到内核的显示 API，通过 drm_mode_fb_cmd2 提供 dma_buf 和修饰符。

格式转换

支持修饰符的 API 通常会将修饰符与 DRM 格式配对，这些格式在 drm_fourcc.h 中定义。但是，VK_EXT_image_drm_format_modifier 使用 VkFormat 而不是 DRM 格式。当应用程序向外部 API 发送或从外部 API 接收 DRM 格式时，必须在 VkFormat 和 DRM 格式之间进行转换。

从 VkFormat 到 DRM 格式的映射是有损的。因此，当从外部 API 接收 DRM 格式时，应用程序通常必须使用来自外部 API 的信息来准确地将 DRM 格式映射到 VkFormat。例如，DRM 格式不区分 RGB 和 sRGB（截至 2018-03-28）；需要外部信息来识别图像的色彩空间。

VkFormat 和 DRM 格式之间的映射也是不完整的。对于某些 DRM 格式，不存在对应的 Vulkan 格式，而对于某些 Vulkan 格式，不存在对应的 DRM 格式。

使用模式

此扩展预期用于三种主要使用模式

  • 协商。 应用程序与支持修饰符的外部组件协商，以确定所有组件都支持的图像创建参数集。

    在 Linux 生态系统中，协商通常假设图像是 2D、单采样、非 mipmapped、非数组图像；此扩展允许这种假设，但不是必需的。协商的结果通常类似于元组集，例如 (drmFormat, drmFormatModifier)，其中每个参与组件都支持该集合中的所有元组。

    此协商的许多细节 - 例如协商期间使用的协议、协议中可表达的图像创建参数集，以及协议如何选择哪个进程和哪个 API 将创建图像 - 都不在此规范的范围内。

    在此扩展中，带有 VkDrmFormatModifierPropertiesListEXT 的 vkGetPhysicalDeviceFormatProperties2 在协商期间起着主要作用，而带有 VkPhysicalDeviceImageDrmFormatModifierInfoEXT 的 vkGetPhysicalDeviceImageFormatProperties2 起着次要作用。

  • 导入。应用程序导入带有修饰符的图像。

    在此模式下，应用程序从外部来源接收图像的内存及其创建参数，这些参数通常是上述协商的结果。某些图像创建参数由外部来源隐式定义；例如，通常假设 VK_IMAGE_TYPE_2D。某些图像创建参数通常是显式的，例如图像的 format、drmFormatModifier 和 extent；以及每个平面的 offset 和 rowPitch。

    在创建图像之前，应用程序首先通过使用 VkDrmFormatModifierPropertiesListEXT 查询 vkGetPhysicalDeviceFormatProperties2 和使用 VkPhysicalDeviceImageDrmFormatModifierInfoEXT 查询 vkGetPhysicalDeviceImageFormatProperties2 来验证物理设备是否支持接收到的创建参数。然后，应用程序通过将 VkImageDrmFormatModifierExplicitCreateInfoEXT 和 VkExternalMemoryImageCreateInfo 链接到 VkImageCreateInfo 来创建图像。

  • 导出。应用程序创建一个图像并分配其内存。然后，应用程序将图像的内存句柄；其创建参数；其修饰符；以及每个内存平面的 offset、size 和 rowPitch 导出到支持修饰符的消费者。

    在此模式下，Vulkan 设备是图像的权威；它是图像内存的分配器和图像创建参数的决策者。在选择图像的创建参数时，应用程序通常从上述协商的结果中选择一个元组 (format, drmFormatModifier)。协商的结果通常包含多个共享相同格式但修饰符不同的元组。在这种情况下，应用程序应通过向 VkImageDrmFormatModifierListCreateInfoEXT::pDrmFormatModifiers 提供所有此类修饰符来将图像的修饰符的选择推迟到 Vulkan 实现；并且实现应在考虑其他图像参数的情况下从 pDrmFormatModifiers 中选择最佳修饰符。

    应用程序通过将 VkImageDrmFormatModifierListCreateInfoEXT 和 VkExternalMemoryImageCreateInfo 链接到 VkImageCreateInfo 来创建图像。应用程序将通过其与外部消费者共享图像的协议和 API 可能会确定 VkExternalMemoryImageCreateInfo::handleTypes 的值。实现从 VkImageDrmFormatModifierListCreateInfoEXT::pDrmFormatModifiers 中为图像选择一个最佳修饰符。然后，应用程序使用 vkGetImageDrmFormatModifierPropertiesEXT 查询实现选择的修饰符，并使用 vkGetImageSubresourceLayout 查询每个平面的内存布局。

    然后，应用程序使用 VkMemoryAllocateInfo 分配图像的内存，添加用于外部内存的链式扩展结构；将其绑定到图像；并导出内存，例如使用 vkGetMemoryFdKHR。

    最后，应用程序将图像的创建参数、其修饰符、其每个平面的内存布局以及导出的内存句柄发送给外部消费者。应用程序如何将此信息传输给外部消费者的详细信息不在此规范的范围内。

现有技术

扩展 EGL_EXT_image_dma_buf_import1 引入了通过为每个平面导入 dma_buf、偏移量和行距来创建 EGLImage 的功能。

之后，扩展 EGL_EXT_image_dma_buf_import_modifiers2 引入了查询实现支持的格式和修饰符的组合，以及在创建 EGLImage 期间指定修饰符的功能。

扩展 EGL_MESA_image_dma_buf_export3 是 EGL_EXT_image_dma_buf_import_modifiers 的逆操作。

Linux 内核模式设置 API (KMS) 在使用 struct drm_mode_fb_cmd24 配置显示的帧缓冲区时，允许指定帧缓冲区的修饰符以及每个平面的内存句柄、偏移量和行距。

GBM，一个用于 Linux 的图形缓冲区管理器，允许通过导入类似于 EGL_EXT_image_dma_buf_import_modifiers1 中的数据来创建 gbm_bo（即图形缓冲区对象）；并且对称地允许从 gbm_bo 导出相同的数据。 请参阅 gbm.h5 中对modifier 和 plane 的引用。

新命令

新结构体

如果支持 VK_KHR_format_feature_flags2 或 Vulkan 1.3 版本

新枚举常量

  • VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME

  • VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_SPEC_VERSION

  • 扩展 VkImageAspectFlagBits

    • VK_IMAGE_ASPECT_MEMORY_PLANE_0_BIT_EXT

    • VK_IMAGE_ASPECT_MEMORY_PLANE_1_BIT_EXT

    • VK_IMAGE_ASPECT_MEMORY_PLANE_2_BIT_EXT

    • VK_IMAGE_ASPECT_MEMORY_PLANE_3_BIT_EXT

  • 扩展 VkImageTiling

    • VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT

  • 扩展 VkResult

    • VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_LIST_EXT

    • VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_EXPLICIT_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_LIST_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_DRM_FORMAT_MODIFIER_INFO_EXT

如果支持 VK_KHR_format_feature_flags2 或 Vulkan 1.3 版本

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_LIST_2_EXT

问题

1) 此扩展应该为每个 VkImage 定义一个 DRM 格式 modifier 吗？还是为每个 plane 定义一个？

+

已解决: 每个 VkImage 存在一个 DRM 格式 modifier。

讨论: 先前的技术，例如 EGL_EXT_image_dma_buf_import_modifiers2、struct drm_mode_fb_cmd24 和 struct gbm_import_fd_modifier_data5，允许为每个 plane 定义一个 modifier。但是，GBM 和内核 API 的开发人员承认这是一个错误。从 Linux 4.10 开始，内核要求应用程序为每个 plane 提供相同的 DRM 格式 modifier。（请参阅 Linux commit bae781b259269590109e8a4a8227331362b88212）。而且 GBM 提供了一个入口点 gbm_bo_get_modifier，用于查询图像的 modifier，但不提供用于查询单个 plane 的 modifier 的入口点。

2) 当使用 VkImageDrmFormatModifierExplicitCreateInfoEXT 创建图像时，通常在导入图像时使用，应用程序是否应该显式提供每个 plane 的大小？

+

已解决: 不应该。应用程序必须不提供大小。为了强制执行此操作，API 要求 VkImageDrmFormatModifierExplicitCreateInfoEXT::pPlaneLayouts->size 必须为 0。

讨论: 先前的技术，例如 EGL_EXT_image_dma_buf_import_modifiers2、struct drm_mode_fb_cmd24 和 struct gbm_import_fd_modifier_data5，在 API 中省略了每个 plane 的大小。相反，API 从导入参数中推断每个 plane 的大小，这些参数包括图像的像素格式和每个 plane 的 dma_buf、偏移量和行距。

但是，Vulkan 在图像创建方面与 EGL 和 GBM 不同，具体如下

图像创建的差异

  • 默认情况下是非专用分配。 当导入或导出作为 EGLImage 或 gbm_bo 的一组 dma_buf 时，常见的做法是强制每个 dma_buf 的内存专用于（在 VK_KHR_dedicated_allocation 的意义上）图像（但不一定专用于单个 plane）。特别是，GBM 文档和 EGL 扩展规范都没有明确说明此要求，但鉴于常见的做法，这很可能是由于规范不足而不是有意省略。相比之下，VK_EXT_image_drm_format_modifier 允许但不要求实现需要使用 VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT 创建的图像的专用分配。

  • 图像创建和内存分配的分离。 当将一组 dma_buf 导入为 EGLImage 或 gbm_bo 时，EGL 和 GBM 会同时创建图像资源并将其绑定到内存（dma_buf）。这允许 EGL 和 GBM 在图像创建期间查询每个 dma_buf 的大小。在 Vulkan 中，除非使用专用分配（如 VK_KHR_dedicated_allocation 中所示），否则图像创建和内存分配是独立的。因此，在不要求专用分配的情况下，Vulkan 在计算图像的内存布局时无法查询每个 dma_buf（或其他外部句柄）的大小。即使需要专用分配，Vulkan 也必须在图像绑定到其 dma_ufs 之后才能计算图像的内存布局。

上述差异使 Vulkan 中 plane 大小的潜在推断变得复杂。考虑以下有问题的案例

有问题的 plane 大小计算

  • 填充。 图像的某些 plane 可能需要依赖于实现的填充。

  • 元数据。 对于某些 modifier，图像可能具有一个元数据 plane，需要进行非平凡的计算才能确定其大小。

  • Mipmapped、数组和 3D 图像。 该实现可能支持 mipLevels、arrayLayers 或 depth 大于 1 的图像的 VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT。对于具有某些 modifier 的此类图像，计算每个 plane 的大小可能并非易事。

但是，应用程序提供的 plane 大小无法解决上述任何问题。

为了简单起见，考虑一个具有单个内存 plane 的外部图像。当其平铺为 VK_IMAGE_TILING_OPTIMAL 时，实现显然能够计算图像的大小。同样，任何合理的实现都能够在使用支持的 modifier 时计算图像的大小。

假设外部图像的大小小于实现计算的大小。如果应用程序将外部图像的大小提供给 vkCreateImage，则实现会观察到大小不匹配，并意识到它无法理解外部图像的布局（除非实现使用应用程序提供的大小来选择由 modifier 指示的平铺布局的细化，这是强烈不鼓励的）。实现将观察到冲突，并拒绝使用 VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT 创建图像。另一方面，如果应用程序没有将外部图像的大小提供给 vkCreateImage，则应用程序会在调用 vkGetImageMemoryRequirements 后观察到外部图像的大小小于实现所需的大小。应用程序将观察到冲突，并拒绝将 VkImage 绑定到外部内存。在这两种情况下，结果都是显式失败。

假设外部图像的大小大于实现计算的大小。如果应用程序将外部图像的大小提供给 vkCreateImage，出于与上述类似的原因，实现会观察到大小不匹配，并意识到它无法理解存在于额外大小中的图像数据。但是，实现必须假设图像数据存在于应用程序提供的整个大小中。实现会观察到冲突，并拒绝创建图像，返回 VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT。另一方面，如果应用程序没有将外部图像的大小提供给 vkCreateImage，那么应用程序在调用 vkGetImageMemoryRequirements 后会观察到外部图像的大小大于实现可使用的大小。应用程序会观察到冲突，并拒绝将 VkImage 绑定到外部内存。在这两种情况下，结果都是明确的失败。

因此，应用程序提供的大小没有任何好处，此扩展不应要求提供它。此决定使得 VkSubresourceLayout::size 在图像创建期间成为一个未使用的字段，因此引入了实现可能要求应用程序在未使用的字段中提交边带创建参数的风险。为了防止实现依赖于边带数据，此扩展要求应用程序将 size 设置为 0。

参考

  1. EGL_EXT_image_dma_buf_import

  2. EGL_EXT_image_dma_buf_import_modifiers

  3. EGL_MESA_image_dma_buf_export

  4. struct drm_mode_fb_cmd2

  5. gbm.h

版本历史

  • 修订版 1，2018-08-29 (Lina Versace)

    • 第一个稳定版本

  • 修订版 2，2021-09-30 (Jon Leech)

VK_EXT_image_sliced_view_of_3d

名称字符串

VK_EXT_image_sliced_view_of_3d

扩展类型

设备扩展

注册扩展号

419

修订

1

批准状态

未批准

扩展和版本依赖关系

     VK_KHR_maintenance1
     和
     VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

  • Mike Blumenkrantz zmike

扩展提案

VK_EXT_image_sliced_view_of_3d

其他扩展元数据

上次修改日期

2023-01-24

IP 状态

没有已知的 IP 声明。

贡献者

  • Mike Blumenkrantz, Valve

  • Hans-Kristian Arntzen, Valve

  • Ricardo Garcia, Igalia

  • Shahbaz Youssefi, Google

  • Piers Daniell, NVIDIA

描述

此扩展允许创建 3D 图像的 3D 视图，以便视图包含图像中的一部分切片，使用 Z 偏移量和范围，目的是将这些视图用作存储图像描述符。这与 D3D12 中的功能相匹配，主要目的是支持 D3D12 模拟。

新结构

新的枚举常量

  • VK_EXT_IMAGE_SLICED_VIEW_OF_3D_EXTENSION_NAME

  • VK_EXT_IMAGE_SLICED_VIEW_OF_3D_SPEC_VERSION

  • VK_REMAINING_3D_SLICES_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_SLICED_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_SLICED_VIEW_OF_3D_FEATURES_EXT

版本历史

  • 修订版 1，2022-10-21 (Mike Blumenkrantz)

    • 初始修订版

VK_EXT_image_view_min_lod

名称字符串

VK_EXT_image_view_min_lod

扩展类型

设备扩展

注册扩展号

392

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2021-11-09

IP 状态

没有已知的 IP 声明。

贡献者

  • Joshua Ashton, Valve

  • Hans-Kristian Arntzen, Valve

  • Samuel Iglesias Gonsalvez，Igalia

  • Tobias Hector, AMD

  • Faith Ekstrand, Intel

  • Tom Olson, ARM

描述

此扩展允许应用程序在 图像级别选择、纹素收集和 整数纹素坐标操作 期间，通过给定的 VkImageView 使用 VkImageViewMinLodCreateInfoEXT::minLod 来钳制最小 LOD 值。

此扩展可能有助于将 VkImageView 限制为仅上传的 mip，并且使用小数 minLod 在使用线性 mipmap 过滤时可以平滑地引入新的 mip 级别。

新结构

新的枚举常量

  • VK_EXT_IMAGE_VIEW_MIN_LOD_EXTENSION_NAME

  • VK_EXT_IMAGE_VIEW_MIN_LOD_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_MIN_LOD_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_VIEW_MIN_LOD_FEATURES_EXT

版本历史

  • 修订版 1，2021-07-06 (Joshua Ashton)

    • 初始版本

VK_EXT_layer_settings

名称字符串

VK_EXT_layer_settings

扩展类型

实例扩展

注册扩展号

497

修订

2

批准状态

已批准

扩展和版本依赖关系

无

联系方式
扩展提案

VK_EXT_layer_settings

其他扩展元数据

上次修改日期

2023-09-23

IP 状态

没有已知的 IP 声明。

贡献者

  • Christophe Riccio，LunarG

  • Mark Lobodzinski, LunarG

  • Charles Giessen, LunarG

  • Spencer Fricke, LunarG

  • Juan Ramos，LunarG

  • Daniel Rakos, RasterGrid

  • Shahbaz Youssefi, Google

  • Lina Versace，谷歌

  • Bill Hollings，The Brenwill Workshop

  • Jon Leech, Khronos

  • Tom Olson, Arm

描述

此扩展提供了一种通过 Vulkan API 以编程方式配置图层行为的机制。

此扩展提供 VkLayerSettingsCreateInfoEXT 结构，该结构可以包含在作为 vkCreateInstance 的 pCreateInfo 参数传递的 VkInstanceCreateInfo 结构的 pNext 链中。

该结构包含一个 VkLayerSettingEXT 结构值数组，用于配置图层的特定功能。

VK_EXT_layer_settings 扩展涵盖了 VK_EXT_validation_flags 扩展和 VK_EXT_validation_features 扩展中提供的所有功能。

新结构

新的枚举

新的枚举常量

  • VK_EXT_LAYER_SETTINGS_EXTENSION_NAME

  • VK_EXT_LAYER_SETTINGS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_LAYER_SETTINGS_CREATE_INFO_EXT

示例

VK_EXT_layer_settings 的一个示例用法是 Vulkan Profiles 层实现的。

它允许 profiles 层 C.I. 使用的 profiles 层测试以编程方式为每个测试配置图层，而不会影响 C.I. 环境，从而允许同时运行多个测试。

const char* profile_file_data = JSON_TEST_FILES_PATH "VP_KHR_roadmap_2022.json";
const char* profile_name_data = "VP_KHR_roadmap_2022";
VkBool32 emulate_portability_data = VK_TRUE;
const char* simulate_capabilities[] = {
    "SIMULATE_API_VERSION_BIT",
    "SIMULATE_FEATURES_BIT",
    "SIMULATE_PROPERTIES_BIT",
    "SIMULATE_EXTENSIONS_BIT",
    "SIMULATE_FORMATS_BIT",
    "SIMULATE_QUEUE_FAMILY_PROPERTIES_BIT"
};
const char* debug_reports[] = {
    "DEBUG_REPORT_ERROR_BIT",
    "DEBUG_REPORT_WARNING_BIT",
    "DEBUG_REPORT_NOTIFICATION_BIT",
    "DEBUG_REPORT_DEBUG_BIT"
};

const VkLayerSettingEXT settings[] = {
     {kLayerName, kLayerSettingsProfileFile, VK_LAYER_SETTING_TYPE_STRING_EXT, 1, &profile_file_data},
     {kLayerName, kLayerSettingsProfileName, VK_LAYER_SETTING_TYPE_STRING_EXT, 1, &profile_name_data},
     {kLayerName, kLayerSettingsEmulatePortability, VK_LAYER_SETTING_TYPE_BOOL32_EXT, 1, &emulate_portability_data},
     {kLayerName, kLayerSettingsSimulateCapabilities, VK_LAYER_SETTING_TYPE_STRING_EXT,
        static_cast<uint32_t>(std::size(simulate_capabilities)), simulate_capabilities},
     {kLayerName, kLayerSettingsDebugReports, VK_LAYER_SETTING_TYPE_STRING_EXT,
        static_cast<uint32_t>(std::size(debug_reports)), debug_reports}
};

const VkLayerSettingsCreateInfoEXT layer_settings_create_info{
    VK_STRUCTURE_TYPE_LAYER_SETTINGS_CREATE_INFO_EXT, nullptr,
    static_cast<uint32_t>(std::size(settings)), settings};

VkInstanceCreateInfo inst_create_info = {};
...
inst_create_info.pNext = &layer_settings_create_info;
vkCreateInstance(&inst_create_info, nullptr, &_instances);

问题

  • 应用程序开发人员应如何确定可用设置的列表？

此扩展不为图层设置提供反射 API。图层设置在每个图层 JSON 清单以及实现此扩展的每个图层的文档中描述。

版本历史

  • 修订版 1，2020-06-17 (Mark Lobodzinski)

    • 用于验证层内部使用的初始修订版

  • 修订版 2，2023-09-26 (Christophe Riccio)

    • 为任何图层使用和公开发布重构 API

VK_EXT_legacy_dithering

名称字符串

VK_EXT_legacy_dithering

扩展类型

设备扩展

注册扩展号

466

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_VERSION_1_4 交互

  • 与 VK_KHR_dynamic_rendering 交互

  • 与 VK_KHR_maintenance5 交互

特殊用途
联系方式
扩展提案

VK_EXT_legacy_dithering

其他扩展元数据

上次修改日期

2024-02-22

贡献者

  • Shahbaz Youssefi, Google

  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, Arm

描述

此扩展公开了某些供应商用于实现 OpenGL 的抖动效果的硬件特性。此扩展的目的是支持在 Vulkan 上分层 OpenGL，允许图层利用相同的硬件特性并为 OpenGL 应用程序提供等效的抖动效果。

新结构体

新枚举常量

  • VK_EXT_LEGACY_DITHERING_EXTENSION_NAME

  • VK_EXT_LEGACY_DITHERING_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LEGACY_DITHERING_FEATURES_EXT

  • 扩展 VkSubpassDescriptionFlagBits

    • VK_SUBPASS_DESCRIPTION_ENABLE_LEGACY_DITHERING_BIT_EXT

如果支持 VK_KHR_dynamic_rendering 或 Vulkan 版本 1.3 和 VK_KHR_maintenance5 或 Vulkan 版本 1.4

版本历史

  • 修订版 1，2022-03-31 (Shahbaz Youssefi)

    • 内部修订

  • 修订版 2，2024-02-22 (Shahbaz Youssefi)

    • 添加了管道创建标志以支持动态渲染

问题

1) 在 OpenGL 中，抖动状态可以动态更改。此扩展是否应为抖动添加管道状态？

已解决：否。在渲染期间，很少甚至从不更改抖动状态。每个被调查的 Android 应用程序要么完全禁用抖动，要么显式启用抖动，要么使用默认状态（已启用）。此外，在某些硬件上，抖动只能在渲染通道粒度中指定，因此抖动状态的更改必然需要导致渲染通道中断。此扩展将 OpenGL 抖动状态的动态更改视为理论情况，并期望图层在这种情况下中断渲染通道而没有任何实际缺点。

VK_EXT_legacy_vertex_attributes

名称字符串

VK_EXT_legacy_vertex_attributes

扩展类型

设备扩展

注册扩展号

496

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_EXT_vertex_input_dynamic_state

特殊用途
联系方式

  • Mike Blumenkrantz zmike

扩展提案

VK_EXT_legacy_vertex_attributes

其他扩展元数据

上次修改日期

2024-02-23

IP 状态

没有已知的 IP 声明。

贡献者

  • Mike Blumenkrantz, Valve

  • Piers Daniell, NVIDIA

  • Spencer Fricke, LunarG

  • Alyssa Rosenzweig，Valve

描述

此扩展增加了对 OpenGL 中发现的（非 64 位）顶点属性的旧版功能的支持

  • 从任意缓冲区对齐方式加载的顶点属性

  • 使用任意步幅的顶点属性

  • 绑定的组件数据类型与着色器输入的组件数值类型不匹配的顶点属性

这些功能只能与动态顶点输入一起使用。顶点属性的未对齐加载可能会导致性能损失，使用属性指示。

新结构体

新枚举常量

  • VK_EXT_LEGACY_VERTEX_ATTRIBUTES_EXTENSION_NAME

  • VK_EXT_LEGACY_VERTEX_ATTRIBUTES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LEGACY_VERTEX_ATTRIBUTES_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LEGACY_VERTEX_ATTRIBUTES_PROPERTIES_EXT

问题

1.) 实现是否应转换浮点/整数值？

已解决：否。当从浮点值获取整数数据类型或从整数值获取浮点数据类型时，生成的着色器值取决于实现。

版本历史

  • 修订版 1，2024-02-16 (Mike Blumenkrantz)

    • 初始修订版

VK_EXT_map_memory_placed

名称字符串

VK_EXT_map_memory_placed

扩展类型

设备扩展

注册扩展号

273

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_map_memory2
或
Vulkan 版本 1.4

联系方式
扩展提案

VK_EXT_map_memory_placed

其他扩展元数据

上次修改日期

2023-03-21

IP 状态

没有已知的 IP 声明。

交互和外部依赖

  • 取决于 apitext:VK_KHR_map_memory2

  • 与 apitext:VK_EXT_external_memory_host 交互

贡献者

  • Faith Ekstrand, Collabora

  • Tobias Hector, AMD

  • James Jones, NVIDIA

  • Georg Lehmann，Valve

  • Derek Lesho，Codeweavers

描述

此扩展允许应用程序请求 vkMapMemory2KHR 尝试将内存映射放置在特定的虚拟地址。

新结构体

新枚举常量

  • VK_EXT_MAP_MEMORY_PLACED_EXTENSION_NAME

  • VK_EXT_MAP_MEMORY_PLACED_SPEC_VERSION

  • 扩展 VkMemoryMapFlagBits

    • VK_MEMORY_MAP_PLACED_BIT_EXT

  • 扩展 VkMemoryUnmapFlagBits

    • VK_MEMORY_UNMAP_RESERVE_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_MEMORY_MAP_PLACED_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAP_MEMORY_PLACED_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAP_MEMORY_PLACED_PROPERTIES_EXT

版本历史

  • 修订版 1，2024-01-14 (Faith Ekstrand)

    • 内部修订

VK_EXT_memory_budget

名称字符串

VK_EXT_memory_budget

扩展类型

设备扩展

注册扩展号

238

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2018-10-08

贡献者

  • Jeff Bolz, NVIDIA

  • Jeff Juliano, NVIDIA

描述

在运行 Vulkan 应用程序时，机器上的其他进程也可能尝试使用相同的设备内存，这可能会带来问题。此扩展增加了对查询内存使用量和内存堆的总内存预算的支持。此查询返回的值取决于实现，并且可能取决于多种因素，包括操作系统和系统负载。

可以使用 VkPhysicalDeviceMemoryBudgetPropertiesEXT::heapBudget 的值作为指导，了解 **当前进程** 在任何给定时间可以从每个堆中使用的内存总量，之后分配可能会开始失败或导致性能下降。这些值可能会根据系统中 Vulkan 实现范围和控制之外的其他活动而变化。

VkPhysicalDeviceMemoryBudgetPropertiesEXT::heapUsage 将显示 **当前进程** 估计的堆使用量。

通过此信息，应用程序可以在某个间隔（每帧一次、每几秒一次等）查询 heapBudget 和 heapUsage。 从这里，应用程序可以注意到它是否超出预算，并决定如何处理内存情况（释放它、移动到主机内存、更改mipmap级别等）。 此扩展旨在与 VK_EXT_memory_priority 结合使用，以帮助进行内存管理。

新结构

新枚举常量

  • VK_EXT_MEMORY_BUDGET_EXTENSION_NAME

  • VK_EXT_MEMORY_BUDGET_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT

版本历史

  • 修订版 1，2018-10-08 (Jeff Bolz)

    • 初始修订版

VK_EXT_memory_priority

名称字符串

VK_EXT_memory_priority

扩展类型

设备扩展

注册扩展号

239

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2018-10-08

贡献者

  • Jeff Bolz, NVIDIA

  • Jeff Juliano, NVIDIA

描述

此扩展在内存分配时添加一个指定的 priority 值。 在某些同时具有设备本地和非设备本地内存堆的系统中，当堆变满时（例如，当所有进程使用的总内存超过堆的大小时），实现可能会透明地将内存从一个堆移动到另一个堆。 在这种情况下，可以使用此优先级值来确定哪些分配更可能保留在设备本地内存中。

新结构

新枚举常量

  • VK_EXT_MEMORY_PRIORITY_EXTENSION_NAME

  • VK_EXT_MEMORY_PRIORITY_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_MEMORY_PRIORITY_ALLOCATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PRIORITY_FEATURES_EXT

版本历史

  • 修订版 1，2018-10-08 (Jeff Bolz)

    • 初始修订版

VK_EXT_mesh_shader

名称字符串

VK_EXT_mesh_shader

扩展类型

设备扩展

注册扩展号

329

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_spirv_1_4

API 交互

  • 与 VK_VERSION_1_2 交互

  • 与 VK_EXT_device_generated_commands 交互

  • 与 VK_KHR_draw_indirect_count 交互

  • 与 VK_KHR_fragment_shading_rate 交互

  • 与 VK_NV_device_generated_commands 交互

  • 与 VkPhysicalDeviceMeshShaderFeaturesEXT::primitiveFragmentShadingRateMeshShader 交互

SPIR-V 依赖项
联系方式
扩展提案

VK_EXT_mesh_shader

其他扩展元数据

上次修改日期

2022-01-20

交互和外部依赖
贡献者

  • Christoph Kubisch, NVIDIA

  • Pat Brown, NVIDIA

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

  • Piers Daniell, NVIDIA

  • Pierre Boudier, NVIDIA

  • Patrick Mours，NVIDIA

  • David Zhao Akeley，NVIDIA

  • Kedarnath Thangudu，NVIDIA

  • Timur Kristóf，Valve

  • Hans-Kristian Arntzen, Valve

  • Philip Rebohle, Valve

  • Mike Blumenkrantz, Valve

  • Slawomir Grajewski, Intel

  • Michal Pietrasiuk，Intel

  • Mariusz Merecki，Intel

  • Tom Olson, ARM

  • Jan-Harald Fredriksen, ARM

  • Sandeep Kakarlapudi，ARM

  • Ruihao Zhang，QUALCOMM

  • Ricardo Garcia，Igalia，S.L.

  • Tobias Hector, AMD

  • Stu Smith, AMD

描述

此扩展提供了一种新机制，允许应用程序通过可编程网格着色生成几何图元集合。 它是现有可编程图元着色管线的替代方案，该管线依赖于通过固定函数汇编程序以及固定函数顶点提取来生成输入图元。

此扩展还在 Vulkan 中增加了对以下 SPIR-V 扩展的支持

新命令

如果支持 VK_KHR_draw_indirect_count 或 Vulkan 版本 1.2

新结构

新枚举常量

  • VK_EXT_MESH_SHADER_EXTENSION_NAME

  • VK_EXT_MESH_SHADER_SPEC_VERSION

  • 扩展 VkPipelineStageFlagBits

    • VK_PIPELINE_STAGE_MESH_SHADER_BIT_EXT

    • VK_PIPELINE_STAGE_TASK_SHADER_BIT_EXT

  • 扩展 VkQueryPipelineStatisticFlagBits

    • VK_QUERY_PIPELINE_STATISTIC_MESH_SHADER_INVOCATIONS_BIT_EXT

    • VK_QUERY_PIPELINE_STATISTIC_TASK_SHADER_INVOCATIONS_BIT_EXT

  • 扩展 VkQueryType

    • VK_QUERY_TYPE_MESH_PRIMITIVES_GENERATED_EXT

  • 扩展 VkShaderStageFlagBits

    • VK_SHADER_STAGE_MESH_BIT_EXT

    • VK_SHADER_STAGE_TASK_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_PROPERTIES_EXT

如果支持 VK_EXT_device_generated_commands

如果支持 VK_NV_device_generated_commands

新的或修改的内置变量

  • CullPrimitiveEXT

  • PrimitivePointIndicesEXT

  • PrimitiveLineIndicesEXT

  • PrimitiveTriangleIndicesEXT

  • （修改后的）Position

  • （修改后的）PointSize

  • （修改后的）ClipDistance

  • （修改后的）CullDistance

  • (已修改)PrimitiveId

  • （修改后的）Layer

  • （修改后的）ViewportIndex

  • （修改后的）NumWorkgroups

  • （修改后的）WorkgroupSize

  • （修改后的）WorkgroupId

  • （修改后的）LocalInvocationId

  • （修改后的）GlobalInvocationId

  • （修改后的）LocalInvocationIndex

  • （修改后的）NumSubgroups

  • （修改后的）SubgroupId

  • （修改后的）DrawIndex

  • （修改后的）PrimitiveShadingRateKHR

  • （修改后的）ViewIndex

新的 SPIR-V 能力

版本历史

  • 修订版 1，2022-03-08 (Christoph Kubisch, Daniel Koch, Patrick Mours)

    • 初始修订版

VK_EXT_metal_objects

名称字符串

VK_EXT_metal_objects

扩展类型

设备扩展

注册扩展号

312

修订

2

批准状态

已批准

扩展和版本依赖关系

无

联系方式
扩展提案

VK_EXT_metal_objects

其他扩展元数据

上次修改日期

2024-04-04

IP 状态

没有已知的 IP 声明。

贡献者

  • Bill Hollings, The Brenwill Workshop Ltd.

  • Dzmitry Malyshau, Mozilla Corp.

描述

在 Apple 设备平台上基于 Metal 构建的 Vulkan 实现中，此扩展提供了导入和导出与特定 Vulkan 对象关联的底层 Metal 对象的能力。

如扩展提案文档中所述，此扩展添加了一个新的 Vulkan 命令 vkExportMetalObjectsEXT，用于从 Vulkan 对象导出底层 Metal 对象，并支持在创建 VkDeviceMemory、VkImage、VkSemaphore 和 VkEvent 类型的 Vulkan 对象时导入相应的现有 Metal 对象。

此扩展的目的在于，它仅在基于 Apple 设备平台上 Metal 构建的实现中被声明和支持。

新的基本类型

  • IOSurfaceRef

  • MTLBuffer_id

  • MTLCommandQueue_id

  • MTLDevice_id

  • MTLSharedEvent_id

  • MTLTexture_id

新命令

新结构体

新枚举

新的位掩码

新的枚举常量

  • VK_EXT_METAL_OBJECTS_EXTENSION_NAME

  • VK_EXT_METAL_OBJECTS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXPORT_METAL_BUFFER_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_COMMAND_QUEUE_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_DEVICE_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_IO_SURFACE_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_OBJECTS_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_OBJECT_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_SHARED_EVENT_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_TEXTURE_INFO_EXT

    • VK_STRUCTURE_TYPE_IMPORT_METAL_BUFFER_INFO_EXT

    • VK_STRUCTURE_TYPE_IMPORT_METAL_IO_SURFACE_INFO_EXT

    • VK_STRUCTURE_TYPE_IMPORT_METAL_SHARED_EVENT_INFO_EXT

    • VK_STRUCTURE_TYPE_IMPORT_METAL_TEXTURE_INFO_EXT

问题

无。

版本历史

  • 修订版 1，2022-05-28（Bill Hollings）

    • 初始草案。

    • 合并了 Vulkan 工作组的评审反馈。重命名了许多结构体，将 MTLBuffer 的导入/导出移至 VkDeviceMemory，添加了 MTLSharedEvent 的导出，为 VkSemaphore 和 VkEvent 添加了 MTLSharedEvent 的导入，并将使用的位掩码字段更改为单个位字段，以简化有效使用规则。

  • 修订版 2，2024-04-04 (Bill Hollings)

    • 向所有 Metal 对象声明添加一个 __unsafe_unretained 所有权限定符，以支持 Apple 设备上的自动引用计数（ARC）。

VK_EXT_metal_surface

名称字符串

VK_EXT_metal_surface

扩展类型

实例扩展

注册扩展号

218

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

其他扩展元数据

上次修改日期

2018-10-01

IP 状态

没有已知的 IP 声明。

贡献者

  • Dzmitry Malyshau, Mozilla Corp.

描述

VK_EXT_metal_surface 扩展是一个实例扩展。它提供了一种机制，可以从 CAMetalLayer 创建一个 VkSurfaceKHR 对象（由 VK_KHR_surface 扩展定义），CAMetalLayer 是 Apple Metal 框架的原生渲染表面。

新的基本类型

  • CAMetalLayer

新命令

新结构体

新的位掩码

新的枚举常量

  • VK_EXT_METAL_SURFACE_EXTENSION_NAME

  • VK_EXT_METAL_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_METAL_SURFACE_CREATE_INFO_EXT

版本历史

  • 修订版 1，2018-10-01（Dzmitry Malyshau）

    • 初始版本

VK_EXT_multi_draw

名称字符串

VK_EXT_multi_draw

扩展类型

设备扩展

注册扩展号

393

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

  • Mike Blumenkrantz zmike

其他扩展元数据

上次修改日期

2021-05-19

交互和外部依赖
IP 状态

没有已知的 IP 声明。

贡献者

  • Mike Blumenkrantz, VALVE

  • Piers Daniell, NVIDIA

  • Faith Ekstrand，INTEL

  • Spencer Fricke，SAMSUNG

  • Ricardo Garcia, IGALIA

  • Jon Leech，KHRONOS

  • Stu Smith, AMD

描述

顺序处理多个绘制命令会导致驱动程序内部在调度期间重复进行状态检查和更新，从而产生可衡量的开销。此扩展允许直接将整个绘制序列传递给驱动程序，以避免任何此类开销，方法是使用带有 vkCmdDrawMultiEXT 或 vkCmdDrawMultiIndexedEXT 的 VkMultiDrawInfoEXT 或 VkMultiDrawIndexedInfoEXT 结构体数组。只要在记录多个绘制命令时它们之间没有任何状态更改，就可以使用这些函数来最大化性能。

新命令

新结构体

新的枚举常量

  • VK_EXT_MULTI_DRAW_EXTENSION_NAME

  • VK_EXT_MULTI_DRAW_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTI_DRAW_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTI_DRAW_PROPERTIES_EXT

新的或修改的内置变量

  • （修改后的）DrawIndex

版本历史

  • 修订版 1，2021-01-20（Mike Blumenkrantz）

    • 初始版本

VK_EXT_multisampled_render_to_single_sampled

名称字符串

VK_EXT_multisampled_render_to_single_sampled

扩展类型

设备扩展

注册扩展号

377

修订

1

批准状态

已批准

扩展和版本依赖关系

     VK_KHR_create_renderpass2
     和
     VK_KHR_depth_stencil_resolve
或
Vulkan 版本 1.2

联系方式
扩展提案

VK_EXT_multisampled_render_to_single_sampled

其他扩展元数据

上次修改日期

2021-04-16

IP 状态

没有已知的 IP 声明。

贡献者

  • Shahbaz Youssefi, Google

  • Jan-Harald Fredriksen, Arm

  • Jörg Wagner，Arm

  • Matthew Netsch，高通技术公司

  • Jarred Davies，Imagination Technologies

描述

通过谨慎使用解析附件，使用 VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT 分配的多采样图像内存，loadOp 不等于 VK_ATTACHMENT_LOAD_OP_LOAD 且 storeOp 不等于 VK_ATTACHMENT_STORE_OP_STORE，Vulkan 应用程序能够有效地执行多采样渲染，而不会在某些实现上产生任何额外的内存开销。

然而，在某些情况下，应用程序可能无法在单个渲染通道中完成其多重采样渲染；例如，如果它逐帧进行部分光栅化、在上一帧的图像上进行混合，或者在模拟 GL_EXT_multisampled_render_to_texture 时。在这种情况下，应用程序可以使用初始子通道来有效地从下一个子通道的解析附件加载单采样数据，并填充多重采样附件，否则该附件将使用 loadOp 等于 VK_ATTACHMENT_LOAD_OP_DONT_CARE。然而，这并非总是可行（例如，在没有 VK_EXT_shader_stencil_export 的情况下处理模板），并且存在多个缺点。

一些实现能够在硬件中高效地执行上述操作，有效地从单采样附件的内容加载多重采样附件。结合在子通道结束时执行解析操作的能力，这些实现能够在单采样附件上执行多重采样渲染，而无需额外的内存或带宽开销。此扩展通过允许帧缓冲和渲染通道包含单采样附件，同时使用指定数量的采样进行渲染来公开此功能。

新结构

新枚举常量

  • VK_EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_EXTENSION_NAME

  • VK_EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_SPEC_VERSION

  • 扩展 VkImageCreateFlagBits

    • VK_IMAGE_CREATE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_FEATURES_EXT

    • VK_STRUCTURE_TYPE_SUBPASS_RESOLVE_PERFORMANCE_QUERY_EXT

问题

1) 多重采样附件是否可以通过某种形式的复制进行初始化？

已解决：否。一些实现通常不支持在附件之间进行复制，并且发现通过复制来表达此操作是不自然的。

2) 实现此目的的另一种方法是引入新的 loadOp 从单采样图像加载多重采样图像的内容。为什么首选此扩展？

已解决：使用此扩展简化了应用程序，因为它不需要管理辅助延迟分配的图像。此外，使用此扩展减少了出错的可能性；例如，在 loadOp 或 storeOp 中的一个错误会导致延迟分配的图像实际占用内存，并保持占用状态直到销毁。

3) 不能保证在具有相同采样数量的两个子通道之间的多重采样数据会被保留，因为实现可能由于各种原因而被强制隐式地拆分渲染通道。此扩展是否应该要求每个使用多重采样渲染到单采样的子通道都以隐式渲染通道拆分（这会导致解析操作）结束？

已解决：否。不要求这样做允许具有多个多重采样渲染到单采样的子通道的渲染通道可能更有效地执行（尽管不能保证）。

版本历史

  • 修订版 1，2021-04-12 (Shahbaz Youssefi)

VK_EXT_mutable_descriptor_type

名称字符串

VK_EXT_mutable_descriptor_type

扩展类型

设备扩展

注册扩展号

495

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_maintenance3

特殊用途
联系方式
扩展提案

VK_EXT_mutable_descriptor_type

其他扩展元数据

上次修改日期

2022-08-22

IP 状态

没有已知的 IP 声明。

贡献者

  • Joshua Ashton, Valve

  • Hans-Kristian Arntzen, Valve

描述

此扩展允许应用程序通过允许描述符根据写入或复制到描述符集中的描述符类型，变更为给定的描述符类型列表，从而减少描述符内存占用。

此扩展旨在解决的主要用例是使用 VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT 的描述符索引，其中描述符类型是完全通用的，因为这意味着应用程序可以分配一个大型描述符集，而不是每个描述符类型都拥有一个大型描述符集，这会显著膨胀描述符内存使用量并导致性能问题。

此扩展还添加了一种机制，用于声明描述符池，以及由此分配的描述符集，仅驻留在主机内存中；因此，这些描述符只能更新/复制，但不能绑定。

这些功能共同允许更有效地模拟原始 D3D12 绑定模型。此扩展主要用于 API 分层工作。

新结构

新枚举常量

版本历史

VK_EXT_nested_command_buffer

名称字符串

VK_EXT_nested_command_buffer

扩展类型

设备扩展

注册扩展号

452

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2023-09-18

贡献者

  • Daniel Story, Nintendo

  • Peter Kohaut, NVIDIA

  • Shahbaz Youssefi, Google

  • Slawomir Grajewski, Intel

  • Stu Smith, AMD

描述

使用核心 Vulkan 时，在记录辅助命令缓冲区时调用 vkCmdExecuteCommands 是不合法的。此扩展放宽了该限制，允许辅助命令缓冲区执行其他辅助命令缓冲区。

新结构

新枚举常量

  • VK_EXT_NESTED_COMMAND_BUFFER_EXTENSION_NAME

  • VK_EXT_NESTED_COMMAND_BUFFER_SPEC_VERSION

  • 扩展 VkRenderingFlagBits

    • VK_RENDERING_CONTENTS_INLINE_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_NESTED_COMMAND_BUFFER_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_NESTED_COMMAND_BUFFER_PROPERTIES_EXT

  • 扩展 VkSubpassContents

    • VK_SUBPASS_CONTENTS_INLINE_AND_SECONDARY_COMMAND_BUFFERS_EXT

问题

1) Vulkan 命令的命令缓冲区级别属性来自命令的 vk.xml 中的 cmdbufferlevel 属性，并且当前无法根据是否启用扩展来修改此属性。对于此扩展，我们希望当启用此扩展时，vkCmdExecuteCommands 的 cmdbufferlevel 属性为 primary,secondary，否则为 primary。

已解决：vkCmdExecuteCommands 的 cmdbufferlevel 属性已更改为 primary,secondary，并添加了一个新的 VUID，以禁止在未启用此扩展的情况下在辅助命令缓冲区中记录此命令。

版本历史

  • 修订版 1，2023-09-18 (Piers Daniell)

    • 内部修订

VK_EXT_non_seamless_cube_map

名称字符串

VK_EXT_non_seamless_cube_map

扩展类型

设备扩展

注册扩展号

423

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式
扩展提案

VK_EXT_non_seamless_cube_map

其他扩展元数据

上次修改日期

2021-09-04

IP 状态

没有已知的 IP 声明。

贡献者

  • Georg Lehmann

描述

此扩展提供在每个采样器级别禁用立方体贴图边缘处理的功能，使其与其它图形 API 的行为相匹配。

此扩展对于为那些 API 构建转换层或移植依赖于此立方体贴图行为的应用程序可能很有用。

新结构

新枚举常量

  • VK_EXT_NON_SEAMLESS_CUBE_MAP_EXTENSION_NAME

  • VK_EXT_NON_SEAMLESS_CUBE_MAP_SPEC_VERSION

  • 扩展 VkSamplerCreateFlagBits

    • VK_SAMPLER_CREATE_NON_SEAMLESS_CUBE_MAP_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_NON_SEAMLESS_CUBE_MAP_FEATURES_EXT

版本历史

  • 版本 1, 2021-09-04 (Georg Lehmann)

    • 第一个版本

VK_EXT_opacity_micromap

名称字符串

VK_EXT_opacity_micromap

扩展类型

设备扩展

注册扩展号

397

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_acceleration_structure
和
     VK_KHR_synchronization2
    或
     Vulkan 版本 1.3

SPIR-V 依赖项
联系方式
扩展提案

VK_EXT_opacity_micromap

其它扩展元数据

上次修改日期

2022-08-24

交互和外部依赖
贡献者

  • Christoph Kubisch, NVIDIA

  • Eric Werness, NVIDIA

  • Josh Barczak, Intel

  • Stu Smith, AMD

描述

在为光线追踪场景添加透明度时，应用程序可以选择进一步细分几何体，或者使用任意命中着色器来允许光线穿过几何体的特定部分。这些选项的缺点是，要么显著增加内存消耗，要么在遍历过程中添加运行时开销来运行着色器代码。

此扩展增加了在构建加速结构时向几何体添加不透明度微型贴图的能力。不透明度微型贴图紧凑地编码了不透明度信息，实现可以使用该信息将三角形的某些部分标记为不透明或透明。该格式对外部可见，允许应用程序提前将其内部几何体和表面表示压缩为压缩格式。压缩格式将每个三角形细分为一组子三角形，每个子三角形可以分配两个或四个不透明度值。这些不透明度值可以控制击中该子三角形的光线是被视为不透明命中、完全未命中还是可能的命中，具体取决于光线不透明度微型贴图中所述的控件。

此扩展提供

新对象类型

新命令

新结构

新枚举

新位掩码

新枚举常量

  • VK_EXT_OPACITY_MICROMAP_EXTENSION_NAME

  • VK_EXT_OPACITY_MICROMAP_SPEC_VERSION

  • 扩展 VkAccessFlagBits2

    • VK_ACCESS_2_MICROMAP_READ_BIT_EXT

    • VK_ACCESS_2_MICROMAP_WRITE_BIT_EXT

  • 扩展 VkBufferUsageFlagBits

    • VK_BUFFER_USAGE_MICROMAP_BUILD_INPUT_READ_ONLY_BIT_EXT

    • VK_BUFFER_USAGE_MICROMAP_STORAGE_BIT_EXT

  • 扩展 VkBuildAccelerationStructureFlagBitsKHR

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DISABLE_OPACITY_MICROMAPS_EXT

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_OPACITY_MICROMAP_DATA_UPDATE_EXT

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_OPACITY_MICROMAP_UPDATE_EXT

  • 扩展 VkGeometryInstanceFlagBitsKHR

    • VK_GEOMETRY_INSTANCE_DISABLE_OPACITY_MICROMAPS_EXT

    • VK_GEOMETRY_INSTANCE_FORCE_OPACITY_MICROMAP_2_STATE_EXT

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_MICROMAP_EXT

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_RAY_TRACING_OPACITY_MICROMAP_BIT_EXT

  • 扩展 VkPipelineStageFlagBits2

    • VK_PIPELINE_STAGE_2_MICROMAP_BUILD_BIT_EXT

  • 扩展 VkQueryType

    • VK_QUERY_TYPE_MICROMAP_COMPACTED_SIZE_EXT

    • VK_QUERY_TYPE_MICROMAP_SERIALIZATION_SIZE_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_TRIANGLES_OPACITY_MICROMAP_EXT

    • VK_STRUCTURE_TYPE_COPY_MEMORY_TO_MICROMAP_INFO_EXT

    • VK_STRUCTURE_TYPE_COPY_MICROMAP_INFO_EXT

    • VK_STRUCTURE_TYPE_COPY_MICROMAP_TO_MEMORY_INFO_EXT

    • VK_STRUCTURE_TYPE_MICROMAP_BUILD_INFO_EXT

    • VK_STRUCTURE_TYPE_MICROMAP_BUILD_SIZES_INFO_EXT

    • VK_STRUCTURE_TYPE_MICROMAP_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_MICROMAP_VERSION_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPACITY_MICROMAP_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPACITY_MICROMAP_PROPERTIES_EXT

参考代码

uint32_t BarycentricsToSpaceFillingCurveIndex(float u, float v, uint32_t level)
{
    u = clamp(u, 0.0f, 1.0f);
    v = clamp(v, 0.0f, 1.0f);

    uint32_t iu, iv, iw;

    // Quantize barycentric coordinates
    float fu = u * (1u << level);
    float fv = v * (1u << level);

    iu = (uint32_t)fu;
    iv = (uint32_t)fv;

    float uf = fu - float(iu);
    float vf = fv - float(iv);

    if (iu >= (1u << level)) iu = (1u << level) - 1u;
    if (iv >= (1u << level)) iv = (1u << level) - 1u;

    uint32_t iuv = iu + iv;

    if (iuv >= (1u << level))
        iu -= iuv - (1u << level) + 1u;

    iw = ~(iu + iv);

    if (uf + vf >= 1.0f && iuv < (1u << level) - 1u) --iw;

    uint32_t b0 = ~(iu ^ iw);
    b0 &= ((1u << level) - 1u);
    uint32_t t = (iu ^ iv) & b0;

    uint32_t f = t;
    f ^= f >> 1u;
    f ^= f >> 2u;
    f ^= f >> 4u;
    f ^= f >> 8u;
    uint32_t b1 = ((f ^ iu) & ~b0) | t;

    // Interleave bits
    b0 = (b0 | (b0 << 8u)) & 0x00ff00ffu;
    b0 = (b0 | (b0 << 4u)) & 0x0f0f0f0fu;
    b0 = (b0 | (b0 << 2u)) & 0x33333333u;
    b0 = (b0 | (b0 << 1u)) & 0x55555555u;
    b1 = (b1 | (b1 << 8u)) & 0x00ff00ffu;
    b1 = (b1 | (b1 << 4u)) & 0x0f0f0f0fu;
    b1 = (b1 | (b1 << 2u)) & 0x33333333u;
    b1 = (b1 | (b1 << 1u)) & 0x55555555u;

    return b0 | (b1 << 1u);
}

问题

(1) 构建是否真的类似于加速结构构建？

  • 已解决：构建应该比加速结构构建轻量得多，但其基础结构足够相似，因此保持概念兼容是有意义的。

(2) 为什么 VkMicromapUsageEXT 没有 type/pNext？

  • 已解决：可能存在大量此类结构，因此将这些结构的大小加倍可能会显著增加内存消耗。此外，应用程序可能会直接从文件中加载这些结构，这与它是平面结构更兼容。包含结构是可扩展的，可能更适合添加可扩展性。

(3) 为什么有 SPIR-V 扩展？

  • 已解决：有一个光线标志。为了与现有光线追踪扩展的工作方式保持一致，该光线标志需要自己的扩展。

(4) 是否应该有间接微型贴图构建？

  • 已解决：目前不应该。需要更深入的用法元数据，并且诸如 GPU 剔除系统之类的事物似乎不太可能需要更改微型贴图的计数。

(5) 微型贴图是否应该具有微型贴图设备地址？

  • 已解决：目前没有必要（可以使用句柄），但这与加速结构略有不同，尽管两者在使用上并非完全平行。

(6) 为什么对齐要求定义为硬编码值和上限的混合？

版本历史

  • 版本 2, 2022-06-22 (Eric Werness)

    • EXTify 并清理以供讨论

  • 版本 1, 2022-01-01 (Eric Werness)

    • 初始修订版

VK_EXT_pageable_device_local_memory

名称字符串

VK_EXT_pageable_device_local_memory

扩展类型

设备扩展

注册扩展号

413

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_EXT_memory_priority

联系方式

其他扩展元数据

上次修改日期

2021-08-24

贡献者

  • Hans-Kristian Arntzen, Valve

  • Axel Gneiting, id Software

  • Billy Khan, id Software

  • Daniel Koch, NVIDIA

  • Chris Lentini, NVIDIA

  • Joshua Schnarr，NVIDIA

  • Stu Smith, AMD

描述

Vulkan 经常在多用户和多进程操作系统上实现，其中设备本地内存可以被多个进程共享。在这样的系统中，应用程序可用的设备本地内存大小可能并非始终是内存堆的完整大小。为了使这些操作系统支持多个应用程序，设备本地内存被虚拟化，并且使用分页在设备本地内存和主机本地内存堆之间移动内存，这对应用程序是透明的。

当前的 Vulkan 规范没有很好地暴露这种行为，并可能导致应用程序在分配内存时做出次优的内存选择。例如，在运行多个应用程序的系统中，应用程序可能认为设备本地内存已满，并恢复为从主机本地内存进行对性能敏感的分配。实际上，内存堆可能并没有满，只是在查询内存消耗时看起来是满的，而设备本地分配本可以成功。一个设计良好的实现可分页设备本地内存的操作系统会尝试将前台应用程序的所有内存分配分页到设备本地内存中，并在不需要时为其他应用程序分页出去。

当 Vulkan 实现暴露此扩展时，它向应用程序表明操作系统实现了可分页的设备本地内存，并且应用程序应相应地调整其内存分配策略。该扩展还公开了一个新的 vkSetDeviceMemoryPriorityEXT 函数，允许应用程序根据其当前需求动态调整现有内存分配的优先级。这将有助于操作系统在需要时先分页出优先级较低的内存分配，然后再分页出优先级较高的分配。它还将帮助操作系统决定首先将哪些内存分配分页回设备本地内存。

为了充分利用可分页的设备本地内存，应用程序必须使用启用了 VkPhysicalDevicePageableDeviceLocalMemoryFeaturesEXT::pageableDeviceLocalMemory 功能来创建 Vulkan 设备。启用后，Vulkan 实现将允许操作系统将设备本地内存分配分页进出，并且即使设备本地内存看起来已满，也可能不会返回 VK_ERROR_OUT_OF_DEVICE_MEMORY，而是会分页此分配或其他分配来腾出空间。Vulkan 实现还将确保主机本地内存分配永远不会被操作系统提升到设备本地内存，或者消耗设备本地内存。

新命令

新结构

新枚举常量

  • VK_EXT_PAGEABLE_DEVICE_LOCAL_MEMORY_EXTENSION_NAME

  • VK_EXT_PAGEABLE_DEVICE_LOCAL_MEMORY_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PAGEABLE_DEVICE_LOCAL_MEMORY_FEATURES_EXT

版本历史

  • 修订版 1，2021-08-24 (Piers Daniell)

    • 初始修订版

VK_EXT_pci_bus_info

名称字符串

VK_EXT_pci_bus_info

扩展类型

设备扩展

注册扩展号

213

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2018-12-10

IP 状态

没有已知的 IP 声明。

贡献者

  • Matthaeus G. Chajdas, AMD

  • Daniel Rakos, AMD

描述

此扩展添加了一个新的查询，用于获取有关物理设备的 PCI 总线信息。

并非所有物理设备都具有 PCI 总线信息，这可能是由于设备未通过 PCI 接口连接到系统，或者由于平台特定的限制和策略。因此，此扩展仅应由可以提供信息的物理设备支持。

因此，应用程序应始终检查每个要为其发出新查询的物理设备是否存在扩展字符串，并且不应对任何给定平台上扩展的可用性进行任何假设。

新结构

新枚举常量

  • VK_EXT_PCI_BUS_INFO_EXTENSION_NAME

  • VK_EXT_PCI_BUS_INFO_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PCI_BUS_INFO_PROPERTIES_EXT

版本历史

  • 修订版 2，2018-12-10 (Daniel Rakos)

    • 将新结构的所有成员更改为 uint32_t 类型

  • 修订版 1，2018-10-11 (Daniel Rakos)

    • 初始修订版

VK_EXT_physical_device_drm

名称字符串

VK_EXT_physical_device_drm

扩展类型

设备扩展

注册扩展号

354

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2021-06-09

IP 状态

没有已知的 IP 声明。

贡献者

  • Simon Ser

描述

此扩展提供了新的工具来查询物理设备的 DRM 属性，使用户能够在 Linux 上将 Vulkan 物理设备与 DRM 节点匹配。

其功能与 EGL_EXT_device_drm1 紧密重叠。与 EGL 扩展不同，此扩展不公开包含设备文件名称的字符串，而是公开设备次要编号。

DRM 定义了多种设备节点类型。每个物理设备可能关联一个主节点和一个渲染节点。物理设备可能没有主节点（例如，如果该设备没有显示子系统），可能没有渲染节点（例如，如果它是软件渲染引擎），或者两者都没有（例如，如果它是没有显示子系统的软件渲染引擎）。

要查询物理设备的 DRM 属性，请将 VkPhysicalDeviceDrmPropertiesEXT 链接到 VkPhysicalDeviceProperties2。

新结构

新枚举常量

  • VK_EXT_PHYSICAL_DEVICE_DRM_EXTENSION_NAME

  • VK_EXT_PHYSICAL_DEVICE_DRM_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRM_PROPERTIES_EXT

参考

  1. EGL_EXT_device_drm

版本历史

  • 修订版 1，2021-06-09

    • 第一个稳定版本

VK_EXT_pipeline_library_group_handles

名称字符串

VK_EXT_pipeline_library_group_handles

扩展类型

设备扩展

注册扩展号

499

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_ray_tracing_pipeline
和
VK_KHR_pipeline_library

联系方式
扩展提案

VK_EXT_pipeline_library_group_handles

其他扩展元数据

上次修改日期

2023-01-25

IP 状态

没有已知的 IP 声明。

贡献者

  • Hans-Kristian Arntzen, Valve

  • Stuart Smith, AMD

  • Ricardo Garcia, Igalia

  • Lionel Landwerlin, Intel

  • Eric Werness, NVIDIA

  • Daniel Koch, NVIDIA

描述

当在光线追踪管道中使用管道库时，一个库可能会以增量方式链接到不同的管道中。应用程序可以使用一种策略，其中光线追踪管道由 N 个管道库组成，然后通过创建具有 N + 1 个库的新管道来增强。如果没有此扩展，所有组句柄都必须重新查询，因为组句柄与管道绑定，而不是与库绑定。这对于旨在分离记录缓冲区构造和光线追踪管道链接的应用程序来说是有问题的。

为了帮助解决这个问题，此扩展支持直接从管道库查询组句柄。从库获取的组句柄在任何链接到该库的 VkPipeline 中必须保持按位相同。

有了此特性，扩展程序还提高了与 DXR 1.1 AddToStateObject() 的兼容性，后者保证了父管道和子管道之间返回的组句柄保持按位相同。此外，该 API 还支持从 COLLECTION 对象查询组句柄。

新结构

新枚举常量

  • VK_EXT_PIPELINE_LIBRARY_GROUP_HANDLES_EXTENSION_NAME

  • VK_EXT_PIPELINE_LIBRARY_GROUP_HANDLES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_LIBRARY_GROUP_HANDLES_FEATURES_EXT

版本历史

  • 修订版 1，2023-01-25（Hans-Kristian Arntzen）

    • 初始草案

VK_EXT_pipeline_properties

名称字符串

VK_EXT_pipeline_properties

扩展类型

设备扩展

注册扩展号

373

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2022-04-19

IP 状态

没有已知的 IP 声明。

贡献者

  • Mukund Keshava, NVIDIA

  • Daniel Koch, NVIDIA

  • Mark Bellamy, Arm

描述

Vulkan SC 需要离线编译管道。为了支持这一点，管道状态表示在 JSON 模式中，该模式由离线工具读取以进行编译。

开发 Vulkan SC 应用程序的一种方法是编写 Vulkan 应用程序，并使用图层记录和序列化管道状态和着色器以进行离线编译。每个管道由单独的 JSON 文件表示，并且可以使用 pipelineIdentifier 进行标识。

一旦管道被离线管道缓存编译器编译，Vulkan SC 应用程序就可以使用此 pipelineIdentifier 通过 Vulkan SC 的 VkPipelineIdentifierInfo 结构来识别管道。

此扩展允许 Vulkan 应用程序查询与每个管道关联的 pipelineIdentifier，以便应用程序可以将其与管道元数据一起存储，并且 Vulkan SC 应用程序随后将使用它将相同的状态映射到 Vulkan SC 管道缓存中的条目。

预计此扩展将最初在 json 生成层中实现，尽管我们可以设想它在原生 Vulkan 驱动程序中也可能存在未来的用途。

新命令

新结构

新枚举常量

  • VK_EXT_PIPELINE_PROPERTIES_EXTENSION_NAME

  • VK_EXT_PIPELINE_PROPERTIES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_PROPERTIES_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_INFO_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_PROPERTIES_IDENTIFIER_EXT

问题

（1）此扩展在严格的 Vulkan SC 实现上没有意义。但是，在非严格的 Vulkan SC 实现中，它可能具有潜在的用途。此扩展是否也应作为 Vulkan SC 的一部分启用？

已解决：否。此扩展不会为 Vulkan SC 启用。

（2）这旨在成为一个通用的管道属性查询，但目前仅检索管道标识符。管道标识符查询对于此扩展以及所有使用此命令的查询是否应为强制性？

已解决：使用 VkBaseOutStructure 作为返回参数。目前，这实际上必须是一个 VkPipelinePropertiesIdentifierEXT 结构，但将来可以放宽此要求，以允许其他结构类型或允许将其他结构与此结构链接在一起。

（3）应该有特征结构吗？它应该被要求吗？

已解决：添加一个特征结构和一个用于查询管道标识符的特征，但允许它是可选的，以便此扩展可以用作其他管道属性查询的基础，而无需支持管道标识符。

版本历史

  • 修订版 1，2022-04-19（Mukund Keshava，Daniel Koch）

    • 初始草案

VK_EXT_post_depth_coverage

名称字符串

VK_EXT_post_depth_coverage

扩展类型

设备扩展

注册扩展号

156

修订

1

批准状态

已批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2017-07-17

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

  • SPV_KHR_post_depth_coverage

它允许片段着色器控制 SampleMask 内置输入变量中的值是否反映应用早期深度和模板测试后的覆盖率。

此扩展在 SampleMaskPostDepthCoverage 功能下添加了一个新的 PostDepthCoverage 执行模式。当指定此模式以及 EarlyFragmentTests 时，使用 SampleMask 内置修饰的输入变量的值反映了应用早期片段测试后的覆盖率。否则，它反映深度和模板测试之前的覆盖率。

当使用基于 GLSL 源的着色语言时，来自 GL_ARB_post_depth_coverage 或 GL_EXT_post_depth_coverage 的 post_depth_coverage 布局限定符映射到 PostDepthCoverage 执行模式。

新枚举常量

  • VK_EXT_POST_DEPTH_COVERAGE_EXTENSION_NAME

  • VK_EXT_POST_DEPTH_COVERAGE_SPEC_VERSION

新的 SPIR-V 功能

版本历史

  • 修订版 1，2017-07-17（Daniel Koch）

    • 内部修订

VK_EXT_present_mode_fifo_latest_ready

名称字符串

VK_EXT_present_mode_fifo_latest_ready

扩展类型

设备扩展

注册扩展号

362

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_swapchain

联系方式
扩展提案

VK_EXT_present_mode_fifo_latest_ready

其他扩展元数据

上次修改日期

2024-05-28

IP 状态

没有已知的 IP 声明。

贡献者

  • James Jones, NVIDIA

  • Lionel Duc, NVIDIA

描述

此设备扩展添加了一种新的呈现模式 VK_PRESENT_MODE_FIFO_LATEST_READY_EXT。

这种无撕裂呈现模式的行为与 VK_PRESENT_MODE_FIFO_KHR 非常相似，只是每个垂直消隐期都会使连续的呈现请求出列，直到找到最新的就绪状态以更新当前图像。

虽然这在概念上与 VK_PRESENT_MODE_MAILBOX_KHR 类似，但根本区别在于 present 请求的处理是在垂直同步期间完成的。从应用程序的角度来看，这意味着例如，在基于翻转的模型中，单个垂直同步可能会导致多个交换链图像一次性释放，而 VK_PRESENT_MODE_MAILBOX_KHR 可能在新的请求准备就绪时持续释放图像。

当使用基于时间的 present API 时，此额外的 present 模式非常有用。

新结构

新枚举常量

  • VK_EXT_PRESENT_MODE_FIFO_LATEST_READY_EXTENSION_NAME

  • VK_EXT_PRESENT_MODE_FIFO_LATEST_READY_SPEC_VERSION

  • 扩展 VkPresentModeKHR

    • VK_PRESENT_MODE_FIFO_LATEST_READY_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_MODE_FIFO_LATEST_READY_FEATURES_EXT

版本历史

  • 修订版 1，2024-05-28 (Lionel Duc)

    • 内部修订

VK_EXT_primitive_topology_list_restart

名称字符串

VK_EXT_primitive_topology_list_restart

扩展类型

设备扩展

注册扩展号

357

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

其他扩展元数据

上次修改日期

2021-01-11

IP 状态

没有已知的 IP 声明。

贡献者

  • Courtney Goeltzenleuchter, Google

  • Shahbaz Youssefi, Google

描述

此扩展允许列表图元使用图元重启索引值。通过避免产生数据复制的模拟，这为在 Vulkan 上分层 OpenGL 功能提供了更高效的实现。

新结构

新枚举常量

  • VK_EXT_PRIMITIVE_TOPOLOGY_LIST_RESTART_EXTENSION_NAME

  • VK_EXT_PRIMITIVE_TOPOLOGY_LIST_RESTART_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRIMITIVE_TOPOLOGY_LIST_RESTART_FEATURES_EXT

版本历史

  • 修订版 0，2020-09-14 (Courtney Goeltzenleuchter)

    • 内部修订

  • 修订版 1，2021-01-11 (Shahbaz Youssefi)

    • 添加 primitiveTopologyPatchListRestart 功能

    • 内部修订

VK_EXT_primitives_generated_query

名称字符串

VK_EXT_primitives_generated_query

扩展类型

设备扩展

注册扩展号

383

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_EXT_transform_feedback

特殊用途
联系方式
扩展提案

VK_EXT_primitives_generated_query

其他扩展元数据

上次修改日期

2022-01-24

贡献者

  • Shahbaz Youssefi, Google

  • Piers Daniell, NVIDIA

  • Faith Ekstrand, Collabora

  • Jan-Harald Fredriksen, Arm

描述

此扩展添加了对新查询类型的支持，以匹配 OpenGL 的 GL_PRIMITIVES_GENERATED，从而支持分层。

新结构

新枚举常量

  • VK_EXT_PRIMITIVES_GENERATED_QUERY_EXTENSION_NAME

  • VK_EXT_PRIMITIVES_GENERATED_QUERY_SPEC_VERSION

  • 扩展 VkQueryType

    • VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRIMITIVES_GENERATED_QUERY_FEATURES_EXT

问题

1) 可以使用来自 VK_EXT_transform_feedback 的查询吗？

已解决：否。虽然来自 VK_EXT_transform_feedback 的查询可以产生与此扩展中相同的结果，但它仅在变换反馈处于活动状态时可用。OpenGL 的 GL_PRIMITIVES_GENERATED 查询独立于变换反馈。通过人工变换反馈进行模拟是不必要的低效。

2) 可以使用 VK_QUERY_PIPELINE_STATISTIC_CLIPPING_INVOCATIONS_BIT 吗？

已解决：可以，但我们出于简化的目的更喜欢使用此扩展。Vulkan 要求一次只能激活一个查询。如果需要同时启用 GL_PRIMITIVES_GENERATED 和 GL_CLIPPING_INPUT_PRIMITIVES_ARB 查询，则通过 VK_QUERY_PIPELINE_STATISTIC_CLIPPING_INVOCATIONS_BIT 模拟两者会很不方便。

3) 在某些硬件上，如果启用了 VkPipelineRasterizationStateCreateInfo::rasterizerDiscardEnable，则无法实现此查询。将如何处理？

已解决：此扩展为此公开了一个功能标志。在上述硬件上，GL 实现会禁用光栅化器丢弃，并通过其他方式实现相同的效果。由于缺少状态信息，它将无法在 Vulkan 中执行相同的操作。此扩展公开了一个功能标志，以便 Vulkan 之上的 OpenGL 实现能够实现类似的解决方法。

4) 在某些硬件上，对于非零查询索引，无法实现此查询。将如何处理？

已解决：此扩展为此公开了一个功能标志。如果不存在此功能，则可以使用来自 VK_EXT_transform_feedback 的查询达到相同的效果。

5) 此扩展与 transformFeedbackRasterizationStreamSelect 的交互是如何处理的？

已解决：禁止用于非零流。在 OpenGL 中，光栅化流始终为流零。

版本历史

  • 修订版 1，2021-06-23 (Shahbaz Youssefi)

    • 内部修订

VK_EXT_provoking_vertex

名称字符串

VK_EXT_provoking_vertex

扩展类型

设备扩展

注册扩展号

255

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

其他扩展元数据

上次修改日期

2021-02-22

IP 状态

没有已知的 IP 声明。

贡献者

  • Alexis Hétu, Google

  • Bill Licea-Kane, Qualcomm

  • Daniel Koch, Nvidia

  • Jamie Madill，谷歌

  • Jan-Harald Fredriksen, Arm

  • Faith Ekstrand, Intel

  • Jeff Bolz, Nvidia

  • Jeff Leger, Qualcomm

  • Jesse Hall, Google

  • Jörg Wagner，Arm

  • Matthew Netsch, Qualcomm

  • Mike Blumenkrantz, Valve

  • Piers Daniell, Nvidia

  • Tobias Hector, AMD

描述

此扩展允许在 Vulkan 的默认约定（第一个顶点）和 OpenGL 的约定（最后一个顶点）之间更改触发顶点约定。

此扩展旨在供 API 转换层使用，这些层在 Vulkan 之上实现 OpenGL 等 API，并且需要匹配源 API 的触发顶点约定。直接使用 Vulkan 的应用程序应使用 Vulkan 的默认约定。

新结构

新枚举

新枚举常量

  • VK_EXT_PROVOKING_VERTEX_EXTENSION_NAME

  • VK_EXT_PROVOKING_VERTEX_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROVOKING_VERTEX_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROVOKING_VERTEX_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_PROVOKING_VERTEX_STATE_CREATE_INFO_EXT

问题

1) 此状态应以什么粒度设置？

已解决：在管道绑定时，可以选择每次渲染通道进行限制。

放置此状态的最自然位置是在图形管道对象中。某些实现要求在创建管道时知道它，并且管道状态对于实现 OpenGL 3.2 的 glProvokingVertex 很方便，后者可以在绘制调用之间更改状态。但是，某些实现只能大约以渲染通道的粒度更改它。为了同时容纳两者，触发顶点将成为管道状态，但是实现可以要求在渲染通道实例中仅使用一种模式；在绑定第一个管道时隐式选择渲染通道的模式。

2) 触发顶点模式是否影响将顶点写入变换反馈缓冲区的顺序？

已解决：是的，为了启用 OpenGL 和 D3D 的分层实现。

所有 OpenGL、OpenGL ES 和 Direct3D 11 都要求将顶点写入变换反馈缓冲区，以便在绘制变换反馈缓冲区的内容时，平面着色属性的值与原始绘制时相同（假设在支持多种模式的 API 中，引发顶点模式没有改变）。

版本历史

  • 修订版 1，(1c) 2021-02-22 (Jesse Hall)

    • 添加了 VkPhysicalDeviceProvokingVertexPropertiesEXT::transformFeedbackPreservesTriangleFanProvokingVertex，以适应无法更改三角形扇形变换反馈顶点顺序的实现。

  • 修订版 1，(1b) 2020-06-14 (Jesse Hall)

    • 添加了 VkPhysicalDeviceProvokingVertexFeaturesEXT::transformFeedbackPreservesProvokingVertex，并要求变换反馈写入顶点以保留每个图元的引发顶点。

  • 修订版 1，(1a) 2019-10-23 (Jesse Hall)

    • 初始草案，基于 Alexis Hétu 的提案

VK_EXT_queue_family_foreign

名称字符串

VK_EXT_queue_family_foreign

扩展类型

设备扩展

注册扩展号

127

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_memory
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2017-11-01

IP 状态

没有已知的 IP 声明。

贡献者

  • Lina Versace，谷歌

  • James Jones, NVIDIA

  • Faith Ekstrand, Intel

  • Jesse Hall, Google

  • Daniel Rakos, AMD

  • Ray Smith, ARM

描述

此扩展定义了一个特殊的队列族 VK_QUEUE_FAMILY_FOREIGN_EXT，它可用于将外部内存支持的资源的拥有权转移到外部的外部队列。这类似于 VK_KHR_external_memory 中定义的 VK_QUEUE_FAMILY_EXTERNAL_KHR。两者之间的主要区别在于

  • VK_QUEUE_FAMILY_EXTERNAL_KHR 表示的队列必须与当前的 VkInstance 共享相同的物理设备和相同的驱动程序版本。VK_QUEUE_FAMILY_FOREIGN_EXT 没有此类限制。它可以表示来自其他供应商的设备和驱动程序，甚至可以表示不具备 Vulkan 功能的设备。

  • 所有外部内存支持的资源都支持 VK_QUEUE_FAMILY_EXTERNAL_KHR。对 VK_QUEUE_FAMILY_FOREIGN_EXT 的支持更具限制性。

  • 应用程序应预期与 VK_QUEUE_FAMILY_FOREIGN_EXT 之间的转换比与 VK_QUEUE_FAMILY_EXTERNAL_KHR 之间的转换更昂贵。

新枚举常量

  • VK_EXT_QUEUE_FAMILY_FOREIGN_EXTENSION_NAME

  • VK_EXT_QUEUE_FAMILY_FOREIGN_SPEC_VERSION

  • VK_QUEUE_FAMILY_FOREIGN_EXT

版本历史

  • 修订版 1，2017-11-01 (Lina Versace)

    • 压缩内部修订版

VK_EXT_rasterization_order_attachment_access

名称字符串

VK_EXT_rasterization_order_attachment_access

扩展类型

设备扩展

注册扩展号

464

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式
扩展提案

VK_EXT_rasterization_order_attachment_access

其他扩展元数据

上次修改日期

2022-07-04

IP 状态

没有已知的 IP 声明。

贡献者

  • Tobias Hector, AMD

  • Jan-Harald Fredriksen, Arm

描述

此扩展扩展了输入附件的机制，允许从一个片段到下一个片段以栅格化顺序访问既用作输入又用作颜色或深度/模板附件的帧缓冲区附件，而无需显式同步。

新结构

新枚举

新枚举常量

  • VK_EXT_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_EXTENSION_NAME

  • VK_EXT_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_SPEC_VERSION

  • 扩展 VkPipelineColorBlendStateCreateFlagBits

    • VK_PIPELINE_COLOR_BLEND_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_BIT_EXT

  • 扩展 VkPipelineDepthStencilStateCreateFlagBits

    • VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_EXT

    • VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_FEATURES_EXT

  • 扩展 VkSubpassDescriptionFlagBits

    • VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_COLOR_ACCESS_BIT_EXT

    • VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_EXT

    • VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_EXT

示例

无。

版本历史

  • 修订版 1，2022-07-04 (Jan-Harald Fredriksen)

    • 初始草案

VK_EXT_rgba10x6_formats

名称字符串

VK_EXT_rgba10x6_formats

扩展类型

设备扩展

注册扩展号

345

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_sampler_ycbcr_conversion
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2021-09-29

IP 状态

没有已知的 IP 声明。

贡献者

  • Jan-Harald Fredriksen, Arm

  • Graeme Leese, Broadcom

  • Spencer Fricke, Samsung

描述

此扩展允许在不启用 采样器 Y′CBCR 转换的情况下使用 VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 格式。

新结构

新枚举常量

  • VK_EXT_RGBA10X6_FORMATS_EXTENSION_NAME

  • VK_EXT_RGBA10X6_FORMATS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RGBA10X6_FORMATS_FEATURES_EXT

问题

1) 我们应该重用现有的格式枚举还是引入新的格式枚举？

已解决：我们重用现有的格式枚举 VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16，该枚举以前专门用于 YCbCr，因此具有一组与该使用相关的限制。另一种方法是引入一个新的格式令牌，该令牌与现有令牌的位表示完全相同，但没有限制。

2) 我们应该只引入 VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 还是也引入 1-3 个分量变体？

已解决：仅引入了 4 分量格式，因为 1 分量和 2 分量变体已经不专用于 YCbCr，而 3 分量变体与硬件功能不太匹配。

版本历史

  • 修订版 1，2021-09-29 (Jan-Harald Fredriksen)

    • 初始 EXT 版本

VK_EXT_robustness2

名称字符串

VK_EXT_robustness2

扩展类型

设备扩展

注册扩展号

287

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2020-01-29

IP 状态

没有已知的 IP 声明。

贡献者

  • Liam Middlebrook, NVIDIA

  • Jeff Bolz, NVIDIA

描述

此扩展为越界读取和写入的处理方式增加了更严格的要求。大多数访问必须进行严格的边界检查，越界写入必须被丢弃，越界读取必须返回零。 与允许多个可能的 (0,0,0,x) 向量不同，越界值被视为零，然后根据 转换为 RGBA 和 顶点输入属性提取 中描述的格式插入缺失的组件。

这些额外的要求在某些实现上可能会很昂贵，只有在真正必要时才应启用。

此扩展还增加了对“空描述符”的支持，其中可以使用 VK_NULL_HANDLE 来代替有效的句柄。访问空描述符具有明确定义的行为，并且不依赖于稳健性。

新结构

新枚举常量

  • VK_EXT_ROBUSTNESS_2_EXTENSION_NAME

  • VK_EXT_ROBUSTNESS_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ROBUSTNESS_2_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ROBUSTNESS_2_PROPERTIES_EXT

问题

  1. 为什么存在 VkPhysicalDeviceRobustness2PropertiesEXT::robustUniformBufferAccessSizeAlignment 和 VkPhysicalDeviceRobustness2PropertiesEXT::robustStorageBufferAccessSizeAlignment？

已解决：某些实现不能有效地对所有缓冲区访问进行严格的边界检查。相反，边界范围的大小被填充为某个 2 的幂倍数，统一缓冲区最多为 256 字节，存储缓冲区最多为 4 字节，并对填充后的尺寸进行边界检查。这足以实现类似 D3D 的行为，因为 D3D 只允许绑定整个统一缓冲区或 256 字节的倍数的范围，并且 D3D 原始和结构化缓冲区只支持 32 位访问。

示例

无。

版本历史

  • 修订版 1, 2019-11-01 (Jeff Bolz, Liam Middlebrook)

    • 初始草案

VK_EXT_sample_locations

名称字符串

VK_EXT_sample_locations

扩展类型

设备扩展

注册扩展号

144

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2017-08-02

贡献者

  • Mais Alnasser, AMD

  • Matthaeus G. Chajdas, AMD

  • Maciej Jesionowski, AMD

  • Daniel Rakos, AMD

  • Slawomir Grajewski, Intel

  • Jeff Bolz, NVIDIA

  • Bill Licea-Kane, Qualcomm

描述

此扩展允许应用程序修改在光栅化中使用的像素内采样的位置。此外，它允许应用程序为一组相邻像素中的每个像素指定不同的采样位置，这可以提高抗锯齿质量（特别是如果使用利用这些不同位置的自定义解析着色器）。

通常，实现会通过存储可以用于在每个采样位置重建深度的值来优化深度值的存储，而不是为每个采样存储单独的深度值。例如，单个三角形的深度值可能使用平面方程表示。当需要采样的深度值时，它会在采样位置自动评估。修改采样位置会导致重建不再像最初生成采样时那样评估相同的深度值，因此在使用不同的采样位置渲染到深度/模板附件之前，必须清除其深度方面。

某些实现在执行图像布局转换时可能需要评估深度图像值。为了适应这种情况，可以在每次必须进行显式或自动布局转换的情况下指定 VkSampleLocationsInfoEXT 结构的实例。可以从 VkImageMemoryBarrier 结构链接 VkSampleLocationsInfoEXT，为由 vkCmdWaitEvents 和 vkCmdPipelineBarrier 调用执行的布局转换提供采样位置，并且可以从 VkRenderPassBeginInfo 链接 VkRenderPassSampleLocationsBeginInfoEXT，为渲染过程实例隐式执行的布局转换提供采样位置。

新命令

新结构

新枚举常量

  • VK_EXT_SAMPLE_LOCATIONS_EXTENSION_NAME

  • VK_EXT_SAMPLE_LOCATIONS_SPEC_VERSION

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_EXT

  • 扩展 VkImageCreateFlagBits

    • VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_MULTISAMPLE_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLE_LOCATIONS_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_SAMPLE_LOCATIONS_STATE_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_RENDER_PASS_SAMPLE_LOCATIONS_BEGIN_INFO_EXT

    • VK_STRUCTURE_TYPE_SAMPLE_LOCATIONS_INFO_EXT

版本历史

  • 修订版 1, 2017-08-02 (Daniel Rakos)

    • 内部修订

VK_EXT_shader_atomic_float

名称字符串

VK_EXT_shader_atomic_float

扩展类型

设备扩展

注册扩展号

261

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

API 交互

  • 与 VkPhysicalDeviceShaderAtomicFloatFeaturesEXT::sparseImageFloat32AtomicAdd 交互

  • 与 VkPhysicalDeviceShaderAtomicFloatFeaturesEXT::sparseImageFloat32Atomics 交互

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2020-07-15

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Vikram Kushwaha, NVIDIA

  • Jeff Bolz, NVIDIA

描述

此扩展允许着色器在缓冲区、工作组和图像内存上包含浮点原子操作。它还通告 SPIR-V AtomicFloat32AddEXT 和 AtomicFloat64AddEXT 功能，允许对浮点数进行原子加法。支持的操作包括 OpAtomicFAddEXT、OpAtomicExchange、OpAtomicLoad 和 OpAtomicStore。

新结构

新枚举常量

  • VK_EXT_SHADER_ATOMIC_FLOAT_EXTENSION_NAME

  • VK_EXT_SHADER_ATOMIC_FLOAT_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_FLOAT_FEATURES_EXT

新 SPIR-V 功能

版本历史

  • 修订版 1, 2020-07-15 (Vikram Kushwaha)

    • 内部修订

VK_EXT_shader_atomic_float2

名称字符串

VK_EXT_shader_atomic_float2

扩展类型

设备扩展

注册扩展号

274

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_EXT_shader_atomic_float

API 交互

  • 与 VkPhysicalDeviceShaderAtomicFloat2FeaturesEXT::sparseImageFloat32AtomicMinMax 交互

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2020-08-14

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Faith Ekstrand, Intel

描述

此扩展允许着色器在缓冲区和工作组内存上执行 16 位浮点原子操作，以及在缓冲区、工作组和图像内存上执行浮点原子最小值和最大值操作。它声明了 SPIR-V AtomicFloat16AddEXT 功能，该功能允许对 16 位浮点数执行原子加法操作，以及 SPIR-V AtomicFloat16MinMaxEXT、AtomicFloat32MinMaxEXT 和 AtomicFloat64MinMaxEXT 功能，这些功能允许对浮点数执行原子最小值和最大值操作。支持的操作包括 OpAtomicFAddEXT、OpAtomicFMinEXT 和 OpAtomicFMaxEXT。

新结构

新枚举常量

  • VK_EXT_SHADER_ATOMIC_FLOAT_2_EXTENSION_NAME

  • VK_EXT_SHADER_ATOMIC_FLOAT_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_FLOAT_2_FEATURES_EXT

问题

1) 此扩展是否应添加对 16 位图像原子的支持？

已解决：否。虽然 Vulkan 支持创建具有 VK_FORMAT_R16_SFLOAT 的存储图像并在其上进行加载和存储，但着色器中的数据具有 32 位表示。Vulkan 目前甚至没有在着色器中使用 16 位浮点值读取或写入此类图像的基本机制。在 16 位图像原子变得有意义之前，需要添加此类功能，但这超出了此扩展的范围。

新的 SPIR-V 功能

版本历史

  • 版本 1，2020-08-14 (Faith Ekstrand)

    • 内部修订

VK_EXT_shader_image_atomic_int64

名称字符串

VK_EXT_shader_image_atomic_int64

扩展类型

设备扩展

注册扩展号

235

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2020-07-14

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Matthaeus Chajdas, AMD

  • Graham Wihlidal, Epic Games

  • Tobias Hector, AMD

  • Jeff Bolz, Nvidia

  • Faith Ekstrand, Intel

描述

此扩展扩展了现有的 64 位整数原子支持，使其能够在图像上执行这些操作。

当处理大型 2 维或 3 维数据集（例如，光栅化或屏幕空间效果）时，图像访问通常比等效的缓冲区访问更有效。此扩展允许以这种方式依赖 64 位整数原子的应用程序通过相对较小的代码更改来快速提高性能。

对于具有 VK_FORMAT_R64_UINT 和 VK_FORMAT_R64_SINT 格式的优化平铺图像，保证支持 64 位整数原子。

新结构

新枚举常量

  • VK_EXT_SHADER_IMAGE_ATOMIC_INT64_EXTENSION_NAME

  • VK_EXT_SHADER_IMAGE_ATOMIC_INT64_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_IMAGE_ATOMIC_INT64_FEATURES_EXT

版本历史

  • 版本 1，2020-07-14 (Tobias Hector)

    • 初始草案

VK_EXT_shader_module_identifier

名称字符串

VK_EXT_shader_module_identifier

扩展类型

设备扩展

注册扩展号

463

修订

1

批准状态

已批准

扩展和版本依赖关系

         VK_KHR_get_physical_device_properties2
         或
         Vulkan 版本 1.1
     和
     VK_EXT_pipeline_creation_cache_control
或
Vulkan 版本 1.3

联系方式
扩展提案

VK_EXT_shader_module_identifier

其他扩展元数据

上次修改日期

2022-05-16

IP 状态

没有已知的 IP 声明。

贡献者

  • Hans-Kristian Arntzen, Valve

  • Ricardo Garcia, Igalia

  • Piers Daniell, NVIDIA

  • Jan-Harald Fredriksen, Arm

  • Tom Olson, Arm

  • Faith Ekstrand, Collabora

描述

某些应用程序在运行时生成 SPIR-V 代码。当通过例如 VkPipelineCache 机制显式地或通过驱动程序管理的缓存隐式地预热管线缓存时，必须重新生成 SPIR-V 模块是多余的。SPIR-V 模块可以由应用程序缓存在磁盘上，但在某些用例中，额外的磁盘空间需求可能令人望而却步。

此扩展增加了应用程序查询与 VkShaderModule 关联的小标识符的能力。在应用程序的后续运行中，可以提供相同的标识符来代替 VkShaderModule 对象。如果可以在不调用编译的情况下创建管线，并且实现不需要 SPIR-V 模块中的信息，则具有此类模块的管线创建调用可能会成功。

如果仅提供标识符，则必须使用 VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT，并且此用例旨在像非阻塞、推测性编译一样工作。应用程序可以根据需要回退。

识别模块本身而不是整个管线的主要动机是，当驱动程序更新时，管线标识符会发生变化，但对于任何特定的驱动程序实现，模块标识符预计都是稳定的。这种方法有助于提前预热管线缓存的着色器预编译系统。当磁盘上的管线缓存更新时，相同的着色器标识符可能会导致管线缓存命中。

新命令

新结构

新枚举常量

  • VK_EXT_SHADER_MODULE_IDENTIFIER_EXTENSION_NAME

  • VK_EXT_SHADER_MODULE_IDENTIFIER_SPEC_VERSION

  • VK_MAX_SHADER_MODULE_IDENTIFIER_SIZE_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_MODULE_IDENTIFIER_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_MODULE_IDENTIFIER_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_MODULE_IDENTIFIER_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_SHADER_MODULE_IDENTIFIER_EXT

版本历史

  • 版本 1，2022-03-16 (Hans-Kristian Arntzen)

    • 初始草案

VK_EXT_shader_object

名称字符串

VK_EXT_shader_object

扩展类型

设备扩展

注册扩展号

483

修订

1

批准状态

已批准

扩展和版本依赖关系

         VK_KHR_get_physical_device_properties2
         或
         Vulkan 版本 1.1
     和
     VK_KHR_dynamic_rendering
或
Vulkan 版本 1.3

API 交互

  • 与 VK_VERSION_1_1 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_EXT_blend_operation_advanced 交互

  • 与 VK_EXT_conservative_rasterization 交互

  • 与 VK_EXT_depth_clamp_control 交互

  • 与 VK_EXT_depth_clip_control 交互

  • 与 VK_EXT_depth_clip_enable 交互

  • 与 VK_EXT_fragment_density_map 交互

  • 与 VK_EXT_line_rasterization 交互

  • 与 VK_EXT_mesh_shader 交互

  • 与 VK_EXT_provoking_vertex 交互

  • 与 VK_EXT_sample_locations 交互

  • 与 VK_EXT_subgroup_size_control 交互

  • 与 VK_EXT_transform_feedback 交互

  • 与 VK_KHR_device_group 交互

  • 与 VK_KHR_fragment_shading_rate 交互

  • 与 VK_NV_clip_space_w_scaling 交互

  • 与 VK_NV_coverage_reduction_mode 交互

  • 与 VK_NV_fragment_coverage_to_color 交互

  • 与 VK_NV_framebuffer_mixed_samples 交互

  • 与 VK_NV_mesh_shader 交互

  • 与 VK_NV_representative_fragment_test 交互

  • 与 VK_NV_shading_rate_image 交互

  • 与 VK_NV_viewport_swizzle 交互

联系方式
扩展提案

VK_EXT_shader_object

其他扩展元数据

上次修改日期

2023-03-30

交互和外部依赖
IP 状态

没有已知的 IP 声明。

贡献者

  • Piers Daniell, NVIDIA

  • Sandy Jamieson, Nintendo

  • Žiga Markuš, LunarG

  • Tobias Hector, AMD

  • Alex Walters, Imagination

  • Shahbaz Youssefi, Google

  • Ralph Potter, Samsung

  • Jan-Harald Fredriksen, ARM

  • Connor Abott, Valve

  • Arseny Kapoulkine, Roblox

  • Patrick Doane, Activision

  • Jeff Leger, Qualcomm

  • Stu Smith, AMD

  • Chris Glover, Google

  • Ricardo Garcia, Igalia

  • Faith Ekstrand, Collabora

  • Timur Kristóf，Valve

  • Constantine Shablya, Collabora

  • Daniel Koch, NVIDIA

  • Alyssa Rosenzweig, Collabora

  • Mike Blumenkrantz, Valve

  • Samuel Pitoiset, Valve

  • Qun Lin, AMD

  • Spencer Fricke, LunarG

  • Soroush Faghihi Kashani, Imagination

描述

此扩展引入了一种新的 VkShaderEXT 对象类型，该类型表示单个已编译的着色器阶段。着色器对象为 VkPipeline 对象提供了更灵活的替代方案，这在某些用例中可能很有用。

新对象类型

新命令

如果支持 VK_EXT_blend_operation_advanced

如果支持 VK_EXT_conservative_rasterization

如果支持 VK_EXT_depth_clamp_control

如果支持 VK_EXT_depth_clip_control

如果支持 VK_EXT_depth_clip_enable

如果支持 VK_EXT_line_rasterization

如果支持 VK_EXT_provoking_vertex

如果支持 VK_EXT_sample_locations

如果支持 VK_EXT_transform_feedback

如果支持 VK_NV_clip_space_w_scaling

如果支持 VK_NV_coverage_reduction_mode

如果支持 VK_NV_fragment_coverage_to_color

如果支持 VK_NV_framebuffer_mixed_samples

如果支持 VK_NV_representative_fragment_test

如果支持 VK_NV_shading_rate_image

如果支持 VK_NV_viewport_swizzle

新结构

新枚举

新位掩码

新枚举常量

  • VK_EXT_SHADER_OBJECT_EXTENSION_NAME

  • VK_EXT_SHADER_OBJECT_SPEC_VERSION

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_SHADER_EXT

  • 扩展 VkResult

    • VK_ERROR_INCOMPATIBLE_SHADER_BINARY_EXT

    • VK_INCOMPATIBLE_SHADER_BINARY_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_OBJECT_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_OBJECT_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_SHADER_REQUIRED_SUBGROUP_SIZE_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_VERTEX_INPUT_ATTRIBUTE_DESCRIPTION_2_EXT

    • VK_STRUCTURE_TYPE_VERTEX_INPUT_BINDING_DESCRIPTION_2_EXT

如果支持 VK_EXT_fragment_density_map

如果支持 VK_EXT_mesh_shader 或 VK_NV_mesh_shader

如果支持 VK_EXT_subgroup_size_control 或 Vulkan 1.3 版本

  • 扩展 VkShaderCreateFlagBitsEXT

    • VK_SHADER_CREATE_ALLOW_VARYING_SUBGROUP_SIZE_BIT_EXT

    • VK_SHADER_CREATE_REQUIRE_FULL_SUBGROUPS_BIT_EXT

如果支持 VK_KHR_device_group 或 Vulkan 版本 1.1

如果支持 VK_KHR_fragment_shading_rate

示例

示例 1

创建顶点着色器和片段着色器的链接对。

// Logical device created with the shaderObject feature enabled
VkDevice device;

// SPIR-V shader code for a vertex shader, along with its size in bytes
void* pVertexSpirv;
size_t vertexSpirvSize;

// SPIR-V shader code for a fragment shader, along with its size in bytes
void* pFragmentSpirv;
size_t fragmentSpirvSize;

// Descriptor set layout compatible with the shaders
VkDescriptorSetLayout descriptorSetLayout;

VkShaderCreateInfoEXT shaderCreateInfos[2] =
{
    {
        .sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
        .pNext = NULL,
        .flags = VK_SHADER_CREATE_LINK_STAGE_BIT_EXT,
        .stage = VK_SHADER_STAGE_VERTEX_BIT,
        .nextStage = VK_SHADER_STAGE_FRAGMENT_BIT,
        .codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
        .codeSize = vertexSpirvSize,
        .pCode = pVertexSpirv,
        .pName = "main",
        .setLayoutCount = 1,
        .pSetLayouts = &descriptorSetLayout;
        .pushConstantRangeCount = 0,
        .pPushConstantRanges = NULL,
        .pSpecializationInfo = NULL
    },
    {
        .sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
        .pNext = NULL,
        .flags = VK_SHADER_CREATE_LINK_STAGE_BIT_EXT,
        .stage = VK_SHADER_STAGE_FRAGMENT_BIT,
        .nextStage = 0,
        .codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
        .codeSize = fragmentSpirvSize,
        .pCode = pFragmentSpirv,
        .pName = "main",
        .setLayoutCount = 1,
        .pSetLayouts = &descriptorSetLayout;
        .pushConstantRangeCount = 0,
        .pPushConstantRanges = NULL,
        .pSpecializationInfo = NULL
    }
};

VkResult result;
VkShaderEXT shaders[2];

result = vkCreateShadersEXT(device, 2, &shaderCreateInfos, NULL, shaders);
if (result != VK_SUCCESS)
{
    // Handle error
}

之后，在命令缓冲区记录期间，绑定链接的着色器并进行绘制。

// Command buffer in the recording state
VkCommandBuffer commandBuffer;

// Vertex and fragment shader objects created above
VkShaderEXT shaders[2];

// Assume vertex buffers, descriptor sets, etc. have been bound, and existing
// state setting commands have been called to set all required state

const VkShaderStageFlagBits stages[2] =
{
    VK_SHADER_STAGE_VERTEX_BIT,
    VK_SHADER_STAGE_FRAGMENT_BIT
};

// Bind linked shaders
vkCmdBindShadersEXT(commandBuffer, 2, stages, shaders);

// Equivalent to the previous line. Linked shaders can be bound one at a time,
// in any order:
// vkCmdBindShadersEXT(commandBuffer, 1, &stages[1], &shaders[1]);
// vkCmdBindShadersEXT(commandBuffer, 1, &stages[0], &shaders[0]);

// The above is sufficient to draw if the device was created with the
// tessellationShader and geometryShader features disabled. Otherwise, since
// those stages should not execute, vkCmdBindShadersEXT() must be called at
// least once with each of their stages in pStages before drawing:

const VkShaderStageFlagBits unusedStages[3] =
{
    VK_SHADER_STAGE_TESSELLATION_CONTROL_BIT,
    VK_SHADER_STAGE_TESSELLATION_EVALUATION_BIT,
    VK_SHADER_STAGE_GEOMETRY_BIT
};

// NULL pShaders is equivalent to an array of stageCount VK_NULL_HANDLE values,
// meaning no shaders are bound to those stages, and that any previously bound
// shaders are unbound
vkCmdBindShadersEXT(commandBuffer, 3, unusedStages, NULL);

// Graphics shader objects may only be used to draw inside dynamic render pass
// instances begun with vkCmdBeginRendering(), assume one has already been begun

// Draw a triangle
vkCmdDraw(commandBuffer, 3, 1, 0, 0);

示例 2

创建未链接的顶点着色器、几何着色器和片段着色器。

// Logical device created with the shaderObject feature enabled
VkDevice device;

// SPIR-V shader code for vertex shaders, along with their sizes in bytes
void* pVertexSpirv[2];
size_t vertexSpirvSize[2];

// SPIR-V shader code for a geometry shader, along with its size in bytes
void pGeometrySpirv;
size_t geometrySpirvSize;

// SPIR-V shader code for fragment shaders, along with their sizes in bytes
void* pFragmentSpirv[2];
size_t fragmentSpirvSize[2];

// Descriptor set layout compatible with the shaders
VkDescriptorSetLayout descriptorSetLayout;

VkShaderCreateInfoEXT shaderCreateInfos[5] =
{
    // Stage order does not matter
    {
        .sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
        .pNext = NULL,
        .flags = 0,
        .stage = VK_SHADER_STAGE_GEOMETRY_BIT,
        .nextStage = VK_SHADER_STAGE_FRAGMENT_BIT,
        .codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
        .codeSize = pGeometrySpirv,
        .pCode = geometrySpirvSize,
        .pName = "main",
        .setLayoutCount = 1,
        .pSetLayouts = &descriptorSetLayout;
        .pushConstantRangeCount = 0,
        .pPushConstantRanges = NULL,
        .pSpecializationInfo = NULL
    },
    {
        .sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
        .pNext = NULL,
        .flags = 0,
        .stage = VK_SHADER_STAGE_VERTEX_BIT,
        .nextStage = VK_SHADER_STAGE_GEOMETRY_BIT,
        .codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
        .codeSize = vertexSpirvSize[0],
        .pCode = pVertexSpirv[0],
        .pName = "main",
        .setLayoutCount = 1,
        .pSetLayouts = &descriptorSetLayout;
        .pushConstantRangeCount = 0,
        .pPushConstantRanges = NULL,
        .pSpecializationInfo = NULL
    },
    {
        .sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
        .pNext = NULL,
        .flags = 0,
        .stage = VK_SHADER_STAGE_FRAGMENT_BIT,
        .nextStage = 0,
        .codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
        .codeSize = fragmentSpirvSize[0],
        .pCode = pFragmentSpirv[0],
        .pName = "main",
        .setLayoutCount = 1,
        .pSetLayouts = &descriptorSetLayout;
        .pushConstantRangeCount = 0,
        .pPushConstantRanges = NULL,
        .pSpecializationInfo = NULL
    },
    {
        .sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
        .pNext = NULL,
        .flags = 0,
        .stage = VK_SHADER_STAGE_FRAGMENT_BIT,
        .nextStage = 0,
        .codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
        .codeSize = fragmentSpirvSize[1],
        .pCode = pFragmentSpirv[1],
        .pName = "main",
        .setLayoutCount = 1,
        .pSetLayouts = &descriptorSetLayout;
        .pushConstantRangeCount = 0,
        .pPushConstantRanges = NULL,
        .pSpecializationInfo = NULL
    },
    {
        .sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
        .pNext = NULL,
        .flags = 0,
        .stage = VK_SHADER_STAGE_VERTEX_BIT,
        // Suppose we want this vertex shader to be able to be followed by
        // either a geometry shader or fragment shader:
        .nextStage = VK_SHADER_STAGE_GEOMETRY_BIT | VK_SHADER_STAGE_FRAGMENT_BIT,
        .codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
        .codeSize = vertexSpirvSize[1],
        .pCode = pVertexSpirv[1],
        .pName = "main",
        .setLayoutCount = 1,
        .pSetLayouts = &descriptorSetLayout;
        .pushConstantRangeCount = 0,
        .pPushConstantRanges = NULL,
        .pSpecializationInfo = NULL
    }
};

VkResult result;
VkShaderEXT shaders[5];

result = vkCreateShadersEXT(device, 5, &shaderCreateInfos, NULL, shaders);
if (result != VK_SUCCESS)
{
    // Handle error
}

之后，在命令缓冲区记录期间，以不同的组合绑定链接的着色器并进行绘制。

// Command buffer in the recording state
VkCommandBuffer commandBuffer;

// Vertex, geometry, and fragment shader objects created above
VkShaderEXT shaders[5];

// Assume vertex buffers, descriptor sets, etc. have been bound, and existing
// state setting commands have been called to set all required state

const VkShaderStageFlagBits stages[3] =
{
    // Any order is allowed
    VK_SHADER_STAGE_FRAGMENT_BIT,
    VK_SHADER_STAGE_VERTEX_BIT,
    VK_SHADER_STAGE_GEOMETRY_BIT,
};

VkShaderEXT bindShaders[3] =
{
    shaders[2], // FS
    shaders[1], // VS
    shaders[0]  // GS
};

// Bind unlinked shaders
vkCmdBindShadersEXT(commandBuffer, 3, stages, bindShaders);

// Assume the tessellationShader feature is disabled, so vkCmdBindShadersEXT()
// need not have been called with either tessellation stage

// Graphics shader objects may only be used to draw inside dynamic render pass
// instances begun with vkCmdBeginRendering(), assume one has already been begun

// Draw a triangle
vkCmdDraw(commandBuffer, 3, 1, 0, 0);

// Bind a different unlinked fragment shader
const VkShaderStageFlagBits fragmentStage = VK_SHADER_STAGE_FRAGMENT_BIT;
vkCmdBindShadersEXT(commandBuffer, 1, &fragmentStage, &shaders[3]);

// Draw another triangle
vkCmdDraw(commandBuffer, 3, 1, 0, 0);

// Bind a different unlinked vertex shader
const VkShaderStageFlagBits vertexStage = VK_SHADER_STAGE_VERTEX_BIT;
vkCmdBindShadersEXT(commandBuffer, 1, &vertexStage, &shaders[4]);

// Draw another triangle
vkCmdDraw(commandBuffer, 3, 1, 0, 0);

版本历史

  • 修订版 1，2023-03-30 (Daniel Story)

    • 初始草案

VK_EXT_shader_replicated_composites

名称字符串

VK_EXT_shader_replicated_composites

扩展类型

设备扩展

注册扩展号

565

修订

1

批准状态

已批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式
扩展提案

VK_EXT_shader_replicated_composites

上次修改日期

2024-02-08

IP 状态

没有已知的 IP 声明。

贡献者

  • Kévin Petit，Arm Ltd.

  • Jeff Bolz, NVIDIA

  • Piers Daniell, NVIDIA

此扩展添加了对从 SPIR-V 模块中的单个值创建复合体的支持，如 SPV_EXT_replicated_composites 中定义。

新结构

新枚举常量

  • VK_EXT_SHADER_REPLICATED_COMPOSITES_EXTENSION_NAME

  • VK_EXT_SHADER_REPLICATED_COMPOSITES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_REPLICATED_COMPOSITES_FEATURES_EXT

新 SPIR-V 功能

版本历史

  • 修订版 1，2024-02-08 (Kévin Petit)

    • 初始修订版

VK_EXT_shader_stencil_export

名称字符串

VK_EXT_shader_stencil_export

扩展类型

设备扩展

注册扩展号

141

修订

1

批准状态

已批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2017-07-19

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Dominik Witczak，AMD

  • Daniel Rakos, AMD

  • Rex Xu，AMD

描述

此扩展添加了对 SPIR-V 扩展 SPV_EXT_shader_stencil_export 的支持，提供了一种机制，使着色器可以为每次调用生成模板参考值。启用模板测试后，允许针对着色器中生成的值执行测试。

新枚举常量

  • VK_EXT_SHADER_STENCIL_EXPORT_EXTENSION_NAME

  • VK_EXT_SHADER_STENCIL_EXPORT_SPEC_VERSION

版本历史

  • 修订版 1，2017-07-19 (Dominik Witczak)

    • 初始草案

VK_EXT_shader_tile_image

名称字符串

VK_EXT_shader_tile_image

扩展类型

设备扩展

注册扩展号

396

修订

1

批准状态

已批准

扩展和版本依赖关系

Vulkan 版本 1.3

SPIR-V 依赖项
联系方式
扩展提案

VK_EXT_shader_tile_image

其他扩展元数据

上次修改日期

2023-03-23

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Sandeep Kakarlapudi，Arm

  • Jan-Harald Fredriksen, Arm

  • James Fitzpatrick，Imagination

  • Andrew Garrard, Imagination

  • Jeff Leger, Qualcomm

  • Huilong Wang，华为

  • Graeme Leese, Broadcom

  • Hans-Kristian Arntzen, Valve

  • Tobias Hector, AMD

  • Jeff Bolz, NVIDIA

  • Shahbaz Youssefi, Google

描述

此扩展允许片段着色器调用以光栅化顺序读取其像素位置的颜色、深度和模板值。仅当使用 VK_KHR_dynamic_rendering 引入的动态渲染通道时，该功能才可用。用例示例是可编程混合和延迟着色。

有关更多信息，请参见 片段着色器图块图像读取。

新结构

新枚举常量

  • VK_EXT_SHADER_TILE_IMAGE_EXTENSION_NAME

  • VK_EXT_SHADER_TILE_IMAGE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_TILE_IMAGE_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_TILE_IMAGE_PROPERTIES_EXT

问题

无。

示例

颜色读取示例。

layout( location = 0 /* aliased to color attachment 0 */ ) tileImageEXT highp attachmentEXT color0;
layout( location = 1 /* aliased to color attachment 1 */ ) tileImageEXT highp attachmentEXT color1;

layout( location = 0 ) out vec4 fragColor;

void main()
{
    vec4 value = colorAttachmentReadEXT(color0) + colorAttachmentReadEXT(color1);
    fragColor = value;
}

深度和模板读取示例。

void main()
{
    // read sample 0: works for non-MSAA or MSAA targets
    highp float last_depth = depthAttachmentReadEXT();
    lowp uint last_stencil = stencilAttachmentReadEXT();

    //..
}

版本历史

  • 修订版 1，2023-03-23 (Sandeep Kakarlapudi)

    • 初始版本

VK_EXT_subpass_merge_feedback

名称字符串

VK_EXT_subpass_merge_feedback

扩展类型

设备扩展

注册扩展号

459

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式
扩展提案

VK_EXT_subpass_merge_feedback

其他扩展元数据

上次修改日期

2022-05-24

IP 状态

没有已知的 IP 声明。

贡献者

  • Jan-Harald Fredriksen, Arm

  • Jorg Wagner，Arm

  • Ting Wei, Arm

描述

此扩展添加了一种机制，以向应用程序提供有关渲染通道创建时指定的子通道是否由实现合并的反馈。此外，它提供了一个控件，以在渲染通道中启用或禁用子通道合并。

新结构

新枚举

新枚举常量

  • VK_EXT_SUBPASS_MERGE_FEEDBACK_EXTENSION_NAME

  • VK_EXT_SUBPASS_MERGE_FEEDBACK_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBPASS_MERGE_FEEDBACK_FEATURES_EXT

    • VK_STRUCTURE_TYPE_RENDER_PASS_CREATION_CONTROL_EXT

    • VK_STRUCTURE_TYPE_RENDER_PASS_CREATION_FEEDBACK_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_RENDER_PASS_SUBPASS_FEEDBACK_CREATE_INFO_EXT

版本历史

  • 修订版 1，2022-03-10

    • 初始草案。

  • 修订版 2，2022-05-24

    • 修复 structextends 和 constness 问题。

VK_EXT_surface_maintenance1

名称字符串

VK_EXT_surface_maintenance1

扩展类型

实例扩展

注册扩展号

275

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_surface
和
VK_KHR_get_surface_capabilities2

联系方式
扩展提案

VK_EXT_surface_maintenance1

其他扩展元数据

上次修改日期

2022-11-09

贡献者

  • Jeff Juliano, NVIDIA

  • Lionel Landwerlin, Intel

  • Shahbaz Youssefi, Google

  • Chris Forbes, Google

  • Ian Elliott, Google

  • Hans-Kristian Arntzen, Valve

  • Daniel Stone, Collabora

描述

VK_EXT_surface_maintenance1 添加了一系列窗口系统集成功能，这些功能在最初的 VK_KHR_surface 扩展中被有意忽略或遗漏。

新功能如下

  • 允许查询特定呈现模式下，从表面获得的最小/最大图像数量。

  • 允许查询表面的缩放呈现能力。

  • 允许查询表面可轻松切换且无需重建交换链的呈现模式集。

新结构体

新枚举

新位掩码

新枚举常量

  • VK_EXT_SURFACE_MAINTENANCE_1_EXTENSION_NAME

  • VK_EXT_SURFACE_MAINTENANCE_1_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_SURFACE_PRESENT_MODE_COMPATIBILITY_EXT

    • VK_STRUCTURE_TYPE_SURFACE_PRESENT_MODE_EXT

    • VK_STRUCTURE_TYPE_SURFACE_PRESENT_SCALING_CAPABILITIES_EXT

版本历史

  • 修订版 0，2019-02-27 (Lionel Landwerlin)

    • 内部修订

  • 修订版 1，2022-11-09 (Shahbaz Youssefi)

    • 添加功能并完善规范

VK_EXT_swapchain_colorspace

名称字符串

VK_EXT_swapchain_colorspace

扩展类型

实例扩展

注册扩展号

105

修订

5

批准状态

已批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

其他扩展元数据

上次修改日期

2019-04-26

IP 状态

没有已知的 IP 声明。

贡献者

  • Courtney Goeltzenleuchter, Google

描述

此扩展扩展了 VkColorSpaceKHR，以支持除 VK_COLOR_SPACE_SRGB_NONLINEAR_KHR 之外的大多数标准颜色空间。此扩展还添加了对 VK_COLOR_SPACE_PASS_THROUGH_EXT 的支持，允许应用程序使用 VkColorSpaceKHR 中未明确枚举的颜色空间。

新枚举常量

  • VK_EXT_SWAPCHAIN_COLOR_SPACE_EXTENSION_NAME

  • VK_EXT_SWAPCHAIN_COLOR_SPACE_SPEC_VERSION

  • 扩展 VkColorSpaceKHR

    • VK_COLOR_SPACE_ADOBERGB_LINEAR_EXT

    • VK_COLOR_SPACE_ADOBERGB_NONLINEAR_EXT

    • VK_COLOR_SPACE_BT2020_LINEAR_EXT

    • VK_COLOR_SPACE_BT709_LINEAR_EXT

    • VK_COLOR_SPACE_BT709_NONLINEAR_EXT

    • VK_COLOR_SPACE_DCI_P3_LINEAR_EXT

    • VK_COLOR_SPACE_DCI_P3_NONLINEAR_EXT

    • VK_COLOR_SPACE_DISPLAY_P3_LINEAR_EXT

    • VK_COLOR_SPACE_DISPLAY_P3_NONLINEAR_EXT

    • VK_COLOR_SPACE_DOLBYVISION_EXT

    • VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT

    • VK_COLOR_SPACE_EXTENDED_SRGB_NONLINEAR_EXT

    • VK_COLOR_SPACE_HDR10_HLG_EXT

    • VK_COLOR_SPACE_HDR10_ST2084_EXT

    • VK_COLOR_SPACE_PASS_THROUGH_EXT

问题

1) 规范是否需要指定哪些图像格式支持颜色空间？

已解决：像素格式与颜色空间无关（尽管某些颜色空间确实需要/必须使用浮点颜色分量才能有用）。因此，不计划记录哪些格式支持哪些颜色空间。应用程序可以调用 vkGetPhysicalDeviceSurfaceFormatsKHR 来查询特定实现支持的内容。

2) 应用程序如何确定硬件是否支持颜色空间的适当传递函数？

已解决：扩展表明，如果不是 sRGB，则实现必须不执行 OETF 编码。此责任由应用程序着色器承担。实现支持的任何其他本机 OETF/EOTF 函数都可以通过单独的扩展来描述。

版本历史

  • 修订版 1，2016-12-27 (Courtney Goeltzenleuchter)

    • 初始版本

  • 修订版 2，2017-01-19 (Courtney Goeltzenleuchter)

    • 为 BT2020 添加直通和多个选项。

    • 修复一些方程式显示不正确的问题。

  • 修订版 3，2017-06-23 (Courtney Goeltzenleuchter)

    • 添加扩展的 sRGB 非线性枚举。

  • 修订版 4，2019-04-26 (Graeme Leese)

    • 澄清颜色空间传递函数的使用。

    • 请参阅数据格式规范中的规范定义。

    • 澄清 DCI-P3 和 Display P3 的使用。

  • 修订版 5，2024-03-16 (Zehui Lin)

    • 修复 EOTF 和 OETF 的概念互换。

    • 澄清呈现引擎可以接受颜色空间。

VK_EXT_swapchain_maintenance1

名称字符串

VK_EXT_swapchain_maintenance1

扩展类型

设备扩展

注册扩展号

276

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_swapchain
和
VK_EXT_surface_maintenance1
和
     VK_KHR_get_physical_device_properties2
    或
     Vulkan 版本 1.1

联系方式
扩展提案

VK_EXT_swapchain_maintenance1

其他扩展元数据

上次修改日期

2022-10-28

贡献者

  • Jeff Juliano, NVIDIA

  • Shahbaz Youssefi, Google

  • Chris Forbes, Google

  • Ian Elliott, Google

  • Yiwei Zhang, Google

  • Charlie Lao, Google

  • Lina Versace，谷歌

  • Ralph Potter, Samsung

  • Igor Nazarov, Samsung

  • Hyunchang Kim, Samsung

  • Suenghwan Lee, Samsung

  • Munseong Kang, Samsung

  • Joonyong Park, Samsung

  • Hans-Kristian Arntzen, Valve

  • Lisa Wu, Arm

  • Daniel Stone, Collabora

  • Pan Gao, Huawei

描述

VK_EXT_swapchain_maintenance1 添加了一系列窗口系统集成功能，这些功能在最初的 VK_KHR_swapchain 扩展中被有意忽略或遗漏。

新功能如下

  • 指定一个栅栏，该栅栏将在与呈现操作相关的资源可以安全销毁时发出信号。

  • 允许在每次呈现粒度上更改交换链正在使用的呈现模式。

  • 允许应用程序定义在将交换链图像呈现到尺寸与图像不同的表面时的行为。使用此功能可能允许实现避免在这种情况下返回 VK_ERROR_OUT_OF_DATE_KHR。

  • 允许应用程序推迟交换链内存分配，以缩短启动时间和内存占用。

  • 允许应用程序释放先前获取但未呈现的图像。

新命令

新结构体

新枚举常量

  • VK_EXT_SWAPCHAIN_MAINTENANCE_1_EXTENSION_NAME

  • VK_EXT_SWAPCHAIN_MAINTENANCE_1_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SWAPCHAIN_MAINTENANCE_1_FEATURES_EXT

    • VK_STRUCTURE_TYPE_RELEASE_SWAPCHAIN_IMAGES_INFO_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_FENCE_INFO_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_MODES_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_MODE_INFO_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_SCALING_CREATE_INFO_EXT

  • 扩展 VkSwapchainCreateFlagBitsKHR

    • VK_SWAPCHAIN_CREATE_DEFERRED_MEMORY_ALLOCATION_BIT_EXT

版本历史

  • 修订版 0，2019-05-28

    • 初始修订

  • 修订版 1，2022-08-21 (Shahbaz Youssefi)

    • 添加功能并完善规范

VK_EXT_transform_feedback

名称字符串

VK_EXT_transform_feedback

扩展类型

设备扩展

注册扩展号

29

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

其他扩展元数据

上次修改日期

2018-10-09

贡献者

  • Baldur Karlsson, Valve

  • Boris Zanin, Mobica

  • Daniel Rakos, AMD

  • Donald Scorgie, Imagination

  • Henri Verbeet, CodeWeavers

  • Jan-Harald Fredriksen, Arm

  • Faith Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Jesse Barker, Unity

  • Jesse Hall, Google

  • Pierre-Loup Griffais, Valve

  • Philip Rebohle, DXVK

  • Ruihao Zhang，高通

  • Samuel Pitoiset, Valve

  • Slawomir Grajewski, Intel

  • Stu Smith, Imagination Technologies

描述

此扩展通过公开 SPIR-V 的 TransformFeedback 和 GeometryStreams 功能，向 Vulkan API 添加了变换反馈，以将顶点、细分或几何着色器输出捕获到一个或多个缓冲区。它增加了 API 功能，可以将变换反馈缓冲区绑定以捕获图形管线从为变换反馈修饰的 SPIR-V 输出发出的图元。通过存储和检索字节计数器，可以暂停和恢复变换反馈捕获。捕获的数据可以再次绘制，其中顶点计数来自字节计数器，无需 CPU 干预。如果实现支持，则可以光栅化除零之外的顶点流。

所有这些功能旨在匹配 OpenGL 核心变换反馈功能的全部功能及其他功能。许多功能是可选的，以允许基本的 OpenGL ES GPU 也实现此扩展。

此扩展公开的功能的主要目的是支持来自其他 3D API 的转换层。此功能不被认为是前瞻性的，预计不会提升为 KHR 扩展或 Vulkan 核心功能。除非需要进行转换，否则建议开发人员使用替代技术来使用 GPU 处理和捕获顶点数据。

新命令

新结构

新位掩码

新枚举常量

  • VK_EXT_TRANSFORM_FEEDBACK_EXTENSION_NAME

  • VK_EXT_TRANSFORM_FEEDBACK_SPEC_VERSION

  • 扩展 VkAccessFlagBits

    • VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT

    • VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT

    • VK_ACCESS_TRANSFORM_FEEDBACK_WRITE_BIT_EXT

  • 扩展 VkBufferUsageFlagBits

    • VK_BUFFER_USAGE_TRANSFORM_FEEDBACK_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_TRANSFORM_FEEDBACK_COUNTER_BUFFER_BIT_EXT

  • 扩展 VkPipelineStageFlagBits

    • VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT

  • 扩展 VkQueryType

    • VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_STREAM_CREATE_INFO_EXT

问题

1）我们是否应该包含暂停/恢复功能？

已解决：是的，这对于简化具有此功能的其他 API 的分层是必要的。要暂停，请使用 vkCmdEndTransformFeedbackEXT，并在 pCounterBuffers 数组中提供有效的缓冲区句柄，并在 pCounterBufferOffsets 数组中提供偏移量，以便实现保存恢复点。然后要恢复，请使用先前的 pCounterBuffers 和 pCounterBufferOffsets 值使用 vkCmdBeginTransformFeedbackEXT。在暂停和恢复之间，需要为计数器缓冲区设置一个内存屏障，其源访问为 VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT，位于管线阶段 VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT，目标访问为 VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT，位于管线阶段 VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT。

2）这如何与多视图交互？

已解决：在启用多视图的渲染通道中，不能激活变换反馈。

3）应该如何进行查询？

已解决：有一个新的查询类型 VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT。使用此类型创建的查询池将捕获 2 个整数 - numPrimitivesWritten 和 numPrimitivesNeeded - 用于来自最后一个光栅化前着色器阶段的指定顶点流输出。默认情况下，查询的顶点流输出为零，但可以使用新的 vkCmdBeginQueryIndexedEXT 和 vkCmdEndQueryIndexedEXT 命令指定。

版本历史

  • 修订版 1，2018-10-09 (Piers Daniell)

    • 内部修订

VK_EXT_validation_cache

名称字符串

VK_EXT_validation_cache

扩展类型

设备扩展

注册扩展号

161

修订

1

批准状态

已批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2017-08-29

IP 状态

没有已知的 IP 声明。

贡献者

  • Cort Stratton，Google

  • Chris Forbes, Google

描述

此扩展提供了一种机制，用于跨 Vulkan 应用程序的多次运行缓存可能开销大的内部验证操作的结果。核心是 VkValidationCacheEXT 对象类型，其管理方式与现有的 VkPipelineCache 类似。

新的结构 VkShaderModuleValidationCacheCreateInfoEXT 可以包含在 vkCreateShaderModule 时的 pNext 链中。它包含一个 VkValidationCacheEXT，用于在验证 VkShaderModule 时使用。

新对象类型

新命令

新结构

新枚举

新位掩码

新枚举常量

  • VK_EXT_VALIDATION_CACHE_EXTENSION_NAME

  • VK_EXT_VALIDATION_CACHE_SPEC_VERSION

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_VALIDATION_CACHE_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_SHADER_MODULE_VALIDATION_CACHE_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_VALIDATION_CACHE_CREATE_INFO_EXT

版本历史

  • 修订版 1，2017-08-29 (Cort Stratton)

    • 初始草案

VK_EXT_vertex_attribute_robustness

名称字符串

VK_EXT_vertex_attribute_robustness

扩展类型

设备扩展

注册扩展号

609

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2024-11-01

IP 状态

没有已知的 IP 声明。

贡献者

  • Daniel Story, Nintendo

描述

对于应用程序来说，为可能引用没有顶点数据的属性位置的顶点着色器定义虚假的顶点属性位置和缓冲区绑定会对性能产生不利影响。

此扩展允许应用程序不必指定虚假的顶点属性位置，如果顶点着色器读取这些属性，它将读取 (0,0,0,0) 或 (0,0,0,1)。

新结构

新枚举常量

  • VK_EXT_VERTEX_ATTRIBUTE_ROBUSTNESS_EXTENSION_NAME

  • VK_EXT_VERTEX_ATTRIBUTE_ROBUSTNESS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_ROBUSTNESS_FEATURES_EXT

问题

无

版本历史

  • 修订版 1，2024-11-01 (Piers Daniell)

    • 内部修订

VK_EXT_vertex_input_dynamic_state

名称字符串

VK_EXT_vertex_input_dynamic_state

扩展类型

设备扩展

注册扩展号

353

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2020-08-21

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

  • Spencer Fricke, Samsung

  • Stu Smith, AMD

描述

顶点输入绑定和属性描述是导致需要创建的管线状态对象组合爆炸的状态之一。通过允许它们是动态的，应用程序可以减少它们需要创建的管线对象的数量。

此扩展为 VkPipelineVertexInputStateCreateInfo 中通常是静态状态的内容添加了动态状态支持。

新命令

新结构体

新枚举常量

  • VK_EXT_VERTEX_INPUT_DYNAMIC_STATE_EXTENSION_NAME

  • VK_EXT_VERTEX_INPUT_DYNAMIC_STATE_SPEC_VERSION

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_VERTEX_INPUT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_INPUT_DYNAMIC_STATE_FEATURES_EXT

    • VK_STRUCTURE_TYPE_VERTEX_INPUT_ATTRIBUTE_DESCRIPTION_2_EXT

    • VK_STRUCTURE_TYPE_VERTEX_INPUT_BINDING_DESCRIPTION_2_EXT

版本历史

VK_EXT_ycbcr_image_arrays

名称字符串

VK_EXT_ycbcr_image_arrays

扩展类型

设备扩展

注册扩展号

253

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_sampler_ycbcr_conversion
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2019-01-15

贡献者

  • Piers Daniell, NVIDIA

描述

此扩展允许创建需要 Y′CBCR 转换 的格式的图像，并具有多个数组层，否则会受到限制。

新结构体

新枚举常量

  • VK_EXT_YCBCR_IMAGE_ARRAYS_EXTENSION_NAME

  • VK_EXT_YCBCR_IMAGE_ARRAYS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_YCBCR_IMAGE_ARRAYS_FEATURES_EXT

版本历史

  • 修订版 1, 2019-01-15 (Piers Daniell)

    • 初始修订版

VK_AMD_anti_lag

名称字符串

VK_AMD_anti_lag

扩展类型

设备扩展

注册扩展号

477

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

  • Stu Smith

扩展提案

VK_AMD_anti_lag

其他扩展元数据

上次修改日期

2024-06-06

IP 状态

没有已知的 IP 声明。

贡献者

  • Tobias Hector, AMD

  • Stuart Smith, AMD

  • Arkadiusz Sarwa, AMD

描述

此扩展会自动调整 CPU 的速度，以确保它不会远远领先于 GPU，从而减少接收到的输入和屏幕上的更新之间的延迟。此外，Anti-Lag+ 为应用程序提供了在输入处理开始时通知驱动程序的功能，以便对齐显示更新的时间，从而实现接收输入和在屏幕上显示之间的更低延迟。

新命令

新结构体

新枚举

新枚举常量

  • VK_AMD_ANTI_LAG_EXTENSION_NAME

  • VK_AMD_ANTI_LAG_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ANTI_LAG_DATA_AMD

    • VK_STRUCTURE_TYPE_ANTI_LAG_PRESENTATION_INFO_AMD

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ANTI_LAG_FEATURES_AMD

版本历史

  • 修订版 1, 2024-06-06 (Arkadiusz Sarw)

    • 初始版本

VK_AMD_buffer_marker

名称字符串

VK_AMD_buffer_marker

扩展类型

设备扩展

注册扩展号

180

修订

1

批准状态

未批准

扩展和版本依赖关系

无

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_synchronization2 交互

特殊用途
联系方式

其他扩展元数据

上次修改日期

2018-01-26

IP 状态

没有已知的 IP 声明。

贡献者

  • Matthaeus G. Chajdas, AMD

  • Jaakko Konttinen, AMD

  • Daniel Rakos, AMD

描述

此扩展添加了一个新操作，用于将小的标记值以流水线方式写入 VkBuffer 对象。

这些标记的主要目的是方便开发调试工具，以跟踪哪些流水线命令导致了设备丢失。

新命令

如果支持 Vulkan 1.3 版本 或 VK_KHR_synchronization2

新枚举常量

  • VK_AMD_BUFFER_MARKER_EXTENSION_NAME

  • VK_AMD_BUFFER_MARKER_SPEC_VERSION

示例

无。

版本历史

  • 修订版 1, 2018-01-26 (Jaakko Konttinen)

    • 初始修订版

VK_AMD_device_coherent_memory

名称字符串

VK_AMD_device_coherent_memory

扩展类型

设备扩展

注册扩展号

230

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2019-02-04

贡献者

  • Ping Fu, AMD

  • Timothy Lottes, AMD

  • Tobias Hector, AMD

描述

此扩展添加了设备一致性和设备非缓存内存类型。对设备一致性内存的任何设备访问都会自动对任何其他设备访问可见。设备非缓存内存向应用程序指示已为特定内存类型禁用缓存，从而保证了设备一致性。

对于一般访问，设备一致性和非缓存内存的性能预计低于非设备一致性内存，但在某些情况下可能很有用；特别是对于调试而言。

新结构体

新枚举常量

  • VK_AMD_DEVICE_COHERENT_MEMORY_EXTENSION_NAME

  • VK_AMD_DEVICE_COHERENT_MEMORY_SPEC_VERSION

  • 扩展 VkMemoryPropertyFlagBits

    • VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD

    • VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COHERENT_MEMORY_FEATURES_AMD

版本历史

  • 修订版 1, 2019-02-04 (Tobias Hector)

    • 初始修订版

VK_AMD_display_native_hdr

名称字符串

VK_AMD_display_native_hdr

扩展类型

设备扩展

注册扩展号

214

修订

1

批准状态

未批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
    或
     Vulkan 版本 1.1
和
VK_KHR_get_surface_capabilities2
和
VK_KHR_swapchain

联系方式

其他扩展元数据

上次修改日期

2018-12-18

IP 状态

没有已知的 IP 声明。

贡献者

  • Matthaeus G. Chajdas, AMD

  • Aaron Hagan, AMD

  • Aric Cyr, AMD

  • Timothy Lottes, AMD

  • Derrick Owens, AMD

  • Daniel Rakos, AMD

描述

此扩展向 Vulkan 引入以下显示原生 HDR 功能

  • 一个新的 VkColorSpaceKHR 枚举，用于设置原生显示色彩空间。例如，此色彩空间将由交换链设置，以在 Freesync2 显示器中使用原生色彩空间。

  • 局部调光控制

新命令

新结构体

新枚举常量

  • VK_AMD_DISPLAY_NATIVE_HDR_EXTENSION_NAME

  • VK_AMD_DISPLAY_NATIVE_HDR_SPEC_VERSION

  • 扩展 VkColorSpaceKHR

    • VK_COLOR_SPACE_DISPLAY_NATIVE_AMD

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DISPLAY_NATIVE_HDR_SURFACE_CAPABILITIES_AMD

    • VK_STRUCTURE_TYPE_SWAPCHAIN_DISPLAY_NATIVE_HDR_CREATE_INFO_AMD

问题

无。

示例

无。

版本历史

  • 修订版 1，2018-12-18 (Daniel Rakos)

    • 初始修订版

VK_AMD_gcn_shader

名称字符串

VK_AMD_gcn_shader

扩展类型

设备扩展

注册扩展号

26

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2016-05-30

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Dominik Witczak，AMD

  • Daniel Rakos, AMD

  • Rex Xu，AMD

  • Graham Sellers, AMD

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

新枚举常量

  • VK_AMD_GCN_SHADER_EXTENSION_NAME

  • VK_AMD_GCN_SHADER_SPEC_VERSION

版本历史

  • 修订版 1，2016-05-30 (Dominik Witczak)

    • 初始草案

VK_AMD_memory_overallocation_behavior

名称字符串

VK_AMD_memory_overallocation_behavior

扩展类型

设备扩展

注册扩展号

190

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2018-09-19

IP 状态

没有已知的 IP 声明。

贡献者

  • Martin Dinkov, AMD

  • Matthaeus Chajdas, AMD

  • Daniel Rakos, AMD

  • Jon Campbell, AMD

描述

此扩展允许控制是否允许超出设备内存堆大小（由 VkPhysicalDeviceMemoryProperties 报告）的显式过度分配。过度分配可能会导致性能损失，并且并非所有平台都支持。

新结构体

新枚举

新枚举常量

  • VK_AMD_MEMORY_OVERALLOCATION_BEHAVIOR_EXTENSION_NAME

  • VK_AMD_MEMORY_OVERALLOCATION_BEHAVIOR_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_MEMORY_OVERALLOCATION_CREATE_INFO_AMD

版本历史

  • 修订版 1，2018-09-19 (Martin Dinkov)

    • 初始草案。

VK_AMD_mixed_attachment_samples

名称字符串

VK_AMD_mixed_attachment_samples

扩展类型

设备扩展

注册扩展号

137

修订

1

批准状态

未批准

扩展和版本依赖关系

无

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_dynamic_rendering 交互

联系方式

其他扩展元数据

上次修改日期

2017-07-24

贡献者

  • Mais Alnasser, AMD

  • Matthaeus G. Chajdas, AMD

  • Maciej Jesionowski, AMD

  • Daniel Rakos, AMD

描述

此扩展使应用程序能够使用多重采样渲染，其深度/模板采样计数大于颜色采样计数。深度/模板采样计数大于颜色采样计数允许以高于颜色信息更高的采样率维护几何和覆盖信息。所有样本都经过深度/模板测试，但只有前几个颜色样本计数编号的样本获得相应的颜色输出。

新结构体

如果支持 Vulkan 版本 1.3 或 VK_KHR_dynamic_rendering

新枚举常量

  • VK_AMD_MIXED_ATTACHMENT_SAMPLES_EXTENSION_NAME

  • VK_AMD_MIXED_ATTACHMENT_SAMPLES_SPEC_VERSION

如果支持 Vulkan 版本 1.3 或 VK_KHR_dynamic_rendering

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ATTACHMENT_SAMPLE_COUNT_INFO_AMD

问题

无。

版本历史

  • 修订版 1，2017-07-24 (Daniel Rakos)

    • 内部修订

VK_AMD_pipeline_compiler_control

名称字符串

VK_AMD_pipeline_compiler_control

扩展类型

设备扩展

注册扩展号

184

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2019-07-26

IP 状态

没有已知的 IP 声明。

贡献者

  • Matthaeus G. Chajdas, AMD

  • Daniel Rakos, AMD

  • Maciej Jesionowski, AMD

  • Tobias Hector, AMD

描述

此扩展引入了 VkPipelineCompilerControlCreateInfoAMD 结构体，可以将其链接到管道的创建信息，以指定影响管道编译的附加标志。

新结构体

新枚举

新位掩码

新枚举常量

  • VK_AMD_PIPELINE_COMPILER_CONTROL_EXTENSION_NAME

  • VK_AMD_PIPELINE_COMPILER_CONTROL_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PIPELINE_COMPILER_CONTROL_CREATE_INFO_AMD

问题

无。

示例

无。

版本历史

  • 修订版 1，2019-07-26 (Tobias Hector)

    • 初始修订版。

VK_AMD_rasterization_order

名称字符串

VK_AMD_rasterization_order

扩展类型

设备扩展

注册扩展号

19

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2016-04-25

IP 状态

没有已知的 IP 声明。

贡献者

  • Matthaeus G. Chajdas, AMD

  • Jaakko Konttinen, AMD

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Dominik Witczak，AMD

描述

此扩展引入了应用程序控制图元光栅化顺序的可能性。在未扩展的 Vulkan 中，保证以下阶段按API 顺序执行

  • 深度边界测试

  • 模板测试、模板操作和模板写入

  • 深度测试和深度写入

  • 遮挡查询

  • 混合、逻辑操作和颜色写入

此扩展使应用程序可以选择采用一种宽松的、实现定义的图元光栅化顺序，该顺序可以允许更好地并行处理图元，从而实现更高的图元吞吐量。它适用于已知图元光栅化顺序不会影响渲染输出的情况，或者从应用程序的角度来看，不同光栅化顺序引起的任何差异都不重要。

以下是一些使用宽松的图元光栅化顺序不会对最终渲染产生影响的示例

  • 如果渲染的图元已知在帧缓冲区空间中不重叠。

  • 如果深度测试与 VK_COMPARE_OP_LESS、VK_COMPARE_OP_LESS_OR_EQUAL、VK_COMPARE_OP_GREATER 或 VK_COMPARE_OP_GREATER_OR_EQUAL 的比较运算符一起使用，并且渲染的图元已知在裁剪空间中不重叠。

  • 如果未使用深度测试，并且为所有附件启用了具有交换混合运算符的混合。

新结构体

新枚举

新枚举常量

  • VK_AMD_RASTERIZATION_ORDER_EXTENSION_NAME

  • VK_AMD_RASTERIZATION_ORDER_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_RASTERIZATION_ORDER_AMD

问题

1) 这个扩展对应用程序开发者有什么用？

已解决：当由于内容的性质、所使用的配置或对渲染输出的要求，严格的 API 顺序光栅化并不重要时，允许他们提高图元的吞吐量。

2) 这个扩展如何与旨在通过适当排序输入图元来减少过度绘制的内容优化交互？

已解决：虽然宽松的光栅化顺序可能会在一定程度上限制此类内容优化的有效性，但即使在使用宽松的光栅化顺序时，预计也会保留其大部分好处，因此即使应用程序打算使用此扩展，也应该仍然应用这些优化。

3) 使用新的宽松模式时，是否对图元光栅化顺序有任何保证？

已解决：没有。在这种情况下，光栅化顺序完全依赖于实现，但实际上预计它会在某种程度上仍然遵循传入图元的顺序。

4) 新的宽松光栅化顺序是否对 API 的可重复性和其他不变性规则有任何不利影响？

已解决：是的，从某种意义上说，它扩展了不适用可重复性要求的例外列表。

示例

无

问题

无

版本历史

  • 修订版 1, 2016-04-25 (Daniel Rakos)

    • 初始草案。

VK_AMD_shader_ballot

名称字符串

VK_AMD_shader_ballot

扩展类型

设备扩展

注册扩展号

38

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2016-09-19

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Qun Lin, AMD

  • Graham Sellers, AMD

  • Daniel Rakos, AMD

  • Rex Xu，AMD

  • Dominik Witczak，AMD

  • Matthäus G. Chajdas, AMD

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

新的枚举常量

  • VK_AMD_SHADER_BALLOT_EXTENSION_NAME

  • VK_AMD_SHADER_BALLOT_SPEC_VERSION

版本历史

  • 修订版 1, 2016-09-19 (Dominik Witczak)

    • 初始草案

VK_AMD_shader_core_properties

名称字符串

VK_AMD_shader_core_properties

扩展类型

设备扩展

注册扩展号

186

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2019-06-25

IP 状态

没有已知的 IP 声明。

贡献者

  • Martin Dinkov, AMD

  • Matthaeus G. Chajdas, AMD

描述

此扩展通过 VK_KHR_get_physical_device_properties2 扩展公开目标物理设备的着色器核心属性。请参考下面的示例以了解正确的使用方法。

新结构

新的枚举常量

  • VK_AMD_SHADER_CORE_PROPERTIES_EXTENSION_NAME

  • VK_AMD_SHADER_CORE_PROPERTIES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_AMD

示例

此示例检索物理设备的着色器核心属性。

extern VkInstance       instance;

PFN_vkGetPhysicalDeviceProperties2 pfnVkGetPhysicalDeviceProperties2 =
    reinterpret_cast<PFN_vkGetPhysicalDeviceProperties2>
    (vkGetInstanceProcAddr(instance, "vkGetPhysicalDeviceProperties2") );

VkPhysicalDeviceProperties2             general_props;
VkPhysicalDeviceShaderCorePropertiesAMD shader_core_properties;

shader_core_properties.pNext = nullptr;
shader_core_properties.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_AMD;

general_props.pNext = &shader_core_properties;
general_props.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2;

// After this call, shader_core_properties has been populated
pfnVkGetPhysicalDeviceProperties2(device, &general_props);

printf("Number of shader engines: %d\n",
    m_shader_core_properties.shader_engine_count =
    shader_core_properties.shaderEngineCount;
printf("Number of shader arrays: %d\n",
    m_shader_core_properties.shader_arrays_per_engine_count =
    shader_core_properties.shaderArraysPerEngineCount;
printf("Number of CUs per shader array: %d\n",
    m_shader_core_properties.compute_units_per_shader_array =
    shader_core_properties.computeUnitsPerShaderArray;
printf("Number of SIMDs per compute unit: %d\n",
    m_shader_core_properties.simd_per_compute_unit =
    shader_core_properties.simdPerComputeUnit;
printf("Number of wavefront slots in each SIMD: %d\n",
    m_shader_core_properties.wavefronts_per_simd =
    shader_core_properties.wavefrontsPerSimd;
printf("Number of threads per wavefront: %d\n",
    m_shader_core_properties.wavefront_size =
    shader_core_properties.wavefrontSize;
printf("Number of physical SGPRs per SIMD: %d\n",
    m_shader_core_properties.sgprs_per_simd =
    shader_core_properties.sgprsPerSimd;
printf("Minimum number of SGPRs that can be allocated by a wave: %d\n",
    m_shader_core_properties.min_sgpr_allocation =
    shader_core_properties.minSgprAllocation;
printf("Number of available SGPRs: %d\n",
    m_shader_core_properties.max_sgpr_allocation =
    shader_core_properties.maxSgprAllocation;
printf("SGPRs are allocated in groups of this size: %d\n",
    m_shader_core_properties.sgpr_allocation_granularity =
    shader_core_properties.sgprAllocationGranularity;
printf("Number of physical VGPRs per SIMD: %d\n",
    m_shader_core_properties.vgprs_per_simd =
    shader_core_properties.vgprsPerSimd;
printf("Minimum number of VGPRs that can be allocated by a wave: %d\n",
    m_shader_core_properties.min_vgpr_allocation =
    shader_core_properties.minVgprAllocation;
printf("Number of available VGPRs: %d\n",
    m_shader_core_properties.max_vgpr_allocation =
    shader_core_properties.maxVgprAllocation;
printf("VGPRs are allocated in groups of this size: %d\n",
    m_shader_core_properties.vgpr_allocation_granularity =
    shader_core_properties.vgprAllocationGranularity;

版本历史

  • 修订版 2, 2019-06-25 (Matthaeus G. Chajdas)

    • 阐明了一些字段的含义。

  • 修订版 1, 2018-02-15 (Martin Dinkov)

    • 初始草案。

VK_AMD_shader_core_properties2

名称字符串

VK_AMD_shader_core_properties2

扩展类型

设备扩展

注册扩展号

228

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_AMD_shader_core_properties

联系方式

其他扩展元数据

上次修改日期

2019-07-26

IP 状态

没有已知的 IP 声明。

贡献者

  • Matthaeus G. Chajdas, AMD

  • Tobias Hector, AMD

描述

此扩展通过 VK_KHR_get_physical_device_properties2 扩展公开目标物理设备的额外着色器核心属性。

新结构

新枚举

新的位掩码

新的枚举常量

  • VK_AMD_SHADER_CORE_PROPERTIES_2_EXTENSION_NAME

  • VK_AMD_SHADER_CORE_PROPERTIES_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_2_AMD

示例

无。

版本历史

  • 修订版 1, 2019-07-26 (Matthaeus G. Chajdas)

    • 初始草案。

VK_AMD_shader_early_and_late_fragment_tests

名称字符串

VK_AMD_shader_early_and_late_fragment_tests

扩展类型

设备扩展

注册扩展号

322

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式
扩展提案

VK_AMD_shader_early_and_late_fragment_tests

其他扩展元数据

上次修改日期

2021-09-14

交互和外部依赖
贡献者

  • Tobias Hector, AMD

描述

此扩展增加了对 SPV_AMD_shader_early_and_late_fragment_tests 扩展的支持，允许着色器使用 EarlyAndLateFragmentTestsAMD 执行模式显式选择允许提前和延迟片段测试。

如果支持 VK_EXT_shader_stencil_export 扩展，则会提供允许类似于 DepthUnchanged、DepthLess 和 DepthGreater 的提前深度测试的额外执行模式。

新结构

新的枚举常量

  • VK_AMD_SHADER_EARLY_AND_LATE_FRAGMENT_TESTS_EXTENSION_NAME

  • VK_AMD_SHADER_EARLY_AND_LATE_FRAGMENT_TESTS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_EARLY_AND_LATE_FRAGMENT_TESTS_FEATURES_AMD

版本历史

  • 修订版 1, 2021-09-14 (Tobias Hector)

    • 初始草案

VK_AMD_shader_explicit_vertex_parameter

名称字符串

VK_AMD_shader_explicit_vertex_parameter

扩展类型

设备扩展

注册扩展号

22

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2016-05-10

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Matthaeus G. Chajdas, AMD

  • Qun Lin, AMD

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Rex Xu，AMD

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

新的枚举常量

  • VK_AMD_SHADER_EXPLICIT_VERTEX_PARAMETER_EXTENSION_NAME

  • VK_AMD_SHADER_EXPLICIT_VERTEX_PARAMETER_SPEC_VERSION

版本历史

  • 修订版 1, 2016-05-10 (Daniel Rakos)

    • 初始草案

VK_AMD_shader_fragment_mask

名称字符串

VK_AMD_shader_fragment_mask

扩展类型

设备扩展

注册扩展号

138

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2017-08-16

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Aaron Hagan, AMD

  • Daniel Rakos, AMD

  • Timothy Lottes, AMD

描述

此扩展提供对压缩多采样颜色表面中片段掩码的高效读取访问。片段掩码是一个查找表，它将颜色样本与颜色片段值关联起来。

从着色器中，可以使用调用 fragmentMaskFetchAMD 来获取片段掩码，该调用返回一个 uint，其中每个后续的四位指定与颜色样本对应的颜色片段索引，从最低有效位开始。例如，当使用八个颜色样本时，颜色样本 0 的颜色片段索引将在片段掩码的第 0-3 位中，颜色样本 7 的索引将在第 28-31 位中。

然后可以使用相应的片段掩码值，使用 fragmentFetchAMD 着色器函数获取特定颜色样本的颜色片段。

新枚举常量

  • VK_AMD_SHADER_FRAGMENT_MASK_EXTENSION_NAME

  • VK_AMD_SHADER_FRAGMENT_MASK_SPEC_VERSION

新的 SPIR-V 功能

示例

此示例显示了一个着色器，该着色器从多采样压缩表面查询片段掩码，并使用它来查询片段值。

#version 450 core

#extension GL_AMD_shader_fragment_mask: enable

layout(binding = 0) uniform sampler2DMS       s2DMS;
layout(binding = 1) uniform isampler2DMSArray is2DMSArray;

layout(binding = 2, input_attachment_index = 0) uniform usubpassInputMS usubpassMS;

layout(location = 0) out vec4 fragColor;

void main()
{
    vec4 fragOne = vec4(0.0);

    uint fragMask = fragmentMaskFetchAMD(s2DMS, ivec2(2, 3));
    uint fragIndex = (fragMask & 0xF0) >> 4;
    fragOne += fragmentFetchAMD(s2DMS, ivec2(2, 3), 1);

    fragMask = fragmentMaskFetchAMD(is2DMSArray, ivec3(2, 3, 1));
    fragIndex = (fragMask & 0xF0) >> 4;
    fragOne += fragmentFetchAMD(is2DMSArray, ivec3(2, 3, 1), fragIndex);

    fragMask = fragmentMaskFetchAMD(usubpassMS);
    fragIndex = (fragMask & 0xF0) >> 4;
    fragOne += fragmentFetchAMD(usubpassMS, fragIndex);

    fragColor = fragOne;
}

版本历史

  • 修订版 1，2017-08-16 (Aaron Hagan)

    • 初始草案

VK_AMD_shader_image_load_store_lod

名称字符串

VK_AMD_shader_image_load_store_lod

扩展类型

设备扩展

注册扩展号

47

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2017-08-21

交互和外部依赖
IP 状态

没有已知的 IP 声明。

贡献者

  • Dominik Witczak，AMD

  • Qun Lin, AMD

  • Rex Xu，AMD

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

新枚举常量

  • VK_AMD_SHADER_IMAGE_LOAD_STORE_LOD_EXTENSION_NAME

  • VK_AMD_SHADER_IMAGE_LOAD_STORE_LOD_SPEC_VERSION

版本历史

  • 修订版 1，2017-08-21 (Dominik Witczak)

    • 初始草案

VK_AMD_shader_info

名称字符串

VK_AMD_shader_info

扩展类型

设备扩展

注册扩展号

43

修订

1

批准状态

未批准

扩展和版本依赖关系

无

特殊用途
联系方式

其他扩展元数据

上次修改日期

2017-10-09

IP 状态

没有已知的 IP 声明。

贡献者

  • Jaakko Konttinen, AMD

描述

此扩展添加了一种方法来查询关于管道中已编译着色器的某些信息。此信息可能包括着色器反汇编、着色器二进制文件以及有关着色器资源使用情况的各种统计信息。

虽然此扩展提供了一种提取此信息的机制，但此扩展并未指定有关此信息的内容或格式的详细信息，并且可能由供应商在外部提供。

此外，所有信息类型都是可选支持的，用户不应假设每个实现都支持查询每种类型的信息。

新命令

新结构体

新枚举

新枚举常量

  • VK_AMD_SHADER_INFO_EXTENSION_NAME

  • VK_AMD_SHADER_INFO_SPEC_VERSION

示例

此示例提取特定图形管道中片段着色器的寄存器使用情况

extern VkDevice device;
extern VkPipeline gfxPipeline;

PFN_vkGetShaderInfoAMD pfnGetShaderInfoAMD = (PFN_vkGetShaderInfoAMD)vkGetDeviceProcAddr(
    device, "vkGetShaderInfoAMD");

VkShaderStatisticsInfoAMD statistics = {};

size_t dataSize = sizeof(statistics);

if (pfnGetShaderInfoAMD(device,
    gfxPipeline,
    VK_SHADER_STAGE_FRAGMENT_BIT,
    VK_SHADER_INFO_TYPE_STATISTICS_AMD,
    &dataSize,
    &statistics) == VK_SUCCESS)
{
    printf("VGPR usage: %d\n", statistics.resourceUsage.numUsedVgprs);
    printf("SGPR usage: %d\n", statistics.resourceUsage.numUsedSgprs);
}

以下示例继续前面的示例，随后尝试查询并打印有关片段着色器的着色器反汇编

// Query disassembly size (if available)
if (pfnGetShaderInfoAMD(device,
    gfxPipeline,
    VK_SHADER_STAGE_FRAGMENT_BIT,
    VK_SHADER_INFO_TYPE_DISASSEMBLY_AMD,
    &dataSize,
    nullptr) == VK_SUCCESS)
{
    printf("Fragment shader disassembly:\n");

    void* disassembly = malloc(dataSize);

    // Query disassembly and print
    if (pfnGetShaderInfoAMD(device,
        gfxPipeline,
        VK_SHADER_STAGE_FRAGMENT_BIT,
        VK_SHADER_INFO_TYPE_DISASSEMBLY_AMD,
        &dataSize,
        disassembly) == VK_SUCCESS)
    {
        printf((char*)disassembly);
    }

    free(disassembly);
}

版本历史

  • 修订版 1，2017-10-09 (Jaakko Konttinen)

    • 初始修订版

VK_AMD_shader_trinary_minmax

名称字符串

VK_AMD_shader_trinary_minmax

扩展类型

设备扩展

注册扩展号

21

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2016-05-10

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Matthaeus G. Chajdas, AMD

  • Qun Lin, AMD

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Rex Xu，AMD

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

新枚举常量

  • VK_AMD_SHADER_TRINARY_MINMAX_EXTENSION_NAME

  • VK_AMD_SHADER_TRINARY_MINMAX_SPEC_VERSION

版本历史

  • 修订版 1, 2016-05-10 (Daniel Rakos)

    • 初始草案

VK_AMD_texture_gather_bias_lod

名称字符串

VK_AMD_texture_gather_bias_lod

扩展类型

设备扩展

注册扩展号

42

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2017-03-21

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Dominik Witczak，AMD

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Matthaeus G. Chajdas, AMD

  • Qun Lin, AMD

  • Rex Xu，AMD

  • Timothy Lottes, AMD

描述

此扩展添加了两个相关功能。

首先，在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

  • SPV_AMD_texture_gather_bias_lod

其次，该扩展允许应用程序查询哪些格式可以与 SPIR-V 扩展引入的新函数原型一起使用。

新结构体

新枚举常量

  • VK_AMD_TEXTURE_GATHER_BIAS_LOD_EXTENSION_NAME

  • VK_AMD_TEXTURE_GATHER_BIAS_LOD_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_TEXTURE_LOD_GATHER_FORMAT_PROPERTIES_AMD

新的 SPIR-V 功能

示例

struct VkTextureLODGatherFormatPropertiesAMD
{
    VkStructureType sType;
    const void*     pNext;
    VkBool32        supportsTextureGatherLODBiasAMD;
};

// ----------------------------------------------------------------------------------------
// How to detect if an image format can be used with the new function prototypes.
VkPhysicalDeviceImageFormatInfo2   formatInfo;
VkImageFormatProperties2           formatProps;
VkTextureLODGatherFormatPropertiesAMD textureLODGatherSupport;

textureLODGatherSupport.sType = VK_STRUCTURE_TYPE_TEXTURE_LOD_GATHER_FORMAT_PROPERTIES_AMD;
textureLODGatherSupport.pNext = nullptr;

formatInfo.sType  = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2;
formatInfo.pNext  = nullptr;
formatInfo.format = ...;
formatInfo.type   = ...;
formatInfo.tiling = ...;
formatInfo.usage  = ...;
formatInfo.flags  = ...;

formatProps.sType = VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2;
formatProps.pNext = &textureLODGatherSupport;

vkGetPhysicalDeviceImageFormatProperties2(physical_device, &formatInfo, &formatProps);

if (textureLODGatherSupport.supportsTextureGatherLODBiasAMD == VK_TRUE)
{
    // physical device supports SPV_AMD_texture_gather_bias_lod for the specified
    // format configuration.
}
else
{
    // physical device does not support SPV_AMD_texture_gather_bias_lod for the
    // specified format configuration.
}

版本历史

  • 修订版 1，2017-03-21 (Dominik Witczak)

    • 初始草案

VK_ANDROID_external_format_resolve

名称字符串

VK_ANDROID_external_format_resolve

扩展类型

设备扩展

注册扩展号

469

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_ANDROID_external_memory_android_hardware_buffer

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_dynamic_rendering 交互

特殊用途
联系方式
扩展提案

VK_ANDROID_external_format_resolve

其他扩展元数据

上次修改日期

2023-05-03

IP 状态

没有已知的 IP 声明。

贡献者

  • Tobias Hector, AMD

  • Chris Forbes, Google

  • Jan-Harald Fredriksen, Arm

  • Shahbaz Youssefi, Google

  • Matthew Netsch, Qualcomm

  • Tony Zlatsinki，Nvidia

  • Daniel Koch, Nvidia

  • Jeff Leger, Qualcomm

  • Alex Walters, Imagination

  • Andrew Garrard, Imagination

  • Ralph Potter, Samsung

  • Ian Elliott, Google

描述

此扩展允许渲染到具有无法直接在 Vulkan 中表示为可渲染的外部格式的 Android 硬件缓冲区，包括 Y′CBCR 格式。

新结构体

新枚举常量

  • VK_ANDROID_EXTERNAL_FORMAT_RESOLVE_EXTENSION_NAME

  • VK_ANDROID_EXTERNAL_FORMAT_RESOLVE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_FORMAT_RESOLVE_PROPERTIES_ANDROID

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FORMAT_RESOLVE_FEATURES_ANDROID

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FORMAT_RESOLVE_PROPERTIES_ANDROID

如果支持 VK_KHR_dynamic_rendering 或 Vulkan 1.3 版本

版本历史

  • 修订版 1，2023-05-34 (Tobias Hector)

    • 初始版本

VK_ANDROID_external_memory_android_hardware_buffer

名称字符串

VK_ANDROID_external_memory_android_hardware_buffer

扩展类型

设备扩展

注册扩展号

130

修订

5

批准状态

未批准

扩展和版本依赖关系

         VK_KHR_sampler_ycbcr_conversion
        和
         VK_KHR_external_memory
        和
         VK_KHR_dedicated_allocation
    或
     Vulkan 版本 1.1
和
VK_EXT_queue_family_foreign

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_format_feature_flags2 交互

联系方式

其他扩展元数据

上次修改日期

2021-09-30

IP 状态

没有已知的 IP 声明。

贡献者

  • Ray Smith, ARM

  • Lina Versace，谷歌

  • Jesse Hall, Google

  • Tobias Hector, Imagination

  • James Jones, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Matthew Netsch, Qualcomm

  • Andrew Garrard，三星

描述

此扩展允许应用程序将 Vulkan 设备外部创建的 Android AHardwareBuffer 对象导入到 Vulkan 内存对象中，这些对象可以绑定到图像和缓冲区。它还允许从 Vulkan 内存对象导出 AHardwareBuffer，以便与其他操作系统保持对称性。但由于并非所有 AHardwareBuffer 的用法和格式都具有 Vulkan 等效项，因此从 Vulkan 导出提供的功能严格少于在外部创建 AHardwareBuffer 并导入它。

某些 AHardwareBuffer 图像具有实现定义的外部格式，这些格式可能与 Vulkan 格式不对应。采样器 Y′CBCR 转换可以用于从这些图像进行采样，并将它们转换为已知的颜色空间。

新的基本类型

  • AHardwareBuffer

新的命令

新的结构体

如果支持 VK_KHR_format_feature_flags2 或 Vulkan 1.3 版本

新的枚举常量

  • VK_ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_EXTENSION_NAME

  • VK_ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_SPEC_VERSION

  • 扩展 VkExternalMemoryHandleTypeFlagBits

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_ANDROID_HARDWARE_BUFFER_BIT_ANDROID

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_FORMAT_PROPERTIES_ANDROID

    • VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_PROPERTIES_ANDROID

    • VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_USAGE_ANDROID

    • VK_STRUCTURE_TYPE_EXTERNAL_FORMAT_ANDROID

    • VK_STRUCTURE_TYPE_IMPORT_ANDROID_HARDWARE_BUFFER_INFO_ANDROID

    • VK_STRUCTURE_TYPE_MEMORY_GET_ANDROID_HARDWARE_BUFFER_INFO_ANDROID

如果支持 VK_KHR_format_feature_flags2 或 Vulkan 1.3 版本

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_FORMAT_PROPERTIES_2_ANDROID

问题

1) 其他外部内存对象表示为弱类型句柄（例如，Win32 HANDLE 或 POSIX 文件描述符），并且需要一个句柄类型参数以及句柄。AHardwareBuffer 是强类型的，因此命名句柄类型是冗余的。对称性是否足以证明无论如何都要添加句柄类型参数/字段？

已解决：否。在通用处理外部内存对象的地方，已经提供了句柄类型。在我们添加它的地方，必须提供句柄类型值的应用程序代码已经处理了 AHardwareBuffer 特定的命令/结构；额外的对称性不足以使该代码通用。

2) AHardwareBuffer 图像的内部布局以及因此的大小可能取决于没有对应 Vulkan 对等的本机使用标志。我们是否以某种方式将此信息提供给 vkCreateImage，或者允许 vkGetImageMemoryRequirements 报告的分配大小为近似值？

已解决：允许在分配内存时未指定分配大小。对于导出的图像内存，它必须以这种方式工作，因为 AHardwareBuffer 分配发生在 vkAllocateMemory 中，并且内部由单独的 HAL 执行，而不是 Vulkan 实现本身。 vkGetImageSubresourceLayout 也存在类似的问题：布局由分配器 HAL 确定，因此在图像绑定到内存之前是未知的。

3) 使用建议的 Y′CBCR 转换参数对外部格式图像进行采样的结果是否应与在 OpenGL ES 中使用 samplerExternalOES 的结果相同？

已解决：这是可取的，以便从 OpenGL ES 转换为 Vulkan 的应用程序可以在给定相同输入的情况下获得相同的输出。但是，由于在 OpenGL ES 中对 Y′CBCR 图像的采样和转换的定义非常宽松，因此多个实现以不符合 Vulkan 要求的方式进行。修改 OpenGL ES 实现将很困难，并且会更改现有未修改应用程序的输出。仅更改正在修改的应用程序的输出，使开发人员有机会注意到并缓解任何问题。鼓励实现尽可能减少差异，而不会给现有的 OpenGL ES 应用程序带来兼容性问题或违反 Vulkan 要求。

4) 具有 AHARDWAREBUFFER_USAGE_CPU_* 用法的 AHardwareBuffer 是否可以在 Vulkan 中映射？是否可以导出具有此类用法的 AHardwareBuffers？

已解决：可选，并且在 Vulkan 中映射与 AHardwareBuffer_lock 不同。它们的语义不同：在内存中映射是持久的，只是给出内存内容的原始视图，并且不涉及所有权。AHardwareBuffer_lock 使主机可以独占访问缓冲区，它是临时的，并且允许重新格式化复制输入/复制输出。实现不需要为导入的 Android 硬件缓冲区或它们支持的资源支持主机可见的内存类型。如果支持并使用主机可见的内存类型，则可以在 Vulkan 中映射内存，但是这样做会遵循 Vulkan 语义：它只是数据的原始视图，并不意味着所有权（这意味着实现不得在内部调用 AHardwareBuffer_lock 来实现 vkMapMemory，或假设应用程序已执行此操作）。即使 AHardwareBuffer 具有 CPU 使用率，实现也不需要支持 Android 硬件缓冲区支持的线性平铺图像。没有可靠的方法可以在 Vulkan 中分配可以导出到具有 CPU 使用率的 AHardwareBuffer 的内存。

5) Android 可能会随着时间的推移添加新的 AHardwareBuffer 格式和使用标志。可以添加到此扩展中引用它们，还是需要新的扩展？

已解决：此扩展可以记录新的 AHB 格式/用法与现有 Vulkan 特性之间的交互。 不允许添加新的 Vulkan 特性或实现要求。 当添加此额外的文档时，扩展版本号将递增，但版本号并不表示实现支持映射到新 AHardwareBuffer 特性的 Vulkan 内存或资源：对此的支持必须使用 vkGetPhysicalDeviceImageFormatProperties2 查询，或者通过在 Vulkan 之外成功分配使用新特性并具有 GPU 使用标志的 AHardwareBuffer 来暗示。

本质上，这些是添加到新的 Android API 级别的新特性，而不是新的 Vulkan 特性。 此扩展将仅记录现有 Vulkan 特性如何映射到新的 Android 特性。

版本历史

  • 修订版 5，2022-02-04 (Chris Forbes)

    • 描述存储图像支持的标志映射

  • 修订版 4，2021-09-30 (Jon Leech)

  • 修订版 3，2019-08-27 (Jon Leech)

    • 更新修订历史以与 XML 版本号对应

  • 修订版 2，2018-04-09 (Petr Kraus)

    • 标记修复并删除不正确的草案状态

  • 修订版 1，2018-03-04 (Jesse Hall)

    • 初始版本

VK_ARM_pipeline_opacity_micromap

名称字符串

VK_ARM_pipeline_opacity_micromap

扩展类型

设备扩展

注册扩展号

597

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_EXT_opacity_micromap

联系方式
扩展提案

VK_ARM_pipeline_opacity_micromap

其他扩展元数据

上次修改日期

2025-01-07

IP 状态

没有已知的 IP 声明。

贡献者

  • Mathieu Robart, Arm

  • Marius Bjorge, Arm

  • Yaozhong Zhang, Arm

  • Jan-Harald Fredriksen, Arm

描述

不透明度微型映射扩展 VK_EXT_opacity_micromap 支持新的管道创建标志 VK_PIPELINE_CREATE_RAY_TRACING_OPACITY_MICROMAP_BIT_EXT，表示光线追踪管道可以与引用微型映射的加速结构一起使用。 这允许进行可能的优化，预先知道不透明度微型映射可能与管道一起使用。

对于支持具有不透明度微型映射的光线查询的管道（例如图形和计算），不存在等效的标志。 因此，目前不可能优化此类管道以实现无不透明度，例如，当应用程序支持不透明度微型映射但管道不使用时。 这可能会导致性能下降。

此扩展添加了一个新标志 VK_PIPELINE_CREATE_2_DISALLOW_OPACITY_MICROMAP_BIT_ARM，表示管道将不与引用不透明度微型映射的加速结构一起使用，因此允许可能的管道优化。

新结构

新枚举常量

  • VK_ARM_PIPELINE_OPACITY_MICROMAP_EXTENSION_NAME

  • VK_ARM_PIPELINE_OPACITY_MICROMAP_SPEC_VERSION

  • 扩展 VkPipelineCreateFlagBits2

    • VK_PIPELINE_CREATE_2_DISALLOW_OPACITY_MICROMAP_BIT_ARM

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_OPACITY_MICROMAP_FEATURES_ARM

问题

无。

示例

无。

版本历史

  • 修订版 1，2025-01-07 (Mathieu Robart)

    • 初始草案

VK_ARM_render_pass_striped

名称字符串

VK_ARM_render_pass_striped

扩展类型

设备扩展

注册扩展号

425

修订

1

批准状态

未批准

扩展和版本依赖关系

         VK_KHR_get_physical_device_properties2
         或
         Vulkan 版本 1.1
     和
     VK_KHR_synchronization2
或
Vulkan 版本 1.3

联系方式
扩展提案

VK_ARM_render_pass_striped

其他扩展元数据

上次修改日期

2023-11-21

IP 状态

没有已知的 IP 声明。

贡献者

  • Jan-Harald Fredriksen, Arm

  • Lisa Wu, Arm

  • Torbjorn Nilsson, Arm

  • Ying-Chieh Chen, Mediatek

  • Jim Chiu, Mediatek

描述

此扩展添加了将渲染通道实例拆分为条纹的功能，并在每个条纹的渲染完成后获取通知的功能。

新结构

新枚举常量

  • VK_ARM_RENDER_PASS_STRIPED_EXTENSION_NAME

  • VK_ARM_RENDER_PASS_STRIPED_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RENDER_PASS_STRIPED_FEATURES_ARM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RENDER_PASS_STRIPED_PROPERTIES_ARM

    • VK_STRUCTURE_TYPE_RENDER_PASS_STRIPE_BEGIN_INFO_ARM

    • VK_STRUCTURE_TYPE_RENDER_PASS_STRIPE_INFO_ARM

    • VK_STRUCTURE_TYPE_RENDER_PASS_STRIPE_SUBMIT_INFO_ARM

示例

无。

版本历史

  • 修订版 1，2023-11-21

    • 初始修订版

VK_ARM_scheduling_controls

名称字符串

VK_ARM_scheduling_controls

扩展类型

设备扩展

注册扩展号

418

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_ARM_shader_core_builtins

联系方式

其他扩展元数据

上次修改日期

2023-08-23

交互和外部依赖

无

IP 状态

没有已知的 IP 声明。

贡献者

  • Kévin Petit，Arm Ltd.

  • Jan-Harald Fredriksen, Arm Ltd.

  • Mikel Garai, Arm Ltd.

描述

此扩展公开了一系列控制项，用于修改 Arm Mali 设备的调度行为。

新结构

新枚举

新位掩码

新枚举常量

  • VK_ARM_SCHEDULING_CONTROLS_EXTENSION_NAME

  • VK_ARM_SCHEDULING_CONTROLS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_QUEUE_SHADER_CORE_CONTROL_CREATE_INFO_ARM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCHEDULING_CONTROLS_FEATURES_ARM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCHEDULING_CONTROLS_PROPERTIES_ARM

新 SPIR-V 功能

无。

问题

无。

版本历史

  • 修订版 1，2023-08-23 (Kévin Petit)

    • 初始修订版

VK_ARM_shader_core_builtins

名称字符串

VK_ARM_shader_core_builtins

扩展类型

设备扩展

注册扩展号

498

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2022-10-05

交互和外部依赖
贡献者

  • Kevin Petit, Arm Ltd.

  • Jan-Harald Fredriksen, Arm Ltd.

描述

此扩展提供了确定 Arm GPU 上特定设备属性的能力。 它公开了着色器核心数量、可以在着色器核心上运行的最大经线数以及允许调用来识别着色器调用正在哪个核心和经线上执行的着色器内置函数的属性。

此扩展启用了对 SPIR-V CoreBuiltinsARM 功能的支持。

这些属性和内置函数可用于调试或性能优化目的。 一个典型的优化示例是使用 CoreIDARM 来选择使用原子操作的算法中数据结构的每个着色器核心实例，从而减少争用。

新结构

新枚举常量

  • VK_ARM_SHADER_CORE_BUILTINS_EXTENSION_NAME

  • VK_ARM_SHADER_CORE_BUILTINS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_BUILTINS_FEATURES_ARM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_BUILTINS_PROPERTIES_ARM

新的或修改的内置变量

新的 SPIR-V 功能

问题

无。

版本历史

  • 版本 1，2022-10-05 (Kevin Petit)

    • 初始修订版

  • 版本 2，2022-10-26 (Kevin Petit)

    • 添加 shaderCoreMask 属性

VK_ARM_shader_core_properties

名称字符串

VK_ARM_shader_core_properties

扩展类型

设备扩展

注册扩展号

416

修订

1

批准状态

未批准

扩展和版本依赖关系

Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2023-02-07

IP 状态

没有已知的 IP 声明。

贡献者

  • Jan-Harald Fredriksen, Arm Ltd.

描述

此扩展提供了确定 Arm GPU 特定设备性能属性的能力。

它公开了每个着色器核心每个时钟的纹素、像素和融合乘加运算的数量的属性。它可以与 VK_ARM_shader_core_builtins 扩展结合使用，该扩展提供了查询物理设备上着色器核心数量的能力。

新结构

新枚举常量

  • VK_ARM_SHADER_CORE_PROPERTIES_EXTENSION_NAME

  • VK_ARM_SHADER_CORE_PROPERTIES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_ARM

版本历史

  • 版本 1，2023-02-07 (Jan-Harald Fredriksen)

    • 初始草案。

VK_FUCHSIA_buffer_collection

名称字符串

VK_FUCHSIA_buffer_collection

扩展类型

设备扩展

注册扩展号

367

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_FUCHSIA_external_memory
和
     VK_KHR_sampler_ycbcr_conversion
    或
     Vulkan 版本 1.1

API 交互

  • 与 VK_EXT_debug_report 交互

联系方式

其他扩展元数据

上次修改日期

2021-09-23

IP 状态

没有已知的 IP 声明。

贡献者

  • Craig Stout, Google

  • John Bauman, Google

  • John Rosasco, Google

描述

缓冲区集合是一个或多个缓冲区的集合，这些缓冲区作为一个组一起分配，并且都具有相同的属性。这些属性描述了缓冲区的内部表示，例如其维度和内存布局。这确保了所有缓冲区都可以被需要在多个缓冲区之间交换的任务互换使用，例如双缓冲图形渲染。

通过在组件之间共享此类缓冲区集合，关于缓冲区生命周期的通信可以变得更简单和更高效。例如，当内容生产者完成写入缓冲区时，它可以向缓冲区的消费者发送缓冲区索引的消息，而不是传递共享内存的句柄。

在 Fuchsia 上，Sysmem 服务在其设计中使用了缓冲区集合作为核心构造。VK_FUCHSIA_buffer_collection 是 Vulkan 扩展，允许 Vulkan 应用程序与 Fuchsia 上的 Sysmem 服务互操作。

新对象类型

新命令

新结构

新枚举

新位掩码

新枚举常量

  • VK_FUCHSIA_BUFFER_COLLECTION_EXTENSION_NAME

  • VK_FUCHSIA_BUFFER_COLLECTION_SPEC_VERSION

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_BUFFER_COLLECTION_FUCHSIA

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BUFFER_COLLECTION_BUFFER_CREATE_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_BUFFER_COLLECTION_CONSTRAINTS_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_BUFFER_COLLECTION_CREATE_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_BUFFER_COLLECTION_IMAGE_CREATE_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_BUFFER_COLLECTION_PROPERTIES_FUCHSIA

    • VK_STRUCTURE_TYPE_BUFFER_CONSTRAINTS_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_IMAGE_CONSTRAINTS_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_IMAGE_FORMAT_CONSTRAINTS_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_IMPORT_MEMORY_BUFFER_COLLECTION_FUCHSIA

    • VK_STRUCTURE_TYPE_SYSMEM_COLOR_SPACE_FUCHSIA

如果支持 VK_EXT_debug_report

问题

1) 在配置用于约束设置的 VkImageConstraintsInfoFUCHSIA 结构时，是否应该允许 NULL pFormatConstraints 参数？

已解决：否。指定 NULL pFormatConstraints 会导致解释 pImageCreateInfos 数组元素 VkImageCreateInfo::usage 设置与隐含或所需的 VkFormatFeatureFlags 之间的关系的逻辑复杂性。

pFormatConstraints 的显式非 NULL 要求简化了实现和 Vulkan 应用程序的预期隐含逻辑。

版本历史

  • 版本 2，2021-09-23 (John Rosasco)

    • 评审通过

  • 版本 1，2021-03-09 (John Rosasco)

    • 初始修订版

VK_FUCHSIA_external_memory

名称字符串

VK_FUCHSIA_external_memory

扩展类型

设备扩展

注册扩展号

365

修订

1

批准状态

未批准

扩展和版本依赖关系

     VK_KHR_external_memory_capabilities
     和
     VK_KHR_external_memory
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2021-03-01

IP 状态

没有已知的 IP 声明。

贡献者

  • Craig Stout, Google

  • John Bauman, Google

  • John Rosasco, Google

描述

Vulkan 应用程序可能希望导出或导入设备内存句柄到其他逻辑设备、实例或 API，或从其他逻辑设备、实例或 API 导入设备内存句柄。

当不同的子系统需要在内存缓冲区上互操作时，这种内存共享可以消除内存缓冲区的复制。共享内存缓冲区还可以促进更复杂内存操作管道的处理工作负载的更好分配。

新命令

新结构

新枚举常量

  • VK_FUCHSIA_EXTERNAL_MEMORY_EXTENSION_NAME

  • VK_FUCHSIA_EXTERNAL_MEMORY_SPEC_VERSION

  • 扩展 VkExternalMemoryHandleTypeFlagBits

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_ZIRCON_VMO_BIT_FUCHSIA

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMPORT_MEMORY_ZIRCON_HANDLE_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_MEMORY_GET_ZIRCON_HANDLE_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_MEMORY_ZIRCON_HANDLE_PROPERTIES_FUCHSIA

问题

有关更多信息，请参阅 VK_KHR_external_memory 问题列表。

版本历史

  • 版本 1，2021-03-01 (John Rosasco)

    • 初始草案

VK_FUCHSIA_external_semaphore

名称字符串

VK_FUCHSIA_external_semaphore

扩展类型

设备扩展

注册扩展号

366

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_external_semaphore_capabilities
和
VK_KHR_external_semaphore

联系方式

其他扩展元数据

上次修改日期

2021-03-08

IP 状态

没有已知的 IP 声明。

贡献者

  • Craig Stout, Google

  • John Bauman, Google

  • John Rosasco, Google

描述

使用外部内存的应用程序可能希望使用信号量来同步对该内存的访问。此扩展允许应用程序将信号量负载导出到 Zircon 事件句柄以及从 Zircon 事件句柄导入信号量负载。

新命令

新结构

新枚举常量

  • VK_FUCHSIA_EXTERNAL_SEMAPHORE_EXTENSION_NAME

  • VK_FUCHSIA_EXTERNAL_SEMAPHORE_SPEC_VERSION

  • 扩展 VkExternalSemaphoreHandleTypeFlagBits

    • VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_ZIRCON_EVENT_BIT_FUCHSIA

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_ZIRCON_HANDLE_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_SEMAPHORE_GET_ZIRCON_HANDLE_INFO_FUCHSIA

问题

1) 应用程序是否需要关闭 vkGetSemaphoreZirconHandleFUCHSIA 返回的 Zircon 事件句柄？

已解决：是的，除非将其传递回驱动程序实例以导入信号量。成功的 get 调用会将 Zircon 事件句柄的所有权转移给应用程序，而成功的导入会将其转移回驱动程序。销毁原始信号量对象不会关闭 Zircon 事件句柄，也不会删除其对与之关联的底层信号量资源的引用。

版本历史

  • 版本 1，2021-03-08 (John Rosasco)

    • 初始修订版

VK_FUCHSIA_imagepipe_surface

名称字符串

VK_FUCHSIA_imagepipe_surface

扩展类型

实例扩展

注册扩展号

215

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

其他扩展元数据

上次修改日期

2018-07-27

IP 状态

没有已知的 IP 声明。

贡献者

  • Craig Stout, Google

  • Ian Elliott, Google

  • Jesse Hall, Google

描述

VK_FUCHSIA_imagepipe_surface 扩展是一个实例扩展。它提供了一种机制来创建一个 VkSurfaceKHR 对象（由 VK_KHR_surface 扩展定义），该对象引用 Fuchsia imagePipeHandle。

新命令

新结构体

新位掩码

新枚举常量

  • VK_FUCHSIA_IMAGEPIPE_SURFACE_EXTENSION_NAME

  • VK_FUCHSIA_IMAGEPIPE_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMAGEPIPE_SURFACE_CREATE_INFO_FUCHSIA

版本历史

  • 版本 1，2018-07-27 (Craig Stout)

    • 初始草案。

VK_GGP_frame_token

名称字符串

VK_GGP_frame_token

扩展类型

设备扩展

注册扩展号

192

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_swapchain
和
VK_GGP_stream_descriptor_surface

联系方式

  • Jean-Francois Roy jfroy

其他扩展元数据

上次修改日期

2019-01-28

IP 状态

没有已知的 IP 声明。

贡献者

  • Jean-Francois Roy, Google

  • Richard O’Grady, Google

描述

此扩展允许使用 VK_KHR_swapchain 扩展并结合 VK_GGP_stream_descriptor_surface 扩展提供的 Google Games Platform surface 的应用程序将 Google Games Platform 帧令牌与 present 操作关联。

新结构体

新枚举常量

  • VK_GGP_FRAME_TOKEN_EXTENSION_NAME

  • VK_GGP_FRAME_TOKEN_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PRESENT_FRAME_TOKEN_GGP

版本历史

  • 版本 1，2018-11-26 (Jean-Francois Roy)

    • 初始修订版。

VK_GGP_stream_descriptor_surface

名称字符串

VK_GGP_stream_descriptor_surface

扩展类型

实例扩展

注册扩展号

50

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

  • Jean-Francois Roy jfroy

其他扩展元数据

上次修改日期

2019-01-28

IP 状态

没有已知的 IP 声明。

贡献者

  • Jean-Francois Roy, Google

  • Brad Grantham, Google

  • Connor Smith, Google

  • Cort Stratton，Google

  • Hai Nguyen, Google

  • Ian Elliott, Google

  • Jesse Hall, Google

  • Jim Ray, Google

  • Katherine Wu, Google

  • Kaye Mason, Google

  • Kuangye Guo, Google

  • Mark Segal, Google

  • Nicholas Vining, Google

  • Paul Lalonde, Google

  • Richard O’Grady, Google

描述

VK_GGP_stream_descriptor_surface 扩展是一个实例扩展。它提供了一种机制来创建一个 VkSurfaceKHR 对象（由 VK_KHR_surface 扩展定义），该对象引用 Google Games Platform GgpStreamDescriptor。

新命令

新结构体

新位掩码

新枚举常量

  • VK_GGP_STREAM_DESCRIPTOR_SURFACE_EXTENSION_NAME

  • VK_GGP_STREAM_DESCRIPTOR_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_STREAM_DESCRIPTOR_SURFACE_CREATE_INFO_GGP

版本历史

  • 版本 1，2018-11-26 (Jean-Francois Roy)

    • 初始修订版。

VK_GOOGLE_decorate_string

名称字符串

VK_GOOGLE_decorate_string

扩展类型

设备扩展

注册扩展号

225

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2018-07-09

IP 状态

没有已知的 IP 声明。

贡献者

  • Hai Nguyen, Google

  • Neil Henning, AMD

描述

VK_GOOGLE_decorate_string 扩展允许在 SPIR-V 着色器模块中使用 SPV_GOOGLE_decorate_string 扩展。

新枚举常量

  • VK_GOOGLE_DECORATE_STRING_EXTENSION_NAME

  • VK_GOOGLE_DECORATE_STRING_SPEC_VERSION

版本历史

  • 版本 1，2018-07-09 (Neil Henning)

    • 初始草案

VK_GOOGLE_display_timing

名称字符串

VK_GOOGLE_display_timing

扩展类型

设备扩展

注册扩展号

93

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_swapchain

联系方式

其他扩展元数据

上次修改日期

2017-02-14

IP 状态

没有已知的 IP 声明。

贡献者

  • Ian Elliott, Google

  • Jesse Hall, Google

描述

此设备扩展允许使用 VK_KHR_swapchain 扩展的应用程序获取有关演示引擎显示的信息，获取有关每次 present 的时间信息，并安排 present 不早于期望的时间发生。应用程序可以使用它来最小化各种视觉异常（例如，卡顿）。

传统的游戏和实时动画应用程序需要为可呈现图像将呈现给用户时正确放置其几何图形。为此，应用程序需要有关演示引擎显示的各种时间信息。他们需要知道可呈现图像实际呈现的时间以及它们可能呈现的时间。应用程序还需要告知演示引擎不早于给定时间显示图像。这允许应用程序避免卡顿，从而使用户的动画看起来流畅。

此扩展将可变刷新率 (VRR) 显示器视为固定刷新率 (FRR) 显示器。

新命令

新结构体

新枚举常量

  • VK_GOOGLE_DISPLAY_TIMING_EXTENSION_NAME

  • VK_GOOGLE_DISPLAY_TIMING_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PRESENT_TIMES_INFO_GOOGLE

示例

此扩展的示例代码（如 VK_KHR_surface 和 VK_GOOGLE_display_timing 扩展）包含在官方 Khronos SDK 附带的立方体演示中，并且在该位置保持最新（请参阅：https://github.com/KhronosGroup/Vulkan-Tools/blob/main/cube/cube.c ）。

版本历史

  • 版本 1，2017-02-14 (Ian Elliott)

    • 内部修订

VK_GOOGLE_hlsl_functionality1

名称字符串

VK_GOOGLE_hlsl_functionality1

扩展类型

设备扩展

注册扩展号

224

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2018-07-09

IP 状态

没有已知的 IP 声明。

贡献者

  • Hai Nguyen, Google

  • Neil Henning, AMD

描述

VK_GOOGLE_hlsl_functionality1 扩展允许在 SPIR-V 着色器模块中使用 SPV_GOOGLE_hlsl_functionality1 扩展。

新的枚举常量

  • VK_GOOGLE_HLSL_FUNCTIONALITY1_EXTENSION_NAME

  • VK_GOOGLE_HLSL_FUNCTIONALITY1_SPEC_VERSION

  • VK_GOOGLE_HLSL_FUNCTIONALITY_1_EXTENSION_NAME

  • VK_GOOGLE_HLSL_FUNCTIONALITY_1_SPEC_VERSION

版本历史

  • 版本 1，2018-07-09 (Neil Henning)

    • 初始草案

VK_GOOGLE_surfaceless_query

名称字符串

VK_GOOGLE_surfaceless_query

扩展类型

实例扩展

注册扩展号

434

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_surface

特殊用途
联系方式
扩展提案

VK_GOOGLE_surfaceless_query

其他扩展元数据

上次修改日期

2022-08-03

IP 状态

没有已知的 IP 声明。

贡献者

  • Ian Elliott, Google

  • Shahbaz Youssefi, Google

  • James Jones, NVIDIA

描述

此扩展允许 vkGetPhysicalDeviceSurfaceFormatsKHR 和 vkGetPhysicalDeviceSurfacePresentModesKHR 函数接受 VK_NULL_HANDLE 作为它们的 surface 参数，从而允许在不提供表面（surface）的情况下查询潜在的表面格式、颜色空间和呈现模式。类似地，vkGetPhysicalDeviceSurfaceFormats2KHR， vkGetPhysicalDeviceSurfacePresentModes2EXT， 和 vkGetPhysicalDeviceSurfaceCapabilities2KHR 将在 VkPhysicalDeviceSurfaceInfo2KHR::surface 中接受 VK_NULL_HANDLE。这只能在查询结果与表面无关，并且所有呈现操作的隐式目标是单个呈现引擎的平台上支持。

新的枚举常量

  • VK_GOOGLE_SURFACELESS_QUERY_EXTENSION_NAME

  • VK_GOOGLE_SURFACELESS_QUERY_SPEC_VERSION

版本历史

  • 修订版 1，2021-12-14（Shahbaz Youssefi）

    • 内部修订

  • 修订版 2，2022-08-03（Shahbaz Youssefi）

    • 当无表面时，对查询响应的哪些部分进行了精确定义

VK_GOOGLE_user_type

名称字符串

VK_GOOGLE_user_type

扩展类型

设备扩展

注册扩展号

290

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2019-07-09

IP 状态

没有已知的 IP 声明。

贡献者

  • Kaye Mason, Google

  • Hai Nguyen, Google

描述

VK_GOOGLE_user_type 扩展允许在 SPIR-V 着色器模块中使用 SPV_GOOGLE_user_type 扩展。

新的枚举常量

  • VK_GOOGLE_USER_TYPE_EXTENSION_NAME

  • VK_GOOGLE_USER_TYPE_SPEC_VERSION

版本历史

  • 修订版 1，2019-09-07（Kaye Mason）

    • 初始草案

VK_HUAWEI_cluster_culling_shader

名称字符串

VK_HUAWEI_cluster_culling_shader

扩展类型

设备扩展

注册扩展号

405

修订

3

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式
扩展提案

VK_HUAWEI_cluster_culling_shader

其他扩展元数据

上次修改日期

2023-08-16

交互和外部依赖
贡献者

  • Yuchang Wang，华为

  • Juntao Li，华为

  • Pan Gao, Huawei

  • Jie Cao，华为

  • Yunjin Zhang，华为

  • Shujie Zhou，华为

  • Chaojun Wang，华为

  • Jiajun Hu，华为

  • Cong Zhang，华为

描述

集群剔除着色器 (CCS) 类似于现有的计算着色器。它们的主要目的是提供一个执行环境，以便在 GPU 上更有效地执行粗级别的几何剔除和 LOD 选择。

使用计算着色器的传统 2 次 GPU 剔除解决方案有时需要在计算和图形管道之间使用管道屏障来优化性能。可能还需要额外的压缩过程。此扩展解决了这些缺点，允许计算着色器直接向后续的图形管道发出可见集群。

一组新的内置输出变量用于表达可见集群，包括每个集群的着色率。此外，一个新的内置函数用于将这些变量从 CCS 发送到 IA 阶段。IA 阶段可以使用这些变量来获取可见集群的顶点并驱动顶点着色器对这些顶点进行着色。

请注意，CCS 不适用于几何或细分着色器，但 IA 和顶点着色器都将被保留。顶点着色器仍然用于顶点位置着色，而不是直接从计算着色器输出转换后的顶点。这使得 CCS 更适合移动 GPU。

新命令

新结构体

新的枚举常量

  • VK_HUAWEI_CLUSTER_CULLING_SHADER_EXTENSION_NAME

  • VK_HUAWEI_CLUSTER_CULLING_SHADER_SPEC_VERSION

  • 扩展 VkPipelineStageFlagBits2

    • VK_PIPELINE_STAGE_2_CLUSTER_CULLING_SHADER_BIT_HUAWEI

  • 扩展 VkQueryPipelineStatisticFlagBits

    • VK_QUERY_PIPELINE_STATISTIC_CLUSTER_CULLING_SHADER_INVOCATIONS_BIT_HUAWEI

  • 扩展 VkShaderStageFlagBits

    • VK_SHADER_STAGE_CLUSTER_CULLING_BIT_HUAWEI

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CLUSTER_CULLING_SHADER_FEATURES_HUAWEI

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CLUSTER_CULLING_SHADER_PROPERTIES_HUAWEI

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CLUSTER_CULLING_SHADER_VRS_FEATURES_HUAWEI

新的内置变量

新的 SPIR-V 能力

示例代码

GLSL 着色器中集群剔除的示例

#extension GL_HUAWEI_cluster_culling_shader: enable

#define GPU_WARP_SIZE                   32
#define GPU_GROUP_SIZE                  GPU_WARP_SIZE

#define GPU_CLUSTER_PER_INVOCATION      1
#define GPU_CLUSTER_PER_WORKGROUP       (GPU_GROUP_SIZE * GPU_CLUSTER_PER_INVOCATION)

// Number of threads per workgroup
// - 1D only
// - warpsize = 32
layout(local_size_x=GPU_GROUP_SIZE, local_size_y=1, local_size_z=1) in;

#define GPU_DRAW_BUFFER_BINDING             0
#define GPU_INSTANCE_DESCRIPTOR_BINDING     1

struct BoundingSphere
{
  vec3 center;
  float radius;
};

struct InstanceData
{
  mat4 mvp_matrix;                      // mvp matrix.
  vec4 frustum_planes[6];               // six frustum planes
  mat4 model_matrix_transpose_inverse;  // inverse transpose of model matrix.
  vec3 view_origin;                     // view original
};

struct InstanceDescriptor
{
  uint begin;
  uint end;
  uint cluster_count;
  uint debug;
  BoundingSphere sphere;
  InstanceData instance_data;
};

struct DrawElementsCommand{
  uint indexcount;
  uint instanceCount;
  uint firstIndex;
  int  vertexoffset;
  uint firstInstance;
  uint cluster_id;
};

// indexed mode
out gl_PerClusterHUAWEI{
  uint gl_IndexCountHUAWEI;
  uint gl_InstanceCountHUAWEI;
  uint gl_FirstIndexHUAWEI;
  int  gl_VertexOffsetHUAWEI;
  uint gl_FirstInstanceHUAWEI;
  uint gl_ClusterIDHUAWEI;
  uint gl_ClusterShadingRateHUAWEI;
};

layout(binding = GPU_DRAW_BUFFER_BINDING, std430) buffer draw_indirect_ssbo
{
        DrawElementsCommand draw_commands[];
};

layout(binding = GPU_INSTANCE_DESCRIPTOR_BINDING, std430) buffer instance_descriptor_ssbo
{
        InstanceDescriptor instance_descriptors[];
};


float Distance(uint instance_id)
{
    vec3 v = normalize(instance_descriptor[instance_id].sphere.center -
                     instance_descriptor[instance_id].instance_data.view_origin);
    float dist = sqrt(dot(v,v));

    return dist;
}

bool isSphereOutsideFrustum( vec3 sphere_center, float sphere_radius )
{
  bool isInside = false;

  for(int i = 0; i < 6; i++)
  {
      isInside = isInside ||
      (dot(instance_descriptors[instance_id].instance_data.frustum_planes[i].xyz,
      sphere_center) + instance_descriptors[instance_id].instance_data.frustum_planes[i].w <
      sphere_radius);
  }
  return isInside;
}


void main()
{
    // get instance description
    instance_id = gl_GlobalInvocationID.x;
    InstanceDescriptor inst_desc = instance_descriptors[instance_id];

    //instance based culling
    bool render = !isSphereOutsideFrustum(inst_desc.sphere.center, inst_desc.sphere.radius);

    if (render)
    {
        // calculate distance
        float distance = Distance(instance_id);

        // update shading rate built-in variable
        if(distance > 0.7)
            gl_ClusterShadingRateHUAWEI =
                gl_ShadingRateFlag4VerticalPixelsEXT | gl_ShadingRateFlag4HorizontalPixelsEXT;
        else if(distance > 0.3)
            gl_ClusterShadingRateHUAWEI =
                gl_ShadingRateFlag2VerticalPixelsEXT | gl_ShadingRateFlag2HorizontalPixelsEXT;
        else
            gl_ClusterShadingRateHUAWEI = 0;

        // this is a visible cluster, update built-in output variable.
        // in case of indexed mode:
        gl_IndexCountHUAWEI     = draw_commands[cluster_id].indexcount;
        gl_InstanceCountHUAWEI  = draw_commands[cluster_id].instanceCount;
        gl_FirstIndexHUAWEI     = draw_commands[cluster_id].firstIndex;
        gl_VertexOffsetHUAWEI   = draw_commands[cluster_id].vertexoffset;
        gl_FirstInstanceHUAWEI  = draw_commands[cluster_id].firstInstance;
        gl_ClusterIDHUAWEI      = draw_commands[cluster_id].cluster_id;

        // emit built-in output variables as a drawing command to subsequent
        // rendering pipeline.
        dispatchClusterHUAWEI();
    }
}

使用集群剔除着色器创建图形管道的示例

// create a cluster culling shader stage info structure.
VkPipelineShaderStageCreateInfo ccsStageInfo{};
ccsStageInfo.sType = VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO;
ccsStageInfo.stage = VK_SHADER_STAGE_CLUSTER_CULLING_BIT_HUAWEI;
ccsStageInfo.module = clustercullingshaderModule;
ccsStageInfo.pName =  "main";

// pipeline shader stage creation
VkPipelineShaderStageCreateInfo shaderStages[] = { ccsStageInfo, vertexShaderStageInfo, fragmentShaderStageInfo };

// create graphics pipeline
VkGraphicsPipelineCreateInfo pipelineInfo{};
pipelineInfo.sType = VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_CREATE_INFO;
pipelineInfo.stageCount = 3;
pipelineInfo.pStage = shaderStages;
pipelineInfo.pVertexInputState = &vertexInputInfo;
// ...
VkPipeline graphicsPipeline;
VkCreateGraphicsPipelines(device, VK_NULL_HANDLE, 1, &pipelineInfo, nullptr, &graphicsPipeline);

启动集群剔除着色器执行的示例

vkCmdBindPipeline(commandBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS, graphicsPipeline);
vkCmdDrawClusterHUAWEI(commandBuffer, groupCountX, 1, 1);
vkCmdEndRenderPass(commandBuffer);

版本历史

  • 修订版 1，2022-11-18（YuChang Wang）

    • 内部修订

  • 修订版 2，2023-04-02（Jon Leech）

    • 语法编辑。

  • 修订版 3，2023-08-21（YuChang Wang）

    • 添加每个集群的着色率。

VK_HUAWEI_hdr_vivid

名称字符串

VK_HUAWEI_hdr_vivid

扩展类型

设备扩展

注册扩展号

591

修订

1

批准状态

未批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
    或
     Vulkan 版本 1.1
和
VK_KHR_swapchain
和
VK_EXT_hdr_metadata

联系方式

其他扩展元数据

上次修改日期

2024-10-08

IP 状态

没有已知的 IP 声明。

贡献者

  • Juntao Li，华为

  • Pan Gao, Huawei

  • Xiufeng Zhang，华为

  • 林泽辉, 华为

描述

此扩展允许应用程序将 HDR Vivid (T/UWA 005.1-2022) 元数据分配给交换链。

HDR Vivid 是由 UWA（超高清世界协会）发布的 HDR 标准。它定义了从元数据到色调映射，以便更好地保留创作者的意图，并在具有不同显示功能的设备上实现更好的一致性。

新结构

新枚举常量

  • VK_HUAWEI_HDR_VIVID_EXTENSION_NAME

  • VK_HUAWEI_HDR_VIVID_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_HDR_VIVID_DYNAMIC_METADATA_HUAWEI

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HDR_VIVID_FEATURES_HUAWEI

版本历史

  • 版本 1, 2024-10-08 (林泽辉)

    • 初始版本

VK_HUAWEI_invocation_mask

名称字符串

VK_HUAWEI_invocation_mask

扩展类型

设备扩展

注册扩展号

371

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_ray_tracing_pipeline
和
     VK_KHR_synchronization2
    或
     Vulkan 版本 1.3

联系方式
扩展提案

VK_HUAWEI_invocation_mask

其他扩展元数据

上次修改日期

2021-05-27

交互和外部依赖
贡献者

  • 朱云鹏

  • Juntao Li，华为

  • 陈亮, 华为

  • 施绍庄, 华为

  • 褚海龙, 华为

描述

在某些用例中，要追踪的光线可能很稀疏。例如，场景中只有少数区域会反射。向光线追踪命令提供调用掩码图像可能会给硬件提示，在不调用额外通道来压缩光线缓冲的情况下进行某些优化。

新命令

新结构

新枚举常量

  • VK_HUAWEI_INVOCATION_MASK_EXTENSION_NAME

  • VK_HUAWEI_INVOCATION_MASK_SPEC_VERSION

  • 扩展 VkAccessFlagBits2

    • VK_ACCESS_2_INVOCATION_MASK_READ_BIT_HUAWEI

  • 扩展 VkImageUsageFlagBits

    • VK_IMAGE_USAGE_INVOCATION_MASK_BIT_HUAWEI

  • 扩展 VkPipelineStageFlagBits2

    • VK_PIPELINE_STAGE_2_INVOCATION_MASK_BIT_HUAWEI

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INVOCATION_MASK_FEATURES_HUAWEI

示例

RT 掩码在每次 traceRay 之前更新。

步骤 1. 生成 InvocationMask。

//the rt mask image bind as color attachment in the fragment shader
Layout(location = 2) out vec4 outRTmask
vec4 mask = vec4(x,x,x,x);
outRTmask = mask;

步骤 2. 使用 InvocationMask 进行 traceRay

vkCmdBindPipeline(
    commandBuffers[imageIndex],
    VK_PIPELINE_BIND_POINT_RAY_TRACING_KHR, m_rtPipeline);
    vkCmdBindDescriptorSets(commandBuffers[imageIndex],
    VK_PIPELINE_BIND_POINT_RAY_TRACING_NV,
    m_rtPipelineLayout, 0, 1, &m_rtDescriptorSet,
    0, nullptr);

vkCmdBindInvocationMaskHUAWEI(
    commandBuffers[imageIndex],
    InvocationMaskimageView,
    InvocationMaskimageLayout);
    vkCmdTraceRaysKHR(commandBuffers[imageIndex],
    pRaygenShaderBindingTable,
    pMissShaderBindingTable,
    swapChainExtent.width,
    swapChainExtent.height, 1);

版本历史

  • 版本 1, 2021-05-27 (朱云鹏)

    • 初始草案。

VK_HUAWEI_subpass_shading

名称字符串

VK_HUAWEI_subpass_shading

扩展类型

设备扩展

注册扩展号

370

修订

3

批准状态

未批准

扩展和版本依赖关系

         VK_KHR_create_renderpass2
         或
         Vulkan 版本 1.2
     和
     VK_KHR_synchronization2
或
Vulkan 版本 1.3

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2021-06-01

交互和外部依赖
贡献者

  • 王辉龙

  • Juntao Li，华为

  • 吕仁苗, 华为

  • Pan Gao, Huawei

描述

此扩展允许应用程序在渲染通道的子通道中执行子通道着色管线，以便为基于瓦片的延迟渲染和正向+等算法节省内存带宽。子通道着色管线是一个具有计算管线能力的管线，允许从输入附件读取值，并且只允许在独立的子通道内分发。它的工作维度由渲染通道的渲染区域大小定义。其工作组大小（宽度、高度）在宽度或高度上应为 2 的幂，最小值为 8，最大值应由渲染通道附件和采样计数决定，但取决于实现。

子通道着色管线的 GlobalInvocationId.xy 等于同一渲染通道中图形管线的 FragCoord.xy 减去 offset，该 offset 来自 VkRenderPassBeginInfo::renderArea。如果支持 VK_EXT_shader_viewport_index_layer，则 GlobalInvocationId.z 将映射到 Layer。GlobalInvocationId.xy 等于局部工作组的索引乘以局部工作组的大小，加上 LocalInvocationId 和 offset，该 offset 来自 VkRenderPassBeginInfo::renderArea。

此扩展允许子通道的管线绑定点为 VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI。

新命令

新结构

新枚举常量

  • VK_HUAWEI_SUBPASS_SHADING_EXTENSION_NAME

  • VK_HUAWEI_SUBPASS_SHADING_SPEC_VERSION

  • 扩展 VkPipelineBindPoint

    • VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI

  • 扩展 VkPipelineStageFlagBits2

    • VK_PIPELINE_STAGE_2_SUBPASS_SHADER_BIT_HUAWEI

    • VK_PIPELINE_STAGE_2_SUBPASS_SHADING_BIT_HUAWEI

  • 扩展 VkShaderStageFlagBits

    • VK_SHADER_STAGE_SUBPASS_SHADING_BIT_HUAWEI

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBPASS_SHADING_FEATURES_HUAWEI

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBPASS_SHADING_PROPERTIES_HUAWEI

    • VK_STRUCTURE_TYPE_SUBPASS_SHADING_PIPELINE_CREATE_INFO_HUAWEI

示例代码

GLSL 着色器中子通道着色的示例

#extension GL_HUAWEI_subpass_shading: enable
#extension GL_KHR_shader_subgroup_arithmetic: enable

layout(constant_id = 0) const uint tileWidth = 8;
layout(constant_id = 1) const uint tileHeight = 8;
layout(local_size_x_id = 0, local_size_y_id = 1, local_size_z = 1) in;
layout(set=0, binding=0, input_attachment_index=0) uniform subpassInput depth;

void main()
{
  float d = subpassLoad(depth).x;
  float minD = subgroupMin(d);
  float maxD = subgroupMax(d);
}

子通道中子通道着色调度的示例

vkCmdNextSubpass(commandBuffer, VK_SUBPASS_CONTENTS_INLINE);
vkCmdBindPipeline(commandBuffer, VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI, subpassShadingPipeline);
vkCmdBindDescriptorSets(commandBuffer, VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI, subpassShadingPipelineLayout,
  firstSet, descriptorSetCount, pDescriptorSets, dynamicOffsetCount, pDynamicOffsets);
vkCmdSubpassShadingHUAWEI(commandBuffer)
vkCmdEndRenderPass(commandBuffer);

子通道着色渲染通道创建的示例

VkAttachmentDescription2 attachments[] = {
  {
    VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
    0, VK_FORMAT_R8G8B8A8_UNORM, VK_SAMPLE_COUNT_1_BIT,
    VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_DONT_CARE,
    VK_ATTACHMENT_LOAD_OP_DONT_CARE, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
    VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL
  },
  {
    VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
    0, VK_FORMAT_R8G8B8A8_UNORM, VK_SAMPLE_COUNT_1_BIT,
    VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_DONT_CARE,
    VK_ATTACHMENT_LOAD_OP_DONT_CARE, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
    VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL
  },
  {
    VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
    0, VK_FORMAT_R8G8B8A8_UNORM, VK_SAMPLE_COUNT_1_BIT,
    VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_DONT_CARE,
    VK_ATTACHMENT_LOAD_OP_DONT_CARE, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
    VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL
  },
  {
    VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
    0, VK_FORMAT_D24_UNORM_S8_UINT, VK_SAMPLE_COUNT_1_BIT,
    VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_DONT_CARE,
    VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
    VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL
  },
  {
    VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
    0, VK_FORMAT_R8G8B8A8_UNORM, VK_SAMPLE_COUNT_1_BIT,
    VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_STORE,
    VK_ATTACHMENT_LOAD_OP_DONT_CARE, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
    VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL
  }
};

VkAttachmentReference2 gBufferAttachmentReferences[] = {
  { VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 0, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT },
  { VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 1, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT },
  { VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 2, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT }
};
VkAttachmentReference2 gBufferDepthStencilAttachmentReferences =
  { VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 3, VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_DEPTH_BIT|VK_IMAGE_ASPECT_STENCIL_BIT };
VkAttachmentReference2 depthInputAttachmentReferences[] = {
  { VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 3, VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL, VK_IMAGE_ASPECT_DEPTH_BIT|VK_IMAGE_ASPECT_STENCIL_BIT };
};
VkAttachmentReference2 preserveAttachmentReferences[] = {
  { VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 0, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT },
  { VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 1, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT },
  { VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 2, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT },
  { VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 3, VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_DEPTH_BIT|VK_IMAGE_ASPECT_STENCIL_BIT }
}; // G buffer including depth/stencil
VkAttachmentReference2 colorAttachmentReferences[] = {
  { VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 4, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT }
};
VkAttachmentReference2 resolveAttachmentReference =
  { VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 4, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT };

VkSubpassDescription2 subpasses[] = {
  {
    VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_2, NULL, 0, VK_PIPELINE_BIND_POINT_GRAPHICS, 0,
    0, NULL, // input
    sizeof(gBufferAttachmentReferences)/sizeof(gBufferAttachmentReferences[0]), gBufferAttachmentReferences, // color
    NULL, &gBufferDepthStencilAttachmentReferences, // resolve & DS
    0, NULL
  },
  {
    VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_2, NULL, 0, VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI , 0,
    sizeof(depthInputAttachmentReferences)/sizeof(depthInputAttachmentReferences[0]), depthInputAttachmentReferences, // input
    0, NULL, // color
    NULL, NULL, // resolve & DS
    sizeof(preserveAttachmentReferences)/sizeof(preserveAttachmentReferences[0]), preserveAttachmentReferences,
  },
  {
    VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_2, NULL, 0, VK_PIPELINE_BIND_POINT_GRAPHICS, 0,
    sizeof(gBufferAttachmentReferences)/sizeof(gBufferAttachmentReferences[0]), gBufferAttachmentReferences, // input
    sizeof(colorAttachmentReferences)/sizeof(colorAttachmentReferences[0]), colorAttachmentReferences, // color
    &resolveAttachmentReference, &gBufferDepthStencilAttachmentReferences, // resolve & DS
    0, NULL
  },
};

VkMemoryBarrier2KHR fragmentToSubpassShading = {
  VK_STRUCTURE_TYPE_MEMORY_BARRIER_2_KHR, NULL,
  VK_PIPELINE_STAGE_2_FRAGMENT_SHADER_BIT_KHR, VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT|VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT,
  VK_PIPELINE_STAGE_2_SUBPASS_SHADER_BIT_HUAWEI, VK_ACCESS_INPUT_ATTACHMENT_READ_BIT
};

VkMemoryBarrier2KHR subpassShadingToFragment = {
  VK_STRUCTURE_TYPE_MEMORY_BARRIER_2_KHR, NULL,
  VK_PIPELINE_STAGE_2_SUBPASS_SHADER_BIT_HUAWEI, VK_ACCESS_SHADER_WRITE_BIT,
  VK_PIPELINE_STAGE_2_FRAGMENT_SHADER_BIT_KHR, VK_ACCESS_SHADER_READ_BIT
};

VkSubpassDependency2 dependencies[] = {
  {
    VK_STRUCTURE_TYPE_SUBPASS_DEPENDENCY_2, &fragmentToSubpassShading,
    0, 1,
    0, 0, 0, 0,
    0, 0
  },
  {
    VK_STRUCTURE_TYPE_SUBPASS_DEPENDENCY_2, &subpassShadingToFragment,
    1, 2,
    0, 0, 0, 0,
    0, 0
  },
};

VkRenderPassCreateInfo2 renderPassCreateInfo = {
  VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO_2, NULL, 0,
    sizeof(attachments)/sizeof(attachments[0]), attachments,
    sizeof(subpasses)/sizeof(subpasses[0]), subpasses,
    sizeof(dependencies)/sizeof(dependencies[0]), dependencies,
    0, NULL
};
VKRenderPass renderPass;
vkCreateRenderPass2(device, &renderPassCreateInfo, NULL, &renderPass);

子通道着色管线创建的示例

VkExtent2D maxWorkgroupSize;

VkSpecializationMapEntry subpassShadingConstantMapEntries[] = {
  { 0, 0 * sizeof(uint32_t), sizeof(uint32_t) },
  { 1, 1 * sizeof(uint32_t), sizeof(uint32_t) }
};

VkSpecializationInfo subpassShadingConstants = {
  2, subpassShadingConstantMapEntries,
  sizeof(VkExtent2D), &maxWorkgroupSize
};

VkSubpassShadingPipelineCreateInfoHUAWEI subpassShadingPipelineCreateInfo {
  VK_STRUCTURE_TYPE_SUBPASSS_SHADING_PIPELINE_CREATE_INFO_HUAWEI, NULL,
  renderPass, 1
};

VkPipelineShaderStageCreateInfo subpassShadingPipelineStageCreateInfo {
  VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO, NULL,
  0, VK_SHADER_STAGE_SUBPASS_SHADING_BIT_HUAWEI,
  shaderModule, "main",
  &subpassShadingConstants
};

VkComputePipelineCreateInfo subpassShadingComputePipelineCreateInfo = {
  VK_STRUCTURE_TYPE_COMPUTE_PIPELINE_CREATE_INFO, &subpassShadingPipelineCreateInfo,
  0, &subpassShadingPipelineStageCreateInfo,
  pipelineLayout, basePipelineHandle, basePipelineIndex
};

VKPipeline pipeline;

vkGetDeviceSubpassShadingMaxWorkgroupSizeHUAWEI(device, renderPass, &maxWorkgroupSize);
vkCreateComputePipelines(device, pipelineCache, 1, &subpassShadingComputePipelineCreateInfo, NULL, &pipeline);

版本历史

  • 版本 3, 2023-06-19 (高攀)

    • 将 VK_PIPELINE_STAGE_2_SUBPASS_SHADING_BIT_HUAWEI 重命名为 VK_PIPELINE_STAGE_2_SUBPASS_SHADER_BIT_HUAWEI，以便更好地与其他管线阶段的命名对齐

  • 版本 2, 2021-06-28 (王辉龙)

    • 将 vkGetSubpassShadingMaxWorkgroupSizeHUAWEI 更改为 vkGetDeviceSubpassShadingMaxWorkgroupSizeHUAWEI，以解决问题 pub1564

  • 版本 1, 2020-12-15 (王辉龙)

    • 初始草案。

VK_IMG_filter_cubic

名称字符串

VK_IMG_filter_cubic

扩展类型

设备扩展

注册扩展号

16

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2016-02-23

贡献者

  • Tobias Hector, Imagination Technologies

描述

VK_IMG_filter_cubic 向 Vulkan 添加了一种额外的高质量立方体过滤模式，它使用 Catmull-Rom 双三次过滤器。执行这种过滤可以使用 16 个采样点和一些指令在着色器中完成，但这可能效率不高。立方体过滤模式通过使用固定的纹理采样功能暴露优化的、高质量的纹理采样。

新的枚举常量

  • VK_IMG_FILTER_CUBIC_EXTENSION_NAME

  • VK_IMG_FILTER_CUBIC_SPEC_VERSION

  • 扩展 VkFilter

    • VK_FILTER_CUBIC_IMG

  • 扩展 VkFormatFeatureFlagBits

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_CUBIC_BIT_IMG

示例

创建一个采样器，对放大和缩小都使用新的过滤器

    VkSamplerCreateInfo createInfo =
    {
        .sType = VK_STRUCTURE_TYPE_SAMPLER_CREATE_INFO,
        // Other members set to application-desired values
    };

    createInfo.magFilter = VK_FILTER_CUBIC_IMG;
    createInfo.minFilter = VK_FILTER_CUBIC_IMG;

    VkSampler sampler;
    VkResult result = vkCreateSampler(
        device,
        &createInfo,
        &sampler);

版本历史

  • 修订版 1，2016-02-23 (Tobias Hector)

    • 初始版本

VK_IMG_relaxed_line_rasterization

名称字符串

VK_IMG_relaxed_line_rasterization

扩展类型

设备扩展

注册扩展号

111

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

其他扩展元数据

上次修改日期

2023-10-22

IP 状态

没有已知的 IP 声明。

贡献者

  • James Fitzpatrick，Imagination

  • Andrew Garrard, Imagination

  • Alex Walters, Imagination

描述

OpenGL 指定实现应该使用菱形退出规则（Bresenham 算法的略微修改版本）来光栅化直线。为了实现 OpenGL，一些实现具有设备级的兼容模式，可以根据 OpenGL 规范光栅化直线。

此扩展允许 OpenGL 模拟层启用此类实现的 OpenGL 兼容直线光栅化模式。

新的结构体

新的枚举常量

  • VK_IMG_RELAXED_LINE_RASTERIZATION_EXTENSION_NAME

  • VK_IMG_RELAXED_LINE_RASTERIZATION_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RELAXED_LINE_RASTERIZATION_FEATURES_IMG

问题

无。

版本历史

  • 修订版 1，2023-10-22 (James Fitzpatrick)

    • 初始版本

VK_INTEL_performance_query

名称字符串

VK_INTEL_performance_query

扩展类型

设备扩展

注册扩展号

211

修订

2

批准状态

未批准

扩展和版本依赖关系

无

特殊用途
联系方式

其他扩展元数据

上次修改日期

2018-05-16

IP 状态

没有已知的 IP 声明。

贡献者

  • Lionel Landwerlin, Intel

  • Piotr Maciejewski, Intel

描述

此扩展允许应用程序捕获性能数据，以便由外部应用程序或库进行解释。

此类库位于：https://github.com/intel/metrics-discovery

诸如 Graphics Performance Analyzers 等性能分析工具使用此扩展和 metrics-discovery 库以人类可读的方式呈现数据。

新的对象类型

新的命令

新的结构体

新的联合体

新的枚举

新的枚举常量

  • VK_INTEL_PERFORMANCE_QUERY_EXTENSION_NAME

  • VK_INTEL_PERFORMANCE_QUERY_SPEC_VERSION

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_PERFORMANCE_CONFIGURATION_INTEL

  • 扩展 VkQueryType

    • VK_QUERY_TYPE_PERFORMANCE_QUERY_INTEL

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_INITIALIZE_PERFORMANCE_API_INFO_INTEL

    • VK_STRUCTURE_TYPE_PERFORMANCE_CONFIGURATION_ACQUIRE_INFO_INTEL

    • VK_STRUCTURE_TYPE_PERFORMANCE_MARKER_INFO_INTEL

    • VK_STRUCTURE_TYPE_PERFORMANCE_OVERRIDE_INFO_INTEL

    • VK_STRUCTURE_TYPE_PERFORMANCE_STREAM_MARKER_INFO_INTEL

    • VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO_INTEL

    • VK_STRUCTURE_TYPE_QUERY_POOL_PERFORMANCE_QUERY_CREATE_INFO_INTEL

示例代码

// A previously created device
VkDevice device;

// A queue derived from the device
VkQueue queue;

VkInitializePerformanceApiInfoINTEL performanceApiInfoIntel = {
  VK_STRUCTURE_TYPE_INITIALIZE_PERFORMANCE_API_INFO_INTEL,
  NULL,
  NULL
};

vkInitializePerformanceApiINTEL(
  device,
  &performanceApiInfoIntel);

VkQueryPoolPerformanceQueryCreateInfoINTEL queryPoolIntel = {
  VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO_INTEL,
  NULL,
  VK_QUERY_POOL_SAMPLING_MODE_MANUAL_INTEL,
};

VkQueryPoolCreateInfo queryPoolCreateInfo = {
  VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO,
  &queryPoolIntel,
  0,
  VK_QUERY_TYPE_PERFORMANCE_QUERY_INTEL,
  1,
  0
};

VkQueryPool queryPool;

VkResult result = vkCreateQueryPool(
  device,
  &queryPoolCreateInfo,
  NULL,
  &queryPool);

assert(VK_SUCCESS == result);

// A command buffer we want to record counters on
VkCommandBuffer commandBuffer;

VkCommandBufferBeginInfo commandBufferBeginInfo = {
  VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO,
  NULL,
  VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT,
  NULL
};

result = vkBeginCommandBuffer(commandBuffer, &commandBufferBeginInfo);

assert(VK_SUCCESS == result);

vkCmdResetQueryPool(
  commandBuffer,
  queryPool,
  0,
  1);

vkCmdBeginQuery(
  commandBuffer,
  queryPool,
  0,
  0);

// Perform the commands you want to get performance information on
// ...

// Perform a barrier to ensure all previous commands were complete before
// ending the query
vkCmdPipelineBarrier(commandBuffer,
  VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT,
  VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT,
  0,
  0,
  NULL,
  0,
  NULL,
  0,
  NULL);

vkCmdEndQuery(
  commandBuffer,
  queryPool,
  0);

result = vkEndCommandBuffer(commandBuffer);

assert(VK_SUCCESS == result);

VkPerformanceConfigurationAcquireInfoINTEL performanceConfigurationAcquireInfo = {
  VK_STRUCTURE_TYPE_PERFORMANCE_CONFIGURATION_ACQUIRE_INFO_INTEL,
  NULL,
  VK_PERFORMANCE_CONFIGURATION_TYPE_COMMAND_QUEUE_METRICS_DISCOVERY_ACTIVATED_INTEL
};

VkPerformanceConfigurationINTEL performanceConfigurationIntel;

result = vkAcquirePerformanceConfigurationINTEL(
  device,
  &performanceConfigurationAcquireInfo,
  &performanceConfigurationIntel);

vkQueueSetPerformanceConfigurationINTEL(queue, performanceConfigurationIntel);

assert(VK_SUCCESS == result);

// Submit the command buffer and wait for its completion
// ...

result = vkReleasePerformanceConfigurationINTEL(
  device,
  performanceConfigurationIntel);

assert(VK_SUCCESS == result);

// Get the report size from metrics-discovery's QueryReportSize

result = vkGetQueryPoolResults(
  device,
  queryPool,
  0, 1, QueryReportSize,
  data, QueryReportSize, 0);

assert(VK_SUCCESS == result);

// The data can then be passed back to metrics-discovery from which
// human readable values can be queried.

版本历史

  • 修订版 2，2020-03-06 (Lionel Landwerlin)

    • 将 VkQueryPoolCreateInfoINTEL 重命名为 VkQueryPoolPerformanceQueryCreateInfoINTEL

  • 修订版 1，2018-05-16 (Lionel Landwerlin)

    • 初始修订版

VK_INTEL_shader_integer_functions2

名称字符串

VK_INTEL_shader_integer_functions2

扩展类型

设备扩展

注册扩展号

210

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2019-04-30

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Ian Romanick, Intel

  • Ben Ashbaugh, Intel

描述

此扩展为图形着色器中使用的 SPIR-V 添加了对几个新的整数指令的支持。许多这些指令在内核环境中具有预先存在的对应物。

添加的整数函数由 SPV_INTEL_shader_integer_functions2 SPIR-V 扩展定义，并且可以与 GL_INTEL_shader_integer_functions2 GLSL 扩展一起使用。

新的结构体

新的枚举常量

  • VK_INTEL_SHADER_INTEGER_FUNCTIONS_2_EXTENSION_NAME

  • VK_INTEL_SHADER_INTEGER_FUNCTIONS_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INTEGER_FUNCTIONS_2_FEATURES_INTEL

新的 SPIR-V 功能

版本历史

  • 修订版 1，2019-04-30 (Ian Romanick)

    • 初始草案

VK_LUNARG_direct_driver_loading

名称字符串

VK_LUNARG_direct_driver_loading

扩展类型

实例扩展

注册扩展号

460

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式
扩展提案

VK_LUNARG_direct_driver_loading

其他扩展元数据

上次修改日期

2022-11-29

贡献者

  • Charles Giessen, LunarG

描述

此扩展为应用程序提供了一种向实现添加驱动程序的机制。这允许驱动程序包含在应用程序中而无需安装，并且能够在任何执行环境中使用，例如以提升的权限运行的进程。

新的结构体

新的函数指针

新的枚举

新的位掩码

新的枚举常量

  • VK_LUNARG_DIRECT_DRIVER_LOADING_EXTENSION_NAME

  • VK_LUNARG_DIRECT_DRIVER_LOADING_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DIRECT_DRIVER_LOADING_INFO_LUNARG

    • VK_STRUCTURE_TYPE_DIRECT_DRIVER_LOADING_LIST_LUNARG

版本历史

  • 修订版 1，2022-11-29 (Charles Giessen)

    • 初始版本

VK_MESA_image_alignment_control

名称字符串

VK_MESA_image_alignment_control

扩展类型

设备扩展

注册扩展号

576

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

其他扩展元数据

上次修改日期

2024-05-03

IP 状态

没有已知的 IP 声明。

贡献者

  • Hans-Kristian Arntzen, Valve

描述

此扩展允许应用程序请求比实现通常要求的图像对齐方式更窄的对齐方式。某些实现内部支持 VK_IMAGE_TILING_OPTIMAL 中的多种图像布局，每种布局具有不同的对齐要求和性能权衡。在某些 API 分层用例（例如 D3D12）中，能够控制对齐方式是有益的，因为某些放置资源的对齐方式保证会被支持，而模拟该期望需要不必要的分配填充。

VkImageAlignmentControlCreateInfoMESA 可以 链接到 VkImageCreateInfo，请求对齐方式不超过提供的对齐方式。如果对于给定的 VkImageCreateInfo 不支持请求的对齐方式，则可能返回更大的对齐方式。

虽然理论上可以使用 VK_EXT_image_drm_format_modifier 来实现类似的功能，但这并不是使用该扩展的预期方式。格式修改器通常用于外部可共享的图像，并且不具有平台可移植性。仅仅为了降低对齐方式而使用它也是一个繁琐的 API。

新结构

新枚举常量

  • VK_MESA_IMAGE_ALIGNMENT_CONTROL_EXTENSION_NAME

  • VK_MESA_IMAGE_ALIGNMENT_CONTROL_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMAGE_ALIGNMENT_CONTROL_CREATE_INFO_MESA

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_ALIGNMENT_CONTROL_FEATURES_MESA

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_ALIGNMENT_CONTROL_PROPERTIES_MESA

版本历史

  • 修订版 1，2024-04-05 (Hans-Kristian Arntzen)

    • 初始规范

VK_MSFT_layered_driver

名称字符串

VK_MSFT_layered_driver

扩展类型

设备扩展

注册扩展号

531

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式
扩展提案

VK_MSFT_layered_driver

其他扩展元数据

上次修改日期

2023-06-21

IP 状态

没有已知的 IP 声明。

贡献者

  • Jesse Natalie, Microsoft

描述

此扩展添加了新的物理设备属性，以允许应用程序和 Vulkan ICD 加载器了解物理设备何时被实现为在另一个底层 API 之上的分层驱动程序。

新结构

新枚举

新枚举常量

  • VK_MSFT_LAYERED_DRIVER_EXTENSION_NAME

  • VK_MSFT_LAYERED_DRIVER_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LAYERED_DRIVER_PROPERTIES_MSFT

示例

无。

版本历史

  • 修订版 1，2023-06-21 (Jesse Natalie)

    • 初始修订版

VK_NN_vi_surface

名称字符串

VK_NN_vi_surface

扩展类型

实例扩展

注册扩展号

63

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

  • Mathias Heyer mheyer

其他扩展元数据

上次修改日期

2016-12-02

IP 状态

没有已知的 IP 声明。

贡献者

  • Mathias Heyer，NVIDIA

  • Michael Chock, NVIDIA

  • Yasuhiro Yoshioka, Nintendo

  • Daniel Koch, NVIDIA

描述

VK_NN_vi_surface 扩展是一个实例扩展。它提供了一种创建与 nn::vi::Layer 关联的 VkSurfaceKHR 对象（由 VK_KHR_surface 扩展定义）的机制。

新命令

新结构

新位掩码

新枚举常量

  • VK_NN_VI_SURFACE_EXTENSION_NAME

  • VK_NN_VI_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_VI_SURFACE_CREATE_INFO_NN

问题

1) VI 是否需要一种方法来查询特定物理设备（和队列族？）与特定 VI 显示器之间的兼容性？

已解决：否。目前总是假设设备和显示器始终兼容。

2) VkViSurfaceCreateInfoNN::pWindow 旨在存储 nn::vi::NativeWindowHandle，但其声明的类型是一个裸 void* 来存储窗口句柄。为什么存在差异？

已解决：这是为了 C 兼容性。VI 本机窗口句柄类型的定义在 nn::vi C++ 命名空间内定义。这会阻止其在 C 源文件中使用。nn::vi::NativeWindowHandle 始终定义为 void*，因此此扩展使用 void* 来匹配。

版本历史

  • 修订版 1，2016-12-2 (Michael Chock)

    • 初始草案。

VK_NV_acquire_winrt_display

名称字符串

VK_NV_acquire_winrt_display

扩展类型

设备扩展

注册扩展号

346

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_EXT_direct_mode_display

联系方式

其他扩展元数据

上次修改日期

2020-09-29

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Juliano, NVIDIA

描述

此扩展允许应用程序在 Windows 10 上独占控制显示器，前提是该显示器尚未被合成器控制。合成器的示例包括 Windows 桌面合成器、使用此 Vulkan 扩展的其他应用程序以及使用 “Acquire” 的应用程序，通过诸如 “DisplayTarget”，使用诸如 “WinRT” 命令（例如 “winrt::Windows::Devices::Display::Core::DisplayManager.TryAcquireTarget()”）。

当获得控制权后，应用程序将对显示器具有独占访问权，直到控制权被释放或应用程序终止。如果不同的应用程序已经获取了显示器，则应用程序的获取尝试将被拒绝。

新命令

新枚举常量

  • VK_NV_ACQUIRE_WINRT_DISPLAY_EXTENSION_NAME

  • VK_NV_ACQUIRE_WINRT_DISPLAY_SPEC_VERSION

问题

1) 此扩展的平台子字符串应该是什么

已解决：平台子字符串是 “Winrt”。

子字符串 “Winrt” 与暴露获取和释放功能的操作系统 API 被称为 “WinRT” 的事实相匹配。

子字符串 “Win32” 是错误的，因为相关的 “WinRT” API 明确不是“Win32” API。“WinRT” 是与 “Win32” API 系列竞争的 API 系列。

子字符串 “Windows” 不是最优的，因为 Windows 平台上可能存在多个相关 API。首选使用更具体的子字符串 “Winrt”。

2) vkAcquireWinrtDisplayNV 应该接受 WinRT DisplayTarget 作为输入，还是 Vulkan 显示句柄作为输入？

已解决：Vulkan 显示句柄。这与 vkAcquireXlibDisplayEXT 的设计相符。

3) 获取命令应该命名为平台无关的 “vkAcquireDisplayNV”，还是平台相关的 “vkAcquireWinrtDisplayNV”？

已解决：添加一个平台相关的命令。

获取命令的输入都是 Vulkan 类型。没有 WinRT 类型。这为 winrt 扩展定义一个平台无关的获取命令提供了可能性。

X11 获取命令确实需要接受一个平台相关的参数。这可以通过向平台无关的获取命令添加一个参数结构体来处理，平台相关的类型可以通过 pNext 指针链接到该结构体。

主流观点认为，创建一个仅在 Windows 10 平台上使用，而不在 X11 平台上使用的第二个平台无关函数是很奇怪的。由于无论如何都需要一个 Windows 10 平台相关的命令来在 vkDisplayKHR 和平台原生句柄之间进行转换，因此意见是创建一个平台相关的获取函数。

4) 用于标识显示的 vkGetWinrtDisplayNV 参数应该命名为 “deviceRelativeId” 还是 “adapterRelativeId”？

已解决：WinRT 名称为 “AdapterRelativeId”。名称 “adapter” 是 Windows 中 Vulkan “物理设备” 的类比。Vulkan 已经有先例使用名称 deviceLUID 来表示 Windows API 称之为 “AdapterLuid” 的概念。与此先例保持一致，选择名称 “deviceRelativeId”。

5) vkAcquireWinrtDisplayNV 是否会导致 Windows 桌面合成器释放显示？

已解决：否。vkAcquireWinrtDisplayNV 本身不会导致 Windows 桌面合成器释放显示。此操作必须在 Vulkan 之外执行。

从 Windows 10 2004 版本开始，可以通过使用“显示设置”控制面板的“高级显示设置”子页面来导致 Windows 桌面合成器释放显示。请参阅 https://docs.microsoft.com/en-us/windows-hardware/drivers/display/specialized-monitors

6) 在哪里可以找到有关 Windows 10 自定义合成器的其他信息？

已解决：相关参考如下。

根据微软关于 “构建自定义合成器” 的文档，编写自定义合成器的能力不是全屏桌面窗口的替代品。该功能用于编写驱动专用硬件的合成器应用程序。

只有某些版本的 Windows 10 支持自定义合成器，“此处有记录”。产品类型可以从 Windows 10 查询。请参阅 https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getproductinfo

版本历史

  • 修订版 1，2020-09-29（Jeff Juliano）

    • 初始草案

VK_NV_clip_space_w_scaling

名称字符串

VK_NV_clip_space_w_scaling

扩展类型

设备扩展

注册扩展号

88

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2017-02-15

贡献者

  • Eric Werness, NVIDIA

  • Kedarnath Thangudu，NVIDIA

描述

虚拟现实 (VR) 应用程序通常涉及一个后处理步骤，对渲染图像应用 “桶形” 失真，以校正 VR 设备中光学器件引入的 “枕形” 失真。与中心相比，桶形失真图像在边缘处的分辨率较低。由于原始图像以高分辨率渲染，该分辨率在整个图像上是均匀的，因此边缘附近的许多像素没有到达最终的后处理图像。

此扩展提供了一种以非均匀分辨率渲染 VR 场景的机制，特别是分辨率从中心向边缘线性下降的分辨率。这是通过在透视分割之前缩放剪辑空间中顶点的 w 坐标来实现的。顶点的剪辑空间 w 坐标可以根据 x 和 y 坐标偏移，如下所示：

w' = w + Ax + By

在视口位置缩放的预期用例中，应用程序应使用一组四个视口，每个视口对应笛卡尔坐标系的四个象限之一。每个视口都设置为图像的尺寸，但会被剪裁到它所代表的象限。应用程序应指定上述 w 缩放方程的 A 和 B 系数，对于每个视口，它们的值相同，但符号不同。A 和 B 的符号应与它们所代表的象限的 x 和 y 的符号匹配，以便 w' 的值始终大于或等于整个图像的原始 w 值。由于 w 的偏移量 (Ax + By) 始终为正，并且随着 x 和 y 的绝对值增加而增加，因此有效分辨率将从图像中心到边缘线性下降。

新命令

新结构体

新枚举常量

  • VK_NV_CLIP_SPACE_W_SCALING_EXTENSION_NAME

  • VK_NV_CLIP_SPACE_W_SCALING_SPEC_VERSION

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_VIEWPORT_W_SCALING_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_W_SCALING_STATE_CREATE_INFO_NV

问题

1) 管道结构体名称是否太长？

已解决：它符合命名约定。

2) 将 W 缩放部分单独分开还是合并到坐标变换中？

已解决：暂时将其保留为单独的部分。

示例

VkViewport viewports[4];
VkRect2D scissors[4];
VkViewportWScalingNV scalings[4];

for (int i = 0; i < 4; i++) {
    int x = (i & 2) ? 0 : currentWindowWidth / 2;
    int y = (i & 1) ? 0 : currentWindowHeight / 2;

    viewports[i].x = 0;
    viewports[i].y = 0;
    viewports[i].width = currentWindowWidth;
    viewports[i].height = currentWindowHeight;
    viewports[i].minDepth = 0.0f;
    viewports[i].maxDepth = 1.0f;

    scissors[i].offset.x = x;
    scissors[i].offset.y = y;
    scissors[i].extent.width = currentWindowWidth/2;
    scissors[i].extent.height = currentWindowHeight/2;

    const float factor = 0.15;
    scalings[i].xcoeff = ((i & 2) ? -1.0 : 1.0) * factor;
    scalings[i].ycoeff = ((i & 1) ? -1.0 : 1.0) * factor;
}

VkPipelineViewportWScalingStateCreateInfoNV vpWScalingStateInfo = { VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_W_SCALING_STATE_CREATE_INFO_NV };

vpWScalingStateInfo.viewportWScalingEnable = VK_TRUE;
vpWScalingStateInfo.viewportCount = 4;
vpWScalingStateInfo.pViewportWScalings = &scalings[0];

VkPipelineViewportStateCreateInfo vpStateInfo = { VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_STATE_CREATE_INFO };
vpStateInfo.viewportCount = 4;
vpStateInfo.pViewports = &viewports[0];
vpStateInfo.scissorCount = 4;
vpStateInfo.pScissors = &scissors[0];
vpStateInfo.pNext = &vpWScalingStateInfo;

用于从 w 缩放纹理读取的示例着色器

// Vertex Shader
// Draw a triangle that covers the whole screen
const vec4 positions[3] = vec4[3](vec4(-1, -1, 0, 1),
                                  vec4( 3, -1, 0, 1),
                                  vec4(-1,  3, 0, 1));
out vec2 uv;
void main()
{
    vec4 pos = positions[ gl_VertexID ];
    gl_Position = pos;
    uv = pos.xy;
}

// Fragment Shader
uniform sampler2D tex;
uniform float xcoeff;
uniform float ycoeff;
out vec4 Color;
in vec2 uv;

void main()
{
    // Handle uv as if upper right quadrant
    vec2 uvabs = abs(uv);

    // unscale: transform w-scaled image into an unscaled image
    //   scale: transform unscaled image int a w-scaled image
    float unscale = 1.0 / (1 + xcoeff * uvabs.x + xcoeff * uvabs.y);
    //float scale = 1.0 / (1 - xcoeff * uvabs.x - xcoeff * uvabs.y);

    vec2 P = vec2(unscale * uvabs.x, unscale * uvabs.y);

    // Go back to the right quadrant
    P *= sign(uv);

    Color = texture(tex, P * 0.5 + 0.5);
}

版本历史

  • 修订版 1，2017-02-15（Eric Werness）

    • 内部修订

VK_NV_command_buffer_inheritance

名称字符串

VK_NV_command_buffer_inheritance

扩展类型

设备扩展

注册扩展号

560

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2024-02-15

IP 状态

没有已知的 IP 声明。

贡献者

  • Piers Daniell, NVIDIA

  • Daniel Story, Nintendo

描述

此扩展允许应用程序利用在提交的命令缓冲区执行之间在队列中保持有效的图形和计算状态。这适用于主命令缓冲区和辅助命令缓冲区。

继承的状态包括先前绑定的管道状态、先前绑定的着色器对象、先前绑定的顶点和索引缓冲区、先前绑定的描述符集和推送常量以及所有先前设置的动态状态。

此扩展放宽了在开始命令缓冲区之后以及下一次绘制或调度之前需要绑定和设置所有这些状态的要求。

通过不必设置已继承的状态，应用程序可以节省 CPU 和 GPU 周期，避免冗余地设置状态，并且在重用二级命令缓冲区时具有更高的灵活性。

新结构

新枚举常量

  • VK_NV_COMMAND_BUFFER_INHERITANCE_EXTENSION_NAME

  • VK_NV_COMMAND_BUFFER_INHERITANCE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMMAND_BUFFER_INHERITANCE_FEATURES_NV

问题

1) 如果状态是在执行时继承的，验证层如何知道在绘制或调度时状态是否有效？

已解决：在记录这些命令时，无法进行绘制和调度时无效状态的验证。相反，验证层需要在记录绘制和调度命令时跟踪任何未设置的状态，但此时不报告错误。它还应跟踪每个已记录命令缓冲区末尾的有效状态。当记录二级命令缓冲区执行时，验证层可以更新其对该命令缓冲区的未设置状态跟踪，以及在二级命令执行后记录的绘制和调度命令，因为它们将从已执行的二级命令继承状态。这可以递归完成，因此每个记录的主命令缓冲区都有一个在绘制和调度时使用的任何未设置状态的最终统计信息。最后，当主缓冲区提交到队列时，验证层将知道先前提交到队列的主缓冲区，并知道是否存在任何使用的未设置状态，然后可以报告错误。

版本历史

  • 修订版 1，2024-02-15 (Lujin Wang)

    • 内部修订

VK_NV_cooperative_matrix

名称字符串

VK_NV_cooperative_matrix

扩展类型

设备扩展

注册扩展号

250

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2019-02-05

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

  • Markus Tavenrath, NVIDIA

  • Daniel Koch, NVIDIA

描述

此扩展添加了对在 SPIR-V 中使用协同矩阵类型的支持。协同矩阵类型是中等大小的矩阵，主要在计算着色器中支持，其中矩阵的存储分布在某个范围（通常是子组）内的所有调用中，并且这些调用协同工作以有效地执行矩阵乘法。

协作矩阵类型由 SPV_NV_cooperative_matrix SPIR-V 扩展定义，并且可以与 GL_NV_cooperative_matrix GLSL 扩展一起使用。

此扩展包括对枚举实现支持的矩阵类型和维度的支持。

新命令

新结构

新枚举

新枚举常量

  • VK_NV_COOPERATIVE_MATRIX_EXTENSION_NAME

  • VK_NV_COOPERATIVE_MATRIX_SPEC_VERSION

  • 扩展 VkComponentTypeKHR

    • VK_COMPONENT_TYPE_FLOAT16_NV

    • VK_COMPONENT_TYPE_FLOAT32_NV

    • VK_COMPONENT_TYPE_FLOAT64_NV

    • VK_COMPONENT_TYPE_SINT16_NV

    • VK_COMPONENT_TYPE_SINT32_NV

    • VK_COMPONENT_TYPE_SINT64_NV

    • VK_COMPONENT_TYPE_SINT8_NV

    • VK_COMPONENT_TYPE_UINT16_NV

    • VK_COMPONENT_TYPE_UINT32_NV

    • VK_COMPONENT_TYPE_UINT64_NV

    • VK_COMPONENT_TYPE_UINT8_NV

  • 扩展 VkScopeKHR

    • VK_SCOPE_DEVICE_NV

    • VK_SCOPE_QUEUE_FAMILY_NV

    • VK_SCOPE_SUBGROUP_NV

    • VK_SCOPE_WORKGROUP_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_COOPERATIVE_MATRIX_PROPERTIES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_PROPERTIES_NV

新 SPIR-V 功能

问题

(1) 实际上会支持哪些矩阵属性？

已解决：在 NVIDIA 的初始实现中，我们将支持

  • AType = BType = fp16 CType = DType = fp16 MxNxK = 16x8x16 范围 = 子组

  • AType = BType = fp16 CType = DType = fp16 MxNxK = 16x8x8 范围 = 子组

  • AType = BType = fp16 CType = DType = fp32 MxNxK = 16x8x16 范围 = 子组

  • AType = BType = fp16 CType = DType = fp32 MxNxK = 16x8x8 范围 = 子组

版本历史

  • 修订版 1，2019-02-05 (Jeff Bolz)

    • 内部修订

VK_NV_cooperative_matrix2

名称字符串

VK_NV_cooperative_matrix2

扩展类型

设备扩展

注册扩展号

594

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_cooperative_matrix

SPIR-V 依赖项
联系方式
扩展提案

VK_NV_cooperative_matrix2

其他扩展元数据

上次修改日期

2024-08-01

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

  • Karthik Vaidyanathan, NVIDIA

描述

此扩展在 VK_KHR_cooperative_matrix 中添加的协作矩阵类型基础上增加了几个新功能。目标是添加和加速超出简单 GEMM 内核的功能，包括添加对类型/用途转换、归约、逐元素操作和张量寻址的支持，并通过添加对更灵活的矩阵大小和通过共享内存进行编译器托管的暂存的工作组范围矩阵的支持，来提高可用性和开箱即用的性能。

新功能由 SPV_NV_tensor_addressing 和 SPV_NV_cooperative_matrix2 SPIR-V 扩展定义，并且可以与 GLSL_NV_cooperative_matrix2 GLSL 扩展一起使用。

此扩展包括对枚举实现支持的矩阵类型和维度以及支持的特定功能的支持。

新命令

新结构

新枚举常量

  • VK_NV_COOPERATIVE_MATRIX_2_EXTENSION_NAME

  • VK_NV_COOPERATIVE_MATRIX_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_COOPERATIVE_MATRIX_FLEXIBLE_DIMENSIONS_PROPERTIES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_2_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_2_PROPERTIES_NV

新 SPIR-V 功能

问题

版本历史

  • 修订版 1，2024-08-01 (Jeff Bolz)

    • 初始修订版

VK_NV_copy_memory_indirect

名称字符串

VK_NV_copy_memory_indirect

扩展类型

设备扩展

注册扩展号

427

修订

1

批准状态

未批准

扩展和版本依赖关系

         VK_KHR_get_physical_device_properties2
         或
         Vulkan 版本 1.1
     和
     VK_KHR_buffer_device_address
或
Vulkan 版本 1.2

联系方式

其他扩展元数据

上次修改日期

2022-10-14

贡献者

  • Vikram Kushwaha, NVIDIA

  • Jeff Bolz, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Daniel Koch, NVIDIA

描述

此扩展增加了对使用间接参数在内存和图像区域之间执行复制的支持，这些间接参数在执行期间由设备从缓冲区读取。 对于在命令缓冲区创建时复制参数未知的情况下执行复制，此功能可能很有用。

新命令

新结构体

新枚举常量

  • VK_NV_COPY_MEMORY_INDIRECT_EXTENSION_NAME

  • VK_NV_COPY_MEMORY_INDIRECT_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COPY_MEMORY_INDIRECT_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COPY_MEMORY_INDIRECT_PROPERTIES_NV

版本历史

  • 修订版 1，2022-10-14 (Vikram Kushwaha)

    • 初始草案

VK_NV_corner_sampled_image

名称字符串

VK_NV_corner_sampled_image

扩展类型

设备扩展

注册扩展号

51

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2018-08-13

贡献者

  • Jeff Bolz, NVIDIA

  • Pat Brown, NVIDIA

  • Chris Lentini, NVIDIA

描述

此扩展添加了对一种新的图像组织的支持，该扩展将其称为“角采样”图像。 角采样图像与传统图像的不同之处在于以下几点

这种图像组织旨在促进像 Ptex 这样的系统，该系统为细分或多边形网格的每个面使用单独的纹理。 将采样位置放置在像素角，允许应用程序通过沿共享边缘复制值来保持相邻补丁之间的连续性。此外，使用修改后的 mipmapping 逻辑以及 2n+1 形式的纹理尺寸，即使相邻补丁使用不同的 LOD 值，也可以在共享边缘上保持连续性。

新结构体

新枚举常量

  • VK_NV_CORNER_SAMPLED_IMAGE_EXTENSION_NAME

  • VK_NV_CORNER_SAMPLED_IMAGE_SPEC_VERSION

  • 扩展 VkImageCreateFlagBits

    • VK_IMAGE_CREATE_CORNER_SAMPLED_BIT_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CORNER_SAMPLED_IMAGE_FEATURES_NV

问题

  1. 此扩展应命名为什么？

    讨论：在命名此扩展时，我们选择了图像组织中最独特的方面，并将此类图像称为“角采样图像”。 因此，我们决定将扩展命名为 NV_corner_sampled_image。

  2. 我们是否需要格式功能标志，以便格式可以声明它们是否支持角采样？

    讨论：目前 NVIDIA 支持所有 2D 和 3D 格式，但不支持立方体贴图或深度模板格式。如果其他供应商仅在某些格式上支持此功能，则格式功能可能会很有用。

  3. 对于角采样图像，整数纹素坐标是否具有不同的范围？

    已解决：否，这些未更改。

  4. 未规范化的采样器坐标是否适用于角采样图像？ 是否有任何功能差异？

    已解决：是的。未规范化的坐标被视为已为角采样使用进行了缩放。

  5. 我们是否应该在“图像操作”章节中提供一个图表，演示不同的纹素采样位置？

    未解决：可能，但稍后。

版本历史

  • 修订版 1，2018-08-14 (Daniel Koch)

    • 内部修订

  • 修订版 2，2018-08-14 (Daniel Koch)

    • ???

VK_NV_coverage_reduction_mode

名称字符串

VK_NV_coverage_reduction_mode

扩展类型

设备扩展

注册扩展号

251

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_NV_framebuffer_mixed_samples
和
     VK_KHR_get_physical_device_properties2
    或
     Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2019-01-29

贡献者

  • Kedarnath Thangudu，NVIDIA

  • Jeff Bolz, NVIDIA

描述

当使用具有混合采样的帧缓冲区时，会执行每次片段覆盖率缩减操作，该操作会从像素覆盖率生成颜色采样覆盖率。此扩展定义了以下模式来控制如何执行此缩减。

  • 合并：当像素覆盖率中的采样多于颜色采样时，像素覆盖率中的每个采样与颜色采样之间存在实现相关的关联。 在合并模式下，颜色采样覆盖率的计算方式为，只有当像素覆盖率中的任何关联采样被覆盖时，颜色采样才会被覆盖。 这是默认模式。

  • 截断：当光栅采样 (N) 多于颜色采样 (M) 时，前 M 个光栅采样与 M 个颜色采样之间存在一一对应的关联；其他光栅采样将被忽略。

当光栅采样的数量等于颜色采样的数量时，在上述任何一种模式下，它们之间都存在一一映射。

可以使用新命令 vkGetPhysicalDeviceSupportedFramebufferMixedSamplesCombinationsNV 查询实现支持的各种光栅、颜色、深度/模板采样计数和缩减模式组合。 此扩展将允许实现同时支持 VK_NV_framebuffer_mixed_samples 和 VK_AMD_mixed_attachment_samples 扩展的行为。

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_NV_COVERAGE_REDUCTION_MODE_EXTENSION_NAME

  • VK_NV_COVERAGE_REDUCTION_MODE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_FRAMEBUFFER_MIXED_SAMPLES_COMBINATION_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COVERAGE_REDUCTION_MODE_FEATURES_NV

    • VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_REDUCTION_STATE_CREATE_INFO_NV

版本历史

  • 修订版 1，2019-01-29 (Kedarnath Thangudu)

    • 内部修订

VK_NV_dedicated_allocation_image_aliasing

名称字符串

VK_NV_dedicated_allocation_image_aliasing

扩展类型

设备扩展

注册扩展号

241

修订

1

批准状态

未批准

扩展和版本依赖关系

     VK_KHR_dedicated_allocation
     和
     VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2019-01-04

贡献者

  • Nuno Subtil, NVIDIA

  • Jeff Bolz, NVIDIA

  • Eric Werness, NVIDIA

  • Axel Gneiting, id Software

描述

此扩展允许应用程序在专用分配上别名图像，但须遵守特定限制：被别名的图像的范围和层数必须小于或等于创建分配的原始图像的范围和层数，并且每个其他图像参数必须匹配。

新结构体

新枚举常量

  • VK_NV_DEDICATED_ALLOCATION_IMAGE_ALIASING_EXTENSION_NAME

  • VK_NV_DEDICATED_ALLOCATION_IMAGE_ALIASING_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEDICATED_ALLOCATION_IMAGE_ALIASING_FEATURES_NV

版本历史

  • 修订版 1, 2019-01-04 (Nuno Subtil)

    • 内部修订

VK_NV_descriptor_pool_overallocation

名称字符串

VK_NV_descriptor_pool_overallocation

扩展类型

设备扩展

注册扩展号

547

修订

1

批准状态

未批准

扩展和版本依赖关系

Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2023-08-30

贡献者

  • Jeff Bolz, NVIDIA

描述

在某些场景中，应用程序无法提前知道它可能需要从描述符池分配多少描述符集，或者可能需要从描述符池分配多少任何描述符类型的描述符。

此扩展允许应用程序请求实现允许分配比描述符池创建时最初指定的更多集合或描述符，但受可用资源的限制。

VK_DESCRIPTOR_POOL_CREATE_ALLOW_OVERALLOCATION_SETS_BIT_NV 标志允许应用程序分配比 VkDescriptorPoolCreateInfo::maxSets 更多的描述符集，而 VK_DESCRIPTOR_POOL_CREATE_ALLOW_OVERALLOCATION_POOLS_BIT_NV 允许应用程序分配比 VkDescriptorPoolSize::descriptorCount 最初为任何描述符类型指定的更多描述符。

新结构体

新枚举常量

  • VK_NV_DESCRIPTOR_POOL_OVERALLOCATION_EXTENSION_NAME

  • VK_NV_DESCRIPTOR_POOL_OVERALLOCATION_SPEC_VERSION

  • 扩展 VkDescriptorPoolCreateFlagBits

    • VK_DESCRIPTOR_POOL_CREATE_ALLOW_OVERALLOCATION_POOLS_BIT_NV

    • VK_DESCRIPTOR_POOL_CREATE_ALLOW_OVERALLOCATION_SETS_BIT_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_POOL_OVERALLOCATION_FEATURES_NV

版本历史

  • 修订版 1, 2023-08-30 (Piers Daniell)

    • 内部修订

VK_NV_device_diagnostic_checkpoints

名称字符串

VK_NV_device_diagnostic_checkpoints

扩展类型

设备扩展

注册扩展号

207

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_synchronization2 交互

联系方式

其他扩展元数据

上次修改日期

2018-07-16

贡献者

  • Oleg Kuznetsov, NVIDIA

  • Alex Dunn, NVIDIA

  • Jeff Bolz, NVIDIA

  • Eric Werness, NVIDIA

  • Daniel Koch, NVIDIA

描述

此扩展允许应用程序在命令流中插入标记，并将它们与自定义数据关联。

如果发生设备丢失错误，则应用程序可以查询实现以获取最后跨越特定实现定义的管线阶段的标记，以便缩小在发生故障时正在执行的命令范围，并可能导致失败。

新命令

如果支持 Vulkan 1.3 版本 或 VK_KHR_synchronization2

新结构体

如果支持 Vulkan 1.3 版本 或 VK_KHR_synchronization2

新枚举常量

  • VK_NV_DEVICE_DIAGNOSTIC_CHECKPOINTS_EXTENSION_NAME

  • VK_NV_DEVICE_DIAGNOSTIC_CHECKPOINTS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_CHECKPOINT_DATA_NV

    • VK_STRUCTURE_TYPE_QUEUE_FAMILY_CHECKPOINT_PROPERTIES_NV

如果支持 Vulkan 1.3 版本 或 VK_KHR_synchronization2

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_CHECKPOINT_DATA_2_NV

    • VK_STRUCTURE_TYPE_QUEUE_FAMILY_CHECKPOINT_PROPERTIES_2_NV

版本历史

  • 修订版 1, 2018-07-16 (Nuno Subtil)

    • 内部修订

  • 修订版 2, 2018-07-16 (Nuno Subtil)

    • ???

VK_NV_device_diagnostics_config

名称字符串

VK_NV_device_diagnostics_config

扩展类型

设备扩展

注册扩展号

301

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2022-04-06

贡献者

  • Kedarnath Thangudu，NVIDIA

  • Thomas Klein, NVIDIA

描述

使用 Nvidia Nsight™ Aftermath SDK for Vulkan 将设备崩溃转储集成到其错误报告机制中的应用程序可以使用此扩展来配置与设备崩溃转储创建相关的选项。

此扩展的第 2 版添加了 VK_DEVICE_DIAGNOSTICS_CONFIG_ENABLE_SHADER_ERROR_REPORTING_BIT_NV，设置后会启用增强的着色器执行错误报告。

新结构体

新枚举

新位掩码

新枚举常量

  • VK_NV_DEVICE_DIAGNOSTICS_CONFIG_EXTENSION_NAME

  • VK_NV_DEVICE_DIAGNOSTICS_CONFIG_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_DIAGNOSTICS_CONFIG_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DIAGNOSTICS_CONFIG_FEATURES_NV

版本历史

  • 修订版 1, 2019-11-21 (Kedarnath Thangudu)

    • 内部修订

  • 修订版 2, 2022-04-06 (Kedarnath Thangudu)

    • 添加了一个配置位 VK_DEVICE_DIAGNOSTICS_CONFIG_ENABLE_SHADER_ERROR_REPORTING_BIT_NV

VK_NV_device_generated_commands

名称字符串

VK_NV_device_generated_commands

扩展类型

设备扩展

注册扩展号

278

修订

3

批准状态

未批准

扩展和版本依赖关系

     Vulkan 版本 1.1
     和
     VK_KHR_buffer_device_address
或
Vulkan 版本 1.2

联系方式

其他扩展元数据

上次修改日期

2020-02-20

交互和外部依赖

  • 此扩展需要 Vulkan 1.1

  • 此扩展需要 VK_EXT_buffer_device_address 或 VK_KHR_buffer_device_address 或 Vulkan 1.2，以便能够在设备上绑定顶点和索引缓冲区。

  • 此扩展与 VK_NV_mesh_shader 交互。 如果不支持后者扩展，请删除用于启动此扩展中的网格任务绘制的命令令牌。

贡献者

  • Christoph Kubisch, NVIDIA

  • Pierre Boudier, NVIDIA

  • Jeff Bolz, NVIDIA

  • Eric Werness, NVIDIA

  • Yuriy O’Donnell, Epic Games

  • Baldur Karlsson, Valve

  • Mathias Schott, NVIDIA

  • Tyson Smith, NVIDIA

  • Ingo Esser, NVIDIA

描述

此扩展允许设备为命令缓冲区生成大量关键图形命令。

在渲染大量对象时，可以利用设备来实现许多关键功能，例如更新矩阵，或实现遮挡剔除、视锥剔除、从前到后排序等。在设备上实现这些功能不需要任何特殊的扩展，因为应用程序可以自由定义自己的数据结构，并且只需使用着色器来处理它们即可。

但是，如果应用程序希望快速启动最终对象流的渲染，则未扩展的 Vulkan 会强制应用程序读回处理后的流并从主机发出图形命令。 对于非常大的场景，同步开销和生成命令缓冲区的成本可能会成为瓶颈。 此扩展允许应用程序生成设备端状态更改和命令流，并将其有效地转换为命令缓冲区，而无需将其读回主机。

此外，它允许通过仅操作命令流的部分部分（例如管线绑定）来增量更改此类命令缓冲区。 在这种情况下，未扩展的 Vulkan 需要重新创建整个命令缓冲区，或在主机上同步更新。

此扩展的预期用法是让应用程序

  • 创建 VkBuffer 对象并通过 vkGetBufferDeviceAddressEXT 从中检索物理地址

  • 使用 VkGraphicsPipelineShaderGroupsCreateInfoNV 创建图形管线，以便能够在设备上更改着色器。

  • 创建一个 VkIndirectCommandsLayoutNV，其中列出了它希望作为原子命令序列动态执行的 VkIndirectCommandsTokenTypeNV。 此步骤可能涉及一些内部设备代码编译，因为目的是让 GPU 在管线中生成命令缓冲区。

  • 使用它需要的每个输入的​​数据填充输入流缓冲区。每个输入都是一个数组，该数组将填充依赖于令牌的数据。

  • 设置一个预处理 VkBuffer，该缓冲区根据通过 vkGetGeneratedCommandsMemoryRequirementsNV 检索的信息使用内存。

  • 可以选择使用 vkCmdPreprocessGeneratedCommandsNV 预处理生成的内容，例如在异步计算队列上，或为了在多次执行中重用数据。

  • 调用 vkCmdExecuteGeneratedCommandsNV 基于提供的输入为所有序列创建并执行实际的设备命令。

对于序列中的每个绘制，可以指定以下内容

  • 不同的着色器组

  • 多个顶点缓冲区绑定

  • 一个不同的索引缓冲区，带有可选的动态偏移和索引类型

  • 多个不同的推送常量

  • 一个编码图元绕序的标志

虽然 GPU 生成命令的速度可能比 CPU 快，但它不会异步于设备发生，因此主要用例是生成“更少”的总工作量（遮挡剔除、分类以使用专用着色器等）。

新对象类型

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_NV_DEVICE_GENERATED_COMMANDS_EXTENSION_NAME

  • VK_NV_DEVICE_GENERATED_COMMANDS_SPEC_VERSION

  • 扩展 VkAccessFlagBits

    • VK_ACCESS_COMMAND_PREPROCESS_READ_BIT_NV

    • VK_ACCESS_COMMAND_PREPROCESS_WRITE_BIT_NV

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_INDIRECT_COMMANDS_LAYOUT_NV

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_INDIRECT_BINDABLE_BIT_NV

  • 扩展 VkPipelineStageFlagBits

    • VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_GENERATED_COMMANDS_INFO_NV

    • VK_STRUCTURE_TYPE_GENERATED_COMMANDS_MEMORY_REQUIREMENTS_INFO_NV

    • VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_SHADER_GROUPS_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_GRAPHICS_SHADER_GROUP_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_TOKEN_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_PROPERTIES_NV

问题

1) 如何命名这个扩展？

VK_NV_device_generated_commands

像往常一样，最难的问题之一 ;)

备选方案：VK_gpu_commands，VK_execute_commands，VK_device_commands，VK_device_execute_commands，VK_device_execute，VK_device_created_commands，VK_device_recorded_commands，VK_device_generated_commands VK_indirect_generated_commands

2) 我们应该使用串行有状态的令牌流还是无状态的序列描述？

与 VkPipeline 类似，固定的布局最有可能被跨供应商采用。它们也受益于可以并行处理。这与通过 GL_NV_command_list 生成的串行命令流相比，是不同的设计选择。

3) 如何命名序列描述？

VkIndirectCommandsLayout，与 NVX 扩展的前身相同。

备选方案：VkGeneratedCommandsLayout

4) 我们是否希望在布局时或在 indirectCommands 时提供 indirectCommands 输入？

像 Vulkan 一样将布局与数据分离。为 indirectCommands 提供充分的灵活性。

5) 输入应该以 SoA 还是 AoS 的形式提供？

两种方式都是可取的。AoS 可以为其他 API 提供可移植性并更容易设置，而 SoA 允许以缓存高效的方式更新单个输入，而其他输入保持静态。

6) 我们如何让开发者了解用于生成命令的、依赖于实现的内存需求？

使 API 明确化并引入一个 preprocess VkBuffer。开发者必须使用 vkGetGeneratedCommandsMemoryRequirementsNV 分配它。

在 NVX 版本中，需求隐含地隐藏在命令缓冲区保留过程中，但是由于内存需求可能很大，我们希望让开发者能够自己预算内存。通过降低 maxSequencesCount，可以减少内存消耗。此外，可以重用内存，例如以乒乓方式进行显式预处理和执行。

实际的缓冲区大小依赖于实现，并且可能为零，即并非总是需要。

当使用图形着色器组时，程序在顶点输入、几何阶段的裁剪和剔除输出以及片段着色器中的采样着色行为方面应该表现相似，以减少最坏情况下的内存近似值。

7) 我们是否应该允许额外的每序列动态状态更改？

是的

引入了一个轻量级的间接状态标志 VkIndirectStateFlagBitsNV。到目前为止，只暴露了切换正面绕序状态。特别是在需要此类更改的 CAD/DCC 镜像变换中，很常见，并且在光线追踪实例描述中给出了类似的灵活性。

该标志可以进一步扩展，例如在图元列表或图元条之间切换，或进行其他状态修改。

此外，由于可以轻松添加新令牌，未来的扩展可以添加更改任何 VkDynamicState 的能力。

8) 我们如何允许重用已经“生成”的 indirectCommands？

公开一个 preprocessBuffer 来重用依赖于实现的标志数据。在 vkCmdExecuteGeneratedCommandsNV 中将 isPreprocessed 设置为 VK_TRUE。

9) 在什么条件下 vkCmdExecuteGeneratedCommandsNV 是合法的？

它的行为类似于常规的绘制调用命令。

10) vkCmdPreprocessGeneratedCommandsNV 是复制输入数据还是引用它？

有多种可能的实现

  • 一种实现可能具有一些模拟代码，用于解析输入并生成输出命令缓冲区，因此会复制输入。

  • 另一种实现可能只是引用输入，并在执行时在管道中完成处理。

如果强制要求复制数据，则会对可以直接在管道中处理输入的实现造成惩罚。如果数据是“引用”的，则允许两种类型的实现。

输入是“引用”的，并且在调用 vkCmdExecuteGeneratedCommandsNV 完成后，必须 不被修改。

11) VkGeneratedCommandsInfoNV 引用的缓冲区需要哪些缓冲区使用标志？

重用现有的 VK_BUFFER_USAGE_INDIRECT_BUFFER_BIT

12) 设备生成命令扩展发生在哪个管道阶段？

vkCmdPreprocessGeneratedCommandsNV 被视为发生在与图形或计算不同的独立逻辑管线中，该管线仅包括 VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT，一个新的阶段 VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV 和 VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT。这个新阶段有两个对应的新访问类型，VK_ACCESS_COMMAND_PREPROCESS_READ_BIT_NV 和 VK_ACCESS_COMMAND_PREPROCESS_WRITE_BIT_NV，用于同步读取缓冲区输入和写入预处理内存输出。

vkCmdExecuteGeneratedCommandsNV 在预处理缓冲区内存中写入的生成输出被认为是由 VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT 管线阶段消耗的。

因此，要同步从写入输入缓冲区到通过 vkCmdPreprocessGeneratedCommandsNV 进行预处理，请使用

  • dstStageMask = VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV

  • dstAccessMask = VK_ACCESS_COMMAND_PREPROCESS_READ_BIT_NV

要同步从 vkCmdPreprocessGeneratedCommandsNV 到通过 vkCmdExecuteGeneratedCommandsNV 执行生成的命令，请使用

  • srcStageMask = VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV

  • srcAccessMask = VK_ACCESS_COMMAND_PREPROCESS_WRITE_BIT_NV

  • dstStageMask = VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT

  • dstAccessMask = VK_ACCESS_INDIRECT_COMMAND_READ_BIT

当 vkCmdExecuteGeneratedCommandsNV 与 isPreprocessed 为 VK_FALSE 一起使用时，生成的命令会被隐式预处理，因此只需要通过以下方式同步输入：

  • dstStageMask = VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT

  • dstAccessMask = VK_ACCESS_INDIRECT_COMMAND_READ_BIT

13) 如果大多数标记数据是“静态的”，但我们经常想要渲染一个子部分，该怎么办？

添加了“sequencesIndexBuffer”。这允许更容易地排序和过滤实际应该执行的内容。

14) 与之前的 NVX 扩展相比，有哪些变化？

  • 删除了计算调度支持（从未在驱动程序中实现）。关于如何从设备进行调度有不同的方法，因此我们将其推迟到未来的扩展中。

  • ObjectTableNVX 被替换为使用物理缓冲区地址并为图形管线引入着色器组。

  • 总体而言，可能的状态更改较少，但重要的操作仍然存在（降低了实现的复杂性）。

  • API 经过重新设计，因此所有输入都必须在预处理和执行时传递（这在 NVX 中是隐式的，现在是显式的）

  • 中间命令空间的保留现在是强制性的，并通过预处理缓冲区显式指定。

  • 引入了 VkIndirectStateFlagBitsNV

15) 从其他 API 移植时，它们的间接缓冲区可能会使用不同的枚举，例如索引缓冲区类型。如何解决这个问题？

添加了“pIndexTypeValues”以将自定义 uint32_t 值映射到相应的 VkIndexType。

16) 我们是否需要更多着色器组状态覆盖？

NVX 版本允许所有 PSO 状态都不同，但是由于目标不是替换所有状态设置，而是专注于为绘制大量对象进行高频率状态更改，因此我们减少了状态覆盖的数量。特别是 VkPipelineLayout 以及 VkRenderPass 配置应该保持静态，其余的仍然可以讨论。

当前的重点只是允许 VertexInput 更改以及着色器，同时所有着色器组使用相同的着色器阶段。

过多的灵活性也会增加测试覆盖率的要求。但是，进一步的扩展也可以允许更多的动态状态。

17) 我们是否需要更详细的物理设备功能查询/启用？

EXT 版本需要详细的实施者反馈才能提出一套好的功能。如果您有兴趣，请联系我们，我们很乐意使更多功能成为可选的，或者添加更多限制以减少 EXT 的最小功能集。

18) 是否计划与 VK_KHR_pipeline_library 进行交互？

是的，此扩展的未来版本将详细说明交互，一旦 VK_KHR_pipeline_library 不再是临时的。

示例代码

可以在以下位置找到说明扩展用法的开源示例（在撰写本文时可能尚不存在）

https://github.com/nvpro-samples/vk_device_generated_cmds

版本历史

  • 修订版 1，2020-02-20 (Christoph Kubisch)

    • 初始版本

  • 修订版 2，2020-03-09 (Christoph Kubisch)

    • 删除 VK_EXT_debug_report 交互

  • 修订版 3，2020-03-09 (Christoph Kubisch)

    • 修复命名 VkPhysicalDeviceGenerated 为 VkPhysicalDeviceDeviceGenerated

VK_NV_device_generated_commands_compute

名称字符串

VK_NV_device_generated_commands_compute

扩展类型

设备扩展

注册扩展号

429

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_NV_device_generated_commands

联系方式

其他扩展元数据

上次修改日期

2023-07-21

贡献者

  • Vikram Kushwaha, NVIDIA

  • Jeff Bolz, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Piers Daniell, NVIDIA

  • Daniel Koch, NVIDIA

  • Hans-Kristian Arntzen, Valve

  • Mike Blumenkrantz, VALVE

描述

此扩展允许设备生成用于绑定计算管线、设置推送常量和启动计算调度的命令。

新命令

新结构

新枚举常量

  • VK_NV_DEVICE_GENERATED_COMMANDS_COMPUTE_EXTENSION_NAME

  • VK_NV_DEVICE_GENERATED_COMMANDS_COMPUTE_SPEC_VERSION

  • 扩展 VkDescriptorSetLayoutCreateFlagBits

    • VK_DESCRIPTOR_SET_LAYOUT_CREATE_INDIRECT_BINDABLE_BIT_NV

  • 扩展 VkIndirectCommandsTokenTypeNV

    • VK_INDIRECT_COMMANDS_TOKEN_TYPE_DISPATCH_NV

    • VK_INDIRECT_COMMANDS_TOKEN_TYPE_PIPELINE_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_COMPUTE_PIPELINE_INDIRECT_BUFFER_INFO_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_COMPUTE_FEATURES_NV

    • VK_STRUCTURE_TYPE_PIPELINE_INDIRECT_DEVICE_ADDRESS_INFO_NV

版本历史

  • 修订版 2，2023-07-21 (Vikram Kushwaha)

    • 将 vkCmdUpdatePipelineIndirectBuffer 重命名为 vkCmdUpdatePipelineIndirectBufferNV

  • 修订版 1，2023-06-09 (Vikram Kushwaha)

    • 第一次修订

VK_NV_display_stereo

名称字符串

VK_NV_display_stereo

扩展类型

实例扩展

注册扩展号

552

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_display
和
VK_KHR_get_display_properties2

联系方式
扩展提案

VK_NV_display_stereo

其他扩展元数据

上次修改日期

2024-11-20

贡献者

  • Russell Chou, NVIDIA

  • Jeff Juliano, NVIDIA

  • James Jones, NVIDIA

描述

此扩展允许应用程序选择它想要使用的 3D 立体硬件类型，以便驱动程序可以正确配置它。此配置对于从显示表面创建的交换链很有用，因为某些环境没有可用于轻松配置的中间窗口系统。此扩展将覆盖窗口系统中的任何立体类型配置。

对于 HDMI 3D，只有一些显示模式支持立体渲染，并且需要一个新的结构来向应用程序公开该信息。

新结构

新枚举

新枚举常量

  • VK_NV_DISPLAY_STEREO_EXTENSION_NAME

  • VK_NV_DISPLAY_STEREO_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DISPLAY_MODE_STEREO_PROPERTIES_NV

    • VK_STRUCTURE_TYPE_DISPLAY_SURFACE_STEREO_CREATE_INFO_NV

版本历史

  • 版本 1，2024-11-20 (Russell Chou)

    • 初始发布

VK_NV_extended_sparse_address_space

名称字符串

VK_NV_extended_sparse_address_space

扩展类型

设备扩展

注册扩展号

493

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2023-10-03

贡献者

  • Russell Chou, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Eric Werness, NVIDIA

  • Jeff Bolz, NVIDIA

描述

实现可能能够支持稀疏内存资源的扩展地址空间，但仅限于特定的用途。

此扩展添加了对扩展限制的查询，以及该限制允许的受支持用法。当VkImage或VkBuffer仅使用受支持的用法时，此限制是对VkPhysicalDeviceLimits::sparseAddressSpaceSize的增加。

新结构

新枚举常量

  • VK_NV_EXTENDED_SPARSE_ADDRESS_SPACE_EXTENSION_NAME

  • VK_NV_EXTENDED_SPARSE_ADDRESS_SPACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_SPARSE_ADDRESS_SPACE_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_SPARSE_ADDRESS_SPACE_PROPERTIES_NV

版本历史

  • 版本 1，2023-10-03 (Russell Chou)

    • 初始草案

VK_NV_external_memory_rdma

名称字符串

VK_NV_external_memory_rdma

扩展类型

设备扩展

注册扩展号

372

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_external_memory
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2021-04-19

IP 状态

没有已知的 IP 声明。

贡献者

  • Carsten Rohde, NVIDIA

描述

此扩展添加了对分配内存的支持，该内存可以用于来自其他设备的远程直接内存访问 (RDMA)。

新基本类型

  • VkRemoteAddressNV

新命令

新结构

新枚举常量

  • VK_NV_EXTERNAL_MEMORY_RDMA_EXTENSION_NAME

  • VK_NV_EXTERNAL_MEMORY_RDMA_SPEC_VERSION

  • 扩展 VkExternalMemoryHandleTypeFlagBits

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_RDMA_ADDRESS_BIT_NV

  • 扩展 VkMemoryPropertyFlagBits

    • VK_MEMORY_PROPERTY_RDMA_CAPABLE_BIT_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_MEMORY_GET_REMOTE_ADDRESS_INFO_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_MEMORY_RDMA_FEATURES_NV

问题

示例

VkPhysicalDeviceMemoryBudgetPropertiesEXT memoryBudgetProperties = { VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT };
VkPhysicalDeviceMemoryProperties2 memoryProperties2 = { VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PROPERTIES_2, &memoryBudgetProperties };
vkGetPhysicalDeviceMemoryProperties2(physicalDevice, &memoryProperties2);
uint32_t heapIndex = (uint32_t)-1;
for (uint32_t memoryType = 0; memoryType < memoryProperties2.memoryProperties.memoryTypeCount; memoryType++) {
    if (memoryProperties2.memoryProperties.memoryTypes[memoryType].propertyFlags & VK_MEMORY_PROPERTY_RDMA_CAPABLE_BIT_NV) {
        heapIndex = memoryProperties2.memoryProperties.memoryTypes[memoryType].heapIndex;
        break;
    }
}
if ((heapIndex == (uint32_t)-1) ||
    (memoryBudgetProperties.heapBudget[heapIndex] < size)) {
    return;
}

VkPhysicalDeviceExternalBufferInfo externalBufferInfo = { VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_BUFFER_INFO };
externalBufferInfo.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT;
externalBufferInfo.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_RDMA_ADDRESS_BIT_NV;

VkExternalBufferProperties externalBufferProperties = { VK_STRUCTURE_TYPE_EXTERNAL_BUFFER_PROPERTIES };
vkGetPhysicalDeviceExternalBufferProperties(physicalDevice, &externalBufferInfo, &externalBufferProperties);

if (!(externalBufferProperties.externalMemoryProperties.externalMemoryFeatures & VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT)) {
    return;
}

VkExternalMemoryBufferCreateInfo externalMemoryBufferCreateInfo = { VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_BUFFER_CREATE_INFO };
externalMemoryBufferCreateInfo.handleTypes = VK_EXTERNAL_MEMORY_HANDLE_TYPE_RDMA_ADDRESS_BIT_NV;

VkBufferCreateInfo bufferCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO, &externalMemoryBufferCreateInfo };
bufferCreateInfo.size = size;
bufferCreateInfo.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT;

VkMemoryRequirements mem_reqs;
vkCreateBuffer(device, &bufferCreateInfo, NULL, &buffer);
vkGetBufferMemoryRequirements(device, buffer, &mem_reqs);

VkExportMemoryAllocateInfo exportMemoryAllocateInfo = { VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO };
exportMemoryAllocateInfo.handleTypes = VK_EXTERNAL_MEMORY_HANDLE_TYPE_RDMA_ADDRESS_BIT_NV;

// Find memory type index
uint32_t i = 0;
for (; i < VK_MAX_MEMORY_TYPES; i++) {
    if ((mem_reqs.memoryTypeBits & (1 << i)) &&
        (memoryProperties.memoryTypes[i].propertyFlags & VK_MEMORY_PROPERTY_RDMA_CAPABLE_BIT_NV)) {
        break;
    }
}

VkMemoryAllocateInfo memAllocInfo = { VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO, &exportMemoryAllocateInfo };
memAllocInfo.allocationSize = mem_reqs.size;
memAllocInfo.memoryTypeIndex = i;

vkAllocateMemory(device, &memAllocInfo, NULL, &mem);
vkBindBufferMemory(device, buffer, mem, 0);

VkMemoryGetRemoteAddressInfoNV getMemoryRemoteAddressInfo = { VK_STRUCTURE_TYPE_MEMORY_GET_REMOTE_ADDRESS_INFO_NV };
getMemoryRemoteAddressInfo.memory = mem;
getMemoryRemoteAddressInfo.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_RDMA_ADDRESS_BIT_NV;

VkRemoteAddressNV rdmaAddress;
vkGetMemoryRemoteAddressNV(device, &getMemoryRemoteAddressInfo, &rdmaAddress);
// address returned in 'rdmaAddress' can be used by external devices to initiate RDMA transfers

版本历史

  • 版本 1，2020-12-15 (Carsten Rohde)

    • 内部修订

VK_NV_fill_rectangle

名称字符串

VK_NV_fill_rectangle

扩展类型

设备扩展

注册扩展号

154

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2017-05-22

贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展添加了一个新的VkPolygonMode enum，其中通过计算并填充其轴对齐的屏幕空间边界框来栅格化三角形，而忽略实际的三角形边缘。这对于绘制矩形而无需将其拆分为具有内部边的两个三角形非常有用。它还有助于最大限度地减少需要绘制的图元数量，特别是对于用户界面。

新枚举常量

  • VK_NV_FILL_RECTANGLE_EXTENSION_NAME

  • VK_NV_FILL_RECTANGLE_SPEC_VERSION

  • 扩展VkPolygonMode

    • VK_POLYGON_MODE_FILL_RECTANGLE_NV

版本历史

  • 版本 1，2017-05-22 (Jeff Bolz)

    • 内部修订

VK_NV_fragment_coverage_to_color

名称字符串

VK_NV_fragment_coverage_to_color

扩展类型

设备扩展

注册扩展号

150

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2017-05-21

贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展允许将片段覆盖率值（表示为整数位掩码）替换为写入具有整数组件的单组件颜色附件（例如，VK_FORMAT_R8_UINT）的颜色输出。此扩展提供的功能与简单地写入 SampleMask 片段着色器输出不同，因为写入帧缓冲区的覆盖率值是在模板测试和深度测试之后，以及在诸如 alpha 到覆盖率等片段操作之后获取的。

此功能对于延迟渲染算法可能很有用，在延迟渲染算法中，第二遍需要知道哪些样本属于哪些原始片段。

新结构

新位掩码

新枚举常量

  • VK_NV_FRAGMENT_COVERAGE_TO_COLOR_EXTENSION_NAME

  • VK_NV_FRAGMENT_COVERAGE_TO_COLOR_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_TO_COLOR_STATE_CREATE_INFO_NV

版本历史

  • 版本 1，2017-05-21 (Jeff Bolz)

    • 内部修订

VK_NV_fragment_shading_rate_enums

名称字符串

VK_NV_fragment_shading_rate_enums

扩展类型

设备扩展

注册扩展号

327

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_fragment_shading_rate

联系方式

其他扩展元数据

上次修改日期

2020-09-02

贡献者

  • Pat Brown, NVIDIA

  • Jeff Bolz, NVIDIA

描述

此扩展建立在 VK_KHR_fragment_shading_rate 扩展提供的片段着色率功能的基础上，添加了对“超采样”片段着色率的支持，该着色率触发每个像素多次片段着色器调用，以及“无调用”着色率，该着色率会丢弃任何将使用该着色率的图元部分。

新命令

新结构

新枚举

新枚举常量

  • VK_NV_FRAGMENT_SHADING_RATE_ENUMS_EXTENSION_NAME

  • VK_NV_FRAGMENT_SHADING_RATE_ENUMS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_ENUMS_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_ENUMS_PROPERTIES_NV

    • VK_STRUCTURE_TYPE_PIPELINE_FRAGMENT_SHADING_RATE_ENUM_STATE_CREATE_INFO_NV

问题

  1. 为什么要创建这个扩展？它应该如何命名？

    已解决：此扩展的主要目标是公开对超采样和“无调用”着色率的支持，这些着色率受 VK_NV_shading_rate_image 扩展支持，但不受 VK_KHR_fragment_shading_rate 支持。 由于 VK_KHR_fragment_shading_rate 使用像素中的片段大小来指定图元着色率，因此它缺乏指定超采样率的良好方法。 为了解决这个问题，我们定义了涵盖 KHR 扩展支持的着色率以及新的着色率的枚举，并添加了接受着色率枚举而不是片段大小的结构和 API。

    由于此扩展添加了两种不同类型的着色率，均使用枚举表示，因此我们选择了扩展名称 VK_NV_fragment_shading_rate_enums。

  2. 这是一个独立的扩展吗？

    已解决：否，此扩展需要 VK_KHR_fragment_shading_rate。为了使用此扩展的功能，应用程序必须启用 KHR 扩展的相关功能。

  3. 如何使用着色率枚举，以及如何分配枚举值？

    已解决：此扩展中的枚举支持的着色率被接受为管线、图元和附件着色率，并且行为相同。对于 KHR 扩展也支持的着色率，分配给相应枚举的值与 KHR 扩展中已用于图元和附件着色率的值相同。 对于这些枚举，位 0 和 1 指定片段高度的以 2 为底的对数，位 2 和 3 指定片段宽度的以 2 为底的对数。 对于此扩展添加的新着色率，我们选择使用 11 到 14（10 加上调用计数的以 2 为底的对数）表示超采样率，使用 15 表示“无调用”率。 KHR 扩展不支持这些值作为图元或附件着色率。

  4. 在此扩展、VK_KHR_fragment_shading_rate 和 VK_NV_shading_rate_image 之间，有三种不同的方法可以在管线中指定着色率状态。我们应该如何处理这个问题？

    已解决：我们不允许同时使用 VK_NV_shading_rate_image 和 VK_KHR_fragment_shading_rate；启用来自两个扩展的着色率功能是错误的。 但是，我们允许应用程序同时启用此扩展和 VK_KHR_fragment_shading_rate。 虽然我们预计应用程序永远不会同时为此扩展和 KHR 扩展附加管线 CreateInfo 结构，但 Vulkan 没有任何先例禁止这种行为，而是通常将没有特定于扩展的 CreateInfo 结构创建的管线视为等同于包含扩展指定的默认值的管线。 与其添加这样的规则，考虑是否存在新的 CreateInfo 结构，不如在 VkPipelineFragmentShadingRateEnumStateCreateInfoNV 中包含一个 shadingRateType 成员，该成员用于选择使用该结构指定的状态和 VkPipelineFragmentShadingRateStateCreateInfoKHR 指定的状态。

版本历史

  • 修订版 1，2020-09-02 (pbrown)

    • 内部修订

VK_NV_framebuffer_mixed_samples

名称字符串

VK_NV_framebuffer_mixed_samples

扩展类型

设备扩展

注册扩展号

153

修订

1

批准状态

未批准

扩展和版本依赖关系

无

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_dynamic_rendering 交互

联系方式

其他扩展元数据

上次修改日期

2017-06-04

贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展允许使用比颜色采样数更大的光栅和深度/模板采样数进行多重采样渲染。 光栅化和深度和模板测试的结果共同确定了像素的“覆盖”部分。 以高于存储颜色采样的频率评估覆盖率可能很有用。 然后将此覆盖率“减少”为一组覆盖的颜色采样，每个采样具有与覆盖的颜色采样分数相对应的不透明度值。 可以选择将不透明度混合到各个颜色采样中。

使用比深度/模板采样少的颜色采样进行渲染可以大大减少颜色缓冲区消耗的内存和带宽。 但是，将覆盖率值转换为不透明度会在三角形共享边缘时引入伪影，并且可能不适合正常的三角形网格渲染。

此功能的一个预期用例是先模板后覆盖路径渲染（类似于 OpenGL GL_NV_path_rendering 扩展）。 模板步骤以较高的采样频率确定整个路径的覆盖率（在模板缓冲区中），然后覆盖步骤使用覆盖率信息将路径绘制到较低频率的颜色缓冲区中，以抗锯齿路径边缘。 通过此两步过程，当应用抗锯齿时，内部边缘会被完全覆盖，并且这些边缘上没有损坏。

此扩展的主要功能是

  • 它允许创建渲染通道和帧缓冲区对象，其中子通道中深度/模板附件中的采样数是子通道中颜色附件中采样数的倍数。

  • 在片段操作中添加了覆盖率减少步骤，该步骤将一组覆盖的光栅/深度/模板采样转换为一组执行混合和颜色写入的颜色采样。 覆盖率减少步骤还包括一个可选的覆盖率调制步骤，该步骤将颜色值乘以与覆盖的光栅/深度/模板采样数相对应的分数不透明度。

新结构

如果支持 Vulkan 版本 1.3 或 VK_KHR_dynamic_rendering

新枚举

新位掩码

新枚举常量

  • VK_NV_FRAMEBUFFER_MIXED_SAMPLES_EXTENSION_NAME

  • VK_NV_FRAMEBUFFER_MIXED_SAMPLES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_MODULATION_STATE_CREATE_INFO_NV

如果支持 Vulkan 版本 1.3 或 VK_KHR_dynamic_rendering

版本历史

  • 修订版 1，2017-06-04 (Jeff Bolz)

    • 内部修订

VK_NV_geometry_shader_passthrough

名称字符串

VK_NV_geometry_shader_passthrough

扩展类型

设备扩展

注册扩展号

96

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2017-02-15

交互和外部依赖
贡献者

  • Piers Daniell, NVIDIA

  • Jeff Bolz, NVIDIA

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

  • SPV_NV_geometry_shader_passthrough

几何着色器允许应用程序使用可编程着色器处理通过图形管线发送的每个图元。然而，一种常见的用例是将它们主要视为“直通”。在这种用例中，大部分几何着色器代码只是将输入图元的每个顶点中的输入复制到输出图元的顶点中的相应输出。这种着色器也可能会计算要分配给输出图元的所有顶点的其他内置或用户定义的每个图元属性（例如，Layer）的值。

此扩展提供了在 GeometryShaderPassthroughNV 功能下访问 PassthroughNV 修饰符的能力。将其添加到几何着色器输入变量会指定此输入的值将复制到输出图元的相应顶点。

当使用基于 GLSL 源的着色语言时，来自 GL_NV_geometry_shader_passthrough 的 passthrough 布局限定符映射到 PassthroughNV 修饰符。要在 GLSL 中使用 passthrough 布局，必须启用 GL_NV_geometry_shader_passthrough 扩展。行为在 GL_NV_geometry_shader_passthrough 扩展规范中描述。

新枚举常量

  • VK_NV_GEOMETRY_SHADER_PASSTHROUGH_EXTENSION_NAME

  • VK_NV_GEOMETRY_SHADER_PASSTHROUGH_SPEC_VERSION

新变量修饰符

新的 SPIR-V 功能

问题

1) 我们应该要求还是允许直通几何着色器在 SPIR-V 中指定输出图元类型和最大顶点数的输出布局限定符？

已解决：是的，它们应该在 SPIR-V 中是必需的。根据 GL_NV_geometry_shader_passthrough，它们在 GLSL 源着色器中是不允许的，但 SPIR-V 是较低级别的。GLSL 编译器可以根据输入图元类型推断它们，并根据下表在 SPIR-V 中显式发出它们，这很简单。

输入布局 隐含的输出布局

点

layout(points, max_vertices=1)

线

layout(line_strip, max_vertices=2)

三角形

layout(triangle_strip, max_vertices=3)

2) 接口匹配如何与直通几何着色器一起工作？

已解决：这在 直通接口匹配 中描述。在 GL 中，当在可分离模式下使用直通几何着色器时，所有输入也必须显式分配位置布局限定符。在 Vulkan 中，所有 SPIR-V 着色器输入（内置变量除外）也必须指定位置修饰符。重新声明添加直通布局限定符的内置变量可免除要求分配位置的规则，因为内置变量没有位置，并且通过 BuiltIn 修饰符匹配。

示例代码

考虑以下未扩展的 GLSL 中的简单几何着色器

layout(triangles) in;
layout(triangle_strip) out;
layout(max_vertices=3) out;

in Inputs {
    vec2 texcoord;
    vec4 baseColor;
} v_in[];
out Outputs {
    vec2 texcoord;
    vec4 baseColor;
};

void main()
{
    int layer = compute_layer();
    for (int i = 0; i < 3; i++) {
        gl_Position = gl_in[i].gl_Position;
        texcoord = v_in[i].texcoord;
        baseColor = v_in[i].baseColor;
        gl_Layer = layer;
        EmitVertex();
    }
}

在此着色器中，输入 gl_Position、Inputs.texcoord 和 Inputs.baseColor 只是从输入顶点复制到相应的输出顶点。几何着色器执行的唯一“有趣”的工作是计算并发出图元的 gl_Layer 值。

以下使用此扩展的几何着色器是等效的

#extension GL_NV_geometry_shader_passthrough : require

layout(triangles) in;
// No output primitive layout qualifiers required.

// Redeclare gl_PerVertex to pass through "gl_Position".
layout(passthrough) in gl_PerVertex {
    vec4 gl_Position;
} gl_in[];

// Declare "Inputs" with "passthrough" to automatically copy members.
layout(passthrough) in Inputs {
    vec2 texcoord;
    vec4 baseColor;
} v_in[];

// No output block declaration required.

void main()
{
    // The shader simply computes and writes gl_Layer.  We do not
    // loop over three vertices or call EmitVertex().
    gl_Layer = compute_layer();
}

版本历史

  • 修订版 1，2017-02-15 (Daniel Koch)

    • 内部修订

VK_NV_inherited_viewport_scissor

名称字符串

VK_NV_inherited_viewport_scissor

扩展类型

设备扩展

注册扩展号

279

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2021-02-04

贡献者

  • David Zhao Akeley，NVIDIA

  • Jeff Bolz, NVIDIA

  • Piers Daniell, NVIDIA

  • Christoph Kubisch, NVIDIA

描述

此扩展添加了辅助命令缓冲区从主命令缓冲区或在同一 vkCmdExecuteCommands 调用中执行的先前辅助命令缓冲区继承动态视口和剪裁状态的功能。它解决了应用程序中处理窗口大小调整并希望提高可重用辅助命令缓冲区的利用率的常见场景。该功能通过 VkCommandBufferInheritanceViewportScissorInfoNV 提供。视口继承有效地限制为 2D 矩形；辅助命令缓冲区必须重新指定继承的深度范围值。

新结构

新枚举常量

  • VK_NV_INHERITED_VIEWPORT_SCISSOR_EXTENSION_NAME

  • VK_NV_INHERITED_VIEWPORT_SCISSOR_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_VIEWPORT_SCISSOR_INFO_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INHERITED_VIEWPORT_SCISSOR_FEATURES_NV

问题

(1) 为什么视口深度值在 VkCommandBufferInheritanceViewportScissorInfoNV 结构中配置，而不是通过 vkCmd…​ 函数？

讨论:

我们考虑过添加新的 vkCmdSetViewportDepthNV 函数，以及修改 vkCmdSetViewport 以在调用具有激活此扩展的辅助命令缓冲区时忽略 x、y、width 和 height 值。

此扩展的主要设计考虑因素是可调试性和易于集成到现有应用程序中。添加新的 vkCmdSetViewportDepthNV 函数的主要问题是降低易于集成性。将需要加载一个新的函数指针，但更重要的是，一个新函数将需要更改才能在图形调试器中得到支持；这将延迟扩展的广泛采用。

修改 vkCmdSetViewport 的提案将避免这些问题。但是，我们期望使用此扩展的应用程序的意图是用于绘制的视口值与继承的值完全匹配；因此，如果没有提供仅修改视口深度的功能，则可调试性会更好。通过在开始记录辅助命令缓冲区时指定视口深度值，并要求指定的深度值与继承的深度值匹配，我们可以允许验证层将深度更改标记为错误。

此设计也更符合硬件模型。事实上，无需重新执行深度设置命令。图形设备保留视口深度状态；必须重新初始化的是 VkCommandBuffer 的 CPU 端状态。

(2) 为什么视口深度值指定为部分 VkViewport 结构，而不是更精简的仅深度结构？

讨论:

我们曾考虑添加一个新的 VkViewportDepthNV 结构体，其中只包含 minDepth 和 maxDepth。然而，由于应用程序开发人员需要维护 VK_NV_inherited_viewport_scissor 代码路径和回退代码路径（至少在短期内），我们最终选择继续使用现有的 VkViewport 结构。这样做可以让应用程序开发人员为两条代码路径重用同一个 VkViewport 数组，而不是为每条代码路径构建单独的 VkViewportDepthNV 和 VkViewport 数组。

版本历史

  • 修订版 1, 2020-02-04 (David Zhao Akeley)

    • 内部修订

VK_NV_linear_color_attachment

名称字符串

VK_NV_linear_color_attachment

扩展类型

设备扩展

注册扩展号

431

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_format_feature_flags2 交互

联系方式

其他扩展元数据

上次修改日期

2021-12-02

交互和外部依赖
贡献者

  • Pat Brown, NVIDIA

  • Piers Daniell, NVIDIA

  • Sourav Parmar, NVIDIA

描述

当渲染通道实例中的所有颜色附件都具有 VK_IMAGE_TILING_LINEAR 平铺时，此扩展增加了对使用 VK_IMAGE_TILING_LINEAR 图像作为颜色附件的支持。此扩展添加了一个新的标志位 VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV，它扩展了现有的 VkFormatFeatureFlagBits2KHR 位。对于 VkFormatProperties3KHR::linearTilingFeatures 格式属性结构成员中可渲染的颜色格式，可以设置此标志。只要渲染通道实例中的所有颜色附件都具有 VK_IMAGE_TILING_LINEAR 平铺，并且创建其图像视图的格式具有 VkFormatProperties3KHR::linearTilingFeatures，其中包含 VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV，则具有 VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV 标志的格式**可以**用作颜色附件。此扩展支持动态渲染和传统渲染通道。

新结构体

新枚举常量

  • VK_NV_LINEAR_COLOR_ATTACHMENT_EXTENSION_NAME

  • VK_NV_LINEAR_COLOR_ATTACHMENT_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINEAR_COLOR_ATTACHMENT_FEATURES_NV

如果支持 VK_KHR_format_feature_flags2 或 Vulkan 1.3 版本

版本历史

  • 修订版 1, 2021-11-29 (sourav parmar)

    • 初始草案

VK_NV_low_latency

名称字符串

VK_NV_low_latency

扩展类型

设备扩展

注册扩展号

311

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2023-02-10

贡献者

  • Charles Hansen, NVIDIA

描述

此扩展添加了 VkQueryLowLatencySupportNV 结构体，该结构体用于查询对 NVIDIA Reflex 的支持。

新结构体

新枚举常量

  • VK_NV_LOW_LATENCY_EXTENSION_NAME

  • VK_NV_LOW_LATENCY_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_QUERY_LOW_LATENCY_SUPPORT_NV

问题

1) 为什么 VkQueryLowLatencySupportNV 在输入链中具有输出参数？

已解决：由于遗留原因，我们不得不这样做 - 我们知道这是不良行为，不应将其用作未来扩展的先例。

版本历史

  • 修订版 1, 2023-02-10 (Charles Hansen)

    • 内部修订

VK_NV_low_latency2

名称字符串

VK_NV_low_latency2

扩展类型

设备扩展

注册扩展号

506

修订

2

批准状态

未批准

扩展和版本依赖关系

Vulkan 版本 1.2
或
VK_KHR_timeline_semaphore

联系方式

其他扩展元数据

上次修改日期

2023-09-25

贡献者

  • Charles Hansen, NVIDIA

  • Liam Middlebrook, NVIDIA

  • Lionel Duc, NVIDIA

  • James Jones, NVIDIA

  • Eric Sullivan, NVIDIA

新命令

新结构体

新枚举

新枚举常量

  • VK_NV_LOW_LATENCY_2_EXTENSION_NAME

  • VK_NV_LOW_LATENCY_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_GET_LATENCY_MARKER_INFO_NV

    • VK_STRUCTURE_TYPE_LATENCY_SLEEP_INFO_NV

    • VK_STRUCTURE_TYPE_LATENCY_SLEEP_MODE_INFO_NV

    • VK_STRUCTURE_TYPE_LATENCY_SUBMISSION_PRESENT_ID_NV

    • VK_STRUCTURE_TYPE_LATENCY_SURFACE_CAPABILITIES_NV

    • VK_STRUCTURE_TYPE_LATENCY_TIMINGS_FRAME_REPORT_NV

    • VK_STRUCTURE_TYPE_OUT_OF_BAND_QUEUE_TYPE_INFO_NV

    • VK_STRUCTURE_TYPE_SET_LATENCY_MARKER_INFO_NV

    • VK_STRUCTURE_TYPE_SWAPCHAIN_LATENCY_CREATE_INFO_NV

描述

此扩展为应用程序提供关于何时开始记录新帧的时间建议，以减少输入采样和帧呈现之间的延迟。应用程序可以通过调用 vkSetLatencySleepModeNV 来允许驱动程序调整给定交换链的步调，然后在使用输入采样之前调用 vkLatencySleepNV 以延迟 CPU 端工作的开始，从而通过扩展实现此目的。还提供了其他方法和结构，以通过延迟标记来深入了解应用程序的延迟管道。VK_NV_low_latency 为使用 NVIDIA Reflex SDK 的应用程序提供遗留支持，而新的实现应使用 VK_NV_low_latency2 扩展。

问题

1) 低延迟 2 如何与使用设备组的应用程序一起工作？

低延迟 2 不支持设备组。

版本历史

  • 修订版 2, 2023-11-15 (Charles Hansen)

  • 修订版 1, 2023-09-25 (Charles Hansen)

    • 内部修订

VK_NV_memory_decompression

名称字符串

VK_NV_memory_decompression

扩展类型

设备扩展

注册扩展号

428

修订

1

批准状态

未批准

扩展和版本依赖关系

         VK_KHR_get_physical_device_properties2
         或
         Vulkan 版本 1.1
     和
     VK_KHR_buffer_device_address
或
Vulkan 版本 1.2

联系方式

其他扩展元数据

上次修改日期

2022-01-31

贡献者

  • Vikram Kushwaha, NVIDIA

  • Jeff Bolz, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Piers Daniell, NVIDIA

描述

此扩展增加了对执行内存到内存解压缩的支持。

新命令

新结构体

新枚举

新位掩码

新的枚举常量

  • VK_NV_MEMORY_DECOMPRESSION_EXTENSION_NAME

  • VK_NV_MEMORY_DECOMPRESSION_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_DECOMPRESSION_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_DECOMPRESSION_PROPERTIES_NV

版本历史

  • 修订版 1，2022-01-31 (Vikram Kushwaha)

    • 初始草案

VK_NV_mesh_shader

名称字符串

VK_NV_mesh_shader

扩展类型

设备扩展

注册扩展号

203

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

API 交互

  • 与 VK_VERSION_1_2 交互

  • 与 VK_EXT_device_generated_commands 交互

  • 与 VK_KHR_draw_indirect_count 交互

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2018-07-19

交互和外部依赖
贡献者

  • Pat Brown, NVIDIA

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

  • Piers Daniell, NVIDIA

  • Pierre Boudier, NVIDIA

描述

此扩展提供了一种新机制，允许应用程序通过可编程网格着色生成几何图元集合。 它是现有可编程图元着色管线的替代方案，该管线依赖于通过固定函数汇编程序以及固定函数顶点提取来生成输入图元。

存在新的可编程着色器类型——任务着色器和网格着色器——用于生成这些集合，以便由固定功能的图元组装和光栅化逻辑处理。当调度任务着色器和网格着色器时，它们会替换核心的预光栅化阶段，包括顶点数组属性获取、顶点着色器处理、细分和几何着色器处理。

此扩展还在 Vulkan 中增加了对以下 SPIR-V 扩展的支持

新命令

如果支持 VK_KHR_draw_indirect_count 或 Vulkan 版本 1.2

新结构体

新的枚举常量

  • VK_NV_MESH_SHADER_EXTENSION_NAME

  • VK_NV_MESH_SHADER_SPEC_VERSION

  • 扩展 VkPipelineStageFlagBits

    • VK_PIPELINE_STAGE_MESH_SHADER_BIT_NV

    • VK_PIPELINE_STAGE_TASK_SHADER_BIT_NV

  • 扩展 VkShaderStageFlagBits

    • VK_SHADER_STAGE_MESH_BIT_NV

    • VK_SHADER_STAGE_TASK_BIT_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_PROPERTIES_NV

如果支持 VK_EXT_device_generated_commands

  • 扩展 VkIndirectCommandsTokenTypeEXT

    • VK_INDIRECT_COMMANDS_TOKEN_TYPE_DRAW_MESH_TASKS_COUNT_NV_EXT

    • VK_INDIRECT_COMMANDS_TOKEN_TYPE_DRAW_MESH_TASKS_NV_EXT

新的或修改的内置变量

新的 SPIR-V 功能

问题

  1. 如何命名此扩展？

    已解决：VK_NV_mesh_shader

    其他考虑的选项

    • VK_NV_mesh_shading

    • VK_NV_programmable_mesh_shading

    • VK_NV_primitive_group_shading

    • VK_NV_grouped_drawing

  2. 我们需要一个新的 VkPrimitiveTopology 吗？

    已解决：否。我们跳过 InputAssembler 阶段。

  3. 我们应该允许实例化吗？

    已解决：否。除了 ID 之外，没有固定的功能输入。但是，允许使用“first”值进行偏移。

  4. 我们应该使用现有的 vkCmdDraw 还是引入新函数？

    已解决：引入新函数。

    新函数更容易与“可编程图元着色”章节分开，减少关于现有函数具有替代行为的“双重用途”语言。围绕现有“绘制”的文本很大程度上基于发射顶点。

  5. 如果是新函数，如何命名？

    已解决：CmdDrawMeshTasks*

    其他考虑的选项

    • CmdDrawMeshed

    • CmdDrawTasked

    • CmdDrawGrouped

  6. VK_SHADER_STAGE_ALL_GRAPHICS 是否应更新以包含新阶段？

    已解决：否。如果应用程序要使用在 VK_SHADER_STAGE_ALL_GRAPHICS 中包含额外着色器阶段位的标头进行重新编译，那么先前有效的应用程序在不支持网格或任务着色器的实现上将不再有效。这意味着该更改不向后兼容。可惜的是，VkShaderStageFlagBits 没有像 VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT 那样专用的“所有支持的图形阶段”位，这将避免此问题。

版本历史

  • 修订版 1，2018-07-19 (Christoph Kubisch, Daniel Koch)

    • 内部修订

VK_NV_optical_flow

名称字符串

VK_NV_optical_flow

扩展类型

设备扩展

注册扩展号

465

修订

1

批准状态

未批准

扩展和版本依赖关系

         VK_KHR_get_physical_device_properties2
         或
         Vulkan 版本 1.1
     和
     VK_KHR_format_feature_flags2
     和
     VK_KHR_synchronization2
或
Vulkan 版本 1.3

联系方式

其他扩展元数据

上次修改日期

2022-09-26

贡献者

  • Carsten Rohde, NVIDIA

  • Vipul Parashar，NVIDIA

  • Jeff Bolz, NVIDIA

  • Eric Werness, NVIDIA

描述

光流是计算机视觉 (CV) 领域的基本算法。此扩展允许应用程序估计两个帧之间像素的 2D 位移。

此扩展旨在与即将推出的 NVIDIA 光流 SDK 5 版一起使用，该版本将在 NVIDIA 开发人员网页上提供。

新对象类型

新命令

新结构体

新枚举

新位掩码

新的枚举常量

  • VK_NV_OPTICAL_FLOW_EXTENSION_NAME

  • VK_NV_OPTICAL_FLOW_SPEC_VERSION

  • 扩展 VkAccessFlagBits2

    • VK_ACCESS_2_OPTICAL_FLOW_READ_BIT_NV

    • VK_ACCESS_2_OPTICAL_FLOW_WRITE_BIT_NV

  • 扩展 VkFormat

    • VK_FORMAT_R16G16_S10_5_NV

    • VK_FORMAT_R16G16_SFIXED5_NV

  • 扩展 VkFormatFeatureFlagBits2

    • VK_FORMAT_FEATURE_2_OPTICAL_FLOW_COST_BIT_NV

    • VK_FORMAT_FEATURE_2_OPTICAL_FLOW_IMAGE_BIT_NV

    • VK_FORMAT_FEATURE_2_OPTICAL_FLOW_VECTOR_BIT_NV

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_OPTICAL_FLOW_SESSION_NV

  • 扩展 VkPipelineStageFlagBits2

    • VK_PIPELINE_STAGE_2_OPTICAL_FLOW_BIT_NV

  • 扩展 VkQueueFlagBits

    • VK_QUEUE_OPTICAL_FLOW_BIT_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_OPTICAL_FLOW_EXECUTE_INFO_NV

    • VK_STRUCTURE_TYPE_OPTICAL_FLOW_IMAGE_FORMAT_INFO_NV

    • VK_STRUCTURE_TYPE_OPTICAL_FLOW_IMAGE_FORMAT_PROPERTIES_NV

    • VK_STRUCTURE_TYPE_OPTICAL_FLOW_SESSION_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_OPTICAL_FLOW_SESSION_CREATE_PRIVATE_DATA_INFO_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPTICAL_FLOW_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPTICAL_FLOW_PROPERTIES_NV

示例

// Example querying available input formats
VkOpticalFlowImageFormatInfoNV ofFormatInfo = { VK_STRUCTURE_TYPE_OPTICAL_FLOW_IMAGE_FORMAT_INFO_NV };
ofFormatInfo.usage = VK_OPTICAL_FLOW_USAGE_INPUT_BIT_NV;

uint32_t count = 0;
vkGetPhysicalDeviceOpticalFlowImageFormatsNV(physicalDevice, &ofFormatInfo, &count, NULL);
VkOpticalFlowImageFormatPropertiesNV* fmt = new VkOpticalFlowImageFormatPropertiesNV[count];
memset(fmt, 0, count  * sizeof(VkOpticalFlowImageFormatPropertiesNV));
for (uint32_t i = 0; i < count; i++) {
    fmt[i].sType = VK_STRUCTURE_TYPE_OPTICAL_FLOW_IMAGE_FORMAT_PROPERTIES_NV;
}
vkGetPhysicalDeviceOpticalFlowImageFormatsNV(physicalDevice, &ofFormatInfo, &count, fmt);

// Pick one of the available formats
VkFormat inputFormat = fmt[0].format;

// Check feature support for optimal tiling
VkFormatProperties3 formatProperties3 = { VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_3 };
VkFormatProperties2 formatProperties2 = { VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_2, &formatProperties3 };
vkGetPhysicalDeviceFormatProperties2(physicalDevice, inputFormat, &formatProperties2);
if (!(formatProperties3.optimalTilingFeatures & VK_FORMAT_FEATURE_2_OPTICAL_FLOW_IMAGE_BIT_NV)) {
    return false;
}

// Check support for image creation parameters
VkPhysicalDeviceImageFormatInfo2 imageFormatInfo2 = { VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2, &ofFormatInfo };
imageFormatInfo2.format = inputFormat;
imageFormatInfo2.type = VK_IMAGE_TYPE_2D;
imageFormatInfo2.tiling = VK_IMAGE_TILING_OPTIMAL;
imageFormatInfo2.usage = VK_IMAGE_USAGE_SAMPLED_BIT | VK_IMAGE_USAGE_TRANSFER_DST_BIT;

VkImageFormatProperties2 imageFormatProperties2 = { VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2 };
if (vkGetPhysicalDeviceImageFormatProperties2(physicalDevice, &imageFormatInfo2, &imageFormatProperties2) != VK_SUCCESS) {
    return false;
}

VkImageCreateInfo imageCreateInfo = { VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO, &ofFormatInfo };
imageCreateInfo.imageType = VK_IMAGE_TYPE_2D;
imageCreateInfo.format = inputFormat;
imageCreateInfo.extent = { width, height, (uint32_t)1};
imageCreateInfo.mipLevels = 1;
imageCreateInfo.arrayLayers = 1;
imageCreateInfo.samples = VK_SAMPLE_COUNT_1_BIT;
imageCreateInfo.usage = VK_IMAGE_USAGE_SAMPLED_BIT | VK_IMAGE_USAGE_TRANSFER_DST_BIT;;
imageCreateInfo.tiling = VK_IMAGE_TILING_OPTIMAL;

vkCreateImage(device, &imageCreateInfo, NULL, &input);
"allocate memory, bind image, create view"

"do the same for reference and output"

// Create optical flow session
VkOpticalFlowSessionCreateInfoNV sessionCreateInfo = { VK_STRUCTURE_TYPE_OPTICAL_FLOW_SESSION_CREATE_INFO_NV };
sessionCreateInfo.width = width;
sessionCreateInfo.height = height;
sessionCreateInfo.imageFormat = inputFormat;
sessionCreateInfo.flowVectorFormat = outputFormat;
sessionCreateInfo.outputGridSize = VK_OPTICAL_FLOW_GRID_SIZE_4X4_BIT_NV;
sessionCreateInfo.performanceLevel = VK_OPTICAL_FLOW_PERFORMANCE_LEVEL_SLOW_NV;
VkOpticalFlowSessionNV session;
vkCreateOpticalFlowSessionNV(device, &sessionCreateInfo, NULL, &session);

"allocate command buffer"

"transfer images to VK_PIPELINE_STAGE_2_OPTICAL_FLOW_BIT_NV"
"transfer input images to VK_ACCESS_2_OPTICAL_FLOW_READ_BIT_NV and output image to VK_ACCESS_2_OPTICAL_FLOW_WRITE_BIT_NV"

vkBindOpticalFlowSessionImageNV(device, session, VK_OPTICAL_FLOW_SESSION_BINDING_POINT_INPUT_NV, inputView, VK_IMAGE_LAYOUT_GENERAL);
vkBindOpticalFlowSessionImageNV(device, session, VK_OPTICAL_FLOW_SESSION_BINDING_POINT_REFERENCE_NV, refView, VK_IMAGE_LAYOUT_GENERAL);
vkBindOpticalFlowSessionImageNV(device, session, VK_OPTICAL_FLOW_SESSION_BINDING_POINT_FLOW_VECTOR_NV, outputView, VK_IMAGE_LAYOUT_GENERAL);

VkOpticalFlowExecuteInfoNV opticalFlowExecuteInfo = { VK_STRUCTURE_TYPE_OPTICAL_FLOW_EXECUTE_INFO_NV };
vkCmdOpticalFlowExecuteNV(cmd, session, &opticalFlowExecuteInfo);

"submit command buffer"

版本历史

  • 修订版 1，2022-09-26 (Carsten Rohde)

    • 内部修订

VK_NV_per_stage_descriptor_set

名称字符串

VK_NV_per_stage_descriptor_set

扩展类型

设备扩展

注册扩展号

517

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_maintenance6
或
Vulkan 版本 1.4

联系方式

其他扩展元数据

上次修改日期

2023-10-16

IP 状态

没有已知的 IP 声明。

贡献者

  • Daniel Story, Nintendo

描述

此扩展引入了一个新的描述符集布局创建标志，允许描述符集中的绑定作用于每个着色器阶段。这意味着同时绑定的着色器可能使用完全不同的描述符集布局，而没有任何兼容性限制，并且原本适用于所有阶段的描述符限制将分别适用于每个阶段。这也意味着多个阶段共享的描述符必须绑定到每个阶段或使用其特定按阶段描述符集布局的阶段集合。

此扩展还允许 VK_KHR_maintenance6 中的每个新描述符绑定函数的可选地将其 VkPipelineLayout 成员设置为 VK_NULL_HANDLE，在这种情况下，管道布局信息将从 pNext 链中的 VkPipelineLayoutCreateInfo 结构中获取。这使得可以直接使用描述符集布局绑定描述符，而无需应用程序在命令记录时创建和管理 VkPipelineLayout 对象。

新结构

新枚举常量

  • VK_NV_PER_STAGE_DESCRIPTOR_SET_EXTENSION_NAME

  • VK_NV_PER_STAGE_DESCRIPTOR_SET_SPEC_VERSION

  • 扩展 VkDescriptorSetLayoutCreateFlagBits

    • VK_DESCRIPTOR_SET_LAYOUT_CREATE_PER_STAGE_BIT_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PER_STAGE_DESCRIPTOR_SET_FEATURES_NV

问题

无

版本历史

  • 修订版 1，2023-10-16 (Piers Daniell)

    • 初始草案

VK_NV_present_barrier

名称字符串

VK_NV_present_barrier

扩展类型

设备扩展

注册扩展号

293

修订

1

批准状态

未批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
    或
     Vulkan 版本 1.1
和
VK_KHR_surface
和
VK_KHR_get_surface_capabilities2
和
VK_KHR_swapchain

联系方式

其他扩展元数据

上次修改日期

2022-05-16

贡献者

  • Liya Li，Nvidia

  • Martin Schwarzer，Nvidia

  • Andy Wolf，Nvidia

  • Ian Williams，Nvidia

  • Ben Morris，Nvidia

  • James Jones，Nvidia

  • Jeff Juliano，Nvidia

描述

此扩展添加了使用present barrier跨多个交换链同步相应呈现请求的支持。

新结构

新枚举常量

  • VK_NV_PRESENT_BARRIER_EXTENSION_NAME

  • VK_NV_PRESENT_BARRIER_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_BARRIER_FEATURES_NV

    • VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_PRESENT_BARRIER_NV

    • VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_BARRIER_CREATE_INFO_NV

问题

1) 是否有查询接口来检查交换链是否正在使用 present barrier？

已解决。没有这样的查询接口。创建交换链时，应用程序可以指定使用present barrier，如果交换链成功创建，则此交换链将使用 present barrier。

2) 我们是否需要额外的接口来设置分布式系统中的 present barrier？

已解决。如果系统中存在所需的硬件，并且已设置与其它系统的物理同步的所有设置，则实现会在创建交换链时自动管理配置，而无需应用程序进行任何额外的调用。

版本历史

  • 修订版 1，2022-07-20

    • 初始版本

VK_NV_raw_access_chains

名称字符串

VK_NV_raw_access_chains

扩展类型

设备扩展

注册扩展号

556

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2023-12-04

交互和外部依赖
贡献者

  • Hans-Kristian Arntzen, Valve

  • Rodrigo Locatti, NVIDIA

描述

此扩展允许在 SPIR-V 着色器模块中使用 SPV_NV_raw_access_chains 扩展。这使得 SPIR-V 生成器能够有效地实现类似于 Direct3D 结构化缓冲区和字节地址缓冲区的接口，从而允许从 HLSL 源代码编译的着色器生成更高效的代码。

新的 SPIR-V 功能

版本历史

  • 修订版 1，2023-12-04 (Rodrigo Locatti)

    • 初始修订版

VK_NV_ray_tracing_invocation_reorder

名称字符串

VK_NV_ray_tracing_invocation_reorder

扩展类型

设备扩展

注册扩展号

491

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_ray_tracing_pipeline

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2022-11-02

交互和外部依赖
贡献者

  • Eric Werness, NVIDIA

  • Ashwin Lele, NVIDIA

描述

光线追踪管道 API 提供了一些重新排序以提高局部性的能力，但更好地控制重新排序的发生方式以及重新排序中包含哪些信息是有用的。着色器 API 提供了一个命中对象来包含来自命中的结果信息，该信息可以用作显式排序的一部分，以及包含用于添加更多局部性的提示位的整数的选项。

新结构

新枚举

新枚举常量

  • VK_NV_RAY_TRACING_INVOCATION_REORDER_EXTENSION_NAME

  • VK_NV_RAY_TRACING_INVOCATION_REORDER_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_INVOCATION_REORDER_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_INVOCATION_REORDER_PROPERTIES_NV

HLSL 映射

HLSL 尚未原生提供此功能。

但是，可以通过 SPIR-V Intrinsics 使用此功能。

着色器调用重新排序的代码从此页面获取

#define ShaderInvocationReorderNV 5383
#define HitObjectAttributeNV 5385

#define OpHitObjectRecordHitMotionNV 5249
#define OpHitObjectRecordHitWithIndexMotionNV 5250
#define OpHitObjectRecordMissMotionNV 5251
#define OpHitObjectGetWorldToObjectNV 5252
#define OpHitObjectGetObjectToWorldNV 5253
#define OpHitObjectGetObjectRayDirectionNV 5254
#define OpHitObjectGetObjectRayOriginNV 5255
#define OpHitObjectTraceRayMotionNV 5256
#define OpHitObjectGetShaderRecordBufferHandleNV 5257
#define OpHitObjectGetShaderBindingTableRecordIndexNV 5258
#define OpHitObjectRecordEmptyNV 5259
#define OpHitObjectTraceRayNV 5260
#define OpHitObjectRecordHitNV 5261
#define OpHitObjectRecordHitWithIndexNV 5262
#define OpHitObjectRecordMissNV 5263
#define OpHitObjectExecuteShaderNV 5264
#define OpHitObjectGetCurrentTimeNV 5265
#define OpHitObjectGetAttributesNV 5266
#define OpHitObjectGetHitKindNV 5267
#define OpHitObjectGetPrimitiveIndexNV 5268
#define OpHitObjectGetGeometryIndexNV 5269
#define OpHitObjectGetInstanceIdNV 5270
#define OpHitObjectGetInstanceCustomIndexNV 5271
#define OpHitObjectGetWorldRayDirectionNV 5272
#define OpHitObjectGetWorldRayOriginNV 5273
#define OpHitObjectGetRayTMaxNV 5274
#define OpHitObjectGetRayTMinNV 5275
#define OpHitObjectIsEmptyNV 5276
#define OpHitObjectIsHitNV 5277
#define OpHitObjectIsMissNV 5278
#define OpReorderThreadWithHitObjectNV 5279
#define OpReorderThreadWithHintNV 5280
#define OpTypeHitObjectNV 5281

需要添加功能和扩展

[[vk::ext_capability(ShaderInvocationReorderNV)]]
[[vk::ext_extension("SPV_NV_shader_invocation_reorder")]]

HitObject 类型的创建可以像这样完成

[[vk::ext_type_def(HitObjectAttributeNV, OpTypeHitObjectNV)]]
void createHitObjectNV();
#define HitObjectNV vk::ext_type<HitObjectAttributeNV>

有效负载

  • 必须是全局的

  • 需要 RayPayloadKHR 属性作为额外的存储类

struct [raypayload] HitPayload
{
  float hitT : write(closesthit, miss) : read(caller);
  int instanceIndex : write(closesthit) : read(caller);
  float3 pos : write(closesthit) : read(caller);
  float3 nrm : write(closesthit) : read(caller);
};

#define RayPayloadKHR 5338
[[vk::ext_storage_class(RayPayloadKHR)]] static HitPayload payload;

以下是一些调用重新排序函数的声明

[[vk::ext_instruction(OpHitObjectRecordEmptyNV)]]
void hitObjectRecordEmptyNV([[vk::ext_reference]] HitObjectNV hitObject);

[[vk::ext_instruction(OpHitObjectTraceRayNV)]]
void hitObjectTraceRayNV(
    [[vk::ext_reference]] HitObjectNV hitObject,
    RaytracingAccelerationStructure as,
    uint RayFlags,
    uint CullMask,
    uint SBTOffset,
    uint SBTStride,
    uint MissIndex,
    float3 RayOrigin,
    float RayTmin,
    float3 RayDirection,
    float RayTMax,
    [[vk::ext_reference]] [[vk::ext_storage_class(RayPayloadKHR)]] HitPayload payload
  );

[[vk::ext_instruction(OpReorderThreadWithHintNV)]]
void reorderThreadWithHintNV(int Hint, int Bits);

[[vk::ext_instruction(OpReorderThreadWithHitObjectNV)]]
void reorderThreadWithHitObjectNV([[vk::ext_reference]] HitObjectNV hitObject);

[[vk::ext_instruction(OpHitObjectExecuteShaderNV)]]
void hitObjectExecuteShaderNV([[vk::ext_reference]] HitObjectNV hitObject, [[vk::ext_reference]] [[vk::ext_storage_class(RayPayloadKHR)]] HitPayload payload);

[[vk::ext_instruction(OpHitObjectIsHitNV)]]
bool hitObjectIsHitNV([[vk::ext_reference]] HitObjectNV hitObject);

使用代码中的函数，可以像这样完成：

  if (USE_SER == 1)
  {
    createHitObjectNV();
    HitObjectNV hObj; //  hitObjectNV hObj;
    hitObjectRecordEmptyNV(hObj); //Initialize to an empty hit object
    hitObjectTraceRayNV(hObj, topLevelAS, rayFlags, 0xFF, 0, 0, 0, r.Origin, 0.0, r.Direction, INFINITE, payload);
    reorderThreadWithHitObjectNV(hObj);
    hitObjectExecuteShaderNV(hObj, payload);
  }

注意

  • createHitObjectNV() 至少需要调用一次。这也可以在着色器的主入口中完成。

  • 带有负载参数的函数，需要在之前定义负载结构。该函数没有模板化声明。

版本历史

  • 修订版 1，2020-09-12 (Eric Werness, Ashwin Lele)

    • 初始外部发布

VK_NV_ray_tracing_motion_blur

名称字符串

VK_NV_ray_tracing_motion_blur

扩展类型

设备扩展

注册扩展号

328

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_ray_tracing_pipeline

SPIR-V 依赖项
联系方式

  • Eric Werness

其他扩展元数据

上次修改日期

2021-06-16

交互和外部依赖
贡献者

  • Eric Werness, NVIDIA

  • Ashwin Lele, NVIDIA

描述

API 中的光线追踪支持提供了一种高效的机制来对静态几何体进行光线相交测试，但是渲染算法通常希望支持运动，而运动使用特定于运动的算法可以更有效地支持。此扩展添加了一组机制来支持快速追踪移动几何体

  • 一个带有时间参数的光线管线追踪调用

  • 用于在加速结构中启用运动支持的标志

  • 支持几何体中随时间变化的顶点位置

  • 随时间移动现有实例的运动实例

此处表示的运动在 0.0 到 1.0 之间的标准化时间步长上进行参数化。使用 OpTraceRayMotionNV 的运动追踪提供了该标准化范围内的某个时间，用于与几何体相交光线。可以通过组合使用 VkAccelerationStructureGeometryMotionTrianglesDataNV 为时间 1.0 添加第二个顶点位置，以及使用 VkAccelerationStructureMotionInstanceNV 在实例中提供多个变换，从而为几何体提供运动。

新结构

新联合

新枚举

新位掩码

新枚举常量

问题

(1) VkAccelerationStructureMotionInstanceNV 的大小是多少？

  • 添加了有关结构大小的注释，并在语言中明确了步幅。

(2) 允许用于运动 TLAS 的 arrayOfPointers 吗？

  • 是的，使用打包编码来最大程度地减少发送的元数据量。

版本历史

  • 修订版 1，2020-06-16 (Eric Werness, Ashwin Lele)

    • 初始外部发布

VK_NV_ray_tracing_validation

名称字符串

VK_NV_ray_tracing_validation

扩展类型

设备扩展

注册扩展号

569

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式
扩展提案

VK_NV_ray_tracing_validation

其他扩展元数据

上次修改日期

2024-03-04

贡献者

  • Vikram Kushwaha, NVIDIA

  • Eric Werness, NVIDIA

  • Piers Daniell, NVIDIA

描述

此扩展添加了在实现级别执行光线追踪验证的支持。

新结构

新枚举常量

  • VK_NV_RAY_TRACING_VALIDATION_EXTENSION_NAME

  • VK_NV_RAY_TRACING_VALIDATION_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_VALIDATION_FEATURES_NV

版本历史

  • 修订版 1，2024-03-04 (Vikram Kushwaha)

    • 初始草案

VK_NV_representative_fragment_test

名称字符串

VK_NV_representative_fragment_test

扩展类型

设备扩展

注册扩展号

167

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2018-09-13

贡献者

  • Kedarnath Thangudu，NVIDIA

  • Christoph Kubisch, NVIDIA

  • Pierre Boudier, NVIDIA

  • Pat Brown, NVIDIA

  • Jeff Bolz, NVIDIA

  • Eric Werness, NVIDIA

描述

此扩展提供了一种新的代表性片段测试，允许实现减少为每个点、线或三角形图元执行的栅格化和片段处理工作量。对于任何生成一个或多个通过所有其他早期片段测试的片段的图元，允许实现选择一个或多个“代表性”片段进行处理并丢弃所有其他片段。对于渲染列表、条带或扇形排列的多个点、线或三角形的绘制调用，代表性片段测试是针对每个图元独立执行的。

此扩展对于使用早期渲染通道来确定最终场景中可见的图元的完整集合的应用程序很有用。在此渲染通道中，此类应用程序将设置一个启用早期片段测试并写入图像或着色器存储缓冲区的片段着色器，以记录生成该片段的图元的 ID。如果没有此扩展，着色器将为每个图元的每个可见片段单独记录 ID。使用此扩展，将执行更少的存储操作，特别是对于大型图元。

如果未通过片段着色器启用早期片段测试，则代表性片段测试无效。代表性片段测试丢弃的片段集取决于实现，并且可能逐帧变化。在某些情况下，代表性片段测试可能不会丢弃给定图元的任何片段。

新结构

新枚举常量

  • VK_NV_REPRESENTATIVE_FRAGMENT_TEST_EXTENSION_NAME

  • VK_NV_REPRESENTATIVE_FRAGMENT_TEST_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_REPRESENTATIVE_FRAGMENT_TEST_FEATURES_NV

    • VK_STRUCTURE_TYPE_PIPELINE_REPRESENTATIVE_FRAGMENT_TEST_STATE_CREATE_INFO_NV

问题

(1) 是否保证代表性片段测试会产生任何效果？

已解决：否。如指定，我们仅保证每个至少有一个通过先前测试的片段的图元将有一个片段通过代表性片段测试。我们不保证任何特定片段将无法通过测试。

在此扩展的初始实现中，代表性片段测试被视为一种优化，对于某些管线状态可能会完全禁用。此功能是为片段着色器使用着色器存储缓冲区或存储图像记录单个图元上的信息而设计的，不写入颜色或深度缓冲区。

(2) 如果你一遍又一遍地绘制同一个场景，通过代表性片段测试的片段集合是否可重复？

已解决：否。通过代表性片段测试的片段集合是与实现相关的，并且可能因 GPU 执行操作的时序而异。

(3) 如果启用代表性片段测试并启用对颜色和/或深度渲染目标的写入，会发生什么？

已解决：如果启用了对颜色或深度缓冲区的写入，则将对通过相关测试的任何片段执行写入。任何未通过代表性片段测试的片段都不会更新颜色缓冲区。对于此功能的目标用例，我们不希望启用颜色或深度写入。

(4) 启用代表性片段测试后，导数和自动纹理 LOD 计算如何工作？

已解决：如果片段着色器使用导数函数或使用自动 LOD 计算的纹理查找，则无论是否启用代表性片段测试，都将以相同的方式计算导数。对于此功能的目标用例，我们不希望在片段着色器中使用导数。

版本历史

  • 修订版 2，2018-09-13 (pbrown)

    • 添加问题。

  • 修订版 1，2018-08-22 (Kedarnath Thangudu)

    • 内部修订

VK_NV_sample_mask_override_coverage

名称字符串

VK_NV_sample_mask_override_coverage

扩展类型

设备扩展

注册扩展号

95

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2016-12-08

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

  • SPV_NV_sample_mask_override_coverage

该扩展提供了在 SampleMaskOverrideCoverageNV 功能下访问 OverrideCoverageNV 修饰符的权限。将此修饰符添加到带有 SampleMask 内置修饰符的变量，允许着色器修改覆盖掩码，并影响使用哪些采样来处理片段。

当使用基于 GLSL 源的着色器语言时，来自 GL_NV_sample_mask_override_coverage 的 override_coverage 布局限定符映射到 OverrideCoverageNV 修饰符。要在 GLSL 中使用 override_coverage 布局限定符，必须启用 GL_NV_sample_mask_override_coverage 扩展。行为在 GL_NV_sample_mask_override_coverage 扩展规范中描述。

新枚举常量

  • VK_NV_SAMPLE_MASK_OVERRIDE_COVERAGE_EXTENSION_NAME

  • VK_NV_SAMPLE_MASK_OVERRIDE_COVERAGE_SPEC_VERSION

新变量修饰符

新的 SPIR-V 功能

版本历史

  • 修订版 1，2016-12-08 (Piers Daniell)

    • 内部修订

VK_NV_scissor_exclusive

名称字符串

VK_NV_scissor_exclusive

扩展类型

设备扩展

注册扩展号

206

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2023-01-18

IP 状态

没有已知的 IP 声明。

交互和外部依赖

无

贡献者

  • Pat Brown, NVIDIA

  • Jeff Bolz, NVIDIA

  • Piers Daniell, NVIDIA

  • Daniel Koch, NVIDIA

描述

此扩展为 Vulkan 添加了对独占剪裁测试的支持。独占剪裁测试的行为类似于剪裁测试，不同之处在于独占剪裁测试对于对应矩形内的像素失败，对于矩形外的像素通过。如果剪裁测试和独占剪裁测试使用相同的矩形，则当且仅当剪裁测试失败时，独占剪裁测试才会通过。

此扩展的第 2 版引入了 VK_DYNAMIC_STATE_EXCLUSIVE_SCISSOR_ENABLE_NV 和 vkCmdSetExclusiveScissorEnableNV。使用此动态状态的应用程序必须确保实现至少声明此扩展的 specVersion 2。

新命令

新结构

新枚举常量

  • VK_NV_SCISSOR_EXCLUSIVE_EXTENSION_NAME

  • VK_NV_SCISSOR_EXCLUSIVE_SPEC_VERSION

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_EXCLUSIVE_SCISSOR_ENABLE_NV

    • VK_DYNAMIC_STATE_EXCLUSIVE_SCISSOR_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXCLUSIVE_SCISSOR_FEATURES_NV

    • VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_EXCLUSIVE_SCISSOR_STATE_CREATE_INFO_NV

问题

1) 对于剪裁测试，视口状态必须使用匹配数量的剪裁和视口矩形创建。对于独占剪裁，我们是否应该有相同的要求？

已解决：对于独占剪裁，我们放宽了此要求，并允许独占剪裁矩形计数为零或等于视口矩形的数量。如果您传入的独占剪裁计数为零，则独占剪裁测试将被视为禁用。

版本历史

  • 修订版 2，2023-01-18 (Piers Daniell)

    • 为显式独占剪裁启用添加动态状态

  • 修订版 1，2018-07-31 (Pat Brown)

    • 内部修订

VK_NV_shader_atomic_float16_vector

名称字符串

VK_NV_shader_atomic_float16_vector

扩展类型

设备扩展

注册扩展号

564

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2024-02-03

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展允许着色器对 float16 的 2 分量和 4 分量向量执行原子加、最小值、最大值和交换操作。所有支持缓冲区、工作组和图像存储类。

新结构

新枚举常量

  • VK_NV_SHADER_ATOMIC_FLOAT16_VECTOR_EXTENSION_NAME

  • VK_NV_SHADER_ATOMIC_FLOAT16_VECTOR_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_FLOAT16_VECTOR_FEATURES_NV

问题

无。

新的 SPIR-V 功能

版本历史

  • 修订版 1，2024-02-03 (Jeff Bolz)

    • 内部修订

VK_NV_shader_image_footprint

名称字符串

VK_NV_shader_image_footprint

扩展类型

设备扩展

注册扩展号

205

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2018-09-13

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Pat Brown, NVIDIA

  • Chris Lentini, NVIDIA

  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

描述

此扩展为 SPV_NV_shader_image_footprint SPIR-V 扩展添加了 Vulkan 支持。该 SPIR-V 扩展提供了一个新的指令 OpImageSampleFootprintNV，允许着色器确定等效过滤纹理查找将访问的纹素集合。

该指令不是返回过滤后的纹理值，而是返回一个可以由着色器代码解释的结构，以确定过滤后的纹理查找的足迹。此结构包括整数值，用于标识正在访问的图像中的一个小区域的纹素，以及一个位域，指示将使用该区域中的哪些纹素。该结构还包括一个位域，其中每个位标识纹素的每个小对齐块中的任何纹素是否将被纹理查找提取。每个块的大小由着色器提供的访问粒度指定。此扩展支持的最小粒度为 2x2（对于 2D 纹理）和 2x2x2（对于 3D 纹理）；最大粒度为 256x256（对于 2D 纹理）或 64x32x32（对于 3D 纹理）。每个足迹查询都会返回来自单个纹理级别的足迹。当使用结合来自多个 mipmap 级别的访问的缩小过滤器时，着色器必须对访问的两个级别（“精细”和“粗略”）执行单独的查询。足迹查询还会返回一个标志，指示纹理查找是仅访问来自一个 mipmap 级别的纹素还是来自两个相邻级别的纹素。

此扩展对于执行初始昂贵的渲染通道以生成第一张图像，然后将该图像用作第二通道纹理的多通道渲染操作很有用。如果第二通道最终仅访问第一张图像的部分区域（例如，由于可见性），则花费在渲染第一张图像的未访问部分的工作将被浪费。使用此功能，应用程序可以通过对第二张图像中的几何体执行初始通道来限制这种浪费，该通道对每个可见像素执行足迹查询，以确定它需要来自第一张图像的像素集。此通道将使用着色器原子操作将所有可见像素的聚合足迹累积到单独的“足迹图像”中。然后，在渲染第一张图像时，应用程序可以终止此聚合足迹中不包含的像素的所有着色工作。

此扩展存在一些限制。 OpImageSampleFootprintNV 指令仅支持二维和三维纹理。足迹评估仅支持 CLAMP_TO_EDGE 包裹模式；对于所有其他包裹模式，结果是未定义的。仅支持一组有限的粒度值，并且该组不支持原始图像中每个纹素的单独覆盖信息。

当使用从 OpenGL 着色语言生成的 SPIR-V 时，新指令将从使用 GL_NV_shader_texture_footprint 着色语言扩展中的新 textureFootprint*NV 内置函数的代码生成。

新结构

新枚举常量

  • VK_NV_SHADER_IMAGE_FOOTPRINT_EXTENSION_NAME

  • VK_NV_SHADER_IMAGE_FOOTPRINT_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_IMAGE_FOOTPRINT_FEATURES_NV

新的 SPIR-V 功能

问题

(1) SPIR-V 指令返回的足迹是一个结构，其中包括锚点、偏移量和一个表示 8x8 或 4x4x4 纹素组邻域的掩码。但是掩码的位不是以简单的步幅顺序存储的。为什么足迹是这样构建的？

已解决：我们预计使用此功能的应用程序将希望使用固定的粒度，并将返回的足迹中的覆盖信息累积到聚合的“足迹图像”中，该图像跟踪常规纹理过滤所需的图像部分。如果应用程序使用具有 4x4 像素粒度的二维图像，我们预计足迹图像将使用 64 位纹素，其中 8x8 位数组中的每一位对应于原始图像中 4x4 块的覆盖率。足迹图像中的纹素 (0,0) 将对应于原始图像中的纹素 (0,0) 到 (31,31)。

通常情况下，单个访问的足迹将完全包含在原始纹理的 32x32 对齐区域中，该区域对应于足迹图像中的单个 64 位纹素。在这种情况下，实现将返回指向单个足迹图像纹素的锚点坐标、(0,0) 的偏移量向量以及其位与足迹纹素中的位对齐的掩码。对于这种情况，着色器可以简单地将掩码位原子地 OR 到足迹纹素的内容中以累积足迹覆盖率。

在最坏的情况下，单个访问的足迹跨越多个 32x32 对齐区域，并且可能需要更新四个单独的足迹图像纹素。在这种情况下，实现将返回指向右下足迹图像纹素的锚点坐标，并且偏移量将标识返回的 8x8 掩码的多少“列”和“行”对应于锚点纹素左侧和上方的足迹纹素。如果锚点为 (2,3)，则返回的掩码的 64 位在空间上按如下方式排列，其中每个 4x4 块被分配一个与其在足迹图像纹素中的位号匹配的位号

    +-------------------------+-------------------------+
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- 46 47 | 40 41 42 43 44 45 -- -- |
    | -- -- -- -- -- -- 54 55 | 48 49 50 51 52 53 -- -- |
    | -- -- -- -- -- -- 62 63 | 56 57 58 59 60 61 -- -- |
    +-------------------------+-------------------------+
    | -- -- -- -- -- -- 06 07 | 00 01 02 03 04 05 -- -- |
    | -- -- -- -- -- -- 14 15 | 08 09 10 11 12 13 -- -- |
    | -- -- -- -- -- -- 22 23 | 16 17 18 19 20 21 -- -- |
    | -- -- -- -- -- -- 30 31 | 24 25 26 27 28 29 -- -- |
    | -- -- -- -- -- -- 38 39 | 32 33 34 35 36 37 -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    +-------------------------+-------------------------+

为了累积四个足迹图像纹素中的每一个的覆盖率，着色器可以将返回的掩码与从 x 和 y 偏移值导出的简单掩码进行 AND 运算，然后将更新的掩码位原子地 OR 到相应的足迹纹素的内容中。

    uint64_t returnedMask = (uint64_t(footprint.mask.x) | (uint64_t(footprint.mask.y) << 32));
    uint64_t rightMask    = ((0xFF >> footprint.offset.x) * 0x0101010101010101UL);
    uint64_t bottomMask   = 0xFFFFFFFFFFFFFFFFUL >> (8 * footprint.offset.y);
    uint64_t bottomRight  = returnedMask & bottomMask & rightMask;
    uint64_t bottomLeft   = returnedMask & bottomMask & (~rightMask);
    uint64_t topRight     = returnedMask & (~bottomMask) & rightMask;
    uint64_t topLeft      = returnedMask & (~bottomMask) & (~rightMask);

(2) 应用程序应该如何操作以确保在将足迹累积到聚合足迹图像中时获得最佳性能？

已解决：我们预计此功能最常见的用法将是累积聚合足迹覆盖率，如上一个问题中所述。即使忽略实现可能返回大于调用者请求的粒度的各向异性过滤情况，每个着色器调用也需要使用原子函数来更新每个访问的 LOD 的最多四个足迹图像纹素。让每个活动的着色器调用执行多个原子操作可能很昂贵，尤其是在相邻的调用想要更新相同的足迹图像纹素时。

可以使用以下技术来减少累积覆盖率时执行的原子操作的数量

  • 具有检测返回的足迹的逻辑，其中返回的偏移量向量的所有分量均为零。在这种情况下，足迹函数返回的掩码保证与足迹图像纹素对齐，并且仅影响单个足迹图像纹素。

  • 使用 VK_NV_shader_subgroup_partitioned 扩展或其他着色器子组扩展中的内置函数进行通信的片段着色器。如果在子组中有多个调用需要更新足迹图像中相同的纹素 (x,y)，则在更新该纹素的子组中的所有调用中计算聚合足迹掩码，并让单个调用使用该聚合掩码执行原子操作。

  • 当返回的足迹在足迹图像中跨越多个纹素时，每次调用都需要执行四个原子操作。在之前的问题中，我们有一个示例，计算了“左上”、“右上”、“左下”和“右下”的单独掩码。当子组中的调用具有良好的局部性时，可能会出现这种情况，即某些调用的“左上”可能指的是足迹图像纹素 (10,10)，而邻居的“左上”纹素可能在 (11,10)、(10,11) 和 (11,11)。如果你为偶数/奇数 x 和 y 值计算单独的掩码，而不是左/右或上/下，则子组中所有调用的“奇数/奇数”掩码将保持对足迹图像纹素 (11,11) 的覆盖，这可以通过整个子组的单个原子操作来更新。

示例

待定

版本历史

  • 修订版 2，2018-09-13 (Pat Brown)

    • 添加了包含性能提示的问题 (2)。

  • 修订版 1，2018-08-12 (Pat Brown)

    • 初始草案

VK_NV_shader_sm_builtins

名称字符串

VK_NV_shader_sm_builtins

扩展类型

设备扩展

注册扩展号

155

修订

1

批准状态

未批准

扩展和版本依赖关系

Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2019-05-28

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

  • Eric Werness, NVIDIA

描述

此扩展提供了确定 NVIDIA GPU 上特定于设备的属性的功能。它提供了流式多处理器 (SM) 的数量、可以在 SM 上运行的最大线程束（子组）数量，以及使调用能够识别着色器调用在哪个 SM 和线程束上执行的着色器内置函数。

此扩展启用了对 SPIR-V ShaderSMBuiltinsNV 功能的支持。

这些属性和内置函数通常只应用于调试目的。

新结构体

新枚举常量

  • VK_NV_SHADER_SM_BUILTINS_EXTENSION_NAME

  • VK_NV_SHADER_SM_BUILTINS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SM_BUILTINS_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SM_BUILTINS_PROPERTIES_NV

新的或修改的内置变量

新的 SPIR-V 功能

问题

  1. 我们应该如何命名此扩展？

    已解决：NV_shader_sm_builtins。考虑过的其他选项包括

    • NV_shader_smid - 但 SMID 很容易拼写错误/与 SIMD 混淆。

    • NV_shader_sm_info - 但 Info 通常保留用于输入结构体

版本历史

  • 修订版 1，2019-05-28 (Daniel Koch)

    • 内部修订

VK_NV_shader_subgroup_partitioned

名称字符串

VK_NV_shader_subgroup_partitioned

扩展类型

设备扩展

注册扩展号

199

修订

1

批准状态

未批准

扩展和版本依赖关系

Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2018-03-17

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展通过 GL_NV_shader_subgroup_partitioned GLSL 扩展和 SPV_NV_shader_subgroup_partitioned SPIR-V 扩展，支持 子组上新的组操作类。对这些新操作的支持通过 VK_SUBGROUP_FEATURE_PARTITIONED_BIT_NV 位来通告。

为了获得通用的子组支持，此扩展需要 Vulkan 1.1。

新枚举常量

  • VK_NV_SHADER_SUBGROUP_PARTITIONED_EXTENSION_NAME

  • VK_NV_SHADER_SUBGROUP_PARTITIONED_SPEC_VERSION

  • 扩展 VkSubgroupFeatureFlagBits

    • VK_SUBGROUP_FEATURE_PARTITIONED_BIT_NV

版本历史

  • 修订版 1，2018-03-17 (Jeff Bolz)

    • 内部修订

VK_NV_shading_rate_image

名称字符串

VK_NV_shading_rate_image

扩展类型

设备扩展

注册扩展号

165

修订

3

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2019-07-18

交互和外部依赖
贡献者

  • Pat Brown, NVIDIA

  • Carsten Rohde, NVIDIA

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

  • Mathias Schott, NVIDIA

  • Matthew Netsch，高通技术公司

描述

此扩展允许应用程序在处理光栅化图元的片段时使用可变着色率。默认情况下，Vulkan 会为图元覆盖的每个像素生成一个片段着色器。在此扩展中，应用程序可以绑定一个着色率图像，该图像可用于改变帧缓冲区中片段着色器调用的数量。屏幕的某些部分可以配置为为每个像素生成多达 16 个片段着色器，而其他部分可以为 4x4 的像素块使用单个片段着色器调用。这对于诸如眼睛追踪之类的用例非常有用，其中可以直接处理用户正在观看的帧缓冲区部分的高频率，而可以以较低的频率处理图像的遥远角落。着色率图像中的每个纹素表示帧缓冲区中的一个固定大小的矩形，在此扩展的初始实现中覆盖 16x16 像素。当光栅化覆盖这些矩形之一的图元时，Vulkan 实现会在绑定的着色率图像中读取一个纹素，并在调色板中查找提取的值以确定基本着色率。

除了控制光栅化的 API 支持之外，此扩展还为 SPV_NV_shading_rate 扩展添加到 SPIR-V 的 Vulkan 支持。该扩展提供了两个片段着色器变量修饰符，允许片段着色器确定用于处理该片段的着色率

  • FragmentSizeNV，指示片段着色器处理的像素集的宽度和高度。

  • InvocationsPerPixel，指示可以为片段覆盖的像素生成的片段着色器调用的最大数量。

当结合使用 SPIR-V 和 OpenGL 着色语言 (GLSL) 时，片段着色器功能由 GL_NV_shading_rate_image 语言扩展提供，并分别对应于内置变量 gl_FragmentSizeNV 和 gl_InvocationsPerPixelNV。

新命令

新结构体

新枚举

新枚举常量

  • VK_NV_SHADING_RATE_IMAGE_EXTENSION_NAME

  • VK_NV_SHADING_RATE_IMAGE_SPEC_VERSION

  • 扩展 VkAccessFlagBits

    • VK_ACCESS_SHADING_RATE_IMAGE_READ_BIT_NV

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_VIEWPORT_COARSE_SAMPLE_ORDER_NV

    • VK_DYNAMIC_STATE_VIEWPORT_SHADING_RATE_PALETTE_NV

  • 扩展 VkImageLayout

    • VK_IMAGE_LAYOUT_SHADING_RATE_OPTIMAL_NV

  • 扩展 VkImageUsageFlagBits

    • VK_IMAGE_USAGE_SHADING_RATE_IMAGE_BIT_NV

  • 扩展 VkPipelineStageFlagBits

    • VK_PIPELINE_STAGE_SHADING_RATE_IMAGE_BIT_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADING_RATE_IMAGE_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADING_RATE_IMAGE_PROPERTIES_NV

    • VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_COARSE_SAMPLE_ORDER_STATE_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_SHADING_RATE_IMAGE_STATE_CREATE_INFO_NV

问题

(1) 当使用指定覆盖多个像素的“粗糙”片段的着色率时，我们将生成一个组合的覆盖掩码，该掩码组合了片段覆盖的所有像素的覆盖掩码。默认情况下，这些掩码以依赖于实现的顺序组合。我们是否应该提供一种机制，允许应用程序查询或指定确切的顺序？

已解决：是的，此功能对于大多数片段着色器可以为整个粗糙片段评估一次，但还需要一些逐像素计算的情况很有用。例如，逐像素 alpha 测试可能想要杀死粗糙片段中某些像素的所有样本。可以使用输出样本掩码来实现这种测试，但是这样的着色器需要知道掩码中的哪个位对应于粗糙片段中的每个样本。我们正在加入一种机制，允许应用程序指定每个着色率和样本计数的覆盖样本顺序，可以作为静态管道状态，也可以通过命令缓冲区动态指定。扩展的这一部分有其自己的功能位。

我们不会提供查询来确定依赖于实现的默认排序。这里的想法是，如果应用程序足够关心粗糙片段样本排序来执行此类查询，则它可以改为设置自己的顺序，也可以在需要时使用自定义的逐像素样本位置。

(2) 对于管道阶段 VK_PIPELINE_STAGE_SHADING_RATE_IMAGE_BIT_NV，我们是否应该指定在管道中访问着色率图像的精确位置（在几何着色之后，但在早期片段测试之前），还是将其保留为未指定状态，以防有其他实现在不同的管道位置访问图像？

已解决：我们正在将管道阶段指定为最终的预栅格化着色器阶段（VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT）和用于片段处理的第一个阶段（VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT）之间，这似乎是访问着色率图像的自然位置。

(3) 质心采样的变量如何与大于一个像素的片段一起工作？

已解决：对于单像素片段，使用 Centroid 修饰的片段着色器输入在正在栅格化的图元的区域与对应于片段的像素区域的交集中的一个依赖于实现的位置采样。对于多像素片段，我们遵循类似的模式，使用图元和对应于片段的一组像素的交集。

使用这种“粗糙”着色率时，要记住的一件重要事情是，默认情况下，片段属性是在片段的中心采样的，而与片段覆盖的像素/样本集无关。对于大小为 4x4 像素的片段，此中心位置将比片段角点的像素中心远两个像素以上（1.5 * sqrt(2)）。当渲染仅覆盖粗糙片段一小部分的图元时，如果颜色值具有较大的梯度，则在图元外部采样颜色可能会产生过亮或过暗的颜色值。为了解决这个问题，应用程序可以在属性上使用质心采样，其中“外推”伪影可能导致像素过亮或过暗。请注意，对于单像素片段的多重采样也存在同样的问题，但不太严重，因为它只影响像素的某些样本，并且这种明亮/黑暗的样本可能会与没有类似问题的其他样本平均。

版本历史

  • 修订版 3，2019-07-18 (Mathias Schott)

    • 在本附录中完整列出扩展接口。

  • 修订版 2，2018-09-13 (Pat Brown)

    • 准备发布规范的各种编辑。

  • 修订版 1，2018-08-08 (Pat Brown)

    • 内部修订

VK_NV_viewport_array2

名称字符串

VK_NV_viewport_array2

扩展类型

设备扩展

注册扩展号

97

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2017-02-15

交互和外部依赖
贡献者

  • Piers Daniell, NVIDIA

  • Jeff Bolz, NVIDIA

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

  • SPV_NV_viewport_array2

允许将单个图元广播到多个视口和/或多个层。提供了一个新的着色器内置输出 ViewportMaskNV，它允许将单个图元同时输出到多个视口。此外，还添加了一个新的 SPIR-V 修饰符，用于控制是否将有效的视口索引添加到使用 Layer 内置修饰的变量中。这些功能允许将单个图元同时输出到多个层。

此扩展允许使用 ShaderViewportIndexLayerNV 功能，从顶点或细分着色器导出使用 Layer 和 ViewportIndex 内置修饰的变量。

此扩展添加了一个新的 ViewportMaskNV 内置修饰符，该修饰符可用于顶点、细分评估和几何着色器中的输出变量，以及一个新的 ViewportRelativeNV 修饰符，当使用 ShaderViewportMaskNV 功能时，可以添加到使用 Layer 修饰的变量上。

当使用基于 GLSL 源的着色语言时，gl_ViewportMask[] 内置输出变量和 GL_NV_viewport_array2 中的 viewport_relative 布局限定符分别映射到 ViewportMaskNV 和 ViewportRelativeNV 修饰符。行为在 GL_NV_viewport_array2 扩展规范中描述。

ShaderViewportIndexLayerNV 功能等效于 VK_EXT_shader_viewport_index_layer 添加的 ShaderViewportIndexLayerEXT 功能。

新枚举常量

  • VK_NV_VIEWPORT_ARRAY2_EXTENSION_NAME

  • VK_NV_VIEWPORT_ARRAY2_SPEC_VERSION

  • VK_NV_VIEWPORT_ARRAY_2_EXTENSION_NAME

  • VK_NV_VIEWPORT_ARRAY_2_SPEC_VERSION

新的或修改的内置变量

新的变量修饰

新的 SPIR-V 功能

版本历史

  • 修订版 1，2017-02-15 (Daniel Koch)

    • 内部修订

VK_NV_viewport_swizzle

名称字符串

VK_NV_viewport_swizzle

扩展类型

设备扩展

注册扩展号

99

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2016-12-22

交互和外部依赖

  • 此扩展需要 multiViewport 和 geometryShader 功能才能有用。

贡献者

  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

描述

此扩展提供一个新的每视口混合，可以修改发送到每个视口的图元的位置。为每个视口添加新的视口混合状态，并通过从原始位置向量的四个分量中选择并可选择地取反来计算每个顶点的新位置向量。

这种新的视口混合对于许多算法很有用，包括单通道立方体贴图渲染（将图元广播到多个面并重新定向每个面的顶点位置）和体素栅格化。混合提供的每视口组件重映射和取反允许应用程序代码沿 X、Y 或 Z 轴重新定向三维几何体。如果需要透视投影和深度缓冲，则应使用 1/W 缓冲，如下面的“问题”部分中的单通道立方体贴图渲染示例所述。

新结构

新枚举

新位掩码

新枚举常量

  • VK_NV_VIEWPORT_SWIZZLE_EXTENSION_NAME

  • VK_NV_VIEWPORT_SWIZZLE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_SWIZZLE_STATE_CREATE_INFO_NV

问题

1) 视口混合发生在管线的哪个位置？

已解决：尽管与视口相关联，但视口混合必须在视口变换之前发生。特别是，它需要在剪裁和透视分割之前执行。

视口掩码扩展 (VK_NV_viewport_array2) 和视口混合可能会在变换反馈之前或之后执行，但反馈具有不同混合的多个视口值的图元似乎不是特别有用。此规范在变换反馈后应用视口掩码和混合，并使图元查询仅计算每个图元一次。

2) 此扩展、VK_NV_viewport_array2 和 VK_NV_geometry_shader_passthrough 如何在实践中一起使用的任何有趣示例？

已解决：此扩展的一个有趣用例是单通道渲染到立方体贴图。在此示例中，应用程序会将立方体贴图纹理附加到分层 FBO，其中六个立方体面被视为层。顶点在不应用投影矩阵的情况下发送到顶点着色器，其中 gl_Position 输出为 (x,y,z,1)，立方体贴图的中心位于 (0,0,0)。使用未扩展的 Vulkan，可以有一个传统的实例化几何着色器，如下所示

layout(invocations = 6) in;     // separate invocation per face
layout(triangles) in;
layout(triangle_strip) out;
layout(max_vertices = 3) out;

in Inputs {
vec2 texcoord;
vec3 normal;
vec4 baseColor;
} v[];

    out Outputs {
    vec2 texcoord;
    vec3 normal;
    vec4 baseColor;
    };

    void main()
    {
    int face = gl_InvocationID;  // which face am I?

    // Project gl_Position for each vertex onto the cube map face.
    vec4 positions[3];
    for (int i = 0; i < 3; i++) {
        positions[i] = rotate(gl_in[i].gl_Position, face);
    }

    // If the primitive does not project onto this face, we are done.
    if (shouldCull(positions)) {
        return;
    }

    // Otherwise, emit a copy of the input primitive to the
    // appropriate face (using gl_Layer).
    for (int i = 0; i < 3; i++) {
        gl_Layer = face;
        gl_Position = positions[i];
        texcoord = v[i].texcoord;
        normal = v[i].normal;
        baseColor = v[i].baseColor;
        EmitVertex();
    }
}

使用直通几何着色器，可以使用更简单的着色器完成此操作

layout(triangles) in;
layout(passthrough) in Inputs {
    vec2 texcoord;
    vec3 normal;
    vec4 baseColor;
}
layout(passthrough) in gl_PerVertex {
    vec4 gl_Position;
} gl_in[];
layout(viewport_relative) out int gl_Layer;

void main()
{
    // Figure out which faces the primitive projects onto and
    // generate a corresponding viewport mask.
    uint mask = 0;
    for (int i = 0; i < 6; i++) {
        if (!shouldCull(face)) {
        mask |= 1U << i;
        }
    }
    gl_ViewportMask = mask;
    gl_Layer = 0;
}

应用程序代码的设置使得六个立方体面中的每一个都有一个单独的视口（编号为 0 到 5）。每个面还有一个单独的混合，通过 VkPipelineViewportSwizzleStateCreateInfoNV 管线状态进行编程。视口混合功能执行原始着色器中 rotate() 函数处理的坐标变换。viewport_relative 布局限定符表示视口号（0 到 5）被添加到 0 的基本 gl_Layer 值，以确定图元应发送到哪个层（立方体面）。

请注意，此示例中使用传递的输入 normal 表明此示例中的片段着色器将执行诸如每个片段照明之类的操作。视口混合会将位置转换为面相关的位置，但 normal 将保留在原始坐标系中。此示例的任一版本中的片段着色器似乎都可能希望在原始坐标系中执行照明。它可能会通过使用 gl_FragCoord、一个保存立方体面大小的常量或 uniform 以及输入 gl_ViewportIndex（或 gl_Layer）重建原始坐标系中片段的位置来执行此操作，该输入标识立方体面。由于 normal 的值在原始坐标系中，因此无需将其作为此坐标变换的一部分进行修改。

请注意，虽然上面常规几何着色器中的 rotate() 操作可以包含任意的后旋转投影矩阵，但视口混合不支持任意数学运算。为了获得正确的投影，应使用 1/W 缓冲。要执行此操作

  1. 编程视口混合，以将投影前 W 眼睛坐标（通常为 1.0）移动到混合输出的 Z 坐标，并将用于深度的眼睛坐标分量移动到 W 坐标。例如，与 +Z 面对应的视口可以使用 (+X, -Y, +W, +Z) 的混合。z'/w' = 1/Zeye 则在混合后计算出的 Z 归一化设备坐标。

  2. 在 NVIDIA 实现上，支持值在 [0,1] 之外的浮点深度缓冲区，通过启用 depthClampEnable 来防止不需要的近平面剪裁。通过将深度范围编程为非常大的值（例如 minDepthBounds=-z、maxDepthBounds=+z，其中 z = 2127），确保深度钳位不会搞乱深度测试。也可以使用 IEEE 无穷大编码（-INF 为 0xFF800000，+INF 为 0x7F800000）。即使禁用近/远剪裁，延伸到眼睛后面的图元仍会被剪裁，因为一个或多个顶点的 W 坐标为负值，并且 X/Y 剪裁测试失败。

    在其他实现上，缩放 X、Y 和 Z 眼睛坐标，使得近平面上的顶点的混合后 W 坐标为 1.0。例如，如果近平面在 Zeye = 1/256，则将 X、Y 和 Z 缩放 256。

  3. 调整深度测试以反映 1/W 值在靠近眼睛时较大，而远离眼睛时较小。将深度缓冲区清除为零（无限远），并使用 VK_COMPARE_OP_GREATER 而不是 VK_COMPARE_OP_LESS 的深度测试。

版本历史

  • 修订版 1，2016-12-22 (Piers Daniell)

    • 内部修订

VK_NVX_binary_import

名称字符串

VK_NVX_binary_import

扩展类型

设备扩展

注册扩展号

30

修订

2

批准状态

未批准

扩展和版本依赖关系

无

API 交互

  • 与 VK_EXT_debug_report 交互

联系方式

其他扩展元数据

上次修改日期

2024-11-04

贡献者

  • Eric Werness, NVIDIA

  • Liam Middlebrook, NVIDIA

描述

此扩展允许应用程序导入 CuBIN 二进制文件并执行它们。

目前没有为该扩展编写规范语言。指向扩展定义的 API 的链接是指存根，这些存根仅包含生成的诸如 API 声明和隐式有效使用语句等内容。

新对象类型

新命令

新结构体

新枚举常量

  • VK_NVX_BINARY_IMPORT_EXTENSION_NAME

  • VK_NVX_BINARY_IMPORT_SPEC_VERSION

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_CU_FUNCTION_NVX

    • VK_OBJECT_TYPE_CU_MODULE_NVX

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_CU_FUNCTION_CREATE_INFO_NVX

    • VK_STRUCTURE_TYPE_CU_LAUNCH_INFO_NVX

    • VK_STRUCTURE_TYPE_CU_MODULE_CREATE_INFO_NVX

    • VK_STRUCTURE_TYPE_CU_MODULE_TEXTURING_MODE_CREATE_INFO_NVX

如果支持 VK_EXT_debug_report

存根 API 引用

目前没有为此类型编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_NVX_binary_import
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkCuFunctionNVX)

目前没有为此类型编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_NVX_binary_import
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkCuModuleNVX)

目前没有为此命令编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_NVX_binary_import
VkResult vkCreateCuFunctionNVX(
    VkDevice                                    device,
    const VkCuFunctionCreateInfoNVX*            pCreateInfo,
    const VkAllocationCallbacks*                pAllocator,
    VkCuFunctionNVX*                            pFunction);
有效使用（隐式）

  • VUID-vkCreateCuFunctionNVX-device-parameter
    device 必须是有效的 VkDevice 句柄

  • VUID-vkCreateCuFunctionNVX-pCreateInfo-parameter
    pCreateInfo 必须是指向有效 VkCuFunctionCreateInfoNVX 结构的有效指针

  • VUID-vkCreateCuFunctionNVX-pAllocator-parameter
    如果 pAllocator 不为 NULL，则 pAllocator 必须是指向有效 VkAllocationCallbacks 结构的有效指针

  • VUID-vkCreateCuFunctionNVX-pFunction-parameter
    pFunction 必须是指向 VkCuFunctionNVX 句柄的有效指针

返回码
成功

  • VK_SUCCESS

失败

  • VK_ERROR_OUT_OF_HOST_MEMORY

  • VK_ERROR_INITIALIZATION_FAILED

目前没有为此类型编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_NVX_binary_import
typedef struct VkCuFunctionCreateInfoNVX {
    VkStructureType    sType;
    const void*        pNext;
    VkCuModuleNVX      module;
    const char*        pName;
} VkCuFunctionCreateInfoNVX;
有效使用（隐式）

  • VUID-VkCuFunctionCreateInfoNVX-sType-sType
    sType 必须为 VK_STRUCTURE_TYPE_CU_FUNCTION_CREATE_INFO_NVX

  • VUID-VkCuFunctionCreateInfoNVX-pNext-pNext
    pNext 必须为 NULL

  • VUID-VkCuFunctionCreateInfoNVX-module-parameter
    module 必须是有效的 VkCuModuleNVX 句柄

  • VUID-VkCuFunctionCreateInfoNVX-pName-parameter
    pName 必须是以 null 结尾的 UTF-8 字符串

目前没有为此命令编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_NVX_binary_import
void vkDestroyCuFunctionNVX(
    VkDevice                                    device,
    VkCuFunctionNVX                             function,
    const VkAllocationCallbacks*                pAllocator);
有效使用（隐式）

  • VUID-vkDestroyCuFunctionNVX-device-parameter
    device 必须是有效的 VkDevice 句柄

  • VUID-vkDestroyCuFunctionNVX-function-parameter
    function 必须是有效的 VkCuFunctionNVX 句柄

  • VUID-vkDestroyCuFunctionNVX-pAllocator-parameter
    如果 pAllocator 不为 NULL，则 pAllocator 必须是指向有效 VkAllocationCallbacks 结构的有效指针

  • VUID-vkDestroyCuFunctionNVX-function-parent
    function 必须是从 device 创建、分配或检索的

目前没有为此命令编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_NVX_binary_import
VkResult vkCreateCuModuleNVX(
    VkDevice                                    device,
    const VkCuModuleCreateInfoNVX*              pCreateInfo,
    const VkAllocationCallbacks*                pAllocator,
    VkCuModuleNVX*                              pModule);
有效使用（隐式）

  • VUID-vkCreateCuModuleNVX-device-parameter
    device 必须是有效的 VkDevice 句柄

  • VUID-vkCreateCuModuleNVX-pCreateInfo-parameter
    pCreateInfo 必须是指向有效 VkCuModuleCreateInfoNVX 结构的有效指针

  • VUID-vkCreateCuModuleNVX-pAllocator-parameter
    如果 pAllocator 不为 NULL，则 pAllocator 必须是指向有效 VkAllocationCallbacks 结构的有效指针

  • VUID-vkCreateCuModuleNVX-pModule-parameter
    pModule 必须是指向 VkCuModuleNVX 句柄的有效指针

返回码
成功

  • VK_SUCCESS

失败

  • VK_ERROR_OUT_OF_HOST_MEMORY

  • VK_ERROR_INITIALIZATION_FAILED

目前没有为此类型编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_NVX_binary_import
typedef struct VkCuModuleCreateInfoNVX {
    VkStructureType    sType;
    const void*        pNext;
    size_t             dataSize;
    const void*        pData;
} VkCuModuleCreateInfoNVX;
有效使用（隐式）

  • VUID-VkCuModuleCreateInfoNVX-sType-sType
    sType 必须为 VK_STRUCTURE_TYPE_CU_MODULE_CREATE_INFO_NVX

  • VUID-VkCuModuleCreateInfoNVX-pNext-pNext
    pNext 必须为 NULL 或指向 VkCuModuleTexturingModeCreateInfoNVX 的有效实例的指针

  • VUID-VkCuModuleCreateInfoNVX-sType-unique
    pNext 链中每个结构体的 sType 值必须是唯一的

  • VUID-VkCuModuleCreateInfoNVX-pData-parameter
    如果 dataSize 不为 0，则 pData 必须是指向大小为 dataSize 字节的数组的有效指针

目前没有为此类型编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_NVX_binary_import
typedef struct VkCuModuleTexturingModeCreateInfoNVX {
    VkStructureType    sType;
    const void*        pNext;
    VkBool32           use64bitTexturing;
} VkCuModuleTexturingModeCreateInfoNVX;
有效使用（隐式）

  • VUID-VkCuModuleTexturingModeCreateInfoNVX-sType-sType
    sType 必须为 VK_STRUCTURE_TYPE_CU_MODULE_TEXTURING_MODE_CREATE_INFO_NVX

目前没有为此命令编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_NVX_binary_import
void vkDestroyCuModuleNVX(
    VkDevice                                    device,
    VkCuModuleNVX                               module,
    const VkAllocationCallbacks*                pAllocator);
有效使用（隐式）

  • VUID-vkDestroyCuModuleNVX-device-parameter
    device 必须是有效的 VkDevice 句柄

  • VUID-vkDestroyCuModuleNVX-module-parameter
    module 必须是有效的 VkCuModuleNVX 句柄

  • VUID-vkDestroyCuModuleNVX-pAllocator-parameter
    如果 pAllocator 不为 NULL，则 pAllocator 必须是指向有效 VkAllocationCallbacks 结构的有效指针

  • VUID-vkDestroyCuModuleNVX-module-parent
    module 必须是从 device 创建、分配或检索的

目前没有为此命令编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_NVX_binary_import
void vkCmdCuLaunchKernelNVX(
    VkCommandBuffer                             commandBuffer,
    const VkCuLaunchInfoNVX*                    pLaunchInfo);
有效使用（隐式）

  • VUID-vkCmdCuLaunchKernelNVX-commandBuffer-parameter
    commandBuffer 必须是有效的 VkCommandBuffer 句柄

  • VUID-vkCmdCuLaunchKernelNVX-pLaunchInfo-parameter
    pLaunchInfo 必须是指向有效 VkCuLaunchInfoNVX 结构的有效指针

  • VUID-vkCmdCuLaunchKernelNVX-commandBuffer-recording
    commandBuffer 必须处于录制状态

  • VUID-vkCmdCuLaunchKernelNVX-commandBuffer-cmdpool
    从其分配 commandBuffer 的 VkCommandPool 必须支持图形或计算操作

  • VUID-vkCmdCuLaunchKernelNVX-videocoding
    此命令必须仅在视频编码范围之外调用

主机同步

  • 对从其分配 commandBuffer 的 VkCommandPool 的主机访问必须进行外部同步

命令属性
命令缓冲区级别 渲染通道范围 视频编码范围 支持的队列类型 命令类型

主
辅助

两者

外部

图形
计算

操作

目前没有为此类型编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_NVX_binary_import
typedef struct VkCuLaunchInfoNVX {
    VkStructureType        sType;
    const void*            pNext;
    VkCuFunctionNVX        function;
    uint32_t               gridDimX;
    uint32_t               gridDimY;
    uint32_t               gridDimZ;
    uint32_t               blockDimX;
    uint32_t               blockDimY;
    uint32_t               blockDimZ;
    uint32_t               sharedMemBytes;
    size_t                 paramCount;
    const void* const *    pParams;
    size_t                 extraCount;
    const void* const *    pExtras;
} VkCuLaunchInfoNVX;
有效使用（隐式）

  • VUID-VkCuLaunchInfoNVX-sType-sType
    sType 必须为 VK_STRUCTURE_TYPE_CU_LAUNCH_INFO_NVX

  • VUID-VkCuLaunchInfoNVX-pNext-pNext
    pNext 必须为 NULL

  • VUID-VkCuLaunchInfoNVX-function-parameter
    function 必须是有效的 VkCuFunctionNVX 句柄

  • VUID-VkCuLaunchInfoNVX-pParams-parameter
    如果 paramCount 不为 0，则 pParams 必须是指向 paramCount 字节数组的有效指针

  • VUID-VkCuLaunchInfoNVX-pExtras-parameter
    如果 extraCount 不为 0，则 pExtras 必须是指向 extraCount 字节数组的有效指针

版本历史

VK_NVX_image_view_handle

名称字符串

VK_NVX_image_view_handle

扩展类型

设备扩展

注册扩展号

31

修订

3

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2024-11-04

贡献者

  • Eric Werness, NVIDIA

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

  • Liam Middlebrook, NVIDIA

描述

此扩展允许应用程序从图像视图中查询不透明句柄，以用作采样图像或存储图像。 它本身不提供直接的功能。

新命令

新结构

新枚举常量

  • VK_NVX_IMAGE_VIEW_HANDLE_EXTENSION_NAME

  • VK_NVX_IMAGE_VIEW_HANDLE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_ADDRESS_PROPERTIES_NVX

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_HANDLE_INFO_NVX

版本历史

VK_NVX_multiview_per_view_attributes

名称字符串

VK_NVX_multiview_per_view_attributes

扩展类型

设备扩展

注册扩展号

98

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_multiview
或
Vulkan 版本 1.1

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_dynamic_rendering 交互

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2017-01-13

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

描述

此扩展添加了一种新的编写着色器的方法，用于多视图子通道，其中所有视图的属性都由预光栅化着色器阶段的单个调用写出。相关的 SPIR-V 和 GLSL 扩展 SPV_NVX_multiview_per_view_attributes 和 GL_NVX_multiview_per_view_attributes 引入了每个视图的位置和视口掩码属性数组，并且此扩展定义了 Vulkan 如何解释这些每个视图的属性数组。使用每个视图属性的管线可能仅对所有视图执行一次预光栅化着色器阶段，而不是每个视图执行一次，这减少了冗余的着色工作。

子通道创建标志控制子通道是否使用此扩展。 子通道必须完全使用此扩展，或者完全不使用它。

某些 Vulkan 实现仅支持在 X 分量中视图之间变化的位置属性。 子通道可以通过第二个创建标志声明为此子通道编译的所有管线是否将遵守此限制。

使用新的每个视图输出（例如 gl_PositionPerViewNV）的着色器必须也写入非每个视图的输出（gl_Position），并且写入的值必须是对于子通道中的所有视图，gl_Position = gl_PositionPerViewNV[gl_ViewIndex]。 实现可以自由地使用每个视图的输出或非每个视图的输出，无论哪个更有效。

如果不支持和启用 VK_NV_viewport_array2 扩展，则必须不使用每个视图的视口掩码。

新结构

如果支持 Vulkan 版本 1.3 或 VK_KHR_dynamic_rendering

新枚举常量

  • VK_NVX_MULTIVIEW_PER_VIEW_ATTRIBUTES_EXTENSION_NAME

  • VK_NVX_MULTIVIEW_PER_VIEW_ATTRIBUTES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PER_VIEW_ATTRIBUTES_PROPERTIES_NVX

  • 扩展 VkSubpassDescriptionFlagBits

    • VK_SUBPASS_DESCRIPTION_PER_VIEW_ATTRIBUTES_BIT_NVX

    • VK_SUBPASS_DESCRIPTION_PER_VIEW_POSITION_X_ONLY_BIT_NVX

如果支持 Vulkan 版本 1.3 或 VK_KHR_dynamic_rendering

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_MULTIVIEW_PER_VIEW_ATTRIBUTES_INFO_NVX

新内置变量

新的 SPIR-V 功能

示例

#version 450 core

#extension GL_KHX_multiview : enable
#extension GL_NVX_multiview_per_view_attributes : enable

layout(location = 0) in vec4 position;
layout(set = 0, binding = 0) uniform Block { mat4 mvpPerView[2]; } buf;

void main()
{
    // Output both per-view positions and gl_Position as a function
    // of gl_ViewIndex
    gl_PositionPerViewNV[0] = buf.mvpPerView[0] * position;
    gl_PositionPerViewNV[1] = buf.mvpPerView[1] * position;
    gl_Position = buf.mvpPerView[gl_ViewIndex] * position;
}

版本历史

  • 修订版 1，2017-01-13 (Jeff Bolz)

    • 内部修订

VK_QCOM_filter_cubic_clamp

名称字符串

VK_QCOM_filter_cubic_clamp

扩展类型

设备扩展

注册扩展号

522

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_EXT_filter_cubic
和
     Vulkan 版本 1.2
    或
     VK_EXT_sampler_filter_minmax

联系方式

其他扩展元数据

上次修改日期

2023-08-02

贡献者

  • Jeff Leger，高通技术公司

描述

此扩展通过增加启用抗振铃钳制的功能来扩展三次滤波。三次滤波从纹素的 4x4 区域采样，并计算该区域的三次加权平均值。在某些情况下，结果值超出 4x4 区域中任何纹素的范围。这有时被称为“滤波器过冲”或“滤波器振铃”，并且当被滤波的 4x4 区域中存在急剧的不连续性时会发生。对于某些用例，这种“振铃”会产生不可接受的伪影。

解决振铃问题的方法是将三次滤波后的值钳制在 4x4 区域中纹素值的最大值和最小值之间。虽然可以在着色器代码中执行这种“范围钳制”，但额外的纹理获取和钳制 ALU 操作可能会很昂贵。

某些 Adreno GPU 能够在三次滤波期间在纹理单元中执行范围钳制，与基于着色器的钳制方法相比，具有显着的性能/功耗节省。此扩展公开了这种硬件功能。

此扩展扩展了 VkSamplerReductionMode，添加了 VK_SAMPLER_REDUCTION_MODE_WEIGHTED_AVERAGE_RANGECLAMP_QCOM，从而启用范围钳制操作。

新结构

新枚举常量

  • VK_QCOM_FILTER_CUBIC_CLAMP_EXTENSION_NAME

  • VK_QCOM_FILTER_CUBIC_CLAMP_SPEC_VERSION

  • 扩展 VkSamplerReductionMode

    • VK_SAMPLER_REDUCTION_MODE_WEIGHTED_AVERAGE_RANGECLAMP_QCOM

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUBIC_CLAMP_FEATURES_QCOM

版本历史

  • 修订版 1，2023-08-02 (jleger)

    • 初始版本

VK_QCOM_filter_cubic_weights

名称字符串

VK_QCOM_filter_cubic_weights

扩展类型

设备扩展

注册扩展号

520

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_EXT_filter_cubic

联系方式

其他扩展元数据

上次修改日期

2023-06-23

贡献者

  • Jeff Leger，高通技术公司

  • Jonathan Wicks，高通技术公司

描述

此扩展通过增加选择一组权重的功能来扩展三次滤波。如果没有此扩展，三次滤波中使用的权重将仅限于与 Catmull-Rom 样条曲线相对应的权重。此扩展添加了对 3 个附加样条曲线权重的支持。

此扩展添加了一个新结构，该结构可以添加到 VkSamplerCreateInfo 的 pNext 链中，该结构可以用于指定在三次滤波中使用哪一组三次权重。可以将类似的结构添加到 VkBlitImageInfo2 的 pNext 链中，以指定在 blit 操作中使用的三次权重。

使用此扩展，可以为三次滤波采样和 blit 选择与以下附加样条曲线相对应的权重

  • 零切线基数

  • B 样条

  • Mitchell-Netravali

新结构

新枚举

新枚举常量

  • VK_QCOM_FILTER_CUBIC_WEIGHTS_EXTENSION_NAME

  • VK_QCOM_FILTER_CUBIC_WEIGHTS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BLIT_IMAGE_CUBIC_WEIGHTS_INFO_QCOM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUBIC_WEIGHTS_FEATURES_QCOM

    • VK_STRUCTURE_TYPE_SAMPLER_CUBIC_WEIGHTS_CREATE_INFO_QCOM

版本历史

  • 修订版 1，2023-06-23 (jleger)

    • 初始版本

VK_QCOM_fragment_density_map_offset

名称字符串

VK_QCOM_fragment_density_map_offset

扩展类型

设备扩展

注册扩展号

426

修订

2

批准状态

未批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
    或
     Vulkan 版本 1.1
和
VK_EXT_fragment_density_map

联系方式

其他扩展元数据

上次修改日期

2024-06-17

贡献者

  • Matthew Netsch，高通技术公司

  • Jonathan Wicks，高通技术公司

  • Jonathan Tinkham，高通技术公司

  • Jeff Leger，高通技术公司

  • Manan Katwala，Qualcomm Technologies, Inc.

描述

此扩展允许应用程序指定片段密度图附件的偏移量，更改应用密度值的帧缓冲区位置，而无需重新生成片段密度图。

新结构

新枚举常量

  • VK_QCOM_FRAGMENT_DENSITY_MAP_OFFSET_EXTENSION_NAME

  • VK_QCOM_FRAGMENT_DENSITY_MAP_OFFSET_SPEC_VERSION

  • 扩展 VkImageCreateFlagBits

    • VK_IMAGE_CREATE_FRAGMENT_DENSITY_MAP_OFFSET_BIT_QCOM

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_OFFSET_FEATURES_QCOM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_OFFSET_PROPERTIES_QCOM

    • VK_STRUCTURE_TYPE_SUBPASS_FRAGMENT_DENSITY_MAP_OFFSET_END_INFO_QCOM

版本历史

  • 修订版 2，2024-06-17 (Matthew Netsch)

    • 修复了关于 fragmentDensityMapOffset 功能的规范中的错别字

  • 修订版 1，2021-09-03 (Matthew Netsch)

    • 初始版本

VK_QCOM_image_processing

名称字符串

VK_QCOM_image_processing

扩展类型

设备扩展

注册扩展号

441

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_format_feature_flags2
或
Vulkan 版本 1.3

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_format_feature_flags2 交互

SPIR-V 依赖项
联系方式
扩展提案

VK_QCOM_image_processing

其他扩展元数据

上次修改日期

2022-07-08

交互和外部依赖
贡献者

  • Jeff Leger，高通技术公司

  • Ruihao Zhang，Qualcomm Technologies, Inc.

描述

GPU 通常用于处理各种应用程序的图像，从 3D 图形到 UI，从合成到计算应用程序。简单的缩放和滤波可以使用双线性滤波完成，在纹理采样期间免费获得。然而，随着屏幕尺寸变大，并且越来越多的用例依赖于 GPU，例如相机和视频后处理需求，对 GPU 支持更高阶滤波和其他高级图像处理的需求不断增加。

此扩展引入了一组新的 SPIR-V 内置函数，用于图像处理。它公开了以下新的成像操作

  • OpImageSampleWeightedQCOM 指令采用 3 个操作数：采样图像、权重图像和纹理坐标。该指令使用权重图像中的一组 MxN 权重计算采样图像中 MxN 区域的纹素的加权平均值。

  • OpImageBoxFilterQCOM 指令采用 3 个操作数：采样图像、框大小和纹理坐标。请注意，框大小指定纹素中的浮点宽度和高度。该指令计算采样图像中由具有指定大小并以指定纹理坐标为中心的框覆盖（部分或完全）的所有纹素的加权平均值。

  • OpImageBlockMatchSADQCOM 和 OpImageBlockMatchSSDQCOM 指令都接受 5 个操作数：目标图像、目标坐标、参考图像、参考坐标 和块大小。每条指令都会计算一个误差指标，用于描述目标图像中的一个纹素块是否与参考图像中相应的纹素块匹配。误差指标是按分量计算的。OpImageBlockMatchSADQCOM 计算“绝对差之和 (Sum Of Absolute Difference)”，而 OpImageBlockMatchSSDQCOM 计算“平方差之和 (Sum of Squared Difference)”。

每个图像处理指令仅在 2D 图像上操作。这些指令不支持对 mipmap、多平面、多层、多采样或深度/模板图像进行采样。这些指令可以在任何着色器阶段中使用。

此扩展的实现应在硬件指令级别原生支持这些操作，从而提供潜在的性能提升以及易于开发。

新结构体

新枚举常量

  • VK_QCOM_IMAGE_PROCESSING_EXTENSION_NAME

  • VK_QCOM_IMAGE_PROCESSING_SPEC_VERSION

  • 扩展 VkDescriptorType

    • VK_DESCRIPTOR_TYPE_BLOCK_MATCH_IMAGE_QCOM

    • VK_DESCRIPTOR_TYPE_SAMPLE_WEIGHT_IMAGE_QCOM

  • 扩展 VkImageUsageFlagBits

    • VK_IMAGE_USAGE_SAMPLE_BLOCK_MATCH_BIT_QCOM

    • VK_IMAGE_USAGE_SAMPLE_WEIGHT_BIT_QCOM

  • 扩展 VkSamplerCreateFlagBits

    • VK_SAMPLER_CREATE_IMAGE_PROCESSING_BIT_QCOM

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_SAMPLE_WEIGHT_CREATE_INFO_QCOM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_PROCESSING_FEATURES_QCOM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_PROCESSING_PROPERTIES_QCOM

如果支持 VK_KHR_format_feature_flags2 或 Vulkan 1.3 版本

  • 扩展 VkFormatFeatureFlagBits2

    • VK_FORMAT_FEATURE_2_BLOCK_MATCHING_BIT_QCOM

    • VK_FORMAT_FEATURE_2_BOX_FILTER_SAMPLED_BIT_QCOM

    • VK_FORMAT_FEATURE_2_WEIGHT_IMAGE_BIT_QCOM

    • VK_FORMAT_FEATURE_2_WEIGHT_SAMPLED_IMAGE_BIT_QCOM

版本历史

  • 修订版 1，2022-07-08 (Jeff Leger)

VK_QCOM_image_processing2

名称字符串

VK_QCOM_image_processing2

扩展类型

设备扩展

注册扩展号

519

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_QCOM_image_processing

SPIR-V 依赖项
联系方式

其他扩展元数据

上次修改日期

2023-03-10

交互和外部依赖
贡献者

  • Jeff Leger，高通技术公司

描述

此扩展启用对 SPIR-V TextureBlockMatch2QCOM 功能的支持。它基于 QCOM_image_processing 的功能构建，增加了 4 个新的图像处理操作。

  • opImageBlockMatchWindowSADQCOM SPIR-V 指令建立在 opImageBlockMatchSADQCOM 的功能之上，它通过在 2D 窗口上重复执行块匹配操作来实现。 “2D windowExtent” 和 “compareMode” 由用于创建目标图像的采样器中的 VkSamplerBlockMatchWindowCreateInfoQCOM 指定。与 OpImageBlockMatchSADQCOM 类似，opImageBlockMatchWindowSADQCOM 计算一个误差指标，用于描述目标图像中的一个纹素块是否与参考图像中相应的纹素块匹配。与 OpImageBlockMatchSADQCOM 不同，此指令计算 2D 窗口内每个 (X,Y) 位置的误差指标，并返回最小或最大误差。该指令仅支持单分量格式。有关详细信息，请参阅下面的伪代码。

  • opImageBlockMatchWindowSSDQCOM 遵循相同的模式，计算 2D 窗口内每个位置的 SSD 误差指标。

  • opImageBlockMatchGatherSADQCOM 基于 OpImageBlockMatchSADQCOM 构建。此指令计算一个误差指标，用于描述目标图像中的一个纹素块是否与参考图像中相应的纹素块匹配。该指令计算 4 个纹素偏移处的 SAD 误差指标，并返回 X、Y、Z 和 W 分量中每个偏移的误差指标。该指令仅支持单分量纹理格式。有关详细信息，请参阅下面的伪代码。

  • opImageBlockMatchGatherSSDQCOM 遵循相同的模式，计算 4 个偏移的 SSD 误差指标。

上述 4 个图像处理指令都仅限于单分量格式。

以下是 GLSL 内置函数 textureWindowBlockMatchSADQCOM 的伪代码。textureWindowBlockMatchSSD 的伪代码是相同的，只是将所有 "SAD" 实例替换为 "SSD"。

vec4 textureBlockMatchWindowSAD( sampler2D target,
                                 uvec2 targetCoord,
                                 samler2D reference,
                                 uvec2 refCoord,
                                 uvec2 blocksize) {
    // compareMode (MIN or MAX) comes from the vkSampler associated with `target`
    // uvec2 window  comes from the vkSampler associated with `target`
    minSAD = INF;
    maxSAD = -INF;
    uvec2 minCoord;
    uvec2 maxCoord;

    for (uint x=0, x < window.width; x++) {
        for (uint y=0; y < window.height; y++) {
            float SAD = textureBlockMatchSAD(target,
                                            targetCoord + uvec2(x, y),
                                            reference,
                                            refCoord,
                                            blocksize).x;
            // Note: the below comparison operator will produce undefined results
            // if SAD is a denorm value.
            if (SAD < minSAD) {
                minSAD = SAD;
                minCoord = uvec2(x,y);
            }
            if (SAD > maxSAD) {
                maxSAD = SAD;
                maxCoord = uvec2(x,y);
            }
        }
    }
    if (compareMode=MIN) {
        return vec4(minSAD, minCoord.x, minCoord.y, 0.0);
    } else {
        return vec4(maxSAD, maxCoord.x, maxCoord.y, 0.0);
    }
}

以下是 textureBlockMatchGatherSADQCOM 的伪代码。textureBlockMatchGatherSSD 的伪代码遵循相同的模式。

vec4 textureBlockMatchGatherSAD( sampler2D target,
                                 uvec2 targetCoord,
                                 samler2D reference,
                                 uvec2 refCoord,
                                 uvec2 blocksize) {
    vec4 out;
    for (uint x=0, x<4; x++) {
            float SAD = textureBlockMatchSAD(target,
                                            targetCoord + uvec2(x, 0),
                                            reference,
                                            refCoord,
                                            blocksize).x;
            out[x] = SAD;
    }
    return out;
}

新结构体

新枚举

新枚举常量

  • VK_QCOM_IMAGE_PROCESSING_2_EXTENSION_NAME

  • VK_QCOM_IMAGE_PROCESSING_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_PROCESSING_2_FEATURES_QCOM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_PROCESSING_2_PROPERTIES_QCOM

    • VK_STRUCTURE_TYPE_SAMPLER_BLOCK_MATCH_WINDOW_CREATE_INFO_QCOM

问题

1) 最小/最大比较检查的精度是多少？

已解决：新操作的中间计算以 16 位浮点精度执行。如果上述代码示例中 "float SAD" 的值是一个 16 位非规范化值，则 MIN/MAX 比较的行为未定义。

版本历史

  • 修订版 1，2023-03-10 (Jeff Leger)

VK_QCOM_multiview_per_view_render_areas

名称字符串

VK_QCOM_multiview_per_view_render_areas

扩展类型

设备扩展

注册扩展号

511

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2023-01-10

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Jeff Leger, Qualcomm

  • Jonathan Tinkham, Qualcomm

  • Jonathan Wicks, Qualcomm

描述

某些用例（例如，并排 VR 渲染）使用多视图，并为每个视图渲染到帧缓冲区的不同区域。在某些实现中，为实现提供每个视图的渲染区域可能会带来性能优势。实现可以使用此类每个视图的渲染区域来减少受附件加载、存储和多采样解析操作影响的像素。

该扩展使多视图渲染通道实例能够定义每个视图的渲染区域。对于多视图渲染通道实例的每个视图，只有每个视图的渲染区域中的像素才会受到加载、存储和解析操作的影响。

新结构体

新枚举常量

  • VK_QCOM_MULTIVIEW_PER_VIEW_RENDER_AREAS_EXTENSION_NAME

  • VK_QCOM_MULTIVIEW_PER_VIEW_RENDER_AREAS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_MULTIVIEW_PER_VIEW_RENDER_AREAS_RENDER_PASS_BEGIN_INFO_QCOM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PER_VIEW_RENDER_AREAS_FEATURES_QCOM

问题

1) 每个视图的 renderAreas 是否与 vkGetRenderAreaGranularity 交互？

已解决：没有变化。vkGetRenderAreaGranularity 返回的粒度也适用于每个视图的 renderAreas。

2) 此扩展如何与 VK_QCOM_render_pass_transform 交互？

已解决: 当启用 VK_QCOM_render_pass_transform 时，应用程序以非旋转坐标提供渲染区域，该区域由实现旋转到旋转后的坐标系。当此扩展与 VK_QCOM_render_pass_transform 结合使用时，则在 VkRenderingInfo::renderArea、VkRenderPassBeginInfo::renderArea 或 VkCommandBufferInheritanceRenderPassTransformInfoQCOM::renderArea 中提供的 renderArea 将由实现旋转。每个视图的渲染区域不会旋转。

3) 此扩展如何与 VK_QCOM_multiview_per_view_viewports 交互？

已解决: 没有直接交互。每个视图的视口和每个视图的渲染区域是正交的特性。

4) 当指定每个视图的 renderArea 时，多视图渲染是否必须包含在多视图渲染通道的每个视图的每个视图的 renderArea 内？

已解决: 是的，并且 VK_QCOM_multiview_per_view_viewports 在这里可能有所帮助，因为它提供了每个视图的剪裁。

5) 当指定每个视图的渲染区域时，VkRenderPassBeginInfo::renderArea 和 VkRenderingInfo::renderArea 有什么用途？

已解决: 每个视图的 renderArea 有效地覆盖了每个渲染通道的 renderArea。每个视图的 renderArea 定义了附件中受加载、存储和多重采样解析操作影响的区域。一个有效的实现可以忽略每个渲染通道的 renderArea。但是，为了帮助实现，应用程序必须将每个渲染通道的 renderArea 设置为至少与所有每个视图渲染区域的并集一样大的区域。在每个渲染通道的 renderArea 内但不位于任何每个视图渲染区域内的像素不得受加载、存储或多重采样解析操作的影响。

版本历史

  • 修订版 1，2023-01-10 (Jeff Leger)

VK_QCOM_multiview_per_view_viewports

名称字符串

VK_QCOM_multiview_per_view_viewports

扩展类型

设备扩展

注册扩展号

489

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

其他扩展元数据

上次修改日期

2022-11-22

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Jeff Leger, Qualcomm

  • Jonathan Tinkham, Qualcomm

  • Jonathan Wicks, Qualcomm

描述

多视图的某些用例需要为每个视图指定单独的视口和剪裁，而无需使用 VK_EXT_shader_viewport_index_layer 引入的基于着色器的视口索引。

此扩展添加了一种新的方式来使用多视图控制 ViewportIndex。当启用 multiviewPerViewViewports 功能并且最后一个预光栅化着色器入口点的接口不使用 ViewportIndex 内建装饰时，多视图渲染通道实例的每个视图将使用一个等于 ViewIndex 的视口和剪裁索引。

新结构

新枚举常量

  • VK_QCOM_MULTIVIEW_PER_VIEW_VIEWPORTS_EXTENSION_NAME

  • VK_QCOM_MULTIVIEW_PER_VIEW_VIEWPORTS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PER_VIEW_VIEWPORTS_FEATURES_QCOM

问题

1) 是否可以为单独的渲染通道实例启用/禁用 multiviewPerViewViewports 功能？

已解决: 不，当在 vkCreateDevice 期间启用 multiviewPerViewViewports 功能时，所有创建的渲染通道实例（包括来自 VK_KHR_dynamic_rendering 的动态渲染通道）和所有创建的 VkPipeline 都将启用该功能。选择此方法是因为它简化了应用程序代码，并且没有已知的用例可以为单独的渲染通道或管道启用/禁用该功能。

2) 当使用此扩展时，ViewportIndex 的值是否由最后一个预光栅化着色器阶段隐式写入，并且可以在片段着色器中读取 ViewportIndex 的值吗？

已解决: 不，使用此扩展不会在任何着色器阶段添加对 ViewportIndex 的隐式写入，此外，片段着色器中 ViewportIndex 的值是未定义的。

版本历史

  • 修订版 1，2022-11-22 (Jeff Leger)

VK_QCOM_render_pass_shader_resolve

名称字符串

VK_QCOM_render_pass_shader_resolve

扩展类型

设备扩展

注册扩展号

172

修订

4

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2019-11-07

IP 状态

没有已知的 IP 声明。

交互和外部依赖

无。

贡献者

  • Srihari Babu Alla, Qualcomm

  • Bill Licea-Kane, Qualcomm

  • Jeff Leger, Qualcomm

描述

此扩展允许着色器解析来替换固定功能解析。

固定功能解析的功能仅限于将多重采样缓冲区简单过滤到单个采样缓冲区。

对于此类简单过滤，固定功能解析比着色器解析更具性能效率和/或功耗效率。

着色器解析允许着色器编写器在子通道依赖链的最后一个子通道中创建复杂的多重采样缓冲区的非线性过滤。

此扩展还提供了一个位，该位可以用于将采样区域依赖性扩大为片段区域依赖性，以便在某些情况下，帧缓冲区区域依赖性可以替换帧缓冲区全局依赖性。

新枚举常量

  • VK_QCOM_RENDER_PASS_SHADER_RESOLVE_EXTENSION_NAME

  • VK_QCOM_RENDER_PASS_SHADER_RESOLVE_SPEC_VERSION

  • 扩展 VkSubpassDescriptionFlagBits

    • VK_SUBPASS_DESCRIPTION_FRAGMENT_REGION_BIT_QCOM

    • VK_SUBPASS_DESCRIPTION_SHADER_RESOLVE_BIT_QCOM

问题

1) 此扩展是否应命名为 render_pass_shader_resolve？

已解决 是。

这是对渲染通道进行小型扩展套件的一部分。

遵循样式指南，而不是遵循 VK_KHR_create_renderpass2。

2) 是否应要求每个 pColorAttachment 和 DepthStencilAttachent 都必须使用 VK_SAMPLE_COUNT_1_BIT？

已解决 否。

虽然这可能不是一个常见的用例，并且虽然大多数固定功能解析硬件都有此限制，但几乎没有理由要求着色器解析解析到单个采样缓冲区。

3) 着色器解析子通道是否应为渲染通道中的最后一个子通道？

已解决 是。

更具体地说，它应该是子通道依赖链中的最后一个子通道。

4) 我们是否需要 VK_SUBPASS_DESCRIPTION_FRAGMENT_REGION_BIT_QCOM 位？

已解决 是。

当输入附件的采样计数等于 rasterizationSamples 时，这将适用。此外，如果启用 sampleShading （显式或隐式），则 minSampleShading 必须等于 0.0。

然而，这个位可以在任何子通道上设置，它不局限于着色器解析子通道。

版本历史

  • 修订版 1，2019-06-28 (wwlk)

    • 初始草案

  • 修订版 2，2019-11-06 (wwlk)

    • 常规清理/规范更新

    • 添加了问题

  • 修订版 3，2019-11-07 (wwlk)

    • 错别字

    • 附加问题

    • 明确了着色器解析子通道是子通道依赖链中的最后一个子通道

  • 修订版 4，2020-01-06 (wwlk)

    • 更改了问题 1 的解决方案 (render_pass, 而不是 renderpass)

VK_QCOM_render_pass_store_ops

名称字符串

VK_QCOM_render_pass_store_ops

扩展类型

设备扩展

注册扩展号

302

修订

2

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2020-03-25

贡献者

  • Bill Licea-Kane，高通技术公司。

描述

渲染通道附件在渲染通道的持续时间内可以是只读的。

示例包括输入附件和深度附件，其中启用了深度测试但未启用深度写入。

在这种情况下，渲染区域内的附件可以不生成任何内容。

此扩展添加了一个新的 VkAttachmentStoreOp VK_ATTACHMENT_STORE_OP_NONE_QCOM，指定渲染区域内的内容可能不会写入内存，但会保留内存中附件的先前内容。但是，如果在渲染期间在渲染区域内生成了任何内容，则附件的内容在渲染区域内将是未定义的。

VkAttachmentStoreOp VK_ATTACHMENT_STORE_OP_STORE 可能会强制实现假设附件已写入，并强制实现将数据刷新到内存或更高级别的缓存。 VkAttachmentStoreOp VK_ATTACHMENT_STORE_OP_NONE_QCOM 可能允许实现假设附件未写入，并允许实现避免此类刷新。

新的枚举常量

  • VK_QCOM_RENDER_PASS_STORE_OPS_EXTENSION_NAME

  • VK_QCOM_RENDER_PASS_STORE_OPS_SPEC_VERSION

  • 扩展 VkAttachmentStoreOp

    • VK_ATTACHMENT_STORE_OP_NONE_QCOM

版本历史

  • 修订版 1，2019-12-20 (wwlk)

    • 初始版本

  • 修订版 2，2020-03-25 (wwlk)

    • 轻微重命名

VK_QCOM_render_pass_transform

名称字符串

VK_QCOM_render_pass_transform

扩展类型

设备扩展

注册扩展号

283

修订

4

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2023-12-13

交互和外部依赖
贡献者

  • Jeff Leger，高通技术公司

  • Brandon Light，高通技术公司。

  • Matthew Netsch，高通技术公司

  • Arpit Agarwal，高通技术公司。

描述

此扩展提供了一种机制，使应用程序能够启用驱动程序对 渲染通道转换 的支持。

移动设备可以旋转，当设备以横向或纵向方向握持时，移动应用程序需要正确渲染。当当前方向与设备的本机方向不同时，需要进行旋转，以便渲染场景的“向上”方向与当前方向匹配。

如果显示处理单元 (DPU) 本机不支持旋转，则 Vulkan 演示引擎可以在单独的合成通道中处理此旋转。或者，应用程序可以“预先旋转”渲染帧，以避免额外的通道。后者更可取，以降低功耗并获得最佳性能，因为它避免了让 GPU 执行额外的复制/旋转操作。

与 OpenGL ES 不同，Vulkan 中的预旋转负担落在应用程序身上。为了实现预旋转，应用程序将渲染到与显示器的设备本机纵横比匹配的交换链图像中，并“预旋转”渲染内容以匹配设备的当前方向。负担不仅仅是在顶点着色器中调整模型视图投影 (MVP) 矩阵以考虑旋转和纵横比。剪刀、视口、导数和几个着色器内置函数的坐标系可能需要调整以产生正确的结果。

一些游戏引擎很难管理这种负担；许多人选择简单地接受在演示引擎中执行旋转的性能/功耗开销。

此扩展允许应用程序通过将上述大部分负担转移到图形驱动程序来获得预旋转渲染的性能优势。此扩展中以下内容未更改

此扩展中以下内容已更改

新的结构体

新的枚举常量

  • VK_QCOM_RENDER_PASS_TRANSFORM_EXTENSION_NAME

  • VK_QCOM_RENDER_PASS_TRANSFORM_SPEC_VERSION

  • 扩展 VkRenderPassCreateFlagBits

    • VK_RENDER_PASS_CREATE_TRANSFORM_BIT_QCOM

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_RENDER_PASS_TRANSFORM_INFO_QCOM

    • VK_STRUCTURE_TYPE_RENDER_PASS_TRANSFORM_BEGIN_INFO_QCOM

问题

1) 一些早期的 Adreno 驱动程序（2019 年 10 月至 2020 年 3 月）宣称支持此扩展，但期望的 VK_STRUCTURE_TYPE 值与 vulkan 头文件中的值不同。为了涵盖市场上所有的 Adreno 设备，应用程序需要检测驱动程序版本，并使用下表中相应的 VK_STRUCTURE_TYPE 值。

在 VkPhysicalDeviceProperties.driverVersion 中报告的驱动程序版本是一个 uint32_t 类型。您可以将 uint32_t 值解码为 major.minor.patch 版本，如下所示：

uint32_t  major = ((driverVersion) >> 22);
uint32_t  minor = ((driverVersion) >> 12) & 0x3ff);
uint32_t  patch = ((driverVersion) & 0xfff);

如果 Adreno major.minor.patch 版本大于或等于 512.469.0，则只需使用 vulkan_core.h 中定义的 VK_STRUCTURE_TYPE 值。如果版本小于或等于 512.468.0，则使用下表中两个 VK_STRUCTURE_TYPE 的备用值。

表 1. Adreno 驱动程序要求
Adreno 驱动程序版本

512.468.0 及更早版本

512.469.0 及更高版本

VK_STRUCTURE_TYPE_RENDER_PASS_TRANSFORM_BEGIN_INFO_QCOM

1000282000

1000282001

VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_RENDER_PASS_TRANSFORM_INFO_QCOM

1000282001

1000282000

2) 该扩展应仅支持旋转（例如 90 度、180 度、270 度），还是也支持镜像变换（例如垂直翻转）？移动用例仅需要旋转。其他显示系统（例如投影仪）可能需要翻转变换。

已解决：在此版本的扩展中，功能限制为 90 度、180 度和 270 度旋转，以满足移动用例的需求。

3) 此扩展如何与 VK_EXT_fragment_density_map 交互？

已解决：某些实现可能无法支持同时启用渲染通道变换和片段密度映射的渲染通道。为简单起见，此扩展不允许在单个渲染通道中同时启用这两个功能。

4) 此扩展应该命名为什么？

我们考虑了诸如“rotated_rendering”、“pre_rotation”等名称。由于该功能仅限于渲染通道，因此名称应包含“render_pass”。虽然当前的扩展仅限于旋转，但将来可以扩展到其他变换（如镜像）。

已解决：“render_pass_transform” 这个名称似乎是对引入的功能最准确的描述。

5) 此扩展如何与 VK_KHR_fragment_shading_rate 交互？

已解决：出于与问题 3 相同的原因，此扩展不允许在单个渲染通道中同时启用 pFragmentShadingRateAttachment 和渲染通道变换。

但是，支持管线着色率和图元着色率，并且它们各自的 fragmentSize 和 PrimitiveShadingRateKHR 在当前的（非旋转）坐标系中提供。实现负责将它们转换为旋转的坐标系。

每个变换支持的着色率集合可能不同。从 vkGetPhysicalDeviceFragmentShadingRatesKHR 查询的支持速率位于本机（旋转）坐标系中。这意味着应用程序必须交换报告速率的 x/y 值，以获得 90 度和 270 度旋转支持的速率集。

版本历史

  • 版本 1，2020-02-05 (Jeff Leger)

  • 版本 2，2021-03-09 (Matthew Netsch)

    • 添加了与 VK_KHR_fragment_shading_rate 的交互

  • 版本 3，2022-07-11 (Arpit Agarwal)

    • 添加了与 VK_QCOM_tile_properties 的交互

  • 版本 4，2023-12-13 (Matthew Netsch)

    • 放宽了对 VK_KHR_surface 和 VK_KHR_swapchain 的依赖

VK_QCOM_rotated_copy_commands

名称字符串

VK_QCOM_rotated_copy_commands

扩展类型

设备扩展

注册扩展号

334

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_copy_commands2
或
Vulkan 版本 1.3

联系方式

其他扩展元数据

上次修改日期

2023-12-13

交互和外部依赖
贡献者

  • Jeff Leger，高通技术公司

  • Matthew Netsch，高通技术公司

描述

此扩展为复制命令 vkCmdBlitImage2KHR、 vkCmdCopyImageToBuffer2KHR 和 vkCmdCopyBufferToImage2KHR 添加了一个可选的旋转变换。当在两个资源之间复制时，如果一个资源包含旋转内容而另一个不包含，则可能需要旋转复制。此扩展可以与 VK_QCOM_render_pass_transform 结合使用，后者添加了旋转渲染通道。

此扩展向以下命令添加了一个扩展结构：vkCmdBlitImage2KHR、vkCmdCopyImageToBuffer2KHR 和 vkCmdCopyBufferToImage2KHR

问题

1) 添加的扩展结构的合适名称是什么？样式指南说：“通过 pNext 链扩展其他结构的结构应反映它们扩展的基础结构的名称。”，但在这种情况下，单个扩展结构用于扩展三个基础结构（vkCmdBlitImage2KHR、vkCmdCopyImageToBuffer2KHR 和 vkCmdCopyBufferToImage2KHR）。创建三个名称唯一的相同结构似乎不可取。

已解决：偏离扩展结构命名的样式指南。

2) 此扩展是否应向 vkCmdCopyImage2KHR 添加旋转功能？

已解决：否。使用旋转的 vkCmdBlitImage2KHR 可以完全解决此用例。

3) 此扩展是否应向 vkCmdResolveImage2KHR 添加旋转功能？

已解决：否。在 Qualcomm 的 GPU 架构上，vkCmdResolveImage2KHR 的使用非常慢且带宽消耗极大，并且强烈建议使用 vkRenderPass 中的 pResolveAttachments。因此，我们选择不向 vkCmdResolveImage2KHR 引入旋转功能。

新结构

新枚举常量

  • VK_QCOM_ROTATED_COPY_COMMANDS_EXTENSION_NAME

  • VK_QCOM_ROTATED_COPY_COMMANDS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_COPY_COMMAND_TRANSFORM_INFO_QCOM

版本历史

  • 版本 1，2020-09-19 (Jeff Leger)

  • 版本 2，2023-12-13 (Matthew Netsch)

    • 放宽了对 VK_KHR_swapchain 的依赖

VK_QCOM_tile_properties

名称字符串

VK_QCOM_tile_properties

扩展类型

设备扩展

注册扩展号

485

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

API 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_KHR_dynamic_rendering 交互

联系方式
扩展提案

VK_QCOM_tile_properties

其他扩展元数据

上次修改日期

2022-07-11

交互和外部依赖
贡献者

  • Jonathan Wicks，高通技术公司

  • Jonathan Tinkham，高通技术公司

  • Arpit Agarwal，高通技术公司。

  • Jeff Leger，高通技术公司

描述

此扩展允许应用程序查询瓦片属性。此扩展支持渲染通道和动态渲染。

新命令

新结构

如果支持 VK_KHR_dynamic_rendering 或 Vulkan 1.3 版本

新的枚举常量

  • VK_QCOM_TILE_PROPERTIES_EXTENSION_NAME

  • VK_QCOM_TILE_PROPERTIES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TILE_PROPERTIES_FEATURES_QCOM

    • VK_STRUCTURE_TYPE_TILE_PROPERTIES_QCOM

版本历史

  • 修订版 1，2022-07-11 (Arpit Agarwal)

    • 初始版本

VK_QCOM_ycbcr_degamma

名称字符串

VK_QCOM_ycbcr_degamma

扩展类型

设备扩展

注册扩展号

521

修订

1

批准状态

未批准

扩展和版本依赖关系

无

联系方式

其他扩展元数据

上次修改日期

2023-07-31

IP 状态

没有已知的 IP 声明。

交互和外部依赖

无

贡献者

  • Jeff Leger, Qualcomm

  • Jonathan Wicks, Qualcomm

描述

此扩展允许实现公开对“sRGB EOTF”（也称为“sRGB 解伽马”）的支持，该支持与使用 8 位 Y′CBCR 格式的图像结合使用。此外，解伽马可以有选择地应用于 Y (亮度) 或 CrCb (色度)。

VK_KHR_sampler_ycbcr_conversion 添加了对 Y′CBCR 转换的支持，但允许在非线性空间中进行纹理采样，这可能会导致伪影。此扩展允许实现公开用于 Y′CBCR 格式的 sRGB 解伽马，该解伽马在纹理过滤期间执行，从而允许纹理过滤在线性空间中运行。

新结构

新的枚举常量

  • VK_QCOM_YCBCR_DEGAMMA_EXTENSION_NAME

  • VK_QCOM_YCBCR_DEGAMMA_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_YCBCR_DEGAMMA_FEATURES_QCOM

    • VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_YCBCR_DEGAMMA_CREATE_INFO_QCOM

问题

1) 哪些 Y′CBCR 格式支持解伽马功能？

已解决：对于支持该扩展的实现，每个包含 8 位 R、G 和 B 分量并且支持 VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT 或 VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT 的格式都必须支持解伽马。

由于非压缩 Vulkan sRGB 格式已经限制为 8 位分量，并且由于 Adreno 支持所有 8 位 Y′CBCR 格式的解伽马，因此此扩展不会为解伽马功能引入新的 VK_FORMAT_FEATURE* 位。

2) 解伽马应用于哪些 Y′CBCR 分量？

已解决：虽然解伽马预计仅应用于 Y（亮度）分量，但该扩展提供了有选择地为 Y（亮度）和/或 CbCr（色度）分量启用解伽马的能力。

3) 应该为采样器对象还是图像视图对象启用解伽马？

已解决：两者都应该。此扩展扩展了 VkSamplerYcbcrConversionCreateInfo，并且规范已经要求采样器和视图对象都必须在其 pNext 链中创建具有相同 VkSamplerYcbcrConversionCreateInfo 的对象。

4) 当使用“ITU 传递函数”更正确，并且仅在值被转换为非线性 R’G’B' 后才这样做时，为什么直接将“sRGB”传递函数应用于 Y′CBCR 数据？

已解决：Y′CBCR 通常按照标准（例如 BT.601 和 BT.709）进行存储，这些标准规定线性与非线性之间的转换应使用 ITU 传递函数。ITU 传递函数在数学上与 sRGB 传递函数不同，虽然 sRGB 和 ITU 定义了相似的曲线，但差异显着。如果在内容使用 VK_SAMPLER_YCBCR_RANGE_ITU_NARROW 编码的情况下，在范围扩展之前执行“sRGB 解伽马”可能会引入伪影。然而，对于某些已知使用 sRGB（或纯伽玛 2.2）传递函数编码并且已知使用全范围编码的相机 YCbCr 图像的用例，使用 sRGB 可能有意义。

对于这些用例，此扩展利用 GPU 能够以很少的成本启用 sRGB 解伽马，并且由于纹理过滤能够在线性空间中进行，因此可以提高质量。

版本历史

  • 修订版 1，2023-07-31 (Jeff Leger)

VK_QNX_external_memory_screen_buffer

名称字符串

VK_QNX_external_memory_screen_buffer

扩展类型

设备扩展

注册扩展号

530

修订

1

批准状态

未批准

扩展和版本依赖关系

         VK_KHR_sampler_ycbcr_conversion
        和
         VK_KHR_external_memory
        和
         VK_KHR_dedicated_allocation
    或
     Vulkan 版本 1.1
和
VK_EXT_queue_family_foreign

联系方式

其他扩展元数据

上次修改日期

2023-05-17

IP 状态

没有已知的 IP 声明。

贡献者

  • Mike Gorchak, QNX / Blackberry Limited

  • Aaron Ruby, QNX / Blackberry Limited

描述

此扩展使应用程序能够将 Vulkan 设备外部创建的 QNX Screen _screen_buffer 对象导入到 Vulkan 内存对象中，在这些对象中可以将它们绑定到图像和缓冲区。

一些 _screen_buffer 图像具有实现定义的外部格式，这些格式可能与 Vulkan 格式不对应。采样器 Y′CBCR 转换可以用于从此类图像进行采样并将其转换为已知颜色空间。

_screen_buffer 是强类型的，因此命名句柄类型是多余的。_screen_buffer 图像的内部布局以及因此大小可能取决于没有相应 Vulkan 对等项的本机使用标志。

新命令

新结构

新的枚举常量

  • VK_QNX_EXTERNAL_MEMORY_SCREEN_BUFFER_EXTENSION_NAME

  • VK_QNX_EXTERNAL_MEMORY_SCREEN_BUFFER_SPEC_VERSION

  • 扩展 VkExternalMemoryHandleTypeFlagBits

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_SCREEN_BUFFER_BIT_QNX

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXTERNAL_FORMAT_QNX

    • VK_STRUCTURE_TYPE_IMPORT_SCREEN_BUFFER_INFO_QNX

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_MEMORY_SCREEN_BUFFER_FEATURES_QNX

    • VK_STRUCTURE_TYPE_SCREEN_BUFFER_FORMAT_PROPERTIES_QNX

    • VK_STRUCTURE_TYPE_SCREEN_BUFFER_PROPERTIES_QNX

问题

版本历史

  • 修订版 1，2023-05-17 (Mike Gorchak)

    • 初始版本

VK_QNX_screen_surface

名称字符串

VK_QNX_screen_surface

扩展类型

实例扩展

注册扩展号

379

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_surface

联系方式

其他扩展元数据

上次修改日期

2021-01-11

IP 状态

没有已知的 IP 声明。

贡献者

  • Mike Gorchak, BlackBerry Limited

描述

VK_QNX_screen_surface 扩展是一个实例扩展。它提供了一种机制来创建一个 VkSurfaceKHR 对象（由 VK_KHR_surface 扩展定义），该对象引用 QNX Screen window，以及一个查询，用于确定是否支持渲染到 QNX Screen 合成器。

新命令

新结构体

新位掩码

新枚举常量

  • VK_QNX_SCREEN_SURFACE_EXTENSION_NAME

  • VK_QNX_SCREEN_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_SCREEN_SURFACE_CREATE_INFO_QNX

版本历史

  • 修订版 1, 2021-01-11 (Mike Gorchak)

    • 初始草案。

VK_SEC_amigo_profiling

名称字符串

VK_SEC_amigo_profiling

扩展类型

设备扩展

注册扩展号

486

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

联系方式

  • Ralph Potter r_potter

其他扩展元数据

上次修改日期

2022-07-29

IP 状态

没有已知的 IP 声明。

贡献者

  • Ralph Potter, Samsung

  • Sangrak Oh, Samsung

  • Jinku Kang, Samsung

描述

此扩展旨在将来自分层 API 实现（如 ANGLE）的信息传递给内部专有系统调度程序。除了使系统调度程序能够执行更智能的行为外，它没有其他行为含义。

应用程序开发人员应避免使用此扩展。仅为了工具和图层开发人员的利益而记录此扩展，这些开发人员可能需要操作包含这些结构的 pNext 链。

目前没有为该扩展编写规范语言。指向扩展定义的 API 的链接是指存根，这些存根仅包含生成的诸如 API 声明和隐式有效使用语句等内容。

此扩展仅适用于具有已知实现细节的特定嵌入式环境，因此未提供文档。

新结构体

新枚举常量

  • VK_SEC_AMIGO_PROFILING_EXTENSION_NAME

  • VK_SEC_AMIGO_PROFILING_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_AMIGO_PROFILING_SUBMIT_INFO_SEC

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_AMIGO_PROFILING_FEATURES_SEC

存根 API 参考

目前没有为此类型编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_SEC_amigo_profiling
typedef struct VkPhysicalDeviceAmigoProfilingFeaturesSEC {
    VkStructureType    sType;
    void*              pNext;
    VkBool32           amigoProfiling;
} VkPhysicalDeviceAmigoProfilingFeaturesSEC;
有效使用（隐式）

  • VUID-VkPhysicalDeviceAmigoProfilingFeaturesSEC-sType-sType
    sType 必须 是 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_AMIGO_PROFILING_FEATURES_SEC

目前没有为此类型编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_SEC_amigo_profiling
typedef struct VkAmigoProfilingSubmitInfoSEC {
    VkStructureType    sType;
    const void*        pNext;
    uint64_t           firstDrawTimestamp;
    uint64_t           swapBufferTimestamp;
} VkAmigoProfilingSubmitInfoSEC;
有效使用（隐式）

  • VUID-VkAmigoProfilingSubmitInfoSEC-sType-sType
    sType 必须 是 VK_STRUCTURE_TYPE_AMIGO_PROFILING_SUBMIT_INFO_SEC

版本历史

  • 修订版 1, 2022-07-29 (Ralph Potter)

    • 初始规范

VK_VALVE_descriptor_set_host_mapping

名称字符串

VK_VALVE_descriptor_set_host_mapping

扩展类型

设备扩展

注册扩展号

421

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

特殊用途
联系方式

其他扩展元数据

上次修改日期

2022-02-22

IP 状态

没有已知的 IP 声明。

贡献者

  • Hans-Kristian Arntzen, Valve

描述

此扩展允许应用程序直接查询 VkDescriptorSet 的主机指针，该指针可以用于在描述符集之间复制描述符，而无需使用 API 命令。 描述符的内存偏移量和大小可以从 VkDescriptorSetLayout 中查询。

目前没有为该扩展编写规范语言。指向扩展定义的 API 的链接是指存根，这些存根仅包含生成的诸如 API 声明和隐式有效使用语句等内容。

此扩展仅适用于具有已知实现细节的特定嵌入式环境，因此未提供文档。

新命令

新结构体

新枚举常量

  • VK_VALVE_DESCRIPTOR_SET_HOST_MAPPING_EXTENSION_NAME

  • VK_VALVE_DESCRIPTOR_SET_HOST_MAPPING_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DESCRIPTOR_SET_BINDING_REFERENCE_VALVE

    • VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_HOST_MAPPING_INFO_VALVE

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_SET_HOST_MAPPING_FEATURES_VALVE

存根 API 参考

目前没有为此命令编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_VALVE_descriptor_set_host_mapping
void vkGetDescriptorSetLayoutHostMappingInfoVALVE(
    VkDevice                                    device,
    const VkDescriptorSetBindingReferenceVALVE* pBindingReference,
    VkDescriptorSetLayoutHostMappingInfoVALVE*  pHostMapping);
有效使用（隐式）

  • VUID-vkGetDescriptorSetLayoutHostMappingInfoVALVE-device-parameter
    device 必须是有效的 VkDevice 句柄

  • VUID-vkGetDescriptorSetLayoutHostMappingInfoVALVE-pBindingReference-parameter
    pBindingReference 必须 是指向有效的 VkDescriptorSetBindingReferenceVALVE 结构的有效指针

  • VUID-vkGetDescriptorSetLayoutHostMappingInfoVALVE-pHostMapping-parameter
    pHostMapping 必须 是指向 VkDescriptorSetLayoutHostMappingInfoVALVE 结构的有效指针

目前没有为此命令编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_VALVE_descriptor_set_host_mapping
void vkGetDescriptorSetHostMappingVALVE(
    VkDevice                                    device,
    VkDescriptorSet                             descriptorSet,
    void**                                      ppData);
有效使用（隐式）

  • VUID-vkGetDescriptorSetHostMappingVALVE-device-parameter
    device 必须是有效的 VkDevice 句柄

  • VUID-vkGetDescriptorSetHostMappingVALVE-descriptorSet-parameter
    descriptorSet 必须 是有效的 VkDescriptorSet 句柄

  • VUID-vkGetDescriptorSetHostMappingVALVE-ppData-parameter
    ppData 必须 是指向指针值的有效指针

  • VUID-vkGetDescriptorSetHostMappingVALVE-descriptorSet-parent
    descriptorSet 必须 是从 device 创建、分配或检索的

目前没有为此类型编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_VALVE_descriptor_set_host_mapping
typedef struct VkPhysicalDeviceDescriptorSetHostMappingFeaturesVALVE {
    VkStructureType    sType;
    void*              pNext;
    VkBool32           descriptorSetHostMapping;
} VkPhysicalDeviceDescriptorSetHostMappingFeaturesVALVE;
有效使用（隐式）

  • VUID-VkPhysicalDeviceDescriptorSetHostMappingFeaturesVALVE-sType-sType
    sType 必须 是 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_SET_HOST_MAPPING_FEATURES_VALVE

目前没有为此类型编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_VALVE_descriptor_set_host_mapping
typedef struct VkDescriptorSetBindingReferenceVALVE {
    VkStructureType          sType;
    const void*              pNext;
    VkDescriptorSetLayout    descriptorSetLayout;
    uint32_t                 binding;
} VkDescriptorSetBindingReferenceVALVE;
有效使用（隐式）

  • VUID-VkDescriptorSetBindingReferenceVALVE-sType-sType
    sType 必须 是 VK_STRUCTURE_TYPE_DESCRIPTOR_SET_BINDING_REFERENCE_VALVE

  • VUID-VkDescriptorSetBindingReferenceVALVE-pNext-pNext
    pNext 必须为 NULL

  • VUID-VkDescriptorSetBindingReferenceVALVE-descriptorSetLayout-parameter
    descriptorSetLayout 必须 是有效的 VkDescriptorSetLayout 句柄

目前没有为此类型编写规范语言。本节仅作为占位符，以避免规范和参考页面中的死链接。

// Provided by VK_VALVE_descriptor_set_host_mapping
typedef struct VkDescriptorSetLayoutHostMappingInfoVALVE {
    VkStructureType    sType;
    void*              pNext;
    size_t             descriptorOffset;
    uint32_t           descriptorSize;
} VkDescriptorSetLayoutHostMappingInfoVALVE;
有效使用（隐式）

  • VUID-VkDescriptorSetLayoutHostMappingInfoVALVE-sType-sType
    sType 必须 是 VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_HOST_MAPPING_INFO_VALVE

  • VUID-VkDescriptorSetLayoutHostMappingInfoVALVE-pNext-pNext
    pNext 必须为 NULL

版本历史

  • 修订版 1, 2022-02-22 (Hans-Kristian Arntzen)

    • 初始规范

临时扩展列表

VK_KHR_portability_subset

名称字符串

VK_KHR_portability_subset

扩展类型

设备扩展

注册扩展号

164

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

  • 这是一个临时扩展，必须谨慎使用。有关启用和稳定性详细信息，请参阅临时头文件的描述。

联系方式

其他扩展元数据

上次修改日期

2020-07-21

IP 状态

没有已知的 IP 声明。

贡献者

  • Bill Hollings, The Brenwill Workshop Ltd.

  • Daniel Koch, NVIDIA

  • Dzmitry Malyshau, Mozilla

  • Chip Davis, CodeWeavers

  • Dan Ginsburg, Valve

  • Mike Weiblen, LunarG

  • Neil Trevett, NVIDIA

  • Alexey Knyazev, Independent

描述

VK_KHR_portability_subset 扩展允许在另一个非 Vulkan 图形 API 之上构建一个不符合规范的 Vulkan 实现，并识别该实现与完全符合规范的本地 Vulkan 实现之间的差异。

此扩展为 Vulkan 实现提供了将原本必需的功能标记为不受支持的能力，或者建立应用程序应遵守的其他属性和限制，以保证跨平台的可移植行为和操作，包括本地不支持 Vulkan 的平台。

本规范的目标是记录并提供查询功能，这些功能是完全符合规范的 Vulkan 1.0 实现所必需支持的，但对于 Vulkan 1.0 可移植子集的实现来说可能是可选的。

本扩展的意图是仅在 Vulkan 1.0 可移植子集的实现上进行通告，而不是在符合规范的 Vulkan 1.0 实现上进行通告。完全符合规范的 Vulkan 实现提供所有必需的功能，因此不会提供此扩展。因此，可以使用此扩展的存在来确定实现很可能不完全符合 Vulkan 规范。

如果 Vulkan 实现支持此扩展，则应用程序必须启用此扩展。

此扩展定义了几个可以链接到某些标准 Vulkan 调用所使用的现有结构的新结构，以便查询不符合规范的可移植行为。

新结构

新枚举常量

  • VK_KHR_PORTABILITY_SUBSET_EXTENSION_NAME

  • VK_KHR_PORTABILITY_SUBSET_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PORTABILITY_SUBSET_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PORTABILITY_SUBSET_PROPERTIES_KHR

问题

无。

版本历史

  • 修订版 1，2020-07-21 (Bill Hollings)

    • 初始草案。

VK_AMDX_shader_enqueue

名称字符串

VK_AMDX_shader_enqueue

扩展类型

设备扩展

注册扩展号

135

修订

2

批准状态

未批准

扩展和版本依赖关系

         VK_KHR_synchronization2
        和
         VK_KHR_spirv_1_4
        和
         VK_EXT_extended_dynamic_state
    或
     Vulkan 版本 1.3
和
VK_KHR_maintenance5
和
VK_KHR_pipeline_library

  • 这是一个临时扩展，必须谨慎使用。有关启用和稳定性详细信息，请参阅临时头文件的描述。

API 交互

  • 与 VK_VERSION_1_4 交互

  • 与 VK_EXT_mesh_shader 交互

  • 与 VK_KHR_maintenance5 交互

SPIR-V 依赖项
联系方式
扩展提案

VK_AMDX_shader_enqueue

其他扩展元数据

上次修改日期

2024-07-17

临时

此扩展是临时的，不应在生产应用程序中使用。该功能可能会以破坏修订版之间以及最终发布之前的向后兼容性的方式进行更改。

贡献者

  • Tobias Hector, AMD

  • Matthaeus Chajdas, AMD

  • Maciej Jesionowski, AMD

  • Robert Martin, AMD

  • Qun Lin, AMD

  • Rex Xu，AMD

  • Dominik Witczak，AMD

  • Karthik Srinivasan, AMD

  • Nicolai Haehnle, AMD

  • Stuart Smith, AMD

描述

此扩展增加了开发人员从其他计算着色器中排队网格和计算着色器工作组的功能。

新命令

新结构

新联合

新枚举常量

  • VK_AMDX_SHADER_ENQUEUE_EXTENSION_NAME

  • VK_AMDX_SHADER_ENQUEUE_SPEC_VERSION

  • VK_SHADER_INDEX_UNUSED_AMDX

  • 扩展 VkBufferUsageFlagBits

    • VK_BUFFER_USAGE_EXECUTION_GRAPH_SCRATCH_BIT_AMDX

  • 扩展 VkPipelineBindPoint

    • VK_PIPELINE_BIND_POINT_EXECUTION_GRAPH_AMDX

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXECUTION_GRAPH_PIPELINE_CREATE_INFO_AMDX

    • VK_STRUCTURE_TYPE_EXECUTION_GRAPH_PIPELINE_SCRATCH_SIZE_AMDX

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ENQUEUE_FEATURES_AMDX

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ENQUEUE_PROPERTIES_AMDX

    • VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_NODE_CREATE_INFO_AMDX

如果支持 VK_KHR_maintenance5 或 Vulkan 1.4 版本

版本历史

  • 修订版 2，2024-07-17 (Tobias Hector)

    • 添加网格节点

  • 修订版 1，2021-07-22 (Tobias Hector)

    • 初始修订版

VK_NV_cuda_kernel_launch

名称字符串

VK_NV_cuda_kernel_launch

扩展类型

设备扩展

注册扩展号

308

修订

2

批准状态

未批准

扩展和版本依赖关系

无

  • 这是一个临时扩展，必须谨慎使用。有关启用和稳定性详细信息，请参阅临时头文件的描述。

API 交互

  • 与 VK_EXT_debug_report 交互

联系方式

其他扩展元数据

上次修改日期

2020-09-30

贡献者

  • Eric Werness, NVIDIA

描述

API 之间的互操作性有时会根据所使用的平台产生额外的开销。此扩展旨在通过 Vulkan 部署现有的 CUDA 内核，并提供一种直接上传 PTX 内核并从 Vulkan 的命令缓冲区分派内核的方法，而无需在 Vulkan 和 CUDA 上下文之间使用互操作性。但是，我们鼓励实际开发使用本机 CUDA 运行时，以便进行调试和分析。

应用程序首先必须使用 vkCreateCudaModuleNV 创建 CUDA 模块，然后使用 vkCreateCudaFunctionNV 创建 CUDA 函数入口点。

然后，为了分派此函数，应用程序将创建一个命令缓冲区，在其中使用 vkCmdCudaLaunchKernelNV 启动内核。

完成后，应用程序将使用 vkDestroyCudaFunctionNV 和 vkDestroyCudaModuleNV 销毁函数句柄以及 CUDA 模块句柄。

为了减少编译时间的影响，此扩展提供了从提供的 PTX 返回二进制缓存的功能。为此，首先使用 vkGetCudaModuleCacheNV 进行首次查询，以获取所需的缓存大小，其中缓冲区指针为 NULL，且一个有效的指针接收大小；然后再次调用同一函数，使用指向缓冲区的有效指针来检索数据。随后，可以通过发送此缓存而不是 PTX 代码（使用相同的 vkCreateCudaModuleNV）来将生成的缓存用于此应用程序的进一步运行，从而显著加快 CUDA 模块的初始化速度。

与 VkPipelineCache 一样，二进制缓存取决于硬件架构。应用程序必须假定缓存可能会失败，并且需要处理在必要时回退到原始 PTX 代码的情况。通常，如果在从 PTX 生成缓存和使用此缓存之间使用相同的 GPU 驱动程序和架构，则缓存将成功。如果使用新的驱动程序版本，或者使用不同的 GPU 架构，则缓存很可能会失效。

新对象类型

新命令

新结构体

新枚举常量

  • VK_NV_CUDA_KERNEL_LAUNCH_EXTENSION_NAME

  • VK_NV_CUDA_KERNEL_LAUNCH_SPEC_VERSION

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_CUDA_FUNCTION_NV

    • VK_OBJECT_TYPE_CUDA_MODULE_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_CUDA_FUNCTION_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_CUDA_LAUNCH_INFO_NV

    • VK_STRUCTURE_TYPE_CUDA_MODULE_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUDA_KERNEL_LAUNCH_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUDA_KERNEL_LAUNCH_PROPERTIES_NV

如果支持 VK_EXT_debug_report

  • 扩展 VkDebugReportObjectTypeEXT

    • VK_DEBUG_REPORT_OBJECT_TYPE_CUDA_FUNCTION_NV_EXT

    • VK_DEBUG_REPORT_OBJECT_TYPE_CUDA_MODULE_NV_EXT

问题

无。

版本历史

  • 修订版 1，2020-03-01（Tristan Lorach）

  • 修订版 2，2020-09-30（Tristan Lorach）

VK_NV_displacement_micromap

名称字符串

VK_NV_displacement_micromap

扩展类型

设备扩展

注册扩展号

398

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_EXT_opacity_micromap

  • 这是一个临时扩展，必须谨慎使用。有关启用和稳定性详细信息，请参阅临时头文件的描述。

联系方式

其他扩展元数据

上次修改日期

2023-03-17

交互和外部依赖

待定

贡献者

  • Christoph Kubisch, NVIDIA

  • Eric Werness, NVIDIA

描述

光线追踪可以非常高效地渲染具有精细细节的几何体，但如果仅使用基本的三角形表示，则内存消耗可能成为问题。此扩展添加了添加位移贴图的功能，以使用高效的内存格式向加速结构中的三角形添加更多细节。该格式对外可见，允许应用程序提前将其内部几何表示压缩为压缩格式。此格式沿定义的向量向从主三角形细分的子三角形顶点添加位移。

此扩展提供

新结构体

新枚举

新枚举常量

  • VK_NV_DISPLACEMENT_MICROMAP_EXTENSION_NAME

  • VK_NV_DISPLACEMENT_MICROMAP_SPEC_VERSION

  • 扩展 VkBuildAccelerationStructureFlagBitsKHR

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DISPLACEMENT_MICROMAP_UPDATE_NV

  • 扩展 VkMicromapTypeEXT

    • VK_MICROMAP_TYPE_DISPLACEMENT_MICROMAP_NV

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_RAY_TRACING_DISPLACEMENT_MICROMAP_BIT_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_TRIANGLES_DISPLACEMENT_MICROMAP_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DISPLACEMENT_MICROMAP_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DISPLACEMENT_MICROMAP_PROPERTIES_NV

问题

(1) 此扩展的状态是什么？

  • 临时的，预计会发生变化。广泛的结构和编码格式是稳定的，但结构体、枚举值和着色器接口可能会发生变化。

版本历史

  • 修订版 1，2023-03-17 (Eric Werness)

    • 初始公开修订版

  • 修订版 2，2023-07-07 (Eric Werness)

    • 为解码内在函数添加着色器支持

已弃用扩展列表

VK_KHR_16bit_storage

名称字符串

VK_KHR_16bit_storage

扩展类型

设备扩展

注册扩展号

84

修订

1

批准状态

已批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
     和
     VK_KHR_storage_buffer_storage_class
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-09-05

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Alexander Galazin，ARM

  • Jan-Harald Fredriksen, ARM

  • Joerg Wagner，ARM

  • Neil Henning, Codeplay

  • Jeff Bolz, Nvidia

  • Daniel Koch, Nvidia

  • David Neto，Google

  • John Kessenich，Google

描述

VK_KHR_16bit_storage 扩展允许在着色器输入和输出接口以及推送常量块中使用 16 位类型。此扩展引入了几个新的可选功能，这些功能映射到 SPIR-V 功能，并允许访问 Uniform 和 StorageBuffer 存储类中 Block 修饰的对象以及 PushConstant 存储类中的对象的 16 位数据。此扩展允许将 16 位变量声明并用作用户定义的着色器输入和输出，但不会更改位置分配和组件分配规则。

晋升至 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。但是，如果支持 Vulkan 1.1 并且不支持此扩展，则 storageBuffer16BitAccess 功能是可选的。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构体

新枚举常量

  • VK_KHR_16BIT_STORAGE_EXTENSION_NAME

  • VK_KHR_16BIT_STORAGE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES_KHR

新的 SPIR-V 功能

版本历史

  • 修订版 1，2017-03-23 (Alexander Galazin)

    • 初始草案

VK_KHR_8bit_storage

名称字符串

VK_KHR_8bit_storage

扩展类型

设备扩展

注册扩展号

178

修订

1

批准状态

已批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
     和
     VK_KHR_storage_buffer_storage_class
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-02-05

交互和外部依赖
IP 状态

没有已知的 IP 声明。

贡献者

  • Alexander Galazin, Arm

描述

VK_KHR_8bit_storage 扩展允许在 uniform 和 storage 缓冲区以及 push 常量块中使用 8 位类型。此扩展引入了几个新的可选功能，这些功能映射到 SPIR-V 功能，并允许访问 Uniform 和 StorageBuffer 存储类中 Block 修饰对象以及 PushConstant 存储类中的对象的 8 位数据。

此扩展的所有实现**必须**支持 StorageBuffer8BitAccess 功能。其他功能是可选的。

提升至 Vulkan 1.2

此扩展中的 Vulkan API 已包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。但是，如果支持 Vulkan 1.2 且不支持此扩展，则 StorageBuffer8BitAccess 功能是可选的。此扩展定义的外部交互，例如 SPIR-V 令牌名称，保留其原始名称。原始 Vulkan API 名称仍然可用作核心功能的别名。

新结构体

新枚举常量

  • VK_KHR_8BIT_STORAGE_EXTENSION_NAME

  • VK_KHR_8BIT_STORAGE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_8BIT_STORAGE_FEATURES_KHR

新的 SPIR-V 功能

版本历史

  • 修订版 1，2018-02-05 (Alexander Galazin)

    • 初始草案

VK_KHR_bind_memory2

名称字符串

VK_KHR_bind_memory2

扩展类型

设备扩展

注册扩展号

158

修订

1

批准状态

已批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-09-05

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

  • Tobias Hector, Imagination Technologies

描述

此扩展提供了 vkBindBufferMemory 和 vkBindImageMemory 的版本，允许一次执行多个绑定，并且是可扩展的。

此扩展还引入了 VK_IMAGE_CREATE_ALIAS_BIT_KHR，它允许 “相同的” 图像别名相同的内存，以便即使在图像布局更改后也能一致地解释内容。

提升至 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新命令

新结构体

新枚举常量

  • VK_KHR_BIND_MEMORY_2_EXTENSION_NAME

  • VK_KHR_BIND_MEMORY_2_SPEC_VERSION

  • 扩展 VkImageCreateFlagBits

    • VK_IMAGE_CREATE_ALIAS_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BIND_BUFFER_MEMORY_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_INFO_KHR

版本历史

  • 修订版 1，2017-05-19 (Tobias Hector)

    • 将绑定内存函数拉入其自己的扩展

VK_KHR_buffer_device_address

名称字符串

VK_KHR_buffer_device_address

扩展类型

设备扩展

注册扩展号

258

修订

1

批准状态

已批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
     和
     VK_KHR_device_group
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-06-24

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

  • Neil Henning, AMD

  • Tobias Hector, AMD

  • Faith Ekstrand, Intel

  • Baldur Karlsson, Valve

  • Jan-Harald Fredriksen, Arm

描述

此扩展允许应用程序查询缓冲区的 64 位设备地址值，该值可用于通过 GL_EXT_buffer_reference GLSL 扩展和 SPV_KHR_physical_storage_buffer SPIR-V 扩展中的 PhysicalStorageBuffer 存储类访问缓冲区内存。

描述此扩展的另一种方式是，它在着色器中添加了 “指向缓冲区内存的指针”。通过调用带有 VkBuffer 的 vkGetBufferDeviceAddress，它将返回一个 VkDeviceAddress 值，该值表示缓冲区起始地址。

vkGetBufferOpaqueCaptureAddress 和 vkGetDeviceMemoryOpaqueCaptureAddress 允许为当前进程查询缓冲区和内存对象的不透明地址。然后，跟踪捕获和重放工具可以提供这些地址，以便在重放时使用以匹配捕获跟踪时使用的地址。为了使工具能够插入这些查询，必须为将绑定到通过 PhysicalStorageBuffer 存储类访问的缓冲区的内存对象指定新的内存分配标志。请注意，此机制仅用于支持捕获/重放工具，不建议在其他应用程序中使用。

提升至 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。但是，如果支持 Vulkan 1.2 且不支持此扩展，则 bufferDeviceAddress 功能是可选的。原始类型、枚举和命令名称仍然可用作核心功能的别名。

提升至 Vulkan 1.3

无论是否支持此扩展，Vulkan 1.3 中强制支持 bufferDeviceAddress 功能。

新命令

新结构体

新枚举常量

  • VK_KHR_BUFFER_DEVICE_ADDRESS_EXTENSION_NAME

  • VK_KHR_BUFFER_DEVICE_ADDRESS_SPEC_VERSION

  • 扩展 VkBufferCreateFlagBits

    • VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_KHR

  • 扩展 VkBufferUsageFlagBits

    • VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_KHR

  • 扩展 VkMemoryAllocateFlagBits

    • VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT_KHR

    • VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_KHR

  • 扩展 VkResult

    • VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_INFO_KHR

    • VK_STRUCTURE_TYPE_BUFFER_OPAQUE_CAPTURE_ADDRESS_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_MEMORY_OPAQUE_CAPTURE_ADDRESS_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_OPAQUE_CAPTURE_ADDRESS_ALLOCATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_KHR

新的 SPIR-V 能力

版本历史

  • 修订版 1，2019-06-24 (Jan-Harald Fredriksen)

    • 基于 VK_EXT_buffer_device_address 的内部修订

VK_KHR_copy_commands2

名称字符串

VK_KHR_copy_commands2

扩展类型

设备扩展

注册扩展号

338

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2020-07-06

贡献者

  • Jeff Leger, Qualcomm

  • Tobias Hector, AMD

  • Jan-Harald Fredriksen, ARM

  • Tom Olson, ARM

描述

此扩展提供 Vulkan 缓冲区和图像复制命令的可扩展版本。新的命令在功能上与核心命令相同，只是它们的复制参数是使用可扩展的结构指定的，这些结构可用于传递特定于扩展的信息。

此扩展引入了以下可扩展的复制命令：vkCmdCopyBuffer2KHR、vkCmdCopyImage2KHR、vkCmdCopyBufferToImage2KHR、vkCmdCopyImageToBuffer2KHR、vkCmdBlitImage2KHR 和 vkCmdResolveImage2KHR。每个命令都包含一个 *Info2KHR 结构参数，该参数包括 sType/pNext 成员。描述要复制的每个区域的较低级别结构也使用 sType/pNext 成员进行扩展。

新命令

新结构

新枚举常量

  • VK_KHR_COPY_COMMANDS_2_EXTENSION_NAME

  • VK_KHR_COPY_COMMANDS_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BLIT_IMAGE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_BUFFER_COPY_2_KHR

    • VK_STRUCTURE_TYPE_BUFFER_IMAGE_COPY_2_KHR

    • VK_STRUCTURE_TYPE_COPY_BUFFER_INFO_2_KHR

    • VK_STRUCTURE_TYPE_COPY_BUFFER_TO_IMAGE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_COPY_IMAGE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_COPY_IMAGE_TO_BUFFER_INFO_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_BLIT_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_COPY_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_RESOLVE_2_KHR

    • VK_STRUCTURE_TYPE_RESOLVE_IMAGE_INFO_2_KHR

提升到 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 KHR 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍可用作核心功能的别名。

版本历史

  • 修订版 1，2020-07-06 (Jeff Leger)

    • 内部修订

VK_KHR_create_renderpass2

名称字符串

VK_KHR_create_renderpass2

扩展类型

设备扩展

注册扩展号

110

修订

1

批准状态

已批准

扩展和版本依赖关系

     VK_KHR_multiview
     和
     VK_KHR_maintenance2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-02-07

贡献者

  • Tobias Hector

  • Jeff Bolz

描述

此扩展提供了一个新命令来创建渲染通道，该命令可以通过渲染通道创建的子结构轻松地被其他扩展所扩展。Vulkan 1.0 渲染通道创建子结构不包括 sType/pNext 成员。此外，渲染通道 begin/next/end 命令已使用新的可扩展结构进行了增强，用于传递额外的子通道信息。

扩展原始 VkRenderPassCreateInfo 的 VkRenderPassMultiviewCreateInfo 和 VkInputAttachmentAspectReference 结构不被新的创建函数接受，而是它们的参数被折叠到此扩展中，如下所示

这些映射的详细信息在新结构中完整说明。

提升到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新命令

新结构

新枚举常量

  • VK_KHR_CREATE_RENDERPASS_2_EXTENSION_NAME

  • VK_KHR_CREATE_RENDERPASS_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2_KHR

    • VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2_KHR

    • VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_BEGIN_INFO_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_DEPENDENCY_2_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_2_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_END_INFO_KHR

版本历史

  • 修订版 1，2018-02-07 (Tobias Hector)

    • 内部修订

VK_KHR_dedicated_allocation

名称字符串

VK_KHR_dedicated_allocation

扩展类型

设备扩展

注册扩展号

128

修订

3

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_memory_requirements2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-09-05

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

  • Faith Ekstrand, Intel

描述

此扩展允许资源绑定到专用分配，而不是子分配。对于任何特定资源，应用程序可以查询是否建议使用专用分配，在这种情况下，使用专用分配可能会提高访问该资源的性能。正常的设备内存分配必须支持每个分配多个资源、内存别名和稀疏绑定，这可能会干扰某些优化。当使用专用分配可能有益时，应用程序应通过向传递给 vkGetBufferMemoryRequirements2 或 vkGetImageMemoryRequirements2 调用的 VkMemoryRequirements2 结构的 pNext 链添加 VkMemoryDedicatedRequirementsKHR 结构来查询实现。某些外部句柄类型和外部图像或缓冲区可能还取决于将图像或缓冲区元数据与操作系统级内存对象关联的实现上的专用分配。

此扩展向内存需求查询和内存分配添加了两个小结构：一个新结构，用于标记图像/缓冲区是否应具有专用分配，以及一个指示分配将绑定到的图像或缓冲区的结构。

晋升到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构

新的枚举常量

  • VK_KHR_DEDICATED_ALLOCATION_EXTENSION_NAME

  • VK_KHR_DEDICATED_ALLOCATION_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR

示例

    // Create an image with a dedicated allocation based on the
    // implementation's preference

    VkImageCreateInfo imageCreateInfo =
    {
        // Image creation parameters
    };

    VkImage image;
    VkResult result = vkCreateImage(
        device,
        &imageCreateInfo,
        NULL,               // pAllocator
        &image);

    VkMemoryDedicatedRequirementsKHR dedicatedRequirements =
    {
        .sType = VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR,
        .pNext = NULL,
    };

    VkMemoryRequirements2 memoryRequirements =
    {
        .sType = VK_STRUCTURE_TYPE_MEMORY_REQUIREMENTS_2,
        .pNext = &dedicatedRequirements,
    };

    const VkImageMemoryRequirementsInfo2 imageRequirementsInfo =
    {
        .sType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_REQUIREMENTS_INFO_2,
        .pNext = NULL,
        .image = image
    };

    vkGetImageMemoryRequirements2(
        device,
        &imageRequirementsInfo,
        &memoryRequirements);

    if (dedicatedRequirements.prefersDedicatedAllocation) {
        // Allocate memory with VkMemoryDedicatedAllocateInfoKHR::image
        // pointing to the image we are allocating the memory for

        VkMemoryDedicatedAllocateInfoKHR dedicatedInfo =
        {
            .sType = VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR,
            .pNext = NULL,
            .image = image,
            .buffer = VK_NULL_HANDLE,
        };

        VkMemoryAllocateInfo memoryAllocateInfo =
        {
            .sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO,
            .pNext = &dedicatedInfo,
            .allocationSize = memoryRequirements.size,
            .memoryTypeIndex = FindMemoryTypeIndex(memoryRequirements.memoryTypeBits),
        };

        VkDeviceMemory memory;
        vkAllocateMemory(
            device,
            &memoryAllocateInfo,
            NULL,               // pAllocator
            &memory);

        // Bind the image to the memory

        vkBindImageMemory(
            device,
            image,
            memory,
            0);
    } else {
        // Take the normal memory sub-allocation path
    }

版本历史

  • 版本 1，2017-02-27 (James Jones)

    • 从 VK_NV_dedicated_allocation 复制内容

    • 向概述添加一些对外部对象交互的引用。

  • 修订版 2，2017-03-27（Faith Ekstrand）

    • 重新设计扩展以基于查询

  • 修订版 3，2017-07-31（Faith Ekstrand）

    • 明确使用 VkMemoryDedicatedAllocateInfoKHR 分配的内存对象只能绑定指定的资源，不能绑定其他资源。

VK_KHR_depth_stencil_resolve

名称字符串

VK_KHR_depth_stencil_resolve

扩展类型

设备扩展

注册扩展号

200

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_create_renderpass2
或
Vulkan 版本 1.2

弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-04-09

贡献者

  • Jan-Harald Fredriksen, Arm

  • Andrew Garrard，三星电子

  • Soowan Park，三星电子

  • Jeff Bolz, NVIDIA

  • Daniel Rakos, AMD

描述

此扩展增加了对子通道中自动解析多重采样的深度/模板附件的支持，其方式与颜色附件类似。

多重采样的颜色附件可以通过指定与 pColorAttachments 数组条目对应的 pResolveAttachments 条目在子通道末尾解析。这不允许将解析附件映射到深度/模板附件。 vkCmdResolveImage 命令不允许用于深度/模板图像。虽然还有其他方法可以解析深度/模板附件，但它们可能会导致次优性能。此扩展中的扩展 VkSubpassDescription2 允许应用程序添加一个 pDepthStencilResolveAttachment，它类似于颜色 pResolveAttachments，pDepthStencilAttachment 可以解析为该附件。

深度和模板样本根据解析模式解析为单个值。可能的解析模式集在 VkResolveModeFlagBits 枚举中定义。 VK_RESOLVE_MODE_SAMPLE_ZERO_BIT 模式是所有实现（支持扩展或支持 Vulkan 1.2 或更高版本）都需要的唯一模式。某些实现可能还支持平均（与颜色样本解析相同）或取最小或最大样本，这可能更适合深度/模板解析。

晋升到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构

新枚举

新位掩码

新的枚举常量

  • VK_KHR_DEPTH_STENCIL_RESOLVE_EXTENSION_NAME

  • VK_KHR_DEPTH_STENCIL_RESOLVE_SPEC_VERSION

  • 扩展 VkResolveModeFlagBits

    • VK_RESOLVE_MODE_AVERAGE_BIT_KHR

    • VK_RESOLVE_MODE_MAX_BIT_KHR

    • VK_RESOLVE_MODE_MIN_BIT_KHR

    • VK_RESOLVE_MODE_NONE_KHR

    • VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_STENCIL_RESOLVE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR

版本历史

  • 修订版 1，2018-04-09（Jan-Harald Fredriksen）

    • 初始修订版

VK_KHR_descriptor_update_template

名称字符串

VK_KHR_descriptor_update_template

扩展类型

设备扩展

注册扩展号

86

修订

1

批准状态

已批准

扩展和版本依赖关系

无

API 交互

  • 与 VK_EXT_debug_report 交互

  • 与 VK_KHR_push_descriptor 交互

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-09-05

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

  • Michael Worcester, Imagination Technologies

描述

应用程序可能希望非常频繁地更新大量描述符集中的一组固定描述符，例如在初始化阶段或如果需要为每个帧重建描述符集。对于这些情况，也不太可能将更新单个描述符集所需的所有信息都存储在单个结构中。此扩展提供了一种使用指向描述新描述符的应用程序定义的数据结构的指针，在单个 VkDescriptorSet 中更新一组固定描述符的方法。

晋升到 Vulkan 1.1

vkCmdPushDescriptorSetWithTemplateKHR 作为与 VK_KHR_push_descriptor 的交互而包含。如果支持 Vulkan 1.1 和 VK_KHR_push_descriptor，则由 VK_KHR_push_descriptor 包含此项。

此扩展中的基本功能包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍可作为核心功能的别名使用。

新对象类型

新命令

如果支持 VK_KHR_push_descriptor

新结构体

新枚举

新位掩码

新枚举常量

  • VK_KHR_DESCRIPTOR_UPDATE_TEMPLATE_EXTENSION_NAME

  • VK_KHR_DESCRIPTOR_UPDATE_TEMPLATE_SPEC_VERSION

  • 扩展 VkDescriptorUpdateTemplateType

    • VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_DESCRIPTOR_SET_KHR

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_CREATE_INFO_KHR

如果支持 VK_EXT_debug_report

如果支持 VK_KHR_push_descriptor

版本历史

  • 修订版 1，2016-01-11 (Markus Tavenrath)

    • 初始草案

VK_KHR_device_group

名称字符串

VK_KHR_device_group

扩展类型

设备扩展

注册扩展号

61

修订

4

批准状态

已批准

扩展和版本依赖关系

VK_KHR_device_group_creation

API 交互

  • 与 VK_KHR_bind_memory2 交互

  • 与 VK_KHR_surface 交互

  • 与 VK_KHR_swapchain 交互

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-10-10

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

  • Tobias Hector, Imagination Technologies

描述

此扩展提供了使用由多个物理设备组成的逻辑设备的功能，这些物理设备是使用 VK_KHR_device_group_creation 扩展创建的。设备组可以在子设备之间分配内存，将一个子设备的内存绑定到另一个子设备上的资源，记录命令缓冲区，其中一些工作在子设备的任意子集上执行，并且可能从一个或多个子设备呈现交换链图像。

晋升到 Vulkan 1.1

以下枚举，类型和命令作为与 VK_KHR_swapchain 的交互包含在内。

如果支持 Vulkan 1.1 和 VK_KHR_swapchain，则这些包含在 VK_KHR_swapchain 中。

此扩展中的基本功能包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍可作为核心功能的别名使用。

新命令

如果支持 VK_KHR_surface

如果支持 VK_KHR_swapchain

新结构体

如果支持 VK_KHR_bind_memory2

如果支持 VK_KHR_surface

如果支持 VK_KHR_swapchain

新枚举

如果支持 VK_KHR_surface

新位掩码

如果支持 VK_KHR_surface

新枚举常量

  • VK_KHR_DEVICE_GROUP_EXTENSION_NAME

  • VK_KHR_DEVICE_GROUP_SPEC_VERSION

  • 扩展 VkDependencyFlagBits

    • VK_DEPENDENCY_DEVICE_GROUP_BIT_KHR

  • 扩展 VkMemoryAllocateFlagBits

    • VK_MEMORY_ALLOCATE_DEVICE_MASK_BIT_KHR

  • 扩展 VkPeerMemoryFeatureFlagBits

    • VK_PEER_MEMORY_FEATURE_COPY_DST_BIT_KHR

    • VK_PEER_MEMORY_FEATURE_COPY_SRC_BIT_KHR

    • VK_PEER_MEMORY_FEATURE_GENERIC_DST_BIT_KHR

    • VK_PEER_MEMORY_FEATURE_GENERIC_SRC_BIT_KHR

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_DISPATCH_BASE_KHR

    • VK_PIPELINE_CREATE_VIEW_INDEX_FROM_DEVICE_INDEX_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_BIND_SPARSE_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_COMMAND_BUFFER_BEGIN_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_RENDER_PASS_BEGIN_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_SUBMIT_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_FLAGS_INFO_KHR

如果支持 VK_KHR_bind_memory2

  • 扩展 VkImageCreateFlagBits

    • VK_IMAGE_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BIND_BUFFER_MEMORY_DEVICE_GROUP_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_DEVICE_GROUP_INFO_KHR

如果支持 VK_KHR_surface

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_CAPABILITIES_KHR

如果支持 VK_KHR_swapchain

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ACQUIRE_NEXT_IMAGE_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_SWAPCHAIN_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_SWAPCHAIN_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_IMAGE_SWAPCHAIN_CREATE_INFO_KHR

  • 扩展 VkSwapchainCreateFlagBitsKHR

    • VK_SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR

新的内置变量

新的 SPIR-V 功能

版本历史

  • 修订版 1，2016-10-19 (Jeff Bolz)

    • 内部修订

  • 修订版 2，2017-05-19 (Tobias Hector)

    • 已将扩展的内存绑定函数移动到 VK_KHR_bind_memory2，添加了对该扩展的依赖关系，并为这些函数添加了特定于设备组的结构。

  • 修订版 3，2017-10-06 (Ian Elliott)

    • 更正了 Vulkan 1.1 与 WSI 扩展的交互。所有 Vulkan 1.1 WSI 交互都与 VK_KHR_swapchain 扩展进行。

  • 修订版 4，2017-10-10 (Jeff Bolz)

    • 将“SFR”位和结构成员重命名为使用短语“拆分实例绑定区域”。

VK_KHR_device_group_creation

名称字符串

VK_KHR_device_group_creation

扩展类型

实例扩展

注册扩展号

71

修订

1

批准状态

已批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-10-19

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展提供实例级别的命令来枚举物理设备组，并从其中一个组的子集中创建一个逻辑设备。然后，可以将这样的逻辑设备与 VK_KHR_device_group 扩展中的新功能一起使用。

晋升到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新命令

新结构体

新枚举常量

  • VK_KHR_DEVICE_GROUP_CREATION_EXTENSION_NAME

  • VK_KHR_DEVICE_GROUP_CREATION_SPEC_VERSION

  • VK_MAX_DEVICE_GROUP_SIZE_KHR

  • 扩展 VkMemoryHeapFlagBits

    • VK_MEMORY_HEAP_MULTI_INSTANCE_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_DEVICE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES_KHR

示例

    VkDeviceCreateInfo devCreateInfo = { VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO };
    // (not shown) fill out devCreateInfo as usual.
    uint32_t deviceGroupCount = 0;
    VkPhysicalDeviceGroupPropertiesKHR *props = NULL;

    // Query the number of device groups
    vkEnumeratePhysicalDeviceGroupsKHR(g_vkInstance, &deviceGroupCount, NULL);

    // Allocate and initialize structures to query the device groups
    props = (VkPhysicalDeviceGroupPropertiesKHR *)malloc(deviceGroupCount*sizeof(VkPhysicalDeviceGroupPropertiesKHR));
    for (i = 0; i < deviceGroupCount; ++i) {
        props[i].sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES_KHR;
        props[i].pNext = NULL;
    }
    vkEnumeratePhysicalDeviceGroupsKHR(g_vkInstance, &deviceGroupCount, props);

    // If the first device group has more than one physical device. create
    // a logical device using all of the physical devices.
    VkDeviceGroupDeviceCreateInfoKHR deviceGroupInfo = { VK_STRUCTURE_TYPE_DEVICE_GROUP_DEVICE_CREATE_INFO_KHR };
    if (props[0].physicalDeviceCount > 1) {
        deviceGroupInfo.physicalDeviceCount = props[0].physicalDeviceCount;
        deviceGroupInfo.pPhysicalDevices = props[0].physicalDevices;
        devCreateInfo.pNext = &deviceGroupInfo;
    }

    vkCreateDevice(props[0].physicalDevices[0], &devCreateInfo, NULL, &g_vkDevice);
    free(props);

版本历史

  • 修订版 1，2016-10-19 (Jeff Bolz)

    • 内部修订

VK_KHR_draw_indirect_count

名称字符串

VK_KHR_draw_indirect_count

扩展类型

设备扩展

注册扩展号

170

修订

1

批准状态

已批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-08-25

IP 状态

没有已知的 IP 声明。

贡献者

  • Matthaeus G. Chajdas, AMD

  • Derrick Owens, AMD

  • Graham Sellers, AMD

  • Daniel Rakos, AMD

  • Dominik Witczak，AMD

  • Piers Daniell, NVIDIA

描述

此扩展基于 VK_AMD_draw_indirect_count 扩展。此扩展允许应用程序从缓冲区获取间接绘制调用的绘制数量。

应用程序可能希望在绘制之前通过计算着色器在 GPU 上进行剔除。这使应用程序能够生成任意数量的绘制命令并在没有主机干预的情况下执行它们。

晋升到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。但是，如果支持 Vulkan 1.2 并且不支持此扩展，则命令 vkCmdDrawIndirectCount 和 vkCmdDrawIndexedIndirectCount 是可选的。原始类型、枚举和命令名称仍可用作核心功能的别名。

新命令

新枚举常量

  • VK_KHR_DRAW_INDIRECT_COUNT_EXTENSION_NAME

  • VK_KHR_DRAW_INDIRECT_COUNT_SPEC_VERSION

版本历史

  • 修订版 1，2017-08-25 (Piers Daniell)

    • 基于 VK_AMD_draw_indirect_count 的初始草案

VK_KHR_driver_properties

名称字符串

VK_KHR_driver_properties

扩展类型

设备扩展

注册扩展号

197

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-04-11

IP 状态

没有已知的 IP 声明。

贡献者

  • Baldur Karlsson

  • Matthaeus G. Chajdas, AMD

  • Piers Daniell, NVIDIA

  • Alexander Galazin, Arm

  • Jesse Hall, Google

  • Daniel Rakos, AMD

描述

此扩展提供了一个新的物理设备查询，允许检索有关驱动程序实现的信息，从而使应用程序能够确定哪个物理设备对应于哪个特定供应商的驱动程序，以及驱动程序实现符合哪个一致性测试套件版本。

升级到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构体

新枚举

新枚举常量

  • VK_KHR_DRIVER_PROPERTIES_EXTENSION_NAME

  • VK_KHR_DRIVER_PROPERTIES_SPEC_VERSION

  • VK_MAX_DRIVER_INFO_SIZE_KHR

  • VK_MAX_DRIVER_NAME_SIZE_KHR

  • 扩展 VkDriverId

    • VK_DRIVER_ID_AMD_OPEN_SOURCE_KHR

    • VK_DRIVER_ID_AMD_PROPRIETARY_KHR

    • VK_DRIVER_ID_ARM_PROPRIETARY_KHR

    • VK_DRIVER_ID_BROADCOM_PROPRIETARY_KHR

    • VK_DRIVER_ID_GGP_PROPRIETARY_KHR

    • VK_DRIVER_ID_GOOGLE_SWIFTSHADER_KHR

    • VK_DRIVER_ID_IMAGINATION_PROPRIETARY_KHR

    • VK_DRIVER_ID_INTEL_OPEN_SOURCE_MESA_KHR

    • VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS_KHR

    • VK_DRIVER_ID_MESA_RADV_KHR

    • VK_DRIVER_ID_NVIDIA_PROPRIETARY_KHR

    • VK_DRIVER_ID_QUALCOMM_PROPRIETARY_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR

版本历史

  • 修订版 1，2018-04-11 (Daniel Rakos)

    • 内部修订

VK_KHR_dynamic_rendering

名称字符串

VK_KHR_dynamic_rendering

扩展类型

设备扩展

注册扩展号

45

修订

1

批准状态

已批准

扩展和版本依赖关系

         VK_KHR_get_physical_device_properties2
         或
         Vulkan 版本 1.1
     和
     VK_KHR_depth_stencil_resolve
或
Vulkan 版本 1.2

弃用状态
联系方式
扩展提案

VK_KHR_dynamic_rendering

其他扩展元数据

上次修改日期

2021-10-06

贡献者

  • Tobias Hector, AMD

  • Arseny Kapoulkine, Roblox

  • François Duranleau, Gameloft

  • Stuart Smith, AMD

  • Hai Nguyen, Google

  • Jean-François Roy, Google

  • Jeff Leger, Qualcomm

  • Jan-Harald Fredriksen, Arm

  • Piers Daniell, Nvidia

  • James Fitzpatrick，Imagination

  • Piotr Byszewski, Mobica

  • Jesse Hall, Google

  • Mike Blumenkrantz, Valve

描述

此扩展允许应用程序创建单通道渲染过程实例，而无需创建渲染过程对象或帧缓冲。动态渲染过程也可以跨多个主命令缓冲区，而不是依赖于辅助命令缓冲区。

此扩展还包含来自 VK_QCOM_render_pass_store_ops 的 VK_ATTACHMENT_STORE_OP_NONE_KHR，使应用程序能够在渲染过程期间不写入附件时避免不必要的同步。

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_KHR_DYNAMIC_RENDERING_EXTENSION_NAME

  • VK_KHR_DYNAMIC_RENDERING_SPEC_VERSION

  • 扩展 VkAttachmentStoreOp

    • VK_ATTACHMENT_STORE_OP_NONE_KHR

  • 扩展 VkRenderingFlagBits

    • VK_RENDERING_CONTENTS_SECONDARY_COMMAND_BUFFERS_BIT_KHR

    • VK_RENDERING_RESUMING_BIT_KHR

    • VK_RENDERING_SUSPENDING_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_RENDERING_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DYNAMIC_RENDERING_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_RENDERING_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_INFO_KHR

    • VK_STRUCTURE_TYPE_RENDERING_INFO_KHR

升级到 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 KHR 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍可用作核心功能的别名。

版本历史

  • 修订版 1，2021-10-06 (Tobias Hector)

    • 初始修订版

VK_KHR_dynamic_rendering_local_read

名称字符串

VK_KHR_dynamic_rendering_local_read

扩展类型

设备扩展

注册扩展号

233

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_dynamic_rendering
或
Vulkan 版本 1.3

弃用状态
联系方式
扩展提案

VK_KHR_dynamic_rendering_local_read

其他扩展元数据

上次修改日期

2023-11-03

贡献者

  • Tobias Hector, AMD

  • Hans-Kristian Arntzen, Valve

  • Connor Abbott, 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

  • Wyvern Wang, Huawei

  • Jeff Bolz, Nvidia

  • Samuel (Sheng-Wen) Huang, MediaTek

描述

此扩展支持从动态渲染过程中的先前片段着色器写入的附件和资源中读取。

新命令

新结构体

新枚举常量

  • VK_KHR_DYNAMIC_RENDERING_LOCAL_READ_EXTENSION_NAME

  • VK_KHR_DYNAMIC_RENDERING_LOCAL_READ_SPEC_VERSION

  • 扩展 VkImageLayout

    • VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DYNAMIC_RENDERING_LOCAL_READ_FEATURES_KHR

    • VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_LOCATION_INFO_KHR

    • VK_STRUCTURE_TYPE_RENDERING_INPUT_ATTACHMENT_INDEX_INFO_KHR

升级到 Vulkan 1.4

此扩展中的功能已包含在核心 Vulkan 1.4 中，省略了 KHR 后缀。但是，Vulkan 1.4 实现只需要支持存储资源和单采样颜色附件的本地读取。

对读取深度/模板附件和多采样附件的支持分别由新的布尔值 dynamicRenderingLocalReadDepthStencilAttachments 和 dynamicRenderingLocalReadMultisampledAttachments 属性控制，如 1.4 版本附录中所述。

原始类型、枚举和命令名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1，2023-11-03 (Tobias Hector)

    • 初始修订版

VK_KHR_external_fence

名称字符串

VK_KHR_external_fence

扩展类型

设备扩展

注册扩展号

114

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_fence_capabilities

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-05-08

IP 状态

没有已知的 IP 声明。

贡献者

描述

使用外部内存的应用程序可能希望使用栅栏同步对该内存的访问。此扩展使应用程序能够创建可以从中导出引用底层同步原语的非 Vulkan 句柄的栅栏。

升级到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构体

新枚举

新位掩码

新枚举常量

  • VK_KHR_EXTERNAL_FENCE_EXTENSION_NAME

  • VK_KHR_EXTERNAL_FENCE_SPEC_VERSION

  • 扩展 VkFenceImportFlagBits

    • VK_FENCE_IMPORT_TEMPORARY_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXPORT_FENCE_CREATE_INFO_KHR

问题

此扩展借鉴了 VK_KHR_external_semaphore 的概念、语义和语言。该扩展的问题同样适用于此扩展。

版本历史

  • 修订版 1，2017-05-08 (Jesse Hall)

    • 初始修订版

VK_KHR_external_fence_capabilities

名称字符串

VK_KHR_external_fence_capabilities

扩展类型

实例扩展

注册扩展号

113

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-05-08

IP 状态

没有已知的 IP 声明。

贡献者

描述

应用程序可能希望在多个 Vulkan 逻辑设备或实例中，在多个进程中，和/或在多个 API 中引用设备栅栏。此扩展提供了一组功能查询和句柄定义，允许应用程序确定实现为给定用例支持哪些类型的“外部”栅栏句柄。

升级到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新命令

新结构

新枚举

新位掩码

新枚举常量

  • VK_KHR_EXTERNAL_FENCE_CAPABILITIES_EXTENSION_NAME

  • VK_KHR_EXTERNAL_FENCE_CAPABILITIES_SPEC_VERSION

  • VK_LUID_SIZE_KHR

  • 扩展 VkExternalFenceFeatureFlagBits

    • VK_EXTERNAL_FENCE_FEATURE_EXPORTABLE_BIT_KHR

    • VK_EXTERNAL_FENCE_FEATURE_IMPORTABLE_BIT_KHR

  • 扩展 VkExternalFenceHandleTypeFlagBits

    • VK_EXTERNAL_FENCE_HANDLE_TYPE_OPAQUE_FD_BIT_KHR

    • VK_EXTERNAL_FENCE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR

    • VK_EXTERNAL_FENCE_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR

    • VK_EXTERNAL_FENCE_HANDLE_TYPE_SYNC_FD_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXTERNAL_FENCE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FENCE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR

版本历史

  • 修订版 1，2017-05-08 (Jesse Hall)

    • 初始版本

VK_KHR_external_memory

名称字符串

VK_KHR_external_memory

扩展类型

设备扩展

注册扩展号

73

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_memory_capabilities
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-10-20

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Faith Ekstrand, Intel

  • Ian Elliott, Google

  • Jesse Hall, Google

  • Tobias Hector, Imagination Technologies

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Matthew Netsch，高通技术公司

  • Daniel Rakos, AMD

  • Carsten Rohde, NVIDIA

  • Ray Smith, ARM

  • Lina Versace，谷歌

描述

应用程序可能希望在多个 Vulkan 逻辑设备或实例中，在多个进程中，和/或在多个 API 中引用设备内存。此扩展允许应用程序从 Vulkan 内存对象导出非 Vulkan 句柄，以便在创建它们的 Vulkan 逻辑设备的范围之外引用底层资源。

升级到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构

新枚举常量

  • VK_KHR_EXTERNAL_MEMORY_EXTENSION_NAME

  • VK_KHR_EXTERNAL_MEMORY_SPEC_VERSION

  • VK_QUEUE_FAMILY_EXTERNAL_KHR

  • 扩展 VkResult

    • VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_KHR

    • VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_BUFFER_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_KHR

问题

1) 应用程序如何在跨进程或 Vulkan 实例边界关联两个物理设备？

已解决：VK_KHR_external_memory_capabilities 引入了新的设备 ID 字段。这些字段与现有的 VkPhysicalDeviceProperties::driverVersion 字段结合使用，可以识别跨进程、驱动程序和 API 的兼容设备。VkPhysicalDeviceProperties::pipelineCacheUUID 不足以实现此目的，因为尽管规范中对此进行了描述，但实际上它只需要识别唯一的管道缓存格式即可。多个设备可能能够使用相同的管道缓存数据，因此希望它们都具有相同的管道缓存 UUID。但是，在共享内存时只能使用相同的具体物理设备，因此引入了实际的唯一设备 ID。此外，管道缓存 UUID 专门用于 Vulkan，但需要与其他不可扩展的 API 进行关联，以实现与这些 API 的互操作。

2) 如果在进程和 API 之间共享内存对象，根据 内存别名 部分中概述的规则，这是否被认为是别名？

已解决：是的。在跨多个 Vulkan 实例或其他 API 使用内存时，应用程序必须注意遵守对别名资源施加的所有限制。

3) 是否需要新的图像布局或元数据来指定与非 Vulkan API 或同一 Vulkan 驱动程序的其他实例兼容的图像布局和布局转换？

已解决：在同一 GPU 上运行的同一 Vulkan 驱动程序的单独实例应具有相同的内部布局语义，因此应用程序具有所需的工具来确保两个实例之间的图像视图是一致的。其他 API 将分为两类：与 Vulkan 兼容的 API 和与 Vulkan 不兼容的 API。Vulkan 不兼容的 API 将需要在访问图像时始终处于 GENERAL 布局中。

请注意，这并不试图解决跨设备转换，也不解决同一设备上 Vulkan API 中不可见的引擎的转换。这两者都超出了此扩展的范围。

4) 是否需要某种类型的新屏障标志或操作来准备外部内存以移交给另一个 Vulkan 实例或 API，和/或从另一个实例或 API 接收它？

已解决：是的。在地址空间之间以及在可能在单独地址空间中操作的其他 API、实例或进程之间转换内存时，某些实现需要执行额外的缓存管理。定义此转换的选项包括

新的结构具有这样的优点：可以根据需要尽可能详细地描述外部转换的类型。然而，目前尚无已知需求需要区分外部访问和内部访问之外的任何内容，因此这可能是一种过度设计的解决方案。访问标志位具有以下优点：它可以应用于缓冲区、图像或全局粒度，并且在语义上与所描述的操作映射得很好。此外，API 已包含 VK_ACCESS_MEMORY_READ_BIT 和 VK_ACCESS_MEMORY_WRITE_BIT，它们似乎旨在用于此目的。但是，没有明显的管线阶段与外部访问相对应，因此没有明确的方法使用 VK_ACCESS_MEMORY_READ_BIT 或 VK_ACCESS_MEMORY_WRITE_BIT。VkDependencyFlags 和 VkPipelineStageFlags 在命令粒度上运行，而不是图像或缓冲区粒度，这将使整个管线屏障成为内部→外部或外部→内部屏障。这在实践中可能不是问题，但似乎范围不正确。VkDependencyFlags 的另一个缺点是它缺乏固有的方向性：在屏障或依赖性描述语义中没有它的 src 和 dst 变体，因此可能需要添加两位来描述内部→外部和外部→内部转换。将资源转换为特殊的队列族与转换到单独的 Vulkan 实例的操作相符，因为这两个操作理想情况下都包括在转换的两侧调度屏障：释放和获取队列或进程。使用特殊的队列族需要添加一个额外的保留队列族索引。重用 VK_QUEUE_FAMILY_IGNORED 会使如何将并发使用资源从一个进程转换到另一个进程变得不清楚，因为语义可能等同于当前忽略的 VK_QUEUE_FAMILY_IGNORED → VK_QUEUE_FAMILY_IGNORED 转换。幸运的是，创建新的保留队列族索引不会造成侵入性。

根据以上分析，选择了转换为特殊的“外部”队列族的方法。

5) 在跨进程或 API 共享图像时，是否需要导出和导入内部驱动程序内存安排和/或其他内部驱动程序图像属性。

已解决：一些供应商声称这在其实现中是必要的，但确定允许将不透明的元数据从应用程序传递到驱动程序的安全风险过高。因此，需要元数据的实现需要将其与外部句柄表示的对象关联起来，并依赖专用分配机制将导出和导入的内存对象与单个图像或缓冲区关联。

6) 大多数先前互操作和跨进程共享 API 都是基于图像级别的共享。Vulkan 共享是否应基于内存对象共享还是图像共享？

已解决：这些扩展假设内存级别的共享是正确的粒度。Vulkan 是一个比大多数先前 API 更底层的 API，因此它试图与它所抽象的硬件和系统级驱动程序的底层原语紧密对齐。一般来说，保存各种类型的图像和缓冲区的后备存储的资源是内存。图像和缓冲区仅仅是元数据，其中包含该内存中位布局的简要描述。

由于基于内存对象的共享与 Vulkan API 的整体设计相一致，因此它可以使用外部对象实现 Vulkan 的全部功能。例如，外部内存可以用作稀疏图像的后备，而对于基于高级原语（如图像）的共享机制来说，这种用法充其量是笨拙的。此外，以这种方式使机制与 API 对齐，可以希望与未来的 API 增强实现简单的兼容性。如果向 API 添加了由内存对象支持的新对象，它们也可以在进程之间使用，而无需对基本外部内存 API 进行最小的添加。

早期的 API 在更高级别实现了互操作，这需要为图像和缓冲区提供完全独立的共享 API。为了与这些 API 共存和互操作，Vulkan 外部共享机制必须适应它们的模型。但是，如果可以同意基于内存的共享是更理想和前瞻性的设计，则可以将遗留互操作约束视为支持基于内存的共享的另一个原因：虽然可能用于实现共享的本机和遗留驱动程序原语可能不像这里的 API 所暗示的那么底层，但原始内存仍然是这些类型中最不常见的公分母。基于图像的共享可以从一组基本的内存对象共享 API 中干净地派生出来，而基于图像的共享不能很好地推广到缓冲区或原始内存共享。因此，遵循 Vulkan 的最小化总体设计原则，最好通过内存共享 API 公开与基于图像的本机和外部原语的互操作性，并对其使用施加足够的限制，以确保它们只能用作等效 Vulkan 图像的后备。这为应用程序提供了统一的 API，无论它们针对哪个平台或外部 API，这使得多 API 和多平台应用程序的开发更加简单。

7) Vulkan 是否应定义一个通用的外部句柄类型并提供 Vulkan 函数以促进此类句柄的跨进程共享，而不是依赖本机句柄来定义外部对象？

已解决：否。资源的跨进程共享最好留给本机平台。此类机制存在无数的安全性和可扩展性问题，并且尝试在 Vulkan 中重新解决所有这些问题不符合 Vulkan 作为图形 API 的宗旨。如果需要，可以在此扩展系列中定义的不透明本机句柄之上构建这样的机制作为层或帮助程序库。

8) 对于可能导出的那些内存对象，实现是否必须提供有关内存对象中隐式包含的状态的其他保证？

已解决：实现必须确保共享内存对象不会在导出实例和导入实例和 API 之间传输任何信息，除了共享显式共享的内存对象中包含的数据所需的信息。作为具体示例，来自先前释放的内存对象（使用相同的底层物理内存）的数据，以及来自使用相邻物理内存的内存对象的数据，对于导入导出内存对象的应用程序来说必须不可见。

9) 实现是否必须验证应用程序作为内存导入操作的输入提供的外部句柄？

已解决：如果提供的内存句柄不能用于完成请求的导入操作，则实现必须向应用程序返回错误。但是，实现无需验证句柄是否与应用程序指定的类型完全一致。

版本历史记录

  • 版本 1，2016-10-20 (James Jones)

    • 初始版本

VK_KHR_external_memory_capabilities

名称字符串

VK_KHR_external_memory_capabilities

扩展类型

实例扩展

注册扩展号

72

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-10-17

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Ian Elliott, Google

  • Jesse Hall, Google

  • James Jones, NVIDIA

描述

应用程序可能希望在多个 Vulkan 逻辑设备或实例、多个进程和/或多个 API 中引用设备内存。此扩展提供了一组功能查询和句柄定义，允许应用程序确定给定用例的实现支持哪些类型的“外部”内存句柄。

晋升至 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新命令

新结构

新枚举

新位掩码

新枚举常量

  • VK_KHR_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME

  • VK_KHR_EXTERNAL_MEMORY_CAPABILITIES_SPEC_VERSION

  • VK_LUID_SIZE_KHR

  • 扩展 VkExternalMemoryFeatureFlagBits

    • VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_KHR

    • VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT_KHR

    • VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT_KHR

  • 扩展 VkExternalMemoryHandleTypeFlagBits

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT_KHR

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_KMT_BIT_KHR

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_HEAP_BIT_KHR

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT_KHR

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXTERNAL_BUFFER_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_EXTERNAL_IMAGE_FORMAT_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_BUFFER_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_IMAGE_FORMAT_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR

问题

1) 为什么需要在每个内存句柄类型的基础上查询如此多的外部内存功能？

提议的解决方案：这是因为某些句柄类型基于操作系统原生对象，其功能远比非常通用的 Vulkan 内存对象有限。例如，并非所有内存句柄类型都可以命名支持 3D 图像的内存对象。某些句柄类型甚至不支持 Vulkan 的延迟图像和内存绑定行为，并且需要在分配或导入内存对象时指定图像。

2) VkExternalImageFormatPropertiesKHR 和 VkExternalBufferPropertiesKHR 结构是否需要包含支持给定句柄类型的内存类型位列表？

提议的解决方案：不需要。当在图像或缓冲区创建时指定一组句柄类型时，不支持句柄类型的内存类型将简单地从 vkGetImageMemoryRequirements 和 vkGetBufferMemoryRequirements 返回的结果中过滤掉。

3) 是否应该将非不透明的句柄类型移动到它们自己的扩展中？

提议的解决方案：也许。但是，定义句柄类型位的作用很小，并且本身不需要任何平台特定的类型，而且现在在一个扩展中维护位域值更容易。据推测，可以通过单独的扩展添加更多句柄类型，并且将某些平台特定的句柄类型定义在核心规范中，而某些在扩展中会有点奇怪。

4) 我们是否需要 D3D11_TILEPOOL 类型？

提议的解决方案：不需要。这在技术上是可行的，但同步很麻烦。D3D11 surface 必须使用共享互斥锁进行同步，这些同步原语由整个内存对象共享，因此在多个缓冲区和图像绑定之间划分的 D3D11 共享分配可能难以同步。

5) 兼容 Windows 7 的句柄类型应该命名为 “KMT” 句柄还是 “GLOBAL_SHARE” 句柄？

提议的解决方案：KMT，仅仅是因为它更简洁。

6) 当共享内存时，应用程序如何在实例、进程和 API 边界之间识别兼容的设备和驱动程序？

提议的解决方案：公开新的设备属性，允许应用程序正确关联设备和驱动程序。添加一个设备和驱动程序 UUID，它们必须都匹配，以确保两个 Vulkan 实例或 Vulkan 实例与可扩展的外部 API 之间的共享兼容性。为了允许与 Direct3D 设备关联，添加了对应于 DXGI 适配器 LUID 的设备 LUID。Direct3D 不需要驱动程序 ID，因为 Windows 操作系统目前不支持不匹配的驱动程序组件版本。如果要在操作系统级别引入对此类配置的支持，则需要进一步的 Vulkan 扩展来关联用户空间组件构建。

版本历史

  • 修订版 1，2016-10-17（James Jones）

    • 初始版本

VK_KHR_external_semaphore

名称字符串

VK_KHR_external_semaphore

扩展类型

设备扩展

注册扩展号

78

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_external_semaphore_capabilities

弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-10-21

IP 状态

没有已知的 IP 声明。

贡献者

  • Faith Ekstrand, Intel

  • Jesse Hall, Google

  • Tobias Hector, Imagination Technologies

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Matthew Netsch，高通技术公司

  • Ray Smith, ARM

  • Lina Versace，谷歌

描述

使用外部内存的应用程序可能希望使用信号量同步对该内存的访问。此扩展允许应用程序创建信号量，从中可以导出引用底层同步原语的非 Vulkan 句柄。

升级到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构

新枚举

新位掩码

新枚举常量

  • VK_KHR_EXTERNAL_SEMAPHORE_EXTENSION_NAME

  • VK_KHR_EXTERNAL_SEMAPHORE_SPEC_VERSION

  • 扩展 VkSemaphoreImportFlagBits

    • VK_SEMAPHORE_IMPORT_TEMPORARY_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO_KHR

问题

1) 当等待处于无效状态的导入信号量时，应该对可能发生的副作用有什么限制？

已解决：是的。通常，验证这种状态将是应用程序的责任，如果违反了有效的使用规则，实现可以自由地进入未定义状态。但是，当使用导入的信号量时，这可能会导致安全问题，因为它需要导入应用程序信任导出应用程序以确保状态有效。对于许多潜在的用例，要求这种级别的信任是不希望的。

2) 实现是否必须验证应用程序作为信号量状态导入操作的输入提供的外部句柄？

已解决：如果提供的信号量状态句柄不能用于完成请求的导入操作，则实现必须向应用程序返回错误。但是，实现不需要验证句柄是否是应用程序指定的精确类型。

版本历史

  • 修订版 1，2016-10-21 (James Jones)

    • 初始修订版

VK_KHR_external_semaphore_capabilities

名称字符串

VK_KHR_external_semaphore_capabilities

扩展类型

实例扩展

注册扩展号

77

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-10-20

IP 状态

没有已知的 IP 声明。

贡献者

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

描述

应用程序可能希望在多个 Vulkan 逻辑设备或实例、多个进程和/或多个 API 中引用设备信号量。此扩展提供了一组功能查询和句柄定义，允许应用程序确定实现对于给定的一组用例支持哪些类型的“外部”信号量句柄。

晋升至 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_KHR_EXTERNAL_SEMAPHORE_CAPABILITIES_EXTENSION_NAME

  • VK_KHR_EXTERNAL_SEMAPHORE_CAPABILITIES_SPEC_VERSION

  • VK_LUID_SIZE_KHR

  • 扩展 VkExternalSemaphoreFeatureFlagBits

    • VK_EXTERNAL_SEMAPHORE_FEATURE_EXPORTABLE_BIT_KHR

    • VK_EXTERNAL_SEMAPHORE_FEATURE_IMPORTABLE_BIT_KHR

  • 扩展 VkExternalSemaphoreHandleTypeFlagBits

    • VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_D3D12_FENCE_BIT_KHR

    • VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT_KHR

    • VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR

    • VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR

    • VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXTERNAL_SEMAPHORE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_SEMAPHORE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR

版本历史

  • 版本 1，2016-10-20 (James Jones)

    • 初始修订版

VK_KHR_format_feature_flags2

名称字符串

VK_KHR_format_feature_flags2

扩展类型

设备扩展

注册扩展号

361

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

API 交互

  • 与 VK_VERSION_1_2 交互

  • 与 VK_EXT_filter_cubic 交互

  • 与 VK_EXT_sampler_filter_minmax 交互

  • 与 VK_IMG_filter_cubic 交互

弃用状态
联系方式

其他扩展元数据

上次修改日期

2021-07-01

IP 状态

没有已知的 IP 声明。

贡献者

  • Lionel Landwerlin, Intel

  • Faith Ekstrand, Intel

  • Tobias Hector, AMD

  • Spencer Fricke, Samsung Electronics

  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, ARM

描述

此扩展添加了一个新的 VkFormatFeatureFlagBits2KHR 64 位格式特征标志类型，以扩展现有的 VkFormatFeatureFlagBits，后者限制为 31 个标志。在撰写本文时，VkFormatFeatureFlagBits 的 29 位已经被使用。

因为 VkFormatProperties2 已经被定义为扩展 Vulkan 1.0 的 vkGetPhysicalDeviceFormatProperties 命令，此扩展定义了一个新的 VkFormatProperties3KHR 来扩展 VkFormatProperties。

除了复制 VkFormatFeatureFlagBits 中的所有位之外，VkFormatFeatureFlagBits2KHR 还添加了以下位：

  • VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHR 和 VK_FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHR 指定实现分别支持在不指定着色器中的格式的情况下通过存储操作读取和写入给定的 VkFormat。

  • VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_DEPTH_COMPARISON_BIT_KHR 指定实现支持在给定的 VkFormat 上由 OpImage*Dref* 指令执行的深度比较。之前，在图像视图上执行 OpImage*Dref* 指令的结果是未定义的，其中 format 不是具有深度分量的深度/模板格式之一。此位明确说明了可以在哪些格式上使用此类指令。

在此扩展的第 2 版之前，公开 shaderStorageImageReadWithoutFormat 和 shaderStorageImageWriteWithoutFormat 功能的实现可能不会在 VkFormatProperties3KHR::bufferFeatures 中报告 VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHR 和 VK_FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHR。尽管如此，缓冲区读取/写入仍然按照原始功能的要求得到支持。

新结构体

新枚举

新位掩码

新枚举常量

  • VK_KHR_FORMAT_FEATURE_FLAGS_2_EXTENSION_NAME

  • VK_KHR_FORMAT_FEATURE_FLAGS_2_SPEC_VERSION

  • 扩展 VkFormatFeatureFlagBits2

    • VK_FORMAT_FEATURE_2_BLIT_DST_BIT_KHR

    • VK_FORMAT_FEATURE_2_BLIT_SRC_BIT_KHR

    • VK_FORMAT_FEATURE_2_COLOR_ATTACHMENT_BIT_KHR

    • VK_FORMAT_FEATURE_2_COLOR_ATTACHMENT_BLEND_BIT_KHR

    • VK_FORMAT_FEATURE_2_COSITED_CHROMA_SAMPLES_BIT_KHR

    • VK_FORMAT_FEATURE_2_DEPTH_STENCIL_ATTACHMENT_BIT_KHR

    • VK_FORMAT_FEATURE_2_DISJOINT_BIT_KHR

    • VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT_KHR

    • VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_BIT_KHR

    • VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_DEPTH_COMPARISON_BIT_KHR

    • VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_LINEAR_BIT_KHR

    • VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT_KHR

    • VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT_KHR

    • VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT_KHR

    • VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT_KHR

    • VK_FORMAT_FEATURE_2_STORAGE_IMAGE_ATOMIC_BIT_KHR

    • VK_FORMAT_FEATURE_2_STORAGE_IMAGE_BIT_KHR

    • VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHR

    • VK_FORMAT_FEATURE_2_STORAGE_TEXEL_BUFFER_ATOMIC_BIT_KHR

    • VK_FORMAT_FEATURE_2_STORAGE_TEXEL_BUFFER_BIT_KHR

    • VK_FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHR

    • VK_FORMAT_FEATURE_2_TRANSFER_DST_BIT_KHR

    • VK_FORMAT_FEATURE_2_TRANSFER_SRC_BIT_KHR

    • VK_FORMAT_FEATURE_2_UNIFORM_TEXEL_BUFFER_BIT_KHR

    • VK_FORMAT_FEATURE_2_VERTEX_BUFFER_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_3_KHR

如果支持 VK_EXT_filter_cubic 或 VK_IMG_filter_cubic

如果支持 Vulkan 版本 1.2 或 VK_EXT_sampler_filter_minmax

晋升至 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 KHR 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍可用作核心功能的别名。

版本历史

  • 修订版 2，2022-07-20 (Lionel Landwerlin)

    • 澄清 VK_FORMAT_FEATURE_2_STORAGE_(READ|WRITE)_WITHOUT_FORMAT_BIT 也适用于缓冲区视图。

  • 修订版 1，2020-07-21 (Lionel Landwerlin)

    • 初始草案

VK_KHR_get_memory_requirements2

名称字符串

VK_KHR_get_memory_requirements2

扩展类型

设备扩展

注册扩展号

147

修订

1

批准状态

已批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-09-05

IP 状态

没有已知的 IP 声明。

贡献者

  • Faith Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Jesse Hall, Google

描述

此扩展为图像和缓冲区的内存需求提供了新的查询方式，可以很容易地被其他扩展所扩展，而无需引入任何额外的命令。Vulkan 1.0 的 VkMemoryRequirements 和 VkSparseImageMemoryRequirements 结构体不包含 sType 和 pNext 成员。此扩展将它们封装在具有这些成员的新结构体中，因此应用程序可以通过构建链并让实现填充它们来查询内存需求结构体的链。对于 Vulkan 1.0 核心中的每个 vkGet*MemoryRequrements 命令，都会添加一个新命令。

晋升到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新命令

新结构体

新枚举常量

  • VK_KHR_GET_MEMORY_REQUIREMENTS_2_EXTENSION_NAME

  • VK_KHR_GET_MEMORY_REQUIREMENTS_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BUFFER_MEMORY_REQUIREMENTS_INFO_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_MEMORY_REQUIREMENTS_INFO_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_SPARSE_MEMORY_REQUIREMENTS_INFO_2_KHR

    • VK_STRUCTURE_TYPE_MEMORY_REQUIREMENTS_2_KHR

    • VK_STRUCTURE_TYPE_SPARSE_IMAGE_MEMORY_REQUIREMENTS_2_KHR

版本历史

  • 修订版 1，2017-03-23 (Faith Ekstrand)

    • 内部修订

VK_KHR_get_physical_device_properties2

名称字符串

VK_KHR_get_physical_device_properties2

扩展类型

实例扩展

注册扩展号

60

修订

2

批准状态

已批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-09-05

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

  • Ian Elliott, Google

描述

此扩展为设备特性、设备属性和格式属性提供了新的查询方式，可以很容易地被其他扩展所扩展，而无需引入任何进一步的查询。Vulkan 1.0 的特性/限制/格式属性结构体不包含 sType/pNext 成员。此扩展将它们封装在具有 sType/pNext 成员的新结构体中，因此应用程序可以通过构建链并让实现填充它们来查询特性/限制/格式属性结构体的链。对于 Vulkan 1.0 核心中的每个 vkGetPhysicalDevice* 命令，都会添加一个新命令。新的特性结构体（以及扩展结构体的 pNext 链）也可以传递到设备创建中以启用特性。

此扩展还允许应用程序在调用 vkCreateDevice 之前使用设备扩展的物理设备组件。

晋升到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新命令

新结构体

新枚举常量

  • VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_EXTENSION_NAME

  • VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SPARSE_IMAGE_FORMAT_INFO_2_KHR

    • VK_STRUCTURE_TYPE_QUEUE_FAMILY_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_SPARSE_IMAGE_FORMAT_PROPERTIES_2_KHR

示例

    // Get features with a hypothetical future extension.
    VkHypotheticalExtensionFeaturesKHR hypotheticalFeatures =
    {
        .sType = VK_STRUCTURE_TYPE_HYPOTHETICAL_FEATURES_KHR,
        .pNext = NULL,
    };

    VkPhysicalDeviceFeatures2KHR features =
    {
        .sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR,
        .pNext = &hypotheticalFeatures,
    };

    // After this call, features and hypotheticalFeatures have been filled out.
    vkGetPhysicalDeviceFeatures2KHR(physicalDevice, &features);

    // Properties/limits can be chained and queried similarly.

    // Enable some features:
    VkHypotheticalExtensionFeaturesKHR enabledHypotheticalFeatures =
    {
        .sType = VK_STRUCTURE_TYPE_HYPOTHETICAL_FEATURES_KHR,
        .pNext = NULL,
    };

    VkPhysicalDeviceFeatures2KHR enabledFeatures =
    {
        .sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR,
        .pNext = &enabledHypotheticalFeatures,
    };

    enabledFeatures.features.xyz = VK_TRUE;
    enabledHypotheticalFeatures.abc = VK_TRUE;

    VkDeviceCreateInfo deviceCreateInfo =
    {
        .sType = VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,
        .pNext = &enabledFeatures,
        ...
        .pEnabledFeatures = NULL,
    };

    VkDevice device;
    vkCreateDevice(physicalDevice, &deviceCreateInfo, NULL, &device);

版本历史

  • 修订版 1，2016-09-12 (Jeff Bolz)

    • 内部修订

  • 修订版 2，2016-11-02 (Ian Elliott)

    • 增加了应用程序在调用 vkCreateDevice 之前使用设备扩展的物理设备组件的能力。

VK_KHR_global_priority

名称字符串

VK_KHR_global_priority

扩展类型

设备扩展

注册扩展号

189

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2021-10-22

贡献者

描述

在 Vulkan 中，用户可以指定设备范围的队列优先级。在某些情况下，将此概念扩展到系统范围可能很有用。此设备扩展允许应用程序查询队列族支持的全局队列优先级，然后在创建队列时设置优先级。默认队列优先级为 VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT。

实现可以报告哪些全局优先级级别被实现以不同方式对待。它主要用于系统集成以及某些特定于平台的优先级强制规则。

驱动程序实现将尝试偏向硬件资源分配以支持更高优先级的任务。因此，即使系统拥塞了较低优先级的工作，更高优先级的工作也可能保持相似的延迟和吞吐量特性。

队列的全局优先级应优先于每个进程的队列优先级（VkDeviceQueueCreateInfo::pQueuePriorities）。

滥用此特性可能会导致系统中其余部分缺乏硬件资源。因此，如果调用者没有足够的权限，驱动程序实现可能会拒绝获取高于默认优先级（VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT）的优先级请求。在这种情况下，会返回 VK_ERROR_NOT_PERMITTED_EXT。

如果完成操作所需的资源已耗尽（由同一进程或不同进程），驱动程序实现可能会使队列分配请求失败。在这种情况下，会返回 VK_ERROR_INITIALIZATION_FAILED。

新结构体

新枚举

新枚举常量

  • VK_KHR_GLOBAL_PRIORITY_EXTENSION_NAME

  • VK_KHR_GLOBAL_PRIORITY_SPEC_VERSION

  • VK_MAX_GLOBAL_PRIORITY_SIZE_KHR

  • 扩展 VkQueueGlobalPriority

    • VK_QUEUE_GLOBAL_PRIORITY_HIGH_KHR

    • VK_QUEUE_GLOBAL_PRIORITY_LOW_KHR

    • VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_KHR

    • VK_QUEUE_GLOBAL_PRIORITY_REALTIME_KHR

  • 扩展 VkResult

    • VK_ERROR_NOT_PERMITTED_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_QUEUE_GLOBAL_PRIORITY_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GLOBAL_PRIORITY_QUERY_FEATURES_KHR

    • VK_STRUCTURE_TYPE_QUEUE_FAMILY_GLOBAL_PRIORITY_PROPERTIES_KHR

晋升到 Vulkan 1.4

此扩展中的功能已包含在 Vulkan 1.4 核心版本中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

问题

1) 我们是否可以在此扩展中额外查询调用者是否被允许获取特定的全局队列优先级？

已解决：否。调用者是否具有足够的权限取决于操作系统，Vulkan 驱动程序无法真正保证该权限在本次查询和实际队列创建调用之间不会发生变化。

2) 如果请求使用全局优先级的多个队列，是否有好的方法来知道哪个队列在设备创建时失败？

已解决：否。目前没有好的方法，并且对于应用程序来说，知道这一点也不是很有用，因为该信息可能不准确。队列创建可能会因运行时约束（如权限不足或资源不足）而失败，并且失败不一定与请求的特定队列配置相关。

版本历史

  • 修订版 1，2021-10-22 (Tobias Hector)

    • 初始草案

VK_KHR_image_format_list

名称字符串

VK_KHR_image_format_list

扩展类型

设备扩展

注册扩展号

148

修订

1

批准状态

已批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-03-20

IP 状态

没有已知的 IP 声明。

贡献者

  • Faith Ekstrand, Intel

  • Jan-Harald Fredriksen, ARM

  • Jeff Bolz, NVIDIA

  • Jeff Leger, Qualcomm

  • Neil Henning, Codeplay

描述

在某些实现中，在图像创建时设置 VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT 可能会导致对该图像的访问性能比未设置 VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT 的等效图像更差，因为实现不知道哪些视图格式将与该图像配对。

此扩展允许应用程序在创建图像时提供所有可以与该图像一起使用的格式列表。然后，实现可能能够创建一个更高效的图像，该图像支持应用程序所需的格式子集，而不必支持图像格式的格式兼容性类中的所有格式。

升级到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构体

新枚举常量

  • VK_KHR_IMAGE_FORMAT_LIST_EXTENSION_NAME

  • VK_KHR_IMAGE_FORMAT_LIST_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMAGE_FORMAT_LIST_CREATE_INFO_KHR

版本历史

  • 修订版 1，2017-03-20 (Faith Ekstrand)

    • 初始修订版

VK_KHR_imageless_framebuffer

名称字符串

VK_KHR_imageless_framebuffer

扩展类型

设备扩展

注册扩展号

109

修订

1

批准状态

已批准

扩展和版本依赖关系

             VK_KHR_get_physical_device_properties2
             和
             VK_KHR_maintenance2
         或
         Vulkan 版本 1.1
     和
     VK_KHR_image_format_list
或
Vulkan 版本 1.2

弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-12-14

贡献者

  • Tobias Hector

  • Graham Wihlidal

描述

此扩展允许创建帧缓冲区，而无需先创建图像，从而在使用方式上具有更大的灵活性，并避免了许多令人困惑的兼容性规则。

现在，使用关于 VkFramebufferAttachmentsCreateInfoKHR 中将使用的图像视图的少量附加元数据创建帧缓冲区，并且实际的图像视图在渲染过程开始时通过 VkRenderPassAttachmentBeginInfoKHR 提供。

升级到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构体

新枚举常量

  • VK_KHR_IMAGELESS_FRAMEBUFFER_EXTENSION_NAME

  • VK_KHR_IMAGELESS_FRAMEBUFFER_SPEC_VERSION

  • 扩展 VkFramebufferCreateFlagBits

    • VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_FRAMEBUFFER_ATTACHMENTS_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_FRAMEBUFFER_ATTACHMENT_IMAGE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGELESS_FRAMEBUFFER_FEATURES_KHR

    • VK_STRUCTURE_TYPE_RENDER_PASS_ATTACHMENT_BEGIN_INFO_KHR

版本历史

  • 修订版 1，2018-12-14 (Tobias Hector)

    • 内部修订

VK_KHR_index_type_uint8

名称字符串

VK_KHR_index_type_uint8

扩展类型

设备扩展

注册扩展号

534

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2023-06-06

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展允许将 uint8_t 索引与 vkCmdBindIndexBuffer 一起使用。

新结构体

新枚举常量

  • VK_KHR_INDEX_TYPE_UINT8_EXTENSION_NAME

  • VK_KHR_INDEX_TYPE_UINT8_SPEC_VERSION

  • 扩展 VkIndexType

    • VK_INDEX_TYPE_UINT8_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INDEX_TYPE_UINT8_FEATURES_KHR

升级到 Vulkan 1.4

此扩展中的功能已包含在 Vulkan 1.4 核心版本中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1，2023-06-06 (Piers Daniell)

    • 内部修订

VK_KHR_line_rasterization

名称字符串

VK_KHR_line_rasterization

扩展类型

设备扩展

注册扩展号

535

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2023-06-08

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

  • Allen Jensen，NVIDIA

  • Faith Ekstrand, Intel

描述

此扩展添加了一些在 CAD 应用程序中常用并在其他 API（如 OpenGL）中支持的线光栅化功能。支持 Bresenham 风格的线光栅化，支持平滑的矩形线（覆盖到 alpha），并且对于所有三种线光栅化模式都支持虚线。

新命令

新结构体

新枚举

新枚举常量

  • VK_KHR_LINE_RASTERIZATION_EXTENSION_NAME

  • VK_KHR_LINE_RASTERIZATION_SPEC_VERSION

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_LINE_STIPPLE_KHR

  • 扩展 VkLineRasterizationMode

    • VK_LINE_RASTERIZATION_MODE_BRESENHAM_KHR

    • VK_LINE_RASTERIZATION_MODE_DEFAULT_KHR

    • VK_LINE_RASTERIZATION_MODE_RECTANGULAR_KHR

    • VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINE_RASTERIZATION_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINE_RASTERIZATION_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_LINE_STATE_CREATE_INFO_KHR

升级到 Vulkan 1.4

此扩展中的功能已包含在 Vulkan 1.4 核心版本中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

当支持 1.4 版本时，必须支持 bresenhamLines 功能。

问题

1) 我们是否需要支持具有多个光栅化采样的 Bresenham 风格和平滑线？即，当帧缓冲区具有多个采样时，相当于 OpenGL 中的 glDisable(GL_MULTISAMPLE)？

已解决：是的。为了简单起见，Bresenham 直线光栅化沿用了 OpenGL 的一些限制，例如不支持逐采样着色、alpha 到覆盖或 alpha 到一。

版本历史

  • 修订版 1，2019-05-09 (Jeff Bolz)

    • 初始草案

VK_KHR_load_store_op_none

名称字符串

VK_KHR_load_store_op_none

扩展类型

设备扩展

注册扩展号

527

修订

1

批准状态

已批准

扩展和版本依赖关系

无

弃用状态
联系方式
扩展提案

VK_KHR_load_store_op_none

其他扩展元数据

上次修改日期

2023-05-16

贡献者

  • Shahbaz Youssefi, Google

  • Bill Licea-Kane，高通技术公司。

  • Tobias Hector, AMD

描述

此扩展提供了 VK_ATTACHMENT_LOAD_OP_NONE_KHR 和 VK_ATTACHMENT_STORE_OP_NONE_KHR，它们与从 VK_EXT_load_store_op_none 扩展中提升而来完全相同。

新的枚举常量

  • VK_KHR_LOAD_STORE_OP_NONE_EXTENSION_NAME

  • VK_KHR_LOAD_STORE_OP_NONE_SPEC_VERSION

  • 扩展 VkAttachmentLoadOp

    • VK_ATTACHMENT_LOAD_OP_NONE_KHR

  • 扩展 VkAttachmentStoreOp

    • VK_ATTACHMENT_STORE_OP_NONE_KHR

升级到 Vulkan 1.4

此扩展中的功能已包含在 Vulkan 1.4 核心版本中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

虽然 VK_ATTACHMENT_STORE_OP_NONE 是 Vulkan 1.3 的一部分，但此扩展并未整体或部分升级到核心 Vulkan 1.3。此功能是从 VK_KHR_dynamic_rendering 升级而来。

版本历史

  • 修订版 1，2023-05-16 (Shahbaz Youssefi)

    • 基于 VK_EXT_load_store_op_none 的初始修订版。

VK_KHR_maintenance1

名称字符串

VK_KHR_maintenance1

扩展类型

设备扩展

注册扩展号

70

修订

2

批准状态

已批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-03-13

贡献者

  • Dan Ginsburg, Valve

  • Daniel Koch, NVIDIA

  • Daniel Rakos, AMD

  • Jan-Harald Fredriksen, ARM

  • Faith Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Jesse Hall, Google

  • John Kessenich，Google

  • Michael Worcester, Imagination Technologies

  • Neil Henning, Codeplay Software Ltd.

  • Piers Daniell, NVIDIA

  • Slawomir Grajewski, Intel

  • Tobias Hector, Imagination Technologies

  • Tom Olson, ARM

描述

VK_KHR_maintenance1 添加了一组次要功能，这些功能在最初的 Vulkan 1.0 版本中被有意省略或忽略。

新功能如下

  • 允许从 3D 图像创建 2D 和 2D 数组图像视图，然后可用作颜色帧缓冲附件。这允许应用程序渲染到 3D 图像的切片。

  • 支持在 2D 数组图层和 3D 切片之间进行 vkCmdCopyImage。此扩展允许从 2D 数组图像的图层复制到 3D 图像的切片，反之亦然。

  • 允许在 VkViewport::height 字段中指定负高度，以执行剪辑空间到帧缓冲空间变换的 y 轴反转。这允许应用程序避免在也面向其他 API 的着色器中使用 gl_Position.y = -gl_Position.y。

  • 允许实现表达对仅进行图像格式的传输和清除的支持，否则它们不支持其他格式功能。这是通过添加新的格式功能标志 VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR 和 VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR 来完成的。

  • 支持在仅传输队列上使用 vkCmdFillBuffer。以前，vkCmdFillBuffer 被定义为仅在从支持图形或计算队列的命令池分配的命令缓冲区上工作。现在允许在仅支持传输操作的队列上使用它。

  • 修复了 vkCreateGraphicsPipelines 和 vkCreateComputePipelines 函数与 vkAllocateDescriptorSets 和 vkAllocateCommandBuffers 函数之间返回错误条件的方式的不一致性。

  • 添加新的 VK_ERROR_OUT_OF_POOL_MEMORY_KHR 错误，以便实现可以为 vkAllocateDescriptorSets 失败提供更精确的原因。

  • 添加一个新命令 vkTrimCommandPoolKHR，这使实现有机会将任何未使用的命令池内存释放回系统。

升级到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新命令

新位掩码

新的枚举常量

  • VK_KHR_MAINTENANCE1_EXTENSION_NAME

  • VK_KHR_MAINTENANCE1_SPEC_VERSION

  • VK_KHR_MAINTENANCE_1_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_1_SPEC_VERSION

  • 扩展 VkFormatFeatureFlagBits

    • VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

    • VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR

  • 扩展 VkImageCreateFlagBits

    • VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT_KHR

  • 扩展 VkResult

    • VK_ERROR_OUT_OF_POOL_MEMORY_KHR

问题

  1. 是否允许高度为零的视口？

    已解决：是的，尽管它们的实用性较低。

版本历史

  • 修订版 1，2016-10-26 (Piers Daniell)

    • 内部修订

  • 修订版 2，2018-03-13 (Jon Leech)

    • 添加有关零高度视口的问题

VK_KHR_maintenance2

名称字符串

VK_KHR_maintenance2

扩展类型

设备扩展

注册扩展号

118

修订

1

批准状态

已批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-09-05

贡献者

  • Michael Worcester, Imagination Technologies

  • Stuart Smith, Imagination Technologies

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

  • Jan-Harald Fredriksen, ARM

  • Daniel Rakos, AMD

  • Neil Henning, Codeplay

  • Piers Daniell, NVIDIA

描述

VK_KHR_maintenance2 添加了一组次要功能，这些功能在最初的 Vulkan 1.0 版本中被有意省略或忽略。

新功能如下

  • 允许应用程序指定给定子通道可能读取输入附件的哪个方面。

  • 允许实现表达点的剪切行为。

  • 允许创建具有基本图像格式可能不支持，但图像视图具有不同但兼容的格式时支持的用法标志的图像。

  • 允许创建压缩图像的未压缩图像视图。

  • 允许应用程序为细分域空间选择左上角或左下角原点。

  • 为深度模板图像添加了两个新的图像布局，以允许深度或模板方面为只读，而另一个方面为可写。

输入附件规范

输入附件规范允许应用程序指定将通过 subpassLoad 操作访问的多方面图像（例如，深度/模板格式）的哪个方面。

在某些实现中，如果实现不知道（在 vkCreateRenderPass 时）哪些多方面图像的方面可以作为输入附件访问，则可能会产生性能损失。

升级到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构体

新枚举

新的枚举常量

  • VK_KHR_MAINTENANCE2_EXTENSION_NAME

  • VK_KHR_MAINTENANCE2_SPEC_VERSION

  • VK_KHR_MAINTENANCE_2_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_2_SPEC_VERSION

  • 扩展 VkImageCreateFlagBits

    • VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT_KHR

    • VK_IMAGE_CREATE_EXTENDED_USAGE_BIT_KHR

  • 扩展 VkImageLayout

    • VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL_KHR

    • VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL_KHR

  • 扩展 VkPointClippingBehavior

    • VK_POINT_CLIPPING_BEHAVIOR_ALL_CLIP_PLANES_KHR

    • VK_POINT_CLIPPING_BEHAVIOR_USER_CLIP_PLANES_ONLY_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_USAGE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_POINT_CLIPPING_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_TESSELLATION_DOMAIN_ORIGIN_STATE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_RENDER_PASS_INPUT_ATTACHMENT_ASPECT_CREATE_INFO_KHR

  • 扩展 VkTessellationDomainOrigin

    • VK_TESSELLATION_DOMAIN_ORIGIN_LOWER_LEFT_KHR

    • VK_TESSELLATION_DOMAIN_ORIGIN_UPPER_LEFT_KHR

输入附件规范示例

考虑一个渲染通道有两个子通道和两个附件的情况。

附件 0 的格式为 VK_FORMAT_D24_UNORM_S8_UINT，附件 1 有某种颜色格式。

子通道 0 写入附件 0，子通道 1 仅从附件 0 读取深度信息（使用 inputAttachmentRead）并写入附件 1。

    VkInputAttachmentAspectReferenceKHR references[] = {
        {
            .subpass = 1,
            .inputAttachmentIndex = 0,
            .aspectMask = VK_IMAGE_ASPECT_DEPTH_BIT
        }
    };

    VkRenderPassInputAttachmentAspectCreateInfoKHR specifyAspects = {
        .sType = VK_STRUCTURE_TYPE_RENDER_PASS_INPUT_ATTACHMENT_ASPECT_CREATE_INFO_KHR,
        .pNext = NULL,
        .aspectReferenceCount = 1,
        .pAspectReferences = references
    };


    VkRenderPassCreateInfo createInfo = {
        ...
        .pNext = &specifyAspects,
        ...
    };

    vkCreateRenderPass(...);

问题

1) 默认的细分域原点是什么？

已解决：Vulkan 1.0 最初无意中记录了左下原点，但一致性测试和所有实现都实现了左上原点。此扩展添加了一个控件来选择左下（与 OpenGL 兼容）和左上，并且我们追溯修复了未扩展的 Vulkan 以使其默认值为左上原点。

版本历史

  • 修订版 1，2017-04-28

VK_KHR_maintenance3

名称字符串

VK_KHR_maintenance3

扩展类型

设备扩展

注册扩展号

169

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-09-05

贡献者

  • Jeff Bolz, NVIDIA

描述

VK_KHR_maintenance3 添加了一系列小的功能，这些功能是最初的 Vulkan 1.0 版本中有意遗漏或忽略的。

新功能如下

  • 对单个描述符集布局中支持的最大描述符数量的限制。某些实现对一个集合中的描述符总大小有限制，这无法用 Vulkan 1.0 中的限制来表示。

  • 对单个内存分配的最大大小的限制。某些平台具有限制最大分配大小的内核接口。

升级到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新命令

新结构体

新枚举常量

  • VK_KHR_MAINTENANCE3_EXTENSION_NAME

  • VK_KHR_MAINTENANCE3_SPEC_VERSION

  • VK_KHR_MAINTENANCE_3_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_3_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_SUPPORT_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_3_PROPERTIES_KHR

版本历史

  • 修订版 1，2017-08-22

VK_KHR_maintenance4

名称字符串

VK_KHR_maintenance4

扩展类型

设备扩展

注册扩展号

414

修订

2

批准状态

已批准

扩展和版本依赖关系

Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2021-10-25

交互和外部依赖

  • 需要 SPIR-V 1.2 用于 LocalSizeId

贡献者

  • Lionel Duc, NVIDIA

  • Faith Ekstrand, Intel

  • Spencer Fricke, Samsung

  • Tobias Hector, AMD

  • Lionel Landwerlin, Intel

  • Graeme Leese, Broadcom

  • Tom Olson, Arm

  • Stu Smith, AMD

  • Yiwei Zhang, Google

描述

VK_KHR_maintenance4 添加了一系列小的功能，这些功能都不足以单独成为一个扩展。

新功能如下

  • 允许应用程序在其用于创建另一个对象后立即销毁 VkPipelineLayout 对象。当创建的对象正在使用时，不再需要保持其句柄有效。

  • 为可以创建的最大大小的 VkBuffer 添加一个新的 maxBufferSize 实现定义限制。

  • 添加对 SPIR-V 1.2 LocalSizeId 执行模式的支持，该模式可以用作 LocalSize 的替代方案，以使用特化常量指定本地工作组大小。

  • 添加保证，以相同创建参数创建的图像将始终具有相同的对齐要求。

  • 添加新的 vkGetDeviceBufferMemoryRequirementsKHR、vkGetDeviceImageMemoryRequirementsKHR 和 vkGetDeviceImageSparseMemoryRequirementsKHR，以允许应用程序在无需创建图像对象并查询它的情况下查询图像内存要求。

  • 放宽了在动态访问之前必须初始化推送常量的要求。

  • 放宽接口匹配规则，以允许更大的输出向量与更小的输入向量匹配，并丢弃其他值。

  • 添加对缓冲区内存要求的保证，即大小内存要求永远不会大于将创建大小与对齐内存要求对齐的结果。

新命令

新结构体

新枚举常量

  • VK_KHR_MAINTENANCE_4_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_4_SPEC_VERSION

  • 扩展 VkImageAspectFlagBits

    • VK_IMAGE_ASPECT_NONE_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_BUFFER_MEMORY_REQUIREMENTS_KHR

    • VK_STRUCTURE_TYPE_DEVICE_IMAGE_MEMORY_REQUIREMENTS_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_4_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_4_PROPERTIES_KHR

升级到 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 KHR 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍可用作核心功能的别名。

问题

无。

版本历史

  • 修订版 1，2021-08-18 (Piers Daniell)

    • 内部修订

  • 修订版 2，2021-10-25 (Yiwei Zhang)

    • 更多关于缓冲区内存要求的保证

VK_KHR_maintenance5

名称字符串

VK_KHR_maintenance5

扩展类型

设备扩展

注册扩展号

471

修订

1

批准状态

已批准

扩展和版本依赖关系

     Vulkan 版本 1.1
     和
     VK_KHR_dynamic_rendering
或
Vulkan 版本 1.3

API 交互

  • 与 VK_VERSION_1_2 交互

  • 与 VK_VERSION_1_3 交互

  • 与 VK_VERSION_1_4 交互

  • 与 VK_ARM_pipeline_opacity_micromap 交互

  • 与 VK_EXT_attachment_feedback_loop_layout 交互

  • 与 VK_EXT_buffer_device_address 交互

  • 与 VK_EXT_conditional_rendering 交互

  • 与 VK_EXT_descriptor_buffer 交互

  • 与 VK_EXT_fragment_density_map 交互

  • 与 VK_EXT_graphics_pipeline_library 交互

  • 与 VK_EXT_opacity_micromap 交互

  • 与 VK_EXT_pipeline_creation_cache_control 交互

  • 与 VK_EXT_pipeline_protected_access 交互

  • 与 VK_EXT_transform_feedback 交互

  • 与 VK_KHR_acceleration_structure 交互

  • 与 VK_KHR_buffer_device_address 交互

  • 与 VK_KHR_dynamic_rendering 交互

  • 与 VK_KHR_fragment_shading_rate 交互

  • 与 VK_KHR_pipeline_executable_properties 交互

  • 与 VK_KHR_pipeline_library 交互

  • 与 VK_KHR_ray_tracing_pipeline 交互

  • 与 VK_KHR_video_decode_queue 交互

  • 与 VK_KHR_video_encode_queue 交互

  • 与 VK_NV_device_generated_commands 交互

  • 与 VK_NV_displacement_micromap 交互

  • 与 VK_NV_ray_tracing 交互

  • 与 VK_NV_ray_tracing_motion_blur 交互

弃用状态
联系方式
扩展提案

VK_KHR_maintenance5

其他扩展元数据

上次修改日期

2023-05-02

交互和外部依赖
贡献者

  • Stu Smith, AMD

  • Tobias Hector, AMD

  • Shahbaz Youssefi, Google

  • Slawomir Cygan，英特尔

  • Lionel Landwerlin, Intel

  • James Fitzpatrick, Imagination Technologies

  • Andrew Garrard，Imagination Technologies

  • Ralph Potter, Samsung

  • Pan Gao, Huawei

  • Jan-Harald Fredriksen, ARM

  • Jon Leech, Khronos

  • Mike Blumenkrantz, Valve

描述

VK_KHR_maintenance5 添加了一系列小功能，这些功能都不足以单独成为一个扩展。

新功能如下

  • 一个新的 VK_FORMAT_A1B5G5R5_UNORM_PACK16_KHR 格式

  • 一个新的 VK_FORMAT_A8_UNORM_KHR 格式

  • 一个属性，用于指示在 EarlyFragmentTests 模式下，多重采样覆盖操作是在样本计数之后执行的

  • 通过使用 VkBufferUsageFlags2CreateInfoKHR 允许使用关联的 VkBuffer 用法的子集来放宽 VkBufferView 创建要求

  • 一个新的命令 vkCmdBindIndexBuffer2KHR，允许将一段内存绑定为索引缓冲区

  • vkGetDeviceProcAddr 对于应用程序请求的版本之外的支持的核心函数必须返回 NULL。

  • 一个属性，用于指示在 EarlyFragmentTests 模式下，样本掩码测试是在样本计数之后执行的

  • vkCmdBindVertexBuffers2 现在支持在 pSizes 参数中使用 VK_WHOLE_SIZE。

  • 如果未写入 PointSize，则使用默认大小 1.0

  • 着色器模块已弃用 - 应用程序现在可以通过 VkPipelineShaderStageCreateInfo 将 VkShaderModuleCreateInfo 作为链式结构传递给管线创建

  • 一个函数 vkGetRenderingAreaGranularityKHR，用于查询动态渲染实例的最佳渲染区域。

  • 一个属性，用于指示使用 VK_COMPONENT_SWIZZLE_ONE 进行深度/模板纹理操作时具有定义的行为

  • 添加 vkGetImageSubresourceLayout2KHR 和一个新的函数 vkGetDeviceImageSubresourceLayoutKHR，允许应用程序查询图像内存布局，而无需创建图像对象并查询它。

  • 允许将 VK_REMAINING_ARRAY_LAYERS 作为 VkImageSubresourceLayers 的 layerCount 成员

  • 为 VK_ERROR_DEVICE_LOST 返回值的传播添加更强的保证

  • 一个属性，用于指示如果 多边形模式 为 VK_POLYGON_MODE_POINT 时，PointSize 是否控制多边形的最终光栅化

  • 两个属性，用于指示所使用的非严格线条光栅化算法

  • 两个新的标志字 VkPipelineCreateFlagBits2KHR 和 VkBufferUsageFlagBits2KHR

  • 物理设备级别的函数现在可以使用类型有效范围内的任何值（超出定义的枚举量）调用，这样应用程序就可以避免在查询特定枚举量的支持属性之前检查单个特性、扩展或版本。

  • 澄清允许任何类型的图像之间的复制，将 1D 图像视为高度为 1 的 2D 图像。

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_KHR_MAINTENANCE_5_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_5_SPEC_VERSION

  • 扩展 VkBufferUsageFlagBits2

    • VK_BUFFER_USAGE_2_INDEX_BUFFER_BIT_KHR

    • VK_BUFFER_USAGE_2_INDIRECT_BUFFER_BIT_KHR

    • VK_BUFFER_USAGE_2_STORAGE_BUFFER_BIT_KHR

    • VK_BUFFER_USAGE_2_STORAGE_TEXEL_BUFFER_BIT_KHR

    • VK_BUFFER_USAGE_2_TRANSFER_DST_BIT_KHR

    • VK_BUFFER_USAGE_2_TRANSFER_SRC_BIT_KHR

    • VK_BUFFER_USAGE_2_UNIFORM_BUFFER_BIT_KHR

    • VK_BUFFER_USAGE_2_UNIFORM_TEXEL_BUFFER_BIT_KHR

    • VK_BUFFER_USAGE_2_VERTEX_BUFFER_BIT_KHR

  • 扩展 VkFormat

    • VK_FORMAT_A1B5G5R5_UNORM_PACK16_KHR

    • VK_FORMAT_A8_UNORM_KHR

  • 扩展 VkPipelineCreateFlagBits2

    • VK_PIPELINE_CREATE_2_ALLOW_DERIVATIVES_BIT_KHR

    • VK_PIPELINE_CREATE_2_DERIVATIVE_BIT_KHR

    • VK_PIPELINE_CREATE_2_DISABLE_OPTIMIZATION_BIT_KHR

    • VK_PIPELINE_CREATE_2_DISPATCH_BASE_BIT_KHR

    • VK_PIPELINE_CREATE_2_VIEW_INDEX_FROM_DEVICE_INDEX_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BUFFER_USAGE_FLAGS_2_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_IMAGE_SUBRESOURCE_INFO_KHR

    • VK_STRUCTURE_TYPE_IMAGE_SUBRESOURCE_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_5_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_5_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_CREATE_FLAGS_2_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_RENDERING_AREA_INFO_KHR

    • VK_STRUCTURE_TYPE_SUBRESOURCE_LAYOUT_2_KHR

如果支持 VK_KHR_dynamic_rendering 或 Vulkan 1.3 版本 和 VK_EXT_fragment_density_map

如果支持 VK_KHR_dynamic_rendering 或 Vulkan 1.3 版本 和 VK_KHR_fragment_shading_rate

如果支持 VK_ARM_pipeline_opacity_micromap

如果支持 VK_EXT_attachment_feedback_loop_layout

  • 扩展 VkPipelineCreateFlagBits2

    • VK_PIPELINE_CREATE_2_COLOR_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT

    • VK_PIPELINE_CREATE_2_DEPTH_STENCIL_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT

如果支持 VK_EXT_conditional_rendering

如果支持 VK_EXT_descriptor_buffer

  • 扩展 VkBufferUsageFlagBits2

    • VK_BUFFER_USAGE_2_PUSH_DESCRIPTORS_DESCRIPTOR_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_2_RESOURCE_DESCRIPTOR_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_2_SAMPLER_DESCRIPTOR_BUFFER_BIT_EXT

  • 扩展 VkPipelineCreateFlagBits2

    • VK_PIPELINE_CREATE_2_DESCRIPTOR_BUFFER_BIT_EXT

如果支持 VK_EXT_graphics_pipeline_library

  • 扩展 VkPipelineCreateFlagBits2

    • VK_PIPELINE_CREATE_2_LINK_TIME_OPTIMIZATION_BIT_EXT

    • VK_PIPELINE_CREATE_2_RETAIN_LINK_TIME_OPTIMIZATION_INFO_BIT_EXT

如果支持 VK_EXT_opacity_micromap

如果支持 VK_EXT_transform_feedback

  • 扩展 VkBufferUsageFlagBits2

    • VK_BUFFER_USAGE_2_TRANSFORM_FEEDBACK_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_2_TRANSFORM_FEEDBACK_COUNTER_BUFFER_BIT_EXT

如果支持 VK_KHR_acceleration_structure

  • 扩展 VkBufferUsageFlagBits2

    • VK_BUFFER_USAGE_2_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_BIT_KHR

    • VK_BUFFER_USAGE_2_ACCELERATION_STRUCTURE_STORAGE_BIT_KHR

如果支持 VK_KHR_pipeline_executable_properties

  • 扩展 VkPipelineCreateFlagBits2

    • VK_PIPELINE_CREATE_2_CAPTURE_INTERNAL_REPRESENTATIONS_BIT_KHR

    • VK_PIPELINE_CREATE_2_CAPTURE_STATISTICS_BIT_KHR

如果支持 VK_KHR_pipeline_library

如果支持 VK_KHR_ray_tracing_pipeline

  • 扩展 VkBufferUsageFlagBits2

    • VK_BUFFER_USAGE_2_SHADER_BINDING_TABLE_BIT_KHR

  • 扩展 VkPipelineCreateFlagBits2

    • VK_PIPELINE_CREATE_2_RAY_TRACING_NO_NULL_ANY_HIT_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_2_RAY_TRACING_NO_NULL_CLOSEST_HIT_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_2_RAY_TRACING_NO_NULL_INTERSECTION_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_2_RAY_TRACING_NO_NULL_MISS_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_2_RAY_TRACING_SHADER_GROUP_HANDLE_CAPTURE_REPLAY_BIT_KHR

    • VK_PIPELINE_CREATE_2_RAY_TRACING_SKIP_AABBS_BIT_KHR

    • VK_PIPELINE_CREATE_2_RAY_TRACING_SKIP_TRIANGLES_BIT_KHR

如果支持 VK_KHR_video_decode_queue

  • 扩展 VkBufferUsageFlagBits2

    • VK_BUFFER_USAGE_2_VIDEO_DECODE_DST_BIT_KHR

    • VK_BUFFER_USAGE_2_VIDEO_DECODE_SRC_BIT_KHR

如果支持 VK_KHR_video_encode_queue

  • 扩展 VkBufferUsageFlagBits2

    • VK_BUFFER_USAGE_2_VIDEO_ENCODE_DST_BIT_KHR

    • VK_BUFFER_USAGE_2_VIDEO_ENCODE_SRC_BIT_KHR

如果支持 VK_NV_device_generated_commands

如果支持 VK_NV_displacement_micromap

如果支持 VK_NV_ray_tracing

如果支持 VK_NV_ray_tracing_motion_blur

如果支持 Vulkan 1.2 版本 或 VK_KHR_buffer_device_address 或 VK_EXT_buffer_device_address

如果支持 Vulkan 1.3 版本 或 VK_EXT_pipeline_creation_cache_control

  • 扩展 VkPipelineCreateFlagBits2

    • VK_PIPELINE_CREATE_2_EARLY_RETURN_ON_FAILURE_BIT_KHR

    • VK_PIPELINE_CREATE_2_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT_KHR

如果支持 Vulkan 1.4 版本 或 VK_EXT_pipeline_protected_access

  • 扩展 VkPipelineCreateFlagBits2

    • VK_PIPELINE_CREATE_2_NO_PROTECTED_ACCESS_BIT_EXT

    • VK_PIPELINE_CREATE_2_PROTECTED_ACCESS_ONLY_BIT_EXT

晋升到 Vulkan 1.4

此扩展中的功能已包含在 Vulkan 1.4 核心版本中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1，2022-12-12 (Stu Smith)

    • 初始修订版

VK_KHR_maintenance6

名称字符串

VK_KHR_maintenance6

扩展类型

设备扩展

注册扩展号

546

修订

1

批准状态

已批准

扩展和版本依赖关系

Vulkan 版本 1.1

API 交互

  • 与 VK_EXT_descriptor_buffer 交互

  • 与 VK_KHR_push_descriptor 交互

弃用状态
联系方式
扩展提案

VK_KHR_maintenance6

其他扩展元数据

上次修改日期

2023-08-03

交互和外部依赖
贡献者

  • Jon Leech, Khronos

  • Stu Smith, AMD

  • Mike Blumenkrantz, Valve

  • Ralph Potter, Samsung

  • James Fitzpatrick, Imagination Technologies

  • Piers Daniell, NVIDIA

  • Daniel Story, Nintendo

描述

VK_KHR_maintenance6 添加了一系列次要功能，这些功能都不足以单独构成一个完整的扩展。

新功能如下

  • VkBindMemoryStatusKHR 可以包含在 VkBindBufferMemoryInfo 和 VkBindImageMemoryInfo 的 pNext 链中，允许应用程序识别在调用 vkBindBufferMemory2 和 vkBindImageMemory2 期间内存绑定失败的单个资源。

  • 一个新的属性 fragmentShadingRateClampCombinerInputs，用于指示实现是否限制片段着色率组合器操作的输入。

  • 当绑定索引缓冲区时，允许使用 VK_NULL_HANDLE，而不是有效的 VkBuffer 句柄。当启用 nullDescriptor 功能时，每个获取的索引都将产生零值。

  • 一个新的属性 maxCombinedImageSamplerDescriptorCount，用于指示实现支持的需要采样器 Y′CBCR 转换的格式所需的描述符的最大数量。

  • 一个新的属性 blockTexelViewCompatibleMultipleLayers，指示是否允许将 VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT 与 layerCount > 1 一起使用

  • 所有描述符绑定命令的 pNext 可扩展 *2 版本。

新命令

如果支持 VK_EXT_descriptor_buffer

如果支持 VK_KHR_push_descriptor

新结构体

如果支持 VK_EXT_descriptor_buffer

如果支持 VK_KHR_push_descriptor

新枚举常量

  • VK_KHR_MAINTENANCE_6_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_6_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BIND_DESCRIPTOR_SETS_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_MEMORY_STATUS_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_6_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_6_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PUSH_CONSTANTS_INFO_KHR

如果支持 VK_EXT_descriptor_buffer

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BIND_DESCRIPTOR_BUFFER_EMBEDDED_SAMPLERS_INFO_EXT

    • VK_STRUCTURE_TYPE_SET_DESCRIPTOR_BUFFER_OFFSETS_INFO_EXT

如果支持 VK_KHR_push_descriptor

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PUSH_DESCRIPTOR_SET_INFO_KHR

    • VK_STRUCTURE_TYPE_PUSH_DESCRIPTOR_SET_WITH_TEMPLATE_INFO_KHR

晋升到 Vulkan 1.4

此扩展中的功能已包含在 Vulkan 1.4 核心版本中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1，2023-08-01 (Jon Leech)

    • 初始修订版

VK_KHR_map_memory2

名称字符串

VK_KHR_map_memory2

扩展类型

设备扩展

注册扩展号

272

修订

1

批准状态

已批准

扩展和版本依赖关系

无

弃用状态
联系方式
扩展提案

VK_KHR_map_memory2

其他扩展元数据

上次修改日期

2023-03-14

交互和外部依赖

  • 无

贡献者

  • Faith Ekstrand, Collabora

  • Tobias Hector, AMD

描述

此扩展提供了 Vulkan 内存映射和取消映射命令的可扩展版本。新命令在功能上与核心命令相同，只是它们的参数是使用可扩展结构指定的，这些结构可用于传递特定于扩展的信息。

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_KHR_MAP_MEMORY_2_EXTENSION_NAME

  • VK_KHR_MAP_MEMORY_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_MEMORY_MAP_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_UNMAP_INFO_KHR

晋升到 Vulkan 1.4

此扩展中的功能已包含在 Vulkan 1.4 核心版本中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

版本历史

  • 修订版 0，2022-08-03 (Faith Ekstrand)

    • 内部修订

  • 修订版 1，2023-03-14

    • 公开发布

VK_KHR_multiview

名称字符串

VK_KHR_multiview

扩展类型

设备扩展

注册扩展号

54

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-10-28

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展的目标与 OpenGL ES 的 GL_OVR_multiview 扩展相同。多视图是一种最初为 VR 设计的渲染技术，在这种技术中，记录一组命令以针对每个“视图”以略微不同的行为执行更有效。

它包含一种简洁的方式来声明具有多个视图的渲染通道，并允许实现以尽可能高效的方式渲染视图。这是通过在渲染通道创建期间，使用传递到VkRenderPassCreateInfo::pNext 的 VkRenderPassMultiviewCreateInfo 指定的多视图配置来完成的。

此扩展启用了 SPV_KHR_multiview 着色器扩展的使用，该扩展添加了一个新的 ViewIndex 内置类型，允许着色器控制每个视图执行的操作。如果使用 GLSL，则还有 GL_EXT_multiview 扩展，该扩展为顶点、曲面细分、几何和片段着色器引入了 highp int gl_ViewIndex; 内置变量。

晋升到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构体

新枚举常量

  • VK_KHR_MULTIVIEW_EXTENSION_NAME

  • VK_KHR_MULTIVIEW_SPEC_VERSION

  • 扩展 VkDependencyFlagBits

    • VK_DEPENDENCY_VIEW_LOCAL_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO_KHR

新的内置变量

新的 SPIR-V 功能

版本历史

  • 修订版 1，2016-10-28 (Jeff Bolz)

    • 内部修订

VK_KHR_push_descriptor

名称字符串

VK_KHR_push_descriptor

扩展类型

设备扩展

注册扩展号

81

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

API 交互

  • 与 VK_VERSION_1_1 交互

  • 与 VK_KHR_descriptor_update_template 交互

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-09-12

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

  • Michael Worcester, Imagination Technologies

描述

此扩展允许将描述符写入命令缓冲区，同时实现负责管理其内存。推送描述符可以更容易地从旧的 API 进行移植，并且在某些情况下可能比将描述符写入描述符集更有效。

新命令

如果支持Vulkan 版本 1.1或VK_KHR_descriptor_update_template

新结构体

新的枚举常量

  • VK_KHR_PUSH_DESCRIPTOR_EXTENSION_NAME

  • VK_KHR_PUSH_DESCRIPTOR_SPEC_VERSION

  • 扩展 VkDescriptorSetLayoutCreateFlagBits

    • VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PUSH_DESCRIPTOR_PROPERTIES_KHR

如果支持Vulkan 版本 1.1或VK_KHR_descriptor_update_template

晋升到 Vulkan 1.4

此扩展中的功能已包含在 Vulkan 1.4 核心版本中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1，2016-10-15 (Jeff Bolz)

    • 内部修订

  • 修订版 2，2017-09-12 (Tobias Hector)

    • 添加了与 Vulkan 1.1 的交互。

VK_KHR_relaxed_block_layout

名称字符串

VK_KHR_relaxed_block_layout

扩展类型

设备扩展

注册扩展号

145

修订

1

批准状态

已批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-03-26

IP 状态

没有已知的 IP 声明。

贡献者

  • John Kessenich，Google

描述

VK_KHR_relaxed_block_layout 扩展允许实现表示它们可以支持块 Offset 修饰符的更多变化。例如，将一个包含三个浮点数的向量放置在偏移量为 16×N + 4 的位置。

有关详细信息，请参阅偏移量和步幅分配。

晋升到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新的枚举常量

  • VK_KHR_RELAXED_BLOCK_LAYOUT_EXTENSION_NAME

  • VK_KHR_RELAXED_BLOCK_LAYOUT_SPEC_VERSION

版本历史

  • 修订版 1，2017-03-26 (JohnK)

VK_KHR_sampler_mirror_clamp_to_edge

名称字符串

VK_KHR_sampler_mirror_clamp_to_edge

扩展类型

设备扩展

注册扩展号

15

修订

3

批准状态

已批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-08-17

贡献者

  • Tobias Hector, Imagination Technologies

  • Jon Leech, Khronos

描述

VK_KHR_sampler_mirror_clamp_to_edge 扩展了采样器寻址模式的集合，包含一个附加模式 (VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE)，该模式有效地使用了一个纹理映射，其大小是原始图像的两倍，其中新图像的附加一半是原始图像的镜像图像。

这种新模式放宽了生成对边匹配的图像的需求，而是使用原始图像来生成匹配的“镜像图像”。这种模式允许仅在负 s、t 和 r 方向上对纹理进行一次镜像。

晋升到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中。但是，如果支持 Vulkan 1.2 且不支持此扩展，则VkSamplerAddressMode VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE 是可选的。由于原始扩展没有在枚举 VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE 上使用作者后缀，因此核心实现和扩展实现都使用它。

新的枚举常量

  • VK_KHR_SAMPLER_MIRROR_CLAMP_TO_EDGE_EXTENSION_NAME

  • VK_KHR_SAMPLER_MIRROR_CLAMP_TO_EDGE_SPEC_VERSION

  • 扩展VkSamplerAddressMode

    • VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE

    • VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE_KHR

示例

在每个维度中创建一个具有新寻址模式的采样器

    VkSamplerCreateInfo createInfo =
    {
        .sType = VK_STRUCTURE_TYPE_SAMPLER_CREATE_INFO,
        // Other members set to application-desired values
    };

    createInfo.addressModeU = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;
    createInfo.addressModeV = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;
    createInfo.addressModeW = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;

    VkSampler sampler;
    VkResult result = vkCreateSampler(
        device,
        &createInfo,
        &sampler);

问题

1) 为什么同时存在 VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE 标记的 KHR 版本和核心版本？

已解决：此功能原计划在 Vulkan 1.0 中是必需的。我们在公开发布前不久意识到并非所有实现都支持它，并将该功能移动到可选扩展中，但没有应用 KHR 扩展后缀。添加非后缀枚举的 KHR 后缀别名是为了遵守我们自己的命名规则。

在一个相关的更改中，在规范修订版 1.1.121 之前，此扩展是硬编码到规范 Makefile 中的，因此它始终包含在规范中，即使在仅核心版本中也是如此。现在已经恢复，它被视为任何其他扩展。

版本历史

  • 修订版 1，2016-02-16 (Tobias Hector)

    • 初始草案

  • 修订版 2，2019-08-14 (Jon Leech)

    • 添加非后缀枚举的 KHR 后缀别名。

  • 修订版 3，2019-08-17 (Jon Leech)

    • 添加一个问题，解释了扩展 API 未使用 KHR 作为后缀的原因。

VK_KHR_sampler_ycbcr_conversion

名称字符串

VK_KHR_sampler_ycbcr_conversion

扩展类型

设备扩展

注册扩展号

157

修订

14

批准状态

已批准

扩展和版本依赖关系

     VK_KHR_maintenance1
     和
     VK_KHR_bind_memory2
     和
     VK_KHR_get_memory_requirements2
     和
     VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

API 交互

  • 与 VK_EXT_debug_report 交互

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-08-11

IP 状态

没有已知的 IP 声明。

贡献者

  • Andrew Garrard，三星电子

  • Tobias Hector, Imagination Technologies

  • James Jones, NVIDIA

  • Daniel Koch, NVIDIA

  • Daniel Rakos, AMD

  • Romain Guy, Google

  • Jesse Hall, Google

  • Tom Cooksey, ARM Ltd

  • Jeff Leger, Qualcomm Technologies, Inc

  • Jan-Harald Fredriksen, ARM Ltd

  • Jan Outters, Samsung Electronics

  • Alon Or-bach, Samsung Electronics

  • Michael Worcester, Imagination Technologies

  • Jeff Bolz, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Matthew Netsch, Qualcomm Technologies, Inc

描述

使用 Y′CBCR 采样器转换是 3D 图形中大多数 Vulkan 开发人员不常用的一个领域。它主要用于处理来自视频解码器和摄像头的输入。此扩展的使用假定对 Y′CBCR 概念有基本的了解。

此扩展提供了在纹理采样操作期间，对 Y′CBCR 色彩空间执行指定色彩空间转换的能力。它还添加了多种多平面格式、图像纵横比平面，以及将内存集体或单独绑定到图像平面的能力。

晋升到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀。但是，如果支持 Vulkan 1.1 且不支持此扩展，则 samplerYcbcrConversion 功能是可选的。原始的类型、枚举和命令名称仍然可以作为核心功能的别名使用。

新对象类型

新命令

新结构体

新枚举

新枚举常量

  • VK_KHR_SAMPLER_YCBCR_CONVERSION_EXTENSION_NAME

  • VK_KHR_SAMPLER_YCBCR_CONVERSION_SPEC_VERSION

  • 扩展 VkChromaLocation

    • VK_CHROMA_LOCATION_COSITED_EVEN_KHR

    • VK_CHROMA_LOCATION_MIDPOINT_KHR

  • 扩展 VkFormat

    • VK_FORMAT_B10X6G10X6R10X6G10X6_422_UNORM_4PACK16_KHR

    • VK_FORMAT_B12X4G12X4R12X4G12X4_422_UNORM_4PACK16_KHR

    • VK_FORMAT_B16G16R16G16_422_UNORM_KHR

    • VK_FORMAT_B8G8R8G8_422_UNORM_KHR

    • VK_FORMAT_G10X6B10X6G10X6R10X6_422_UNORM_4PACK16_KHR

    • VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16_KHR

    • VK_FORMAT_G10X6_B10X6R10X6_2PLANE_422_UNORM_3PACK16_KHR

    • VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16_KHR

    • VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_422_UNORM_3PACK16_KHR

    • VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_444_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4B12X4G12X4R12X4_422_UNORM_4PACK16_KHR

    • VK_FORMAT_G12X4_B12X4R12X4_2PLANE_420_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4_B12X4R12X4_2PLANE_422_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_420_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_422_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_444_UNORM_3PACK16_KHR

    • VK_FORMAT_G16B16G16R16_422_UNORM_KHR

    • VK_FORMAT_G16_B16R16_2PLANE_420_UNORM_KHR

    • VK_FORMAT_G16_B16R16_2PLANE_422_UNORM_KHR

    • VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM_KHR

    • VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM_KHR

    • VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM_KHR

    • VK_FORMAT_G8B8G8R8_422_UNORM_KHR

    • VK_FORMAT_G8_B8R8_2PLANE_420_UNORM_KHR

    • VK_FORMAT_G8_B8R8_2PLANE_422_UNORM_KHR

    • VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM_KHR

    • VK_FORMAT_G8_B8_R8_3PLANE_422_UNORM_KHR

    • VK_FORMAT_G8_B8_R8_3PLANE_444_UNORM_KHR

    • VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16_KHR

    • VK_FORMAT_R10X6G10X6_UNORM_2PACK16_KHR

    • VK_FORMAT_R10X6_UNORM_PACK16_KHR

    • VK_FORMAT_R12X4G12X4B12X4A12X4_UNORM_4PACK16_KHR

    • VK_FORMAT_R12X4G12X4_UNORM_2PACK16_KHR

    • VK_FORMAT_R12X4_UNORM_PACK16_KHR

  • 扩展 VkFormatFeatureFlagBits

    • VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT_KHR

    • VK_FORMAT_FEATURE_DISJOINT_BIT_KHR

    • VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT_KHR

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT_KHR

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT_KHR

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT_KHR

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT_KHR

  • 扩展 VkImageAspectFlagBits

    • VK_IMAGE_ASPECT_PLANE_0_BIT_KHR

    • VK_IMAGE_ASPECT_PLANE_1_BIT_KHR

    • VK_IMAGE_ASPECT_PLANE_2_BIT_KHR

  • 扩展 VkImageCreateFlagBits

    • VK_IMAGE_CREATE_DISJOINT_BIT_KHR

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_KHR

  • 扩展 VkSamplerYcbcrModelConversion

    • VK_SAMPLER_YCBCR_MODEL_CONVERSION_RGB_IDENTITY_KHR

    • VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_2020_KHR

    • VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_601_KHR

    • VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_709_KHR

    • VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_IDENTITY_KHR

  • 扩展 VkSamplerYcbcrRange

    • VK_SAMPLER_YCBCR_RANGE_ITU_FULL_KHR

    • VK_SAMPLER_YCBCR_RANGE_ITU_NARROW_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BIND_IMAGE_PLANE_MEMORY_INFO_KHR

    • VK_STRUCTURE_TYPE_IMAGE_PLANE_MEMORY_REQUIREMENTS_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_YCBCR_CONVERSION_FEATURES_KHR

    • VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_IMAGE_FORMAT_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_INFO_KHR

如果支持 VK_EXT_debug_report

  • 扩展 VkDebugReportObjectTypeEXT

    • VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_EXT

    • VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_KHR_EXT

版本历史

  • 修订版 1，2017-01-24 (Andrew Garrard)

    • 初始草案

  • 修订版 2，2017-01-25 (Andrew Garrard)

    • 在初步反馈之后

  • 修订版 3，2017-01-27 (Andrew Garrard)

    • 更高的位深度格式、重命名、交换

  • 修订版 4，2017-02-22 (Andrew Garrard)

    • 添加查询函数，格式为 RGB，澄清

  • 修订版 5，2017-04-?? (Andrew Garrard)

    • 简化了查询并删除了输出转换

  • 修订版 6，2017-04-24 (Andrew Garrard)

    • 整理、合并了新的图像查询，恢复了传输函数

  • 修订版 7，2017-04-25 (Andrew Garrard)

    • 为格式添加了 cosited 选项/中点要求，“bypassConversion”

  • 修订版 8，2017-04-25 (Andrew Garrard)

    • 进一步简化

  • 修订版 9，2017-04-27 (Andrew Garrard)

    • 不再是不相交的

  • 修订版 10，2017-04-28 (Andrew Garrard)

    • 恢复了不相交

  • 修订版 11，2017-04-29 (Andrew Garrard)

    • 现在是 Ycbcr 转换和 KHR

  • 修订版 12，2017-06-06 (Andrew Garrard)

    • 添加了到图像视图创建的转换

  • 修订版 13，2017-07-13 (Andrew Garrard)

    • 允许格式仅使用 cosited 色度样本

  • 修订版 14，2017-08-11 (Andrew Garrard)

    • 反映了 BT.2100-1 中的量化更改

VK_KHR_separate_depth_stencil_layouts

名称字符串

VK_KHR_separate_depth_stencil_layouts

扩展类型

设备扩展

注册扩展号

242

修订

1

批准状态

已批准

扩展和版本依赖关系

         VK_KHR_get_physical_device_properties2
         或
         Vulkan 版本 1.1
     和
     VK_KHR_create_renderpass2
或
Vulkan 版本 1.2

弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-06-25

贡献者

  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

  • Jesse Barker, Unity

  • Tobias Hector, AMD

描述

此扩展允许深度/模板图像的图像内存屏障仅设置 VK_IMAGE_ASPECT_DEPTH_BIT 或 VK_IMAGE_ASPECT_STENCIL_BIT 方面位之一，而不是要求两者都设置。这允许独立设置它们的布局。为了支持深度和模板方面具有不同布局的深度/模板图像，已更新深度/模板附件接口以支持单独的模板布局。

晋升到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构体

新枚举常量

  • VK_KHR_SEPARATE_DEPTH_STENCIL_LAYOUTS_EXTENSION_NAME

  • VK_KHR_SEPARATE_DEPTH_STENCIL_LAYOUTS_SPEC_VERSION

  • 扩展 VkImageLayout

    • VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_OPTIMAL_KHR

    • VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL_KHR

    • VK_IMAGE_LAYOUT_STENCIL_ATTACHMENT_OPTIMAL_KHR

    • VK_IMAGE_LAYOUT_STENCIL_READ_ONLY_OPTIMAL_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_STENCIL_LAYOUT_KHR

    • VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_STENCIL_LAYOUT_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SEPARATE_DEPTH_STENCIL_LAYOUTS_FEATURES_KHR

版本历史

  • 修订版 1，2019-06-25 (Piers Daniell)

    • 内部修订

VK_KHR_shader_atomic_int64

名称字符串

VK_KHR_shader_atomic_int64

扩展类型

设备扩展

注册扩展号

181

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-07-05

交互和外部依赖
贡献者

  • Aaron Hagan, AMD

  • Daniel Rakos, AMD

  • Jeff Bolz, NVIDIA

  • Neil Henning, Codeplay

描述

此扩展为 Vulkan 声明了 SPIR-V 的 Int64Atomics 功能，允许着色器包含对有符号和无符号整数的 64 位原子操作。支持的操作包括 OpAtomicMin、OpAtomicMax、OpAtomicAnd、OpAtomicOr、OpAtomicXor、OpAtomicAdd、OpAtomicExchange 和 OpAtomicCompareExchange。

晋升到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。但是，如果支持 Vulkan 1.2 且不支持此扩展，则 shaderBufferInt64Atomics 功能是可选的。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构体

新枚举常量

  • VK_KHR_SHADER_ATOMIC_INT64_EXTENSION_NAME

  • VK_KHR_SHADER_ATOMIC_INT64_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_INT64_FEATURES_KHR

新的 SPIR-V 功能

版本历史

  • 修订版 1，2018-07-05 (Aaron Hagan)

    • 内部修订

VK_KHR_shader_draw_parameters

名称字符串

VK_KHR_shader_draw_parameters

扩展类型

设备扩展

注册扩展号

64

修订

1

批准状态

已批准

扩展和版本依赖关系

无

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-09-05

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Daniel Koch, NVIDIA Corporation

  • Jeff Bolz, NVIDIA

  • Daniel Rakos, AMD

  • Jan-Harald Fredriksen, ARM

  • John Kessenich，Google

  • Stuart Smith, IMG

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

  • SPV_KHR_shader_draw_parameters

此扩展在 Vulkan 中提供了对三个额外的内置着色器变量的访问权限

  • BaseInstance，包含传递给绘制命令的 firstInstance 参数，

  • BaseVertex，包含传递给绘制命令的 firstVertex 或 vertexOffset 参数，以及

  • DrawIndex，包含从间接绘制调用中当前正在处理的绘制调用的索引。

当使用基于 GLSL 源的着色器语言时，来自 GL_ARB_shader_draw_parameters 的以下变量可以映射到这些 SPIR-V 内置修饰符

  • in int gl_BaseInstanceARB; → BaseInstance,

  • in int gl_BaseVertexARB; → BaseVertex, 和

  • in int gl_DrawIDARB; → DrawIndex.

晋升到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中。但是，添加了 shaderDrawParameters 功能位，以区分它是否实际可用。

新枚举常量

  • VK_KHR_SHADER_DRAW_PARAMETERS_EXTENSION_NAME

  • VK_KHR_SHADER_DRAW_PARAMETERS_SPEC_VERSION

新的内置变量

新的 SPIR-V 功能

问题

1) 这是否与 GL_ARB_shader_draw_parameters 的功能相同？

已解决：它实际上是一个超集，因为它还增加了对数组绘制命令的支持。

在 GL 中，对于 GL_ARB_shader_draw_parameters，gl_BaseVertexARB 保存传递给导致当前着色器调用的命令的参数的整数值。如果命令没有 baseVertex 参数，则 gl_BaseVertexARB 的值为零。这意味着 gl_BaseVertexARB = baseVertex（对于带有 baseVertex 的 glDrawElements 命令）或 0。特别地，没有采用 baseVertex 参数的 glDrawArrays 命令。

现在在 Vulkan 中，我们有 BaseVertex = vertexOffset（对于索引绘制命令）或 firstVertex（对于数组绘制命令），因此 Vulkan 的版本实际上是 GL 功能的超集。

版本历史

  • 修订版 1，2016-10-05 (Daniel Koch)

    • 内部修订

VK_KHR_shader_expect_assume

名称字符串

VK_KHR_shader_expect_assume

扩展类型

设备扩展

注册扩展号

545

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式
扩展提案

VK_KHR_shader_expect_assume

其他扩展元数据

上次修改日期

2023-12-06

IP 状态

没有已知的 IP 声明。

贡献者

  • Kevin Petit, Arm

  • Tobias Hector, AMD

  • James Fitzpatrick, Imagination Technologies

描述

此扩展允许在 SPIR-V 着色器模块中使用 SPV_KHR_expect_assume 扩展，这使 SPIR-V 生成器可以向 Vulkan 实现提供优化提示。

新结构体

新枚举常量

  • VK_KHR_SHADER_EXPECT_ASSUME_EXTENSION_NAME

  • VK_KHR_SHADER_EXPECT_ASSUME_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_EXPECT_ASSUME_FEATURES_KHR

新的 SPIR-V 功能

晋升到 Vulkan 1.4

此扩展中的功能已包含在 Vulkan 1.4 核心版本中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1，2023-12-06 (Kevin Petit)

    • 初始修订版

VK_KHR_shader_float16_int8

名称字符串

VK_KHR_shader_float16_int8

扩展类型

设备扩展

注册扩展号

83

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-03-07

交互和外部依赖
IP 状态

没有已知的 IP 声明。

贡献者

  • Alexander Galazin, Arm

  • Jan-Harald Fredriksen, Arm

  • Jeff Bolz, NVIDIA

  • Graeme Leese, Broadcom

  • Daniel Rakos, AMD

描述

VK_KHR_shader_float16_int8 扩展允许在着色器中使用 16 位浮点类型和 8 位整数类型进行算术运算。

它引入了两个新的可选特性 shaderFloat16 和 shaderInt8，它们直接映射到 SPIR-V 的 Float16 和 Int8 功能。VK_KHR_shader_float16_int8 扩展还指定了半精度浮点 SPIR-V 操作的精度要求。此扩展不会在任何着色器输入和输出接口中启用 8 位整数类型或 16 位浮点类型的使用，因此不会取代 VK_KHR_8bit_storage 或 VK_KHR_16bit_storage 扩展。

晋升到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，并省略了 KHR 后缀。但是，如果支持 Vulkan 1.2 并且不支持此扩展，则 shaderFloat16 和 shaderInt8 功能都是可选的。原始类型、枚举和命令名称仍然可以作为核心功能的别名使用。

新结构

新枚举常量

  • VK_KHR_SHADER_FLOAT16_INT8_EXTENSION_NAME

  • VK_KHR_SHADER_FLOAT16_INT8_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT16_INT8_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_FLOAT16_INT8_FEATURES_KHR

版本历史

  • 修订版 1，2018-03-07 (Alexander Galazin)

    • 初始草案

VK_KHR_shader_float_controls

名称字符串

VK_KHR_shader_float_controls

扩展类型

设备扩展

注册扩展号

198

修订

4

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-09-11

IP 状态

没有已知的 IP 声明。

贡献者

  • Alexander Galazin, Arm

  • Jan-Harald Fredriksen, Arm

  • Jeff Bolz, NVIDIA

  • Graeme Leese, Broadcom

  • Daniel Rakos, AMD

描述

VK_KHR_shader_float_controls 扩展通过能够查询和覆盖实现对舍入模式、非正规数、有符号零和无穷大的默认行为，从而实现高效的浮点计算。

晋升到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构

新枚举

新枚举常量

  • VK_KHR_SHADER_FLOAT_CONTROLS_EXTENSION_NAME

  • VK_KHR_SHADER_FLOAT_CONTROLS_SPEC_VERSION

  • 扩展 VkShaderFloatControlsIndependence

    • VK_SHADER_FLOAT_CONTROLS_INDEPENDENCE_32_BIT_ONLY_KHR

    • VK_SHADER_FLOAT_CONTROLS_INDEPENDENCE_ALL_KHR

    • VK_SHADER_FLOAT_CONTROLS_INDEPENDENCE_NONE_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR

新的 SPIR-V 功能

问题

1) 哪些指令必须刷新非正规数？

已解决：只有浮点转换、浮点算术、浮点关系（除了 OpIsNaN、OpIsInf）和浮点 GLSL.std.450 扩展指令必须刷新非正规数。

2) 中间结果的非正规数行为是什么？

已解决：当 SPIR-V 指令实现为其他指令序列时

  • 在 DenormFlushToZero 执行模式下，中间指令可以刷新非正规数，序列的最终结果必须不是非正规数。

  • 在 DenormPreserve 执行模式下，非正规数必须在整个序列中保留。

3) 非正规数和舍入模式控制是否适用于 OpSpecConstantOp？

已解决：是的，除非操作码是 OpQuantizeToF16。

4) SPIR-V 规范指出 OpConvertFToU 和 OpConvertFToS 无条件向零舍入。通过执行模式指定的舍入模式控制是否适用于它们？

已解决：不，这些指令无条件向零舍入。

5) 任何 “Pack” GLSL.std.450 指令是否算作转换指令并应用舍入模式？

已解决：不，只有 SPIR-V 规范的 “3.32.11. 转换指令” 部分中列出的指令才算作转换指令。

6) 当使用 inf/nan 忽略模式时，对 OpIsNan 和 OpIsInf 的期望是什么？

已解决：这些指令必须始终准确检测传递给它们的 inf/nan。

版本 4 API 不兼容性

VK_KHR_shader_float_controls 的原始版本附带了名为“separateDenormSettings”和“separateRoundingModeSettings”的布尔值，乍一看可能表示“它们可以全部独立设置，也可以不设置”。然而，规范语言的编写表明，32 位值始终可以独立设置，只有当这些值是 VK_FALSE 时，16 位和 64 位控制才需要相同。

由于这种轻微的差异，以及对该扩展方面的测试覆盖不足，我们最终在野外出现了两种不同的行为，其中一些实现按编写工作，而另一些则基于命名工作。由于这些是硬件中的硬限制，并且有理由按编写公开，因此无法在现有 API 中标准化一种工作方式。

野外不存在此扩展部分的已知用户，因此 Vulkan WG 采取了不同寻常的步骤，将曾经是布尔值的值追溯更改为三态枚举，从而破坏了源代码兼容性。但是，这样做的方式是保留 ABI 兼容性，以防存在任何使用此代码的情况；数值 0 和 1 保留了其原始指定含义，而新值表示额外的 “都需要一起设置” 状态。如果今天存在任何应用程序，编译后的二进制文件将在大多数情况下继续按编写工作，但在重新编译代码之前需要进行更改。

版本历史

  • 修订版 4，2019-06-18 (Tobias Hector)

  • 修订版 3，2018-09-11 (Alexander Galazin)

    • 小幅重组

  • 修订版 2，2018-04-17 (Alexander Galazin)

    • 添加了问题和解决方案

  • 修订版 1，2018-04-11 (Alexander Galazin)

    • 初始草案

VK_KHR_shader_float_controls2

名称字符串

VK_KHR_shader_float_controls2

扩展类型

设备扩展

注册扩展号

529

修订

1

批准状态

已批准

扩展和版本依赖关系

Vulkan 版本 1.1
和
VK_KHR_shader_float_controls

SPIR-V 依赖项
弃用状态
联系方式
扩展提案

VK_KHR_shader_float_controls2

其他扩展元数据

上次修改日期

2023-05-16

交互和外部依赖
贡献者

  • Graeme Leese, Broadcom

描述

此扩展启用了 SPV_KHR_float_controls2 扩展中更具表现力的快速浮点数学标志的使用。这些标志可以更精细地控制编译器可以应用的优化，从而在保留正确结果的同时，潜在地加快执行速度。

此扩展还为 GLSL 扩展指令集添加了对快速数学模式的控制，使这些操作与 SPIR-V 更一致，并允许在浮点一致性很重要的情况下使用它们。

新结构

新枚举常量

  • VK_KHR_SHADER_FLOAT_CONTROLS_2_EXTENSION_NAME

  • VK_KHR_SHADER_FLOAT_CONTROLS_2_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_FLOAT_CONTROLS_2_FEATURES_KHR

新的 SPIR-V 功能

升级到 Vulkan 1.4

此扩展中的功能已包含在 Vulkan 1.4 核心版本中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1，2023-05-16 (Graeme Leese)

    • 初始草案

VK_KHR_shader_integer_dot_product

名称字符串

VK_KHR_shader_integer_dot_product

扩展类型

设备扩展

注册扩展号

281

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式
扩展提案

VK_KHR_shader_integer_dot_product

其他扩展元数据

上次修改日期

2021-06-16

交互和外部依赖
IP 状态

没有已知的 IP 声明。

贡献者

  • Kévin Petit，Arm Ltd.

  • Jeff Bolz, NVidia

  • Spencer Fricke, Samsung

  • Jesse Hall, Google

  • John Kessenich，Google

  • Graeme Leese, Broadcom

  • Einar Hov, Arm Ltd.

  • Stuart Brady, Arm Ltd.

  • Pablo Cascon, Arm Ltd.

  • Tobias Hector, AMD

  • Jeff Leger, Qualcomm

  • Ruihao Zhang，高通

  • Pierre Boudier, NVidia

  • Jon Leech, The Khronos Group

  • Tom Olson, Arm Ltd.

描述

此扩展添加了对 SPV_KHR_integer_dot_product 中定义的整数点积 SPIR-V 指令的支持。这些指令对于神经网络推理和训练特别有用，但在其他通用计算应用程序中也得到了应用。

新结构

新枚举常量

  • VK_KHR_SHADER_INTEGER_DOT_PRODUCT_EXTENSION_NAME

  • VK_KHR_SHADER_INTEGER_DOT_PRODUCT_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INTEGER_DOT_PRODUCT_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INTEGER_DOT_PRODUCT_PROPERTIES_KHR

升级到 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 KHR 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍可用作核心功能的别名。

新的 SPIR-V 功能

版本历史

  • 修订版 1，2021-06-16 (Kévin Petit)

    • 初始修订版

VK_KHR_shader_non_semantic_info

名称字符串

VK_KHR_shader_non_semantic_info

扩展类型

设备扩展

注册扩展号

294

修订

1

批准状态

已批准

扩展和版本依赖关系

无

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-10-16

IP 状态

没有已知的 IP 声明。

贡献者

  • Baldur Karlsson, Valve

描述

此扩展允许在 SPIR-V 着色器模块中使用 SPV_KHR_non_semantic_info 扩展。

新枚举常量

  • VK_KHR_SHADER_NON_SEMANTIC_INFO_EXTENSION_NAME

  • VK_KHR_SHADER_NON_SEMANTIC_INFO_SPEC_VERSION

升级到 Vulkan 1.3

此扩展中的功能已包含在 Vulkan 1.3 核心中。由于该扩展没有控制其功能的 API，因此只会导致 SPIR-V 扩展表发生更改。

版本历史

  • 修订版 1，2019-10-16 (Baldur Karlsson)

    • 初始修订版

VK_KHR_shader_subgroup_extended_types

名称字符串

VK_KHR_shader_subgroup_extended_types

扩展类型

设备扩展

注册扩展号

176

修订

1

批准状态

已批准

扩展和版本依赖关系

Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-01-08

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

  • Jan-Harald Fredriksen, Arm

  • Neil Henning, AMD

  • Daniel Koch, NVIDIA

  • Jeff Leger, Qualcomm

  • Graeme Leese, Broadcom

  • David Neto，Google

  • Daniel Rakos, AMD

描述

此扩展使 SPIR-V 中的非统一组操作能够支持 8 位整数、16 位整数、64 位整数、16 位浮点数以及这些类型的向量。

升级到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构

新枚举常量

  • VK_KHR_SHADER_SUBGROUP_EXTENDED_TYPES_EXTENSION_NAME

  • VK_KHR_SHADER_SUBGROUP_EXTENDED_TYPES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SUBGROUP_EXTENDED_TYPES_FEATURES_KHR

版本历史

  • 修订版 1，2019-01-08 (Neil Henning)

    • 初始草案

VK_KHR_shader_subgroup_rotate

名称字符串

VK_KHR_shader_subgroup_rotate

扩展类型

设备扩展

注册扩展号

417

修订

2

批准状态

已批准

扩展和版本依赖关系

无

SPIR-V 依赖项
弃用状态
联系方式
扩展提案

VK_KHR_shader_subgroup_rotate

上次修改日期

2024-01-29

IP 状态

没有已知的 IP 声明。

贡献者

  • Kévin Petit，Arm Ltd.

  • Tobias Hector, AMD

  • Jon Leech, Khronos

  • Matthew Netsch, Qualcomm

  • Jan-Harald Fredriksen, Arm Ltd.

  • Graeme Leese, Broadcom

  • Tom Olson, Arm Ltd.

  • Spencer Fricke, LunarG Inc.

此扩展添加了对 SPV_KHR_subgroup_rotate 中定义的子组旋转指令的支持。

新结构

新枚举常量

  • VK_KHR_SHADER_SUBGROUP_ROTATE_EXTENSION_NAME

  • VK_KHR_SHADER_SUBGROUP_ROTATE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SUBGROUP_ROTATE_FEATURES_KHR

  • 扩展 VkSubgroupFeatureFlagBits

    • VK_SUBGROUP_FEATURE_ROTATE_BIT_KHR

    • VK_SUBGROUP_FEATURE_ROTATE_CLUSTERED_BIT_KHR

新的 SPIR-V 功能

升级到 Vulkan 1.4

此扩展中的功能已包含在 Vulkan 1.4 核心版本中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

版本历史

  • 修订版 2，2024-01-29 (Kévin Petit)

    • 添加 VK_SUBGROUP_FEATURE_ROTATE_BIT_KHR 和 VK_SUBGROUP_FEATURE_ROTATE_CLUSTERED_BIT_KHR

  • 修订版 1，2023-06-20 (Kévin Petit)

    • 初始修订版

VK_KHR_shader_terminate_invocation

名称字符串

VK_KHR_shader_terminate_invocation

扩展类型

设备扩展

注册扩展号

216

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2020-08-11

IP 状态

没有已知的 IP 声明。

贡献者

  • Alan Baker, Google

  • Jeff Bolz, NVIDIA

  • Jesse Hall, Google

  • Ralph Potter, Samsung

  • Tom Olson, Arm

描述

此扩展为 SPV_KHR_terminate_invocation SPIR-V 扩展添加了 Vulkan 支持。该 SPIR-V 扩展提供了一个新的指令 OpTerminateInvocation，它会导致着色器调用立即终止并将着色样本的覆盖率设置为 0；只有先前执行的指令才会有可观察的效果。OpTerminateInvocation 指令，连同 VK_EXT_shader_demote_to_helper_invocation 扩展中的 OpDemoteToHelperInvocation 指令一起，取代了 OpKill 指令，该指令的行为可能类似于这两个指令中的任何一个。OpTerminateInvocation 提供了 GLSL discard 语句所需的行为，并且 GLSL 编译器和需要 GLSL discard 行为的应用程序在可用时应使用它。

新结构

新枚举常量

  • VK_KHR_SHADER_TERMINATE_INVOCATION_EXTENSION_NAME

  • VK_KHR_SHADER_TERMINATE_INVOCATION_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_TERMINATE_INVOCATION_FEATURES_KHR

晋升到 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 KHR 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍可用作核心功能的别名。

版本历史

  • 修订版 1，2020-08-11（Jesse Hall）

VK_KHR_spirv_1_4

名称字符串

VK_KHR_spirv_1_4

扩展类型

设备扩展

注册扩展号

237

修订

1

批准状态

已批准

扩展和版本依赖关系

Vulkan 版本 1.1
和
VK_KHR_shader_float_controls

弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-04-01

IP 状态

没有已知的 IP 声明。

交互和外部依赖

  • 需要 SPIR-V 1.4。

贡献者

  • Alexander Galazin, Arm

  • David Neto，Google

  • Jesse Hall, Google

  • John Kessenich，Google

  • Neil Henning, AMD

  • Tom Olson, Arm

描述

此扩展允许使用 SPIR-V 1.4 着色器模块。SPIR-V 1.4 的新特性主要使其更容易成为来自高级语言的编译器的目标，而不是暴露新的硬件功能。

SPIR-V 1.4 合并了也作为扩展单独提供的功能。SPIR-V 1.4 着色器模块不需要使用 OpExtension 操作码启用这些扩展，因为它们是 SPIR-V 1.4 的组成部分。

SPIR-V 1.4 引入了新的浮点执行模式功能，也可以通过 SPV_KHR_float_controls 获得。实现不需要支持所有这些新功能；可以使用来自 VK_KHR_shader_float_controls 扩展的 VkPhysicalDeviceFloatControlsPropertiesKHR 查询支持。

晋升到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新枚举常量

  • VK_KHR_SPIRV_1_4_EXTENSION_NAME

  • VK_KHR_SPIRV_1_4_SPEC_VERSION

问题

1. 我们应该为这个 SPIR-V 版本设置一个特定的扩展，还是添加一个用于 SPIR-V 版本的版本通用查询？SPIR-V 1.4 不需要任何其他 API 更改。

已解决：仅公开 SPIR-V 1.4。

大多数新的 SPIR-V 版本引入了可选的必需功能或具有实现定义的限制，并且需要更多特定于该版本的 API 和规范更改才能在 Vulkan 中使用它们。例如，为了支持 SPIR-V 1.3 中添加的子组功能，需要引入 VkPhysicalDeviceSubgroupProperties 以允许查询支持的组操作类别、最大支持的子组大小等。虽然我们可以泛型地公开新 SPIR-V 版本中不需要伴随更改的部分，但我们仍然最终会为剩余部分编写特定于每个版本的扩展。因此，通用机制不会减少未来规范编写的工作量。此外，很难提前弄清楚未来版本的哪些部分受通用机制支持，哪些部分在没有特定支持的情况下不能使用。

2. 同一管线的不同阶段可以使用具有不同 SPIR-V 版本的着色器吗？

已解决：可以。

在同一管线中混合 SPIR-V 版本 1.0-1.3 并没有被禁止，因此禁止混合 1.4 和以前的版本是不一致的。SPIR-V 1.4 没有引入任何会导致此处出现新困难的东西。

3. 为了在 SPIR-V 1.4 模块中使用在 1.4 中升级为核心的 SPIR-V 扩展对应的 Vulkan 扩展，是否必须启用它们？

已解决：否，但有注意事项。

SPIR-V 1.4 模块不需要声明 SPIR-V 扩展，因为该功能现在是核心的一部分，因此无需启用允许 SPIR-V 模块声明 SPIR-V 扩展的 Vulkan 扩展。但是，当现在 SPIR-V 1.4 中是核心的功能是可选支持时，对支持的查询由 Vulkan 扩展提供，并且只有在启用该扩展时才能使用该查询。

这适用于任何 SPIR-V 版本；特别是对于 SPIR-V 1.4，这仅适用于 SPV_KHR_float_controls 中的功能，该功能已通过 VK_KHR_shader_float_controls 在 Vulkan 中提供。即使该扩展在 SPIR-V 1.4 中被提升，但在支持 VK_KHR_spirv_1_4 的实现中，这些功能仍然是可选的。

SPIR-V 1.4 模块不需要启用 SPV_KHR_float_controls 才能使用这些功能，因此如果应用程序事先知道该实现支持这些功能，则它不需要启用 VK_KHR_shader_float_controls。但是，如果它没有此知识并且必须在运行时查询支持，则必须启用 VK_KHR_shader_float_controls 才能使用 VkPhysicalDeviceFloatControlsPropertiesKHR。

版本历史

  • 修订版 1，2019-04-01（Jesse Hall）

    • 内部草案版本

VK_KHR_storage_buffer_storage_class

名称字符串

VK_KHR_storage_buffer_storage_class

扩展类型

设备扩展

注册扩展号

132

修订

1

批准状态

已批准

扩展和版本依赖关系

无

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-09-05

IP 状态

没有已知的 IP 声明。

贡献者

  • Alexander Galazin，ARM

  • David Neto，Google

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

  • SPV_KHR_storage_buffer_storage_class

此扩展提供了一个新的 SPIR-V StorageBuffer 存储类。此类中带有 Block 修饰的对象等效于 Uniform 存储类中带有 BufferBlock 修饰的对象。

晋升到 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中。

新枚举常量

  • VK_KHR_STORAGE_BUFFER_STORAGE_CLASS_EXTENSION_NAME

  • VK_KHR_STORAGE_BUFFER_STORAGE_CLASS_SPEC_VERSION

版本历史

  • 修订版 1，2017-03-23 (Alexander Galazin)

    • 初始草案

VK_KHR_synchronization2

名称字符串

VK_KHR_synchronization2

扩展类型

设备扩展

注册扩展号

315

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

API 交互

  • 与 VK_EXT_blend_operation_advanced 交互

  • 与 VK_EXT_conditional_rendering 交互

  • 与 VK_EXT_device_generated_commands 交互

  • 与 VK_EXT_fragment_density_map 交互

  • 与 VK_EXT_mesh_shader 交互

  • 与 VK_EXT_transform_feedback 交互

  • 与 VK_KHR_acceleration_structure 交互

  • 与 VK_KHR_fragment_shading_rate 交互

  • 与 VK_KHR_ray_tracing_pipeline 交互

  • 与 VK_NV_device_generated_commands 交互

  • 与 VK_NV_mesh_shader 交互

  • 与 VK_NV_ray_tracing 交互

  • 与 VK_NV_shading_rate_image 交互

弃用状态
联系方式

其他扩展元数据

上次修改日期

2020-12-03

交互和外部依赖
贡献者

  • Tobias Hector

描述

此扩展修改了原始的核心同步 API，以简化接口并提高这些 API 的可用性。它还添加了新的管线阶段和访问标志类型，这些类型扩展到 64 位范围，因为我们在 32 位范围内已用完。新的标志与 32 位范围内的旧值相同，并在此基础上增加了新的阶段和位。

管线阶段和访问标志现在在内存屏障结构中一起指定，使得两者之间的联系更加明显。此外，将管线阶段限定在屏障结构中允许使用 MEMORY_READ 和 MEMORY_WRITE 标志，而不会牺牲精度。每个阶段的访问标志应用于消除给定阶段或一组阶段中特定访问的歧义 - 例如，统一读取和采样操作之间。

布局转换也得到了简化；不再需要为深度/模板/颜色附件使用不同的布局集，而是使用通用的 VK_IMAGE_LAYOUT_ATTACHMENT_OPTIMAL_KHR 和 VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR 布局，这些布局根据图像格式进行上下文应用。例如，对于深度格式图像，VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR 等效于 VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL_KHR。VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR 在功能上也取代了 VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL。

事件现在更有效率，因为在设备上设置事件时，它们会包含内存依赖性信息。以前，此信息仅在等待事件时才已知，因此依赖关系在等待发生之前无法满足。这有时意味着在等待发生时会使管线停滞。新的 API 提供了足够的信息，使实现能够在与其他任务并行的情况下满足这些依赖关系。

队列提交已更改为将命令缓冲区和信号量包装在可扩展的结构中，这些结构整合了 Vulkan 1.1、VK_KHR_device_group 和 VK_KHR_timeline_semaphore 的更改。这还为信号量信号操作添加了一个管线阶段，镜像了等待操作的现有管线阶段规范。

其他杂项更改包括

  • 事件现在可以指定为仅与设备交互，从而允许更有效地访问底层对象。

  • 可以通过将 oldLayout 设置为等于 newLayout 来指定不执行图像布局转换的图像内存屏障。

    • 例如，旧布局和新布局都可以设置为 VK_IMAGE_LAYOUT_UNDEFINED，而不会丢弃图像中的数据。

  • 在某些情况下，队列族所有权转移参数得到了简化。

  • 具有带 VkPipelineStageFlags 或 VkPipelineStageFlagBits 参数的命令或函数的扩展已将其 API 替换为使用 VkPipelineStageFlags2KHR 的等效 API。

  • 新的事件和屏障接口现在更具可扩展性，以适应未来的更改。

  • 现在可以使用新的 VK_PIPELINE_STAGE_NONE_KHR 和 VK_PIPELINE_STAGE_2_NONE_KHR 值将相关的管线阶段掩码指定为空。

  • VkMemoryBarrier2KHR 可以链接到 VkSubpassDependency2，从而覆盖原始的 32 位阶段和访问掩码。

新基础类型

  • VkFlags64

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_KHR_SYNCHRONIZATION_2_EXTENSION_NAME

  • VK_KHR_SYNCHRONIZATION_2_SPEC_VERSION

  • 扩展 VkAccessFlagBits

    • VK_ACCESS_NONE_KHR

  • 扩展 VkAccessFlagBits2

    • VK_ACCESS_2_COLOR_ATTACHMENT_READ_BIT_KHR

    • VK_ACCESS_2_COLOR_ATTACHMENT_WRITE_BIT_KHR

    • VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_READ_BIT_KHR

    • VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT_KHR

    • VK_ACCESS_2_HOST_READ_BIT_KHR

    • VK_ACCESS_2_HOST_WRITE_BIT_KHR

    • VK_ACCESS_2_INDEX_READ_BIT_KHR

    • VK_ACCESS_2_INDIRECT_COMMAND_READ_BIT_KHR

    • VK_ACCESS_2_INPUT_ATTACHMENT_READ_BIT_KHR

    • VK_ACCESS_2_MEMORY_READ_BIT_KHR

    • VK_ACCESS_2_MEMORY_WRITE_BIT_KHR

    • VK_ACCESS_2_NONE_KHR

    • VK_ACCESS_2_SHADER_READ_BIT_KHR

    • VK_ACCESS_2_SHADER_SAMPLED_READ_BIT_KHR

    • VK_ACCESS_2_SHADER_STORAGE_READ_BIT_KHR

    • VK_ACCESS_2_SHADER_STORAGE_WRITE_BIT_KHR

    • VK_ACCESS_2_SHADER_WRITE_BIT_KHR

    • VK_ACCESS_2_TRANSFER_READ_BIT_KHR

    • VK_ACCESS_2_TRANSFER_WRITE_BIT_KHR

    • VK_ACCESS_2_UNIFORM_READ_BIT_KHR

    • VK_ACCESS_2_VERTEX_ATTRIBUTE_READ_BIT_KHR

  • 扩展 VkEventCreateFlagBits

    • VK_EVENT_CREATE_DEVICE_ONLY_BIT_KHR

  • 扩展 VkImageLayout

    • VK_IMAGE_LAYOUT_ATTACHMENT_OPTIMAL_KHR

    • VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR

  • 扩展 VkPipelineStageFlagBits

    • VK_PIPELINE_STAGE_NONE_KHR

  • 扩展 VkPipelineStageFlagBits2

    • VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT_KHR

    • VK_PIPELINE_STAGE_2_ALL_GRAPHICS_BIT_KHR

    • VK_PIPELINE_STAGE_2_ALL_TRANSFER_BIT_KHR

    • VK_PIPELINE_STAGE_2_BLIT_BIT_KHR

    • VK_PIPELINE_STAGE_2_BOTTOM_OF_PIPE_BIT_KHR

    • VK_PIPELINE_STAGE_2_CLEAR_BIT_KHR

    • VK_PIPELINE_STAGE_2_COLOR_ATTACHMENT_OUTPUT_BIT_KHR

    • VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT_KHR

    • VK_PIPELINE_STAGE_2_COPY_BIT_KHR

    • VK_PIPELINE_STAGE_2_DRAW_INDIRECT_BIT_KHR

    • VK_PIPELINE_STAGE_2_EARLY_FRAGMENT_TESTS_BIT_KHR

    • VK_PIPELINE_STAGE_2_FRAGMENT_SHADER_BIT_KHR

    • VK_PIPELINE_STAGE_2_GEOMETRY_SHADER_BIT_KHR

    • VK_PIPELINE_STAGE_2_HOST_BIT_KHR

    • VK_PIPELINE_STAGE_2_INDEX_INPUT_BIT_KHR

    • VK_PIPELINE_STAGE_2_LATE_FRAGMENT_TESTS_BIT_KHR

    • VK_PIPELINE_STAGE_2_NONE_KHR

    • VK_PIPELINE_STAGE_2_PRE_RASTERIZATION_SHADERS_BIT_KHR

    • VK_PIPELINE_STAGE_2_RESOLVE_BIT_KHR

    • VK_PIPELINE_STAGE_2_TESSELLATION_CONTROL_SHADER_BIT_KHR

    • VK_PIPELINE_STAGE_2_TESSELLATION_EVALUATION_SHADER_BIT_KHR

    • VK_PIPELINE_STAGE_2_TOP_OF_PIPE_BIT_KHR

    • VK_PIPELINE_STAGE_2_TRANSFER_BIT_KHR

    • VK_PIPELINE_STAGE_2_VERTEX_ATTRIBUTE_INPUT_BIT_KHR

    • VK_PIPELINE_STAGE_2_VERTEX_INPUT_BIT_KHR

    • VK_PIPELINE_STAGE_2_VERTEX_SHADER_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BUFFER_MEMORY_BARRIER_2_KHR

    • VK_STRUCTURE_TYPE_COMMAND_BUFFER_SUBMIT_INFO_KHR

    • VK_STRUCTURE_TYPE_DEPENDENCY_INFO_KHR

    • VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER_2_KHR

    • VK_STRUCTURE_TYPE_MEMORY_BARRIER_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SYNCHRONIZATION_2_FEATURES_KHR

    • VK_STRUCTURE_TYPE_SEMAPHORE_SUBMIT_INFO_KHR

    • VK_STRUCTURE_TYPE_SUBMIT_INFO_2_KHR

  • 扩展 VkSubmitFlagBits

    • VK_SUBMIT_PROTECTED_BIT_KHR

如果支持 VK_EXT_blend_operation_advanced

如果支持 VK_EXT_conditional_rendering

如果支持 VK_EXT_device_generated_commands

如果支持 VK_EXT_fragment_density_map

如果支持 VK_EXT_mesh_shader

如果支持 VK_EXT_transform_feedback

  • 扩展 VkAccessFlagBits2

    • VK_ACCESS_2_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT

    • VK_ACCESS_2_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT

    • VK_ACCESS_2_TRANSFORM_FEEDBACK_WRITE_BIT_EXT

  • 扩展 VkPipelineStageFlagBits2

    • VK_PIPELINE_STAGE_2_TRANSFORM_FEEDBACK_BIT_EXT

如果支持 VK_KHR_acceleration_structure

  • 扩展 VkAccessFlagBits2

    • VK_ACCESS_2_ACCELERATION_STRUCTURE_READ_BIT_KHR

    • VK_ACCESS_2_ACCELERATION_STRUCTURE_WRITE_BIT_KHR

  • 扩展 VkPipelineStageFlagBits2

    • VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_BUILD_BIT_KHR

如果支持 VK_KHR_fragment_shading_rate

如果支持 VK_KHR_ray_tracing_pipeline

如果支持 VK_NV_device_generated_commands

如果支持 VK_NV_mesh_shader

如果支持 VK_NV_ray_tracing

  • 扩展 VkAccessFlagBits2

    • VK_ACCESS_2_ACCELERATION_STRUCTURE_READ_BIT_NV

    • VK_ACCESS_2_ACCELERATION_STRUCTURE_WRITE_BIT_NV

  • 扩展 VkPipelineStageFlagBits2

    • VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_BUILD_BIT_NV

    • VK_PIPELINE_STAGE_2_RAY_TRACING_SHADER_BIT_NV

如果支持 VK_NV_shading_rate_image

晋升至 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 KHR 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍可用作核心功能的别名。

示例

请参阅 https://github.com/KhronosGroup/Vulkan-Docs/wiki/Synchronization-Examples

版本历史

  • 修订版 1，2020-12-03（Tobias Hector）

    • 内部修订

VK_KHR_timeline_semaphore

名称字符串

VK_KHR_timeline_semaphore

扩展类型

设备扩展

注册扩展号

208

修订

2

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-06-12

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

  • Yuriy O’Donnell, Epic Games

  • Faith Ekstrand, Intel

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Daniel Rakos, AMD

  • Ray Smith, Arm

描述

此扩展引入了一种新型的信号量，该信号量具有一个整数有效负载，用于标识时间线中的某个点。这种时间线信号量支持以下操作：

  • 主机查询 - 一种主机操作，允许查询时间线信号量的有效负载。

  • 主机等待 - 一种主机操作，允许阻塞等待时间线信号量达到指定的值。

  • 主机信号 - 一种主机操作，允许将时间线信号量推进到指定的值。

  • 设备等待 - 一种设备操作，允许等待时间线信号量达到指定的值。

  • 设备信号 - 一种设备操作，允许将时间线信号量推进到指定的值。

晋升为 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_KHR_TIMELINE_SEMAPHORE_EXTENSION_NAME

  • VK_KHR_TIMELINE_SEMAPHORE_SPEC_VERSION

  • 扩展 VkSemaphoreType

    • VK_SEMAPHORE_TYPE_BINARY_KHR

    • VK_SEMAPHORE_TYPE_TIMELINE_KHR

  • 扩展 VkSemaphoreWaitFlagBits

    • VK_SEMAPHORE_WAIT_ANY_BIT_KHR

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TIMELINE_SEMAPHORE_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TIMELINE_SEMAPHORE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_SEMAPHORE_SIGNAL_INFO_KHR

    • VK_STRUCTURE_TYPE_SEMAPHORE_TYPE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_SEMAPHORE_WAIT_INFO_KHR

    • VK_STRUCTURE_TYPE_TIMELINE_SEMAPHORE_SUBMIT_INFO_KHR

问题

1）我们需要为此使用新的对象类型吗？

已解决：不需要，我们只是引入一种新的信号量对象类型，因为 VK_KHR_external_semaphore_win32 已经使用信号量作为导入 D3D12 栅栏对象的目标，这些栅栏对象在语义上与提议的同步原语接近/相同。

2）新的同步原语具有哪种类型的有效负载？

已解决：一个 64 位无符号整数，只能通过信号操作设置为严格递增的值，并且不会被等待操作更改。

3）新的同步原语是否与现有信号量一样具有相同的信号先于等待的要求？

已解决：否。时间线信号量完全支持异步的信号和等待。应用程序有责任避免死锁。

4）新的同步原语是否允许重置其有效负载？

已解决：否，允许有效负载值“倒退”是有问题的。寻求重置行为的应用程序应该创建新的同步原语实例。

5）我们如何启用对同步原语的主机等待？

已解决：提供了同步原语的当前有效负载值的非阻塞查询和阻塞等待操作。

6）我们如何启用对同步原语的设备等待和信号？

已解决：与 VK_KHR_external_semaphore_win32 类似，此扩展引入了一个新结构，可以链接到 VkSubmitInfo 以指定信号量应设置的值，以及等待信号量需要达到的值。

7）新的同步原语是否可用于同步演示和交换链图像获取操作？

已解决：某些实现可能在直接支持此功能方面存在问题，因此在此扩展中不允许这样做。

8）我们是否要支持新同步原语类型的外部共享？

已解决：是。可以使用 vkGetPhysicalDeviceExternalSemaphoreProperties 并将新的 VkSemaphoreTypeCreateInfoKHR 结构链接到其 pExternalSemaphoreInfo 结构来查询时间线信号量特定的外部共享功能。这允许为时间线信号量与二进制信号量支持不同的外部信号量句柄类型集。

9）我们需要为新的同步原语类型添加主机信号操作吗？

已解决：是。这有助于在一种主机线程提交工作负载但另一种主机线程具有工作负载何时准备好执行的信息的情况下。

10）新的同步原语应如何与原始 VkSemaphore 的排序要求交互？

已解决：在调用任何 可能 导致二进制信号量等待操作的命令之前，应用程序 必须 确保已提交执行的信号量信号操作及其所依赖的任何信号量信号操作（如果有）也 必须 已提交执行。

11）我们是否应该为时间线信号量的不同子功能设置单独的功能位？

已解决：否。唯一不能普遍支持的功能是时间线信号量的导入/导出。对于导入/导出，应用程序已经需要通过 vkGetPhysicalDeviceExternalSemaphoreProperties 查询可用的外部句柄类型，并通过将 VkSemaphoreTypeCreateInfoKHR 结构添加到 VkPhysicalDeviceExternalSemaphoreInfo 的 pNext 链中来提供信号量类型，因此不需要新的功能位。

版本历史

  • 修订版 1，2018-05-10 (Faith Ekstrand)

    • 初始版本

  • 修订版 2，2019-06-12 (Faith Ekstrand)

    • 向时间线信号量创建添加了一个 initialValue 参数

VK_KHR_uniform_buffer_standard_layout

名称字符串

VK_KHR_uniform_buffer_standard_layout

扩展类型

设备扩展

注册扩展号

254

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-01-25

贡献者

  • Graeme Leese, Broadcom

  • Jeff Bolz, NVIDIA

  • Tobias Hector, AMD

  • Faith Ekstrand, Intel

  • Neil Henning, AMD

描述

此扩展允许对统一缓冲区使用更紧密的数组和结构体打包。

它修改了统一缓冲区的对齐规则，允许更紧密地打包数组和结构体。例如，这允许在统一缓冲区中支持 GLSL 中定义的 std430 布局。

晋升至 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构体

新枚举常量

  • VK_KHR_UNIFORM_BUFFER_STANDARD_LAYOUT_EXTENSION_NAME

  • VK_KHR_UNIFORM_BUFFER_STANDARD_LAYOUT_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_UNIFORM_BUFFER_STANDARD_LAYOUT_FEATURES_KHR

版本历史

  • 修订版 1，2019-01-25 (Graeme Leese)

    • 初始草案

VK_KHR_variable_pointers

名称字符串

VK_KHR_variable_pointers

扩展类型

设备扩展

注册扩展号

121

修订

1

批准状态

已批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
     和
     VK_KHR_storage_buffer_storage_class
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-09-05

IP 状态

没有已知的 IP 声明。

贡献者

  • John Kessenich，Google

  • Neil Henning, Codeplay

  • David Neto，Google

  • Daniel Koch, Nvidia

  • Graeme Leese, Broadcom

  • Weifeng Zhang, Qualcomm

  • Stephen Clarke, Imagination Technologies

  • Faith Ekstrand, Intel

  • Jesse Hall, Google

描述

VK_KHR_variable_pointers 扩展允许实现指示它们对 SPV_KHR_variable_pointers SPIR-V 扩展的支持级别。SPIR-V 扩展允许着色器模块使用指向统一缓冲区和/或存储缓冲区的调用私有指针，其中指针值可以是动态的和非统一的。

SPV_KHR_variable_pointers 扩展引入了两个功能。第一个，VariablePointersStorageBuffer，必须由该扩展的所有实现支持。第二个，VariablePointers，是可选的。

晋升至 Vulkan 1.1

此扩展中的所有功能都包含在核心 Vulkan 1.1 中，省略了 KHR 后缀，但是对 variablePointersStorageBuffer 功能的支持是可选的。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构体

新枚举常量

  • VK_KHR_VARIABLE_POINTERS_EXTENSION_NAME

  • VK_KHR_VARIABLE_POINTERS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VARIABLE_POINTERS_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VARIABLE_POINTER_FEATURES_KHR

新的 SPIR-V 功能

问题

1) 我们是否需要为 SPIR-V VariablePointersStorageBuffer 功能提供一个可选属性，还是当广告此扩展时应该强制执行？

已解决：将其添加为一个单独的功能，但使其强制支持。将其添加为功能使得该扩展更容易包含在未来的核心 API 版本中。在该扩展中，该功能是强制性的，因此该扩展的存在保证了某些功能。当包含在核心 API 版本中时，该功能将是可选的。

2) 这些功能的支持是否在着色器阶段之间有所不同？

已解决：否，如果该功能在任何阶段都受支持，则必须在所有阶段都受支持。

3) 这些功能应该是特性还是限制？

已解决：特性，主要是为了与其他类似扩展保持一致。

版本历史

  • 修订版 1，2017-03-14 (Jesse Hall 和 John Kessenich)

    • 内部修订

VK_KHR_vertex_attribute_divisor

名称字符串

VK_KHR_vertex_attribute_divisor

扩展类型

设备扩展

注册扩展号

526

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式
扩展提案

VK_KHR_vertex_attribute_divisor

其他扩展元数据

上次修改日期

2023-09-20

IP 状态

没有已知的 IP 声明。

贡献者

描述

此扩展基于 VK_EXT_vertex_attribute_divisor 扩展。唯一的区别是新的属性 supportsNonZeroFirstInstance，它表示支持 firstInstance 中的非零值。这允许在传统上仅支持 OpenGL ES 的实现上支持该扩展。

新结构体

新枚举常量

  • VK_KHR_VERTEX_ATTRIBUTE_DIVISOR_EXTENSION_NAME

  • VK_KHR_VERTEX_ATTRIBUTE_DIVISOR_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_KHR

晋升至 Vulkan 1.4

此扩展中的功能已包含在 Vulkan 1.4 核心版本中，省略了 KHR 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

版本历史

VK_KHR_vulkan_memory_model

名称字符串

VK_KHR_vulkan_memory_model

扩展类型

设备扩展

注册扩展号

212

修订

3

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-12-10

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

  • Alan Baker, Google

  • Tobias Hector, AMD

  • David Neto，Google

  • Robert Simpson, Qualcomm Technologies, Inc.

  • Brian Sumner, AMD

描述

VK_KHR_vulkan_memory_model 扩展允许使用着色器模块中受 VulkanMemoryModel、VulkanMemoryModelDeviceScope 和 VulkanMemoryModelAvailabilityVisibilityChains 功能保护的功能。Vulkan 内存模型正式定义了如何同步多个着色器调用对相同内存位置执行的内存访问。

规范的第 3 版在 VkPhysicalDeviceVulkanMemoryModelFeaturesKHR 中添加了一个成员 (vulkanMemoryModelAvailabilityVisibilityChains)，这是与第 2 版的不兼容更改。

晋升至 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 KHR 后缀。但是，如果支持 Vulkan 1.2 并且不支持此扩展，则 vulkanMemoryModel 功能是可选的。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构体

新枚举常量

  • VK_KHR_VULKAN_MEMORY_MODEL_EXTENSION_NAME

  • VK_KHR_VULKAN_MEMORY_MODEL_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR

新的 SPIR-V 功能

版本历史

  • 修订版 1，2018-06-24 (Jeff Bolz)

    • 初始草案

  • 修订版 3，2018-12-10 (Jeff Bolz)

    • 向 VkPhysicalDeviceVulkanMemoryModelFeaturesKHR 结构添加 vulkanMemoryModelAvailabilityVisibilityChains 成员。

VK_KHR_zero_initialize_workgroup_memory

名称字符串

VK_KHR_zero_initialize_workgroup_memory

扩展类型

设备扩展

注册扩展号

326

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2020-11-18

IP 状态

没有已知的 IP 声明。

贡献者

  • Alan Baker, Google

  • Jeff Bolz, Nvidia

  • Faith Ekstrand, Intel

描述

此扩展允许在着色器工作组内存变量上使用空常量初始化器，从而允许实现公开它们可能拥有的任何特殊硬件或指令。零初始化通常被运行不受信任内容（例如，Web 浏览器）的应用程序用作一种击败内存抓取攻击的方法。

新结构体

新枚举常量

  • VK_KHR_ZERO_INITIALIZE_WORKGROUP_MEMORY_EXTENSION_NAME

  • VK_KHR_ZERO_INITIALIZE_WORKGROUP_MEMORY_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ZERO_INITIALIZE_WORKGROUP_MEMORY_FEATURES_KHR

升级到 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 KHR 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍可用作核心功能的别名。

版本历史

  • 修订版 1, 2020-11-18 (Alan Baker)

    • 内部草稿版本

VK_EXT_4444_formats

名称字符串

VK_EXT_4444_formats

扩展类型

设备扩展

注册扩展号

341

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2020-07-28

IP 状态

没有已知的 IP 声明。

贡献者

  • Joshua Ashton, Valve

  • Faith Ekstrand, Intel

描述

此扩展定义了 VK_FORMAT_A4R4G4B4_UNORM_PACK16_EXT 和 VK_FORMAT_A4B4G4R4_UNORM_PACK16_EXT 格式，这些格式在其他当前的图形 API 中定义。

此扩展对于构建这些 API 的转换层或移植使用这些格式而无需诉诸交换的应用可能很有用。

当使用 VK_EXT_custom_border_color 时，这些格式不受与 VK_FORMAT_B4G4R4A4_UNORM_PACK16 相同的无格式边框颜色限制。

新结构体

新枚举常量

  • VK_EXT_4444_FORMATS_EXTENSION_NAME

  • VK_EXT_4444_FORMATS_SPEC_VERSION

  • 扩展 VkFormat

    • VK_FORMAT_A4B4G4R4_UNORM_PACK16_EXT

    • VK_FORMAT_A4R4G4B4_UNORM_PACK16_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_4444_FORMATS_FEATURES_EXT

升级到 Vulkan 1.3

扩展引入的格式枚举包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。但是，核心 Vulkan 1.3 中对这些格式的运行时支持是可选的，而如果支持此扩展，则运行时支持是强制性的。功能结构未升级。原始枚举名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1, 2020-07-04 (Joshua Ashton)

    • 初始草案

VK_EXT_buffer_device_address

名称字符串

VK_EXT_buffer_device_address

扩展类型

设备扩展

注册扩展号

245

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-01-06

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

  • Neil Henning, AMD

  • Tobias Hector, AMD

  • Faith Ekstrand, Intel

  • Baldur Karlsson, Valve

描述

此扩展允许应用程序查询缓冲区的 64 位缓冲区设备地址值，该值可用于通过 GL_EXT_buffer_reference GLSL 扩展和 SPV_EXT_physical_storage_buffer SPIR-V 扩展中的 PhysicalStorageBufferEXT 存储类访问缓冲区内存。

它还允许跟踪重放工具提供缓冲区设备地址，以便它与捕获跟踪时使用的地址匹配。

新命令

新结构体

新枚举常量

  • VK_EXT_BUFFER_DEVICE_ADDRESS_EXTENSION_NAME

  • VK_EXT_BUFFER_DEVICE_ADDRESS_SPEC_VERSION

  • 扩展 VkBufferCreateFlagBits

    • VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_EXT

  • 扩展 VkBufferUsageFlagBits

    • VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_EXT

  • 扩展 VkResult

    • VK_ERROR_INVALID_DEVICE_ADDRESS_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_ADDRESS_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_EXT

新 SPIR-V 功能

问题

1) VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_ADDRESS_FEATURES_EXT 和 VkPhysicalDeviceBufferAddressFeaturesEXT 在哪里？

已解决：为了保持一致性，它们被重命名为 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_EXT 和 VkPhysicalDeviceBufferDeviceAddressFeaturesEXT。即使如此，为了兼容性，旧名称仍然可以在生成的头文件中找到。

版本历史

  • 修订版 1, 2018-11-01 (Jeff Bolz)

    • 内部修订

  • 修订版 2, 2019-01-06 (Jon Leech)

    • 对附录进行次要更新以供发布

VK_EXT_calibrated_timestamps

名称字符串

VK_EXT_calibrated_timestamps

扩展类型

设备扩展

注册扩展号

185

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式
扩展提案

VK_EXT_calibrated_timestamps

其他扩展元数据

上次修改日期

2018-10-04

IP 状态

没有已知的 IP 声明。

贡献者

  • Matthaeus G. Chajdas, AMD

  • Alan Harrison, AMD

  • Derrick Owens, AMD

  • Daniel Rakos, AMD

  • Faith Ekstrand, Intel

  • Keith Packard, Valve

描述

此扩展提供了一个接口，用于查询从两个时间域准同时获得的校准时间戳。

升级到 VK_KHR_calibrated_timestamps

此扩展中的所有功能都包含在 VK_KHR_calibrated_timestamps 中，后缀更改为 KHR。原始枚举名称仍然可用作 KHR 功能的别名。

新命令

新结构体

新枚举

新枚举常量

  • VK_EXT_CALIBRATED_TIMESTAMPS_EXTENSION_NAME

  • VK_EXT_CALIBRATED_TIMESTAMPS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_CALIBRATED_TIMESTAMP_INFO_EXT

  • 扩展 VkTimeDomainKHR

    • VK_TIME_DOMAIN_CLOCK_MONOTONIC_EXT

    • VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT

    • VK_TIME_DOMAIN_DEVICE_EXT

    • VK_TIME_DOMAIN_QUERY_PERFORMANCE_COUNTER_EXT

版本历史

  • 修订版 2, 2021-03-16 (Lionel Landwerlin)

    • 指定设备时间戳的要求

  • 修订版 1, 2018-10-04 (Daniel Rakos)

    • 内部修订。

VK_EXT_debug_marker

名称字符串

VK_EXT_debug_marker

扩展类型

设备扩展

注册扩展号

23

修订

4

批准状态

未批准

扩展和版本依赖关系

VK_EXT_debug_report

弃用状态
特殊用途
联系方式

其他扩展元数据

上次修改日期

2017-01-31

IP 状态

没有已知的 IP 声明。

贡献者

  • Baldur Karlsson

  • Dan Ginsburg, Valve

  • Jon Ashburn, LunarG

  • Kyle Spagnoli, NVIDIA

描述

VK_EXT_debug_marker 扩展是一个设备扩展。它引入了对象命名和标记的概念，以便更好地跟踪 Vulkan 对象，以及用于记录工作负载的命名部分的注释的其他命令，以帮助组织和外部工具中的离线分析。

新命令

新结构体

新枚举

新枚举常量

  • VK_EXT_DEBUG_MARKER_EXTENSION_NAME

  • VK_EXT_DEBUG_MARKER_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEBUG_MARKER_MARKER_INFO_EXT

    • VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_NAME_INFO_EXT

    • VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_TAG_INFO_EXT

示例

示例 1

为图像关联一个名称，以便在外部工具中或在验证层中更容易进行调试，这些工具和验证层可以在错误消息中引用对象时打印友好的名称。

    extern VkDevice device;
    extern VkImage image;

    // Must call extension functions through a function pointer:
    PFN_vkDebugMarkerSetObjectNameEXT pfnDebugMarkerSetObjectNameEXT = (PFN_vkDebugMarkerSetObjectNameEXT)vkGetDeviceProcAddr(device, "vkDebugMarkerSetObjectNameEXT");

    // Set a name on the image
    const VkDebugMarkerObjectNameInfoEXT imageNameInfo =
    {
        .sType = VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_NAME_INFO_EXT,
        .pNext = NULL,
        .objectType = VK_DEBUG_REPORT_OBJECT_TYPE_IMAGE_EXT,
        .object = (uint64_t)image,
        .pObjectName = "Brick Diffuse Texture",
    };

    pfnDebugMarkerSetObjectNameEXT(device, &imageNameInfo);

    // A subsequent error might print:
    //   Image 'Brick Diffuse Texture' (0xc0dec0dedeadbeef) is used in a
    //   command buffer with no memory bound to it.

示例 2

使用命名信息注释工作负载的区域，以便脱机分析工具可以显示更易用的提交命令可视化。

    extern VkDevice device;
    extern VkCommandBuffer commandBuffer;

    // Must call extension functions through a function pointer:
    PFN_vkCmdDebugMarkerBeginEXT pfnCmdDebugMarkerBeginEXT = (PFN_vkCmdDebugMarkerBeginEXT)vkGetDeviceProcAddr(device, "vkCmdDebugMarkerBeginEXT");
    PFN_vkCmdDebugMarkerEndEXT pfnCmdDebugMarkerEndEXT = (PFN_vkCmdDebugMarkerEndEXT)vkGetDeviceProcAddr(device, "vkCmdDebugMarkerEndEXT");
    PFN_vkCmdDebugMarkerInsertEXT pfnCmdDebugMarkerInsertEXT = (PFN_vkCmdDebugMarkerInsertEXT)vkGetDeviceProcAddr(device, "vkCmdDebugMarkerInsertEXT");

    // Describe the area being rendered
    const VkDebugMarkerMarkerInfoEXT houseMarker =
    {
        .sType = VK_STRUCTURE_TYPE_DEBUG_MARKER_MARKER_INFO_EXT,
        .pNext = NULL,
        .pMarkerName = "Brick House",
        .color = { 1.0f, 0.0f, 0.0f, 1.0f },
    };

    // Start an annotated group of calls under the 'Brick House' name
    pfnCmdDebugMarkerBeginEXT(commandBuffer, &houseMarker);
    {
        // A mutable structure for each part being rendered
        VkDebugMarkerMarkerInfoEXT housePartMarker =
        {
            .sType = VK_STRUCTURE_TYPE_DEBUG_MARKER_MARKER_INFO_EXT,
            .pNext = NULL,
            .pMarkerName = NULL,
            .color = { 0.0f, 0.0f, 0.0f, 0.0f },
        };

        // Set the name and insert the marker
        housePartMarker.pMarkerName = "Walls";
        pfnCmdDebugMarkerInsertEXT(commandBuffer, &housePartMarker);

        // Insert the drawcall for the walls
        vkCmdDrawIndexed(commandBuffer, 1000, 1, 0, 0, 0);

        // Insert a recursive region for two sets of windows
        housePartMarker.pMarkerName = "Windows";
        pfnCmdDebugMarkerBeginEXT(commandBuffer, &housePartMarker);
        {
            vkCmdDrawIndexed(commandBuffer, 75, 6, 1000, 0, 0);
            vkCmdDrawIndexed(commandBuffer, 100, 2, 1450, 0, 0);
        }
        pfnCmdDebugMarkerEndEXT(commandBuffer);

        housePartMarker.pMarkerName = "Front Door";
        pfnCmdDebugMarkerInsertEXT(commandBuffer, &housePartMarker);

        vkCmdDrawIndexed(commandBuffer, 350, 1, 1650, 0, 0);

        housePartMarker.pMarkerName = "Roof";
        pfnCmdDebugMarkerInsertEXT(commandBuffer, &housePartMarker);

        vkCmdDrawIndexed(commandBuffer, 500, 1, 2000, 0, 0);
    }
    // End the house annotation started above
    pfnCmdDebugMarkerEndEXT(commandBuffer);

问题

1) 对象的标签或名称是否应使用对象的 Vk*CreateInfo 结构中的 pNext 参数指定？

已解决：否。虽然这符合其他 Vulkan 模式，并且可以提高类型安全性和防止未来对象出现问题，但它也有明显的缺点。特别是，在 Vk*CreateInfo 时传递名称不允许重命名，阻止了命名信息的后期绑定，并且不允许命名隐式创建的对象，例如队列和交换链图像。

2) 命令注释函数 vkCmdDebugMarkerBeginEXT 和 vkCmdDebugMarkerEndEXT 是否应支持指定颜色的功能？

已解决：是。这些函数已扩展为接受一个可选颜色，实现可以随意使用该颜色，在其可视化中消耗命令缓冲区注释。

3) 此扩展中添加的函数是否应接受可扩展的结构作为其参数，以获得更灵活的 API，而不是直接函数参数？ 如果是，哪些函数？

已解决：是。所有函数都已修改为接受具有可扩展的 pNext 指针的结构类型，以允许未来的扩展在同一命令中添加其他注释信息。

版本历史

  • 修订版 1，2016-02-24（Baldur Karlsson）

    • 基于 LunarG 标记规范的初始草案

  • 修订版 2，2016-02-26（Baldur Karlsson）

    • 在函数名称中将 Dbg 重命名为 DebugMarker

    • 在某些情况下允许辅助命令缓冲区中的标记

    • 微小的语言调整和编辑

  • 修订版 3，2016-04-23（Baldur Karlsson）

    • 重新组织规范布局以更接近所需的组织

    • 为标记添加可选颜色（区域和插入标签）

    • 将函数更改为接受可扩展结构而不是直接函数参数

  • 修订版 4，2017-01-31（Baldur Karlsson）

    • 添加了对 VK_EXT_debug_report 的显式依赖

    • 将 VkDebugReportObjectTypeEXT 的定义移动到调试报告章节。

    • 修复了修订历史中的日期中的错别字

VK_EXT_debug_report

名称字符串

VK_EXT_debug_report

扩展类型

实例扩展

注册扩展号

12

修订

10

批准状态

未批准

扩展和版本依赖关系

无

API 交互

  • 与 VK_VERSION_1_1 交互

弃用状态
特殊用途
联系方式

其他扩展元数据

上次修改日期

2020-12-14

IP 状态

没有已知的 IP 声明。

贡献者

  • Courtney Goeltzenleuchter, LunarG

  • Dan Ginsburg, Valve

  • Jon Ashburn, LunarG

  • Mark Lobodzinski, LunarG

描述

由于 Vulkan 界面的性质，开发人员和应用程序可用的错误信息非常少。通过启用可选的验证层并使用 VK_EXT_debug_report 扩展，开发人员可以获得有关应用程序使用 Vulkan 的更详细的反馈。此扩展定义了一种方式，使层和实现可以回调用应用程序来处理应用程序感兴趣的事件。

新对象类型

新命令

新结构体

新函数指针

新枚举

新位掩码

新枚举常量

  • VK_EXT_DEBUG_REPORT_EXTENSION_NAME

  • VK_EXT_DEBUG_REPORT_SPEC_VERSION

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT

  • 扩展 VkResult

    • VK_ERROR_VALIDATION_FAILED_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT

如果支持 Vulkan 版本 1.1

  • 扩展 VkDebugReportObjectTypeEXT

    • VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_EXT

    • VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_EXT

示例

VK_EXT_debug_report 允许应用程序向验证层注册多个回调。一些回调可能会将信息记录到文件中，另一些回调可能会导致调试断点或其他应用程序定义的行为。即使未启用任何验证层，应用程序可以注册回调，但它们只会为加载程序事件（如果已实现）和驱动程序事件调用。

为了捕获在创建或销毁实例时发生的事件，应用程序可以将 VkDebugReportCallbackCreateInfoEXT 结构链接到提供给 vkCreateInstance 的 VkInstanceCreateInfo 结构的 pNext 元素。

示例用法：创建三个回调对象。一个将使用 Windows OutputDebugString 将错误和警告记录到调试控制台。第二个将在发生错误时导致调试器在该回调处中断，第三个将警告记录到标准输出。

    VkResult res;
    VkDebugReportCallbackEXT cb1, cb2, cb3;

    VkDebugReportCallbackCreateInfoEXT callback1 = {
        .sType = VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,
        .pNext = NULL,
        .flags = VK_DEBUG_REPORT_ERROR_BIT_EXT |
                 VK_DEBUG_REPORT_WARNING_BIT_EXT,
        .pfnCallback = myOutputDebugString,
        .pUserData = NULL
    };
    res = vkCreateDebugReportCallbackEXT(instance, &callback1, &cb1);
    if (res != VK_SUCCESS)
       /* Do error handling for VK_ERROR_OUT_OF_MEMORY */

    callback.flags = VK_DEBUG_REPORT_ERROR_BIT_EXT;
    callback.pfnCallback = myDebugBreak;
    callback.pUserData = NULL;
    res = vkCreateDebugReportCallbackEXT(instance, &callback, &cb2);
    if (res != VK_SUCCESS)
       /* Do error handling for VK_ERROR_OUT_OF_MEMORY */

    VkDebugReportCallbackCreateInfoEXT callback3 = {
        .sType = VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,
        .pNext = NULL,
        .flags = VK_DEBUG_REPORT_WARNING_BIT_EXT,
        .pfnCallback = mystdOutLogger,
        .pUserData = NULL
    };
    res = vkCreateDebugReportCallbackEXT(instance, &callback3, &cb3);
    if (res != VK_SUCCESS)
       /* Do error handling for VK_ERROR_OUT_OF_MEMORY */

    ...

    /* remove callbacks when cleaning up */
    vkDestroyDebugReportCallbackEXT(instance, cb1);
    vkDestroyDebugReportCallbackEXT(instance, cb2);
    vkDestroyDebugReportCallbackEXT(instance, cb3);

在 VK_EXT_debug_report 扩展的初始版本中，使用了标记 VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT。从扩展分支的第 2 版开始，为了与 Vulkan 命名规则保持一致，改用 VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT。为了向后兼容，较旧的枚举仍然可用。

在 VK_EXT_debug_report 扩展的初始版本中，使用了标记 VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_EXT。从扩展分支的第 8 版开始，为了与 Vulkan 命名规则保持一致，改用 VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT_EXT。为了向后兼容，较旧的枚举仍然可用。

问题

1) 消息标志的层次结构/严重性是什么？ 例如 ERROR > WARN > PERF_WARN …​

已解决：没有特定的层次结构。每个位都是独立的，应通过按位与进行检查。例如

    if (localFlags & VK_DEBUG_REPORT_ERROR_BIT_EXT) {
        process error message
    }
    if (localFlags & VK_DEBUG_REPORT_DEBUG_BIT_EXT) {
        process debug message
    }

验证层以分层方式使用它们（ERROR > WARN > PERF，WARN > DEBUG > INFO），并且它们（至少在编写本文时）一次只设置一个位。但这并不是此扩展的要求。

层可能会拦截并更改或使用应用程序的调试报告处理程序可能不熟悉的扩展值来增强标志，因此独立处理每个标志非常重要。

2) 是否应存在 VU 要求 VkDebugReportCallbackCreateInfoEXT::flags 不为零？

已解决：它可能不是很有用，但我们不需要 VU 语句要求在创建时 VkDebugReportCallbackCreateInfoEXT::msgFlags 不为零。可以想象，应用程序可能会更喜欢它，因为它允许它们在运行时根据需要设置掩码（包括什么都不设置），而无需进行检查。

3) VK_DEBUG_REPORT_DEBUG_BIT_EXT 和 VK_DEBUG_REPORT_INFORMATION_BIT_EXT 之间有什么区别？

已解决：VK_DEBUG_REPORT_DEBUG_BIT_EXT 指定了可能有助于调试 Vulkan 实现本身的信息。

4) 如何比较 debug_report 回调返回的句柄与应用程序的句柄？

已解决：由于可分发和不可分发句柄的性质不同，对于常见的 32 位、64 位、C 和 C++ 编译器来说，没有通用的方法（我们所知）可以工作。我们建议应用程序使用验证层使用的相同转换。

+

reinterpret_cast<uint64_t &>(dispatchableHandle)
(uint64_t)(nondispatchableHandle)

+ 这确实要求应用程序以不同的方式处理可分发和不可分发句柄。

版本历史

  • 版本 1, 2015-05-20 (Courtney Goetzenleuchter)

    • 基于 LunarG KHR 规范和其他 KHR 规范的初始草案

  • 版本 2, 2016-02-16 (Courtney Goetzenleuchter)

    • 更新用法、文档

  • 版本 3, 2016-06-14 (Courtney Goetzenleuchter)

    • 更新 VK_EXT_DEBUG_REPORT_SPEC_VERSION 以指示增加了对 vkCreateInstance 和 vkDestroyInstance 的支持

  • 版本 4, 2016-12-08 (Mark Lobodzinski)

    • 添加了 Display_KHR、DisplayModeKHR 扩展对象

    • 添加了 ObjectTable_NVX、IndirectCommandsLayout_NVX 扩展对象

    • 提升了规范版本

    • 追溯添加了版本历史

  • 版本 5, 2017-01-31 (Baldur Karlsson)

  • 版本 6, 2017-01-31 (Baldur Karlsson)

    • 添加了 VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR_EXT

  • 版本 7, 2017-04-20 (Courtney Goeltzenleuchter)

    • 澄清措辞并解决开发人员提出的问题。

  • 版本 8, 2017-04-21 (Courtney Goeltzenleuchter)

    • 删除未使用的枚举 VkDebugReportErrorEXT

  • 版本 9, 2017-09-12 (Tobias Hector)

    • 添加了与 Vulkan 1.1 的交互。

  • 版本 10, 2020-12-14 (Courtney Goetzenleuchter)

    • 根据公开问题 368 中的建议，添加了讨论匹配扩展返回的句柄的第 4 个问题。

VK_EXT_depth_clamp_zero_one

名称字符串

VK_EXT_depth_clamp_zero_one

扩展类型

设备扩展

注册扩展号

422

修订

1

批准状态

已批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2021-07-29

贡献者

  • Graeme Leese, Broadcom

描述

此扩展为最终超出传统 [0, 1] 范围的片段深度值定义了行为。它可以用于确保诸如 depthBias 等功能的边缘情况下的可移植性。选择的特定行为与 OpenGL 匹配，以帮助移植或模拟。

提升至 VK_KHR_depth_clamp_zero_one

此扩展中的所有功能都包含在 VK_KHR_depth_clamp_zero_one 中，并将后缀更改为 KHR。原始的类型、枚举和命令名称仍然可用作核心功能的别名。

新结构

新枚举常量

  • VK_EXT_DEPTH_CLAMP_ZERO_ONE_EXTENSION_NAME

  • VK_EXT_DEPTH_CLAMP_ZERO_ONE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLAMP_ZERO_ONE_FEATURES_EXT

版本历史

  • 版本 1, 2021-07-29 (Graeme Leese)

    • 内部修订

VK_EXT_descriptor_indexing

名称字符串

VK_EXT_descriptor_indexing

扩展类型

设备扩展

注册扩展号

162

修订

2

批准状态

已批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
     和
     VK_KHR_maintenance3
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-10-02

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

  • Daniel Rakos, AMD

  • Slawomir Grajewski, Intel

  • Tobias Hector, Imagination Technologies

描述

此扩展添加了几个小的功能，这些功能共同使应用程序能够创建包含其基本上所有资源的大型描述符集，并在着色器中使用动态（非统一）索引在这些资源中进行选择。着色器中存在用于非统一描述符索引的功能启用和 SPIR-V 功能，并且着色器中的非统一索引需要使用在 SPV_EXT_descriptor_indexing SPIR-V 扩展中定义的新 NonUniformEXT 修饰符。存在启用几个功能的描述符集布局绑定创建标志

  • 可以在将描述符绑定到命令缓冲区后对其进行更新，以便命令缓冲区的执行反映描述符的最新更新。

  • 可以更新任何挂起的命令缓冲区未使用的描述符，这使得在执行帧 N 的同时可以为帧 N+1 写入新的描述符。

  • 放宽对“静态使用”的绑定中的所有描述符都必须有效的要求，以便不需要有效且可以在执行提交时更新未通过提交访问的描述符。

  • 描述符集布局中的最后一个绑定可以具有可变大小（并且在 GL_EXT_nonuniform_qualifier 和 SPV_EXT_descriptor_indexing 扩展中允许使用大小可变的资源数组）。

请注意，着色器中的多个描述符数组使用相同的集和绑定号是有效的，只要它们都与管道布局中的描述符类型兼容即可。这意味着描述符集中的单个数组绑定可以服务于多个纹理维度，或者可以将缓冲描述符数组与多个不同的块布局一起使用。

存在新的描述符集布局和描述符池创建标志，这些标志是选择加入绑定后更新功能所必需的，并且存在单独的 maxPerStage* 和 maxDescriptorSet* 限制，这些限制适用于这些描述符集布局，并且可能比以前的限制高得多。旧的限制仅计算非 updateAfterBind 描述符集布局中的描述符，而新的限制计算管道布局中所有描述符集布局中的描述符。

新结构

新枚举

新位掩码

新枚举常量

  • VK_EXT_DESCRIPTOR_INDEXING_EXTENSION_NAME

  • VK_EXT_DESCRIPTOR_INDEXING_SPEC_VERSION

  • 扩展 VkDescriptorBindingFlagBits

    • VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT_EXT

    • VK_DESCRIPTOR_BINDING_UPDATE_AFTER_BIND_BIT_EXT

    • VK_DESCRIPTOR_BINDING_UPDATE_UNUSED_WHILE_PENDING_BIT_EXT

    • VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT_EXT

  • 扩展 VkDescriptorPoolCreateFlagBits

    • VK_DESCRIPTOR_POOL_CREATE_UPDATE_AFTER_BIND_BIT_EXT

  • 扩展 VkDescriptorSetLayoutCreateFlagBits

    • VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT

  • 扩展 VkResult

    • VK_ERROR_FRAGMENTATION_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_BINDING_FLAGS_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_DESCRIPTOR_SET_VARIABLE_DESCRIPTOR_COUNT_ALLOCATE_INFO_EXT

    • VK_STRUCTURE_TYPE_DESCRIPTOR_SET_VARIABLE_DESCRIPTOR_COUNT_LAYOUT_SUPPORT_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_INDEXING_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_INDEXING_PROPERTIES_EXT

晋升到 Vulkan 1.2

此扩展中的 Vulkan API 已包含在核心 Vulkan 1.2 中，省略了 EXT 后缀。但是，如果支持 Vulkan 1.2 但不支持此扩展，则 descriptorIndexing 功能是可选的。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1, 2017-07-26 (Jeff Bolz)

    • 内部修订

  • 修订版 2, 2017-10-02 (Jeff Bolz)

    • ???

VK_EXT_extended_dynamic_state

名称字符串

VK_EXT_extended_dynamic_state

扩展类型

设备扩展

注册扩展号

268

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-12-09

IP 状态

没有已知的 IP 声明。

贡献者

  • Dan Ginsburg, Valve Corporation

  • Graeme Leese, Broadcom

  • Hans-Kristian Arntzen, Valve Corporation

  • Jan-Harald Fredriksen, Arm Limited

  • Faith Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Jesse Hall, Google

  • Philip Rebohle, Valve Corporation

  • Stuart Smith, Imagination Technologies

  • Tobias Hector, AMD

描述

此扩展添加了一些更动态的状态，以支持需要减少其编译和绑定管线状态对象的应用程序。

新命令

新结构

新枚举常量

  • VK_EXT_EXTENDED_DYNAMIC_STATE_EXTENSION_NAME

  • VK_EXT_EXTENDED_DYNAMIC_STATE_SPEC_VERSION

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_CULL_MODE_EXT

    • VK_DYNAMIC_STATE_DEPTH_BOUNDS_TEST_ENABLE_EXT

    • VK_DYNAMIC_STATE_DEPTH_COMPARE_OP_EXT

    • VK_DYNAMIC_STATE_DEPTH_TEST_ENABLE_EXT

    • VK_DYNAMIC_STATE_DEPTH_WRITE_ENABLE_EXT

    • VK_DYNAMIC_STATE_FRONT_FACE_EXT

    • VK_DYNAMIC_STATE_PRIMITIVE_TOPOLOGY_EXT

    • VK_DYNAMIC_STATE_SCISSOR_WITH_COUNT_EXT

    • VK_DYNAMIC_STATE_STENCIL_OP_EXT

    • VK_DYNAMIC_STATE_STENCIL_TEST_ENABLE_EXT

    • VK_DYNAMIC_STATE_VERTEX_INPUT_BINDING_STRIDE_EXT

    • VK_DYNAMIC_STATE_VIEWPORT_WITH_COUNT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_FEATURES_EXT

晋升到 Vulkan 1.3

此扩展中的所有动态状态枚举和命令都包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。功能结构未晋升。已晋升的扩展接口仍然可用作核心功能的别名。

问题

1) 当相同的静态状态不存在此限制时，为什么 vkCmdBindVertexBuffers2 中的 pStrides 值被限制在 0 和绑定的最大范围之间？

实现这些边缘情况会给某些实现增加开销，在调用此函数时会产生巨大的成本，并且目的是该状态应可以或多或少地自由更改。

VK_EXT_vertex_input_dynamic_state 允许在使用 vkCmdSetVertexInputEXT 支持时自由更改步幅。

版本历史

  • 修订版 1, 2019-12-09 (Piers Daniell)

    • 内部修订

VK_EXT_extended_dynamic_state2

名称字符串

VK_EXT_extended_dynamic_state2

扩展类型

设备扩展

注册扩展号

378

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2021-04-12

IP 状态

没有已知的 IP 声明。

贡献者

  • Vikram Kushwaha, NVIDIA

  • Piers Daniell, NVIDIA

  • Jeff Bolz, NVIDIA

描述

此扩展添加了一些更动态的状态，以支持需要减少其编译和绑定管线状态对象的应用程序。

新命令

新结构

新枚举常量

  • VK_EXT_EXTENDED_DYNAMIC_STATE_2_EXTENSION_NAME

  • VK_EXT_EXTENDED_DYNAMIC_STATE_2_SPEC_VERSION

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_DEPTH_BIAS_ENABLE_EXT

    • VK_DYNAMIC_STATE_LOGIC_OP_EXT

    • VK_DYNAMIC_STATE_PATCH_CONTROL_POINTS_EXT

    • VK_DYNAMIC_STATE_PRIMITIVE_RESTART_ENABLE_EXT

    • VK_DYNAMIC_STATE_RASTERIZER_DISCARD_ENABLE_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_2_FEATURES_EXT

晋升到 Vulkan 1.3

此扩展中的动态状态枚举 VK_DYNAMIC_STATE_DEPTH_BIAS_ENABLE_EXT、VK_DYNAMIC_STATE_PRIMITIVE_RESTART_ENABLE_EXT 和 VK_DYNAMIC_STATE_RASTERIZER_DISCARD_ENABLE_EXT；以及相应的命令都包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。动态逻辑操作和补丁控制点的枚举和命令未晋升，功能结构也未晋升。已晋升的扩展接口仍然可用作核心功能的别名。

版本历史

  • 修订版 1, 2021-04-12 (Vikram Kushwaha)

    • 内部修订

VK_EXT_global_priority

名称字符串

VK_EXT_global_priority

扩展类型

设备扩展

注册扩展号

175

修订

2

批准状态

未批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-10-06

IP 状态

没有已知的 IP 声明。

贡献者

  • Andres Rodriguez, Valve

  • Pierre-Loup Griffais, Valve

  • Dan Ginsburg, Valve

  • Mitch Singer, AMD

描述

在 Vulkan 中，用户可以指定设备范围的队列优先级。在某些情况下，将此概念扩展到系统范围可能很有用。此扩展为调用者提供了一种设置其系统范围优先级的机制。默认队列优先级为 VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT。

驱动程序实现将尝试偏向硬件资源分配以支持更高优先级的任务。因此，即使系统拥塞了较低优先级的工作，更高优先级的工作也可能保持相似的延迟和吞吐量特性。

队列的全局优先级应优先于每个进程的队列优先级（VkDeviceQueueCreateInfo::pQueuePriorities）。

滥用此特性可能会导致系统中其余部分缺乏硬件资源。因此，如果调用者没有足够的权限，驱动程序实现可能会拒绝获取高于默认优先级（VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT）的优先级请求。在这种情况下，会返回 VK_ERROR_NOT_PERMITTED_EXT。

如果完成操作所需的资源已耗尽（由同一进程或不同进程），驱动程序实现可能会使队列分配请求失败。在这种情况下，会返回 VK_ERROR_INITIALIZATION_FAILED。

新结构

新枚举

新枚举常量

  • VK_EXT_GLOBAL_PRIORITY_EXTENSION_NAME

  • VK_EXT_GLOBAL_PRIORITY_SPEC_VERSION

  • 扩展 VkQueueGlobalPriority

    • VK_QUEUE_GLOBAL_PRIORITY_HIGH_EXT

    • VK_QUEUE_GLOBAL_PRIORITY_LOW_EXT

    • VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT

    • VK_QUEUE_GLOBAL_PRIORITY_REALTIME_EXT

  • 扩展 VkResult

    • VK_ERROR_NOT_PERMITTED_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_QUEUE_GLOBAL_PRIORITY_CREATE_INFO_EXT

版本历史

  • 修订版 2, 2017-11-03 (Andres Rodriguez)

    • 修复了 VkQueueGlobalPriorityEXT 缺少 _EXT 后缀的问题

  • 修订版 1, 2017-10-06 (Andres Rodriguez)

    • 第一个版本。

VK_EXT_global_priority_query

名称字符串

VK_EXT_global_priority_query

扩展类型

设备扩展

注册扩展号

389

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_EXT_global_priority
和
     VK_KHR_get_physical_device_properties2
    或
     Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2021-03-29

IP 状态

没有已知的 IP 声明。

贡献者

  • Yiwei Zhang, Google

描述

此设备扩展允许应用程序查询队列族支持的全局队列优先级。它允许实现报告哪些全局优先级级别被实现区别对待，而不是默默地将多个请求的全局优先级级别映射到相同的内部优先级，或使用设备创建失败来表示不支持请求的优先级。它主要用于系统集成以及某些特定于平台的优先级强制规则。

新结构

新枚举常量

  • VK_EXT_GLOBAL_PRIORITY_QUERY_EXTENSION_NAME

  • VK_EXT_GLOBAL_PRIORITY_QUERY_SPEC_VERSION

  • VK_MAX_GLOBAL_PRIORITY_SIZE_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GLOBAL_PRIORITY_QUERY_FEATURES_EXT

    • VK_STRUCTURE_TYPE_QUEUE_FAMILY_GLOBAL_PRIORITY_PROPERTIES_EXT

问题

1) 我们是否可以在此扩展中额外查询调用者是否被允许获取特定的全局队列优先级？

已解决：否。调用者是否具有足够的权限取决于操作系统，Vulkan 驱动程序无法真正保证该权限在本次查询和实际队列创建调用之间不会发生变化。

2) 如果请求使用全局优先级的多个队列，是否有好的方法来知道哪个队列在设备创建时失败？

已解决：否。目前没有好的方法，并且对于应用程序来说，知道这一点也不是很有用，因为该信息可能不准确。队列创建可能会因运行时约束（如权限不足或资源不足）而失败，并且失败不一定与请求的特定队列配置相关。

版本历史

  • 修订版 1，2021-03-29 (张毅伟)

VK_EXT_host_image_copy

名称字符串

VK_EXT_host_image_copy

扩展类型

设备扩展

注册扩展号

271

修订

1

批准状态

已批准

扩展和版本依赖关系

         VK_KHR_get_physical_device_properties2
         或
         Vulkan 版本 1.1
     和
     VK_KHR_copy_commands2
     和
     VK_KHR_format_feature_flags2
或
Vulkan 版本 1.3

弃用状态
联系方式
扩展提案

VK_EXT_host_image_copy

其他扩展元数据

上次修改日期

2023-04-26

贡献者

  • Shahbaz Youssefi, Google

  • Faith Ekstrand, Collabora

  • Hans-Kristian Arntzen, Valve

  • Piers Daniell, NVIDIA

  • Jan-Harald Fredriksen, Arm

  • James Fitzpatrick，Imagination

  • Daniel Story, Nintendo

描述

此扩展允许应用程序在主机内存和主机处理器上的图像之间复制数据，而无需通过 GPU 可访问的缓冲区暂存数据。这消除了分配和管理缓冲区及其关联内存的需要。在某些架构上，它还可以消除额外的复制操作。此扩展还允许应用程序在主机上的图像之间复制数据。

为了支持初始化新图像以准备进行主机复制，现在可以通过vkTransitionImageLayoutEXT将新图像转换为 VK_IMAGE_LAYOUT_GENERAL 或其他可主机复制的布局。此外，可以通过使用 VK_HOST_IMAGE_COPY_MEMCPY_EXT 标志来执行保留图像的交换布局的复制。在这种情况下，通过将VkSubresourceHostMemcpySizeEXT链接到vkGetImageSubresourceLayout2EXT中的 pLayout，可以检索从缓冲区复制或复制到缓冲区所需的内存大小。

新命令

新结构

新枚举

新位掩码

新枚举常量

  • VK_EXT_HOST_IMAGE_COPY_EXTENSION_NAME

  • VK_EXT_HOST_IMAGE_COPY_SPEC_VERSION

  • 扩展 VkFormatFeatureFlagBits2

    • VK_FORMAT_FEATURE_2_HOST_IMAGE_TRANSFER_BIT_EXT

  • 扩展VkHostImageCopyFlagBits

    • VK_HOST_IMAGE_COPY_MEMCPY_EXT

  • 扩展 VkImageUsageFlagBits

    • VK_IMAGE_USAGE_HOST_TRANSFER_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_COPY_IMAGE_TO_IMAGE_INFO_EXT

    • VK_STRUCTURE_TYPE_COPY_IMAGE_TO_MEMORY_INFO_EXT

    • VK_STRUCTURE_TYPE_COPY_MEMORY_TO_IMAGE_INFO_EXT

    • VK_STRUCTURE_TYPE_HOST_IMAGE_COPY_DEVICE_PERFORMANCE_QUERY_EXT

    • VK_STRUCTURE_TYPE_HOST_IMAGE_LAYOUT_TRANSITION_INFO_EXT

    • VK_STRUCTURE_TYPE_IMAGE_TO_MEMORY_COPY_EXT

    • VK_STRUCTURE_TYPE_MEMORY_TO_IMAGE_COPY_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HOST_IMAGE_COPY_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HOST_IMAGE_COPY_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_SUBRESOURCE_HOST_MEMCPY_SIZE_EXT

晋升至 Vulkan 1.4

此扩展中的功能包含在核心 Vulkan 1.4 中，省略了 EXT 后缀。但是，该功能在 Vulkan 1.4 中是可选的。原始类型、枚举和命令名称仍然可用作核心功能的别名。

具有 VK_QUEUE_GRAPHICS_BIT 队列的 Vulkan 1.4 实现必须支持以下之一

  • hostImageCopy 功能；或

  • 支持 VK_QUEUE_TRANSFER_BIT 的其他队列。

此外，所有支持 VK_QUEUE_GRAPHICS_BIT 或 VK_QUEUE_COMPUTE_BIT 的队列还必须公布 VK_QUEUE_TRANSFER_BIT。

问题

1) 在将数据上传到图像时，数据通常是从磁盘加载的。为什么不让应用程序将数据直接加载到绑定到缓冲区的 VkDeviceMemory 中（而不是主机内存），并使用 vkCmdCopyBufferToImage？从图像下载数据时也可以这样做。

已解决：这可能并非总是可行。像游戏引擎这样复杂的 Vulkan 应用程序通常具有用于流式传输数据和渲染的解耦子系统。要求流式传输子系统与渲染子系统协调以代表其分配内存可能是不合理的，尤其是在 Vulkan 可能不是引擎支持的唯一 API 时。在模拟层中，图像数据必须由应用程序在主机内存中提供，因此无法进行建议的优化。最重要的是，设备内存可能无法被应用程序映射，但仍然可以被驱动程序访问。

2) optimalBufferCopyOffsetAlignment 和 optimalBufferCopyRowPitchAlignment 是否也适用于此扩展引入的函数的主机内存？或者是否应该有新的限制？

已解决：主机内存指针没有对齐要求。

3) 图像偏移和范围是否应该有粒度要求？

已解决：没有粒度要求，即假设粒度为 1 像素（对于非压缩格式）和 1 纹素块（对于压缩格式）。

4) 应用程序应如何在复制到图像或从图像复制之前或之后处理布局转换？

已解决：线性图像的现有问题是，在模拟其他 API 时，无法知道何时转换它们，因为它们是由主机写入的，然后无绑定地使用。此扩展中的复制操作也受到相同的限制的影响。因此，此扩展引入了一个新命令来解决此问题，允许主机在少数布局之间执行图像布局转换。

版本历史

  • 修订版 0，2021-01-20 (Faith Ekstrand)

    • 初始想法和 xml

  • 修订版 1，2023-04-26 (Shahbaz Youssefi)

    • 初始修订版

VK_EXT_host_query_reset

名称字符串

VK_EXT_host_query_reset

扩展类型

设备扩展

注册扩展号

262

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-03-06

IP 状态

没有已知的 IP 声明。

贡献者

  • Bas Nieuwenhuizen, Google

  • Faith Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Piers Daniell, NVIDIA

描述

此扩展添加了一个新函数，用于从主机重置查询。

晋升至 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 EXT 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新命令

新结构体

新枚举常量

  • VK_EXT_HOST_QUERY_RESET_EXTENSION_NAME

  • VK_EXT_HOST_QUERY_RESET_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HOST_QUERY_RESET_FEATURES_EXT

版本历史

  • 修订版 1，2019-03-12 (Bas Nieuwenhuizen)

    • 初始草案

VK_EXT_image_robustness

名称字符串

VK_EXT_image_robustness

扩展类型

设备扩展

注册扩展号

336

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2020-04-27

IP 状态

没有已知的 IP 声明。

贡献者

  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, ARM

  • Jeff Bolz, NVIDIA

  • Spencer Fricke, Samsung

  • Courtney Goeltzenleuchter, Google

  • Slawomir Cygan，英特尔

描述

此扩展对如何处理图像越界读取添加了更严格的要求。大多数越界读取不再返回未定义的值，而是返回 R、G 和 B 值为零，alpha 值要么为零，要么为一。图像格式中不存在的组件可以设置为零，也可以设置为基于 转换为 RGBA 中描述的格式的值。

新结构体

新枚举常量

  • VK_EXT_IMAGE_ROBUSTNESS_EXTENSION_NAME

  • VK_EXT_IMAGE_ROBUSTNESS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_ROBUSTNESS_FEATURES_EXT

晋升至 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍然可用作核心功能的别名。

问题

  1. 此扩展与 VK_EXT_robustness2 有何不同？

此扩展提供的保证是 VK_EXT_robustness2 的 robustImageAccess2 功能提供的保证的子集。此扩展允许返回 (0, 0, 0, 0) 或 (0, 0, 0, 1) 的值，而 robustImageAccess2 要求返回依赖于图像格式的特定值。此扩展不保证访问无效 Lod 时返回的值。

示例

无。

版本历史

  • 修订版 1，2020-04-27 (Graeme Leese)

  • 初始草案

VK_EXT_index_type_uint8

名称字符串

VK_EXT_index_type_uint8

扩展类型

设备扩展

注册扩展号

266

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-05-02

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展允许将 uint8_t 索引与 vkCmdBindIndexBuffer 一起使用。

晋升至 VK_KHR_index_type_uint8

此扩展中的所有功能都包含在 VK_KHR_index_type_uint8 中，后缀更改为 KHR。原始枚举名称仍然可用作 KHR 功能的别名。

新结构体

新枚举常量

  • VK_EXT_INDEX_TYPE_UINT8_EXTENSION_NAME

  • VK_EXT_INDEX_TYPE_UINT8_SPEC_VERSION

  • 扩展 VkIndexType

    • VK_INDEX_TYPE_UINT8_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INDEX_TYPE_UINT8_FEATURES_EXT

版本历史

  • 修订版 1，2019-05-02 (Piers Daniell)

    • 内部修订

VK_EXT_inline_uniform_block

名称字符串

VK_EXT_inline_uniform_block

扩展类型

设备扩展

注册扩展号

139

修订

1

批准状态

未批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
     和
     VK_KHR_maintenance1
或
Vulkan 版本 1.1

API 交互

  • 与 VK_VERSION_1_2 交互

  • 与 VK_EXT_descriptor_indexing 交互

  • 与 VkPhysicalDeviceVulkan12Features::descriptorIndexing 交互

弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-08-01

IP 状态

没有已知的 IP 声明。

贡献者

  • Daniel Rakos, AMD

  • Jeff Bolz, NVIDIA

  • Slawomir Grajewski, Intel

  • Neil Henning, Codeplay

描述

此扩展引入了通过在描述符池存储中存储内联统一数据，直接使用描述符集来支持统一块的功能。与推送常量相比，这种新结构允许在多个不相交的绘制或调度命令集中重用统一数据，并且可能允许使用比缓冲内存支持的统一变量更少的间接访问来访问统一数据。

新结构体

新枚举常量

  • VK_EXT_INLINE_UNIFORM_BLOCK_EXTENSION_NAME

  • VK_EXT_INLINE_UNIFORM_BLOCK_SPEC_VERSION

  • 扩展 VkDescriptorType

    • VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_INLINE_UNIFORM_BLOCK_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT

晋升至 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍然可用作核心功能的别名。

Vulkan 1.3 以 maxInlineUniformTotalSize 限制的形式添加了与此扩展相关的附加功能。

问题

1) 我们是否需要为内联统一块与统一块添加新的存储类？

已解决：否。Uniform 存储类用于允许用于统一缓冲区和内联统一块的相同语法。

2) 内联统一块描述符的描述符数组索引和数组大小是以字节还是以双字表示？

已解决：以字节为单位，但两者必须是 4 的倍数，类似于指定推送常量范围的方式。VkDescriptorSetLayoutBinding 的 descriptorCount 因此提供了具有内联统一块描述符类型的特定绑定可以容纳的字节总数，而 VkWriteDescriptorSet、VkCopyDescriptorSet 和 VkDescriptorUpdateTemplateEntry 的 srcArrayElement、dstArrayElement 和 descriptorCount 成员（如果适用）指定要写入/复制到绑定后备存储的字节偏移量和字节数。此外，VkDescriptorUpdateTemplateEntry 的 stride 成员对于内联统一块会被忽略，并且使用默认值 1，这意味着用于更新内联统一块绑定的数据在内存中必须是连续的。

3) 对应于内联常量的统一块应用哪些布局规则？

已解决：它们使用与统一缓冲区相同的布局规则。

4) 我们是否需要为内联统一块添加 VK_EXT_descriptor_indexing 引入的非统一索引功能/属性？

已解决：否，因为内联统一缓冲区不允许“数组化”。具有内联统一缓冲区描述符类型的单个绑定对应于单个统一缓冲区实例，并且该绑定内的数组索引引用统一缓冲区内的各个偏移量（请参阅问题 #2）。但是，此扩展引入了关于更新后绑定内联统一缓冲区的支持级别的新特性/属性。

5) VK_EXT_descriptor_indexing 引入的 descriptorBindingVariableDescriptorCount 特性是否支持内联统一缓冲区？

已解决：是的，只要遵守其他内联统一缓冲区特定的限制即可。

6) robustBufferAccess 的鲁棒性保证是否适用于内联统一缓冲区访问？

已解决：否，与推送常量类似，因为它们不像统一缓冲区那样由缓冲区内存支持。

版本历史

  • 修订版 1，2018-08-01 (Daniel Rakos)

    • 内部修订

VK_EXT_line_rasterization

名称字符串

VK_EXT_line_rasterization

扩展类型

设备扩展

注册扩展号

260

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
特殊用途
联系方式

其他扩展元数据

上次修改日期

2019-05-09

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

  • Allen Jensen，NVIDIA

  • Faith Ekstrand, Intel

描述

此扩展添加了一些在 CAD 应用程序中常用并在其他 API（如 OpenGL）中支持的线光栅化功能。支持 Bresenham 风格的线光栅化，支持平滑的矩形线（覆盖到 alpha），并且对于所有三种线光栅化模式都支持虚线。

提升至 VK_KHR_line_rasterization

此扩展中的所有功能都包含在 VK_KHR_line_rasterization 中，后缀更改为 KHR。原始枚举名称仍然可用作 KHR 功能的别名。

新命令

新结构体

新枚举

新枚举常量

  • VK_EXT_LINE_RASTERIZATION_EXTENSION_NAME

  • VK_EXT_LINE_RASTERIZATION_SPEC_VERSION

  • 扩展 VkDynamicState

    • VK_DYNAMIC_STATE_LINE_STIPPLE_EXT

  • 扩展 VkLineRasterizationMode

    • VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT

    • VK_LINE_RASTERIZATION_MODE_DEFAULT_EXT

    • VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT

    • VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINE_RASTERIZATION_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINE_RASTERIZATION_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_LINE_STATE_CREATE_INFO_EXT

问题

1) 我们是否需要支持具有多个光栅化采样的 Bresenham 风格和平滑线？即，当帧缓冲区具有多个采样时，相当于 OpenGL 中的 glDisable(GL_MULTISAMPLE)？

已解决：是的。为了简单起见，Bresenham 直线光栅化沿用了 OpenGL 的一些限制，例如不支持逐采样着色、alpha 到覆盖或 alpha 到一。

版本历史

  • 修订版 1，2019-05-09 (Jeff Bolz)

    • 初始草案

VK_EXT_load_store_op_none

名称字符串

VK_EXT_load_store_op_none

扩展类型

设备扩展

注册扩展号

401

修订

1

批准状态

已批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2021-06-06

贡献者

  • Shahbaz Youssefi, Google

  • Bill Licea-Kane，高通技术公司。

  • Tobias Hector, AMD

描述

此扩展合并了来自 VK_QCOM_render_pass_store_ops 的 VK_ATTACHMENT_STORE_OP_NONE_EXT，使应用程序能够在渲染过程中未写入附件时避免不必要的同步。

此外，引入了 VK_ATTACHMENT_LOAD_OP_NONE_EXT 以避免在渲染过程中根本不使用附件时进行不必要的同步。与 VK_ATTACHMENT_STORE_OP_NONE_EXT 结合使用，这对于在无法在创建必要的管线之前确定是否在渲染过程中使用附件的应用程序中，作为保留附件的替代方法非常有用。

提升至 VK_KHR_load_store_op_none

此扩展中的所有功能都包含在 VK_KHR_load_store_op_none 中，后缀更改为 KHR。原始枚举名称仍然可用作 KHR 功能的别名。

新枚举常量

  • VK_EXT_LOAD_STORE_OP_NONE_EXTENSION_NAME

  • VK_EXT_LOAD_STORE_OP_NONE_SPEC_VERSION

  • 扩展 VkAttachmentLoadOp

    • VK_ATTACHMENT_LOAD_OP_NONE_EXT

  • 扩展 VkAttachmentStoreOp

    • VK_ATTACHMENT_STORE_OP_NONE_EXT

虽然 VK_ATTACHMENT_STORE_OP_NONE 是 Vulkan 1.3 的一部分，但此扩展未整体或部分提升为核心。此功能是从 VK_KHR_dynamic_rendering 中提升而来的。

版本历史

  • 修订版 1，2021-06-06 (Shahbaz Youssefi)

    • 基于 VK_QCOM_render_pass_store_ops 的初始修订版。

    • 添加了 VK_ATTACHMENT_LOAD_OP_NONE_EXT。

VK_EXT_pipeline_creation_cache_control

名称字符串

VK_EXT_pipeline_creation_cache_control

扩展类型

设备扩展

注册扩展号

298

修订

3

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2020-03-23

IP 状态

没有已知的 IP 声明。

贡献者

  • Gregory Grebe，AMD

  • Tobias Hector, AMD

  • Matthaeus Chajdas, AMD

  • Mitch Singer, AMD

  • Spencer Fricke, Samsung Electronics

  • Stuart Smith, Imagination Technologies

  • Jeff Bolz，NVIDIA Corporation

  • Daniel Koch, NVIDIA Corporation

  • Dan Ginsburg, Valve Corporation

  • Jeff Leger, QUALCOMM

  • Michal Pietrasiuk，Intel

  • Jan-Harald Fredriksen, Arm Limited

描述

此扩展向 Vk*PipelineCreateInfo 和 VkPipelineCacheCreateInfo 结构体添加了标志，旨在提高管线创建成本的可预测性。目标是在执行管线创建期间，在客户端驱动程序中，将有关潜在的高成本风险的信息在执行之前而不是之后提供给应用程序。

背景

管线创建是一个代价高昂的操作，Vulkan 设计的显式性质意味着该成本不会对开发者隐藏。还希望应用程序调度、确定优先级和负载平衡所有管线创建的调用。强烈建议应用程序在其使用之前充分创建管线。否则将导致应用程序无响应、间歇性卡顿或其他不良用户体验。正确使用管线缓存和/或派生管线有助于缓解这种情况，但不能保证在所有情况下都能消除中断。如果无法提前创建，则应考虑确保当前执行上下文适合管线创建（包括可能的着色器编译）的工作负载。

调用 API 创建管线的应用程序必须为以下任何一种情况做好准备

  • 由 ICD 发出的 OS/内核调用

  • 未被传递给 vkCreate*Pipelines 的 pAllocator 跟踪的内部内存分配

  • 内部线程同步或当前线程核心的让步

  • 非常长（多毫秒以上）、阻塞的编译时间

  • 任意的调用堆栈深度和堆栈内存使用

正在开发的基于作业或任务的游戏引擎，旨在利用诸如 Vulkan 之类的显式图形 API，如果发生上述任何情况，可能会表现得非常糟糕。但是，大多数游戏引擎已经构建为在用户玩游戏时动态“流式传输”资源。通过以 VkPipelineCreateFlags 的方式添加控制，我们可以要求 ICD 在关键执行路径中报告失败，而不是强制进行意外等待。

应用程序可以通过在 Vk*PipelineCreateInfo::flags 上设置 VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT_EXT 来防止意外编译。设置后，ICD 不得尝试进行管线或着色器编译来创建管线对象。在这种情况下，如果实现无法在不进行编译的情况下创建管线，则实现必须返回结果 VK_PIPELINE_COMPILE_REQUIRED_EXT 并为管线返回 VK_NULL_HANDLE。

默认情况下，vkCreate*Pipelines 调用必须尝试创建所有管线，然后才能返回。在 Vk*PipelineCreateInfo::flags 上设置 VK_PIPELINE_CREATE_EARLY_RETURN_ON_FAILURE_BIT_EXT 可以用作批量管线创建的逃生舱。

隐藏的锁也会增加管线创建成本的不可预测性。vkCreate*Pipelines 中最常见的锁情况是 VkPipelineCache 对象的内部同步。调用 vkCreatePipelineCache 时可以设置 VK_PIPELINE_CACHE_CREATE_EXTERNALLY_SYNCHRONIZED_BIT_EXT，以声明缓存是外部同步的。

希望有了这些信息，应用程序和引擎开发人员可以利用现有的资源流式传输系统，从“即时”管线创建停顿中恢复。

新结构

新枚举

新枚举常量

  • VK_EXT_PIPELINE_CREATION_CACHE_CONTROL_EXTENSION_NAME

  • VK_EXT_PIPELINE_CREATION_CACHE_CONTROL_SPEC_VERSION

  • 扩展 VkPipelineCacheCreateFlagBits

    • VK_PIPELINE_CACHE_CREATE_EXTERNALLY_SYNCHRONIZED_BIT_EXT

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_EARLY_RETURN_ON_FAILURE_BIT_EXT

    • VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT_EXT

  • 扩展 VkResult

    • VK_ERROR_PIPELINE_COMPILE_REQUIRED_EXT

    • VK_PIPELINE_COMPILE_REQUIRED_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_CREATION_CACHE_CONTROL_FEATURES_EXT

晋升至 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1，2019-11-01 (Gregory Grebe)

    • 初始修订版

  • 修订版 2，2020-02-24 (Gregory Grebe)

    • 初始公开修订版

  • 修订版 3，2020-03-23 (Tobias Hector)

    • 将 VK_PIPELINE_COMPILE_REQUIRED_EXT 更改为成功代码，为原始的 VK_ERROR_PIPELINE_COMPILE_REQUIRED_EXT 添加了别名。还更新了 XML，以将这些代码作为返回值包含在内。

VK_EXT_pipeline_creation_feedback

名称字符串

VK_EXT_pipeline_creation_feedback

扩展类型

设备扩展

注册扩展号

193

修订

1

批准状态

未批准

扩展和版本依赖关系

无

弃用状态
特殊用途
联系方式

  • Jean-Francois Roy jfroy

其他扩展元数据

上次修改日期

2019-03-12

IP 状态

没有已知的 IP 声明。

贡献者

  • Jean-Francois Roy, Google

  • Hai Nguyen, Google

  • Andrew Ellem, Google

  • Bob Fraser, Google

  • Sujeevan Rajayogam, Google

  • Jan-Harald Fredriksen, ARM

  • Jeff Leger，高通技术公司

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

  • Neil Henning, AMD

描述

此扩展添加了一种机制，向应用程序提供有关管线创建的反馈，其具体目标是允许构建系统和现场应用程序执行之间建立反馈循环，以确保将有效的管线缓存交付给客户。

新结构

新枚举

新位掩码

新枚举常量

  • VK_EXT_PIPELINE_CREATION_FEEDBACK_EXTENSION_NAME

  • VK_EXT_PIPELINE_CREATION_FEEDBACK_SPEC_VERSION

  • 扩展 VkPipelineCreationFeedbackFlagBits

    • VK_PIPELINE_CREATION_FEEDBACK_APPLICATION_PIPELINE_CACHE_HIT_BIT_EXT

    • VK_PIPELINE_CREATION_FEEDBACK_BASE_PIPELINE_ACCELERATION_BIT_EXT

    • VK_PIPELINE_CREATION_FEEDBACK_VALID_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PIPELINE_CREATION_FEEDBACK_CREATE_INFO_EXT

晋升至 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1，2019-03-12 (Jean-Francois Roy)

    • 初始修订版

VK_EXT_pipeline_protected_access

名称字符串

VK_EXT_pipeline_protected_access

扩展类型

设备扩展

注册扩展号

467

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式
扩展提案

VK_EXT_pipeline_protected_access

其他扩展元数据

上次修改日期

2022-07-28

贡献者

  • Shahbaz Youssefi, Google

  • Jörg Wagner，Arm

  • Ralph Potter, Samsung

  • Daniel Koch, NVIDIA

描述

此扩展允许为每个管线而不是每个设备指定受保护的内存访问。通过使用此扩展，由于访问受保护的内存而产生的任何性能损失将仅限于进行此类访问的特定管线。

新结构

新枚举常量

  • VK_EXT_PIPELINE_PROTECTED_ACCESS_EXTENSION_NAME

  • VK_EXT_PIPELINE_PROTECTED_ACCESS_SPEC_VERSION

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_NO_PROTECTED_ACCESS_BIT_EXT

    • VK_PIPELINE_CREATE_PROTECTED_ACCESS_ONLY_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_PROTECTED_ACCESS_FEATURES_EXT

晋升至 Vulkan 1.4

此扩展中的功能包含在核心 Vulkan 1.4 中，省略了 EXT 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1，2022-07-28 (Shahbaz Youssefi)

    • 内部修订

VK_EXT_pipeline_robustness

名称字符串

VK_EXT_pipeline_robustness

扩展类型

设备扩展

注册扩展号

69

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

  • Jarred Davies

其他扩展元数据

上次修改日期

2022-07-12

交互和外部依赖
贡献者

  • Jarred Davies，Imagination Technologies

  • Alex Walters, Imagination Technologies

  • Piers Daniell, NVIDIA

  • Graeme Leese，博通公司

  • Jeff Leger，高通技术公司

  • Faith Ekstrand, Intel

  • Lionel Landwerlin, Intel

  • Shahbaz Youssefi，Google, Inc.

描述

此扩展允许用户根据每个管线阶段请求鲁棒性。

由于 robustBufferAccess 和其他鲁棒性功能可能会对性能产生不利影响，因此此扩展旨在允许用户仅在可能需要时请求鲁棒行为。

新结构

新枚举

新枚举常量

  • VK_EXT_PIPELINE_ROBUSTNESS_EXTENSION_NAME

  • VK_EXT_PIPELINE_ROBUSTNESS_SPEC_VERSION

  • 扩展 VkPipelineRobustnessBufferBehavior

    • VK_PIPELINE_ROBUSTNESS_BUFFER_BEHAVIOR_DEVICE_DEFAULT_EXT

    • VK_PIPELINE_ROBUSTNESS_BUFFER_BEHAVIOR_DISABLED_EXT

    • VK_PIPELINE_ROBUSTNESS_BUFFER_BEHAVIOR_ROBUST_BUFFER_ACCESS_2_EXT

    • VK_PIPELINE_ROBUSTNESS_BUFFER_BEHAVIOR_ROBUST_BUFFER_ACCESS_EXT

  • 扩展 VkPipelineRobustnessImageBehavior

    • VK_PIPELINE_ROBUSTNESS_IMAGE_BEHAVIOR_DEVICE_DEFAULT_EXT

    • VK_PIPELINE_ROBUSTNESS_IMAGE_BEHAVIOR_DISABLED_EXT

    • VK_PIPELINE_ROBUSTNESS_IMAGE_BEHAVIOR_ROBUST_IMAGE_ACCESS_2_EXT

    • VK_PIPELINE_ROBUSTNESS_IMAGE_BEHAVIOR_ROBUST_IMAGE_ACCESS_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_ROBUSTNESS_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_ROBUSTNESS_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_ROBUSTNESS_CREATE_INFO_EXT

晋升至 Vulkan 1.4

此扩展中的功能包含在核心 Vulkan 1.4 中，省略了 EXT 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1，2022-07-12 (Jarred Davies)

    • 初始版本

VK_EXT_private_data

名称字符串

VK_EXT_private_data

扩展类型

设备扩展

注册扩展号

296

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2020-03-25

IP 状态

没有已知的 IP 声明。

贡献者

  • Matthew Rusch, NVIDIA

  • Nuno Subtil, NVIDIA

  • Piers Daniell, NVIDIA

  • Jeff Bolz, NVIDIA

描述

此扩展是一个设备扩展，允许将任意有效负载附加到 Vulkan 对象。它引入了私有数据槽的概念，作为存储应用程序定义的 64 位无符号整数数据的一种手段。私有数据槽可以在关联设备可用时随时创建或销毁。私有数据槽可以在设备创建时预留，并且将使用限制为预留的数量将允许该扩展表现出更好的性能特征。

新的对象类型

新的命令

新的结构体

新的位掩码

新的枚举常量

  • VK_EXT_PRIVATE_DATA_EXTENSION_NAME

  • VK_EXT_PRIVATE_DATA_SPEC_VERSION

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_PRIVATE_DATA_SLOT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEVICE_PRIVATE_DATA_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRIVATE_DATA_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PRIVATE_DATA_SLOT_CREATE_INFO_EXT

晋升到 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍然可用作核心功能的别名。

示例

  • 正在进行中

问题

(1) 如果我必须创建一个 VkPrivateDataSlot 来存储和检索对象上的数据，那么这个扩展如何帮助我？我是否不需要将 VkPrivateDataSlot 映射与每个对象一起存储，如果我这样做，我不如直接存储原始数据！

已解决： VkPrivateDataSlot 可以被认为是每个对象中保留的存储的不透明索引。也就是说，您可以将同一个 VkPrivateDataSlot 与每个对象一起用于特定信息。例如，如果一个层希望跟踪每个对象的信息，该层只需要为每个设备分配一个 VkPrivateDataSlot，它可以使用该私有数据槽用于设备的所有子对象。这允许多个层存储私有数据，而不会彼此和/或应用程序的私有数据冲突。

(2) 如果我需要存储每个对象超过 64 位的信息怎么办？

已解决： 您存储在每个对象上的数据可以是您自己分配的另一个对象或结构的指针。

版本历史

  • 修订版 1，2020-01-15（Matthew Rusch）

    • 初始草案

VK_EXT_sampler_filter_minmax

名称字符串

VK_EXT_sampler_filter_minmax

扩展类型

设备扩展

注册扩展号

131

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-05-19

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

  • Piers Daniell, NVIDIA

描述

在未扩展的 Vulkan 中，诸如 LINEAR 之类的缩小和放大过滤器允许采样的图像查找返回一个经过滤的纹素值，该值是通过计算所提供的纹理坐标附近的纹素集合的加权平均值生成的。

此扩展提供了一个新的采样器参数，允许应用程序通过计算通常平均的纹素的组件最小值 (MIN) 或最大值 (MAX) 来生成经过滤的纹素值。缩减模式与缩小和放大过滤器参数正交。过滤器参数用于标识用于生成最终过滤值的纹素集；缩减模式标识如何组合这些纹素。

晋升到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 EXT 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新的结构体

新的枚举

新的枚举常量

  • VK_EXT_SAMPLER_FILTER_MINMAX_EXTENSION_NAME

  • VK_EXT_SAMPLER_FILTER_MINMAX_SPEC_VERSION

  • 扩展 VkFormatFeatureFlagBits

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT

  • 扩展 VkSamplerReductionMode

    • VK_SAMPLER_REDUCTION_MODE_MAX_EXT

    • VK_SAMPLER_REDUCTION_MODE_MIN_EXT

    • VK_SAMPLER_REDUCTION_MODE_WEIGHTED_AVERAGE_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_FILTER_MINMAX_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_SAMPLER_REDUCTION_MODE_CREATE_INFO_EXT

版本历史

  • 修订版 2，2017-05-19（Piers Daniell）

    • 重命名为 EXT

  • 修订版 1，2017-03-25（Jeff Bolz）

    • 内部修订

VK_EXT_scalar_block_layout

名称字符串

VK_EXT_scalar_block_layout

扩展类型

设备扩展

注册扩展号

222

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-11-14

贡献者

  • Jeff Bolz

  • Jan-Harald Fredriksen

  • Graeme Leese

  • Faith Ekstrand

  • John Kessenich

描述

此扩展为 SPIR-V 块启用类似 C 的结构布局。它修改了统一缓冲区、存储缓冲区和推送常量的对齐规则，允许非标量类型仅根据其组件的大小进行对齐，而无需额外的要求。

晋升到 Vulkan 1.2

此扩展中的 Vulkan API 包含在核心 Vulkan 1.2 中，省略了 EXT 后缀。但是，如果支持 Vulkan 1.2 并且不支持此扩展，则 scalarBlockLayout 功能是可选的。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍然可用作核心功能的别名。

新的结构体

新的枚举常量

  • VK_EXT_SCALAR_BLOCK_LAYOUT_EXTENSION_NAME

  • VK_EXT_SCALAR_BLOCK_LAYOUT_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCALAR_BLOCK_LAYOUT_FEATURES_EXT

版本历史

  • 修订版 1，2018-11-14（Tobias Hector）

    • 初始草案

VK_EXT_separate_stencil_usage

名称字符串

VK_EXT_separate_stencil_usage

扩展类型

设备扩展

注册扩展号

247

修订

1

批准状态

未批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-11-08

IP 状态

没有已知的 IP 声明。

贡献者

  • Daniel Rakos, AMD

  • Jordan Logan，AMD

描述

此扩展允许在图像创建时为具有深度模板格式的图像的模板方面指定单独的使用标志。

晋升到 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中，省略了 EXT 后缀。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新结构

新枚举常量

  • VK_EXT_SEPARATE_STENCIL_USAGE_EXTENSION_NAME

  • VK_EXT_SEPARATE_STENCIL_USAGE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IMAGE_STENCIL_USAGE_CREATE_INFO_EXT

版本历史

  • 修订版 1，2018-11-08 (Daniel Rakos)

    • 内部修订。

VK_EXT_shader_demote_to_helper_invocation

名称字符串

VK_EXT_shader_demote_to_helper_invocation

扩展类型

设备扩展

注册扩展号

277

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-06-01

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展为 SPV_EXT_demote_to_helper_invocation SPIR-V 扩展添加了 Vulkan 支持。该 SPIR-V 扩展提供了一个新的指令 OpDemoteToHelperInvocationEXT，允许着色器将片段着色器调用“降级”为在其持续时间内表现得像助手调用。降级后的调用将不再有副作用，也不会输出到帧缓冲区，但仍保持活动状态，并且可以参与计算导数和 组操作。这更符合 HLSL 中的“discard”指令。

新结构

新枚举常量

  • VK_EXT_SHADER_DEMOTE_TO_HELPER_INVOCATION_EXTENSION_NAME

  • VK_EXT_SHADER_DEMOTE_TO_HELPER_INVOCATION_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_DEMOTE_TO_HELPER_INVOCATION_FEATURES_EXT

新 SPIR-V 功能

晋升到 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1，2019-06-01 (Jeff Bolz)

    • 初始草案

VK_EXT_shader_subgroup_ballot

名称字符串

VK_EXT_shader_subgroup_ballot

扩展类型

设备扩展

注册扩展号

65

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-11-28

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Jeff Bolz, NVIDIA

  • Neil Henning, Codeplay

  • Daniel Koch, NVIDIA Corporation

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

  • SPV_KHR_shader_ballot

此扩展提供了一组并行执行的调用，通过对调用值的组广播或对表示组中每个调用的谓词值的位数组的广播来执行有限形式的跨调用通信的能力。

此扩展在 Vulkan 中提供对多个附加内置着色器变量的访问

  • SubgroupEqMaskKHR，包含当前子组调用的子组掩码，

  • SubgroupGeMaskKHR，包含大于或等于当前调用的调用的子组掩码，

  • SubgroupGtMaskKHR，包含大于当前调用的调用的子组掩码，

  • SubgroupLeMaskKHR，包含小于或等于当前调用的调用的子组掩码，

  • SubgroupLtMaskKHR，包含小于当前调用的调用的子组掩码，

  • SubgroupLocalInvocationId，包含子组中调用的索引，以及

  • SubgroupSize，包含子组中调用的最大数量。

此外，此扩展提供对新的 SPIR-V 指令的访问

  • OpSubgroupBallotKHR,

  • OpSubgroupFirstInvocationKHR，以及

  • OpSubgroupReadInvocationKHR,

当使用基于 GLSL 源的着色器语言时，来自 GL_ARB_shader_ballot 的以下变量和着色器函数可以映射到这些 SPIR-V 内置修饰和指令

  • in uint64_t gl_SubGroupEqMaskARB; → SubgroupEqMaskKHR，

  • in uint64_t gl_SubGroupGeMaskARB; → SubgroupGeMaskKHR，

  • in uint64_t gl_SubGroupGtMaskARB; → SubgroupGtMaskKHR，

  • in uint64_t gl_SubGroupLeMaskARB; → SubgroupLeMaskKHR，

  • in uint64_t gl_SubGroupLtMaskARB; → SubgroupLtMaskKHR，

  • in uint gl_SubGroupInvocationARB; → SubgroupLocalInvocationId，

  • uniform uint gl_SubGroupSizeARB; → SubgroupSize，

  • ballotARB() → OpSubgroupBallotKHR，

  • readFirstInvocationARB() → OpSubgroupFirstInvocationKHR，以及

  • readInvocationARB() → OpSubgroupReadInvocationKHR。

由 Vulkan 1.2 弃用

此扩展中的大多数功能已被核心 Vulkan 1.1 子组操作所取代。但是，Vulkan 1.1 要求 OpGroupNonUniformBroadcast “Id” 是常量。此限制已在 Vulkan 1.2 中通过添加 subgroupBroadcastDynamicId 功能而删除。

新枚举常量

  • VK_EXT_SHADER_SUBGROUP_BALLOT_EXTENSION_NAME

  • VK_EXT_SHADER_SUBGROUP_BALLOT_SPEC_VERSION

新的内置变量

新的 SPIR-V 功能

版本历史

  • 修订版 1，2016-11-28 (Daniel Koch)

    • 初始草案

VK_EXT_shader_subgroup_vote

名称字符串

VK_EXT_shader_subgroup_vote

扩展类型

设备扩展

注册扩展号

66

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-11-28

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Neil Henning, Codeplay

  • Daniel Koch, NVIDIA Corporation

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

  • SPV_KHR_subgroup_vote

此扩展提供新的 SPIR-V 指令

  • OpSubgroupAllKHR,

  • OpSubgroupAnyKHR，以及

  • OpSubgroupAllEqualKHR.

以计算一组并行运行的着色器调用（子组）中的一组布尔条件的组合。这些组合结果可用于在 VkPhysicalDevice 上更有效地执行着色器。

当使用基于 GLSL 源的着色器语言时，来自 GL_ARB_shader_group_vote 的以下着色器函数可以映射到这些 SPIR-V 指令

  • anyInvocationARB() → OpSubgroupAnyKHR，

  • allInvocationsARB() → OpSubgroupAllKHR，以及

  • allInvocationsEqualARB() → OpSubgroupAllEqualKHR。

计算布尔条件的子组是与实现相关的，此扩展不保证单个着色器调用如何分配到子组。特别是，子组与计算着色器的本地工作组没有必然的联系——计算本地工作组中的任何一对着色器调用都可能在这些指令使用的不同子组中执行。

计算着色器在显式指定的一组线程（本地工作组）上运行，但许多实现也会将非计算着色器调用分组并并发执行。当执行如下代码时：

if (condition) {
  result = do_fast_path();
} else {
  result = do_general_path();
}

其中 condition 在调用之间发散，一种实现可能会首先为 condition 为 true 的调用执行 do_fast_path()，并使其他调用休眠。一旦 do_fast_path() 返回，它可能会为 condition 为 false 的调用调用 do_general_path()，并使其他调用休眠。在这种情况下，着色器会执行快速路径和通用路径两者，最好只对所有调用使用通用路径。

此扩展提供了通过使用如下代码跨整个子组评估条件来避免发散执行的能力：

if (allInvocationsARB(condition)) {
  result = do_fast_path();
} else {
  result = do_general_path();
}

内置函数 allInvocationsARB() 将为组中的所有调用返回相同的值，因此该组要么执行 do_fast_path()，要么执行 do_general_path()，但绝不会两者都执行。例如，着色器代码可能希望通过从结果的近似值开始，然后细化近似值来迭代评估一个复杂的函数。某些输入值可能需要少量迭代才能生成准确的结果 (do_fast_path)，而另一些输入值则需要更多迭代 (do_general_path)。在另一个示例中，着色器代码可能希望评估一个复杂的函数 (do_general_path)，当假设其输入的特定值时，该函数可以大大简化 (do_fast_path)。

被 Vulkan 1.1 弃用

此扩展中的所有功能都被核心 Vulkan 1.1 子组操作取代。

新的枚举常量

  • VK_EXT_SHADER_SUBGROUP_VOTE_EXTENSION_NAME

  • VK_EXT_SHADER_SUBGROUP_VOTE_SPEC_VERSION

新的 SPIR-V 功能

版本历史

  • 修订版 1，2016-11-28 (Daniel Koch)

    • 初始草案

VK_EXT_shader_viewport_index_layer

名称字符串

VK_EXT_shader_viewport_index_layer

扩展类型

设备扩展

注册扩展号

163

修订

1

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2017-08-08

交互和外部依赖
贡献者

  • Piers Daniell, NVIDIA

  • Jeff Bolz, NVIDIA

  • Jan-Harald Fredriksen, ARM

  • Daniel Rakos, AMD

  • Slawomir Grajeswki, Intel

描述

此扩展添加了对 Vulkan 中 SPV_EXT_shader_viewport_index_layer 扩展的 ShaderViewportIndexLayerEXT 功能的支持。

此扩展允许使用 Layer 和 ViewportIndex 内置变量修饰的变量从顶点或细分着色器导出，使用 ShaderViewportIndexLayerEXT 功能。

当使用基于 GLSL 源的着色语言时，gl_ViewportIndex 和 gl_Layer 内置变量分别映射到 SPIR-V 的 ViewportIndex 和 Layer 内置修饰。这些变量的行为按照 GL_ARB_shader_viewport_layer_array（或先前的 GL_AMD_vertex_shader_layer、GL_AMD_vertex_shader_viewport_index 和 GL_NV_viewport_array2 扩展）中的描述进行了扩展。

ShaderViewportIndexLayerEXT 功能等效于 VK_NV_viewport_array2 添加的 ShaderViewportIndexLayerNV 功能。

提升至 Vulkan 1.2

此扩展中的所有功能都包含在核心 Vulkan 1.2 中。

来自 SPV_EXT_shader_viewport_index_layer 扩展的单个 ShaderViewportIndexLayerEXT 功能被来自 SPIR-V 1.5 的 ShaderViewportIndex 和 ShaderLayer 功能取代，这些功能分别由 shaderOutputViewportIndex 和 shaderOutputLayer 功能启用。此外，如果支持 Vulkan 1.2 但不支持此扩展，则这些功能是可选的。

启用这两个功能等效于启用 VK_EXT_shader_viewport_index_layer 扩展。

新的枚举常量

  • VK_EXT_SHADER_VIEWPORT_INDEX_LAYER_EXTENSION_NAME

  • VK_EXT_SHADER_VIEWPORT_INDEX_LAYER_SPEC_VERSION

新的或修改的内置变量

新的 SPIR-V 功能

版本历史

  • 修订版 1，2017-08-08 (Daniel Koch)

    • 内部草案

VK_EXT_subgroup_size_control

名称字符串

VK_EXT_subgroup_size_control

扩展类型

设备扩展

注册扩展号

226

修订

2

批准状态

未批准

扩展和版本依赖关系

Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-03-05

贡献者

  • Jeff Bolz, NVIDIA

  • Faith Ekstrand, Intel

  • Sławek Grajewski, Intel

  • Jesse Hall, Google

  • Neil Henning, AMD

  • Daniel Koch, NVIDIA

  • Jeff Leger, Qualcomm

  • Graeme Leese, Broadcom

  • Allan MacKinnon, Google

  • Mariusz Merecki，Intel

  • Graham Wihlidal, Electronic Arts

描述

此扩展使实现能够通过允许可变的子组大小并指定所需的子组大小来控制子组大小。

它扩展了 Vulkan 1.1 中的子组支持，以允许实现公开可变的子组大小。以前，Vulkan 为每个物理设备公开一个子组大小，期望实现的行为就像所有子组都具有相同的大小一样。某些实现可能会为不同的子组调度具有可变子组大小的着色器。因此，它们可以隐式地将一个大的子组拆分为较小的子组，或者将一个小的子组表示为较大的子组，其中一些调用在启动时处于非活动状态。

为了帮助开发人员了解其程序的性能特征，此扩展公开了物理设备支持的最小和最大子组大小，以及一个管道创建标志，以使该管道能够改变其子组大小。如果启用，则提供给管道创建的 SPIR-V 着色器模块中任何用 SubgroupSize 修饰的变量可能在最小和最大子组大小之间变化。

实现可以选择性地支持为给定的管线阶段指定所需的子组大小。实现会声明哪些阶段支持所需的子组大小，并且任何受支持阶段的管线都可以传递一个VkPipelineShaderStageRequiredSubgroupSizeCreateInfoEXT结构体，以设置该管线着色器阶段的子组大小。对于计算着色器，这要求开发者查询maxComputeWorkgroupSubgroups，并确保

开发者还可以指定一个新的管线着色器阶段创建标志，该标志要求实现具有局部工作组内完全填充的子组。这要求 X 维度的工作组大小是子组大小的倍数。

新结构体

新枚举常量

  • VK_EXT_SUBGROUP_SIZE_CONTROL_EXTENSION_NAME

  • VK_EXT_SUBGROUP_SIZE_CONTROL_SPEC_VERSION

  • 扩展 VkPipelineShaderStageCreateFlagBits

    • VK_PIPELINE_SHADER_STAGE_CREATE_ALLOW_VARYING_SUBGROUP_SIZE_BIT_EXT

    • VK_PIPELINE_SHADER_STAGE_CREATE_REQUIRE_FULL_SUBGROUPS_BIT_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBGROUP_SIZE_CONTROL_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBGROUP_SIZE_CONTROL_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_REQUIRED_SUBGROUP_SIZE_CREATE_INFO_EXT

晋升到 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍然可用作核心功能的别名。

版本历史

VK_EXT_texel_buffer_alignment

名称字符串

VK_EXT_texel_buffer_alignment

扩展类型

设备扩展

注册扩展号

282

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-06-06

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展为统一和存储纹理缓冲添加了更具表现力的对齐要求。一些实现具有无法通过 VkPhysicalDeviceLimits::minTexelBufferOffsetAlignment 表示的单纹素对齐要求。

新结构体

新枚举常量

  • VK_EXT_TEXEL_BUFFER_ALIGNMENT_EXTENSION_NAME

  • VK_EXT_TEXEL_BUFFER_ALIGNMENT_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXEL_BUFFER_ALIGNMENT_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXEL_BUFFER_ALIGNMENT_PROPERTIES_EXT

晋升到 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。但是，只晋升了属性结构体。特性结构体没有晋升，如果使用 Vulkan 1.3 实例，则启用 texelBufferAlignment。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1，2019-06-06 (Jeff Bolz)

    • 初始草案

VK_EXT_texture_compression_astc_hdr

名称字符串

VK_EXT_texture_compression_astc_hdr

扩展类型

设备扩展

注册扩展号

67

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-05-28

IP 状态

没有已知问题。

贡献者

  • Jan-Harald Fredriksen, Arm

描述

此扩展添加了对使用自适应可伸缩纹理压缩 (ASTC) 高动态范围 (HDR) 配置文件压缩的纹理的支持。

启用此扩展后，将为ASTC 压缩图像格式中列出的所有 ASTC 格式支持 HDR 配置文件。

新结构体

新枚举常量

  • VK_EXT_TEXTURE_COMPRESSION_ASTC_HDR_EXTENSION_NAME

  • VK_EXT_TEXTURE_COMPRESSION_ASTC_HDR_SPEC_VERSION

  • 扩展 VkFormat

    • VK_FORMAT_ASTC_10x10_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_10x5_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_10x6_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_10x8_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_12x10_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_12x12_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_4x4_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_5x4_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_5x5_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_6x5_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_6x6_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_8x5_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_8x6_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_8x8_SFLOAT_BLOCK_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXTURE_COMPRESSION_ASTC_HDR_FEATURES_EXT

晋升到 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。但是，该特性在 Vulkan 1.3 中是可选的。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍然可用作核心功能的别名。

问题

1) 我们是否应该为此功能添加特性或限制？

是的。添加像 textureCompressionASTC_HDR 这样的特性与 ASTC LDR 支持一致。

严格来说，只要这只是一个扩展，该特性就是多余的；只需启用该扩展就足够了。但是，如果希望将来将其作为可选的核心特性，添加该特性则更具前瞻性。

2) 我们是否应该为 HDR 引入新的格式枚举？

是的。Vulkan 1.0 将 ASTC 格式枚举描述为 UNORM，例如 VK_FORMAT_ASTC_4x4_UNORM_BLOCK，因此使这些枚举包含 HDR 数据会令人困惑。请注意，OpenGL (ES) 扩展没有进行这种区分，因为单个 ASTC HDR 纹理可能包含 unorm 和 float 块。实现可能无法在内部区分 LDR 和 HDR ASTC 纹理，而只是将它们视为相同格式，也就是说，如果支持此扩展，则从 VK_FORMAT_ASTC_4x4_UNORM_BLOCK 图像格式采样可能会返回 HDR 结果。应用程序可以通过使用适当的图像格式来获得可预测的结果。

版本历史

  • 修订版 1，2019-05-28 (Jan-Harald Fredriksen)

    • 初始版本

VK_EXT_tooling_info

名称字符串

VK_EXT_tooling_info

扩展类型

设备扩展

注册扩展号

246

修订

1

批准状态

未批准

扩展和版本依赖关系

无

API 交互

  • 与 VK_EXT_debug_marker 交互

  • 与 VK_EXT_debug_report 交互

  • 与 VK_EXT_debug_utils 交互

弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-11-05

贡献者

  • Rolando Caloca

  • Matthaeus Chajdas

  • Baldur Karlsson

  • Daniel Rakos

描述

当应用程序开发期间发生错误时，常见的问题是“现在实际运行的是哪些工具？”此扩展添加了直接从 Vulkan 实现查询该信息的功能。

一个工具的过时版本可能无法与其他工具很好地配合，或者某个工具可能在应该运行时实际上没有运行。试图弄清楚这一点可能会导致麻烦，因为有必要查阅每个已知的工具来弄清楚发生了什么 - 在某些情况下，甚至可能不知道该工具。

通常，当出现问题时，开发者会直接打印出这些信息以进行视觉检查，但是，为了帮助以编程方式识别问题，会提供少量关于工具正在做什么的语义信息。例如，如果实现所声明的限制或功能出乎意料，是否有工具在修改这些限制？或者，如果应用程序提供了调试标记，但实现实际上没有对这些信息执行任何操作，则可以快速指出这一点。

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_EXT_TOOLING_INFO_EXTENSION_NAME

  • VK_EXT_TOOLING_INFO_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TOOL_PROPERTIES_EXT

  • 扩展 VkToolPurposeFlagBits

    • VK_TOOL_PURPOSE_ADDITIONAL_FEATURES_BIT_EXT

    • VK_TOOL_PURPOSE_MODIFYING_FEATURES_BIT_EXT

    • VK_TOOL_PURPOSE_PROFILING_BIT_EXT

    • VK_TOOL_PURPOSE_TRACING_BIT_EXT

    • VK_TOOL_PURPOSE_VALIDATION_BIT_EXT

如果支持 VK_EXT_debug_marker

如果支持 VK_EXT_debug_report

如果支持 VK_EXT_debug_utils

  • 扩展 VkToolPurposeFlagBits

    • VK_TOOL_PURPOSE_DEBUG_MARKERS_BIT_EXT

    • VK_TOOL_PURPOSE_DEBUG_REPORTING_BIT_EXT

升级到 Vulkan 1.3

此扩展中的 Vulkan API 包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。此扩展定义的外部交互（例如 SPIR-V 令牌名称）保留其原始名称。原始 Vulkan API 名称仍然可用作核心功能的别名。

示例

打印工具信息
uint32_t num_tools;
VkPhysicalDeviceToolPropertiesEXT *pToolProperties;
vkGetPhysicalDeviceToolPropertiesEXT(physicalDevice, &num_tools, NULL);

pToolProperties = (VkPhysicalDeviceToolPropertiesEXT*)malloc(sizeof(VkPhysicalDeviceToolPropertiesEXT) * num_tools);

vkGetPhysicalDeviceToolPropertiesEXT(physicalDevice, &num_tools, pToolProperties);

for (int i = 0; i < num_tools; ++i) {
    printf("%s:\n", pToolProperties[i].name);
    printf("Version:\n");
    printf("%s:\n", pToolProperties[i].version);
    printf("Description:\n");
    printf("\t%s\n", pToolProperties[i].description);
    printf("Purposes:\n");
    printf("\t%s\n", VkToolPurposeFlagBitsEXT_to_string(pToolProperties[i].purposes));
    if (strnlen_s(pToolProperties[i].layer,VK_MAX_EXTENSION_NAME_SIZE) > 0) {
        printf("Corresponding Layer:\n");
        printf("\t%s\n", pToolProperties[i].layer);
    }
}

问题

1) 为什么此信息与图层机制分离？

某些工具可能会内置到驱动程序中，或成为 Vulkan 加载器的一部分等。将此信息直接与图层绑定充其量会很尴尬。

版本历史

  • 修订版 1，2018-11-05 (Tobias Hector)

    • 初始草案

VK_EXT_validation_features

名称字符串

VK_EXT_validation_features

扩展类型

实例扩展

注册扩展号

248

修订

6

批准状态

未批准

扩展和版本依赖关系

无

弃用状态
特殊用途
联系方式

其他扩展元数据

上次修改日期

2018-11-14

IP 状态

没有已知的 IP 声明。

贡献者

  • Karl Schultz, LunarG

  • Dave Houlton，LunarG

  • Mark Lobodzinski, LunarG

  • Camden Stocker，LunarG

  • Tony Barbour，LunarG

  • John Zulauf，LunarG

描述

此扩展提供了 VkValidationFeaturesEXT 结构体，该结构体可以包含在作为 vkCreateInstance 的 pCreateInfo 参数传递的 VkInstanceCreateInfo 结构的 pNext 链中。 该结构体包含一个 VkValidationFeatureEnableEXT 枚举值数组，这些枚举值启用默认情况下禁用的特定验证功能。 该结构体还包含一个 VkValidationFeatureDisableEXT 枚举值数组，这些枚举值禁用默认情况下启用的特定验证层功能。

被 VK_EXT_layer_settings 弃用

此扩展中的功能被 VK_EXT_layer_settings 扩展取代。

新结构体

新枚举

新枚举常量

  • VK_EXT_VALIDATION_FEATURES_EXTENSION_NAME

  • VK_EXT_VALIDATION_FEATURES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_VALIDATION_FEATURES_EXT

版本历史

  • 修订版 1，2018-11-14 (Karl Schultz)

    • 初始修订版

  • 修订版 2，2019-08-06 (Mark Lobodzinski)

    • 添加最佳实践启用

  • 修订版 3，2020-03-04 (Tony Barbour)

    • 添加调试Printf启用

  • 修订版 4，2020-07-29 (John Zulauf)

    • 添加同步验证启用

  • 修订版 5，2021-05-18 (Tony Barbour)

    • 添加着色器验证缓存禁用

  • 修订版 6，2023-09-25 (Christophe Riccio)

    • 标记为被 VK_EXT_layer_settings 弃用

VK_EXT_validation_flags

名称字符串

VK_EXT_validation_flags

扩展类型

实例扩展

注册扩展号

62

修订

3

批准状态

未批准

扩展和版本依赖关系

无

弃用状态
特殊用途
联系方式

其他扩展元数据

上次修改日期

2019-08-19

IP 状态

没有已知的 IP 声明。

贡献者

  • Tobin Ehlis, Google

  • Courtney Goeltzenleuchter, Google

描述

此扩展提供了 VkValidationFlagsEXT 结构体，该结构体可以包含在作为 vkCreateInstance 的 pCreateInfo 参数传递的 VkInstanceCreateInfo 结构的 pNext 链中。该结构体包含一个 VkValidationCheckEXT 值数组，这些值将被验证层禁用。

被 VK_EXT_layer_settings 弃用

此扩展中的功能被 VK_EXT_layer_settings 扩展取代。

新结构体

新枚举

新枚举常量

  • VK_EXT_VALIDATION_FLAGS_EXTENSION_NAME

  • VK_EXT_VALIDATION_FLAGS_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_VALIDATION_FLAGS_EXT

版本历史

  • 修订版 3，2023-09-25 (Christophe Riccio)

    • 标记为被 VK_EXT_layer_settings 弃用

  • 修订版 2，2019-08-19 (Mark Lobodzinski)

    • 标记为被 VK_EXT_validation_features 弃用

  • 修订版 1，2016-08-26 (Courtney Goeltzenleuchter)

    • 初始草案

VK_EXT_vertex_attribute_divisor

名称字符串

VK_EXT_vertex_attribute_divisor

扩展类型

设备扩展

注册扩展号

191

修订

3

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-08-03

IP 状态

没有已知的 IP 声明。

贡献者

  • Vikram Kushwaha, NVIDIA

  • Faith Ekstrand, Intel

描述

此扩展允许在启用实例化渲染时，实例速率顶点属性为特定数量的实例重复使用，而不是为每个实例递增。

新结构

新枚举常量

  • VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_EXTENSION_NAME

  • VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_EXT

问题

1) firstInstance 的非零值有什么影响？

已解决：Vulkan API 应遵循 OpenGL 约定，并在计算顶点属性偏移时，通过 firstInstance 偏移属性的获取。

2) 零是否应为允许的除数？

已解决：是。零除数表示顶点属性对于所有实例重复使用。

示例

要创建一个顶点绑定，使得第一个绑定使用实例化渲染，并且每个 4 个绘制实例使用相同的属性，应用程序可以使用以下结构集

    const VkVertexInputBindingDivisorDescriptionEXT divisorDesc =
    {
        .binding = 0,
        .divisor = 4
    };

    const VkPipelineVertexInputDivisorStateCreateInfoEXT divisorInfo =
    {
        .sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_EXT,
        .pNext = NULL,
        .vertexBindingDivisorCount = 1,
        .pVertexBindingDivisors = &divisorDesc
    }

    const VkVertexInputBindingDescription binding =
    {
        .binding = 0,
        .stride = sizeof(Vertex),
        .inputRate = VK_VERTEX_INPUT_RATE_INSTANCE
    };

    const VkPipelineVertexInputStateCreateInfo viInfo =
    {
        .sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_CREATE_INFO,
        .pNext = &divisorInfo,
        ...
    };
    //...

版本历史

  • 修订版 1, 2017-12-04 (Vikram Kushwaha)

    • 第一个版本

  • 修订版 2, 2018-07-16 (Faith Ekstrand)

    • 调整 divisor 和 firstInstance 之间的交互以匹配 OpenGL 约定。

    • 不允许除数为零。

  • 修订版 3, 2018-08-03 (Vikram Kushwaha)

    • 允许零除数。

    • 添加物理设备功能结构来查询/启用此功能。

VK_EXT_ycbcr_2plane_444_formats

名称字符串

VK_EXT_ycbcr_2plane_444_formats

扩展类型

设备扩展

注册扩展号

331

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_sampler_ycbcr_conversion
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2020-07-28

IP 状态

没有已知的 IP 声明。

贡献者

  • Piers Daniell, NVIDIA

  • Ping Liu, Intel

描述

此扩展添加了一些 Y′CBCR 格式，这些格式在视频编码和解码中常用，但不是 VK_KHR_sampler_ycbcr_conversion 扩展的一部分。

新结构

新枚举常量

  • VK_EXT_YCBCR_2PLANE_444_FORMATS_EXTENSION_NAME

  • VK_EXT_YCBCR_2PLANE_444_FORMATS_SPEC_VERSION

  • 扩展 VkFormat

    • VK_FORMAT_G10X6_B10X6R10X6_2PLANE_444_UNORM_3PACK16_EXT

    • VK_FORMAT_G12X4_B12X4R12X4_2PLANE_444_UNORM_3PACK16_EXT

    • VK_FORMAT_G16_B16R16_2PLANE_444_UNORM_EXT

    • VK_FORMAT_G8_B8R8_2PLANE_444_UNORM_EXT

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_YCBCR_2_PLANE_444_FORMATS_FEATURES_EXT

升级到 Vulkan 1.3

扩展引入的格式枚举包含在核心 Vulkan 1.3 中，省略了 EXT 后缀。但是，核心 Vulkan 1.3 中对这些格式的运行时支持是可选的，而如果支持此扩展，则运行时支持是强制性的。功能结构未升级。原始枚举名称仍然可用作核心功能的别名。

版本历史

  • 修订版 1, 2020-03-08 (Piers Daniell)

    • 初始草案

VK_AMD_draw_indirect_count

名称字符串

VK_AMD_draw_indirect_count

扩展类型

设备扩展

注册扩展号

34

修订

2

批准状态

未批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-08-23

IP 状态

没有已知的 IP 声明。

贡献者

  • Matthaeus G. Chajdas, AMD

  • Derrick Owens, AMD

  • Graham Sellers, AMD

  • Daniel Rakos, AMD

  • Dominik Witczak，AMD

描述

此扩展允许应用程序从缓冲区获取间接绘制命令的绘制数量。 这使得应用程序能够生成任意数量的绘制命令，并在没有主机干预的情况下执行它们。

升级到 VK_KHR_draw_indirect_count

此扩展中的所有功能都包含在 VK_KHR_draw_indirect_count 中，后缀更改为 KHR。原始类型、枚举和命令名称仍然可用作核心功能的别名。

新命令

新枚举常量

  • VK_AMD_DRAW_INDIRECT_COUNT_EXTENSION_NAME

  • VK_AMD_DRAW_INDIRECT_COUNT_SPEC_VERSION

版本历史

  • 修订版 2, 2016-08-23 (Dominik Witczak)

    • 小修复

  • 修订版 1, 2016-07-21 (Matthaeus Chajdas)

    • 初始草案

VK_AMD_gpu_shader_half_float

名称字符串

VK_AMD_gpu_shader_half_float

扩展类型

设备扩展

注册扩展号

37

修订

2

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-04-11

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Daniel Rakos, AMD

  • Dominik Witczak，AMD

  • 董林伟, AMD

  • Graham Sellers, AMD

  • Qun Lin, AMD

  • Rex Xu，AMD

描述

此扩展增加了对在着色器中使用半浮点变量的支持。

被 VK_KHR_shader_float16_int8 弃用

当 shaderFloat16 功能启用时，此扩展中的功能包含在 VK_KHR_shader_float16_int8 扩展中。

新枚举常量

  • VK_AMD_GPU_SHADER_HALF_FLOAT_EXTENSION_NAME

  • VK_AMD_GPU_SHADER_HALF_FLOAT_SPEC_VERSION

版本历史

  • 修订版 2, 2019-04-11 (Tobias Hector)

    • 标记为已弃用

  • 修订版 1, 2016-09-21 (Dominik Witczak)

    • 初始草案

VK_AMD_gpu_shader_int16

名称字符串

VK_AMD_gpu_shader_int16

扩展类型

设备扩展

注册扩展号

133

修订

2

批准状态

未批准

扩展和版本依赖关系

无

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2019-04-11

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Daniel Rakos, AMD

  • Dominik Witczak，AMD

  • Matthaeus G. Chajdas, AMD

  • Rex Xu，AMD

  • Timothy Lottes, AMD

  • 蔡志, AMD

描述

此扩展增加了对在着色器中使用 16 位整数变量的支持。

被 VK_KHR_shader_float16_int8 弃用

当 shaderInt16 和 shaderFloat16 功能启用时，此扩展中的功能包含在 VK_KHR_shader_float16_int8 扩展中。

新枚举常量

  • VK_AMD_GPU_SHADER_INT16_EXTENSION_NAME

  • VK_AMD_GPU_SHADER_INT16_SPEC_VERSION

版本历史

  • 修订版 2, 2019-04-11 (Tobias Hector)

    • 标记为已弃用

  • 修订版 1, 2017-06-18 (Dominik Witczak)

    • 第一个版本

VK_AMD_negative_viewport_height

名称字符串

VK_AMD_negative_viewport_height

扩展类型

设备扩展

注册扩展号

36

修订

1

批准状态

未批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-09-02

IP 状态

没有已知的 IP 声明。

贡献者

  • Matthaeus G. Chajdas, AMD

  • Graham Sellers, AMD

  • Baldur Karlsson

描述

此扩展允许应用程序指定负视口高度。结果是视口变换将沿 y 轴翻转。

  • 允许在 VkViewport::height 字段中指定负高度，以执行剪辑空间到帧缓冲空间变换的 y 轴反转。这允许应用程序避免在也面向其他 API 的着色器中使用 gl_Position.y = -gl_Position.y。

被 VK_KHR_maintenance1 和 Vulkan 1.1 废弃

此扩展中的功能包含在 VK_KHR_maintenance1 扩展以及随后的 Vulkan 1.1 中。由于一些细微的行为差异，此扩展必须不能与 VK_KHR_maintenance1 同时启用，也不能在 VkApplicationInfo::apiVersion 中请求版本 1.1 或更高版本的情况下创建实例。

新的枚举常量

  • VK_AMD_NEGATIVE_VIEWPORT_HEIGHT_EXTENSION_NAME

  • VK_AMD_NEGATIVE_VIEWPORT_HEIGHT_SPEC_VERSION

版本历史

  • 修订版 1，2016-09-02 (Matthaeus Chajdas)

    • 初始草案

VK_ARM_rasterization_order_attachment_access

名称字符串

VK_ARM_rasterization_order_attachment_access

扩展类型

设备扩展

注册扩展号

343

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

弃用状态
联系方式

其他扩展元数据

上次修改日期

2021-11-12

IP 状态

没有已知的 IP 声明。

贡献者

  • Tobias Hector, AMD

  • Jan-Harald Fredriksen, Arm

描述

渲染通道，特别是子通道依赖关系，启用了与 OpenGL ES 的帧缓冲获取和像素局部存储扩展相同的大部分功能。但是，仅使用这些方法很难或不切实际地实现某些技术，例如可编程混合，部分原因是每次片段在给定采样坐标处读取值时都需要自我依赖。

此扩展扩展了输入附件的机制，允许从一个片段到下一个片段以光栅化顺序访问帧缓冲附件，将其用作输入和颜色或深度/模板附件，而无需显式同步。

新的结构体

新的枚举常量

  • VK_ARM_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_EXTENSION_NAME

  • VK_ARM_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_SPEC_VERSION

  • 扩展 VkPipelineColorBlendStateCreateFlagBits

    • VK_PIPELINE_COLOR_BLEND_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_BIT_ARM

  • 扩展 VkPipelineDepthStencilStateCreateFlagBits

    • VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_ARM

    • VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_ARM

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_FEATURES_ARM

  • 扩展 VkSubpassDescriptionFlagBits

    • VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_COLOR_ACCESS_BIT_ARM

    • VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_ARM

    • VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_ARM

问题

1) 是否与 VK_KHR_dynamic_rendering 扩展有任何交互？

否。此扩展仅影响从输入附件的读取。使用 vkCmdBeginRenderingKHR 开始的渲染通道实例没有输入附件，在这种情况下需要不同的机制来提供类似的功能。

示例

无。

版本历史

  • 修订版 1，2021-11-12 (Jan-Harald Fredriksen)

    • 初始草案

VK_IMG_format_pvrtc

名称字符串

VK_IMG_format_pvrtc

扩展类型

设备扩展

注册扩展号

55

修订

1

批准状态

未批准

扩展和版本依赖关系

无

弃用状态

  • 已弃用，无替代方案

联系方式

  • Stuart Smith

其他扩展元数据

上次修改日期

2019-09-02

IP 状态

Imagination Technologies 专有

贡献者

  • Stuart Smith, Imagination Technologies

描述

VK_IMG_format_pvrtc 提供了 Imagination Technologies PowerVR 纹理压缩格式（称为 PVRTC）特有的额外纹理压缩功能。

正如 Khronos 数据格式规范 中也指出的那样，PVRTC1 图像的尺寸必须是 2 的幂。

弃用

在 PowerVR GPU 上，PVRTC1 和 PVRTC2 都比标准图像格式慢，并且在未来的硬件中将不再支持。

新的枚举常量

  • VK_IMG_FORMAT_PVRTC_EXTENSION_NAME

  • VK_IMG_FORMAT_PVRTC_SPEC_VERSION

  • 扩展 VkFormat

    • VK_FORMAT_PVRTC1_2BPP_SRGB_BLOCK_IMG

    • VK_FORMAT_PVRTC1_2BPP_UNORM_BLOCK_IMG

    • VK_FORMAT_PVRTC1_4BPP_SRGB_BLOCK_IMG

    • VK_FORMAT_PVRTC1_4BPP_UNORM_BLOCK_IMG

    • VK_FORMAT_PVRTC2_2BPP_SRGB_BLOCK_IMG

    • VK_FORMAT_PVRTC2_2BPP_UNORM_BLOCK_IMG

    • VK_FORMAT_PVRTC2_4BPP_SRGB_BLOCK_IMG

    • VK_FORMAT_PVRTC2_4BPP_UNORM_BLOCK_IMG

版本历史

  • 修订版 1，2019-09-02 (Stuart Smith)

    • 初始版本

VK_MVK_ios_surface

名称字符串

VK_MVK_ios_surface

扩展类型

实例扩展

注册扩展号

123

修订

3

批准状态

未批准

扩展和版本依赖关系

VK_KHR_surface

弃用状态
联系方式

其他扩展元数据

上次修改日期

2020-07-31

IP 状态

没有已知的 IP 声明。

贡献者

  • Bill Hollings, The Brenwill Workshop Ltd.

描述

VK_MVK_ios_surface 扩展是一个实例扩展。它提供了一种机制来创建一个基于 UIView（iOS 的本机表面类型）的 VkSurfaceKHR 对象（由 VK_KHR_surface 扩展定义），该对象由 CAMetalLayer 支持，以支持使用 Apple 的 Metal 框架渲染到表面。

被 VK_EXT_metal_surface 弃用

VK_MVK_ios_surface 扩展被认为是已弃用的，并且已被 VK_EXT_metal_surface 扩展取代。

新命令

新的结构体

新的位掩码

新的枚举常量

  • VK_MVK_IOS_SURFACE_EXTENSION_NAME

  • VK_MVK_IOS_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_IOS_SURFACE_CREATE_INFO_MVK

版本历史

  • 修订版 1，2017-02-15 (Bill Hollings)

    • 初始草案。

  • 修订版 2，2017-02-24 (Bill Hollings)

    • 对语法进行了小的修复，以强调 UIView 必须由 CAMetalLayer 支持的严格要求。

  • 修订版 3，2020-07-31 (Bill Hollings)

    • 更新有关 UIView 要求的文档。

    • 标记为被 VK_EXT_metal_surface 弃用。

VK_MVK_macos_surface

名称字符串

VK_MVK_macos_surface

扩展类型

实例扩展

注册扩展号

124

修订

3

批准状态

未批准

扩展和版本依赖关系

VK_KHR_surface

弃用状态
联系方式

其他扩展元数据

上次修改日期

2020-07-31

IP 状态

没有已知的 IP 声明。

贡献者

  • Bill Hollings, The Brenwill Workshop Ltd.

描述

VK_MVK_macos_surface 扩展是一个实例扩展。它提供了一种机制来创建基于 NSView (macOS 的原生表面类型，由 CAMetalLayer 提供支持) 的 VkSurfaceKHR 对象（由 VK_KHR_surface 扩展定义），以支持使用 Apple 的 Metal 框架渲染到该表面。

被 VK_EXT_metal_surface 弃用

VK_MVK_macos_surface 扩展被认为是已弃用的，并已被 VK_EXT_metal_surface 扩展取代。

新命令

新结构体

新位掩码

新枚举常量

  • VK_MVK_MACOS_SURFACE_EXTENSION_NAME

  • VK_MVK_MACOS_SURFACE_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_MACOS_SURFACE_CREATE_INFO_MVK

版本历史

  • 修订版 1，2017-02-15 (Bill Hollings)

    • 初始草案。

  • 修订版 2，2017-02-24 (Bill Hollings)

    • 小幅语法修复，强调 NSView 必须由 CAMetalLayer 支持的严格要求。

  • 修订版 3，2020-07-31 (Bill Hollings)

    • 更新了关于 NSView 要求的文档。

    • 标记为被 VK_EXT_metal_surface 弃用。

VK_NV_compute_shader_derivatives

名称字符串

VK_NV_compute_shader_derivatives

扩展类型

设备扩展

注册扩展号

202

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-07-19

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Pat Brown, NVIDIA

描述

此扩展为 SPV_NV_compute_shader_derivatives SPIR-V 扩展添加了 Vulkan 支持。

SPIR-V 扩展提供了两种新的执行模式，这两种模式都允许计算着色器使用显式或隐式计算导数的内置函数。导数将通过在 2x2 着色器调用组上求差来计算。DerivativeGroupQuadsNV 执行模式将着色器调用组装成 2x2 的组，其中每组的局部调用 ID 的 x 和 y 坐标的形式为 (2m+{0,1}, 2n+{0,1})。DerivativeGroupLinearNV 执行模式将着色器调用组装成 2x2 的组，其中每组的局部调用索引值的形式为 4m+{0,1,2,3}。

新结构体

新枚举常量

  • VK_NV_COMPUTE_SHADER_DERIVATIVES_EXTENSION_NAME

  • VK_NV_COMPUTE_SHADER_DERIVATIVES_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_SHADER_DERIVATIVES_FEATURES_NV

新的 SPIR-V 能力

问题

(1) 我们是否应该指定用于计算着色器中导数的四组着色器调用与在着色器子组中形成“四边形”的四组调用相同？

已解决：可以。

示例

无。

版本历史

  • 修订版 1, 2018-07-19 (Pat Brown)

    • 初始草案

VK_NV_dedicated_allocation

名称字符串

VK_NV_dedicated_allocation

扩展类型

设备扩展

注册扩展号

27

修订

1

批准状态

未批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-05-31

IP 状态

没有已知的 IP 声明。

贡献者

  • Jeff Bolz, NVIDIA

描述

此扩展允许为特定的缓冲区或图像资源分配设备内存，这在某些设备上可以显著提高该资源的性能。普通的设备内存分配必须支持内存别名和稀疏绑定，这可能会干扰帧缓冲区压缩或高效的页表使用等优化。这对渲染目标和非常大的资源很重要，但不应该（也可能不应该）用于可以从子分配中受益的较小资源。

此扩展为资源创建和内存分配添加了一些小的结构：一个新结构，用于标记图像/缓冲区是否将具有专用分配，以及一个结构，用于指示分配将绑定到的图像或缓冲区。

新结构体

新枚举常量

  • VK_NV_DEDICATED_ALLOCATION_EXTENSION_NAME

  • VK_NV_DEDICATED_ALLOCATION_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_BUFFER_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_IMAGE_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV

示例

    // Create an image with
    // VkDedicatedAllocationImageCreateInfoNV::dedicatedAllocation
    // set to VK_TRUE

    VkDedicatedAllocationImageCreateInfoNV dedicatedImageInfo =
    {
        .sType = VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_IMAGE_CREATE_INFO_NV,
        .pNext = NULL,
        .dedicatedAllocation = VK_TRUE,
    };

    VkImageCreateInfo imageCreateInfo =
    {
        .sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO,
        .pNext = &dedicatedImageInfo
        // Other members set as usual
    };

    VkImage image;
    VkResult result = vkCreateImage(
        device,
        &imageCreateInfo,
        NULL,               // pAllocator
        &image);

    VkMemoryRequirements memoryRequirements;
    vkGetImageMemoryRequirements(
        device,
        image,
        &memoryRequirements);

    // Allocate memory with VkDedicatedAllocationMemoryAllocateInfoNV::image
    // pointing to the image we are allocating the memory for

    VkDedicatedAllocationMemoryAllocateInfoNV dedicatedInfo =
    {
        .sType = VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV,
        .pNext = NULL,
        .image = image,
        .buffer = VK_NULL_HANDLE,
    };

    VkMemoryAllocateInfo memoryAllocateInfo =
    {
        .sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO,
        .pNext = &dedicatedInfo,
        .allocationSize = memoryRequirements.size,
        .memoryTypeIndex = FindMemoryTypeIndex(memoryRequirements.memoryTypeBits),
    };

    VkDeviceMemory memory;
    vkAllocateMemory(
        device,
        &memoryAllocateInfo,
        NULL,               // pAllocator
        &memory);

    // Bind the image to the memory

    vkBindImageMemory(
        device,
        image,
        memory,
        0);

版本历史

  • 修订版 1, 2016-05-31 (Jeff Bolz)

    • 内部修订

VK_NV_external_memory

名称字符串

VK_NV_external_memory

扩展类型

设备扩展

注册扩展号

57

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_NV_external_memory_capabilities

弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-08-19

IP 状态

没有已知的 IP 声明。

贡献者

  • James Jones, NVIDIA

  • Carsten Rohde, NVIDIA

描述

应用程序可能希望将内存导出到其他 Vulkan 实例或其他 API，或者从其他 Vulkan 实例或其他 API 导入内存，以便在应用程序模块、进程或 API 边界之间拆分 Vulkan 工作负载。此扩展使应用程序可以创建可导出的 Vulkan 内存对象，以便底层资源可以在创建它们的 Vulkan 实例之外引用。

新结构体

新枚举常量

  • VK_NV_EXTERNAL_MEMORY_EXTENSION_NAME

  • VK_NV_EXTERNAL_MEMORY_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_NV

    • VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_NV

问题

1) 如果内存对象在进程和 API 之间共享，这是否被视为符合 内存别名部分概述的规则的别名？

已解决：是的，但为了允许在这些情况下使用某些形式的别名，添加了对规则的严格例外。此外，其他扩展可以基于这些新的别名规则，定义 Vulkan 中对导入的本机内存对象或来自其他 API 的内存对象的特定支持用法。

2) 是否需要新的图像布局或元数据来指定与非 Vulkan API 或同一 Vulkan 驱动程序的其他实例兼容的图像布局和布局转换？

已解决：不需要。在同一 GPU 上运行的同一 Vulkan 驱动程序的单独实例应该具有相同的内部布局语义，因此应用程序具有确保两个实例之间图像视图一致性所需的工具。其他 API 将分为两类：与 Vulkan 兼容的 API（由后续的互操作性扩展定义的一个术语）或与 Vulkan 不兼容的 API。当与 Vulkan 不兼容的 API 共享图像时，Vulkan 图像必须在将其交给外部 API 之前转换为 VK_IMAGE_LAYOUT_GENERAL 布局。

请注意，这并不试图解决跨设备转换，也不解决同一设备上 Vulkan API 中不可见的引擎的转换。这两者都超出了此扩展的范围。

示例

    // TODO: Write some sample code here.

版本历史

  • 修订版 1, 2016-08-19 (James Jones)

    • 初始草案

VK_NV_external_memory_capabilities

名称字符串

VK_NV_external_memory_capabilities

扩展类型

实例扩展

注册扩展号

56

修订

1

批准状态

未批准

扩展和版本依赖关系

无

弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-08-19

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • James Jones, NVIDIA

描述

应用程序可能希望从 Direct 3D API 导入内存，或者将内存导出到其他 Vulkan 实例。此扩展提供了一组功能查询，允许应用程序确定实现对于给定用例支持哪些类型的 win32 内存句柄。

新命令

新结构体

新枚举

新位掩码

新枚举常量

  • VK_NV_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME

  • VK_NV_EXTERNAL_MEMORY_CAPABILITIES_SPEC_VERSION

问题

1) 为什么需要在每个内存句柄类型的基础上查询如此多的外部内存功能？

已解决：这是因为某些句柄类型基于操作系统原生对象，这些对象的功能远比非常通用的 Vulkan 内存对象的功能有限。并非所有内存句柄类型都可以命名支持 3D 图像的内存对象。有些句柄类型甚至不支持 Vulkan 的延迟图像和内存绑定行为，并且需要在分配或导入内存对象时指定图像。

2) VkExternalImageFormatPropertiesNV 结构体是否需要包含支持给定句柄类型的内存类型位列表？

已解决：否。当在图像创建时指定了一组句柄类型时，不支持句柄类型的内存类型将简单地从 vkGetImageMemoryRequirements 返回的结果中过滤掉。

3) 是否应该将非不透明的句柄类型移动到它们自己的扩展中？

已解决：也许。然而，定义句柄类型位的作用很小，并且本身不需要任何平台特定的类型，现在在一个扩展中维护位掩码值更容易。据推测，可以通过单独的扩展添加更多的句柄类型，并且将一些平台特定的句柄类型定义在核心规范中，而一些定义在扩展中，会有点奇怪。

版本历史

  • 修订版 1, 2016-08-19 (James Jones)

    • 初始版本

VK_NV_external_memory_win32

名称字符串

VK_NV_external_memory_win32

扩展类型

设备扩展

注册扩展号

58

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_NV_external_memory

弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-08-19

IP 状态

没有已知的 IP 声明。

贡献者

  • James Jones, NVIDIA

  • Carsten Rohde, NVIDIA

描述

应用程序可能希望将内存导出到其他 Vulkan 实例或其他 API，或者从其他 Vulkan 实例或其他 API 导入内存，以使 Vulkan 工作负载能够在应用程序模块、进程或 API 边界之间拆分。此扩展使 win32 应用程序能够从 Vulkan 内存对象导出 win32 句柄，以便可以在创建它们的 Vulkan 实例之外引用底层资源，并将 Direct3D API 中创建的 win32 句柄导入到 Vulkan 内存对象。

新命令

新结构体

新枚举常量

  • VK_NV_EXTERNAL_MEMORY_WIN32_EXTENSION_NAME

  • VK_NV_EXTERNAL_MEMORY_WIN32_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_NV

    • VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_NV

问题

1) 如果内存对象在进程和 API 之间共享，这是否被视为符合 内存别名部分概述的规则的别名？

已解决：是的，但为了允许在这些情况下使用某些形式的别名，添加了对规则的严格例外。此外，其他扩展可以基于这些新的别名规则，定义 Vulkan 中对导入的本机内存对象或来自其他 API 的内存对象的特定支持用法。

2) 是否需要新的图像布局或元数据来指定与非 Vulkan API 或同一 Vulkan 驱动程序的其他实例兼容的图像布局和布局转换？

已解决：不需要。在同一 GPU 上运行的同一 Vulkan 驱动程序的单独实例应该具有相同的内部布局语义，因此应用程序具有确保两个实例之间图像视图一致性所需的工具。其他 API 将分为两类：与 Vulkan 兼容的 API（由后续的互操作性扩展定义的一个术语）或与 Vulkan 不兼容的 API。当与 Vulkan 不兼容的 API 共享图像时，Vulkan 图像必须在将其交给外部 API 之前转换为 VK_IMAGE_LAYOUT_GENERAL 布局。

请注意，这并不试图解决跨设备转换，也不解决同一设备上 Vulkan API 中不可见的引擎的转换。这两者都超出了此扩展的范围。

3) 当 handleType 为 VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_NV 时，应用程序是否需要在从 vkGetMemoryWin32HandleNV 返回的值上调用 CloseHandle()？

已解决：是的，除非它被传递回另一个驱动程序实例以导入对象。成功的 get 调用会将句柄的所有权转移给应用程序，而导入会将所有权转移给关联的驱动程序。销毁内存对象不会销毁句柄或句柄对底层内存资源的引用。

示例

    //
    // Create an exportable memory object and export an external
    // handle from it.
    //

    // Pick an external format and handle type.
    static const VkFormat format = VK_FORMAT_R8G8B8A8_UNORM;
    static const VkExternalMemoryHandleTypeFlagsNV handleType =
        VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_NV;

    extern VkPhysicalDevice physicalDevice;
    extern VkDevice device;

    VkPhysicalDeviceMemoryProperties memoryProperties;
    VkExternalImageFormatPropertiesNV properties;
    VkExternalMemoryImageCreateInfoNV externalMemoryImageCreateInfo;
    VkDedicatedAllocationImageCreateInfoNV dedicatedImageCreateInfo;
    VkImageCreateInfo imageCreateInfo;
    VkImage image;
    VkMemoryRequirements imageMemoryRequirements;
    uint32_t numMemoryTypes;
    uint32_t memoryType;
    VkExportMemoryAllocateInfoNV exportMemoryAllocateInfo;
    VkDedicatedAllocationMemoryAllocateInfoNV dedicatedAllocationInfo;
    VkMemoryAllocateInfo memoryAllocateInfo;
    VkDeviceMemory memory;
    VkResult result;
    HANDLE memoryHnd;

    // Figure out how many memory types the device supports
    vkGetPhysicalDeviceMemoryProperties(physicalDevice,
                                        &memoryProperties);
    numMemoryTypes = memoryProperties.memoryTypeCount;

    // Check the external handle type capabilities for the chosen format
    // Exportable 2D image support with at least 1 mip level, 1 array
    // layer, and VK_SAMPLE_COUNT_1_BIT using optimal tiling and supporting
    // texturing and color rendering is required.
    result = vkGetPhysicalDeviceExternalImageFormatPropertiesNV(
        physicalDevice,
        format,
        VK_IMAGE_TYPE_2D,
        VK_IMAGE_TILING_OPTIMAL,
        VK_IMAGE_USAGE_SAMPLED_BIT |
        VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT,
        0,
        handleType,
        &properties);

    if ((result != VK_SUCCESS) ||
        !(properties.externalMemoryFeatures &
          VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT_NV)) {
        abort();
    }

    // Set up the external memory image creation info
    memset(&externalMemoryImageCreateInfo,
           0, sizeof(externalMemoryImageCreateInfo));
    externalMemoryImageCreateInfo.sType =
        VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_NV;
    externalMemoryImageCreateInfo.handleTypes = handleType;
    if (properties.externalMemoryFeatures &
        VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_NV) {
        memset(&dedicatedImageCreateInfo, 0, sizeof(dedicatedImageCreateInfo));
        dedicatedImageCreateInfo.sType =
            VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_IMAGE_CREATE_INFO_NV;
        dedicatedImageCreateInfo.dedicatedAllocation = VK_TRUE;
        externalMemoryImageCreateInfo.pNext = &dedicatedImageCreateInfo;
    }
    // Set up the  core image creation info
    memset(&imageCreateInfo, 0, sizeof(imageCreateInfo));
    imageCreateInfo.sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO;
    imageCreateInfo.pNext = &externalMemoryImageCreateInfo;
    imageCreateInfo.format = format;
    imageCreateInfo.extent.width = 64;
    imageCreateInfo.extent.height = 64;
    imageCreateInfo.extent.depth = 1;
    imageCreateInfo.mipLevels = 1;
    imageCreateInfo.arrayLayers = 1;
    imageCreateInfo.samples = VK_SAMPLE_COUNT_1_BIT;
    imageCreateInfo.tiling = VK_IMAGE_TILING_OPTIMAL;
    imageCreateInfo.usage = VK_IMAGE_USAGE_SAMPLED_BIT |
        VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
    imageCreateInfo.sharingMode = VK_SHARING_MODE_EXCLUSIVE;
    imageCreateInfo.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;

    vkCreateImage(device, &imageCreateInfo, NULL, &image);

    vkGetImageMemoryRequirements(device,
                                 image,
                                 &imageMemoryRequirements);

    // For simplicity, just pick the first compatible memory type.
    for (memoryType = 0; memoryType < numMemoryTypes; memoryType++) {
        if ((1 << memoryType) & imageMemoryRequirements.memoryTypeBits) {
            break;
        }
    }

    // At least one memory type must be supported given the prior external
    // handle capability check.
    assert(memoryType < numMemoryTypes);

    // Allocate the external memory object.
    memset(&exportMemoryAllocateInfo, 0, sizeof(exportMemoryAllocateInfo));
    exportMemoryAllocateInfo.sType =
        VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_NV;
    exportMemoryAllocateInfo.handleTypes = handleType;
    if (properties.externalMemoryFeatures &
        VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_NV) {
        memset(&dedicatedAllocationInfo, 0, sizeof(dedicatedAllocationInfo));
        dedicatedAllocationInfo.sType =
            VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV;
        dedicatedAllocationInfo.image = image;
        exportMemoryAllocateInfo.pNext = &dedicatedAllocationInfo;
    }
    memset(&memoryAllocateInfo, 0, sizeof(memoryAllocateInfo));
    memoryAllocateInfo.sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO;
    memoryAllocateInfo.pNext = &exportMemoryAllocateInfo;
    memoryAllocateInfo.allocationSize = imageMemoryRequirements.size;
    memoryAllocateInfo.memoryTypeIndex = memoryType;

    vkAllocateMemory(device, &memoryAllocateInfo, NULL, &memory);

    if (!(properties.externalMemoryFeatures &
          VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_NV)) {
        vkBindImageMemory(device, image, memory, 0);
    }

    // Get the external memory opaque FD handle
    vkGetMemoryWin32HandleNV(device, memory, &memoryHnd);

版本历史

  • 修订版 1, 2016-08-11 (James Jones)

    • 初始草案

VK_NV_fragment_shader_barycentric

名称字符串

VK_NV_fragment_shader_barycentric

扩展类型

设备扩展

注册扩展号

204

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_get_physical_device_properties2
或
Vulkan 版本 1.1

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-08-03

IP 状态

没有已知的 IP 声明。

交互和外部依赖
贡献者

  • Pat Brown, NVIDIA

  • Daniel Koch, NVIDIA

描述

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

该扩展提供了对 SPIR-V 中三个附加片段着色器变量修饰符的访问

  • PerVertexNV，表示片段着色器输入将不具有插值，而是必须使用额外的数组索引进行访问，该索引标识生成片段的图元的顶点之一

  • BaryCoordNV，表示变量是三组件浮点向量，其中包含使用透视插值生成的片段的重心权重

  • BaryCoordNoPerspNV，表示变量是三组件浮点向量，其中包含使用线性插值生成的片段的重心权重

当使用基于 GLSL 源的着色器语言时，来自 GL_NV_fragment_shader_barycentric 的以下变量映射到这些 SPIR-V 内置装饰

  • in vec3 gl_BaryCoordNV; → BaryCoordNV

  • in vec3 gl_BaryCoordNoPerspNV; → BaryCoordNoPerspNV

使用 __pervertexNV GLSL 限定符声明的 GLSL 变量应使用 SPIR-V 中的 PerVertexNV 进行装饰。

升级到 VK_KHR_fragment_shader_barycentric

此扩展中的所有功能都包含在 VK_KHR_fragment_shader_barycentric 中，后缀已更改为 KHR。

新结构体

新枚举常量

  • VK_NV_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME

  • VK_NV_FRAGMENT_SHADER_BARYCENTRIC_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_FEATURES_NV

新内置变量

新的 SPIR-V 装饰

新的 SPIR-V 功能

问题

(1) AMD_shader_explicit_vertex_parameter 扩展提供了类似的功能。为什么要编写新的扩展，以及这个扩展有什么不同？

已解决：出于 Vulkan/SPIR-V 的目的，由于几个功能上的差异，我们选择实现一个单独的扩展。

首先，支持此扩展的硬件可以为使用 BaryCoordNV 修饰的变量提供一个三组件重心权重向量，而使用 BaryCoordSmoothAMD 修饰的变量仅提供两个组件。在某些情况下，通过以下方式显式插值属性可能更有效：

float value = (baryCoordNV.x * v[0].attrib +
               baryCoordNV.y * v[1].attrib +
               baryCoordNV.z * v[2].attrib);

而不是：

float value = (baryCoordSmoothAMD.x * (v[0].attrib - v[2].attrib) +
               baryCoordSmoothAMD.y * (v[1].attrib - v[2].attrib) +
               v[2].attrib);

此外，BaryCoordPullModelAMD 修饰的语义似乎没有映射到此扩展的初始硬件实现所支持的任何内容。

此扩展提供的修饰数量少于 AMD 扩展，因为我们期望着色器可以使用显式属性插值指令来派生使用诸如 BaryCoordNoPerspCentroidAMD 之类修饰的变量。另一个相关的区别是，使用此扩展的显式逐顶点属性访问不需要常量顶点编号。

(2) 为什么此扩展的内置 SPIR-V 修饰包括两个独立的内置项 BaryCoordNV 和 BaryCoordNoPerspNV，而“无透视”变量可以使用 BaryCoordNV 和 NoPerspective 修饰？

已解决：此功能的 SPIR-V 扩展选择镜像 GLSL 扩展的行为，该扩展提供了两个内置变量。此外，尚不清楚使用“相同属性”但具有不同插值修饰符的两个变量是否是一个好主意（甚至是合法的）。

版本历史

  • 修订版 1，2018-08-03 (Pat Brown)

    • 内部修订

VK_NV_glsl_shader

名称字符串

VK_NV_glsl_shader

扩展类型

设备扩展

注册扩展号

13

修订

1

批准状态

未批准

扩展和版本依赖关系

无

弃用状态

  • 已弃用，无替代方案

联系方式

其他扩展元数据

上次修改日期

2016-02-14

IP 状态

没有已知的 IP 声明。

贡献者

  • Piers Daniell, NVIDIA

描述

此扩展允许使用为 GL_KHR_vulkan_glsl 扩展规范编写的 GLSL 着色器来代替 SPIR-V。实现将自动检测着色器是 SPIR-V 还是 GLSL，并对其进行相应的编译。

弃用

此扩展中的功能超出了 Vulkan 的范围，最好由诸如 glslang 之类的编译器库来提供。没有新的实现将支持此扩展，因此应用程序不应该使用它。

新枚举常量

  • VK_NV_GLSL_SHADER_EXTENSION_NAME

  • VK_NV_GLSL_SHADER_SPEC_VERSION

  • 扩展 VkResult

    • VK_ERROR_INVALID_SHADER_NV

示例

示例 1

传入 GLSL 代码

    char const vss[] =
        "#version 450 core\n"
        "layout(location = 0) in vec2 aVertex;\n"
        "layout(location = 1) in vec4 aColor;\n"
        "out vec4 vColor;\n"
        "void main()\n"
        "{\n"
        "    vColor = aColor;\n"
        "    gl_Position = vec4(aVertex, 0, 1);\n"
        "}\n"
    ;
    VkShaderModuleCreateInfo vertexShaderInfo = { VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO };
    vertexShaderInfo.codeSize = sizeof vss;
    vertexShaderInfo.pCode = vss;
    VkShaderModule vertexShader;
    vkCreateShaderModule(device, &vertexShaderInfo, 0, &vertexShader);

版本历史

  • 修订版 1，2016-02-14 (Piers Daniell)

    • 初始草案

VK_NV_ray_tracing

名称字符串

VK_NV_ray_tracing

扩展类型

设备扩展

注册扩展号

166

修订

3

批准状态

未批准

扩展和版本依赖关系

     VK_KHR_get_physical_device_properties2
     和
     VK_KHR_get_memory_requirements2
或
Vulkan 版本 1.1

API 交互

  • 与 VK_VERSION_1_1 交互

  • 与 VK_EXT_debug_report 交互

  • 与 VK_KHR_get_memory_requirements2 交互

SPIR-V 依赖项
弃用状态
联系方式

其他扩展元数据

上次修改日期

2018-11-20

交互和外部依赖
贡献者

  • Eric Werness, NVIDIA

  • Ashwin Lele, NVIDIA

  • Robert Stepinski, NVIDIA

  • Nuno Subtil, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Martin Stich, NVIDIA

  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

  • Joshua Barczak, Intel

  • Tobias Hector, AMD

  • Henrik Rydgard, NVIDIA

  • Pascal Gautron, NVIDIA

描述

光栅化一直是生成交互式图形的主要方法，但是图形硬件性能的提高使得光线追踪成为交互式渲染的可行选择。能够将光线追踪与传统的光栅化集成，使得应用程序可以更容易地将光线追踪效果逐步添加到现有应用程序中，或者采用混合方法，使用光栅化进行主要可见性计算，而使用光线追踪进行辅助查询。

为了启用光线追踪，此扩展添加了几个不同类别的新功能

  • 加速结构对象和构建命令

  • 具有新着色器域的新管线类型

  • 一个将着色器组与加速结构项链接的间接表

此扩展在 Vulkan 中添加了对以下 SPIR-V 扩展的支持

  • SPV_NV_ray_tracing

新对象类型

新命令

新结构体

如果支持 VK_KHR_get_memory_requirements2 或 Vulkan 版本 1.1

新枚举

新位掩码

新枚举常量

  • VK_NV_RAY_TRACING_EXTENSION_NAME

  • VK_NV_RAY_TRACING_SPEC_VERSION

  • VK_SHADER_UNUSED_NV

  • 扩展 VkAccelerationStructureTypeKHR

    • VK_ACCELERATION_STRUCTURE_TYPE_BOTTOM_LEVEL_NV

    • VK_ACCELERATION_STRUCTURE_TYPE_TOP_LEVEL_NV

  • 扩展 VkAccessFlagBits

    • VK_ACCESS_ACCELERATION_STRUCTURE_READ_BIT_NV

    • VK_ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_NV

  • 扩展 VkBufferUsageFlagBits

    • VK_BUFFER_USAGE_RAY_TRACING_BIT_NV

  • 扩展 VkBuildAccelerationStructureFlagBitsKHR

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_COMPACTION_BIT_NV

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_UPDATE_BIT_NV

    • VK_BUILD_ACCELERATION_STRUCTURE_LOW_MEMORY_BIT_NV

    • VK_BUILD_ACCELERATION_STRUCTURE_PREFER_FAST_BUILD_BIT_NV

    • VK_BUILD_ACCELERATION_STRUCTURE_PREFER_FAST_TRACE_BIT_NV

  • 扩展 VkCopyAccelerationStructureModeKHR

    • VK_COPY_ACCELERATION_STRUCTURE_MODE_CLONE_NV

    • VK_COPY_ACCELERATION_STRUCTURE_MODE_COMPACT_NV

  • 扩展 VkDescriptorType

    • VK_DESCRIPTOR_TYPE_ACCELERATION_STRUCTURE_NV

  • 扩展 VkGeometryFlagBitsKHR

    • VK_GEOMETRY_NO_DUPLICATE_ANY_HIT_INVOCATION_BIT_NV

    • VK_GEOMETRY_OPAQUE_BIT_NV

  • 扩展 VkGeometryInstanceFlagBitsKHR

    • VK_GEOMETRY_INSTANCE_FORCE_NO_OPAQUE_BIT_NV

    • VK_GEOMETRY_INSTANCE_FORCE_OPAQUE_BIT_NV

    • VK_GEOMETRY_INSTANCE_TRIANGLE_CULL_DISABLE_BIT_NV

    • VK_GEOMETRY_INSTANCE_TRIANGLE_FRONT_COUNTERCLOCKWISE_BIT_NV

  • 扩展 VkGeometryTypeKHR

    • VK_GEOMETRY_TYPE_AABBS_NV

    • VK_GEOMETRY_TYPE_TRIANGLES_NV

  • 扩展 VkIndexType

    • VK_INDEX_TYPE_NONE_NV

  • 扩展 VkObjectType

    • VK_OBJECT_TYPE_ACCELERATION_STRUCTURE_NV

  • 扩展 VkPipelineBindPoint

    • VK_PIPELINE_BIND_POINT_RAY_TRACING_NV

  • 扩展 VkPipelineCreateFlagBits

    • VK_PIPELINE_CREATE_DEFER_COMPILE_BIT_NV

  • 扩展 VkPipelineStageFlagBits

    • VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_NV

    • VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV

  • 扩展 VkQueryType

    • VK_QUERY_TYPE_ACCELERATION_STRUCTURE_COMPACTED_SIZE_NV

  • 扩展 VkRayTracingShaderGroupTypeKHR

    • VK_RAY_TRACING_SHADER_GROUP_TYPE_GENERAL_NV

    • VK_RAY_TRACING_SHADER_GROUP_TYPE_PROCEDURAL_HIT_GROUP_NV

    • VK_RAY_TRACING_SHADER_GROUP_TYPE_TRIANGLES_HIT_GROUP_NV

  • 扩展 VkShaderStageFlagBits

    • VK_SHADER_STAGE_ANY_HIT_BIT_NV

    • VK_SHADER_STAGE_CALLABLE_BIT_NV

    • VK_SHADER_STAGE_CLOSEST_HIT_BIT_NV

    • VK_SHADER_STAGE_INTERSECTION_BIT_NV

    • VK_SHADER_STAGE_MISS_BIT_NV

    • VK_SHADER_STAGE_RAYGEN_BIT_NV

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_INFO_NV

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_MEMORY_REQUIREMENTS_INFO_NV

    • VK_STRUCTURE_TYPE_BIND_ACCELERATION_STRUCTURE_MEMORY_INFO_NV

    • VK_STRUCTURE_TYPE_GEOMETRY_AABB_NV

    • VK_STRUCTURE_TYPE_GEOMETRY_NV

    • VK_STRUCTURE_TYPE_GEOMETRY_TRIANGLES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_PROPERTIES_NV

    • VK_STRUCTURE_TYPE_RAY_TRACING_PIPELINE_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_RAY_TRACING_SHADER_GROUP_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_ACCELERATION_STRUCTURE_NV

如果支持 VK_EXT_debug_report

新的或修改的内置变量

新的 SPIR-V 功能

问题

1) 存在问题吗？

已解决：可以。

示例代码

示例光线生成 GLSL 着色器

#version 450 core
#extension GL_NV_ray_tracing : require
layout(set = 0, binding = 0, rgba8) uniform image2D image;
layout(set = 0, binding = 1) uniform accelerationStructureNV as;
layout(location = 0) rayPayloadNV float payload;

void main()
{
   vec4 col = vec4(0, 0, 0, 1);

   vec3 origin = vec3(float(gl_LaunchIDNV.x)/float(gl_LaunchSizeNV.x), float(gl_LaunchIDNV.y)/float(gl_LaunchSizeNV.y), 1.0);
   vec3 dir = vec3(0.0, 0.0, -1.0);

   traceNV(as, 0, 0xff, 0, 1, 0, origin, 0.0, dir, 1000.0, 0);

   col.y = payload;

   imageStore(image, ivec2(gl_LaunchIDNV.xy), col);
}

版本历史

  • 修订版 1，2018-09-11 (Robert Stepinski, Nuno Subtil, Eric Werness)

    • 内部修订

  • 修订版 2，2018-10-19 (Eric Werness)

    • 重命名为 VK_NV_ray_tracing，添加对可调用对象的支持。

    • 更新过多，无法一一列出

  • 修订版 3，2018-11-20 (Daniel Koch)

    • 更新为使用 InstanceId 而不是已实现的 InstanceIndex。

VK_NV_win32_keyed_mutex

名称字符串

VK_NV_win32_keyed_mutex

扩展类型

设备扩展

注册扩展号

59

修订

2

批准状态

未批准

扩展和版本依赖关系

VK_NV_external_memory_win32

弃用状态
联系方式

其他扩展元数据

上次修改日期

2016-08-19

IP 状态

没有已知的 IP 声明。

贡献者

  • James Jones, NVIDIA

  • Carsten Rohde, NVIDIA

描述

希望将 Direct3D 11 内存对象导入 Vulkan API 的应用程序可能希望使用本机键控互斥机制来同步 Vulkan 和 Direct3D 之间对内存的访问。此扩展提供了一种方法，当应用程序向队列提交命令缓冲区时，可以访问与导入的 Vulkan 内存对象关联的键控互斥锁。

新结构体

新枚举常量

  • VK_NV_WIN32_KEYED_MUTEX_EXTENSION_NAME

  • VK_NV_WIN32_KEYED_MUTEX_SPEC_VERSION

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_NV

示例

    //
    // Import a memory object from Direct3D 11, and synchronize
    // access to it in Vulkan using keyed mutex objects.
    //

    extern VkPhysicalDevice physicalDevice;
    extern VkDevice device;
    extern HANDLE sharedNtHandle;

    static const VkFormat format = VK_FORMAT_R8G8B8A8_UNORM;
    static const VkExternalMemoryHandleTypeFlagsNV handleType =
        VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_IMAGE_BIT_NV;

    VkPhysicalDeviceMemoryProperties memoryProperties;
    VkExternalImageFormatPropertiesNV properties;
    VkExternalMemoryImageCreateInfoNV externalMemoryImageCreateInfo;
    VkImageCreateInfo imageCreateInfo;
    VkImage image;
    VkMemoryRequirements imageMemoryRequirements;
    uint32_t numMemoryTypes;
    uint32_t memoryType;
    VkImportMemoryWin32HandleInfoNV importMemoryInfo;
    VkMemoryAllocateInfo memoryAllocateInfo;
    VkDeviceMemory mem;
    VkResult result;

    // Figure out how many memory types the device supports
    vkGetPhysicalDeviceMemoryProperties(physicalDevice,
                                        &memoryProperties);
    numMemoryTypes = memoryProperties.memoryTypeCount;

    // Check the external handle type capabilities for the chosen format
    // Importable 2D image support with at least 1 mip level, 1 array
    // layer, and VK_SAMPLE_COUNT_1_BIT using optimal tiling and supporting
    // texturing and color rendering is required.
    result = vkGetPhysicalDeviceExternalImageFormatPropertiesNV(
        physicalDevice,
        format,
        VK_IMAGE_TYPE_2D,
        VK_IMAGE_TILING_OPTIMAL,
        VK_IMAGE_USAGE_SAMPLED_BIT |
        VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT,
        0,
        handleType,
        &properties);

    if ((result != VK_SUCCESS) ||
        !(properties.externalMemoryFeatures &
          VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT_NV)) {
        abort();
    }

    // Set up the external memory image creation info
    memset(&externalMemoryImageCreateInfo,
           0, sizeof(externalMemoryImageCreateInfo));
    externalMemoryImageCreateInfo.sType =
        VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_NV;
    externalMemoryImageCreateInfo.handleTypes = handleType;
    // Set up the  core image creation info
    memset(&imageCreateInfo, 0, sizeof(imageCreateInfo));
    imageCreateInfo.sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO;
    imageCreateInfo.pNext = &externalMemoryImageCreateInfo;
    imageCreateInfo.format = format;
    imageCreateInfo.extent.width = 64;
    imageCreateInfo.extent.height = 64;
    imageCreateInfo.extent.depth = 1;
    imageCreateInfo.mipLevels = 1;
    imageCreateInfo.arrayLayers = 1;
    imageCreateInfo.samples = VK_SAMPLE_COUNT_1_BIT;
    imageCreateInfo.tiling = VK_IMAGE_TILING_OPTIMAL;
    imageCreateInfo.usage = VK_IMAGE_USAGE_SAMPLED_BIT |
        VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
    imageCreateInfo.sharingMode = VK_SHARING_MODE_EXCLUSIVE;
    imageCreateInfo.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;

    vkCreateImage(device, &imageCreateInfo, NULL, &image);
    vkGetImageMemoryRequirements(device,
                                 image,
                                 &imageMemoryRequirements);

    // For simplicity, just pick the first compatible memory type.
    for (memoryType = 0; memoryType < numMemoryTypes; memoryType++) {
        if ((1 << memoryType) & imageMemoryRequirements.memoryTypeBits) {
            break;
        }
    }

    // At least one memory type must be supported given the prior external
    // handle capability check.
    assert(memoryType < numMemoryTypes);

    // Allocate the external memory object.
    memset(&exportMemoryAllocateInfo, 0, sizeof(exportMemoryAllocateInfo));
    exportMemoryAllocateInfo.sType =
        VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_NV;
    importMemoryInfo.handleTypes = handleType;
    importMemoryInfo.handle = sharedNtHandle;

    memset(&memoryAllocateInfo, 0, sizeof(memoryAllocateInfo));
    memoryAllocateInfo.sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO;
    memoryAllocateInfo.pNext = &exportMemoryAllocateInfo;
    memoryAllocateInfo.allocationSize = imageMemoryRequirements.size;
    memoryAllocateInfo.memoryTypeIndex = memoryType;

    vkAllocateMemory(device, &memoryAllocateInfo, NULL, &mem);

    vkBindImageMemory(device, image, mem, 0);

    ...

    const uint64_t acquireKey = 1;
    const uint32_t timeout = INFINITE;
    const uint64_t releaseKey = 2;

    VkWin32KeyedMutexAcquireReleaseInfoNV keyedMutex =
        { VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_NV };
    keyedMutex.acquireCount = 1;
    keyedMutex.pAcquireSyncs = &mem;
    keyedMutex.pAcquireKeys = &acquireKey;
    keyedMutex.pAcquireTimeoutMilliseconds = &timeout;
    keyedMutex.releaseCount = 1;
    keyedMutex.pReleaseSyncs = &mem;
    keyedMutex.pReleaseKeys = &releaseKey;

    VkSubmitInfo submit_info = { VK_STRUCTURE_TYPE_SUBMIT_INFO, &keyedMutex };
    submit_info.commandBufferCount = 1;
    submit_info.pCommandBuffers = &cmd_buf;
    vkQueueSubmit(queue, 1, &submit_info, VK_NULL_HANDLE);

版本历史

  • 修订版 2，2016-08-11 (James Jones)

    • 基于 NV 外部内存扩展更新了示例代码。

    • 从 NVX 重命名为 NV 扩展。

    • 添加了概述和描述部分。

    • 更新了示例代码以使用 NV 外部内存扩展。

  • 修订版 1，2016-06-14 (Carsten Rohde)

    • 初始草案。

VK_VALVE_mutable_descriptor_type

名称字符串

VK_VALVE_mutable_descriptor_type

扩展类型

设备扩展

注册扩展号

352

修订

1

批准状态

未批准

扩展和版本依赖关系

VK_KHR_maintenance3

弃用状态
特殊用途
联系方式

其他扩展元数据

上次修改日期

2020-12-02

IP 状态

没有已知的 IP 声明。

贡献者

  • Joshua Ashton, Valve

  • Hans-Kristian Arntzen, Valve

描述

此扩展允许应用程序通过允许描述符根据写入或复制到描述符集中的描述符类型，变更为给定的描述符类型列表，从而减少描述符内存占用。

此扩展旨在解决的主要用例是使用 VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT 的描述符索引，其中描述符类型是完全通用的，因为这意味着应用程序可以分配一个大型描述符集，而不是每个描述符类型都拥有一个大型描述符集，这会显著膨胀描述符内存使用量并导致性能问题。

此扩展还添加了一种机制，用于声明描述符池，以及由此分配的描述符集，仅驻留在主机内存中；因此，这些描述符只能更新/复制，但不能绑定。

这些功能共同允许更有效地模拟原始 D3D12 绑定模型。此扩展主要用于 API 分层工作。

新结构体

新枚举常量

  • VK_VALVE_MUTABLE_DESCRIPTOR_TYPE_EXTENSION_NAME

  • VK_VALVE_MUTABLE_DESCRIPTOR_TYPE_SPEC_VERSION

  • 扩展 VkDescriptorPoolCreateFlagBits

    • VK_DESCRIPTOR_POOL_CREATE_HOST_ONLY_BIT_VALVE

  • 扩展 VkDescriptorSetLayoutCreateFlagBits

    • VK_DESCRIPTOR_SET_LAYOUT_CREATE_HOST_ONLY_POOL_BIT_VALVE

  • 扩展 VkDescriptorType

    • VK_DESCRIPTOR_TYPE_MUTABLE_VALVE

  • 扩展 VkStructureType

    • VK_STRUCTURE_TYPE_MUTABLE_DESCRIPTOR_TYPE_CREATE_INFO_VALVE

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MUTABLE_DESCRIPTOR_TYPE_FEATURES_VALVE

版本历史

  • 修订版 1，2020-12-01 (Joshua Ashton, Hans-Kristian Arntzen)

    • 初始规范，从公开草案中压缩而来。