Upscaling on Linux, head to head: Intel XeSS joins NVIDIA DLSS and AMD FSR in the Proton pipeline
Intel's proposed Proton patches would route XeSS Direct3D 12 calls to a native Linux library and unlock the XMX path on Arc GPUs. We compare how the three vendors' upscalers reach Linux gamers today.
The proposal is to add a built-in XeSS library (libxess.dll) that forwards XeSS Direct3D 12 calls
Comprehensive take
Linux gamers on Intel Arc should watch ValveSoftware/wine PR 369 but not buy on the promise; the patches are unmerged. Owners of AMD or NVIDIA cards lose nothing today: FSR works everywhere and DLSS already ships via dxvk-nvapi v0.9.2 in Proton 11.0-2. Developers shipping D3D12 titles should note that all three upscalers can now be reached from Proton without Linux-specific builds.
Use cases
Steam Deck and handheld owners
FSR's shader-based path remains the only upscaler that runs system-wide across all handheld GPUs; XeSS on Proton is irrelevant here until an Intel-based handheld ships with Arc graphics.
Arc A-Series desktop on Linux
The proposed libxess.dll forwarding layer would let existing Windows games use the XMX path instead of the slower fallback, improving performance in titles that already integrate XeSS.
GeForce owners on Proton
DLSS reaches Proton through dxvk-nvapi, updated to v0.9.2 in Proton 11.0-2; the main risk is nvapi-related breakage, which Valve patches game by game.
Game developers targeting Proton
Integrating all three upscalers in the Windows build is now sufficient; Proton's layers (dxvk-nvapi, portable FSR shaders, proposed XeSS forwarding) handle Linux without a native port.
Specs
| Intel XeSS path | Built-in libxess.dll in Proton forwards D3D12 calls to native Linux XeSS library; XMX acceleration enabled source |
|---|---|
| VKD3D-Proton change | Enables required Vulkan extensions; converts D3D12 objects to Vulkan via interop interface source |
| DXVK change | Stops hiding Intel GPU brand when Proton supplies XeSS source |
| Tracking | ValveSoftware/wine pull request 369; not merged source |
| NVIDIA DLSS path | dxvk-nvapi v0.9.2 shipped in Proton 11.0-2 source |
| Known nvapi side effect | Proton 11.0-2 fixed Mirror's Edge Catalyst freezing on non-NVIDIA systems due to nvapi presence source |
Insights
- Intel's design forwards to a first-party Linux library rather than emulating a Windows API, which avoids the class of bugs Proton 11.0-2 had to patch around for nvapi.
- The DXVK vendor-ID change is small but decisive: games choose the XMX path only when they can see an Intel GPU.
- FSR's portability advantage is structural, not a feature flag; it comes from being plain HLSL that DXVK translates like any other shader.
- All three upscalers reaching Proton through separate mechanisms means Linux support is now a property of the translation layer, not of the game.
Axion Scorecard
Overall: 6.4
Not yet scored — no cited data
Open-source patches to free software; no cost to users beyond owning an Arc GPU. source
Not yet scored — no cited data
Forwarding to a native Linux library via VKD3D-Proton interop is a cleaner architecture than API emulation. source
Depends on Valve merging; competitors' paths (dxvk-nvapi v0.9.2, portable FSR) already ship in Proton 11.0-2. source
Unmerged pull request (ValveSoftware/wine PR 369); no release date. source
Three small coordinated changes (Proton, VKD3D-Proton, DXVK) with clear separation of concerns. source
For most of the Steam Deck era, temporal upscaling on Linux has been a two-horse race between NVIDIA's DLSS, reaching Proton through the dxvk-nvapi shim, and AMD's FSR, which has the advantage of being open and vendor-agnostic. Intel's Arc GPUs have been the odd one out: Windows games that call XeSS under Proton have had to fall back to the slower generic codepath, because Proton had no way to forward those calls to Intel's XMX matrix engines. On Sunday, Phoronix reported that an Intel engineer has opened pull requests against Valve's Proton to change that. This is a good moment to lay the three approaches side by side.
How XeSS would get in
According to Phoronix, the Proton change adds a built-in XeSS library, libxess.dll, that forwards XeSS Direct3D 12 calls to the native Linux XeSS library. On the VKD3D-Proton side, the patches enable the Vulkan extensions and features XeSS requires and use VKD3D-Proton's interoperability interface to convert D3D12 objects to Vulkan handles. DXVK gets a small companion change: it stops hiding Intel GPU brand information when Proton is providing XeSS, so games correctly detect that they are on Arc and offer the XMX path. The work is tracked in ValveSoftware/wine pull request 369 and is not merged. Phoronix expects it to land eventually given that comparable upscaling plumbing for AMD and NVIDIA already exists in Proton.
How DLSS gets in
NVIDIA's route is dxvk-nvapi, an open-source reimplementation of NVIDIA's NVAPI that lets Windows games see an NVIDIA GPU and reach DLSS through Proton. Valve's own release notes for Proton 11.0-2 show how routine this has become: the changelog bumps dxvk-nvapi to v0.9.2 and separately fixes Mirror's Edge Catalyst freezing on non-NVIDIA systems because of the nvapi layer's presence. That second bullet is the honest cost of the approach: emulating a vendor API surface is a moving target, and the shim can misfire on hardware it was never meant for. NVIDIA's advantage is maturity. The pipeline has shipped in Proton for years, and the DLSS binaries games bundle are the same ones Windows uses.
How FSR gets in
AMD's FSR takes the path of least resistance. The shader-based FSR 1 through 3 implementations are platform-neutral HLSL that DXVK and VKD3D-Proton translate like any other shader, so they generally work on every vendor's GPU, including Arc and GeForce, without a vendor-specific layer. That portability is why FSR is the upscaler Valve exposes system-wide on Steam Deck. The trade-off is that FSR's quality depends on the game's integration, and AMD's newer machine-learning variants narrow the portability advantage because they lean on vendor-specific acceleration. We have not independently measured FSR quality against XeSS or DLSS on Linux for this piece, so we make no claim about which looks better.
What the comparison tells us
Three vendors, three philosophies. NVIDIA emulates its Windows API surface and accepts the maintenance burden. AMD writes portable shaders and accepts that it cannot exploit its own hardware as deeply. Intel is now proposing a hybrid: a thin forwarding DLL in Proton plus a native Linux XeSS library, so the heavy lifting runs on Intel's own Linux code rather than on a translated Windows binary. If it merges, Intel would arguably have the cleanest architecture of the three, because nothing is emulated; D3D12 objects are converted to Vulkan once and handed to a first-party library.
The catch is timing and scale. Intel's patches are unmerged and target a GPU line with a small share of the Linux gaming market. NVIDIA's path is shipping today in Proton 11.0-2. AMD's path is shipping today and works on everyone's hardware. For a Linux gamer buying in late 2026, the practical order remains AMD for zero-friction compatibility, NVIDIA for the deepest upscaler feature set at the cost of a shim, and Intel as the one to watch.
Why it matters beyond Arc
The interoperability interface in VKD3D-Proton that Intel is leaning on is the same kind of mechanism that could carry any future vendor-specific D3D12 extension to Linux. Every upscaler that arrives through a clean forwarding layer rather than a reverse-engineered API makes the next one easier. Intel's small market share means this will not change many frame counters this year, but the pattern it establishes is the right one, and Valve has every incentive to accept it.
Our scorecard below rates the XeSS-on-Proton proposal as the subject of the piece. Dimensions where we have no sourced measurement are left unscored rather than guessed.