The Best April Fools' Joke in the Linux World? The Proposal to Integrate Zink in Wine That Actually Works

A merge request opened on GitLab by WineHQ could fundamentally change the way Wine handles OpenGL calls. Signed by Rémi Bernon, a developer at CodeWeavers (the company collaborating with Valve on the development of Proton), the proposal has a straightforward title: "opengl32: Just use Zink (as PE-side OpenGL implementation)." The announcement came on April 1st, and Bernon confirmed that the MR originated as a playful tribute to April Fool's Day, but at the same time specified that the code actually works and that the approach is "genuinely interesting and deserves to be explored."

The Architecture of the Proposal

The mechanism is simply formulated yet has substantial implications: the merge request directly incorporates a subset of Mesa 26.0.3 compiled as a Windows DLL, using Zink as the PE-side OpenGL implementation over a Vulkan layer, which is also PE-side. In practice, Windows applications running on Wine that make OpenGL calls would have them handled by Zink, which translates them into Vulkan calls before reaching the host driver. In the original proposal, Bernon reports that both Steam and Star Wars: Knights of the Old Republic work with this configuration: "which means everything else will as well."

On the performance side, Bernon admitted that the implementation is currently slower than the existing Unix GL bridge. This is not a dramatic downgrade since applications run and the outcome is usable, but in benchmarks such as those from the Unigine suite, the gap is measurable. This is an expected limitation for a proposal still in a raw form, not an indicator of the validity of the approach: Zink has already demonstrated over the years that it can reach and in some cases exceed the native OpenGL implementations, although it requires dedicated optimization work.

A Driver That Has Come a Long Way

Zink is not a recent project: the driver was introduced in 2018 by Erik Faye-Lund of Collabora as a hardware-accelerated OpenGL implementation for systems with only a Vulkan driver available. Technically, it is a Mesa Gallium driver: instead of generating hardware-specific commands like traditional drivers, it produces hardware-agnostic Vulkan calls that are then delegated to the system's Vulkan implementation. This mechanism allows for complete OpenGL support even when the GPU driver does not natively provide it, which has significant implications for both older hardware and GPUs without dedicated OpenGL drivers.

Since its introduction in 2018, Zink has undergone substantial improvements. A key milestone arrived in 2022 with the merge of Kopper, the component that allowed Zink to handle window system integration via Vulkan WSI. Before Kopper, using Zink required impractical combinations of environment variables; with Kopper, MESA_LOADER_DRIVER_OVERRIDE=zink is sufficient for any driver, and Zink acquires real swapchains with full compositor support. Mesa 26.0, from which the proposed subset for Wine is extracted, includes targeted fixes for the Zink driver in maintenance releases 26.0.2 and 26.0.3, including corrections to format conversion logic and image management.

Why the Proposal Makes Technical Sense

The rationale behind Zink's integration into Wine is related to cross-driver compatibility. Today, Wine's OpenGL layer acts as a bridge to the host system's OpenGL: inherited Windows applications thus depend on the quality of the OpenGL implementation of the driver installed on the user's machine. Vulkan operates at a lower level and tends to be less affected by variations between different implementations, resulting in a more predictable compatibility surface. Bernon explicitly cited macOS as an emblematic scenario: Apple has deprecated OpenGL for years, and the Unix GL bridge in Wine encounters structural compatibility problems on that platform that a PE-side implementation over Vulkan could effectively bypass.

The industrial context is not irrelevant. The focus of driver manufacturers has progressively shifted to Vulkan: the most obvious case is NVIDIA, which has retired the legacy OpenGL-based Nouveau driver in favor of NVK, the new open-source Vulkan implementation. If in the future other drivers were to abandon native OpenGL support, the ability to rely on an OpenGL implementation integrated within Wine, depending solely on the host Vulkan, would ensure compatibility without requiring changes to the system's infrastructure.

The Path Towards an ICD Architecture

Bernon indicated that the ideal long-term solution would not be choosing between the current Unix GL bridge and the PE-side Zink implementation but to make them coexist through an ICD mechanism (Installable Client Driver), similar to what is used by Vulkan. This would allow Wine to dynamically load the most suitable OpenGL implementation for the context, whether it be the Unix bridge for those with mature OpenGL drivers or Zink for those lacking it or having a partial implementation, without requiring manual intervention by the user. The author acknowledges that this path would require significant refactoring of Wine's OpenGL infrastructure and that the current merge request is far from that model; however, it remains a stated architectural goal. The proposal is currently under review, and it is not yet clear if and how much it will change before a potential merge into the official builds.