Intel Moves to Bring XeSS XMX Acceleration to Proton for Linux Gaming

Intel is working to bring hardware-accelerated XeSS upscaling to Windows games running through Valve’s Proton compatibility layer on Linux. Four pull requests submitted on October 19, 2026, propose changes that would allow compatible Intel Arc graphics processors to use their dedicated XMX hardware instead of relying on the DP4a fallback. The work could improve the Linux gaming experience for Arc desktop users and Intel-powered handhelds, although the patches have not yet been merged.

For Intel Arc owners who have moved from Windows to Linux, the proposal addresses a gap between what their graphics hardware supports and what Windows games can actually access through Proton.

Intel’s Xe Super Sampling (XeSS) technology already works in supported games through Proton, but accessing its dedicated XMX acceleration has been a challenge. As a result, compatible Arc hardware has generally relied on the alternative implementation designed for broader GPU compatibility.

The proposed changes aim to remove that limitation without requiring game developers to produce separate Linux versions of their Windows titles.

Intel Proposes Native XeSS XMX Support for Proton

Intel developer Damian Tomczak submitted four coordinated pull requests affecting Proton, Wine, VKD3D-Proton, and DXVK. Together, they establish a proposed path for Windows games using Direct3D 12 XeSS to access Intel’s native Linux XeSS implementation.

The central idea is straightforward: rather than forcing a Windows game to use the more general-purpose upscaling path, Proton would connect the game’s XeSS calls to a Linux library capable of accessing Intel’s dedicated XMX hardware.

The changes span multiple projects because Proton does not translate Windows gaming workloads through a single application or library. Instead, it combines several compatibility technologies that handle Windows application behavior, graphics API translation, and communication with Linux graphics drivers.

As of October 20, 2026, all four pull requests remain open. The proposed integration is not yet available as a standard Proton feature, and no public release date has been established.

Why XeSS XMX Matters for Intel Arc Graphics

Intel XeSS Super Resolution improves gaming performance by rendering frames at a lower internal resolution and reconstructing them for a higher-resolution display.

To accomplish this, XeSS uses information such as motion vectors, depth data, and previously rendered frames. Its reconstruction process attempts to preserve fine details and maintain image stability while reducing the amount of rendering work performed by the GPU.

However, not every XeSS implementation uses the same hardware.

XMX Acceleration Versus DP4a

Intel XeSS supports two important execution approaches:

• XMX acceleration: Uses dedicated Xe Matrix Extensions hardware available on compatible Intel Arc GPUs. These engines accelerate matrix calculations used by AI workloads, including XeSS image reconstruction.
• DP4a fallback: Uses integer dot-product instructions on more conventional GPU execution resources. This allows supported GPUs from different manufacturers to run XeSS without requiring Intel’s dedicated matrix hardware.

The DP4a path remains an important part of XeSS’s broader compatibility strategy. It allows supported games to offer Intel’s upscaling technology even when players do not own an Intel graphics card.

Nevertheless, the two approaches differ in how they use GPU resources.

Intel’s XMX hardware is specifically designed to accelerate matrix operations, while DP4a executes its workload through more general-purpose graphics resources.

Using dedicated XMX hardware may reduce the processing cost of upscaling and leave more conventional GPU resources available for other rendering tasks.

Image quality can also differ between the two implementations. The XMX path may provide better reconstruction or temporal stability in some games, although the size of any improvement depends on the title, XeSS version, resolution, and selected quality preset.

Importantly, the proposed Proton patches have not yet established how these differences translate into real-world Linux gaming performance.

How Intel Plans to Connect XeSS to Linux

The most significant part of Intel’s proposal involves connecting the Windows XeSS library used by games to a native Linux implementation.

Windows games ordinarily load a library called libxess.dll to access XeSS functionality.

Intel’s proposed Wine changes introduce a built-in replacement that forwards supported Direct3D 12 XeSS operations to a native Linux library named libxess.so.

VKD3D-Proton provides the interoperability needed to connect relevant Direct3D 12 objects with Vulkan resources used by the Linux implementation.

This allows XeSS to operate within Proton’s existing graphics translation infrastructure rather than replacing it.

The approach also differs from how other upscaling technologies are supported on Linux.

Traditional shader-based implementations of AMD FidelityFX Super Resolution use portable graphics compute workloads, while NVIDIA DLSS support through Proton relies on compatibility components such as DXVK-NVAPI to expose NVIDIA functionality to Windows games.

Intel’s proposal introduces a dedicated forwarding mechanism that connects Direct3D 12 XeSS calls to a native Linux library through Wine and VKD3D-Proton interoperability.

These differences help explain why support for one GPU upscaling technology does not automatically guarantee support for another.

Four Pull Requests Working Together

The proposed implementation requires coordinated changes across four repositories:

• Wine: Pull Request #369 introduces the built-in libxess.dll implementation that forwards supported Direct3D 12 XeSS operations to the native Linux library.
• VKD3D-Proton: Pull Request #3379 exposes the Vulkan extensions and device features required by the XeSS implementation when available.
• DXVK: Pull Request #5992 adjusts an existing compatibility workaround that can hide Intel GPU identification from games using XeSS.
• Proton: Pull Request #10289 integrates the coordinated changes and configures Proton to use a compatible native Linux XeSS library when one is available.

The Proton integration depends on the related Wine, VKD3D-Proton, and DXVK work because it brings the updated components together into the compatibility environment used by games.

Why the DXVK Change Is Necessary

One interesting detail involves DXVK, which primarily handles Direct3D 9, 10, and 11 translation to Vulkan.

Although Intel’s proposed XeSS forwarding path targets Direct3D 12, DXVK also includes DXGI functionality used for graphics adapter identification.

DXVK contains a compatibility workaround that can hide Intel GPUs from games using older XeSS libraries. The existing check applies to XeSS DLL versions older than 2.0.2.68.

The new Proton-provided DLL complicates that detection mechanism because Wine’s built-in library does not contain the conventional Windows version resource expected by the existing check.

Without an adjustment, the compatibility workaround could prevent the game from recognizing Intel hardware even when Proton is prepared to provide native XeSS functionality.

The proposed correction allows DXVK to recognize the Proton-provided implementation instead of incorrectly hiding the Intel GPU.

It is a relatively small modification, but one that illustrates why enabling an advanced graphics feature can require changes across several layers of the compatibility stack.

One Important Requirement: The Native Linux XeSS Library

Intel’s proposed Proton integration has an important dependency: it must locate a compatible native Linux XeSS library before it can enable the XMX acceleration path.

According to Proton pull request #10289, the implementation searches for libxess.so in three locations, in order:

• User-defined override: A library location specified through the proposed XESS_LIB_OVERRIDE environment variable.
• Proton contribution directory: A location where Proton can include additional supporting libraries.
• System library path: Libraries made available through the Linux installation.

Proton also performs a version compatibility check. The native Linux library must provide a XeSS major and minor version at least as recent as the version required by the game’s Windows DLL.

If Proton cannot locate a suitable library, or the available library is too old, it is designed to retain the game’s existing Windows libxess.dll instead.

That fallback behavior matters because the proposed implementation is not intended to require every existing XeSS game to adopt a new library immediately.

For advanced Linux users, XESS_LIB_OVERRIDE could eventually provide a useful way to select a particular native library for testing or troubleshooting.

However, the variable remains part of the proposed integration and should not be confused with a supported configuration option in current standard Proton releases.

Library Distribution Remains an Open Question

Even after the compatibility patches are merged, users will still need access to a suitable native XeSS library.

Developers and Linux enthusiasts have previously asked Intel how Linux XeSS libraries would be distributed and whether they might eventually ship alongside Proton. Those questions are documented in Intel’s XeSS GitHub repository.

Intel’s published XeSS SDK includes proprietary binary components, although its software license permits redistribution of unmodified binaries under specified conditions. That does not independently establish the licensing arrangements for the particular Linux library required by this proposal.

Whether Intel distributes the library directly, Valve includes it with Proton, or Linux distributions provide supported packages remains uncertain.

For Arc owners, this is an important distinction. The compatibility patches establish a potential route to XMX acceleration, but convenient access to a compatible native library will also be necessary for widespread adoption.

Why This Matters for Intel Arc Desktop GPUs and Handhelds

The most obvious beneficiaries would be Linux gamers using Intel Arc graphics hardware equipped with XMX capabilities.

That includes compatible Arc A-Series and B-Series discrete graphics cards, along with supported Intel integrated Arc implementations.

For example, an Arc B580 owner running a Linux gaming desktop could potentially gain access to the dedicated matrix acceleration already available to supported XeSS games under Windows.

The opportunity is particularly relevant to enthusiasts running Windows games through Steam and Proton on Linux distributions such as Bazzite or other gaming-focused environments.

As Linux gaming continues to develop, access to the complete feature set of a graphics processor becomes increasingly important. Basic game compatibility is useful, but hardware features such as upscaling, ray tracing, and specialized compute acceleration can strongly influence the overall experience.

Intel-Powered Handhelds Could Benefit Too

Intel-based handheld gaming PCs, including compatible MSI Claw configurations, represent another potential use case.

Handheld systems operate within tighter power and thermal limits than typical desktop gaming PCs. The efficiency of individual graphics workloads can therefore have a meaningful effect on sustained performance.

Moving XeSS reconstruction to dedicated XMX hardware could reduce the amount of conventional shader work needed for upscaling.

That may improve GPU workload efficiency, but it does not automatically mean a particular handheld will gain additional battery life or higher frame rates.

Those outcomes depend on the device’s power limits, GPU architecture, driver behavior, game engine, and how the XeSS implementation interacts with the rest of the rendering pipeline.

There is also an important distinction involving Valve’s Steam Deck.

The existing Steam Deck uses AMD graphics hardware rather than Intel Arc silicon equipped with XMX engines.

It may continue using compatible cross-vendor XeSS implementations where supported, but these specific patches do not provide Intel XMX acceleration to AMD graphics hardware.

The proposed improvements are therefore more directly relevant to Intel-equipped Linux gaming PCs and handhelds than to current Steam Deck hardware.

What Gamers Should Expect From the Proposed Changes

The technical direction is promising, but the distinction between proposed support and demonstrated performance matters.

Intel’s pull requests establish a potential implementation path. They do not establish how much faster XeSS will run under Proton when XMX acceleration is enabled.

They also do not establish whether image quality, frame pacing, or power consumption will match equivalent Windows configurations.

Those questions require testing across multiple games, driver versions, and hardware platforms.

There are several areas worth watching as the implementation progresses:

• Performance: How much GPU processing time does native XMX-based XeSS save compared with the existing DP4a fallback?
• Visual quality: Do supported games show meaningful differences in image sharpness, ghosting, and temporal stability?
• Game compatibility: Which Direct3D 12 titles successfully initialize and operate through the native XeSS path?
• Library availability: Will the required native Linux library become readily accessible to ordinary Proton users?
• Release readiness: When will the coordinated patches move from review into Proton builds that gamers can test?

What About XeSS Frame Generation?

It is important not to confuse this proposal with support for every feature in Intel’s wider XeSS ecosystem.

Intel offers separate XeSS technologies for super resolution, frame generation, and latency management.

The four pull requests specifically address the hardware-accelerated super-resolution path through XMX.

They should not be interpreted as confirmation that XeSS frame generation or multi-frame generation will become available through Proton as part of the same work.

Those capabilities involve additional requirements and should be evaluated independently from the proposed super-resolution integration.

Should Intel Arc Linux Users Do Anything Now?

For most gamers, there is no immediate action required.

Installing a current standard Proton release does not automatically enable the proposed native XMX path.

Arc owners can continue using supported XeSS options already available in their games while keeping their Linux graphics drivers, Mesa packages, and Proton installations reasonably up to date through trusted distribution channels.

Enthusiasts interested in the development process can monitor the Proton integration pull request, which links the associated Wine, VKD3D-Proton, and DXVK changes.

For users considering a move from Windows to Linux, this development is an encouraging sign of continued compatibility work. However, it is not yet a reason to assume complete XeSS feature parity between the two operating systems.

Bottom Line

Intel’s proposed XeSS XMX integration addresses a meaningful limitation for Arc graphics owners running Windows games through Proton on Linux.

By connecting Windows XeSS calls to a native Linux library, the coordinated changes could allow supported games to use Intel’s dedicated matrix acceleration rather than relying on the cross-vendor DP4a fallback.

The potential benefits include more efficient upscaling and better utilization of the hardware already available in compatible Intel Arc GPUs. However, the scale of any performance or image-quality improvement remains unverified.

The next milestones are clear: upstream acceptance of the proposed changes, accessible distribution of the native XeSS library, and independent testing across supported games and hardware.

Until then, this represents progress toward stronger Intel Arc support on Linux rather than a performance upgrade gamers can install today.