Loading...
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.
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.

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.

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.
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.
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]
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.
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.
NVIDIA FrameView. Recursos de FPS, tempo e logs; não implica teste realizado, campos de potência iguais entre GPUs ou software instalado.
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.
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.
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.