xess-xmx-linux es un proyecto independiente que ejecuta XeSS Super Resolution y generación de fotogramas con aceleración XMX en juegos de Windows lanzados mediante Proton. No es una función integrada en Proton: el proyecto afirma que no modifica ni Proton ni vkd3d-proton. Su documentación describe una ruta experimental que depende de una GPU Arc compatible y de Mesa parcheado.
NeoTeo ya había explicado una propuesta anterior para llevar XeSS XMX a Proton. xess-xmx-linux plantea una implementación independiente, con requisitos concretos y resultados publicados en un Arc B390.
Cómo ejecuta XeSS en Proton
El proyecto usa bibliotecas de XeSS para Windows y un shim, una capa intermedia que redirige sus llamadas. También modifica Mesa ANV, el controlador Vulkan de Mesa para Intel, para compilar los núcleos de XeSS con Intel Graphics Compiler (IGC) y ejecutarlos en las unidades XMX.
Para elegir XeSS, el juego debe usar su renderizador DirectX 12. La instalación configura el controlador Vulkan Intel de 64 bits y variables de entorno para la sesión del usuario, con efecto en los juegos DirectX 12 que se ejecuten durante esa sesión. El proyecto incluye un script de desinstalación. En el primer lanzamiento de cada juego, la compilación de los núcleos puede tardar uno o dos minutos; después quedan en la caché ~/.cache/xess-xmx.
Requisitos y límites de compatibilidad
El proyecto se dirige a GPU Intel Arc con unidades XMX de las arquitecturas Xe-HPG, Xe2 y Xe3. Identifica Arc B390 como GPU de desarrollo y recoge pruebas de usuarios con Arc B580 y Arc A310. Esos casos no acreditan compatibilidad con todos los equipos que incorporan esas GPU.
| Área | Requisito o límite indicado por el proyecto |
| GPU | Intel Arc con XMX de arquitectura Xe-HPG, Xe2 o Xe3 |
| Controlador del kernel | xe o i915 |
| Mesa | Versiones parcheadas 26.1.2 o 26.3.0-rc3; esta última es una candidata a versión final y se había probado con menos juegos |
| Proton | vkd3d-proton como el de Proton 11 o GE-Proton 11; el desarrollo usó GE-Proton 11-6 y Proton Experimental |
| Steam | Cliente nativo de Steam; Flatpak Steam no es compatible |
| Bibliotecas del sistema | Para los controladores suministrados: glibc 2.38 y libwayland-client 1.24 o posterior |
| Límites de GPU | Xe-LPG, presente en Meteor Lake, carece de XMX; Lunar Lake y Arrow Lake-H se detectan, pero no se habían probado |
Los controladores suministrados se compilaron en Arch Linux. El proyecto indica que Debian 13 y Ubuntu 24.04 necesitan un controlador compilado para el sistema, porque incluyen libwayland-client 1.23. Si la comprobación de sesión no carga el controlador parcheado, la ruta puede volver a los controladores normales y XeSS funcionar por una vía genérica como DP4a, no por XMX.
Qué cifras publicó el proyecto en Arc B390
El proyecto informa de una ejecución de su benchmark integrado por juego. La comparación enfrenta Mesa 26.1.2 con la ruta DP4a y Mesa 26.3.0-rc3 parcheado con XMX; por tanto, cambian tanto la versión de Mesa como la ruta de renderizado.
| Juego | Mesa 26.1.2 + DP4a (fps) | Mesa 26.3.0-rc3 + XMX (fps) | XMX con generación de fotogramas 3× (fps) |
| Cyberpunk 2077 | 47,7 | 61,3 | 117 |
| Forza Horizon 6 | 43 | 46 | 98 |
El proyecto atribuye la mayor parte de la diferencia entre ambas configuraciones al compilador Jay, una mejora del compilador de sombreadores de Mesa. Estima que XMX por sí solo es alrededor de un 5 % más rápido que DP4a en estos dos juegos. Los resultados describen las pruebas publicadas por el proyecto, no una comparación que aísle únicamente el efecto de XMX.
Qué enseña la demostración de MSI Claw
ETA PRIME mostró XeSS XMX en una MSI Claw 8 EX con gráfica integrada Arc G3 Extreme / Arc B390 y un ajuste de 30 W. En el menú de ClawDeck aparecen controles para activar la ruta XMX, elegir multiplicadores de generación de fotogramas y usar Xe Low Latency; la demostración también incluye partidas de Cyberpunk 2077 y otros juegos.
El proyecto también advierte que depende de componentes internos de Mesa y vkd3d-proton. Sus multiplicadores de generación de fotogramas de 5× a 8× son experimentales y no cuentan con el respaldo de Intel; el uso de 7× u 8× añade bastante latencia. La sustitución de FSR por XeSS puede producir más parpadeo que la implementación XeSS propia de un juego.
