- Según pruebas de Ars Technica, SteamOS mostró una mejora notable en la tasa de cuadros en cuatro de los cinco juegos evaluados
- Returnal, Borderlands3, Cyberpunk 2077, Homeworld 3, Doom: The Dark Ages
- Solo Borderlands 3 mostró un nivel de rendimiento similar tanto en Windows como en SteamOS
- En general, los drivers predeterminados de SteamOS ofrecieron mejores resultados que los drivers predeterminados de Windows
- SteamOS mostró ventaja en aspectos como menor sobrecarga del sistema operativo y optimización de Proton
- Microsoft también está mostrando movimientos de respuesta al anunciar funciones de optimización de Windows para juegos
Principales mejoras de rendimiento
- SteamOS confirmó un aumento notable en la tasa de cuadros en 4 de 5 juegos
- Returnal, Borderlands3, Cyberpunk 2077, Homeworld 3, Doom: The Dark Ages
- Solo Borderlands 3 mostró resultados de rendimiento casi iguales en ambos sistemas operativos, aunque en este juego Windows tendió a registrar cifras ligeramente más altas
- En algunos juegos, solo cambiar de sistema operativo mostró una pérdida de tasa de cuadros de entre 8% y 36%
- En el caso de Homeworld 3, al instalar el driver gráfico provisto por Asus, Windows alcanzó un rendimiento similar al de SteamOS con configuración gráfica baja
- En los otros cuatro juegos, se confirmó que el driver predeterminado de Windows de Lenovo quedó muy por debajo en rendimiento frente al driver de SteamOS
Actualizaciones de drivers y cambios de rendimiento
- Al instalar manualmente el driver de Asus en Windows, se observó una mejora general del rendimiento
- En la configuración gráfica 'Low' de Homeworld 3, el rendimiento de ambos sistemas operativos fue casi equivalente
- En el resto de las pruebas, incluso Windows con drivers actualizados sufrió una pérdida de cuadros de 8% a 36% frente a SteamOS
Optimización de SteamOS y Proton
- Aunque SteamOS ejecuta juegos de Windows mediante la capa de compatibilidad Proton, en la práctica mostró un rendimiento superior al de Windows
- Se analiza como resultado de la optimización continua de Valve sobre Proton y los drivers gráficos Mesa
Sobrecarga del sistema operativo y respuesta de Windows
- Al ejecutarse en SteamOS, se reducen las tareas innecesarias en segundo plano, lo que favorece el rendimiento
- Microsoft también reconoce este problema y recientemente, mediante el anuncio de "Xbox Experience for Handheld", presentó una política de optimización del rendimiento para juegos, como minimizar tareas en segundo plano y posponer tareas no esenciales
- Por esto, se puede esperar que en el futuro las consolas portátiles para juegos basadas en Windows también apunten a ofrecer tasas de cuadros más altas
1 comentarios
Comentarios en Hacker News
Según la experiencia personal de los últimos años, el ranking de rendimiento en juegos sería así: en 1.º lugar Steam en Linux usando Proton y Wayland (Niri), en 2.º Proton con X11 (Xfce), en 3.º Steam en Windows y en 4.º los juegos ejecutados en Linux de otras maneras. Lo que más se notó al pasarse a Linux fue la mejora en la consistencia de los cuadros, con mucha menos microinterrupción ocasional, haciendo que los juegos se sintieran mucho más estables y predecibles. También comenta que al cambiar de X11/Xfce a Wayland/Niri sintió una subida general de FPS. Además, le pareció llamativo que, tras varios intentos, recién a comienzos de 2023 logró establecerse con éxito. Aun así, menciona que es inevitable que el tiempo de arranque de los juegos suela ser más largo al ejecutarse mediante Proton o Wine
Lo curioso es que incluso en juegos con port nativo para Linux, hubo casos en los que la versión de Windows corriendo con Proton rendía mejor. Da como ejemplos Civ5, Civ6 y Cities Skylines (1). En su caso lo nota todavía más porque usa hardware no orientado a gaming (una laptop con GPU Nvidia 3050 para portátil). En Cities Skylines, por ejemplo, en Linux se queda alrededor de 20 fps, mientras que en Windows se mantiene de forma constante entre 45 y 60 fps. También menciona que Diablo 4 tiene una respuesta tan pobre en Linux que en la práctica no se puede jugar. Su postura es que para quienes tienen hardware gamer de alto rendimiento Linux es suficiente, pero en entornos modestos Windows sigue teniendo ventaja
Elogia a Niri como un window manager (WM) realmente genial. Después de ver en HN una nota de Phoronix sobre la incorporación del modo overview, por fin se cambió de Sway a Niri. Comenta que en juegos a pantalla completa o con ventanas flotantes, Niri presenta mucho menos lag y trabas que un entorno X11 (quizá gracias a
xwayland-satellite). Como tip menor, menciona que fue difícil encontrar una barra compatible con i3status-rs y que finalmente terminó usando i3bar-riverLleva años jugando en Linux y en general coincide con gran parte de las opiniones sobre framerate. Usando ZFS (single NVMe) se pueden experimentar tiempos de carga mucho más rápidos que en Windows. Comparte un caso real en el que, comparando con su esposo usando Windows en el mismo hardware, muchas veces sus juegos cargaban unos 10 segundos antes
Pregunta si existe alguna manera de hacer que Wayland funcione de forma realmente usable en un entorno con GPU Nvidia. Comenta con honestidad que cada vez que lo intenta todo se siente lento y el sistema completo más pesado que con X11
Además de que los juegos de Steam en Linux suelen tardar más en arrancar por Proton/Wine, agrega que su impresión personal es que en Linux los juegos de Steam compilan shaders en la CPU y que además parecen estar menos optimizados. En cambio, Windows parecería ofrecer shaders precompilados o aprovechar la GPU, y ahí habría una diferencia. Aun así, la experiencia con Wayland + Linux le parece mucho más estable y con bastante menos stutter que en Windows. Eso sí, no está seguro de si la diferencia se debe al sistema operativo en sí o a que en Windows es muy fácil ir instalando cosas hasta volver el sistema innecesariamente pesado. También influye que sus usos de cada OS son bastante distintos
Sostiene que la última pieza que le falta al gaming en Linux para estar completo es el anti-cheat. Las empresas principales evitan darle soporte por la falta de seguridad a nivel kernel, y aun cuando el anti-cheat existe, muchas veces los desarrolladores del juego no lo habilitan (como en el caso de Destiny). Si los juegos AAA funcionaran sin problemas, dejaría Windows por completo. Llama a SteamOS la mejor innovación en la historia del gaming
Afirma que el anti-cheat moderno en realidad no deja de ser un parche temporal. Con la mejora de la seguridad del OS, la inviabilidad de mantener anti-cheat a nivel kernel en entornos de baja confianza y la naturaleza cambiante de esta carrera del gato y el ratón, el enfoque tradicional (basado en hooks del kernel) tiene límites muy claros. Propone alternativas más eficaces, como hacer todas las verificaciones en el servidor y dar al cliente solo la información necesaria. Espera que si juegos representativos como UT adoptan esta arquitectura, los métodos anticuados desaparecerán de forma natural
Opina que los juegos multijugador sin servidores dedicados tienen un límite inevitable. No quiere un demonio anti-cheat metiéndose en el kernel para vigilar archivos o memoria. Sostiene, a partir de su experiencia, que las comunidades con servidores dedicados gestionan a los jugadores de forma mucho más eficaz que el matchmaking centralizado
Interpreta que Epic, en particular, culpa a la complejidad por negarse a dar soporte a Linux, pero que en realidad también hay una parte de exclusión deliberada porque no le gusta que Steam sea la tienda estándar de facto
Recuerda que Easy Anti Cheat y Battle Eye ya tienen soporte nativo para Linux desde hace años, pero que la activación real depende del desarrollador del juego. Aproximadamente el 40% de los juegos con anti-cheat funcionan en Linux, y se puede comprobar en areweanticheatyet.com
Con tono de nostalgia poética, recuerda tecnologías como Valve Anti-Cheat (VAC) de la época en que Counter-Strike y otros impulsaban la popularidad de Steam. Se pregunta por qué VAC no logró evolucionar al ritmo de los tiempos. Le gustaría que se reinvirtiera en VAC para la era de Linux y que se lo convirtiera en una alternativa competitiva frente a Easy Anti Cheat
Si los juegos de Windows corren más rápido en SteamOS mediante Proton, entonces los desarrolladores deberían priorizar SteamOS API por encima de Windows, según esta postura. Así podrían mantener compatibilidad con Windows y al mismo tiempo maximizar el rendimiento. Propone que motores importantes como Unity y Unreal refuercen CI y las pruebas teniendo a SteamOS como objetivo principal. Se pregunta si Valve opera una granja de CI/CD para SteamOS y expresa expectativa por plantillas y bibliotecas en Rust que permitan build/test multiplataforma
Como respuesta, se remarca que Windows API es la referencia real (True Source) del comportamiento de los juegos. Si algo funciona en Windows pero no en Proton, Valve corrige Proton; pero si algo funciona solo en Proton y no en Windows, al final el juego corre riesgo de romperse. En Proton conviene evitar funciones que no encajen bien con Windows y, al probar juegos, considerar también entornos como Steam Deck, pero aun así se considera deseable mantener una estrategia de desarrollo con prioridad en Windows
Se señala que el único ABI estable en el entorno de SteamOS es Win32, por lo que desarrollar apuntando solo a SteamOS podría generar problemas de compatibilidad a largo plazo
Se comenta que, dado que Epic posee Unreal Engine, es dudoso que esté muy dispuesto a optimizar para SteamOS y sus APIs. También se menciona como contexto la competencia entre Epic Store y Steam
Se hace una observación realista: la mayor parte del mercado (99%) gira en torno a Windows. Proton, al final, no deja de ser una implementación de Win32, así que en esencia se sigue apuntando a Windows
Comparte una experiencia curiosa de la época de Windows XP: ejecutaba Windows dentro de una VM de VMWare sobre Linux y, sorprendentemente, eso resultó más rápido que usar solo Windows en el mismo hardware
Hace poco se cambió a Arch (no basado en SteamOS) y lo evalúa como una experiencia bastante sólida. Eso sí, admite con sinceridad que no funciona perfecto out-of-the-box y que cada juego requiere un poco de configuración. Como mucho, se trata de añadir parámetros al comando de ejecución, así que no le pareció algo difícil, y comenta que casi todos los consejos necesarios se pueden obtener en Proton DB y en comentarios de la comunidad. Expresa que casi no tiene intención de volver a Windows
Hace unos 10 a 15 años alternó el mismo juego entre Windows y Linux (Wine), guardando entre 100 y 200 archivos de partida, y sorprendentemente la carga de la lista de saves en Linux (Wine) era el doble de rápida que en Windows. Expresa curiosidad por no entender cómo podía darse esa diferencia, sobre todo considerando que NTFS no es el sistema de archivos nativo de Linux
Señala que si SteamOS y Ganoo/L00nockz (probablemente una forma humorística de escribir GNU/Linux) se establecen por completo como plataforma de gaming, planea armar una PC para juegos por primera vez desde 2012. Usa Mac y, aunque está conforme con la base Unix para desarrollo, lamenta que la experiencia gaming siga estando por detrás incluso de Linux. Espera grandes cambios dentro de cinco años, cuando se consoliden los lanzamientos AAA y la estabilidad de los drivers de GPU
Se responde que, en realidad, los juegos AAA ya funcionan bien desde hace años y que, usando el cliente de Steam y una GPU AMD, Linux ya es una excelente plataforma de gaming
Desde el lanzamiento de Steam Deck, se considera que prácticamente todos los juegos funcionan bien en Linux. Solo quedan como excepción algunos títulos rotos intencionalmente (por ejemplo, por integración de anti-cheat). La compatibilidad se puede revisar en protondb.com; de los 300 juegos principales de Steam, en realidad solo 17 no funcionan, y 5 de esos ni siquiera son juegos sino utilidades
Dice que siempre ha deseado que Windows se volviera un sistema basado en Unix para disfrutar lo mejor de ambos mundos, tanto en desarrollo como en juegos. Siente de forma positiva que la realidad actual ya se está acercando bastante a eso
Comparte con ironía algunos enlaces y debates de HN sobre que el kernel de Windows también es más lento que el de otros OS: post del blog discusión relacionada en HN
Afirma que llamar a Proton una "translation layer" tiene algo de impreciso. Explica que la Win32 API no es un conjunto de syscalls a nivel sistema, sino un conjunto de funciones registradas en DLL; Proton en Linux proporciona DLL que implementan esa Win32 API usando syscalls de Linux, mientras que Windows simplemente usa DLL que llaman a sus propias syscalls, y ahí está la diferencia estructural
Como contraargumento, se responde que incluso la página oficial de Wine lo describe directamente como una 'capa de compatibilidad' que traduce llamadas en tiempo de ejecución, así que la expresión translation layer tampoco estaría tan equivocada
Expresa respeto por la persistente historia de desarrollo de Wine (incluyendo Proton). En otro tiempo se lo ridiculizaba diciendo que era una solución que solo creaba problemas nuevos, pero ahora se le considera un arma potente para reemplazar Windows
Con humor, pregunta si funciones como
sscanf()también llegaron a implementarse de forma innecesariamente compleja por razones de compatibilidadSeñala que Proton/Wine incluso implementa directamente varias syscalls de NT, y que en realidad muchos programas de Windows también usan esas syscalls directamente
Da una explicación básica: la esencia de Wine es traducir el ABI de Windows (interfaz binaria) al OS Linux y su userland. Es decir, el acto mismo de traducción es la clave del port
Comenta que esperaba una diferencia de rendimiento de entre 20 y 30%, pero que se sorprendió al ver algo más cercano a 200 o 300%. Dice que le gustaría que Microsoft lanzara un “Windows para gaming” quitándole funciones innecesarias, y añade que hoy en día él mismo usa Windows únicamente para ejecutar Steam