Por que FPS alto ainda pode apresentar travadas

O jogo mostra mais de noventa FPS, mas para por um instante ao virar ou entrar em outra área. A média não deixou de funcionar: responde a uma pergunta ampla, quantos quadros foram produzidos no intervalo. Para saber se chegam em ritmo uniforme, é preciso observar os tempos.

Comece pelo tempo de quadro e depois decida o que medir. Um percentual de gargalo ou uma queda isolada no uso da GPU não diz qual peça substituir.

Um quadro longo pode se esconder em uma média boa

Com saída idealmente uniforme, o intervalo em milissegundos é aproximadamente 1.000 ÷ FPS. Assim, 60 FPS correspondem a 16,67 ms e 120 FPS a 8,33 ms. É conversão de tempo, não resultado de um computador.

Suponha 100 quadros: 99 levam 10 ms cada e um leva 100 ms. O total é 99 × 10 + 100 = 1.090 ms. Dividir quadros por duração dá cerca de 91,74 FPS. A média parece boa, mas ainda existe uma espera muito maior.

Illustrative guide and worked example in English

Figura: cálculo sintético e processo de conferência, não captura de benchmark de jogo.

A média aritmética do FPS instantâneo de cada quadro também difere de quadros totais divididos pelo tempo total. Janela de amostragem, inclusão de carregamentos e definição estatística alteram o número.

Outra medida intuitiva é quanto tempo os quadros lentos ocupam. Em 60 segundos hipotéticos com seis quadros de 100 ms, esses seis tomam 0,6 segundo, ou 1% do intervalo. Continua sendo cálculo artificial, mas preserva pausas raras que um percentil pode omitir.

Illustrative guide and worked example in English

Figura: 100 quadros sintéticos. O eixo horizontal é a ordem dos quadros, não tempo igualmente espaçado. O quadro 50 leva 100 ms; os outros 99 levam 10 ms cada.

Descubra que tipo de quadro foi registrado

A página oficial da NVIDIA FrameView lista medição de FPS, tempo de quadro e potência, com gravação de logs.[1] Ajuda a guardar dados do evento, mas a ferramenta sozinha não prova “é gargalo de CPU”.

Antes de comparar relatórios, confira quadros renderizados ou exibidos, geração de quadros, sincronização vertical e limite. Misturar gerados e renderizados-base pode aumentar o número sem melhorar proporcionalmente a resposta. Problemas na exibição também podem ficar fora do log de renderização; um gráfico estável não elimina toda travada visual.

“1% low” ajuda a observar desempenho baixo, mas programas podem calculá-lo de formas diferentes. Preserve ferramenta, versão, definição e duração. Não o trate como o quadro mais lento nem misture ferramentas em um ranking.

CapFrameX distingue percentis ordenados por quadro e duração.[3] “99% dos quadros atingem um limite” não equivale estritamente a “99% do tempo é fluido”: poucos quadros lentos podem ocupar muito tempo. Também distingue percentis e resumos da fração mais lenta. Se houver apenas “1% low” sem algoritmo, mantenha essa lacuna.

Quais campos ler em conjunto

Abra o CSV e confira os cabeçalhos. A documentação de console do PresentMon define os campos abaixo; a saída depende da versão e das opções.[2]

Campo Definição documentada O que ajuda a investigar
MsBetweenPresents Intervalo entre chamadas Present adjacentes Se o ritmo de envio se alongou subitamente
MsCPUBusy Trabalho de CPU antes do envio deste quadro Mudanças de trabalho da CPU perto do quadro longo
MsGPUBusy Tempo ativo de GPU para o quadro do processo Se o trabalho gráfico aumenta com a cena
DisplayLatency Tempo do início do quadro até exibi-lo Espera no caminho de exibição
DisplayedTime Tempo visível; pode ser NA se não exibido Se um quadro permanece tempo demais

São intervalos diferentes, e CPU e GPU podem trabalhar em paralelo. Não some colunas exigindo igualdade com o tempo total. MsGPUBusy também não é o percentual do Gerenciador de Tarefas. Leia as definições antes de comparar números.

Se o intervalo de envio cresce junto com o tempo ativo de GPU, vale investigar gráficos. GPU breve com espera longa pode envolver limite, fornecimento pela CPU ou escalonamento. Isso restringe a busca, não prova CPU insuficiente. A documentação também apresenta limitações por API e escalonamento de hardware; mantenha campos ausentes ou limitados como estão.[4]

Guarde evidências com um trajeto curto repetível

Escolha um trajeto repetível e fixe resolução, qualidade, movimento de câmera e limite. Salve os ajustes originais, capture o log e preserve o arquivo. Identifique versão, driver, cenário e configurações para comparações futuras.

Anote se o pico ocorre na primeira entrada, em giro brusco, ao iniciar programa de fundo ou em toda passagem pelo local. Observe juntas as métricas disponíveis de CPU, GPU, memória e armazenamento. Não preencha sensores não capturados com zero.

Repita inicialmente três vezes e guarde cada resultado. Se variarem muito, confira cena, temperaturas, cache e tarefas antes de ampliar os testes. Escolher apenas a melhor execução apaga a variação que precisa ser explicada.

Esta é uma ficha inicial. Sessenta segundos e três repetições são ilustrativos, não garantia de suficiência para todos os jogos.

Registro Exemplo
Trecho Partir do mesmo save e seguir a rota por 60 segundos
Partida fria Guardar separadamente a primeira entrada
Repetições Três passagens iguais, CSVs separados
Exclusões Decidir antes se menus e carregamentos contam
Variável Reduzir apenas sombras, manter o restante

Compare separadamente a partida fria e a cena já visitada. A travada inicial também merece registro. Para carga contínua, não misture primeira carga de um grupo com execuções aquecidas de outro.

PresentMon permite escolher processo por nome, duração e arquivo CSV.[2] Com interface ou terminal, confirme o processo para não misturar launcher e jogo. Não houve captura real de jogo aqui; as imagens ilustram métricas.

Altere uma condição por vez

Se suspeitar de carga gráfica, reduza um peso de renderização definido e repita. Para interferência em segundo plano, feche um programa conhecido e teste novamente. Não altere driver, qualidade, limite e reinicialização juntos, pois a causa da melhora ficará incerta.

Se baixar a qualidade eleva o FPS médio, mas o pico continua no mesmo ponto, a carga média e a travada podem ser problemas diferentes. Travar na primeira passagem e melhorar depois pode envolver recursos ou cache, mas o padrão sozinho não identifica a causa. Uso baixo de GPU também pode refletir limite, espera pela CPU ou outras restrições, não falta direta de capacidade gráfica.

Guarde uma conclusão com condições: “As três passagens tiveram pico ao entrar na área, mesmo reduzindo sombras”, em vez de “o PC tem 30% de gargalo”. O teste seguinte poderá conferir o ponto e a diferença das sombras sem recomeçar nas suposições.

Referências

  1. NVIDIA FrameView. Recursos de FPS, tempo e logs; não implica teste realizado, campos de potência iguais entre GPUs ou software instalado.

  2. PresentMon Console Application. Snapshot de main lido em 2026-09-27. Campos CSV, processo e duração mudam por versão; não implica captura local.

  3. CapFrameX: Explanation of different performance metrics. Taxxor, 2020-05-31. Percentis e x% low. Usado para conceitos, não como captura atual de uma interface antiga.

  4. PresentMon: documentação e limitações. Conferido em 2026-09-27. API e escalonamento afetam a medição; registre o ambiente, sem concluir diretamente o gargalo.


Copyright © 2024 Bottleneck-calculator.net