I am happy to be celebrating an important achievement this week: the PowerVR open-source Vulkan driver now (as of Mesa 26.1) has support for Zink. With it, the driver can support a much greater library of applications.
Zink solves the problem of running OpenGL and OpenGL ES applications through Vulkan. It is a translation layer that, instead of targeting a specific GPU architecture, emits Vulkan API calls. This can be used to get full desktop OpenGL support on devices that only support Vulkan, as well as OpenGL ES support for those app developers and vendors in the mobile and embedded space.
Translation layers have become a valuable option in the industry to mitigate the obsolescence of previous generations of Graphics APIs by building on top of newer, more capable and more performant ones, for example Vulkan. Zink is not the only layer in town: Google, for instance, maintains its own solution called ANGLE that helps Android with the inevitable phase-out of WebGL and OpenGL ES.
In the software graphics industry, OpenGL and OpenGL ES have been undisputed landmarks since the early 90s and are the backbone of an entire generation of 3D accelerated applications, some of which are still in use today but may never be ported to Vulkan. We wanted our open-source driver to be able to accelerate these OpenGL (ES) based applications, but as a Vulkan-only implementation it needed a means of backwards compatibility. Adding support for Zink was one of the most future-proof design decisions Imagination has made in the software space.
In order to support Zink, we needed the PowerVR driver to meet some fundamental software requirements and, in open-source, requirements can be a moving target…
When we initially started the project, Zink only required Vulkan 1.0, in addition to a whole raft of Vulkan extensions (in the region of 20), as well as optional features and pixel formats to be supported. By the time our team had nearly finalized the work to meet those requirements on Imagination’s AXE-1-16M GPU, Zink had increased the minimum version to Vulkan 1.2. Another notable additional requirement was VK_KHR_dynamic_rendering, which greatly modernises and simplifies the Zink implementation.
By October 2025, all of the work done on Vulkan 1.2 had been merged into upstream Mesa (see here, here, here); and in the last four months we have been working to fill in the missing pieces to fully enable upstream Zink support. This work included:
VK_EXT_dynamic_rendering, which came with a few challenges: it is big, intrusive (code-wise) and has the potential to regress a wide number of tests. We aimed for a clean way to add new code that will only be exercised by dynamic rendering, thus narrowing down the scope of possible regressions. Future improvements include removing legacy renderpass code. In fact, thanks to the implementation available in the Mesa Vulkan Runtime, we can provide the same functionality via dynamic rendering.
VK_EXT_image_drm_format_modifier, the work on which really shows that open source software can benefit from contributions made by the community. Imagination in the last months has been able to push upstream a long backlog of changes. We wanted to enable development in the public domain and the feedback received from the community was very positive - ultimately this made it possible for others to contribute. We would like to thank 👋Icenowy Zheng for the help and engagement with PowerVR based platforms, like the BXM-4-64 GPU, to proactively test and upstream the KMSRO side of changes (more on KMSRO later), and for sharing an implementation of VK_EXT_image_drm_format_modifier. Likewise, a big thanks to 👋Erico Nunes for upstreaming a Vulkan renderer for Weston and for pioneering the use of it with the PowerVR driver.
Thank you also to 👋Ella Stanforth for helping with VK_KHR_sampler_ycbcr_conversion, the extension is indirectly needed for Zink, in fact it is a dependency of VK_EXT_image_drm_format_modifier. This YCbCr extension is hardware specific and relies on how the GPU handles a completely new class of pixel formats and their layouts in memory.
The final major piece of the work we needed to do was to extend Zink to make use of the KMSRO (Kernel Mode Setting Render Only) Mesa framework. This is necessary because, up until now, upstream Zink has only been compatible with devices where the GPU and display controller are managed by the same kernel driver. As Imagination only provides IP for the GPU, not display controllers, in our case there are actually two kernel drivers, and thus devices: one for our GPU IP, which we maintain, and a second one for the display controller IP, which is maintained by someone else. KMRSO takes care of "gluing" these two devices together, which allows us to allocate memory via one kernel driver (the display driver in our case) and to then share this with the other kernel driver (the GPU driver in our case). Without this it isn't possible to render an image and to then display this on a display or monitor.
With all these pieces in place, Imagination’s open-source driver can now support Zink. The work for passing the Khronos Conformance Suite for Vulkan 1.2 and OpenGL ES is kicking off now and we look forward to keeping you all posted on the progress in the coming months.
I would like to take this opportunity to thank the Mesa community for designing, developing and maintaining the Zink framework.
I also believe that this is one of those milestones that demonstrate how well several parties in the open source development process can work together. We appreciate the contribution of everyone who invested the time and effort to bring PowerVR one step forward, including by reviewing and support with patches. Thanks go to:
Ella Stanforth
Icenowy Zheng
Erico Nunes
Erik Faye-Lund
Simon Peretta
Frank Binns