Latencia de la cola de renderizado, NVIDIA Reflex y AMD Anti-Lag: eliminación del retardo de entrada por cuello de botella de GPU

La paradoja de la latencia a altos fotogramas por segundo

Una creencia muy extendida en los juegos de PC es que alcanzar una tasa de fotogramas por segundo (FPS) elevada garantiza de forma automática una latencia de entrada mínima. No son pocos los jugadores competitivos que invierten en tarjetas gráficas de última generación, reducen al mínimo la calidad visual y observan con satisfacción cómo su contador de fotogramas se sitúa entre 140 y 240 FPS, para luego experimentar una molesta sensación de "ratón flotante" o una respuesta lenta e imprecisa al apuntar.

Esta discrepancia surge de confundir el rendimiento bruto o tasa de transferencia (throughput) con la capacidad de respuesta (responsiveness):

+--------------------------------------------------------------------------+
|             RENDIMIENTO BRUTO (Throughput) vs. RESPUESTA (Responsiveness)|
+--------------------------------------------------------------------------+
|  TASA DE FOTOGRAMAS (Throughput / Rendimiento bruto)                     |
|  - Cantidad de fotogramas que el hardware procesa y muestra por segundo. |
|  - Métrica: FPS o tiempo de fotograma (Frametime, ms = 1000 / FPS).      |
|  - Determina la fluidez visual, la claridad de movimiento y la nitidez.  |
+--------------------------------------------------------------------------+
|  LATENCIA DEL SISTEMA (Responsiveness / Capacidad de respuesta)          |
|  - Tiempo total desde la acción física (clic o movimiento del ratón)     |
|    hasta la emisión correspondiente de fotones en la pantalla.           |
|  - Métrica: latencia de extremo a extremo (milisegundos, ms).            |
|  - Puede dispararse de forma drástica aunque los FPS sigan siendo altos. |
+--------------------------------------------------------------------------+

Cuando un sistema de juego se vuelve limitado por la GPU (GPU-bound) —situación en la que el uso de la tarjeta gráfica alcanza entre el 98% y el 100% de saturación—, el cuello de botella se traslada a la cola de renderizado (Render Queue) por software. La CPU, libre de la pesada carga de rasterización, procesa la física del juego y despacha llamadas de dibujo (Draw Calls) a un ritmo superior al que la saturada GPU puede asimilar. Para evitar que la GPU quede desocupada e inactiva (hambruna de GPU o starvation), las API gráficas y los controladores apilan estos fotogramas en un búfer previo.

Aunque este búfer mantiene la GPU al 100% y maximiza la media de FPS, impone un severo coste de latencia: el motor del juego muestrea la posición del ratón en la fase de simulación de la CPU, pero ese fotograma debe esperar en la cola detrás de dos o tres fotogramas previos antes de que la GPU pueda dibujarlo y enviarlo al monitor. En consecuencia, la retícula en pantalla refleja decisiones tomadas decenas de milisegundos atrás.

Anatomía de la canalización de latencia de extremo a extremo

Para localizar con precisión dónde se produce la acumulación en la cola de renderizado, es necesario analizar el recorrido completo desde el clic hasta la pantalla:

[ Ratón / Teclado ]
        |
        | 1. Latencia del periférico (antirrebote del microinterruptor, MCU, sondeo USB)
        v
[ Sistema operativo y bucle del juego ]
        |
        | 2. Muestreo de entrada y simulación (la CPU actualiza físicas, cámara y lógica)
        v
[ Hilo de renderizado (Render Thread) ]
        |
        | 3. Envío de renderizado (la CPU construye las llamadas de dibujo y las despacha a la API)
        v
+==========================================================================+
| 4. COLA DE RENDERIZADO DE LA API Y EL CONTROLADOR (El cuello de botella) |
|    - Se acumula cuando la GPU alcanza el 99% - 100% de uso               |
|    - Profundidad habitual: de 1 a 3 fotogramas pre-renderizados          |
|    - Retardo acumulado: profundidad de la cola * tiempo de fotograma     |
+==========================================================================+
        |
        v
[ Procesador gráfico (GPU) ]
        |
        | 5. Ejecución en GPU (geometría, rasterizado, sombreado de píxeles, posprocesado)
        v
[ Canalización de visualización ]
        |
        | 6. Presentación (Present), sincronización vertical (V-Sync) y barrido del panel
        v
[ Fotones emitidos que alcanzan el ojo del jugador ]

Cuantificación del retardo en la cola de renderizado

En un título que funciona a 60 FPS estables ($16,67\text{ ms}$ por fotograma), si el controlador gráfico almacena dos fotogramas en búfer:

$$\text{Latencia de la cola} = 2 \times 16,67\text{ ms} = 33,34\text{ ms}$$

Si sumamos el tiempo de sondeo de periféricos, la simulación del motor y el propio dibujado en GPU (unos $25\text{ ms}$ adicionales), la latencia total de extremo a extremo rozará los $60\text{ ms}$.

Incluso a 144 FPS ($6,94\text{ ms}$ por fotograma), una cola descontrolada de dos fotogramas añade cerca de $14\text{ ms}$ de pura espera. Para jugadores competitivos que dependen de la memoria muscular y de reflejos milimétricos, esta fluctuación constante arruina la puntería.

Modos de baja latencia del controlador frente a SDK integrados en el motor

Para erradicar la cola de renderizado, los fabricantes de tarjetas gráficas intentaron en un principio resolverlo mediante el controlador de pantalla. Sin embargo, la llegada de las API gráficas de bajo nivel expuso las limitaciones de este método y forzó la integración directa en el código del juego.

1. Controladores externos: NVIDIA Ultra-Low Latency y AMD Radeon Anti-Lag 1

Los ajustes disponibles en los paneles de control de la tarjeta gráfica (como el "Modo de baja latencia: Desactivado, Activado, Ultra" de NVIDIA o el primer "Radeon Anti-Lag" de AMD) operan de forma externa al proceso del juego:

• Modo "Activado" (On): Restringe el límite de fotogramas pre-renderizados en el controlador de los habituales 2-3 a un máximo estricto de 1.
• Modo "Ultra": Intenta sincronizar el envío de llamadas de dibujo con el intervalo de refresco vertical de la pantalla para conseguir un renderizado casi justo a tiempo (Just-In-Time).

Por qué fallan en DirectX 12 y Vulkan

Estas intervenciones del controlador se diseñaron para API tradicionales como DirectX 9 y DirectX 11, donde el controlador gestionaba de forma autoritaria las colas de órdenes y los búferes traseros.

En cambio, en DirectX 12 y Vulkan, el control de la cadena de intercambio (swapchain), los objetos de espera de fotogramas (como DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT) y la programación de comandos fueron transferidos por diseño al propio motor del juego.

Dado que el controlador no puede interceptar o congelar las listas de comandos del juego sin provocar bloqueos mutuos (deadlocks) o tirones graves (micro-stuttering), los modos de ultra baja latencia del panel de control son prácticamente inoperantes en títulos nativos de DirectX 12 y Vulkan.

2. Integración en el motor: NVIDIA Reflex y AMD Radeon Anti-Lag 2

Para erradicar la latencia de cola en motores modernos, las herramientas se trasladaron al bucle principal de simulación y renderizado. NVIDIA Reflex SDK y AMD Radeon Anti-Lag 2 SDK se integran directamente en el código fuente del juego:

CANALIZACIÓN TRADICIONAL (GPU saturada):
CPU: [ Sim 1 ][ Envío 1 ][ Sim 2 ][ Envío 2 ][ Sim 3 ][ Envío 3 ]
GPU:                     [------- Render GPU 1 -------][------- Render GPU 2 -------]
Cola:                    | Fotograma 2 espera en RAM   | Fotograma 3 espera en RAM
Latencia: Muy alta (la entrada se lee demasiado pronto y queda atrapada en la cola)

SINCRONIZACIÓN EN EL MOTOR (Reflex / Anti-Lag 2 activo):
CPU:          [ Sim 1 ][ Envío 1 ]         [ Sim 2 ][ Envío 2 ]         [ Sim 3 ]
GPU:                              [-- Render GPU 1 --]          [-- Render GPU 2 --]
Cola:                             | Cero fotogramas en cola     | Cero fotogramas en cola
Latencia: Mínima (la CPU espera a que la GPU quede libre antes de muestrear la entrada)

Mediante marcas de sincronización explícitas en el motor (SetLatencyMarker(SIMULATION_START) y SetLatencyMarker(RENDERSUBMIT_START)), el juego consulta directamente el estado de ejecución de la GPU.

Cuando detecta saturación en la GPU, la CPU entra deliberadamente en reposo (sleep) en lugar de generar fotogramas por adelantado. Retrasa la captura del ratón y el teclado hasta el último milisegundo antes de que la tarjeta gráfica esté lista para recibir nuevas instrucciones.

Este cambio de paradigma arquitectónico aporta dos ventajas decisivas:

1. Colapso de la cola de renderizado: La profundidad de la cola se reduce prácticamente a cero.
2. Entrada ultra fresca: La acción del usuario se procesa e inmediatamente se rasteriza en la GPU, reduciendo drásticamente la latencia sin necesidad de sacrificar calidad gráfica ni FPS medios.

Análisis de NVIDIA Reflex: "On" frente a "On + Boost"

La mayoría de los títulos con soporte para Reflex ofrecen dos modos de activación: On y On + Boost. Comprender cómo actúan a nivel de hardware evita malas configuraciones:

+-------------------------------------------------------------------------------+
|                        MODOS DE FUNCIONAMIENTO DE REFLEX                      |
+-------------------------------------------------------------------------------+
|  Reflex Off (Desactivado)                                                     |
|  - El motor no sincroniza; la cola de renderizado se llena con saturación.   |
|  - Máximo rendimiento bruto, pero latencia de entrada elevada y errática.     |
+-------------------------------------------------------------------------------+
|  Reflex On (Activado)                                                         |
|  - Alinea dinámicamente la simulación de la CPU con el renderizado en GPU.    |
|  - Elimina por completo la cola de espera cuando la GPU está saturada.        |
|  - Mantiene las funciones convencionales de ahorro de energía y frecuencias.  |
+-------------------------------------------------------------------------------+
|  Reflex On + Boost (Activado con mejora)                                      |
|  - Incorpora todas las ventajas de sincronización de "Reflex On".             |
|  - Anula el mecanismo de bajada de frecuencias dinámicas de la GPU (P-states).|
|  - Fija frecuencias máximas de reloj y VRAM incluso con cuello de CPU puntual.|
+-------------------------------------------------------------------------------+

Qué hace en realidad el modo Boost

• No es overclocking: Boost no eleva las frecuencias máximas de reloj por encima del límite de fábrica ni rompe los topes de consumo térmico (TDP).
• Evita la caída transitoria de frecuencias: En una partida intensa, el juego alterna rápidamente entre zonas abiertas (cuello de botella de GPU) y combates cerrados repletos de personajes (cuello de botella de CPU donde el uso de la GPU baja). Cuando el uso de la GPU desciende temporalmente, los controladores bajan las frecuencias de reloj a estados de menor energía (P-states) para ahorrar electricidad.
• Si de repente explota una granada de humo o se despliega una habilidad compleja, la tarjeta gráfica necesita varios ciclos para elevar de nuevo sus relojes al máximo, lo que produce microtirones y picos de latencia inesperados.
• Frecuencias siempre en guardia: Reflex Boost impide que la GPU baje de vueltas en esos momentos valle, garantizando que cualquier carga repentina se procese con el menor tiempo de renderizado posible.

Criterio de elección

• Ordenadores de sobremesa: Gracias a su capacidad de refrigeración, se recomienda mantener activado "On + Boost" en títulos competitivos.
• Portátiles gaming: Al compartir disipadores y tubos de calor entre la CPU y la GPU, fijar la GPU en frecuencias máximas puede saturar la refrigeración y provocar estrangulamiento térmico (thermal throttling) en la CPU, causando severas caídas de fotogramas. En portátiles suele ser más aconsejable utilizar el modo convencional "Reflex On".

Comparativa técnica de tecnologías de baja latencia

Interacción con G-SYNC, FreeSync y limitadores de fotogramas

En monitores con frecuencia de actualización variable (VRR), los SDK integrados proporcionan una salvaguarda automatizada crucial.

Es práctica habitual habilitar G-SYNC o FreeSync junto con V-Sync en el panel de control para erradicar por completo el desgarro de pantalla (tearing). Sin embargo, esto encierra un riesgo: si los fotogramas del juego superan el límite de refresco del monitor, el controlador se ve forzado a retener fotogramas para respetar el intervalo vertical, generando una severa presión en el búfer de pantalla que dispara la latencia.

Para neutralizar este problema:

1. Límite automático protector: Cuando detecta que G-SYNC y V-Sync están activos simultáneamente, NVIDIA Reflex limita de forma automática la tasa de fotogramas ligeramente por debajo de la frecuencia de refresco máxima del panel.
   • En monitores de 144Hz, Reflex limita a unos 138 FPS.
   • En monitores de 240Hz, limita a unos 225 FPS.
   • En monitores de 360Hz, limita a unos 338 FPS.
2. De este modo, la imagen permanece dentro de la ventana de funcionamiento de VRR, evitando el desgarro y desterrando las colas de espera asociadas al V-Sync convencional.

Árbol de decisiones y optimización práctica

Según la API y la compatibilidad del juego, aplique las siguientes pautas:

[ Comprobar compatibilidad en el juego ]
           |
           +-------------------------------------+
           |                                     |
           v                                     v
[ El juego incluye Reflex / Anti-Lag 2 ]  [ El juego carece de SDK integrado ]
           |                                     |
           |                                     |
           v                                     v
1. Activar la opción en el juego:      1. Comprobar la API gráfica:
   - NVIDIA: Reflex en "On"              - Si es DX9 / DX11:
     (o "On + Boost" en sobremesa)         Panel de NVIDIA -> Modo baja latencia: Ultra
   - AMD: Anti-Lag 2 en "Activado"         Software de AMD -> Anti-Lag: Activado
2. Desactivar opciones del controlador   - Si es DX12 / Vulkan:
   (evita conflictos entre el gancho       Los ajustes del controlador no tienen efecto
    del controlador y el motor)        2. Aplicar límite manual de fotogramas:
3. En monitores con VRR:                 - Usar el limitador interno del juego o RTSS
   - Activar G-SYNC / FreeSync           - Ajustar el límite entre 3 y 5 FPS por debajo
   - Activar V-Sync en el panel            del refresco del monitor
   - Reflex gestionará el margen         - O limitar a un valor que mantenga la GPU por
     de FPS automáticamente                debajo del 95% de uso

Cuando sea necesario determinar si la sensación de pesadez en el ratón proviene de la saturación de la cola de renderizado en GPU, de la presión del búfer de V-Sync o de la inestabilidad en el sondeo del periférico, cotejar las métricas con las guías de diagnóstico de hardware y visualización de 365Finds permite identificar el origen real de la latencia sin depender de pruebas a ciegas en el controlador.

Verificación de resultados y telemetría de latencia

Es posible comprobar de forma empírica si la cola de renderizado ha desaparecido mediante las estadísticas integradas en el juego:

1. Métricas clave de telemetría

• Game to Render Latency: Tiempo transcurrido desde que el motor recibe la orden del usuario hasta que la CPU concluye el envío de llamadas de dibujo para ese fotograma.
• Render Latency: Tiempo que tarda el hardware de la GPU en procesar y dibujar el fotograma por completo.
• PC Latency: Tiempo global que suma el muestreo, la simulación, la espera en la cola y la ejecución en GPU.

Interpretación de las cifras:

• Sistema no optimizado (cola saturada): $$\text{Render Latency} = 10\text{ ms}, \quad \text{PC Latency} = 38\text{ ms}$$ La brecha de $28\text{ ms}$ refleja que los fotogramas permanecen en cola casi tres ciclos completos antes de entrar a la GPU.
• Sistema optimizado (Reflex / Anti-Lag 2 activo): $$\text{Render Latency} = 10\text{ ms}, \quad \text{PC Latency} = 13\text{ ms}$$ La diferencia se reduce al coste inevitable de la simulación de la CPU ($2-3\text{ ms}$), certificando la eliminación total de la cola.

2. Errores habituales que conviene evitar

• No duplicar tecnologías: Si un juego ya cuenta con Reflex nativo, no active el modo de baja latencia "Ultra" en el panel de control. La concurrencia entre ambos sistemas provocará irregularidades en el ritmo de entrega de fotogramas (frame pacing).
• No desactivar Reflex para arañar 1 o 2 FPS: Desactivar Reflex puede arrojar una cifra ligeramente superior de FPS medios en pruebas de rendimiento, pero introduce una penalización masiva de 20 a 40 ms de retraso en cada acción.

Referencias

• Reflex SDK | NVIDIA Developer
• Introducing NVIDIA Reflex: Optimize and Measure Latency in Competitive Games | GeForce News | NVIDIA
• How To Reduce Lag - A Guide To Better System Latency | GeForce News | NVIDIA
• GitHub - GPUOpen-LibrariesAndSDKs/AntiLag2-SDK: The main repository for the AMD Radeon Anti-Lag 2 SDK. · GitHub
• Reduce latency with DXGI 1.3 swap chains - UWP applications | Microsoft Learn