Benchmark GPU: come leggere FPS medi, 1% low e frametime

Media FPS, 1% low e frametime: come leggerli

Media FPS: utile, ma “cieca” sulla qualità

La media FPS indica quante immagini al secondo vengono prodotte, in media, durante il test. È un dato utile per farsi un’idea del livello generale della prestazione, ma da solo può nascondere comportamenti molto diversi: due run con la stessa media possono dare una “sensazione” opposta se una è regolare e l’altra alterna frame veloci e frame lenti.

La media va letta come primo orientamento, non come giudizio finale. Se due test hanno FPS medi simili, guarda subito anche il 1% low e il frametime: spesso la differenza vera è nei cali e nella regolarità dei frame.

1% low: come leggere la “coda” peggiore

Il 1% low prova a descrivere i frame più lenti, cioè la parte “difficile” del test. È molto utile per capire quanto uno scenario sia robusto, ma va letto con una precauzione importante: non esiste un’unica definizione universale, perché dipende dal tool/metodologia. Percentili, medie della porzione peggiore e finestre temporali diverse possono produrre letture non equivalenti.

Per questo il 1% low è utile soprattutto quando i dati arrivano dallo stesso tool e dallo stesso scenario di test. Se cambi fonte, metodo o scena, il numero resta un indizio interessante, ma non basta da solo per dire che una scheda video è più fluida dell’altra.

Frametime: il termometro della fluidità percepita

Il frametime è il tempo tra un frame e il successivo, di solito espresso in millisecondi. Spesso è il dato che spiega perché, “a parità di FPS”, un gioco possa sembrare più o meno fluido: la regolarità della consegna dei frame conta quanto il livello medio.

Il rapporto di base è semplice: frametime (ms) ≈ 1000 / FPS. La conversione funziona bene per capire l’ordine di grandezza, ma va usata con cautela su medie e percentili: un grafico irregolare può raccontare molto più di un singolo valore convertito.

Nella lettura pratica, quindi, non fermarti a un singolo valore. Cerca soprattutto assenza di picchi ricorrenti e una curva “pulita”, perché sono questi elementi a raccontare meglio la continuità della fluidità percepita.

Un benchmark è un “test di scenario”, non una verità assoluta

Un risultato ha senso solo dentro le condizioni in cui è stato raccolto: scena, preset, API, patch del gioco, driver, limiti di frame e carico in background. Prima di usare quel numero per confrontare due schede, chiediti se lo scenario del test assomiglia davvero al tuo uso.

Se usi i benchmark per trasformare i numeri in una decisione d’acquisto, separa la lettura tecnica dalla scelta finale: prima definisci i criteri di scelta GPU, poi valuta la miglior GPU qualità/prezzo solo tra schede confrontate in scenari coerenti.

Quando un benchmark GPU è davvero confrontabile

La regola del confronto pulito: tutto uguale tranne una cosa

Un confronto è credibile quando cambia una sola variabile alla volta. Se vuoi valutare due GPU, devono restare uguali risoluzione, preset, API, versione del gioco, driver e scena usata nel test.

• Risoluzione e modalità (nativa vs upscaling, finestra vs fullscreen)
• Preset grafico e singole opzioni “pesanti” (ombre, distanza visiva, RT)
• API (es. DirectX 11/12, Vulkan) e modalità di rendering
• Versione del gioco (patch/build) e driver GPU
• Frame cap / V-Sync / VRR e impostazioni del pannello driver
• Scenario del test (stessa scena, stesso percorso, stessa durata)

Se anche solo uno di questi elementi cambia, non stai più confrontando “GPU vs GPU”: stai confrontando test diversi. In quel caso, la lettura corretta diventa “come cambia lo scenario”, non “quale scheda è migliore”.

Non mischiare prove diverse: raster, RT e upscaling non “sommano”

Per evitare letture sbagliate, raster, ray tracing e upscaling vanno trattati come scenari separati. Il raster rappresenta la baseline della GPU nel rendering tradizionale. Il ray tracing (RT) introduce un carico e un comportamento diversi: non è solo “più pesante”, perché cambia anche la sensibilità a preset e scene. L’ upscaling (DLSS/FSR/XeSS), invece, è un sistema composto da render scale, ricostruzione, sharpening e, dove previsto, frame generation, ha senso confrontarlo solo dopo aver verificato le impostazioni DLSS FSR XeSS, perché modalità, qualità e frame generation cambiano lo scenario.

Nel confronto reale conviene tenerli separati: raster, ray tracing e upscaling non misurano lo stesso carico. Un risultato buono in raster non descrive automaticamente il comportamento con RT attivo o con frame generation.

Come leggere media, minimi e picchi di frametime

Quando hai più metriche, leggile insieme. La media descrive il livello generale, il 1% low aiuta a capire la robustezza nei momenti difficili e il frametime mostra la qualità della consegna dei frame, quindi regolarità e picchi.

Un risultato solido di solito mostra coerenza tra media, 1% low e frametime: FPS medi buoni, minimi non troppo distanti e pochi picchi evidenti. Se invece la media resta alta ma i minimi crollano, controlla prima un possibile bottleneck CPU/GPU, streaming asset, compilazione shader, I/O o processi in background.

Per esempio, 90 FPS medi con picchi frequenti sopra i 30-40 ms possono risultare meno fluidi di 75 FPS medi con frametime più stabile. In quel caso la media è più alta, ma l’esperienza percepita può essere peggiore.

Un dettaglio che si vede spesso in pratica: se un test include una fase iniziale “turbolenta” e poi si stabilizza, è un segnale che parte del run sta misurando preparazione dello scenario oltre alla resa della GPU. In quel caso, confronta solo run che gestiscono quella fase nello stesso modo.

Consumi, temperature e rumore durante il test

Se un benchmark include dati di potenza, temperature o rumorosità, usali per capire quanto margine richiede la scheda nel sistema reale. A parità di scenario, consumi più alti o temperature più spinte possono richiedere più attenzione ad airflow del case, curva ventole e gestione termica.

Anche qui la comparabilità conta: confronti più sensati richiedono stesso profilo/limite di potenza e condizioni ambientali comparabili. Se l’obiettivo è capire letture dei sensori e range termici, il controllo corretto riguarda le temperature GPU, inclusi hotspot e VRAM.

Parametri da dichiarare nei test della scheda video

Checklist rapida: prima di fidarti di un confronto

Prima di prendere per buono un confronto, controlla se i risultati descrivono davvero lo stesso scenario. Anche una differenza apparentemente piccola, come API o modalità di upscaling, può cambiare il senso del benchmark.

• Il test dichiara chiaramente risoluzione, preset e opzioni chiave?
• Sono indicate API e versioni (gioco/driver) o almeno il fatto che siano identiche tra prove?
• È specificato se c’è upscaling e in quale modalità? (se sì, è uno scenario diverso dal nativo)
• Sono noti frame cap/V-Sync e condizioni del display?
• Lo scenario è replicabile (stessa scena/percorso) o almeno descritto in modo coerente?
• Le metriche (1% low/frametime) sono calcolate con lo stesso metodo tra i risultati che confronti?
• Ci sono indizi di interferenze (overlay pesanti, registrazione video, processi in background, caching/shader compilation in corso)?

Cosa dichiarare sempre in un benchmark (checklist “minima”)

Un benchmark utile deve permettere a chi legge di ricostruire le condizioni della prova. Senza questi dati, anche un grafico ben fatto resta difficile da interpretare o replicare.

• Hardware: CPU, RAM, storage (almeno tipologia), GPU e impostazioni “di profilo” rilevanti (default/OC/undervolt/power limit). Se il profilo non è “default”, dichiara esattamente cosa è stato cambiato, quando la modifica riguarda consumi o frequenze, i riferimenti corretti per metodo e test di stabilità sono undervolt GPU e overclock GPU.
• Software: OS, API, versione gioco, versione driver.
• Display e output: risoluzione, modalità schermo, frame cap/V-Sync/VRR.
• Grafica: preset e opzioni che cambiano il carico (RT on/off, texture, distanza visiva). Se texture, risoluzione o streaming asset influenzano minimi e frametime, dichiara anche il taglio di VRAM 8/12/16 GB.
• Upscaling: tecnologia e modalità, render scale implicita/esplicita, eventuale frame generation.
• Metodologia: scena/percorso, durata, warm-up/caching gestiti, ripetibilità (più run) e come vengono riassunti i risultati.
• Metriche: quali (media, 1% low, frametime) e con quale tool/definizione.

Template tabellare da riempire (per rendere confrontabili i risultati)

Criteri di stop (quando NON confrontare)

Quando mancano dati fondamentali, il risultato può servire solo come indicazione generale. Non è abbastanza solido per dire che una GPU sia davvero più veloce, più stabile o più fluida di un’altra.

• Mancano risoluzione o preset: puoi leggere solo l’ordine di grandezza, non fare confronti “A vs B”.
• Non è dichiarata l’ API: i risultati possono non essere trasferibili tra prove.
• Il test non dice se c’è upscaling (o quale modalità): il confronto rischia di essere “mele con pere”.
• Il 1% low è presente ma senza indicazione di metodo/tool: evita conclusioni basate sui minimi, concentrati sulla coerenza dello scenario.

Cosa annotare (prima ancora di guardare i numeri)

Prima dei grafici, conviene annotare i dettagli che definiscono lo scenario. Questo passaggio mette nella condizione giusta per interpretare il confronto senza equivoci, perché chiarisce subito che cosa stanno misurando i numeri.

• Scenario: scena/percorso e durata (anche in una riga).
• Output: risoluzione e se il rendering è nativo o con upscaling.
• Grafica: preset e la presenza/assenza di RT.
• Limitazioni: frame cap, V-Sync, VRR.
• Versioni: build del gioco e driver (almeno “uguali tra le prove”).
• Tool: come sono calcolati 1% low e frametime.

Evita falsi positivi e falsi negativi

Molti errori di lettura nascono quando una differenza di impostazioni viene scambiata per una differenza tra GPU. Un falso positivo, cioè un risultato che sembra migliore, può dipendere da frame cap/V-Sync, upscaling non dichiarato, modalità diverse o preset/API non equivalenti anche se hanno lo stesso nome.

Un falso negativo, cioè un risultato che sembra peggiore, può invece comparire quando il run include interferenze evidenti come registrazione, overlay pesanti o attività in background. Lo stesso vale se il test parte “a freddo” e misura anche fasi di preparazione dello scenario, come cache/shader non gestiti allo stesso modo.

Un altro falso negativo possibile riguarda il profilo della GPU: se profili o limiti non sono comparabili, per esempio default vs power limit/OC/undervolt senza dichiarazione, il confronto rischia di attribuire alla scheda una differenza che dipende dalle condizioni della prova.

Errori comuni che falsano i benchmark

Nei benchmark GPU, molti errori non dipendono dai numeri in sé, ma dal modo in cui vengono messi a confronto. Questi sono i casi in cui media FPS, minimi e frametime rischiano di essere interpretati male.

• Confrontare “preset” non equivalenti: due test “Ultra” possono avere settaggi diversi o RT attivo in uno solo.
• Mescolare nativo e upscaling senza dichiararlo: non è un confronto “GPU vs GPU”, è “scenario vs scenario”.
• Usare solo la media per parlare di fluidità: senza 1% low/frametime rischi di ignorare i frame peggiori.
• Ignorare frame cap/V-Sync: se il gioco è limitato, la media smette di essere informativa sulla GPU.
• Attribuire subito alla GPU un frametime irregolare: spesso entrano in gioco componenti dello scenario (asset streaming, CPU, I/O, compilazione shader). Se l’obiettivo è risolvere micro scatti e picchi di frametime, il controllo corretto riguarda lo stuttering GPU.

Domande frequenti sui benchmark GPU

Quale dato devo guardare per primo in un benchmark GPU?

Guarda prima la media FPS per capire il livello generale della prestazione, ma non usarla da sola. Per capire se il risultato è davvero fluido, confronta anche 1% low e frametime: una media alta può nascondere cali improvvisi o frame consegnati in modo irregolare.

Che cosa significa se il 1% low è molto più basso della media FPS?

Significa che nei momenti peggiori del test la fluidità cala molto rispetto al valore medio. Non indica automaticamente che la GPU sia scarsa: può dipendere anche da scena, CPU, streaming degli asset, compilazione shader, driver, tool usato o metodologia del benchmark.

Perché due benchmark della stessa GPU possono dare risultati diversi?

Perché un benchmark misura uno scenario preciso, non una verità assoluta. Risoluzione, preset, API, versione del gioco, driver, upscaling, ray tracing, frame cap, V-Sync, durata del run e scena testata possono cambiare il risultato. Il confronto è pulito solo quando cambia una variabile alla volta.

Il frametime è più importante degli FPS?

Non è “più importante”, ma spiega meglio la regolarità percepita. Gli FPS indicano quanti frame vengono prodotti in media, il frametime mostra quanto tempo passa tra un frame e l’altro. Se il frametime ha picchi frequenti, il gioco può sembrare poco fluido anche con una media FPS buona.

Posso confrontare benchmark con ray tracing, upscaling e frame generation?

Sì, ma solo se li tratti come scenari separati. Un test nativo, un test con ray tracing, un test con DLSS/FSR/XeSS e un test con frame generation non misurano la stessa cosa. Per confrontarli correttamente, modalità, preset, risoluzione interna e impostazioni devono essere dichiarati in modo chiaro.