Progress Report: Linux 6.16
With Linux 6.16 now out in the wild, it’s time for yet another progress report! As we mentioned last time, the Asahi and Honeykrisp Mesa drivers have finally found their way upstream. This has resulted in a flurry of GPU-related work, so let’s start there.
No missing nuts in this Flatpak
For quite some time, we have maintained a version of our Mesa driver built against the Flatpak runtime and shipped it as a Flatpak runtime extension. This was required to enable GPU acceleration on Flatpak while our Mesa driver was not enabled upstream. As Flatpak runtime version 23.08 reaches end of life this month, this will no longer be necessary. 24.08 now ships with Mesa 25.1, and so will the forthcoming 25.08 runtime. Once 25.08 is released, we will be discontinuing the Flatpak runtime extension as it will serve no purpose.
A fully upstream graphics stack
Asahi uses DRM Native Context to paravirtualise the GPU. Rather than having to virtualise high-level APIs like DirectX and Vulkan, the VM runs the userspace component of the host’s native GPU driver. The host is then passed native GPU commands that it only needs to forward on to the kernel without modifying. This improves GPU performance inside muvm, our virtual machine for gaming on Asahi Linux. Until now however, this has relied on downstream patches to virglrenderer and Mesa.
We are pleased to announce that our DRM Native Context implementation has now been merged into the upstream virglrenderer project, and will therefore be enabled in upstream Mesa 25.2! This completes our transition to a fully upstream graphics stack, and as such we are retiring our Mesa fork completely.
GPU go brrrrr
Now that our Mesa driver is totally upstream, work on improving it has been able to occur rapidly. Alyssa has been hard at work over the past couple of months optimising performance. A whole mess of merge requests have found their way upstream, with the bulk of them being merged in time for the release of Mesa 25.2. Performance improvements are variable but decent, especially when paired with this month’s improvements to FEX’s JIT.
A fine vintage
Also new in Mesa 25.2 is support for VK_EXT_map_memory_placed, courtesy of
chaos_princess. This Vulkan extension allows applications to request GPU memory
be mapped at a specific address. WINE uses this when thunking 32-bit DXVK to
ensure any memory allocated by the GPU driver is within a 32-bit address space.
This is required to enable GPU acceleration for 32-bit Windows applications.
What’s that? Your 32-bit games already work in FEX? Well…
The stack we currently ship to enable gaming is quite a beast. At the bottom we have muvm, which spins up a micro VM (who would’ve guessed) using a kernel configured with 4K memory pages. FEX as it ships today requires this; the x86 architecture only supports 4K pages and we cannot “split” a memory page into smaller pages, only combine them to create pages of a larger size. Atop that is FEX, which translates x86 binaries so they can run on 64-bit ARM devices. But binary applications are very rarely self-contained monoliths. They require access to kernel functions via syscalls, system libraries like glibc, and access to the GPU via APIs like Vulkan.
The obvious solution—and the one used by FEX—is to translate the entire world. When FEX loads an x86 or amd64 application, its loader pulls whichever libraries the application binary is linked to from a disk image or mount point containing a multilib amd64 root filesystem, and translates them. The benefit here is that the application we want to run gets ABI-correct, native versions of any libraries it’s linked against. The disadvantages, however, are significant.
The image needs to have whichever libraries any arbitrary application could realistically be linked to. We either accept that some applications simply will not run, or we ship everyone an enormous filesystem image full of libraries for a foreign machine that they will likely never use. There are also the runtime costs associated with translating a bunch of libraries and faking syscall interfaces for their benefit. We can do better than this.
The emulation stack is being used overwhelmingly for gaming via WINE/Proton. For the sake of simplicity, let us simplify the problem space and say that our goal is not to run x86 Linux applications, but x86 Windows applications, and games especially.
Users of Windows on Arm will have noticed that it can run x86 applications. I’ll spare you the Windows NT history lesson for today, but the NT team’s almost religious focus on abstraction, portability and backward compatibility for nearly 40 years has given us three very important and beneficial features:
- WoW64, which thunks out 32-bit system calls to their 64-bit counterparts
- An API to plug binary translators into WoW64
- 64K virtual memory pages, regardless of the underlying physical page size
Since WINE implements WoW64 and FEX implements the WoW64 binary translator API,
AArch64 WINE is capable of running 32-bit x86 applications. Since all Windows
applications are allocated 64K pages, we theoretically (more on this in a bit)
don’t need to worry about page size. With VK_EXT_map_memory_placed, all of the
pieces of the puzzle are now in place; AArch64 WINE can now run 32-bit Windows
applications and games without muvm!
- We no longer have to paravirtualise the GPU, network access, or filesystem
- We no longer have to mangle and proxy the X11 or PipeWire protocols
- WINE can now use Wayland directly rather than be forced through XWayland
- FEX only has to translate x86 Windows code; WINE calls out to native AArch64 64-bit Windows and *nix
That said, your mileage may vary…
While it’s true that Windows allocates 64K virtual memory pages, not all applications respect this. Windows application developers have a long tradition of simply ignoring the Windows API, with game developers committing particularly heinous crimes in pursuit of performance. This often means baking x86-isms like 4K physical memory pages into code. Any applications which do this simply will not work, and will continue to require the use of muvm. You will however be able to use WoW64 inside muvm, and these applications will still reap most of the benefits from doing so.
You should also expect bugs in FEX and WINE, though unlike broken Windows applications from 2003, these have a pretty good chance of being fixed.
Want to try this out for yourself? Some distros already make this seamless; thanks
to chaos_princess once again, Gentoo automatically installs FEX’s WoW64
implementation on AArch64 systems when the wow64 USE flag is enabled. Simply
install your preferred WINE flavour with the wow64 USE flag and create a new
WINE prefix to get started!
On other distros, you will need to do some extra work:
- Ensure your distro builds AArch64 WINE with WoW64 enabled. This is not currently the case for Fedora, but is coming soon!
- Install WINE using your native distro packages
- Download the latest
fex-emu-winebuild from the FEX Ubuntu PPA - Extract
libwow64fex.dllonly to/usr/lib/wine/aarch64-windows/xtajit.dll - Create a new WINE prefix
Once you have a WINE prefix all set up, you can start enjoying your x86 Windows applications in a much improved fashion!
What about amd64/x86_64/x64 applications, you ask? Well unfortunately there are some challenges unique to making amd64 Windows code run on an AArch64 Windows environment which mean we don’t support this style of emulation for amd64 Windows applications.
…Yet.
We’re getting there…
As always, we have been hard at work upstreaming various bits and pieces.
Devicetree bindings for the GPU have been accepted and merged for 6.17, which allows us to stabilise how m1n1 initialises the GPU and forwards information onward to the kernel.
The SPMI controller driver, required for power management, landed in 6.16. The USB-C mux chips used in M3 Macs and above are also connected via SPMI bus, making this driver necessary for USB on those machines.
A bunch of audio-related patches have landed in 6.16 and are queued for 6.17. Some of these patches rework the upstream I2S controller driver, allowing the speaker amps to feed speakersafetyd the data it needs. This brings us very close to being able to upstream everything required to support speakers upstream.
The core SMC driver has been accepted for 6.17, along with subdevice drivers for its GPIO controller and reset controller functions. Combined, these allow the upstream kernel to not only shut down and reboot Apple Silicon Macs, but also enable the WiFi/Bluetooth module and USB Type A ports on machines with them. Also in the pipeline for upstreaming is the hwmon driver to enable fan control and access to the myriad hardware sensors present on these machines, the SMC HID driver to support power button presses for suspend/resume, and the SMC RTC driver to read and update the current system time.
With Linux 6.16, we also hit a pretty cool milestone. In our first progress report, we mentioned that we were carrying over 1200 patches downstream. After doing a little housekeeping on our branch and upstreaming what we have so far, that number is now below 1000 for the first time in many years, meaning we have managed to upstream a little over 20% of our entire patch set in just under five months. If we discount the DCP and GPU/Rust patches from both figures, that proportion jumps to just under half!
While we still have quite a way to go, this progress has already made rebases significantly less hassle and given us some room to breathe.
Miscellaneous fixes
Now that we have some time to do so, we have managed to progress a number of things that had been sitting on the backburner.
Plymouth, the system used to display a boot splash screen instead of TTY messages, broke its automatic DPI scaling on 13-inch laptops at some point recently. We have now been able to fix this.
A recent update to OBS broke screencasting on KMSRO systems implementing DRM explicit sync. This was found to be caused by compositor bugs, and has been fixed in kwin, and a merge request has been raised for Mutter. As those fixes are not yet released and other compositors might have the same issue, Janne added DRM syncobj support to the DCP driver in asahi-6.15.8-1 as a workaround.
Development on m1n1 has also started picking up again. The release of 1.5.0 marks the first new release since February. A number of small fixes were able to be merged, including a fix for boot time crashes caused by missing calibration data on Macs that have had their WiFi/Bluetooth module replaced. We also made it easier for distros to add a custom logo to m1n1.
Conference talks
Davide and Neal presented at Red Hat Summit and DevConf.CZ, covering the ongoing work on Fedora Asahi Remix and introducing a CentOS Stream port as part of their work in the CentOS Hyperscale SIG. This was also covered at CentOS Showcase in July.
Project merch
Want to show your love for Asahi Linux to the world? Now you can! Head over to HELLOTUX to buy official Asahi Linux merch. A portion of each sale is donated to the project. Many thanks to HELLOTUX for facilitating this!
Until next time!
Our next report should hopefully bring even more improvements and developments, so make sure to stick around. As always, a warm thanks goes out to our supporters on OpenCollective and GitHub Sponsors, without whom this would not be possible.