WSL graphics driver update brings better GPU support for Linux apps
Meanwhile, WINE and OpenGL tweaks speed Windows apps on 64-bit hosts
Whatever OS you run, you have a better chance to run non-native apps. Running Linux virtualized on Windows is set to speed up slightly, and so is running Windows apps on top of 64-bit Linux and macOS.
Two very different types of graphics driver stack both received updates this week, and although they are unrelated, both are pursuing the same goal: better graphics performance when running non-native apps on top of a different OS.
The first of these is one that The Register has mentioned before – albeit quite a long time ago. Six years ago, we covered Microsoft's new dxgkrnl driver, which allows Linux running under WSL2 to access the DirectX functionality of a GPU belonging to the host OS. Microsoft was keen to promote this at the time, and even now the driver has its own section on the Microsoft docs site.
Dxgkrnl hasn't been touched in almost exactly four years. After its introduction in 2020, it got a significant rebuild in 2022 – effectively version 2 – and a few months later Microsoft refactored the code for clarity and ease of review, labeling it PATCH v3. A new patch on the Linux kernel mailing list introduces version 4 of the driver.
This version supports compute-only GPUs, for running those painfully trendy – or just plain painful – LLMs, plus multiple virtual GPUs per VM, and driver buffer sharing via dma-fence. Of course, DirectX itself remains closed source, and the driver is no use in any other context except running under Hyper-V on top of Windows.
WINE continues to drive new development
WSL2 runs a single real copy of Linux inside Windows, with containers impersonating different distributions. It's a big contrast to the original WSL a decade ago. Now referred to as WSL1, it provided a translation layer to convert Linux API calls into Windows ones, derived from the long-gone Project Astoria runtime for running Android apps on Windows Phone.
As it happens, WSL1 bears more resemblance to how WINE works than it does to WSL2. WINE is also a translation layer that converts Windows API calls into Linux equivalents. As we reported in early 2024, WINE 9.0 introduced 32-bit to 64-bit thunking: it could run 32-bit Windows binaries on 64-bit host OSes, without using any 32-bit subsystem on the host – which is necessary for all versions of macOS since 10.15 "Catalina". With this year's WINE 11 release, this is so integrated that there are no wine32 or wine64 commands any more.
WINE is thriving in recent years thanks to Valve. Its SteamOS 3 distribution, originally built for the Steam Deck handheld games console, runs Windows games on Linux using Valve's Proton, which is built into the Linux client for Valve's Steam gaming platform. SteamOS 3 is doing so well that Valve is planning to launch more Steam hardware later this year.
There's still life in OpenGL yet
Valve's success in selling consumer gaming hardware based around OS-level emulation isn't just driving Linux development. It's driving changes in OpenGL as well.
Back in 2024, Codeweavers' Derek Lesho raised a new problem on the mesa-dev mailing list: Helping Wine use 64-bit Mesa OGL drivers for 32-bit Windows applications. Last year, he explained more on Mesa's GitLab. The problem affects WINE when it's running a 32-bit Windows game on a 64-bit host OS. When WINE allocates a block of GPU memory for the game using the glMapBuffer API, that buffer's address will be a 64-bit address – but WINE can't pass that address to a 32-bit application if the address won't fit into the 32-bit address range.
(Anyone who ever tried to add more than 4 GB of RAM to a Windows XP computer only to find that 32-bit XP couldn't see the extra memory encountered a different facet of the same issue.)
After some discussion, the result is a new OpenGL API, called MESA_map_buffer_client_pointer. Its summary says:
In other words, when allocating a buffer, it lets an application request that the buffer is within a given address range, so that it's reachable by 32-bit code without slow copy operations.
This extension allows the application to specify pointer ranges within which buffers should be mapped.
It's already a decade since The Register reported on the Vulkan 1.0 open graphics specification, but development is still happening in its forerunner, OpenGL. Even if Microsoft has dropped 16-bit app support from Windows, and Apple has discontinued 32-bit app support from macOS, WINE is working to keep those old Windows binaries running well on modern 64-bit Unix-like OSes. ®