XeSS XMX on Linux: Proton Gets a Patched Mesa Driver

By Indie Kings | October 20, 2026

Updated October 20, 2026: A community project called XeSS XMX on Linux is running Intel's XeSS super resolution and frame generation on the XMX matrix units inside Proton games. The latest release, dated October 18, 2026, pairs an igdext64.dll shim with patched Mesa ANV drivers for Mesa 26.1.2 and 26.3.0-rc1. It does not need a Windows driver and does not patch Proton or vkd3d-proton, but it does replace the 64-bit Intel Vulkan driver for the user session.

The one-sentence version: stock Proton runs XeSS through the slower DP4a path on Intel Arc, and this project gives the game's own XeSS kernels a way to compile and run on the GPU's matrix units instead.

Image credit: GitHub repository card for HHHHanasak1/xess-xmx-linux.

The problem: XeSS on Linux is not using XMX

Intel's XeSS has two paths. One uses the XMX matrix units on Arc GPUs and runs the model's kernels on dedicated hardware. The other uses DP4a instructions, a lower-precision dot-product path that works on a wider range of GPUs. On Windows, the driver and the XeSS runtime choose the XMX path when the hardware supports it. On Linux under Proton, the game often gets the DP4a path instead, because the Windows driver interface the XeSS runtime expects is not there.

The practical result is that an Arc GPU can run XeSS on Linux, but not at the quality and performance level its hardware was built for. The project's README is blunt about the gap: without the Intel extension, XeSS frame generation is limited to 2x, and super resolution falls back to the generic path. The XMX path is the one that makes XeSS interesting on Arc.

This is not a new problem, and it is not unique to XeSS. Intel's graphics stack on Linux has been catching up to its Windows stack for years, and features that depend on Windows driver interfaces often arrive later or through community work. What makes this project notable is that it closes the gap without waiting for Intel to ship a new driver.

How the shim and the patched driver work

The project has two halves. The first is igdext64.dll, a shim built on Intel's open-source dxvk-igdext. It answers XeSS's driver queries as if an Intel driver were present and accepts every C-for-Metal, or CM, kernel XeSS submits, handing back a placeholder instead of failing the call.

The second half is a patched Mesa ANV Vulkan driver. When XeSS submits one of those placeholder kernels, the patched driver compiles the real kernel with Intel's graphics compiler, IGC, on first use. The compiled kernel runs inside the normal vkd3d-proton queue, in place of the placeholder. The result is the game's own XeSS model running on the GPU's XMX units, not a replacement upscaler.

That design is why the project can work without a Windows driver and without changing Proton or vkd3d-proton. It does not translate the game or replace its upscaler. It gives the existing XeSS runtime the driver behavior it expects, then compiles the kernels the runtime was already trying to run.

The installation writes environment variables into ~/.config/environment.d/50-xess-xmx.conf. It selects the patched driver as the 64-bit Intel Vulkan driver, keeps the other GPUs' drivers and the 32-bit Intel driver in the list, and sets VKD3D_DISABLE_EXTENSIONS=VK_EXT_descriptor_buffer, which the kernel binding needs. It also sets force_vk_vendor=0, because Mesa hides the Intel GPU from some games. Those variables apply to every D3D12 game in the session, not just the game being tested.

The shim is copied into every Proton that bundles an igdext64.dll and into every prefix, with the original kept as .stock. A watcher repeats that after a Proton update and for a new prefix. A session check runs before every graphical session and verifies that the patched driver loads and finds the GPU. If it does not, the other driver in the package takes over; if both fail, the session uses the stock drivers and XeSS falls back to DP4a.

What hardware it has been tested on

The project was developed on an ONEXPLAYER 3 with an Arc B390, which is Intel's Xe3 architecture, running SteamOS with Mesa 26.1.2 and 26.3, plus GE-Proton 11-6 and Proton Experimental. A contributor tested an Arc B580, which is Xe2 Battlemage. The README says Lunar Lake is untested, and Xe-HPG Alchemist and Xe-LPG are detected but untested.

That is a narrow hardware list, and the project says so. It is not claiming support for every Intel GPU or every Proton version. The requirements are Xe3 Panther Lake or Xe2 Battlemage on the xe or i915 kernel driver, the patched drivers in the archive and vkd3d-proton as shipped in Proton 11 or GE-Proton 11. Native Steam is required; Flatpak Steam is not supported.

The tested games are equally specific. Wuthering Waves runs super resolution and frame generation. Forza Horizon 6 runs super resolution, with frame generation through OptiScaler. Cyberpunk 2077 runs both after replacing its older XeSS libraries. The README also has notes on OptiScaler and on a game without XeSS, but those are not the same as a compatibility guarantee.

The project's own performance numbers

The most useful data in the README compares Mesa 26.3.0-rc1 with its new Jay shader compiler against Mesa 26.1.2 on the same Arc B390, at the same spot and settings, with XeSS super resolution and frame generation on XMX. The numbers are the project's own tests, not an independent benchmark, and they cover two games.

Source: XeSS XMX on Linux README, Arc B390 test, fetched October 20, 2026. Project measurements, not independent testing.

The Cyberpunk result is the larger jump, and the README attributes part of the gain to Mesa 26.3's Jay compiler for the game's own shaders, not only to XMX. The project also links a Final Fantasy VII Rebirth comparison from a contributor that shows about a 15% gain, half of it from Jay. That is a useful distinction: some of the improvement would arrive with Mesa 26.3 even without the XMX work.

The README is careful about what it has not measured. It says XMX against DP4a super resolution alone has not been measured, image quality has not been measured, and the cost of disabling VK_EXT_descriptor_buffer has not been measured. Those are the right caveats. A frame rate table is not a quality review, and a two-game sample is not a universal result.

Install, drivers and the rollback path

The install is a shell script, not a package manager. The user downloads the release archive, unpacks it somewhere it can stay, and runs ./install.sh. The script fetches a compiler bundle of about 230 MB, writes the environment file, installs the shim into the Proton prefixes it finds, enables the session check and asks the user to reboot or log out and back in.

The archive carries two patched driver builds. Mesa 26.3.0-rc1 is the default; it includes the new Jay compiler, which is the default on Xe2 and Xe3 and makes the games' own shaders faster. Mesa 26.1.2 is the older driver, the same version as SteamOS' own, and it is the fallback. The user can choose per game in Steam launch options with MESA=26.1 %command% or MESA=26.3 %command%, or change the default with tools/switch-driver.sh.

The rollback path is the part I would want before installing. ./uninstall.sh reverts the changes. The session check switches to the other driver if the default fails, and falls back to the stock drivers if both fail. ~/.cache/xess-xmx/driver-status records which driver loaded, and tools/rebuild-driver.sh rebuilds a driver for a new Mesa version. That is more safety equipment than most graphics experiments ship with.

The first launch of each game compiles its kernels, which can take a minute or two. After that the kernels come from ~/.cache/xess-xmx. A failed kernel compile retries once and then uses XeSS's generic paths, which means the game still runs but frame generation is limited to 2x. The log is at ~/.cache/xess-xmx/compile.log.

Source: XeSS XMX on Linux README, fetched October 20, 2026.

Games, frame generation and XeLL

The project supports XeSS super resolution and XeSS frame generation. On the XMX path, frame generation runs at 2x, 3x or 4x. Without the Intel extension, the fallback is limited to 2x, which is the same limitation stock Proton has. That difference is the reason the project exists: the frame generation multiplier is not just a quality setting, it is a feature the hardware can support and the software path often cannot.

XeLL, Intel's latency reduction for frame generation, runs in its cross-vendor mode. The driver mode needs a component of Intel's Windows driver, which the project does not have. That is a real limitation, not a hidden setting. The README says so directly, and it does not pretend the Linux path is identical to Windows.

The wider risk is compatibility. The project patches Mesa ANV and relies on how vkd3d-proton compiles placeholder shaders and lays out its descriptor heap. If a vkd3d-proton update changes the first, the self-test turns the XMX path off. If it changes the second, the driver logs no vkd3d-style descriptor heap and the kernels do nothing. That is a fragile interface, and the project is honest that it is one.

The installation is also system-wide for the user session. It changes the 64-bit Intel Vulkan driver, sets environment variables for every D3D12 game, and installs a watcher and a session service. That is a lot of surface for a graphics experiment. The rollback path makes it recoverable, but users should understand that this is not a per-game shader tweak.

The limits and the risks

The first limit is version coupling. The patched drivers are built against Mesa 26.1.2 and 26.3.0-rc1, and the kernel binding relies on how vkd3d-proton compiles placeholder shaders and lays out its descriptor heap. A Mesa update can break the driver patch. A vkd3d-proton update can break the descriptor layout. The self-test catches some of that and falls back to the other driver or the stock path, but it does not make the interface stable.

The second is scope. install.sh replaces the 64-bit Intel Vulkan driver for the user session, writes environment variables that apply to every D3D12 game and installs a watcher plus a session service. That is broader than a per-game mod. The uninstall script and the session check make it recoverable, but anyone installing it should be comfortable with a system-level graphics change.

The third is XeLL. Intel's latency reduction runs in its cross-vendor mode because the driver mode needs a component of Intel's Windows driver. The project does not pretend that is equivalent to the Windows path. The fourth is testing: two games and two GPUs are a demonstration, not a compatibility matrix. The README says XMX against DP4a super resolution alone, image quality and the cost of disabling VK_EXT_descriptor_buffer have not been measured.

Why this matters for Intel on Linux

Intel's Arc GPUs are competitive on price and performance, and XeSS is one of their better features. On Linux, the hardware story is weaker because the software stack does not always expose the same paths. A project that gets XMX working inside Proton is useful for the same reason Proton itself is useful: it lets the hardware compete on the software people already run.

The project also shows how much of the Linux graphics stack is now community-maintained glue. Intel publishes the compiler, the XeSS SDK and the open-source dxvk-igdext component. Mesa provides the Vulkan driver. vkd3d-proton provides the D3D12 translation. The project connects those pieces with a shim and a patch. None of that is official support, but it is a credible demonstration that the pieces fit.

The limitation is the same one that applies to every community graphics patch: it is tied to specific Mesa versions and specific Proton internals. A new Mesa release can break the driver patch. A new vkd3d-proton release can break the descriptor heap layout. The project has a self-test and a fallback, but it does not have a stable ABI to build on.

Our take

The most impressive part is not the frame rate table. It is the decision to compile XeSS's own kernels with Intel's compiler and run them inside the existing vkd3d-proton queue, instead of writing a replacement upscaler. That keeps the game's image quality path and the vendor's model intact, and it makes the patch smaller than a full XeSS reimplementation would be.

The most worrying part is the installation footprint. Replacing the 64-bit Intel Vulkan driver for the user session, disabling a Vulkan extension for every D3D12 game and installing a watcher and a service is a lot of change for a feature that still has untested image quality and a two-game performance table. The rollback path is good, but the blast radius is larger than the average mod.

For an Arc handheld owner on SteamOS, this is worth watching closely. For everyone else, it is a technical preview. The project says what it has tested and what it has not, which is more than many graphics patches do. The next useful data point is an independent image-quality comparison and a wider game list, not another frame rate screenshot.

FAQ

What is XeSS XMX on Linux?
It is a community project that runs Intel XeSS super resolution and frame generation on the XMX matrix units inside Proton games. It uses an igdext64.dll shim and patched Mesa ANV drivers to compile and run the game's XeSS kernels.

How is this different from normal XeSS on Proton?
Stock Proton often runs XeSS through the DP4a fallback, which does not use the XMX matrix units and limits frame generation to 2x. This project provides the driver behavior XeSS expects, so the XMX path can run at 2x, 3x or 4x frame generation.

Which GPUs are supported?
The project is developed and tested on Intel Xe3 Panther Lake, specifically an Arc B390, and a contributor tested Xe2 Battlemage on an Arc B580. Lunar Lake is untested, and Xe-HPG Alchemist and Xe-LPG are detected but untested.

Does it work with Flatpak Steam?
No. The README says only the native Steam client is supported, including SteamOS and distribution packages, not Flatpak Steam.

What are the performance gains?
On an Arc B390, the project measured Wuthering Waves at 112-119 fps on Mesa 26.1.2 and 120-126 fps on Mesa 26.3.0-rc1, and Cyberpunk 2077 at 61-62 fps versus 91-96 fps. Those are the project's own tests, not independent benchmarks, and part of the Cyberpunk gain comes from Mesa 26.3's Jay compiler.

Can I undo the install?
Yes. The release includes uninstall.sh, a session check that falls back to the other patched driver or the stock drivers, and tools/rebuild-driver.sh for a new Mesa version. The project still replaces the 64-bit Intel Vulkan driver for the user session, so the change is broader than a per-game mod.

Bottom Line

XeSS XMX on Linux is a community project that brings Intel's XeSS super resolution and frame generation to the XMX matrix units inside Proton games. Its October 18, 2026 release pairs an igdext64.dll shim with patched Mesa 26.1.2 and 26.3.0-rc1 drivers, compiles the game's XeSS kernels with Intel's IGC compiler and runs them in the normal vkd3d-proton queue. It has been tested on an Arc B390 and an Arc B580, supports 2x, 3x and 4x frame generation on the XMX path, and includes a session check and uninstall script. It requires native Steam, specific Mesa and Proton versions, and a user-session driver replacement; it is not a universal Intel Linux fix.

Sources

• XeSS XMX on Linux repository and README: HHHHanasak1/xess-xmx-linux
• Release 20261018, published October 18, 2026: 20261018
• Game notes: docs/games.md
• How it works: docs/how-it-works.md

Related: Intel Developer Surface: Four Repos in Four Weeks Put Intel Driver Extensions in Proton | Upshift Wraps OptiScaler With Full Game Library Manager