Misurazione delle latenze e PresentMon

PCBenchmarkX misura separatamente la latenza interna di elaborazione e la latenza di output del frame. Queste metriche software non descrivono l’intero percorso dal clic del mouse all’accensione del pixel sullo schermo. Il ciclo di misurazione completo è descritto nella metodologia.

Stimolo software proprietario

Un flusso costante genera segnali con intervalli deterministici di 8-12 ms. Se Windows lo consente, crea un timer in attesa ad alta precisione; altrimenti usa un normale timer in attesa. L’attesa dell’evento avviene senza polling continuo, che occuperebbe il core. La risoluzione globale del timer di sistema non viene modificata.

Per ogni segnale vengono registrati la scadenza pianificata, il risveglio del generatore, il segnale effettivo, il risveglio del destinatario, la simulazione, l’invio dei comandi, i timestamp GPU e gli eventi di presentazione. Un identificatore comune del frame collega tutte le fasi.

Scadenza pianificata → risveglio del generatore → segnale
                                            ↓
                               risveglio del destinatario
                                            ↓
                                CPU → comandi → GPU
                                            ↓
                            Present → evento di output

In queste sequenze sono visibili separatamente sia il ritardo del timer sia la latenza di risveglio del destinatario. L’inizio della Core Latency è il segnale effettivo, quindi il passo dalla scadenza pianificata al segnale non viene conteggiato in questa metrica.

Scomposizione per fasi del percorso di latenza

Il risultato contiene una scomposizione per fasi del percorso misurato latency_path — separatamente per Baseline e Loaded. Le fasi vengono conteggiate dal segnale effettivo:

Fase	Cosa misura
signal_to_consumer_wake	dal segnale al risveglio del destinatario
cpu_processing	l’elaborazione CPU: la simulazione e la preparazione dei dati del frame
cpu_end_to_submit_start	la pausa dalla fine del lavoro CPU all’inizio della preparazione dell’invio
workload_submit_cpu_span	la preparazione e la scrittura dei comandi dell’API grafica
submit_start_to_gpu_begin	dall’inizio della preparazione all’inizio del lavoro GPU; non è la pura latenza della coda
gpu_execution	l’esecuzione stessa del lavoro GPU, in cicli GPU
presentation spans	la presentazione: l’involucro Present e gli intervalli dal segnale e dalla fine del lavoro GPU a ScreenTime

Ogni fase è fornita come distribuzione con statistiche e percentili. I segmenti vengono calcolati per ogni coppia di marcatori separatamente, non sottraendo due mediane. Se il marcatore finale di una fase è assente o inattendibile, la sua distribuzione resta vuota — non ci sono valori sostitutivi. Il ritardo del timer (la discrepanza tra la scadenza pianificata e il segnale effettivo) viene registrato come diagnostica separata prima del segnale e non entra nei valori totali del percorso.

QPC e GPU timestamps proprietari

Il tempo CPU viene registrato tramite QueryPerformanceCounter. Per la GPU il motore colloca due timestamp query attorno al lavoro misurato, ottiene la frequenza della coda tramite GetTimestampFrequency e converte la differenza di tick in millisecondi:

GPU work, ms = (GPU_end − GPU_begin) × 1000 / GPU_frequency

Secondo la documentazione Microsoft sul timing D3D12, timestamp query riflette il passaggio del lavoro fino alla fine della pipeline, mentre i contatori GPU e CPU vengono correlati tramite GetClockCalibration.

La coppia di calibrazione GPU/QPC permette di esprimere il completamento del lavoro GPU sulla stessa scala temporale del segnale:

GPU_completion_QPC = calibration_QPC +
  (GPU_end − calibration_GPU) × QPC_frequency / GPU_frequency

Core Latency, ms =
  (GPU_completion_QPC − signal_QPC) × 1000 / QPC_frequency

La precisione di questa stima dipende in gran parte da quanto accuratamente sono allineati gli orologi CPU e GPU. Essa comunque non copre il percorso USB del mouse, il tempo di scansione della matrice o la risposta del pixel. Microsoft descrive separatamente le sfumature dei marcatori QPC ad alta precisione.

Baseline e Loaded

Baseline misura la latenza nella configurazione minima di questo carico. Loaded lavora con un carico GPU calibrato su 8,333333 ms, cioè su un budget di calcolo di circa 120 Hz. Il monitor fisico può avere una frequenza diversa.

La calibrazione modifica la complessità all’interno dello shader nell’intervallo 1-4096. Il numero di passaggi resta fisso: quattro post-passaggi. Prima si individua un intervallo attorno al tempo target, poi lo si affina e la configurazione scelta viene verificata. Per occupare lo stesso tempo su una scheda video veloce serve un lavoro più complesso.

In Performance il volume di lavoro è fisso. In Loaded Latency il carico viene calibrato affinché il tempo del lavoro GPU sia simile su schede video diverse. I marcatori temporali ottenuti dopo la misurazione non vengono normalizzati.

L’output dei frame del test di latenza avviene tramite un percorso di presentazione separato: finestra senza bordi in modalità flip-discard, massima latenza del frame (maximum frame latency) 1, oggetto DXGI in attesa e tearing, se il sistema lo supporta. Questo percorso è separato dal carico fisso di performance, che viene eseguito fuori dal buffer dello schermo e non provoca Present.

Il ruolo di PresentMon

Per gli eventi di presentazione viene usata la libreria PresentMon 2.5.1. È un progetto ETW di analisi degli eventi grafici in Windows, descritto dai suoi autori. Procmon / Process Monitor non viene impiegato in questa pipeline di misurazione.

PCBenchmarkX avvia una propria sessione di raccolta, seleziona gli eventi del proprio processo e collega i frame ai segnali software. Per questo non serve un servizio separato né l’avvio manuale di un PresentMon separato.

Vengono salvati intervalli aggiuntivi:

• dal segnale a Present;
• da Present a ScreenTime;
• dal segnale a ScreenTime.

ScreenTime è un evento software di presentazione del frame; il fotodiodo per misurare la luce dallo schermo non viene usato. Le metriche di presentazione non entrano nel PC Score; cosa vi entra è descritto nel calcolo dei punteggi. L’avvio di una sessione ETW può richiedere l’esecuzione come amministratore o l’appartenenza al gruppo «Utenti del registro di prestazioni». Se la sessione non è riuscita ad avviarsi, il blocco di questa diagnostica non ci sarà, e il guasto viene registrato esplicitamente nel risultato. L’assenza di dati non equivale a latenza zero.

Il tempo GPU di PresentMon viene inoltre memorizzato separatamente dal tempo D3D12 proprietario. Gli sviluppatori di PresentMon segnalano limitazioni di precisione delle metriche GPU con HAGS. Perciò il motore non sostituisce i GPU timestamps proprietari con una stima da ETW.

Cosa è stato sviluppato in PCBenchmarkX

In PCBenchmarkX sono stati sviluppati il generatore di segnali, la correlazione delle fasi del frame, la simulazione CPU, i carichi D3D12, la calibrazione di Loaded, l’ordine dei blocchi ripetuti, la raccolta delle misurazioni, l’elaborazione statistica e il modello dei punteggi. QPC e D3D12 sono forniti da Windows. Per la raccolta degli eventi grafici tramite ETW viene usato il progetto open source PresentMon.

Le informazioni tecniche e le fonti esterne sono state verificate il 2026-09-20 per il motore 0.5.2.