Medição de latência e PresentMon

Nesta página

PCBenchmarkX mede separadamente a latência interna de processamento e a latência de apresentação do frame. Estas métricas de software não descrevem todo o caminho desde o clique do rato até ao acendimento do pixel no ecrã. O ciclo de medição completo 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 o permitir, cria um temporizador de espera de alta precisão; caso contrário, usa um temporizador de espera normal. A espera pelo evento dispensa a sondagem contínua, que ocuparia o kernel. A resolução global do temporizador do sistema não é alterada.

Para cada sinal são registados o prazo planeado, o despertar do gerador, o sinal efetivo, o despertar do recetor, a simulação, o envio de comandos, os timestamps da GPU e os eventos de apresentação. Um identificador comum de frame liga todas as etapas.

Prazo planeado → despertar do gerador → sinal
                                            ↓
                               despertar do recetor
                                            ↓
                                CPU → comandos → GPU
                                            ↓
                            Present → evento de apresentação

Nestes registos veem-se separadamente tanto o atraso do temporizador como a latência do despertar do recetor. O início da Core Latency é o sinal efetivo, por isso o passo do prazo planeado até ao sinal não é contabilizado nesta métrica.

Desdobramento por etapas do caminho de latência

O resultado contém um desdobramento por etapas do caminho medido latency_path — separadamente para Baseline e Loaded. As etapas são contadas a partir do sinal efetivo:

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

Cada etapa é apresentada 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 de uma etapa estiver ausente ou não for fiável, a sua distribuição fica vazia — não há valores substitutos. O atraso do temporizador (a divergência entre o prazo planeado e o sinal efetivo) é registado como um diagnóstico separado antes do sinal e não entra nos valores totais do caminho.

QPC e timestamps próprios da GPU

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

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

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

O par de calibração GPU/QPC permite expressar a conclusão do trabalho da GPU na mesma escala temporal 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 desta estimativa depende em grande medida de quão exatamente estão correlacionados os relógios da CPU e da GPU. Ainda assim, não cobre o caminho USB do rato, o tempo de varrimento da matriz nem a resposta do pixel. A Microsoft descreve separadamente os detalhes das marcas QPC de alta precisão.

Baseline e Loaded

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

A calibração altera a complexidade dentro do shader no intervalo 1-4096. O número de passagens mantém-se fixo: quatro pós-passagens. Primeiro é escolhido um intervalo em torno do tempo alvo, depois este é refinado e a configuração escolhida é verificada. Para ocupar o mesmo tempo numa placa gráfica rápida, é necessário trabalho mais complexo.

Em Performance o volume de trabalho é fixo. Em Loaded Latency a carga é calibrada para que o tempo de trabalho da GPU seja semelhante em placas gráficas diferentes. As marcas temporais obtidas não são normalizadas após a medição.

A apresentação de frames do teste de latência passa por um caminho de apresentação separado: janela sem moldura em modo flip-discard, latência máxima de frame (maximum frame latency) 1, objeto DXGI de espera e tearing, se o sistema o suportar. Este caminho está separado da carga de desempenho fixa, que é executada fora do buffer de ecrã e não provoca 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 pelos seus autores. O Procmon / Process Monitor não é aplicado neste pipeline de medição.

O PCBenchmarkX inicia a sua própria sessão de recolha, seleciona os eventos do seu processo e associa os frames aos sinais de software. Para isso não é necessária uma serviço separado nem o arranque manual de um PresentMon separado.

São guardados intervalos adicionais:

desde o sinal até Present;
desde Present até ScreenTime;
desde o sinal até ScreenTime.

ScreenTime é um evento de software de apresentação do frame; não é usado um fotodíodo para medir a luz do ecrã. As métricas de apresentação não entram no PC Score; o que entra nele está descrito no cálculo das pontuações. O arranque de uma sessão ETW pode exigir a execução como administrador ou a pertença ao grupo «Utilizadores de Registo de Desempenho». Se não for possível iniciar a sessão, o bloco deste diagnóstico não existirá, e a falha é registada explicitamente no resultado. A ausência de dados não é igual a latência zero.

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

O que foi desenvolvido no PCBenchmarkX

No PCBenchmarkX foram desenvolvidos o gerador de sinais, a associação das etapas do frame, a simulação na CPU, as cargas D3D12, a calibração do Loaded, a ordem dos blocos repetidos, a recolha de medições, o tratamento estatístico e o modelo de pontuações. O QPC e o D3D12 são fornecidos pelo Windows. Para a recolha de eventos gráficos através de 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.