Explore the development, current state, and future plans of the open-source Vulkan driver for Raspberry Pi 4 in this 38-minute conference talk. Dive into the implementation challenges, including the driver's code name V3DV, its development process, and the use of Mesa Vulkan WSI. Learn about the iterative feature development using Vulkan CTS, regression testing strategies, and the progress towards Vulkan 1.0 conformance. Discover performance considerations, GPU execution expectations, and specific challenges related to the Raspberry Pi 4's linear display pipeline. Gain insights into format handling, shader compilation optimizations, and proposed solutions for device matching. Understand the long-term goals, including improved TFU unit usage, WSI platform support, and potential Vulkan 1.1 compatibility. Explore opportunities for code reuse with the GLES driver and the ongoing efforts to expand optional features and extensions.
Overview of the Open Source Vulkan Driver for Raspberry Pi 4
Overview
Syllabus
Overview of the Open Source Vulkan Driver for Raspberry Pi 4
Development story . Current state Implementation challenges • Future plans . Contributing
Driver code name: V3DV. • Development started in a public fork of Mesa. • Leverages Mesa Vulkan WSI. • Expands existing V3D NIR compiler. . Same kernel interface as V3D.
Initial early milestone to render on hardware. • Vulkan CTS to help iterative feature development - Requires minimal functionality in the driver first. - Helped improve CTS coverage.
Growing subset of CTS for regression testing. - Parallel deqp runner for faster execution. - Currently -10K tests (-10% of CTS pass list). • Weekly rebases and full CTS runs. • Assert everywhere philosophy. • Progress updates via blog posts.
Vulkan 1.0 mandatory feature set complete. - A bunch of optional features too. - Many optional features and extensions missing. . Current focus on CTS conformance. - Passing -110K tests, -4 fails to go.
Not much performance work yet. - Mostly for the Quake games. - VkQuake3 much faster than its GL1 renderer.
Aware of some slow paths in the driver. - Particularly for some cases of transfer ops. - Possibly underused TFU unit.
Vulkan expects everything to execute in GPU. - Not quite possible for us in a few selected cases. - Caused some implementation churn. - Incurs in additional coordination (flushes).
Linear display pipeline in Raspberry Pi 4 - V3D cannot sample from linear images. - For now, we don't support sampling on swapchains. - We should be able to sample in windowed mode when running inside a compositor... worth it?
formats for optimal performance. - We don't know formats until descriptors are bound. Pre-compile 2 shader variants in advance. • Optimal case: use 16-bit return size • Fallback case: use 32-bit return size
Optimal path requires PCI GPU and VK_EXT_pci_bus_info. - Raspberry Pi display device is not a PCI device. • We just want to check that DR13 device matches. - RFC MR with a solution proposed.
Long term: - Explore better TFU unit usage. - Better WSI platform support. - Optimal implementation of input attachments. - Optional features & extensions - Maybe Vulkan 1.1?
Improve code reuse with GLES driver. - Maybe port some features to GLES driver
Taught by
Linux Foundation
