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 tali test non vengono usate registrazioni di gioco, e le cifre finali non equivalgono agli «FPS in un gioco specifico». Il ciclo di misura completo è descritto nella metodologia.

La descrizione si riferisce al motore 0.8.0. Tra le versioni è cambiata l’esecuzione degli scenari GPU, quindi le vecchie misurazioni non possono essere considerate equivalenti alle nuove solo dopo il ricalcolo dei punteggi. Per verificare il driver o l’overclock usate una sola versione del motore.

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. Poi i thread vengono sincronizzati.

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 «leader» 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 rendering della scena con 9 216 istanze e 2 passaggi di post-elaborazione	L’elaborazione della geometria e l’invio del lavoro grafico
Shader	1 rendering della scena, 16 passaggi di post-elaborazione, parametro di complessità dello shader 24	Il carico su 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 possono essere letti come 8 000 FPS in un gioco né confrontati 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 di schede video diversi, senza un ramo separato per un vendor specifico.

La correttezza dell’esecuzione del carico viene verificata separatamente dalla velocità. In caso di errore orientatevi sul messaggio del programma e ripetete il test dopo aver eliminato la causa.

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 riduce la sua 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 valutare lo scenario si prende la media aritmetica del throughput dei suoi tre blocchi. La mediana e la media geometrica dei blocchi possono essere consultate 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 cambiare la 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.

La verifica archiviata della versione 0.5.2 con 1920×1080, 1280×768 e 800×600 è riportata nell’articolo sulla ripetibilità. Essa non sostituisce una nuova serie dopo la modifica degli scenari GPU.

Driver e confronto delle schede video

Geometry, Shader e Compute verificano percorsi di esecuzione diversi. Una scheda video può essere più veloce in uno scenario e più lenta in un altro. La versione del driver, le frequenze, i limiti di alimentazione e l’invio dei comandi possono cambiare il risultato. Un solo Compute diverso non basta per attribuire la differenza unicamente al driver. Confrontate più ripetizioni, la versione del motore e ogni scenario separatamente.

Ridurre la risoluzione del desktop non riduce la griglia di lavoro di Compute. Questo test usa un proprio shader di calcolo, non gli FPS di visualizzazione della finestra. Il peso di Compute nel GPU Score di base è del 10%; i dettagli sono riportati nella formula.

Verificato per l’implementazione descritta: 2026-10-02.