Frame pacing em jogos: controle do ritmo de apresentação e da latência de fila

Finalidade

Um jogo pode reportar uma taxa média de quadros satisfatória e, ainda assim, exibir movimento com engasgos. O resultado visível depende de quando as imagens concluídas chegam à tela e de por quanto tempo cada uma permanece visível. O frame pacing coordena essa entrega com a tela, em vez de tratar cada renderização concluída como uma ordem para apresentar imediatamente. Ele também limita o trabalho desnecessário acumulado em fila, que faz uma mudança de entrada esperar atrás de quadros mais antigos.

Como funciona

Em uma tela de taxa de atualização fixa, as oportunidades de apresentação ocorrem em intervalos discretos. O VK_PRESENT_MODE_FIFO_KHR do Vulkan enfileira as requisições de apresentação em ordem e é o modo cujo suporte é obrigatório. O VK_PRESENT_MODE_MAILBOX_KHR, quando disponível, substitui uma requisição pendente por outra mais recente antes da apresentação. Essa política de substituição não elimina o trabalho que já está enfileirado em outro ponto da GPU.

A quantidade de imagens da swapchain, os quadros em andamento (frames in flight) da aplicação e a fila de apresentação descrevem recursos relacionados, mas distintos. Um limite de submissões baseado em fences pode controlar o trabalho pendente. Um pacer da plataforma pode combinar timestamps de agendamento com esperas de sincronização; a biblioteca do Android trata explicitamente de apresentação antecipada e de acúmulo excessivo na fila (queue stuffing). Escolha a política com base nas capacidades reais da superfície e na carga de trabalho.

Exemplo prático

Suponha uma taxa de atualização fixa de 60 Hz e uma meta do jogo de 30 quadros por segundo. Cada atualização dura aproximadamente 1000 / 60 ≈ 16.67 ms. Exibir cada imagem do jogo durante duas atualizações produz um ritmo de cerca de 33.33 ms.

Se, em vez disso, a visibilidade alternar entre uma atualização e três atualizações, os intervalos ficam próximos de 16.67 ms e 50 ms. A taxa média ainda pode coincidir com a meta, mas o ritmo fica visivelmente irregular. Este é um cronograma ilustrativo, não uma medição nem uma garantia sobre um compositor de tela específico.

Fluxo de trabalho prático

Capture os timestamps de amostragem de entrada, de submissão na CPU, de conclusão na GPU e de apresentação efetiva, onde a plataforma os expuser. Mantenha explícitos os domínios de relógio; o retorno de uma chamada de submissão não prova que a imagem já foi exibida. Analise a distribuição dos intervalos e as imagens repetidas, em vez de se basear apenas em um contador de FPS.

Escolha um modo de apresentação suportado, defina um ritmo alcançável e limite o número de quadros pendentes. Compare a latência e os prazos perdidos enquanto varia esse limite. Teste um movimento contínuo de câmera, picos deliberados de carga e transições entre modos de atualização da tela. Preserve trabalho paralelo suficiente para usar a GPU de forma eficaz, sem acumular atraso de apresentação evitável.

Limites e verificação

Uma biblioteca de pacing não consegue concluir um quadro custoso antes de o hardware terminá-lo. Reduzir a meta pode melhorar a regularidade, mas o modo de tela escolhido precisa suportar o ritmo pretendido. Telas de taxa de atualização variável trazem oportunidades e limites de temporização diferentes; o exemplo de taxa fixa não deve ser aplicado sem adaptação.

A apresentação em modo mailbox pode descartar imagens pendentes mais antigas, mas renderizar imagens desnecessárias ainda consome recursos. Verifique o comportamento sustentado, o consumo de energia e a latência de entrada nos dispositivos-alvo. Registre o modo selecionado, a taxa de atualização e as configurações de pacing em cada captura, para que um resultado fluido possa ser reproduzido.

Fontes

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