Frame pacing en videojuegos: controlar la cadencia de presentación y la latencia de la cola

Finalidad

Un juego puede indicar una tasa media de fotogramas satisfactoria y aun así mostrar el movimiento con tirones. El resultado visible depende de cuándo llegan a la pantalla las imágenes terminadas y de cuánto tiempo permanece visible cada una. El frame pacing (ritmo de fotogramas) coordina esa entrega con la pantalla, en lugar de tratar cada render completado como una orden de presentarlo de inmediato. Además, limita el trabajo innecesario en cola que obliga a un cambio de entrada a esperar detrás de fotogramas más antiguos.

Cómo funciona

En una pantalla de frecuencia de refresco fija, las oportunidades de presentación se producen a intervalos discretos. El modo VK_PRESENT_MODE_FIFO_KHR de Vulkan pone en cola las solicitudes de presentación en orden y es el modo cuyo soporte es obligatorio. VK_PRESENT_MODE_MAILBOX_KHR, cuando está disponible, sustituye una solicitud pendiente por otra más reciente antes de presentarla. Esa política de sustitución no elimina el trabajo que ya está en cola en otras partes de la GPU.

El número de imágenes de la swapchain, los fotogramas de la aplicación en vuelo y la cola de presentación describen recursos relacionados pero distintos. Un límite de envíos basado en fences puede controlar el trabajo pendiente. Un pacer de la plataforma puede combinar marcas de tiempo de planificación con esperas de sincronización; la biblioteca de Android aborda de forma explícita la presentación anticipada y el llenado excesivo de la cola (queue stuffing). Elige la política según las capacidades reales de la superficie y la carga de trabajo.

Ejemplo práctico

Supón una frecuencia de pantalla fija de 60 Hz y un objetivo de juego de 30 fotogramas por segundo. Cada refresco dura aproximadamente 1000 / 60 ≈ 16.67 ms. Si cada imagen del juego se muestra durante dos refrescos, la cadencia resulta de unos 33.33 ms.

Si en cambio la visibilidad alterna entre un refresco y tres, los intervalos son cercanos a 16.67 ms y 50 ms. La tasa media puede seguir coincidiendo con el objetivo, pero la cadencia es visiblemente irregular. Es una planificación ilustrativa, no una medición ni una garantía sobre un compositor de pantalla concreto.

Flujo de trabajo práctico

Registra las marcas de tiempo del muestreo de entrada, del envío desde la CPU, de la finalización en la GPU y de la presentación real, allí donde la plataforma las exponga. Mantén explícitos los dominios de reloj; que la llamada de envío haya retornado no demuestra que la imagen ya se haya mostrado. Examina la distribución de los intervalos y las imágenes repetidas, en lugar de basarte solo en un contador de FPS.

Elige un modo de presentación compatible, fija una cadencia alcanzable y limita los fotogramas pendientes. Compara la latencia y los plazos incumplidos mientras varías ese límite. Prueba un paneo de cámara constante, picos de carga deliberados y transiciones entre modos de refresco de la pantalla. Conserva suficiente trabajo en paralelo para aprovechar bien la GPU sin acumular un retraso de presentación evitable.

Límites y verificación

Una biblioteca de pacing no puede terminar un fotograma costoso antes de que el hardware lo complete. Reducir el objetivo puede mejorar la regularidad, pero el modo de pantalla elegido debe admitir la cadencia prevista. Las pantallas de refresco variable ofrecen oportunidades y límites de temporización distintos; el ejemplo de refresco fijo no debe aplicarse sin cambios.

La presentación en modo mailbox puede descartar imágenes pendientes más antiguas, pero renderizar imágenes innecesarias sigue consumiendo recursos. Verifica el comportamiento sostenido, el consumo de energía y la latencia de entrada en los dispositivos de destino. Registra con cada captura el modo seleccionado, la frecuencia de refresco y los ajustes de pacing, de modo que un resultado fluido pueda reproducirse.

Fuentes

• Android Frame Pacing library — Google, Android Developers
• VkPresentModeKHR — Khronos Group, Vulkan Documentation Project