# Intel propone XMX para XeSS en Proton, su upscaler de Linux > Intel propone que Proton use XMX en XeSS sobre sus GPU Arc. Qué gana SteamOS, qué sigue igual en Steam Deck y por qué Valve acepta el parche. > Por José Maldonado · Tecnología · 2026-10-22 Hay una escena que se repite en cada portátil con gráficos Intel. El juego ofrece XeSS, lo activas, y la imagen mejora menos de lo que debería porque el reescalado está tomando la ruta lenta. Esa ruta tiene nombre técnico y desde hace unos días también tiene remedio en forma de parches. Damian Tomczak, ingeniero de Intel, abrió el 19 de octubre de 2026 una serie de cuatro pull requests para que XeSS aproveche los núcleos XMX dentro de Proton, la capa de compatibilidad de Steam Play. Conviene aclarar qué se juega aquí. [Proton](https://observatorioblockchain.com/tecnologia/valve-lanza-proton-11-y-gana-terreno-a-windows-en-el-gaming/) permite ejecutar juegos de Windows en Linux, y las bibliotecas de reescalado que esos juegos traen están escritas para Windows. XeSS funciona con dos motores: uno genérico que corre en GPU de casi cualquier marca y otro que usa la aceleración matricial propia de las GPU de Intel, bastante más rápido. Bajo Linux, incluso con una Arc instalada, XeSS se quedaba en el camino genérico y dejaba los núcleos matriciales sin usar. El detalle importa porque el reescalado se ha convertido en la herramienta con la que las portátiles de bajo consumo intentan sostener 60 fotogramas. Intel anunció el 28 de mayo de 2026 sus procesadores Arc G-Series para portátiles, con gráficos Xe3 y XeSS 3, y esos equipos salen al mercado con Windows 11, [según la nota de prensa de la compañía](https://www.intel.com/content/www/us/en/newsroom/news/client-computing/intel-arc-g-series-processors-set-a-new-standard-for-handheld-pc-gaming.html). Si Proton aprende a usar XMX, esos usuarios podrían cambiar de sistema sin renunciar al mejor upscaler de su hardware. Todavía no es una función: son cuatro PR abiertos y sin revisar. ## Cuatro parches que solo funcionan en orden La serie la firma un ingeniero de Intel y consta de cuatro piezas que no sirven por separado. Cada eslabón vive en un repositorio distinto y, sin el último, los otros tres no llegan a SteamOS ni a [Bazzite](https://observatorioblockchain.com/tecnologia/bazzite-actualizacion-octubre-2026/). El PR 369 de ValveSoftware/wine añade un libxess.dll integrado que reenvía las llamadas D3D12 de XeSS a la biblioteca nativa de Linux, libxess.so, de modo que el juego cree hablar con el runtime de Windows y termine ejecutando el de Linux. Los objetos D3D12 se convierten a Vulkan a través de la interfaz de interoperabilidad de vkd3d-proton, el PR 3379 habilita las extensiones de Vulkan que XeSS necesita y el PR 5992 de DXVK deja de esconder la marca de la GPU Intel cuando el reescalado lo pone Proton. El PR 10289 de Proton sube los tres submódulos anteriores, así que tiene que entrar al final. El texto del PR describe una condición que convierte esto en un parche y no en un interruptor. La DLL integrada solo se usa cuando Proton encuentra un libxess.so, primero en su directorio contrib y luego en la ruta de bibliotecas del sistema, y esa ruta se puede forzar con la variable XESS\_LIB\_OVERRIDE. Si no hay biblioteca nativa, el juego sigue cargando su propia libxess.dll de Windows, con el camino lento de siempre. [El PR 369 de ValveSoftware/wine](https://github.com/ValveSoftware/wine/pull/369) se abrió el 19 de octubre de 2026 y sigue abierto, con un único comentario de coordinación de la serie y ninguna revisión aprobada. En un repositorio así, una serie puede tardar semanas en verse. Ahí está la frontera entre una función y una promesa. Proton no puede incluir por su cuenta el binario de Intel, porque alguien tiene que aportar la biblioteca nativa, y el SDK de XeSS se distribuye con binarios cerrados. La parte abierta es la integración, no el upscaler. ## Tres upscalers con tres dueños distintos Cada fabricante ha resuelto el problema a su manera dentro de Proton, y las tres soluciones tienen edades y requisitos diferentes. NVIDIA pasa por DXVK-NVAPI, la pieza que expone NVAPI bajo Linux y que Proton activa por defecto desde la versión 9.0, según [la documentación del proyecto](https://github.com/jp7677/dxvk-nvapi). Sirve para DLSS, aunque, DLSS 4 sigue sin soporte en esa capa. AMD llegó antes por la vía oficial. VKD3D-Proton 3.0, publicado el 17 de noviembre de 2025, añadió FSR 4 mediante las extensiones de matriz cooperativa y de coma flotante de 8 bits, con una ruta nativa para RDNA 4 y una emulación sobre int8 y fp16 que el propio registro de cambios califica de hacky y que no entra en las compilaciones oficiales. En junio de 2026 Valve llevó FSR 4 a las GPU RDNA 3 discretas con Proton Experimental. Intel llega último y con una diferencia de fondo. Su upscaler no necesita una GPU de la competencia, sino su propia biblioteca y sus propios núcleos matriciales. Esa dependencia explica por qué el parche tiene que venir de Intel y no de un voluntario de la comunidad. Upscaler Qué exige bajo Linux Estado en Proton DLSS de NVIDIA GPU RTX y DXVK-NVAPI activo DLSS 4 sin soporte en VKD3D-Proton FSR 4 de AMD RDNA 4, o emulación compilada a mano VKD3D-Proton 3.0 y Proton Experimental XeSS con XMX GPU Intel con núcleos matriciales y libxess.so Cuatro PR abiertos, sin revisión ## Qué gana y qué no gana cada usuario Para quien tiene una Arc en un equipo con SteamOS o Bazzite, el cambio es el que más se nota y el que menos se puede cuantificar. Pasar de la ruta DP4a a XMX significa usar las unidades matriciales que Intel metió en sus GPU precisamente para esta tarea, con mejor imagen por fotograma y menos coste. Ninguna de las cuatro piezas incluye cifras, así que cualquier porcentaje que circule es una extrapolación de pruebas hechas en Windows. En Steam Deck no cambia nada. La consola de Valve usa una APU con gráficos RDNA 2, sin núcleos matriciales y por debajo del corte de RDNA 4 que exige FSR 4 en la ruta oficial. Sus dueños seguirán dependiendo del reescalado que traiga el juego o de la emulación de FSR 4 que exige compilar VKD3D-Proton a mano. Hay un límite que conviene tener presente. Proton no añade XeSS a un juego que no lo trae ni cambia la versión del upscaler que el estudio eligió: solo hace que la biblioteca que el juego ya carga encuentre el camino rápido en lugar del lento. En Bazzite, una distribución pensada para portátiles y equipos de salón, el cambio llegará por la misma vía que en SteamOS: actualizaciones de Proton y de sus submódulos, no un paquete propio de la distribución. Esa es la ventaja de que el trabajo se haga en común. ## Por qué Valve deja que un fabricante toque su capa SteamOS nació atada a AMD y la actualización 3.8 llegó en marzo de 2026 como versión preview con cambios pensados para Steam Machine y para hardware de terceros. La razón de fondo es comercial. Cada fabricante que entra en ese círculo amplía el catálogo de máquinas capaces de ejecutar la tienda de Valve, sitúa entre las mejoras del año la compatibilidad con plataformas recientes de AMD e Intel. El modelo de Valve consiste en aceptar código de los fabricantes en proyectos compartidos, no en abrir bifurcaciones privadas. VKD3D-Proton, DXVK y Wine reciben contribuciones de Intel, de AMD y de NVIDIA, y Valve conserva la decisión final sobre lo que entra. El precedente más claro es el propio FSR 4, porque Proton Experimental incorporó un camino de actualización para juegos con FSR 3.1 que solo funciona en GPU de AMD y lo hizo con el visto bueno de la casa. El riesgo es real. Cada ruta acelerada añade un binario de un fabricante al árbol de dependencias, y ese binario puede cambiar de licencia, de versión o de comportamiento sin avisar al resto. Valve acepta esa deuda porque la alternativa es que sus usuarios de Arc jueguen con el upscaler peor. ## La portátil con Arc todavía arranca Windows Intel presentó el 28 de mayo de 2026 sus procesadores Arc G-Series para portátiles, con arquitectura Xe3 y hasta gráficos Arc B390, y los primeros equipos, entre ellos el MSI Claw 8 EX AI+, llegan con Windows 11 desde junio. Esos procesadores estrenan XeSS 3 con generación múltiple de fotogramas, y la función bajó después a Alchemist y Battlemage con el driver 32.0.101.8509. La ironía es que el mejor upscaler de Intel en una portátil Intel sigue dependiendo de un sistema operativo que no es el de Valve. Si los cuatro PR se fusionan, SteamOS dará un paso real hacia la paridad con Windows en hardware Arc; si se quedan en revisión, la GPU seguirá rindiendo mejor fuera de SteamOS por la vía del driver. Merece la pena seguir la fusión y no el anuncio. Cuando el PR 10289 entre, la pregunta dejará de ser quién acelera XeSS y pasará a ser quién empaqueta libxess.so, con qué licencia y a partir de qué fecha.