20261025

Two patched Mesa ANV drivers (26.3.0-rc1 and 26.1.2), igdext64.dll, ControlLib.dll, scripts, tools and docs. Unpack over (or next to) the previous version, run ./install.sh (or enable.sh for a single game), reboot or re-login.

Changes since 20261024

• More frame generation: XESS_FG=4 %command%.

  • It works like the frame generation override of Intel Graphics Software on Windows. XeSS frame generation runs at the number you set, whatever the game's menu offers or picks: Cyberpunk 2077, which offers 2x, runs at 4x.
  • install.sh puts a small stand-in for Intel's Control Library (ControlLib.dll) into every prefix to make this work.
  • 2x to 4x is Intel's own range.

• 5x to 8x, experimental: XESS_FG=5 ... 8.

  • Above 4x, XeSS frame generation ignores the override, so the shim raises the number inside Intel's library while the game runs. This is beyond what Intel supports.
  • All four work in Cyberpunk 2077 and Wuthering Waves. 7x and 8x are not recommended: every step lowers the real frame rate and raises the latency.

• Whatever the frame generation multiplier, keep a frame rate limiter on (the game's own, or gamescope's): without one the generated frames reach the screen unevenly.

• XESS=latest no longer loses a library. Two cases could leave a game's libxess_fg.dll missing until "Verify integrity of game files":

  • stopping a game from the Steam menu;
  • a game with a launcher, such as Cyberpunk 2077.

  The original files now always come back.

• Every Steam library (#28): Protons and prefixes on an SD card or a second disk now get the shim too.

• Distribution Protons (#28): a Proton from a distribution package (CachyOS' proton-cachyos in /usr/share/steam/compatibilitytools.d) can only be changed by root. install.sh now lists it with the sudo commands that put the shim in; until then, games on it run on DP4a.

• XeSS frame generation log: XESS_LOG=1 now also writes XeSS frame generation's own log and the number of generated frames it uses.

• The drivers are the 20261023 builds, unchanged. igdext64.dll is new (the frame generation override); its XMX path is unchanged.

• The archive contains no Intel binaries. ControlLib.dll is this project's own code. The XeSS SDK libraries for XESS=latest are downloaded on your machine by install.sh, from Intel's GitHub (github.com/intel/xess).

Tested

Arc B390 (Xe3, ONEXPLAYER 3, SteamOS):

• Cyberpunk 2077 with XESS=latest: 4x, 6x and 8x.
• Wuthering Waves: 5x with the game's own 4x in its menu, and its own 2x/3x/4x without XESS_FG.
• XESS=latest restore: the game's libraries come back after an in-game exit, a stop from the Steam menu, and a Steam client restart.
• Install and uninstall: two Steam libraries, and a Proton only root can write to.

20261024

Two patched Mesa ANV drivers (26.3.0-rc1 and 26.1.2), igdext64.dll, scripts, tools and docs. Unpack over (or next to) the previous version, run ./install.sh (or enable.sh for a single game), reboot or re-login.

Changes since 20261023

• Steam launch options on one page (#29): docs/launch-options.md lists every option for a single game, what it does and when to use it: driver choice (MESA=26.1), Jay off (INTEL_DEBUG=no-jay), the XeSS options below, and logs for a bug report. docs/debugging.md now lists every switch, including the variables the scripts read.
• Games with XeSS older than 2.0.2.68: XESS=latest %command%.
  • DXVK reports an Intel GPU as an AMD one to such a game. XeSS then runs on DP4a and there is no XeSS frame generation option (Cyberpunk 2077 2.31 ships XeSS 2.0.1.41 and XeSS-FG 1.1.0.19).
  • With XESS=latest, the game runs with Intel's XeSS SDK 3.0.2 libraries (XeSS 2.0.2.68, XeSS-FG 1.3.1.78, XeLL 1.3.2.10) in place of its own, but only while it runs. When it exits, also when Steam stops it, the game's own files are back, so Steam updates and "Verify integrity" are not affected.
  • install.sh downloads the SDK from Intel's GitHub (github.com/intel/xess) into xess/; it is not part of the archive.
  • The option works through a small user_settings.py that install.sh puts into every Proton. A user_settings.py of your own is kept as user_settings.user.py and still applies; uninstall.sh puts it back.
  • Not offered on purpose: making DXVK show the Intel GPU to the game's own old libraries. Cyberpunk 2077's XeSS-FG 1.1.0.19 crashes at start that way.
• Shorter switches: XESS=dp4a (XeSS without the XMX path, for comparison) and XESS_LOG=1 (the shim's and XeLL's logs).
• The drivers and igdext64.dll are the 20261023 builds, unchanged.

Tested

• Arc B390 (Xe3, ONEXPLAYER 3, SteamOS), Cyberpunk 2077 2.31 with XESS=latest: super resolution and frame generation (2x, the most the game offers) on XMX; the game's own libraries were back after it exited.
• The swap and restore on their own: normal exit, Steam stopping the game, a run killed outright and cleaned up at the next start, a game update in between, a user_settings.py of your own, install and uninstall.

20261023

Two patched Mesa ANV drivers (26.3.0-rc1 and 26.1.2), igdext64.dll, scripts, tools and docs. Unpack over (or next to) the previous version, run ./install.sh (or enable.sh for a single game), reboot or re-login.

Changes since 20261018

• The driver now loads in games on systems without another Mesa Vulkan driver (#26). The drivers need libSPIRV-Tools.so and libdisplay-info.so.3. Proton games run inside the Steam Linux Runtime container, which has neither library and does not see the system's /usr. Until now both reached the container only as dependencies of the system's other Vulkan drivers (on SteamOS, the radeon driver). With only the Intel Vulkan driver installed, the patched driver could not load in any game. The session check runs at every login and from install.sh / enable.sh. It now copies both libraries into lib/deps/, and the drivers look there first.
• More distributions (#25, #27):
  • Void Linux (libSPIRV-Tools-shared.so) and openSUSE (libSPIRV-Tools-<version>.so) name SPIRV-Tools differently. The check takes those libraries. The symlink suggested in #25 is no longer needed and can be removed.
  • Debian, Ubuntu and Fedora ship libdisplay-info 0.1/0.2, and Debian and Ubuntu have no shared SPIRV-Tools. For systems without them, the archive now includes SPIRV-Tools (vulkan-sdk-1.4.350.1, Apache-2.0) and libdisplay-info 0.3.0 (MIT) in lib/bundled/, unmodified and built by tools/build-deps.sh on Debian 12. The system's own library is used whenever it has one.
• Both drivers are the 20261018 builds with that run path added; their code is unchanged. igdext64.dll is unchanged.
• tools/rebuild-driver.sh builds with the run path. It also finds the build again: since the switch to the release tarballs it looked in the wrong folder (that version was not in a release).

Tested

• Arc B390 (Xe3, ONEXPLAYER 3, SteamOS), in the Steam Linux Runtime container with only the Intel drivers in the driver list. Without lib/deps/, both drivers fail with libdisplay-info.so.3: cannot open shared object file. With it, they find the GPU.
• Load test of both drivers in containers, before and after the session check:
  • Arch, openSUSE Tumbleweed, Void Linux, Fedora 43 and Ubuntu 25.10 load.
  • Debian 13 and Ubuntu 24.04 still don't. Their libwayland-client is 1.23, and the drivers need 1.24 (undefined symbol: wl_fixes_interface). That library can't be bundled, so there the driver has to be built on the system (tools/rebuild-driver.sh).
  • Only loading was tested in these containers, not games on real hardware.
• tools/rebuild-driver.sh 26.1.2 end to end on the deck.

20261018

Two patched Mesa ANV drivers (26.3.0-rc1 and 26.1.2), igdext64.dll, scripts, tools and docs. Unpack over (or next to) the previous version, run ./install.sh, reboot or re-login.

Changes since 20261016

• Mesa 26.3 driver: fix for a crash at start in some RE Engine games. Mesa turns on anv_emulate_divergent_barriers for Resident Evil Requiem, Pragmata and Monster Hunter Stories 3, and with Jay (the default on Xe2 and Xe3) those games crashed while creating their pipelines. patches/mesa-26.3/0004 by @kas5852 (#22) compiles the affected shaders of those games with the older brw compiler and keeps Jay for everything else. On SteamOS, whose Mesa 26.1.2 settings do not turn the option on, these games did not crash; no launch options are needed either way.
• The Mesa 26.1.2 driver, igdext64.dll and the scripts are unchanged.

Tested

• Arc B390 (Xe3, ONEXPLAYER 3, SteamOS): Resident Evil Requiem with anv_emulate_divergent_barriers=true crashes at start with the 20261016 driver and starts and runs with this one.

20261016

Two patched Mesa ANV drivers (26.3.0-rc1 and 26.1.2), igdext64.dll, scripts, tools and docs. Unpack over (or next to) the previous version, run ./install.sh, reboot or re-login.

Changes since 20261005

• Mesa 26.3.0-rc1 with the Jay compiler, now the default. The patches were rebased onto Mesa 26.3 by @kas5852 in #19 (patches/mesa-26.3/). On Xe2 and Xe3, 26.3 compiles the games' own shaders with Jay, which is much faster. (#14)

• Choose the driver per game in its launch options: MESA=26.1 %command% or MESA=26.3 %command%. Games without it use the default; tools/switch-driver.sh lists the drivers and changes the default. If the default driver fails the check before a session, the other one takes over automatically.

• tools/rebuild-driver.sh builds either version (tools/rebuild-driver.sh 26.3.0-rc1).

• The driver switch: per game, the default, and the fallback with a broken driver.

20261005 - Xe2 (Battlemage) works, vendor id override, watcher fix, Cyberpunk 2077

Patched Mesa 26.1.2 ANV (built by tools/rebuild-driver.sh from patches/0001-0003 on a clean mesa-26.1.2), igdext64.dll, scripts, tools and docs. Unpack over (or next to) the previous version, run ./install.sh, reboot or re-login. Supersedes v1.3.2. Releases are named by date from now on.

Changes since v1.3.2

• Xe2 works (Battlemage). On Xe2 the first CM kernel hung the GPU: the kernels use 256 registers, which on Xe2 needs the engine-wide Large GRF Mode that nothing turned on. patches/0003, contributed by @RNI4114 in #16, switches it around the kernels that need it. Tested by the contributor on an Arc B580: Cyberpunk 2077 and Wuthering Waves, super resolution and frame generation, no engine resets. Lunar Lake is still untested. (#3)
• Games that Mesa hides the Intel GPU from. Mesa's game profiles set force_vk_vendor=-1 for a number of games (24 in 26.1.2: Spider-Man Remastered, Hitman 3, Hogwarts Legacy, The Witcher 3, Diablo IV, Baldur's Gate 3, ...). The game then sees no Intel GPU and XeSS super resolution stays on DP4a. Since v1.3.2 the release driver reads these profiles, so those games lost the XMX path with that release. install.sh / enable.sh now set force_vk_vendor=0 for the session; force_vk_vendor=-1 %command% in a game's launch options restores Mesa's behaviour for that game. (#15)
• Shim lost after a Proton update. When Steam wrote a Proton update's igdext64.dll while the watcher was already running, the stock library stayed in that Proton and its games ran without the shim. The watcher now keeps checking the Proton folders as well, and the .stock backup follows the updated file.
• Cyberpunk 2077 added to the games list: super resolution and frame generation on XMX. The game ships XeSS 2.0.1.41, and DXVK reports an Intel GPU as an AMD one for XeSS older than 2.0.2.68, which keeps XeSS on DP4a and hides the XeSS frame generation option. The game's XeSS libraries have to be replaced by newer ones (docs/games.md; PROTON_XESS_UPGRADE=1 is one source).
• Troubleshooting entries for the three cases above; build docs describe 0003.

Tested

• Arc B390 (Xe3, ONEXPLAYER 3, SteamOS): the driver of this archive in Wuthering Waves and Cyberpunk 2077: same kernels dispatched as with v1.3.2's driver, no engine resets. The vendor override with the patched driver and a Mesa game profile (hidden with the profile, Intel with force_vk_vendor=0, hidden again with -1). The watcher with Valve's library put back while it was idle, while its service was running, and after it had finished.
• Arc B580 (Xe2), by the contributor: see #16.
• Not tested with this driver: Forza Horizon 6.

v1.3.2 - driver reads per-game workarounds (ray tracing hang), self-test fallback, retry rule, rebuild script

Xe3 (Panther Lake) build (Xe2 untested): patched Mesa 26.1.2 ANV (built by tools/rebuild-driver.sh from patches/0001 + 0002 on a clean mesa-26.1.2), igdext64.dll, scripts, tools and docs. Unpack over (or next to) the previous version, run ./install.sh, reboot or re-login. Supersedes v1.3.1.

Update recommended for everyone: the drivers of all earlier releases were built with meson's default /usr/local prefix, so they looked for Mesa's per-game workarounds in /usr/local/share/drirc.d and ran every game without them. Visible example: Wuthering Waves with ray tracing on hangs the GPU within a minute (no image). The stock SteamOS driver, and this release, read /usr/share/drirc.d.

Changes since v1.3.1

• Driver reads the system's per-game workarounds (-Dprefix=/usr -Dsysconfdir=/etc). Bisected on the device: unpatched Mesa 26.1.2 and 26.1.8 built with the default prefix hang the same way; our driver with the workarounds does not. rebuild-driver.sh and CI refuse a driver that does not reference /usr/share/drirc.d; the session check notes such a driver in ~/.cache/xess-xmx/driver-status.
• Ray tracing is available again (-Dintel-rt=enabled, like the stock driver). Earlier releases exposed no ray tracing extensions, so games hid the option.
• Self-test and a real fallback. Before XeSS gets CM kernels, the shim creates one canary placeholder and checks that the patched driver recognised it. If it did not (stock driver active, session check fell back, a vkd3d-proton change), or kernels failed to compile, the shim declines the extension context: XeSS behaves as on a system without the Intel extension, with DP4a super resolution and generic frame generation, which is limited to 2x (the game's 3x/4x needs the XMX path). v1.3.1's "fallback" gave noise instead. IGDEXT_FORCE_FALLBACK=1 selects it by hand.
• Retry rule for failed compiles. One automatic retry at the next launch; after a second failure no further attempts until something changes: a graphics component newer than the failure (compiler in igc/, helper, patched driver, system Mesa), a game update (the game's libxess.dll / libxess_fg.dll newer than the failure), or by hand (delete drive_c/igdext_kernels/compile_failed.txt or run install.sh).
• Session check also enumerates the GPU with only the patched driver (vulkaninfo), and reports a Mesa version that differs from the system's.
• tools/rebuild-driver.sh: rebuilds the patched driver for the system's Mesa version after an OS update (in an Arch distrobox), tests it, and keeps the previous one as lib/libvulkan_intel.so.prev.
• Kernel cache key includes the toolchain (ocloc / IGC / packer), so a compiler update recompiles instead of reusing stale kernels.
• Watcher also covers new prefixes (a game started for the first time), newly installed Protons and compatibilitytools.d.
• Patch series: 0001 (feature) now builds on its own; 0002 holds only the debug tools. CI checks the layering.
• XeLL: the Wuthering Waves frame-cap fix applies to that game only (IGDEXT_XELL_FIXCAP=1 for others); the XeLL log reports simulation-to-present latency from XeLL's frame reports.
• Docs corrected: the XMX vs generic frame generation numbers compared 4x with 2x (the generic path cannot do more than 2x), and v1.3's descriptor_buffer measurement was not a valid measurement; both are now described as such.

Tested on the ONEXPLAYER 3 (Arc B390)

• Wuthering Waves with ray tracing on: stock driver fine; v1.3.1-style driver hangs after ~43 s; this driver in the world with ray tracing and the XMX path active, no hang.
• Self-test positive and negative; fallback keeps frame generation at 2x.
• Retry rule via device creation: one automatic retry, none after the second failure, exactly one more after a compiler update, fallback lifted when the kernel compiles.
• Game-update detection in game (a bug found and fixed in this release: the game opens an extension context before loading XeSS, and the decision had been cached there): marker removed, XeSS and XeFG contexts granted.
• Watcher: a simulated new prefix had the shim 7 s after it appeared.
• rebuild-driver.sh end to end on the device (this release's driver was built with it); the archive's files are identical to the tested installation.

v1.3.1 - session driver check, self-healing compile failures

Xe3 (Panther Lake) build (Xe2 untested): patched Mesa 26.1.2 ANV (built from patches/0001 + 0002 on a clean mesa-26.1.2), igdext64.dll, scripts, tools and docs. Unpack over (or next to) v1.3, run ./install.sh, reboot or re-login. Supersedes v1.3.

Changes since v1.3

• Session driver check. The patched driver links against system libraries (an unversioned libSPIRV-Tools.so, glibc 2.38). If a SteamOS update breaks one of them, the driver cannot load, and because the patched driver replaces the stock 64-bit Intel driver, the whole session (gamescope included) would lose the GPU. install.sh now enables xess-xmx-check.service, which loads the driver once before every graphical session and, if that fails, switches the session back to the stock drivers so everything else keeps working. Correction: in this version XeSS does not fall back to DP4a in that case - the shim kept handing out placeholders, which the stock driver runs as no-ops (noise in the image). Fixed in v1.3.2 (self-test). Status in ~/.cache/xess-xmx/driver-status.
• Compile failures heal by themselves. Kernels listed in compile_failed.txt are compiled again when the next game starts; the DP4a fallback is lifted as soon as they succeed (before, a single transient failure kept the game on DP4a until install.sh was run again).
• The compile log is now in ~/.cache/xess-xmx/compile.log. Inside the Steam runtime container $XDG_RUNTIME_DIR is private, so the previously documented log file never showed up on the host.
• The compiler helper is started with posix_spawn (no fork of the game process). Compile cost was measured and documented (about 0.3 s per kernel while a game loads, ~65 s for Wuthering Waves' 90 kernels, once).
• The static kernel table is no longer compiled into the release shim (developer option XMX_STATIC_TABLE).
• CI builds from a fixed Arch Linux Archive snapshot and reports the driver's library dependencies.
• Docs: why INTC_ALT_DRIVER_EXTENSIONS_PATH cannot replace the per-prefix copies of the shim (XeSS reads it first, but GE-Proton sets it to C:\Windows\System32 for every game).

Tested on the ONEXPLAYER 3 (Arc B390): clean-tag build of both patches, fresh install/uninstall from this archive (20 checks), the session check with a deliberately broken driver, forced compile failure and self-heal, Wuthering Waves cold-cache compile and a cached run.

Correction (2026-09-25): the "switches back to the stock drivers ... XeSS runs as DP4a" statement above was wrong for this version; see v1.3.2.

v1.3 - hardening, run-time kernels by default, docs

Xe3 (Panther Lake) build (Xe2 untested): patched Mesa 26.1.2 ANV (lib/libvulkan_intel.so, built from patches/0001 + 0002 on a clean mesa-26.1.2), igdext64.dll, scripts, tools and docs. Unpack, run ./install.sh, reboot or re-login. Supersedes v1.2.2.

The archive no longer contains any XeSS kernels. They are compiled on your machine the first time a game uses them (a minute or two once; cached in ~/.cache/xess-xmx, shared by all games). install.sh fetches the compiler (about 230 MB) if it is missing.

Fixes

• Other GPUs and 32-bit games kept their Vulkan drivers. Earlier install.sh versions put only the patched 64-bit driver into VK_DRIVER_FILES, so on a machine with another GPU that GPU vanished from Vulkan, and 32-bit Vulkan games had no Intel driver at all. Every other driver now stays in the list. Re-run install.sh and re-login.
• install.sh from a release archive failed (it expected a run/ folder the archive did not contain).
• Scripts in the release archives were not executable after unzip (v1.2 - v1.2.2; the v1.2 notes said otherwise). Fixed in the packaging.
• A game shader could be replaced by an XeSS kernel if its workgroup size matched a placeholder's. The driver now also checks a magic value only the shim's placeholders store.
• Failed kernel compiles and kernel updates stuck in the shader cache. Placeholders are no longer stored in any pipeline cache.
• A failed compile now makes XeSS fall back to its DP4a path on the next launch instead of producing noise.
• The XeLL frame-cap fix is limited to Wuthering Waves (it could hide a legitimate cap in other games).
• Driver: null surfaces instead of a crash if the descriptor heap is not bound; the sampler comes from the root signature's static sampler; environment variables are read once.

Changes

• GPU detection in the shim (device info, XMX and SIMD16 answers per family: Xe3, Xe2, Xe-HPG, Xe-LPG) and in the compiler helper (ocloc target from the PCI id). Only Xe3 is tested.
• Run-time kernel ids: 1549 (was 288), rotation when used up; kernels cached per hash across prefixes.
• enable.sh has no Wuthering Waves defaults any more (XMX_APPID or XMX_PREFIX is required; config file ~/.config/xess-xmx.conf).
• The ANV patch is split into 0001-anv-cm-kernel-injection.patch (the feature) and 0002-anv-cm-debug-tools.patch.
• Documentation split into README + docs/ (how it works, building, debugging with a symptom table, games).
• Measured: disabling VK_EXT_descriptor_buffer (needed for the kernel binding) costs nothing measurable in Wuthering Waves or Forza Horizon 6. Correction (2026-09-25): not reliably measured - the Wuthering Waves numbers came from a capped title screen, and the Forza Horizon 6 runs did not confirm that the setting reached the game.
• XeLL driver mode investigated: it is a separate component of Intel's Windows driver (igxell64.dll), so XeLL stays in its cross-vendor mode on Linux; an experimental probe (IGDEXT_XELL_PROBE) is included.

Both binaries are also built by CI on every push (.github/workflows/build.yml; the release binaries are the device-tested builds).

Tested on the ONEXPLAYER 3 (Arc B390): Wuthering Waves with an empty kernel cache (90 kernels compiled in ~80 s, clean image, 4x frame generation on XMX), the DP4a fallback after forced compile failures, Forza Horizon 6 in the open world, and install/uninstall from this archive.

Superseded by v1.3.1.

v1.2.2 - frame generation on XMX confirmed, caller trace

Xe3 (Panther Lake) binaries: patched Mesa 26.1.2 ANV (lib/libvulkan_intel.so, unchanged from v1.2.1), igdext64.dll, kernels/ (146 .cmk) and the scripts. Unpack anywhere and run ./install.sh (see README). Supersedes v1.2.1.

Changes since v1.2.1

• XeSS frame generation runs on XMX, confirmed. A caller trace on the deck showed that libxess_fg.dll builds its own CM network (kernel ids 30-89 of the shipped set, half of them using dpas). In Wuthering Waves at 4x, twelve of those kernels run once per generated frame, so multi-frame generation runs on XMX. The README said the game-integrated XeFG used a non-CM path; that was wrong and is corrected, including the split of the shipped set (30 SR + 60 XeFG kernels). No behaviour change: the shim still answers SIMD16Required=1 to every caller. Answering 0 to XeFG was tried and makes it request Xe-HPG kernels that do not compile for Xe3 (black generated frames).
• IGDEXT_TRACE=1 now logs the calling module of every extension context, feature query and CM pipeline (callers(...): igdext64.dll < libxess_fg.dll < ...). That tells XeSS SR and XeFG kernels apart in any game, so you can check whether a game's frame generation uses XMX. Trace mode only.
• IGDEXT_OPTIONS2_FG=<simd16>,<lsc>,<legacy> overrides the feature answer for XeFG only (for experiments).

Tested on the ONEXPLAYER 3 with Wuthering Waves in the open world at 4x frame generation.

Open: #3 (Xe2 untested), #4 (the 24 Xe-HPG XeFG kernels can be dropped).

Superseded by v1.3.