Vulkan 1.2.182 released with extensions to help VR and the OpenGL over Vulkan driver Zink

Another specification update for Vulkan is out now with Vulkan 1.2.182. As usual it cleans up some issues but it also brings in multiple new and interesting Vulkan extensions.

The new extensions are:

VK_EXT_acquire_drm_display

This extension allows an application to take exclusive control of a display using the Direct Rendering Manager (DRM) interface. When acquired, the display will be under full control of the application until the display is either released or the connector is unplugged.

Going from the pull request, it's mentioned it will help Wayland and VR. Hopefully once this is fully merged into Mesa and Wayland compositors can use it, the VR experience on Wayland will be improved.

VK_EXT_multi_draw

Processing multiple draw commands in sequence incurs measurable overhead within drivers due to repeated state checks and updates during dispatch. This extension enables passing the entire sequence of draws directly to the driver in order to avoid any such overhead, using an array of VkMultiDrawInfoEXT or VkMultiDrawIndexedInfoEXT structs with vkCmdDrawMultiEXT or vkCmdDrawMultiIndexedEXT, respectively. These functions could be used any time multiple draw commands are being recorded without any state changes between them in order to maximize performance.

This one is real interesting too, with software engineer Ricardo García of Igalia writing a blog post going into more detail. The big one here is that this extension came as a result of the Zink driver, which runs OpenGL over Vulkan. The idea is that it helps close the gap between OpenGL and Vulkan - so we might be able to see even better performance from it once this is all hooked up.

VK_EXT_physical_device_drm

This extension provides new facilities to query DRM properties for physical devices, enabling users to match Vulkan physical devices with DRM nodes on Linux.

Its functionality closely overlaps with EGL_EXT_device_drm1. Unlike the EGL extension, this extension does not expose a string containing the name of the device file and instead exposes device minor numbers.

DRM defines multiple device node types. Each physical device may have one primary node and one render node associated. Physical devices may have no primary node (e.g. if the device doesn’t have a display subsystem), may have no render node (e.g. if it’s a software rendering engine), or may have neither (e.g. if it’s a software rendering engine without a display subsystem).

VK_HUAWEI_subpass_shading

This extension allows applications to execute a subpass shading pipeline in a subpass of a render pass in order to save memory bandwidth for algorithms like tile-based deferred rendering and forward plus. A subpass shading pipeline is a pipeline with the compute pipeline ability, allowed to read values from input attachments, and only allowed to be dispatched inside a stand-alone subpass. Its work dimension is defined by the render pass’s render area size. Its workgroup size (width, height) shall be a power-of-two number in width or height, with minimum value from 8, and maximum value shall be decided from the render pass attachments and sample counts but depends on implementation.

VK_NV_ray_tracing_motion_blur

Ray tracing support in the API provides an efficient mechanism to intersect rays against static geometry, but rendering algorithms often want to support motion, which is more efficiently supported with motion-specific algorithms. This extension adds a set of mechanisms to support fast tracing of moving geometry:

• A ray pipeline trace call which takes a time parameter
• Flags to enable motion support in an acceleration structure
• Support for time-varying vertex positions in a geometry
• Motion instances to move existing instances over time

While this was contributed from NVIDIA, there shouldn't be anything stopping Mesa picking it up for AMD as the RADV developers continue bringing up Ray Tracing on the open source driver.