Igalia, a consulting business that has been working on the Mesa V3DV open-source Vulkan driver for the Raspberry Pi 4 and newer, has given an overview of recent Mesa achievements.
Since becoming Vulkan 1.1 compliant at the end of last year, the Mesa V3DV driver has been steadily improving, adding additional extensions, more features, and improved performance.
More Vulkan extensions have been added to V3DV in the months afterward, including EXT debug utils for easier debugging, KHR timeline semaphore, KHR driver properties, EXT line rasterization, KHR spirv 1 4, KHR shader float controls, KHR pipeline executable properties, and more.
This open-source Vulkan driver for the Raspberry Pi now supports multi-sync in combination with the latest V3D DRM kernel driver, as well as Mesa's common synchronization framework, Android compatibility, and continued speed optimization.
Support for multisync
They attempted to focus as much as possible on the userspace aspect for the Vulkan driver, as described in previous blogs. As a result, they attempted to reuse the previously existing V3D kernel interface used by the OpenGL driver without altering or expanding it.
Except for synchronization, everything worked perfectly. Per submission, the V3D kernel interface only supported one synchronization object. This didn't match well with Vulkan synchronization, which is more comprehensive and complicated and allows many semaphores/fences to be defined. The first dealt with the problem by using workarounds and leaving some optional features unsupported.
They changed V3DV to use this new capability after finishing the 1.1 compliance work. For the time being, the driver uses one of two code paths, depending on whether or not the kernel supports this new capability. That implies the V3DV driver may expose a somewhat different set of supported features depending on the kernel.
Migration to the common synchronization framework will result in more shared code.
Mesa developers have been working hard for a long time to rework and transfer common functionality to a single location where it can be utilized by all drivers, decreasing the amount of code that each driver must maintain.
We've been migrating V3DV to portions of that infrastructure over the last few months, from tiny ones (common VkShaderModule to NIR code) to a major one (common synchronization framework).
The Vulkan synchronization model is extremely complex and strong, as previously stated. However, this also implies that it is complicated. Threads were heavily used in V3DV's Vulkan synchronization support. Because the GPU lacked a means for implementing vkCmdWaitEvents, V3DV had to rely on a CPU wait (polling with threads).
More extensions are supported:
Since the release of 1.1, the following extensions have been implemented and made public:
- VK_EXT_debug_utils
- VK_KHR_timeline_semaphore
- VK_KHR_create_renderpass2
- VK_EXT_4444_formats
- VK_KHR_driver_properties
- VK_KHR_16_bit_storage and VK_KHR_8bit_storage
- VK_KHR_imageless_framebuffer
- VK_KHR_depth_stencil_resolve
- VK_EXT_image_drm_format_modifier
- VK_EXT_line_rasterization
- VK_EXT_inline_uniform_block
- VK_EXT_separate_stencil_usage
- VK_KHR_separate_depth_stencil_layouts
- VK_KHR_pipeline_executable_properties
- VK_KHR_shader_float_controls
- VK_KHR_spirv_1_4
Android compatibility
Roman Stratiienko, who implemented and submitted Mesa modifications, was responsible for adding Android support for V3DV. We'd also want to thank the Android RPi team, as well as the Lineage RPi maintainer (Konsta), for creating and testing an initial version of that support, which served as the foundation for Roman's code. LineageOS images for the RPi4 are currently available, but I haven't tested it personally (it's on my personal TO-DO list).
Performance
We've been working on increasing performance as well as adding new features. The V3D shader compiler received the most attention, as enhancements to it would benefit both the OpenGL and Vulkan drivers.
However, one feature unique to the Vulkan driver (yet to be transferred to OpenGL) is the implementation of double buffer mode, which is only usable if MSAA is off. The tile buffer would be split in half in this mode, allowing the driver to begin processing the next tile while the current one is being stored in memory.
This might theoretically increase speed by lowering tile storage overhead, therefore it would be more useful when vertex/geometry shaders aren't too costly. However, it comes at the expense of lowering tile size, which has its own set of costs.
We don't activate this by default for the time being since testing reveals that it helps in some circumstances (like the Vulkan Quake ports) but damages in others (like Unreal Engine 4). V3D DEBUG=db can be added to the environment variables to selectively activate it. In the future, a heuristic might be used to determine when this mode should be activated.
Source- Phoronix
Please leave a comment if I missed anything.
