Como ler o benchmark

O que ele mede

Tempos de quadro do jogo que você está realmente jogando, lidos da própria pilha gráfica em vez de um overlay enganchado no jogo. Inicie a captura, jogue normalmente, pare.

Jogar o seu próprio jogo faz diferença. Uma cena sintética diz como a máquina lida com aquela cena; ela não consegue dizer se o seu jogo engasga no único lugar em que ele sempre engasga.

Os números

Leia os lows, não a média. Ir de 200 para 210 de média não muda nada que você consiga sentir. Ir de 90 para 140 no 1% low muda tudo.

Comparar duas execuções com honestidade

• Mesmo jogo, mesmo mapa, mesmas configurações, mesma duração.
• Mude uma coisa entre as execuções. Mude três e a comparação não diz nada sobre qual delas importou.
• Jogue do mesmo jeito. Uma execução olhando para uma parede e uma execução no meio do tiroteio não são comparáveis.

O que fica de fora

Os quadros que o jogo desenha quando não está em primeiro plano não são contados: os segundos entre iniciar a captura e passar para o jogo, os segundos depois de voltar para pará-la, qualquer alt-tab no meio e o primeiro segundo depois que o jogo volta ao primeiro plano. Um jogo em segundo plano costuma desenhar uma fração do seu ritmo normal, e só esses quadros já podem definir o 1% low. O resultado diz quantos segundos ficaram de fora, e uma captura salva por um w0a mais antigo, que ainda os contava, não é julgada contra uma mais recente.

Por que os números mudam entre execuções

Eles sempre mudam. Temperaturas, carga em segundo plano, por onde você andou, o que os outros jogadores fizeram. Alguns por cento entre duas execuções é normal e não é prova de nada. Se uma mudança é real, ela aparece repetidas vezes e aparece nos lows.

Depois de uma atualização do driver ou do jogo

Um par feito dos dois lados de uma atualização do jogo não é julgado: a página mostra as duas versões e deixa a diferença sem cor, como já faz com uma troca de driver. Um patch muda o que o próprio jogo faz, então nenhuma diferença através de uma atualização pode ser atribuída a uma configuração. O w0a lê a versão dos próprios arquivos do Counter-Strike 2; em outros jogos só o driver é comparado.

A primeira partida depois de uma atualização do driver ou do jogo pode compilar shaders que o cache já não tem. Quando a primeira execução após a atualização mais recente saiu pior que a seguinte nas mesmas versões, por mais que o ruído próprio das duas execuções, uma nota abaixo dos resultados diz isso. Se a compilação de shaders foi a causa não é medido; a nota só diz que as duas coisas se encaixam. Se as duas execuções não diferem, não há nota. Então, depois de uma atualização, jogue uma partida antes de medir e compare as configurações a partir da segunda execução.

Tirar a dúvida com uma série A/B

Uma execução de cada lado não consegue separar uma mudança pequena dessa variação. Uma série A/B repete a comparação até conseguir. Você decide o que são A e B (por exemplo A: motores desligados, B: ligados); o w0a não muda nenhuma configuração sozinho.

• Primeiro o piloto. Clique em Iniciar piloto e meça a mesma cena dez vezes sem mudar nada. O piloto mede quanto o seu 1% low varia sozinho de uma execução para outra e, a partir disso, a menor diferença que uma série consegue ver. Ele vale para o mesmo jogo no mesmo hardware.
• Depois a série. Clique em Iniciar série A/B. Antes de cada captura a página diz qual lado medir, na ordem A B B A, repetida. Mude para essa configuração, jogue a mesma cena e pare a captura. Cada B é comparado com o A medido ao lado dele, então o aquecimento lento da máquina ao longo da noite se anula.
• Cada execução é a mesma cena e dura pelo menos 100 segundos. Apague a primeira execução depois de abrir o jogo: os caches ainda estão aquecendo.
• O veredito sai só do 1% low, quando há pelo menos seis pares utilizáveis (oito é melhor); as outras linhas são informativas. Três respostas precisam concordar: um teste de postos com sinal, um intervalo de 95% da mediana da diferença que deixe o zero de fora e uma diferença pelo menos do tamanho da menor que a série consegue ver. Sem piloto, ou sem dez execuções A na série para fazer o papel dele, a diferença é mostrada mas não é decidida.
• "Dentro do ruído" também é um resultado: a mudança não mexeu nos lows mais do que eles se mexem sozinhos.

Um par que o cartão de comparação não julgaria sozinho (uma execução curta, eventos perdidos, um motor mudando de estado, outro hardware) não é contado, e a série diz quantos ficaram de fora. Clique em Encerrar série quando terminar; o resultado fica na página.

Quanto tempo o jogo esperou por um processador

Abaixo da lista de intervalos longos entre quadros, um cartão lê por uma janela curta os próprios registros do agendador do kernel, depois que o jogo já está apresentando quadros há algum tempo: quanto as threads do jogo esperaram entre ficar prontas para rodar e receber um processador, e quais outros programas ocuparam o processador nesse meio-tempo. Precisa de direitos de administrador, e uma janela em que o kernel perdeu eventos não mostra número nenhum em vez de um errado. Com duas execuções selecionadas, diz se a espera se moveu mais do que a própria dispersão das janelas.

O mesmo cartão mostra o processador em que a thread mais ocupada do jogo (tomada como a thread principal) mais rodou e o tempo de chamadas de procedimento adiadas (DPC) medido onde ela rodou, ao lado do processador médio. Uma série acrescenta uma linha: se, nas execuções de uma mesma configuração (o piloto ou o lado A), esse tempo de DPC e os engasgos subiram e desceram juntos. Descreve só coincidência no tempo; o que causa o quê não é medido.

Execuções salvas alimentam a análise de engasgos

As execuções que você salva servem de evidência para a análise de engasgos: quadros medidos claramente mais lentos que os quadros ao redor aparecem lá como um achado próprio, ao lado das causas possíveis. Uma execução salva do jogo que engasga é a evidência mais direta que você pode entregar a ela.

Relacionados

• O que a análise de engasgos procura