WSL graphics driver update brings better GPU support for Linux apps

When you work on a computer, the operating system you run almost completely determines what software you can run natively. But what if you want to work with applications written for a different system? For years, this was a problem that forced users to make a choice: either you come to the system, or you give up the application. Now this dynamic is starting to change. In late March 2026, Microsoft and the developer community behind the WINE project simultaneously published graphics updates that promise significantly better performance when running applications incompatible with the host system. This might seem like a technical detail, but in reality it means a paradigm shift – the boundaries between operating systems are becoming increasingly fluid.

Two unrelated graphics driver updates reached the developer community in the same week, and although they were created independently, they achieve exactly the same goal: significant improvement in graphics performance when running applications incompatible with the operating system on which they work. For the user, this means something simple: Windows games running on Linux will run faster, and Linux applications inside Windows Subsystem for Linux will show better GPU performance. For the industry, it means something much bigger – that traditional divisions between ecosystems are becoming increasingly irrelevant.

Dxgkrnl returns after four years of inactivity

The history of the dxgkrnl driver is fascinating from the perspective of technological evolution. Microsoft introduced it to a wider audience six years ago when it published an article promoting a new kernel driver that allows Linux running inside WSL2 (Windows Subsystem for Linux version 2) to access DirectX functionality of the host graphics card. This was a significant achievement – translating DirectX instructions from a Linux virtual machine to actual Windows hardware is a complicated operation that requires deep changes in the driver stack.

After its introduction in 2020, the driver remained virtually unchanged for four years. It received a major overhaul in 2022 – effectively version 2.0 – and a few months later Microsoft refactored the code for clarity and ease of review, labeling this as PATCH v3. Now, after almost exactly four years of waiting, a new patch appeared on the Linux kernel mailing list introducing version 4 of the driver.

This new version introduces support for compute-only GPUs, which are essential for running large language models (LLMs) – technology that has become ubiquitous in the AI industry in recent years. Additionally, the driver now supports multiple virtual GPUs per virtual machine and exposes driver buffers via dma-fence, a synchronization mechanism that prevents race conditions between processes. However, it should be remembered that DirectX itself remains closed, and the driver is useful only in the context of running it under Hyper-V on top of Windows – there is no universal solution here.

Four years between versions 3 and 4 might seem like a long time, but in reality they reflect the fact that many business applications running on WSL2 did not require drastic changes. However, the emergence of AI and the need to run LLMs in virtual Linux environments forced Microsoft to pay attention to this driver again.

WSL2 is not the same as its predecessor

To understand the significance of the dxgkrnl update, it's worth stepping back and explaining the WSL architecture. Modern WSL2 runs one actual copy of Linux inside Windows, with containers pretending to be different distributions. This is a radical change from the original WSL, now known as WSL1, which was introduced a decade ago. WSL1 provided a translation layer that converted Linux API calls to equivalent Windows calls – the technology comes from the long-defunct Project Astoria, a runtime environment created to run Android applications on Windows Phone.

Interestingly, WSL1 has more in common with how WINE works than with WSL2. WINE is also a translation layer, but working in the opposite direction – it converts Windows API calls to equivalent Linux calls. This approach allowed the WINE community for decades to keep older Windows applications running on Unix-like systems, but always with some cost to performance and compatibility.

The difference between WSL1 and WSL2 is crucial to understanding why the dxgkrnl update matters. WSL1 was more like WINE – a translation layer. WSL2 is more like a virtual machine – actual Linux running under a Hyper-V hypervisor. This means that WSL2 can potentially offer better performance for many scenarios, but requires a more complicated approach to accessing host resources, including the GPU.

WINE 11 and the 32-bit to 64-bit thunking revolution

While Microsoft was working on improvements for WSL, the community behind WINE was achieving its own breakthroughs. In 2024, WINE 9.0 introduced the 32-bit to 64-bit thunking feature – the ability to run 32-bit Windows binaries on 64-bit host systems without needing any 32-bit subsystem on the host. This was crucial for macOS, where all versions since 10.15 "Catalina" dropped support for 32-bit applications.

Now, with the release of WINE 11 this year, this functionality is so well integrated that the traditional wine32 and wine64 commands no longer exist. The user simply runs wine, and the system automatically handles different binary architectures. This might sound like a small detail, but for users trying to run old software on modern hardware, this is a change that can mean the difference between being able to run an application and complete inability to do so.

WINE's success in recent years is largely due to Valve. Their SteamOS 3 distribution, originally built for the Steam Deck portable gaming console, runs Windows games on Linux using Valve's Proton – software built on the basis of WINE and integrated with the Linux client for Valve's Steam gaming platform. SteamOS 3 has been so successful that Valve plans to introduce more Steam hardware later this year. This is no accident – Valve actively invests in improving compatibility because it has a direct financial interest in selling Linux-based hardware.

Valve's contribution to the Linux graphics ecosystem

Valve's success in selling consumer hardware based on operating system-level emulation not only drives Linux development – it also drives changes in OpenGL, the open graphics standard that has competed with Microsoft's closed DirectX for decades. In 2024, Derek Lesho from CodeWeavers filed a new issue on the mesa-dev mailing list: how to help WINE use 64-bit Mesa OpenGL drivers for 32-bit Windows applications.

The problem is classic for mixed-architecture computers. When WINE allocated a GPU memory block for a game using the glMapBuffer API, the address of that buffer would be a 64-bit address – but WINE couldn't pass that address to a 32-bit application if the address didn't fit within the 32-bit address range. Anyone who ever tried to add more than 4 GB of RAM to a Windows XP computer and discovered that 32-bit XP doesn't see the extra memory encounters the other side of the same problem.

After discussions in the developer community, the result was the creation of a new OpenGL API called MESA_map_buffer_client_pointer. Its description says: "This extension allows an application to specify ranges of pointers within which buffers should be mapped." In other words, when allocating a buffer, it allows the application to request that the buffer be located in a given address range, making it accessible to 32-bit code without slow copy operations.

OpenGL lives on, even though Vulkan took the future

More than a decade has passed since the industry media first widely described the Vulkan 1.0 specification, an open graphics standard that was supposed to replace both OpenGL and DirectX. However, despite the emergence of Vulkan and its adoption by many modern games, OpenGL development continues. Microsoft dropped support for 16-bit applications from Windows, and Apple removed support for 32-bit applications from macOS, but WINE is working to make old Windows binaries run well on modern 64-bit Unix-like operating systems.

This shows a fundamental difference in approach between technology giants and the open source community. While Microsoft and Apple can simply drop older formats, WINE must support them because many people still have software they want to run. The new MESA_map_buffer_client_pointer API is an elegant solution to this problem – it's not a hack or a workaround, but a proper extension of the standard.

Implications for users and developers

In practical terms, these two updates mean that a user can now run more applications with better performance on systems that were not originally intended for them. For someone working on Linux but needing to run an old 32-bit Windows game, the new OpenGL API means less lag and better responsiveness. For someone working on Windows but wanting to run GPU-intensive Linux tools, the dxgkrnl update means those tools will run significantly faster.

For developers, the implications are deeper. These updates show that both Microsoft and the open source community are interested in interoperability. This is not a victory of one system over another – it's an evolution toward a world where the boundaries between operating systems are increasingly transparent. A developer can write code once and expect it to work reasonably well on multiple platforms, without needing to maintain completely separate code bases.

Broader context: emulation as a business strategy

It's worth noting that these updates don't appear in a vacuum. They are part of a broader trend where operating system-level emulation and translation have become important business strategies. Apple did this with Rosetta 2 on Apple Silicon, allowing Intel applications to run on its ARM hardware. Microsoft is doing this with WSL, allowing Windows users to run Linux tools. Valve is doing this with Proton, allowing Linux gamers to run Windows games.

Each of these technologies has a different architecture and a different purpose, but all achieve the same goal: reducing friction when moving between ecosystems. This is important for users, but also has implications for competition. If a user can easily run applications from another ecosystem, it reduces "lock-in" – user attachment to a given platform.

The future: convergence or coexistence?

The question that remains is whether these updates represent steps toward convergence – where all operating systems become essentially interchangeable – or rather coexistence, where systems remain distinct but can work together seamlessly. Given current trends, coexistence seems more likely. Each operating system has its unique characteristics and user base, which won't disappear in the foreseeable future. But a future where running an application "incompatible" with the system is the norm rather than the exception seems increasingly real. These two updates are small steps in that direction, but small steps can lead to significant changes.