El impulso de velocidad de los juegos en Linux viene del kernel

Los juegos en Linux ya no son solo una historia de trucos con Wine y del pulido de Proton. Las mejoras más importantes provienen ahora del propio kernel de Linux, donde características que antes se asociaban a las API de Windows se están reconstruyendo de forma nativa para que los juegos funcionen más rápido y se comporten mejor en sistemas como la Steam Deck.

El último ejemplo es NTSYNC, un controlador a nivel de kernel que ayuda a los juegos de Windows a coordinar su trabajo sin el malabarismo de la capa de traducción que Linux solía necesitar. Ya forma parte de la pila en sistemas Steam Deck actualizados, y apunta a un cambio más amplio: los juegos en Linux dejan de ser tanto un truco de compatibilidad y se convierten en una plataforma con su propia infraestructura.

NTSYNC lleva la planificación al estilo Windows a Linux

Los juegos modernos son básicamente pequeñas ciudades‑estado de caos. El renderizado, la física, el audio, la IA, la transmisión de activos y la gestión de entradas deben mantenerse en sincronía entre múltiples núcleos, y Windows hace tiempo que dispone de mecanismos nativos para esa coordinación.

Recomendado

Fulu ofrece $10K para vulnerar los bloqueos de PS5 y permitir Linux

Antes de NTSYNC, Wine y Proton tenían que imitar esos mecanismos con soluciones como esync y fsync. NTSYNC cambia las reglas del juego al incorporar el comportamiento relevante en el kernel, de modo que Linux puede responder a esas llamadas de API directamente en lugar de hacerse pasar por Windows lo suficiente para una conversación en la cena.

Eso importa porque reduce la cantidad de emulación en el medio. Las llamadas de API para los desarrolladores no cambian, pero la ruta subyacente es más limpia, y eso suele significar menos sorpresas cuando los juegos empiezan a llevar el sistema al límite.

Las grandes afirmaciones sobre FPS necesitan una comprobación de la realidad

Las cifras llamativas de los benchmarks relacionadas con NTSYNC se midieron frente a Wine upstream sin modificar, lo que no es cómo la mayoría de la gente juega en Linux. La mayoría de los usuarios confía en Proton, y Proton ya incluye fsync, por lo que la comparación que hace que la función parezca descomunal también es la menos relevante para los jugadores habituales.

En comparación con fsync, las ganancias son menores. Los verdaderos beneficiados son los juegos que ya tenían problemas, donde una mejor vía de sincronización puede aumentar el rendimiento y suavizar comportamientos que las simples tablas de FPS nunca capturan.

• Wine upstream: las mayores ganancias publicadas parecen dramáticas.
• Proton: ya usa fsync, por lo que la mejora es más modesta.
• Steam Deck: recibe la corrección a nivel de kernel en sistemas actualizados.

Valve está llevando a Linux más allá de la cultura de los apaños

Que Valve incluya NTSYNC en la versión estable de SteamOS en marzo dice mucho sobre lo lejos que ha llegado la plataforma. Si fsync fuera realmente suficiente para todos los casos, Valve tendría poco incentivo para seguir investigando; en cambio, decidió que arreglar los casos límite en la raíz valía la pena.

Esa es la parte interesante de la historia de los juegos en Linux. El ecosistema ya no solo toma prestado el comportamiento de Windows; lo está incorporando en el kernel para que toda la pila se beneficie, ya sea que la máquina ejecute Bazzite, CachyOS, Fedora o Ubuntu.

Y sí, esto sigue siendo en gran medida una historia de Valve. La compañía, CodeWeavers y un flujo constante de colaboradores han convertido los juegos en Linux en un proyecto de ingeniería a largo plazo en lugar de una sucesión de parches de fin de semana. Con Linux ahora por encima del cinco por ciento de los usuarios de Steam, el caso de negocio para continuar ya no es teórico.

Qué viene después de NTSYNC

Probablemente NTSYNC no será la última característica nacida en Windows que llegue a Linux porque los jugadores la pidieron. El patrón es demasiado útil, la audiencia es demasiado grande, y el coste de dejar extraños errores de compatibilidad al azar sigue siendo mayor que hacer correctamente el tedioso trabajo en el kernel.

La siguiente pregunta es qué dependencia de Windows se reconstruirá primero, y si los juegos en Linux seguirán ganando al volverse menos reconocibles como «Linux» a nivel de llamadas al sistema. Si los últimos años sirven de guía, la respuesta será más de lo mismo: menos escapatorias ingeniosas, más soporte nativo y mucha menos paciencia con los viejos trucos que son «suficientemente buenos».