Carichi CPU e GPU

PCBenchmarkX esegue i propri carichi sintetici con un volume di lavoro fisso a ogni ripetizione, quindi possono essere confrontati tra sistemi diversi. In questi test non vengono usate registrazioni di gioco, e le cifre finali non equivalgono ai «FPS in un gioco specifico». Il ciclo di misurazione completo è descritto nella metodologia.

Attualmente vengono applicati il motore 0.5.2 e il carico phase4.6-dev-1. La versione va tenuta presente: il cambio di scenario rende i risultati di release diverse direttamente incomparabili.

CPU: simulazione di oggetti

Nel blocco CPU vengono creati 65 536 oggetti con coordinate, velocità e flag. A ogni passo vengono ricalcolati movimento, rimbalzi dai bordi e visibilità. Il thread principale elabora prima 8 192 oggetti di seguito, poi passa la parte rimanente ai thread di lavoro e in parallelo esegue la preparazione. Successivamente i thread si sincronizzano.

Il numero di thread di lavoro viene scelto secondo la regola:

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

Se il numero di core fisici è sconosciuto, si prende una stima dai processori logici. I core per i thread non vengono fissati manualmente. Questo approccio imita il modello di «un thread principale» con aiuto limitato, e non una corsa totalmente parallelizzata su ogni core.

Lo stato e l’ordine di attraversamento degli oggetti sono deterministici. Prima di ogni misurazione della sezione CPU esso viene reimpostato ed esegue 512 frame preparatori fuori classifica, per non trascinare nella serie lo stato residuo della corsa precedente.

Il determinismo del carico non significa tempo di esecuzione identico: frequenze, temperatura, scheduler e processi in background continuano a influenzare la misurazione.

Tre carichi GPU

La parte GPU lavora tramite Direct3D 12. Le texture di lavoro interne hanno dimensione fissa 1920×1080, indipendentemente dalla dimensione della finestra e del desktop.

Carico	Lavoro di calcolo	Cosa aiuta a distinguere
Geometry	6 disegni della scena da 9 216 istanze e 2 passaggi di post-elaborazione	L’elaborazione della geometria e l’invio del lavoro grafico
Shader	1 disegno della scena, 16 passaggi di post-elaborazione, parametro di complessità dello shader 24	Il carico di pixel e texture
Compute	Griglia 1920×1080, gruppi 8×8, calcoli interi con 96 iterazioni	L’esecuzione dello shader di calcolo
Combined	Simulazione CPU e pipeline grafica fissa	Il lavoro congiunto di CPU, driver e GPU

Questi sono scenari separati con un volume di lavoro diverso. Ad esempio, 8 000 frame condizionali di Compute non si possono leggere come 8 000 FPS in un gioco né confrontare direttamente con 800 frame di Geometry. Per l’unione si applica la normalizzazione per scenario, descritta nel calcolo dei punteggi.

I carichi sono scritti su un livello di funzionalità portabile: shader model 5.0 e feature level 11_0 senza estensioni dei vendor. Lo stesso codice viene eseguito su generazioni e produttori diversi di schede video, senza una branca separata per un vendor specifico.

Dopo le misurazioni il motore verifica l’output di ogni carico GPU: per Geometry, Shader, Compute, Combined e il test di latenza caricato è fissata una firma di controllo — l’aspetto atteso di un piccolo frammento del risultato. Il frammento letto dopo il completamento viene confrontato con quello atteso; una mancata corrispondenza significa che il carico è stato eseguito in modo errato e rende la corsa inutilizzabile. La verifica viene eseguita dopo le misurazioni valide e non influisce sui numeri stessi.

In questo set non ci sono test separati della velocità del disco e della larghezza di banda della RAM. La memoria e il driver influenzano l’esecuzione dei carichi, tuttavia il benchmark non calcola valutazioni separate di SSD e RAM.

Ripetizione dei blocchi

I cinque carichi di prestazioni vengono eseguiti in tre round con permutazione dell’ordine:

Round	Ordine
1	CPU → Geometry → Shader → Compute → Combined
2	Shader → Compute → Combined → CPU → Geometry
3	Combined → CPU → Geometry → Shader → Compute

La posizione di ogni carico nella sequenza cambia da un round all’altro. Questo ne riduce l’influenza sul confronto. Il riscaldamento può comunque cambiare i risultati, quindi per i blocchi vengono inoltre salvati la dispersione della velocità di esecuzione e la sua variazione dal primo blocco all’ultimo.

Per la valutazione dello scenario si prende la media aritmetica del throughput dei suoi tre blocchi. La mediana e la media geometrica dei blocchi si possono vedere come diagnostica aggiuntiva, ma l’indicatore finale resta comunque su questa media.

Perché una bassa risoluzione non alleggerisce il test principale

I carichi CPU, GPU e Combined vengono eseguiti fuori dal buffer dello schermo. Il loro percorso di invio dei comandi non causa Present e non attende il limite della coda di presentazione. Le texture interne restano 1920×1080, anche se il desktop è commutato a 800×600.

L’interfaccia e il test di latenza lavorano tramite un percorso di output separato. Pertanto il cambio di risoluzione del desktop di per sé non alleggerisce il carico stesso. Tuttavia non si può comunque leggere un risultato «assolutamente identico» a qualsiasi risoluzione: nella parte di output partecipano il driver e lo stato attuale del sistema.

Una verifica pratica con 1920×1080, 1280×768 e 800×600 è riportata nell’articolo sulla ripetibilità.

Verificato per l’implementazione descritta: 2026-09-20.