Mesa 24.1 is out, and the graphics team at Collabora has been working hard to bring a slew of new features and bug fixes to Panfrost, Zink, NVK, and Mesa in general. Let's take a look at the contributions made by Collabora for this release cycle.

Panfrost

Mesa 24.1 finally brings support to the Panfrost OpenGL and OpenGL ES driver for Arm Mali v10 GPUs, as found in SoCs such as RK3588. The kernel driver was also merged for the 6.10 kernel release, bringing full upstream support to these systems.

On the Vulkan side, Boris Brezillon and others have also been hard at work refactoring PanVK to prepare it for Mali v9 and v10 support. Previously, most PanVK work focused on Mali v8 which differs significantly from v9 and v10. Mali v9 brought bindless support and completely reworked the binding model as well as the shader ISA. The new CSF in v10 will significantly impact how the Vulkan driver models command buffers and job submission. Full v10 support in PanVK still needs some work but is now underway.

We're also modernizing PanVK to be able to leverage more of the common Vulkan runtime in Mesa. Mary Guillemard reworked PanVK properties to make better use of the framework code. In the process, she fixed a bug with the driverUUID we were reporting and enabled the VK_KHR_driver_properties extension. Boris implemented VK_KHR_push_descriptor in preparation for using the common meta framework for copies, resolves, and blits. Constantine Shablia implemented bufferDeviceAddress.

On the OpenGL side, Eric Smith fixed several bugs affecting stencil clears, CPU/GPU synchronization, polygon offset, indirect compute dispatch, and others. Erik Faye-Lund fixed a bug with large texture buffer sizes, added driconf support, and made performance debug messages visible to applications. Louis-Francis Ratté-Boulianne fixed a bug with AFBC-packed textures and Constantine fixed a bug with 1D array textures on Bifrost, affecting both OpenGL and Vulkan.

As part of adding v10 support, we also increased the kernel requirement of the Mesa Panfrost drivers to require version 1.1 of the kernel interface. Version 1.1 is 5 years old at this point so this shouldn't impact most users.

Zink

The big news for Zink this week is that Zink+NVK is now a conformant OpenGL 4.6 implementation! Faith worked with Mike Blumenkrantz (Valve) to fix a handful of Zink bugs, OpenGL CTS bugs, and a couple of NVK bugs to get there. This is the second Vulkan driver to be able to get OpenGL 4.6 conformance with Zink. Imagination has been OpenGL 4.6 conformant with Zink since last July.

Corentin Noël and Gert Wollny have been working to harden the Zink codebase. Corentin fixed many uninitialized variables, fixed memory leaks on failure paths, and reduced the memory footprint of many structures while Gert fixed a bunch of Vulkan validation errors. Gert also restructured the resource and shader texture instruction emission code.

NVK

Mesa 24.1 is also the first release in which NVK is no longer considered experimental. It's both Vulkan 1.3 conformant and OpenGL 4.6 conformant when paired with Zink. We've also fixed a lot of bugs since the 24.0 release. At this point, a lot of games are working out-of-the-box on NVK and, while no one is going to claim it's bug-free, it is now ready for deployment and broad user testing.

NVK development continues to proceed at a brisk pace. Faith Ekstrand implemented a bunch of new features, including:

• VK_KHR_incremental_present
• VK_KHR_maintenance5
• VK_KHR_maintenance6 
• VK_KHR_pipeline_library 
• VK_KHR_shader_maximal_reconvergence
• VK_KHR_shader_subgroup_uniform_control_flow
• VK_KHR_zero_initialize_workgroup_memory
• VK_EXT_depth_range_unrestricted 
• VK_EXT_drm_format_modifer
• VK_EXT_graphics_pipeline_library 
• VK_EXT_map_memory_placed 
• VK_EXT_memory_budget 
• VK_EXT_pipeline_robustness 
• VK_EXT_queue_familiy_foreign 
• VK_EXT_shader_object 
• VK_NV_shader_sm_builtins 
• shderStorageImageMultisample
• variableMultisampleRate

While some of the features on that list are fairly small, a few required significant effort. VK_KHR_shader_maximal_reconvergence and VK_KHR_shader_subgroup_uniform_control_flow required substantial NVIDIA back-end compiler work. VK_EXT_drm_format_modifer has been in the works for several months but was stalled on pre-existing Nouveau OpenGL driver issues. We finally came to a compromise and merged the feature a couple of weeks ago. This fixed GameScope and also makes Zink more robust.

Faith continues to mentor many new developers as the Nouveau community slowly rebuilds. She worked closely with Mohamed Ahmed at Valve for several months to implement sparse residency support for NVK. Mohamed also helped some with the implementation of VK_EXT_drm_format_modifer. There were another 4 other new developers who implemented 14 minor extensions under Faith's guidance.

Mary Guillemard implemented 16-bit float support as well as multiple new back-end compiler passes.

We've also slowly incorporated more Rust into NVK. The NVIDIA back-end compiler used by NVK has always been written in Rust but the rest of the driver remained written in C. Daniel Almeida ported the NVIDIA image layout library to Rust. This is one necessary step on the way towards a Rust Vulkan driver. In the meantime, it allows us to use Rust's powerful type system to enforce correct unit conversions, preventing a whole class of tricky and subtle image layout bugs.

Mesa common core

Erik Faye-Lund implemented GL_EXT_texture_storage support and chased down a nasty interaction between GL_BGRA / GL_BGRA8 formats and rendering. This resulted in OpenGL specification and CTS changes in order to prevent breaking shipping applications.

Daniel Stone has been cleaning up the DRI layer to standardize on Mesa's PIPE_FORMAT enum. This should make it easier and more straightforward for drivers to advertise display formats.

VK_EXT_map_memory_placed is a new extension that has been in development for a while but finally shipped in the Vulkan spec. It provides clients with the ability to specify where in their address space a Vulkan memory object should be mapped. This is intended for use by Wine and similar layers that want more direct control over memory mapping. In particular, Wine needs it for WoW64 where they implement 32-bit Windows APIs on top of a 64-bit userspace. They need to be able to ensure that Vulkan memory maps end up in the lower 32 bits of the address space. Previously, they were allocating memory on the host using memfd() or similar and mapping it into the GPU using VK_EXT_external_memory_host. However, such memory can never live in VRAM and the performance of imported host memory is never quite as good as if it's allocated by the GPU driver. This gives Wine the control it needs without the restrictions of host allocations. Faith Ekstrand wrote the extension itself and implemented it in both NVK and the Intel Vulkan driver (ANV).

Faith also reworked the way that Vulkan drivers and OpenCL implementations interface with Mesa's SPIR-V front-end. Previously, every Vulkan driver carried a hand-typed table of SPIR-V capabilities which only mostly matched the actual capabilities in the SPIR-V specification. With this rework, the list of capabilities is now generated from the Vulkan features and extensions the driver exposes, and the mapping from Vulkan features to SPIR-V capabilities is auto-generated from the Vulkan XML.

When implementing VK_EXT_graphics_pipeline_library and VK_EXT_shader_object for NVK, Faith added a new common pipeline framework to the Mesa Vulkan runtime. With this, drivers only need to implement shader objects and they get the rest of Vulkan pipelines for free. With the complexity added to pipelines by VK_EXT_graphics_pipeline_library, moving pipelines into shared code is becoming increasingly important. With this shared implementation, we can get all those details correct in one place and drivers can remain relatively simple. NVK has been using the new pipeline framework since it landed and the PanVK team is working on porting PanVK as well.

Related Posts

Implementing DRM format modifiers in NVK

Re-converging control flow on NVIDIA GPUs - What went wrong, and how we fixed it

NVK is now ready for prime time

Related Posts

Implementing DRM format modifiers in NVK

Re-converging control flow on NVIDIA GPUs - What went wrong, and how we fixed it

NVK is now ready for prime time