- Al medir en una pantalla de 500Hz desde el clic hasta el cambio de brillo en pantalla, incluso aplicando X11, VRR y
dxvk-low-latency, la mediana de la latencia de extremo a extremo solo bajó 0.72ms frente a Wayland base
- Wayland nativo fue 0.14~0.22ms más lento que X11, mientras que XWayland añadió hasta 3.13ms frente a Wayland nativo, generando una diferencia mucho mayor
- La frecuencia de actualización variable (VRR) redujo la latencia entre 0.26 y 0.45ms en todas las comparaciones, y también estrechó el rango de distribución p5~p95 de 2.6~3.0ms a 2.1~2.2ms
- dxvk-low-latency redujo entre 0.10 y 0.29ms con límite de cuadros, y 0.84ms sin límite, aunque en este último caso mantuvo el uso de GPU en 95~97% en vez de 100%, mientras que los FPS bajaron de 715 a 670
- Los resultados provienen de condiciones óptimas con FPS estables y cuello de botella en CPU, además de una combinación específica de hardware y software; en juego real, la reducción del jitter con VRR y la supresión de la cola de render por parte del frame pacer podrían generar diferencias mayores que la mediana
Por qué se verificaron directamente los consejos de optimización
- En gaming en Linux existen muchísimos consejos de optimización: usar X11 en vez de Wayland, desactivar la composición, usar forks de DXVK optimizados para latencia, schedulers de kernel para juegos, aplicar
gamescope, gamemode y variables de entorno, entre otros
- En los FPS competitivos son importantes la baja latencia, la consistencia en el tiempo de cuadro y los FPS altos, pero es difícil comprobar si cambiar una configuración realmente mejora algo o si es placebo o incluso contraproducente
- El hardware del dispositivo de medición, su carcasa, firmware, código de análisis y datos en bruto están publicados en el repositorio de GitHub de click2photon
El dispositivo que mide desde el clic hasta el cambio en pantalla
- Se fija un dispositivo al monitor, se genera un clic de mouse por USB y se mide el tiempo hasta que un sensor óptico detecta el cambio en pantalla, para obtener la latencia de extremo a extremo del sistema
- El diseño inicial tomó como referencia los esquemas de OSLTT, disponibles en ese momento, y durante el desarrollo también integró ideas de m2p-latency y Open-Source-LDAT
- La construcción requirió microcontrolador, soldadura, firmware de Arduino, tiempo de integración, amplificador de transimpedancia, KiCad y diseño de carcasa
- El Adafruit QT Py RP2040 funciona como mouse USB HID con polling de 1,000Hz y genera el clic
- Justo después de enviar el clic, toma muestras del fotodiodo aproximadamente cada 24µs
- En cada clic envía al host 12,000 muestras por conexión serial y las registra como CSV
- La herramienta del host calcula una línea base por clic y busca la primera muestra que se desvía por encima de cierto umbral
- Como el tiempo de captura de las 12,000 muestras es fijo, puede calcularse el tiempo desde el envío del clic hasta el cambio de brillo en pantalla
Configuraciones de pantalla y render comparadas
- Se comparó X11 y Wayland nativo para contrastar la percepción de que Wayland se siente más lento con los resultados medidos
- También se comparó activar o no la frecuencia de actualización variable (VRR), incluyendo G-Sync y FreeSync
- Se midió la diferencia entre dxvk-low-latency y DXVK base
- El frame pacer de este fork fue integrado en el paquete oficial
proton-cachyos, y se activa con PROTON_DXVK_LOWLATENCY=1
- Se añadieron 2 casos sin límite de FPS para comprobar si el frame pacer absorbe la variación en el tiempo de cuadro y evita la acumulación de la cola de render
- En una escena estática del juego no había variación en el tiempo de cuadro y además la prueba estaba en condiciones de cuello de botella en CPU, por lo que no refleja por completo una sesión real de juego
- En una sesión real, el tiempo de cuadro puede variar según la situación dentro del juego o el uso de recursos por otros procesos
- Las pruebas de Wayland se ejecutaron por defecto en Wayland nativo usando
PROTON_ENABLE_WAYLAND=1, y para comparar también se midieron 2 casos de XWayland con VRR desactivado
Hardware y software de prueba
- Durante las pruebas solo se conectó una pantalla y la configuración de hardware fue la siguiente
- AMD Ryzen 7 5800X3D
- NVIDIA GeForce RTX 4070 SUPER
- 2 módulos DDR4 3,200MHz de 8GB
- MSI MAG 272QP QD-OLED X50, 2560×1440, 500Hz
- MSI B450 GAMING PRO CARBON AC
- El stack de software estuvo compuesto por CachyOS, Kernel 7.1.3-2-cachyos, driver NVIDIA 610.43.03-1, KDE Plasma 6.7.2-1.1 y xorg-server 21.1.24-1.1
- Se usaron
proton-cachyos-native 1:11.0.20260602-3 y dxvk 3.0
- Se mantuvo el scheduler de kernel predeterminado de CachyOS
Configuración de pantalla y DXVK
- La frecuencia de actualización del sistema se configuró en 500Hz
- En X11 se activaron el modo flip y VRR con
nvidia-settings, y cambiar VRR requiere reiniciar
- En Wayland, VRR se activa desde la configuración de KDE y no requiere reinicio
- En Wayland, el modo flip o el direct scan-out no se configuran manualmente; el compositor decide en cada cuadro
- En la pestaña Effects de KWin Debug Console se activó
showcompositing
- Si el juego era lo único mostrado en pantalla completa, estaba completamente enfocado y no aparecía un borde rojo en los bordes, se consideraba que estaba en modo flip
- Se usó un
dxvk.conf optimizado para cada condición comparada
- Con VRR desactivado:
dxgi.maxFrameRate = 500
- Con VRR activado y
dxvk-low-latency desactivado: dxgi.maxFrameRate = 497
- Al activar VRR junto con
dxvk-low-latency, se usó la siguiente configuración para frame pacing VRR de baja latencia en 500Hz
dxgi.maxFrameRate = 480
dxvk.lowLatencyOffset = 70
dxvk.framePace = "low-latency-vrr-500"
dxvk.lowLatencyAllowCpuFramesOverlap = False
- En todas las configuraciones se aplicó
d3d11.cachedDynamicResources = "c"
Entorno del juego y procedimiento de medición repetida
- El juego de prueba fue Diabotical, un juego DirectX 11, ejecutado con Heroic y Proton
- Se usó la resolución nativa y 100% de escala de render, con Vsync desactivado y el resto de los ajustes visuales lo más bajo posible
- Se vinculó a clic izquierdo el comando oculto para ocultar temporalmente la UI, usando
/bind mouse_left testlatency, y se configuró un HUD con una gran caja blanca para aumentar la diferencia de brillo al hacer clic
- Cada prueba se repitió en las mismas condiciones
- Se cerró software innecesario y se inició un servidor local en el mismo modo y mapa
- Desde una posición fijada, se alineó el mouse con una marca específica del terreno
- Se repitió 3 veces un proceso de 100 clics durante unos 2 minutos
- Se mantuvo una escena estática, sin bots, otros jugadores, movimiento ni reinicio de ronda
- Se evitó que corrieran otros procesos relevantes y también se mantuvo fija la posición del dispositivo de medición en todas las pruebas
Rango de latencia en todas las configuraciones
- Todos los casos con límite de cuadros mantuvieron estable el FPS objetivo, y el juego estuvo en cuello de botella de CPU durante toda la prueba
- Todos los casos mostraron distribuciones con forma de campana, sin grandes outliers, con un rango p5 a p95 de aproximadamente 2~3ms
- La mediana de las 8 configuraciones principales estuvo entre 4.21 y 4.93ms, una diferencia total de apenas 0.72ms
- XWayland tuvo una mediana hasta 3.13ms más alta que la configuración equivalente en Wayland nativo, registrando 8.06ms frente a 4.93ms
- En los casos sin límite de FPS,
dxvk-low-latency redujo la latencia 0.84ms frente a DXVK base
La pequeña diferencia entre X11 y Wayland nativo
- X11 fue más rápido en todas las configuraciones, pero la diferencia fue pequeña, de 0.14~0.22ms, insuficiente para explicar la percepción de que Wayland se siente mucho más lento
- low-latency y VRR activados: X11 4.21ms, Wayland 4.38ms, diferencia +0.17ms
- solo low-latency activado: X11 4.64ms, Wayland 4.83ms, diferencia +0.19ms
- solo VRR activado: X11 4.45ms, Wayland 4.67ms, diferencia +0.22ms
- ambos desactivados: X11 4.79ms, Wayland 4.93ms, diferencia +0.14ms
- La forma de la distribución de latencia entre ambos servidores de pantalla también fue muy similar
Efecto de VRR en la latencia y la distribución
- VRR mostró el mayor impacto entre los elementos comparados, y fue 0.26~0.45ms más rápido en todas las combinaciones
- X11 con low-latency: de 4.64ms a 4.21ms, una reducción de 0.43ms
- X11 con DXVK base: de 4.79ms a 4.45ms, una reducción de 0.34ms
- Wayland con low-latency: de 4.83ms a 4.38ms, una reducción de 0.45ms
- Wayland con DXVK base: de 4.93ms a 4.67ms, una reducción de 0.26ms
- El ancho entre p95 y p5 fue de 2.1~2.2ms con VRR, frente a 2.6~3.0ms sin VRR, así que también se estrechó la distribución de latencia
- Con VRR, los cuadros se escanean apenas están listos en vez de esperar al siguiente slot de scan-out, por lo que los resultados coinciden con su funcionamiento esperado
Efecto y costo de dxvk-low-latency
- En los casos con límite de FPS,
dxvk-low-latency redujo la latencia en todas las combinaciones, con una mejora media de 0.20ms, similar a la diferencia media de 0.18ms entre X11 y Wayland
- X11 con VRR: de 4.45ms a 4.21ms, reducción de 0.24ms
- X11 con VRR desactivado: de 4.79ms a 4.64ms, reducción de 0.15ms
- Wayland con VRR: de 4.67ms a 4.38ms, reducción de 0.29ms
- Wayland con VRR desactivado: de 4.93ms a 4.83ms, reducción de 0.10ms
- En las condiciones sin límite de FPS, el efecto del pacer fue mayor al evitar la acumulación de la cola de render y suavizar el frame pacing irregular
- Mantuvo la GPU cerca del cuello de botella, sin saturarla por completo
- El uso de GPU fue de 100% con DXVK base y de 95~97% con
dxvk-low-latency
- La latencia bajó de 5.27ms a 4.43ms, una reducción de 0.84ms
- Los FPS cayeron de 715 a 670, es decir, 45FPS menos
La gran latencia adicional de XWayland
- Si se desactiva
Enable Wine-Wayland (Experimental) en Heroic Launcher o PROTON_ENABLE_WAYLAND=1, el juego se ejecuta mediante XWayland
- XWayland añadió mucha más latencia que Wayland nativo
- con low-latency activado: de 4.83ms a 5.95ms, un aumento de 1.12ms
- con DXVK base: de 4.93ms a 8.06ms, un aumento de 3.13ms
- Los 3.13ms añadidos en el caso con DXVK base fueron mayores que todos los demás efectos medidos combinados, y no se debieron a unos pocos cuadros malos elevando el promedio, sino a un desplazamiento de toda la distribución
- Al añadir
dxvk-low-latency en XWayland, la latencia bajó 2.11ms, la mayor mejora registrada entre todos los casos
Alcance de los resultados e interpretación práctica
- Los resultados medidos se limitan a condiciones óptimas: FPS estables con límite, cuello de botella en CPU y una escena estática, además de un stack específico de hardware y software
- En otros entornos, los valores absolutos de latencia pueden variar, pero se considera que los aumentos y reducciones observados por configuración deberían trasladarse en términos generales
- En pantallas con menor frecuencia de actualización, las mejoras de VRR y del pacer de baja latencia podrían ser mayores
- X11 fue 0.14~0.22ms más rápido que Wayland, pero ese margen podría reducirse con el trabajo de optimización en KWin, y otros compositores Wayland incluso podrían rendir mejor desde ya
- Excluyendo XWayland, aplicar X11, VRR y
dxvk-low-latency juntos deja una mediana 0.72ms por debajo de la configuración base de Wayland
- Aunque la diferencia de mediana es pequeña, VRR reduce el jitter de latencia y
dxvk-low-latency ayuda a mitigar las caídas en el tiempo de cuadro y los cuellos de botella de GPU que aparecen en sesiones reales de juego
Proyectos similares de medición de latencia de entrada
1 comentarios
Comentarios de Hacker News
Lo bueno de Linux es que no solo permite este tipo de análisis, sino que además realmente lleva a mejoras en el ecosistema. Los resultados llegan a los desarrolladores de software gráfico y a los encargados de empaquetar las distribuciones, pero en Microsoft parece difícil esperar una vía de mejora así
Usé Windows durante mucho tiempo y hace poco me pasé a Linux; me gustó que KDE Plasma se siente más ágil que Windows 11 y que, si surge un problema, uno mismo puede meter mano para mejorarlo. Si hace tiempo que no pruebas un escritorio Linux, recomiendo Bazzite, una Fedora ajustada para gaming; incluso si no juegas, permite armar rápido un escritorio muy pulido
Antes podías cambiar todo a tu gusto con un solo archivo de configuración intuitivo, pero ahora hay montones de capas de abstracción para temas, íconos, modo claro y modo oscuro, y aun así cuesta encontrar una combinación que funcione bien. En modo claro aparece texto gris sobre gris claro, en modo oscuro texto negro sobre fondo negro, y con temas como Adwaita a veces ni el visor de PDF logra decidir bien los colores del texto y del fondo
Ningún tema hace que las barras de desplazamiento sean lo bastante visibles ni distingue con colores claros entre ventanas activas e inactivas. Incluso Windows 3.11 hacía mejor las barras de desplazamiento, la indicación de ventana activa y la personalización de colores; en ese sentido, era mejor antes de sobre-diseñarlo todo
Intel(https://www.techpowerup.com/312122/psa-intel-graphics-driver...) y Nvidia(https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...) también recopilan este tipo de datos de usuarios que dieron su consentimiento. Eso sí, en ambos casos es opcional, así que puede que no haya muchos datos de gamers entusiastas
Hay muchos cambios graduales, pero a menudo se quedan atrapados durante años en óptimos locales. Aun así, está bien que sea relativamente fácil mirar cómo funciona todo por dentro, y no está muy claro por qué Windows y macOS tendrían que ser necesariamente de código cerrado
Hace unos meses cambié mi sistema principal y entorno de juego a Fedora, y en general se sintió más ágil que Windows; esta medición además respondió parcialmente algunas dudas que tenía sobre la latencia de entrada en juegos
Hace poco me pasé a Hyprland sobre Wayland y me da curiosidad cómo cambiarían los resultados; ahora que ganó popularidad, estaría bien que lo volvieran a probar. También consideré Gamescope, pero he leído que no funciona bien con Nvidia, y además me enteré recién de que existe algo como un kernel optimizado para gaming. En juegos de pelea competitivos, la latencia de entrada es muy importante, así que me interesa escuchar experiencias de gente que haya probado optimizaciones parecidas
Para jugar me gustó Hyprland, y me resultó más fácil ajustar detalles como frecuencia de refresco variable y tearing mediante Gamescope que cuando usaba AwesomeWM en X11. La configuración en Lua también se siente familiar viniendo de AwesomeWM
Como la prueba se hizo con una pantalla de 500 Hz, puede que se hayan ocultado muchos problemas que sí aparecen en pantallas de baja tasa de refresco. Que XWayland haya sido 3 ms más lento podría incluso significar que quedó un frame atrás con esa frecuencia
Si se probara a 120 Hz o 60 Hz, sería más fácil distinguir entre pequeñas diferencias en el momento de ejecución y el efecto grande de retrasarse un frame completo
Al final del texto resulta extraño que se considere que Wayland es más lento, pero los resultados de XWayland podrían ser justamente la razón. Es posible que quienes ejecutaban juegos de X11 sobre Wayland sí hayan percibido una latencia relevante. Ojalá hubiera más mediciones reales de este tipo en varias áreas
El autor eliminó bien otras variables de confusión, pero quienes sintieron que Wayland era más lento podrían haber partido de un entorno no optimizado y, al pasar a una configuración de baja latencia, también haber corregido ajustes relacionados
A diferencia de X11, donde Xorg funciona de forma parecida en casi todas partes como implementación de referencia estándar de facto, las diferencias entre implementaciones de Wayland son grandes. Podría haber compositores más lentos que KDE Plasma, usado en la prueba, y también otros más rápidos
La expresión latencia de entrada de Wayland en sí mezcla capas distintas, como decir
suavidad de animación HTTP. Lo que este artículo midió fue Xorg, KWin y XWayland; otras implementaciones de X11 y Wayland pueden comportarse distintoAun así, la latencia adicional de XWayland es lo bastante grande como para que resulte sospechoso tratarla solo como un costo extra menor
En particular, Emacs en modo pgtk funciona mucho mejor en GNOME, mientras que en KWin usa bastante CPU al hacer scroll y a veces incluso tiene algo de retraso en alta resolución
También sería muy interesante ver cómo saldría la comparación con Windows en el mismo hardware
En Breaka Club están abordando este problema directamente mientras enseñan a programar a niños con una versión modificada de Overcooked 2!
Como es difícil instalar mods en los equipos de la escuela, transmiten por WebRTC una copia de OC2 con el mod incluido, y los niños juegan desde Mobile Safari en iPad con un gamepad en pantalla. La instancia del juego corre en un contenedor Docker sobre Kubernetes/k3s en hardware viejo de Nvidia, y como pasa por internet y por la red escolar, están reduciendo la latencia total con cosas como transferencia sin copia usando NVEnc y DMABuf
Ahora mismo están sufriendo el costo adicional de entrada de XWayland, aunque como la entrada viene de un dispositivo virtual el comportamiento podría ser distinto. La optimización de extremo a extremo es difícil y el rendimiento actual es aceptable. Video sobre programación con OC2: https://www.youtube.com/watch?v=ITWSL5lTLig
Compran una cantidad limitada de licencias de OC2 y cada pod recibe una al iniciarse; si ya están todas en uso, los niños juegan a otro juego
En X11, al usar renderizado compuesto, si una ventana en pantalla completa envía al compositor una pista para desredirigir, este puede dejar de componer mientras no haya otros elementos dibujándose en pantalla y pasar directamente al monitor la swapchain de la aplicación. En la práctica, es una forma casi óptima y difícil de mejorar
Si aparece otra ventana encima o el compositor decide que no puede hacer ese passthrough directo, aparece un paso intermedio en el que compone la ventana de la aplicación y otros elementos en un búfer temporal. Si la desredirección se rompe —por ejemplo, porque la ventana se crea con 1 píxel menos que la altura de la pantalla— o si se usa XWayland, la latencia puede aumentar; es una limitación fundamental y problemas parecidos también aparecen en los compositores de otros sistemas operativos
Wayland también ha explorado display planes, donde el hardware de la GPU compone directamente varias capas. Con eso, el juego podría renderizar al máximo de cuadros por segundo mientras las ventanas superpuestas se dibujan en un plano aparte, permitiendo composición sin efectos secundarios, pero no sé si eso se use hoy en entornos de producto reales
Mientras que las consolas tienden a un número fijo de cuadros por segundo en la salida y resolución dinámica, la PC tiende a fijar la resolución y dejar dinámicos los cuadros por segundo y el espaciado entre tiempos de cuadro. Me pregunto cómo se relaciona esto con la latencia
En especial en juegos competitivos, se apunta a cuadros por segundo muy por encima de la tasa de refresco de la pantalla, pero no estoy seguro de si es una ventaja real o una ilusión
El punto clave no es ver más cuadros, sino ver información más reciente. También se podría retrasar el inicio del render para que termine justo antes de la actualización de pantalla, pero si se falla por poco ese momento se produce un tirón severo, y ni el tiempo de ejecución de la GPU ni el tiempo de envío de trabajo por parte de la CPU son deterministas
Idealmente, bastaría con no generar cuadros innecesarios e iniciar el render justo antes de la actualización de pantalla, pero si se pierde la fecha límite aparece un tirón muy molesto
Un cuadro nuevo puede entrar a mitad del barrido de pantalla y producir tearing, pero debajo de la línea de corte se muestran píxeles más recientes. Por eso, en un solo cuadro del monitor pueden mezclarse varios cuadros renderizados y, aunque no sea tan bueno como una pantalla VRR de alta tasa de refresco, sí reduce la latencia. En juegos donde la respuesta es menos crítica, es común usar VSync para igualar los cuadros a la tasa de refresco y eliminar el tearing
Algunos juegos ajustan la resolución en tiempo real para mantener una tasa de cuadros estable. En PC, históricamente se podía ejecutar un juego incluso en equipos muy por debajo del objetivo original, las tasas bajas eran culturalmente más toleradas y, si no gustaba, siempre se podía actualizar el hardware. En consola no había ruta de actualización y había que optimizar para una sola configuración, así que antes de que el rendimiento cayera demasiado tenía más sentido bajar la resolución
No significa que el juego reciba más eventos de entrada, pero sí que puede procesarlos y reflejarlos más rápido. No es una ilusión, aunque los rendimientos decrecientes son grandes, y el efecto varía según la cola de cuadros, VSync, la tasa de refresco variable, cuellos de botella de CPU o GPU, y la estructura del bucle de entrada y simulación
El autor intenta descartar la ilusión desde el principio, pero al final la latencia no deja de evaluarse por sensación y experiencia de uso. Personalmente, creo que cómo lo siente cada quien es la prueba final, y aunque los datos sean útiles para diagnosticar y corregir la latencia real, en la mayoría de las UI/UX está bien apoyarse en la preferencia y la percepción
Acompañarlo con evaluaciones menos técnicas, como una calificación por estrellas, también puede evitar que las pruebas y la recolección de datos se vuelvan excesivamente prisioneras de la metodología. En pruebas muy cuidadosamente armadas, podrían quedar fuera condiciones de degradación de rendimiento que aparecen con frecuencia en el uso cotidiano de cierto entorno