Vulkan 1.2.180 Released With Two New Extensions
Vulkan 1.2.180 is out as the latest revision to this graphics/compute interface. Vulkan 1.2.180 comes with a number of fixes/clarifications to the spec plus the addition of two more extensions.
The new extensions to Vulkan 1.2.180 include:
VK_KHR_shader_subgroup_uniform_control_flow - The VK_KHR_shader_subgroup_uniform_control_flow extension allows the use of the SPIR-V SPV_KHR_subgroup_uniform_control_flow extension in shader modules. This SPIR-V extension in turn provides stronger guarantees that diverged subgroups will reconverge. This extension was pushed forward by NVIDIA and Google engineers.
VK_EXT_global_priority_query - The VK_EXT_global_priority_query device extension allows querying of the global queue priorities supported by a queue family. "It allows implementations to report which global priority levels are treated differently by the implementation, instead of silently mapping multiple requested global priority levels to the same internal priority, or using device creation failure to signal that a requested priority is not supported. It is intended primarily for use by system integration along with certain platform-specific priority enforcement rules."
That's about it for this routine Vulkan API update with the rest of the changes just being the usual spec churn. The updated spec is available from Vulkan.org.
The new extensions to Vulkan 1.2.180 include:
VK_KHR_shader_subgroup_uniform_control_flow - The VK_KHR_shader_subgroup_uniform_control_flow extension allows the use of the SPIR-V SPV_KHR_subgroup_uniform_control_flow extension in shader modules. This SPIR-V extension in turn provides stronger guarantees that diverged subgroups will reconverge. This extension was pushed forward by NVIDIA and Google engineers.
VK_EXT_global_priority_query - The VK_EXT_global_priority_query device extension allows querying of the global queue priorities supported by a queue family. "It allows implementations to report which global priority levels are treated differently by the implementation, instead of silently mapping multiple requested global priority levels to the same internal priority, or using device creation failure to signal that a requested priority is not supported. It is intended primarily for use by system integration along with certain platform-specific priority enforcement rules."
That's about it for this routine Vulkan API update with the rest of the changes just being the usual spec churn. The updated spec is available from Vulkan.org.
2 Comments