Medição de latência e PresentMon

Nesta página

PCBenchmarkX mede separadamente a latência interna de processamento e a latência de saída do quadro. Essas métricas de software não descrevem todo o caminho desde o clique do mouse até o acendimento do pixel na tela. O ciclo completo de medição está descrito na metodologia.

Estímulo de software próprio

Um fluxo constante gera sinais com intervalos determinísticos de 8-12 ms. Se o Windows permitir, ele cria um temporizador de espera de alta precisão; caso contrário, usa um temporizador de espera comum. A espera pelo evento dispensa a sondagem contínua, que ocuparia o núcleo. A resolução global do temporizador do sistema não é alterada.

Para cada sinal são registrados o prazo planejado, o despertar do gerador, o sinal real, o despertar do receptor, a simulação, o envio de comandos, os timestamps de GPU e os eventos de apresentação. Um identificador comum de quadro vincula todas as etapas.

Prazo planejado → despertar do gerador → sinal
                                            ↓
                               despertar do receptor
                                            ↓
                                CPU → comandos → GPU
                                            ↓
                            Present → evento de saída

Nessas trilhas são visíveis separadamente tanto o atraso do temporizador quanto a latência de despertar do receptor. O início do Core Latency é o sinal real, portanto o passo do prazo planejado até o sinal não é contado nessa métrica.

Detalhamento por estágio do caminho de latência

O resultado contém um detalhamento por estágio do caminho medido latency_path — separadamente para Baseline e Loaded. Os estágios são contados a partir do sinal real:

Estágio	O que mede
`signal_to_consumer_wake`	do sinal até o despertar do receptor
`cpu_processing`	o processamento de CPU: simulação e preparação dos dados do quadro
`cpu_end_to_submit_start`	a pausa do fim do trabalho de CPU até o início da preparação do envio
`workload_submit_cpu_span`	a preparação e a gravação dos comandos da API gráfica
`submit_start_to_gpu_begin`	do início da preparação até o início do trabalho de GPU; não é a latência pura da fila
`gpu_execution`	a própria execução do trabalho de GPU, em ciclos de GPU
presentation spans	a apresentação: o invólucro `Present` e os intervalos do sinal e do fim do trabalho de GPU até `ScreenTime`

Cada estágio é fornecido como uma distribuição com estatísticas e percentis. Os segmentos são calculados para cada par de marcas separadamente, e não pela subtração de duas medianas. Se a marca final do estágio estiver ausente ou não for confiável, sua distribuição permanece vazia — não há valores substitutos. O atraso do temporizador (a divergência entre o prazo planejado e o sinal real) é registrado como um diagnóstico separado antes do sinal e não entra nos valores totais do caminho.

QPC e timestamps de GPU próprios

O tempo de CPU é registrado via QueryPerformanceCounter. Para a GPU, o motor posiciona duas timestamp query em torno do trabalho medido, obtém a frequência da fila via GetTimestampFrequency e converte a diferença de ticks em milissegundos:

GPU work, ms = (GPU_end − GPU_begin) × 1000 / GPU_frequency

Conforme a documentação da Microsoft sobre D3D12 timing, timestamp query reflete a passagem do trabalho até o fim do pipeline, e os contadores de GPU e CPU são vinculados via GetClockCalibration.

O par de calibração GPU/QPC permite expressar a conclusão do trabalho de GPU na mesma escala de tempo que o sinal:

GPU_completion_QPC = calibration_QPC +
  (GPU_end − calibration_GPU) × QPC_frequency / GPU_frequency

Core Latency, ms =
  (GPU_completion_QPC − signal_QPC) × 1000 / QPC_frequency

A precisão dessa estimativa depende em grande parte de quão exatamente os relógios de CPU e GPU estão correlacionados. Ela ainda não cobre o caminho USB do mouse, o tempo de varredura da matriz ou a resposta do pixel. A Microsoft descreve separadamente as nuances das marcas QPC de alta precisão.

Baseline e Loaded

O Baseline mede a latência na configuração mínima dessa carga. O Loaded trabalha com uma carga de GPU calibrada em 8,333333 ms, ou seja, um orçamento computacional de aproximadamente 120 Hz. O monitor físico pode ter outra frequência.

A calibração altera a complexidade dentro do shader na faixa de 1-4096. O número de passagens permanece fixo: quatro pós-passagens. Primeiro é selecionada uma faixa em torno do tempo alvo, depois ela é refinada e a configuração escolhida é verificada. Para ocupar o mesmo tempo em uma placa de vídeo rápida, é necessário um trabalho mais complexo.

Em Performance o volume de trabalho é fixo. Em Loaded Latency a carga é calibrada para que o tempo de trabalho de GPU seja próximo em diferentes placas de vídeo. As marcas temporais obtidas após a medição não são normalizadas.

A saída de quadros do teste de latência ocorre por um caminho de apresentação separado: janela sem bordas no modo flip-discard, latência máxima de quadro (maximum frame latency) 1, objeto DXGI de espera e tearing, se o sistema o suportar. Esse caminho é separado da carga fixa de desempenho, que é executada fora do buffer de tela e não causa Present.

O papel do PresentMon

Para os eventos de apresentação é usada a biblioteca PresentMon 2.5.1. É um projeto ETW de análise de eventos gráficos no Windows, descrito por seus autores. O Procmon / Process Monitor não é aplicado nesse pipeline de medição.

O PCBenchmarkX inicia sua própria sessão de coleta, seleciona os eventos de seu processo e vincula os quadros aos sinais de software. Para isso não é necessário um serviço separado nem a execução manual de um PresentMon separado.

Intervalos adicionais são armazenados:

do sinal até Present;
de Present até ScreenTime;
do sinal até ScreenTime.

ScreenTime é um evento de software de apresentação do quadro; o fotodiodo para medir a luz da tela não é usado. As métricas de apresentação não entram no PC Score; o que entra nele está descrito no cálculo de pontos. Iniciar a sessão ETW pode exigir execução como administrador ou participação no grupo “Usuários do Log de Desempenho”. Se a sessão não puder ser iniciada, o bloco desse diagnóstico não existirá, e a falha é registrada explicitamente no resultado. A ausência de dados não é igual a latência zero.

O tempo de GPU do PresentMon também é armazenado separadamente do tempo próprio de D3D12. Os desenvolvedores do PresentMon observam limitações de precisão das métricas de GPU com HAGS. Por isso o motor não substitui os timestamps de GPU próprios pela estimativa do ETW.

O que foi desenvolvido no PCBenchmarkX

No PCBenchmarkX foram desenvolvidos o gerador de sinais, a correlação das etapas do quadro, a simulação de CPU, as cargas D3D12, a calibração do Loaded, a ordem dos blocos repetidos, a coleta de medições, o processamento estatístico e o modelo de pontos. O QPC e o D3D12 são fornecidos pelo Windows. Para a coleta de eventos gráficos via ETW é usado o projeto aberto PresentMon.

As informações técnicas e as fontes externas foram verificadas em 2026-09-20 para o motor 0.5.2.