As spring slowly shakes the Northern Hemisphere from the winter gloom, that can mean only one thing: daylight savings desynchronization wrecks everyone's calendars. So what better way to deal with the first week of confusion than to get together in person at Embedded World in Nürnberg instead of figuring out if your call is anchored to North American or European time?

Our stand at Embedded World covered a huge amount of ground: from wall scanners running updateable Apertis, to a wall full of recent SoCs demonstrating boot and functional testing just as we do in KernelCI and Mesa CI, to open source remote rendering for XR headsets, to real-time AI video analytics, and more. But, given I'm a graphics person, I want to focus on three graphics-centric demos we presented.

End-to-end HDR with upstream technologies

As has been very well documented, our journey with Wayland color management has been a long one. We were thrilled to be able to take a Rockchip RK3588 SoC, on which we have done an immense amount of upstream work, showing a full end-to-end HDR pipeline with V4L2 decoding an AV1 media stream, integrated into a simple client application with GStreamer's V4L2 and waylandsink elements, pushing the stream through Weston on its way to the final display.

The client was toggling between two modes: when the video was unoccluded, we were able to pass the video through directly to the display hardware without any intermediate composition steps. However, the client would periodically create an SDR surface, at which point Weston would use the GPU to composite SDR and HDR together - a notoriously difficult problem. This demonstrates that the open source community now has a comprehensive solution available for color-management issues, being able to dynamically switch between modes with high-quality results instead of fixed pipelines for fixed use cases. Being able to dynamically select the most efficient path shows significant power savings: in this case, the difference between GPU composition and direct display varied between a 200-500mW saving, depending on the content.

This flexibility and genericism are important because we believe that proper HDR and fully color-managed workflows should be available to all users as baseline functionality. We believe that it shouldn't be restricted to those who buy professional equipment or license-specific software and spend weeks configuring it on particular hardware. Much of our work went into making sure that we had a good, flexible base for the future, enabling this to work as widely as possible.

A significant milestone in this journey, which was somewhat buried in the GStreamer 1.26 release notes, was bridging the worlds of multimedia and graphics by being able to convert between V4L2's format codes and the DRM format/modifier pairings. Whilst converting a 32-bit integer into one 32-bit and one 64-bit integer isn't the most exciting achievement on the face of it, doing this allows us to eliminate a copy when exchanging buffers between video codecs and the graphics/display subsystem, including compressed or deep-color buffers.

A huge thanks to Collaborans Pekka Paalanen (whose color management journey started by creating the canonical open source color-management glossary to just get us on the same page with terminology) and Leandro Ribeiro for their tireless work on the upstream color-management protocol and its implementation, Nicolas Dufresne for his work on V4L2 and GStreamer, Derek Foreman and Cristian Ciocaltea for their work on the RK3588 display driver, and to Robert Mader for his tireless efforts gluing everything together all across the stack.

PanVK on a brand-new SoC

Right next to the HDR demo was a Radxa Orion O6 board, powered by the CIX CD8180 SoC. The Orion was of course running Weston, demonstrating Mesa's Panfrost (OpenGL ES) and PanVK (Vulkan) support. The impressive part of this is that we only got our hands on this SoC around a month ago: before then, we had never had hardware for that GPU generation. Within that time, we had the demo on the stand, running multiple workloads side by side, with zero issues or crashes across the three days.

Whilst our work on open source Mali support has been a huge effort by many people over many years, including several people not mentioned in that post who have joined our team since, this demo was particularly made possible by a heroic effort from Mary Guillemard, who has over the last two months tirelessly worked to bring support for not only the v12 Mali-G720 GPU in the Orion, but also for the v13 Mali-G925 GPU. We will have more to share on this throughout the year, but it is already on par with the well-supported Mali-G610 in the RK3588 for feature support and conformance test results.

Our journey with Mali support began trying to catch up with the most basic support for GPUs released several years ago, and has now got to enabling GPUs before the silicon ever hits commercial products. PanVK is rocketing through Vulkan support, now fully supporting Vulkan 1.1 and rapidly moving through newer Vulkan versions to catch up with Vulkan 1.4 support as soon as we can. Supporting seven GPU generations definitely comes with its complexities, but we are very much committed to supporting the full family of Mali GPUs to the best of its capabilities.

NVK and WebGPU, out of the box

Finally, flanking the HDR demo on the other side, was an incongruous gaming laptop, using a stock Google Chrome build which would display a warning bubble when opened: warning you that WebGPU support was experimental and not yet ready for production. We dismissed it and launched two WebGPU demos at their highest level of complexity.

These demos were running on Mesa's open source NVK driver to provide Vulkan support for the NVIDIA GPU, with Zink to provide OpenGL support. This was made possible by some final fixes to Zink that we root-caused and fixed a couple of weeks ago, enabling us to flip the switch to enable NVK and Zink by default on Mesa, finally giving people with NVIDIA hardware a fully conformant and performant graphics stack.

Over the past couple of years we've worked hard to bring first-class NVIDIA support to Mesa. As usual, this has not just been the driver itself, but a huge amount of work to Mesa's common Vulkan runtime to lift Vulkan support for the whole of Mesa, a framework to allow more driver code to be written in Rust, and more. To that end, we're also working alongside Danilo Krummrich and Lyude Paul from Red Hat, plus the Asahi community and other contributors such as Alice Rhyl from Google and Rob Herring from Arm, to enhance the kernel's support for Rust-based DRM drivers to bring more safety to Mali, alongside the new NVIDIA kernel driver.

This demo was so personally pleasing as it brought together two strands of work over the past few years: firstly NVK itself which Faith, Daniel Almeida, Mary Guillemard, and Rebecca Mckeever have worked on alongside external contributors like Dave Airlie, Karol Herbst, and Mel Henning to bring to production quality. Secondly, Zink which we started in 2018 as a long-term tilt to help the industry shift to Vulkan, which has seen an enormous amount of work from Erik Faye-Lund, Antonino Maniscalo, Igor Torrente, and others, with Mike Blumenkrantz currently carrying the torch with a relentless focus on desktop performance. We decided to push for NVK in order to address Mesa's last remaining blind spot, and we're so happy with the results. We hope you are too when it comes very shortly to a distribution near you.

Making the sausage

Our raison d'être is to accelerate the adoption of open source technologies, methodologies, and philosophy. As a consultancy, we work with a wide variety of partners from across the industry to help make this happen.

All the work we've discussed above has been a combination of Collabora's own investment, and directly-sponsored project work. Unfortunately we can't name everyone who has helped us by sponsoring the work that's gone into this, but we'd like to thank all our customers for enabling this to happen. Every project we do helps sponsor our upstream work: our initial work on everything from Wayland itself to Panfrost to NVK was not direct project work, but paid for out of our own pocket as part of our commitment to keeping upstream Linux healthy and sustainable. So thanks to everyone who has not only directly sponsored the project work that's gone into all these showcases, but on all the other projects which do contribute to our long-term investment in healthy upstream projects. (As always, our operators are standing by to take your call.)

Related Posts

Embedded World 2025

12 years of incubating Wayland color management

Mesa 25.0: PanVK moves towards production quality

Related Posts

Embedded World 2025

12 years of incubating Wayland color management

Mesa 25.0: PanVK moves towards production quality