Cargas de CPU e GPU

PCBenchmarkX executa suas cargas sintéticas com volume fixo de trabalho em cada repetição, por isso elas podem ser comparadas entre sistemas diferentes. Nesses testes não são usadas gravações de jogos, e os números finais não equivalem a «FPS em um jogo específico». O ciclo completo de medição está descrito na metodologia.

Atualmente são aplicados o motor 0.5.2 e a carga phase4.6-dev-1. A versão precisa ser levada em conta: a mudança de cenário torna os resultados de releases diferentes diretamente incomparáveis.

CPU: simulação de objetos

No bloco de CPU são criados 65 536 objetos com coordenadas, velocidades e flags. A cada passo são recalculados o movimento, os ricochetes nas bordas e a visibilidade. A thread principal primeiro processa 8 192 objetos em sequência, depois passa a parte restante para as threads de trabalho e, em paralelo, faz a preparação. Em seguida, as threads são sincronizadas.

A quantidade de threads de trabalho é escolhida pela regra:

workers = clamp(physical_cores − 1, 1, 6)

Se o número de núcleos físicos for desconhecido, usa-se uma estimativa pelos processadores lógicos. Os núcleos para as threads não são fixados manualmente. Essa abordagem imita o modelo de «uma thread líder» com ajuda limitada, e não uma execução totalmente paralelizada em cada núcleo.

O estado e a ordem de percurso dos objetos são determinísticos. Antes de cada medição da seção de CPU, ele é redefinido e executa 512 quadros preparatórios fora da contagem, para não arrastar para a série o estado residual da execução anterior.

O determinismo da carga não significa tempo de execução igual: frequências, temperatura, agendador e processos em segundo plano continuam influenciando a medição.

Três cargas de GPU

A parte de GPU funciona via Direct3D 12. As texturas de trabalho internas têm tamanho fixo de 1920×1080, independentemente do tamanho da janela e da área de trabalho.

Carga	Trabalho computacional	O que ajuda a distinguir
Geometry	6 renderizações de cena com 9 216 instâncias e 2 passagens de pós-processamento	O processamento de geometria e a entrega de trabalho gráfico
Shader	1 renderização de cena, 16 passagens de pós-processamento, parâmetro de complexidade de shader 24	A carga de pixels e de texturas
Compute	Grade 1920×1080, grupos 8×8, cálculos inteiros com 96 iterações	A execução do shader de computação
Combined	Simulação de CPU e pipeline gráfico fixo	O trabalho conjunto de CPU, driver e GPU

São cenários separados com volume de trabalho diferente. Por exemplo, 8 000 quadros condicionais de Compute não podem ser lidos como 8 000 FPS em um jogo nem comparados diretamente com 800 quadros de Geometry. Para a unificação aplica-se a normalização por cenário, descrita no cálculo de pontos.

As cargas são escritas em um nível de recursos portável: shader model 5.0 e feature level 11_0 sem extensões de fornecedor. O mesmo código é executado em diferentes gerações e fabricantes de placas de vídeo, sem um ramo separado para um fornecedor específico.

Após as medições, o motor verifica a saída de cada carga de GPU: para Geometry, Shader, Compute, Combined e o teste de latência carregado está fixada uma assinatura de controle — a aparência esperada de um pequeno fragmento do resultado. O fragmento lido após a conclusão é comparado com o esperado; uma divergência significa que a carga foi executada incorretamente e torna a execução inutilizável. A verificação é feita após as medições válidas e não influencia os próprios números.

Não há testes separados de velocidade de disco e de largura de banda da RAM neste conjunto. A memória e o driver influenciam a execução das cargas, porém o benchmark não calcula avaliações separadas de SSD e RAM.

Repetição dos blocos

As cinco cargas de desempenho são executadas em três rodadas com permutação da ordem:

Rodada	Ordem
1	CPU → Geometry → Shader → Compute → Combined
2	Shader → Compute → Combined → CPU → Geometry
3	Combined → CPU → Geometry → Shader → Compute

A posição de cada carga na sequência muda de rodada para rodada. Isso reduz sua influência sobre a comparação. O aquecimento ainda pode alterar os resultados, por isso, para os blocos, são adicionalmente salvos a dispersão da velocidade de execução e sua variação do primeiro bloco para o último.

Para a avaliação do cenário toma-se a média aritmética do throughput de seus três blocos. A mediana e a média geométrica dos blocos podem ser vistas como diagnóstico adicional, mas o indicador final permanece nessa média.

Por que a baixa resolução não alivia o teste principal

As cargas de CPU, GPU e Combined são executadas fora do buffer de tela. Seu caminho de envio de comandos não aciona Present e não espera a limitação da fila de apresentação. As texturas internas permanecem 1920×1080, mesmo que a área de trabalho esteja alternada para 800×600.

A interface e o teste de latência funcionam por um caminho de saída separado. Por isso, a mudança de resolução da área de trabalho por si só não alivia a carga em si. Ainda assim, não se pode ler um resultado «absolutamente igual» em qualquer resolução: no trecho de saída participam o driver e o estado atual do sistema.

Uma verificação prática com 1920×1080, 1280×768 e 800×600 é apresentada no artigo sobre repetibilidade.

Verificado para a implementação descrita: 2026-09-20.