Měření latence a PresentMon

Na této stránce

PCBenchmarkX samostatně měří vnitřní latenci zpracování a latenci výstupu snímku. Tyto softwarové metriky nepopsují celou cestu od kliknutí myší až po rozsvícení pixelu na obrazovce. Celý měřicí cyklus je popsán v metodice.

Vlastní softwarový stimul

Nepřetržitý proud generuje signály s deterministickými intervaly 8-12 ms. Pokud to Windows dovolí, vytvoří čekající časovač s vysokou přesností; jinak použije běžný čekající časovač. Čekání na událost se obejde bez nepřetržitého dotazování, které by zatěžovalo jádro. Globální rozlišení systémového časovače se přitom nemění.

Pro každý signál se loguje plánovaný termín, probuzení generátoru, skutečný signál, probuzení příjemce, simulace, odeslání příkazů, časové značky GPU a události zobrazení. Společný identifikátor snímku propojuje všechny etapy.

Plánovaný termín → probuzení generátoru → signál
                                            ↓
                               probuzení příjemce
                                            ↓
                                CPU → příkazy → GPU
                                            ↓
                            Present → událost výstupu

V těchto záznamech jsou samostatně vidět jak zpoždění časovače, tak latence probuzení příjemce. Začátek Core Latency je skutečný signál, proto se krok od plánovaného termínu k signálu v této metrice nepočítá.

Rozpad cesty latence podle etap

Výsledek obsahuje rozpad naměřené cesty latency_path podle etap — samostatně pro Baseline a Loaded. Etapy se počítají od skutečného signálu:

Etapa	Co měří
`signal_to_consumer_wake`	od signálu po probuzení příjemce
`cpu_processing`	CPU zpracování: simulaci a přípravu dat snímku
`cpu_end_to_submit_start`	pauzu od konce CPU práce po začátek přípravy odeslání
`workload_submit_cpu_span`	přípravu a zápis příkazů grafického API
`submit_start_to_gpu_begin`	od začátku přípravy po začátek GPU práce; nejde o čistou latenci fronty
`gpu_execution`	samotné vykonání GPU práce, v taktech GPU
presentation spans	zobrazení: obal `Present` a intervaly od signálu a od konce GPU práce po `ScreenTime`

Každá etapa je dána rozdělením se statistikami a percentily. Segmenty se počítají pro každou dvojici značek samostatně, nikoli odečtením dvou mediánů. Pokud koncová značka etapy chybí nebo je nedůvěryhodná, její rozdělení zůstává prázdné — žádné náhradní hodnoty neexistují. Zpoždění časovače (rozpor mezi plánovaným termínem a skutečným signálem) se zaznamenává jako samostatná diagnostika před signálem a do souhrnných hodnot cesty se nezahrnuje.

QPC a vlastní GPU timestamps

CPU čas se zaznamenává přes QueryPerformanceCounter. Pro GPU engine umisťuje dvě timestamp query kolem měřené práce, získává frekvenci fronty přes GetTimestampFrequency a převádí rozdíl tiků na milisekundy:

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

Podle dokumentace Microsoft k D3D12 timing timestamp query odráží průchod práce až na konec pipeline a GPU a CPU čítače se propojují přes GetClockCalibration.

Kalibrační pár GPU/QPC umožňuje vyjádřit dokončení GPU práce na stejné časové škále jako signál:

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

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

Přesnost tohoto odhadu do značné míry závisí na tom, jak přesně jsou hodiny CPU a GPU přiřazeny k sobě. Stále však nepokrývá USB cestu myši, dobu snímání matrice ani odezvu pixelu. Microsoft samostatně popisuje nuance vysoce přesných značek QPC.

Baseline a Loaded

Baseline měří latenci v minimální konfiguraci této zátěže. Loaded pracuje s GPU zátěží kalibrovanou na 8,333333 ms, tedy na výpočetní rozpočet přibližně 120 Hz. Fyzický monitor může mít jinou frekvenci.

Kalibrace mění složitost uvnitř shaderu v rozsahu 1-4096. Počet průchodů zůstává pevný: čtyři postprocesy. Nejprve se hledá rozsah kolem cílového času, poté se zpřesní a zvolená konfigurace se ověří. Aby se stejný čas zabral na rychlé grafické kartě, je zapotřebí složitější práce.

V Performance je objem práce pevný. V Loaded Latency se zátěž kalibruje, aby doba GPU práce byla na různých grafických kartách podobná. Získané časové značky se po měření nenormalizují.

Výstup snímků testu latence jde přes samostatnou prezentační cestu: bezrámové okno v režimu flip-discard, maximální latence snímku (maximum frame latency) 1, očekávaný objekt DXGI a tearing, pokud jej systém podporuje. Tato cesta je oddělena od pevné zátěže výkonu, která se vykonává mimo obrazový buffer a nevyvolává Present.

Role PresentMon

Pro události zobrazení se používá knihovna PresentMon 2.5.1. Jde o ETW projekt analýzy grafických událostí ve Windows, popsaný jeho autory. Procmon / Process Monitor se v tomto měřicím řetězci nepoužívá.

PCBenchmarkX spouští vlastní sběrnou relaci, vybírá události svého procesu a propojuje snímky se softwarovými signály. K tomu není zapotřebí samostatná služba ani ruční spuštění samostatného PresentMon.

Ukládají se další intervaly:

od signálu po Present;
od Present po ScreenTime;
od signálu po ScreenTime.

ScreenTime je softwarová událost zobrazení snímku; fotodioda pro měření světla z obrazovky se nepoužívá. Metriky zobrazení nejsou součástí PC Score; co je jeho součástí, je popsáno ve výpočtu skóre. Spuštění ETW relace může vyžadovat spuštění jako správce nebo členství ve skupině „Uživatelé protokolu výkonu“. Pokud se relaci nepodařilo spustit, blok této diagnostiky nebude a selhání se ve výsledku zaznamená výslovně. Absence dat se nerovná nulové latenci.

GPU čas PresentMon se také ukládá odděleně od vlastního D3D12 času. Vývojáři PresentMon upozorňují na omezení přesnosti GPU metrik při HAGS. Engine proto nenahrazuje vlastní GPU timestamps odhadem z ETW.

Co je vyvinuto v PCBenchmarkX

V PCBenchmarkX jsou vyvinuty generátor signálů, přiřazení etap snímku, CPU simulace, D3D12 zátěže, kalibrace Loaded, pořadí opakujících se bloků, sběr měření, statistické zpracování a model skóre. QPC a D3D12 poskytuje Windows. Pro sběr grafických událostí přes ETW se používá otevřený projekt PresentMon.

Technické údaje a externí zdroje byly ověřeny 2026-09-20 pro engine 0.5.2.