Måling af latenstider og PresentMon

PCBenchmarkX måler intern behandlingslatens og latens for frame-output separat. Disse softwaremetrikker beskriver ikke hele vejen fra museklik til pixel på skærmen. Den fulde målecyklus er beskrevet i metodikken.

Eget softwarestimulus

En konstant strøm genererer signaler med deterministiske intervaller på 8-12 ms. Hvis Windows tillader det, opretter den en ventende højpræcisionstimer; ellers bruger den en almindelig ventende timer. Afventning af hændelsen foregår uden kontinuerlig polling, som ville optage kernen. Den globale opløsning af systemtimeren ændres ikke.

For hvert signal logges det planlagte tidspunkt, generatorens opvågning, det faktiske signal, modtagerens opvågning, simuleringen, afsendelse af kommandoer, GPU-tidsstempler og visningshændelser. En fælles frame-identifikator binder alle faser sammen.

Planlagt tidspunkt → generatorens opvågning → signal
                                            ↓
                               modtagerens opvågning
                                            ↓
                                CPU → kommandoer → GPU
                                            ↓
                            Present → outputhændelse

I disse forløb ses både timerens forsinkelse og modtagerens opvågningslatens separat. Start på Core Latency er det faktiske signal, derfor tælles skridtet fra det planlagte tidspunkt til signalet ikke med i denne metrik.

Faseopdelt opdeling af latensvejen

Resultatet indeholder en faseopdelt opdeling af den målte vej latency_path — separat for Baseline og Loaded. Faserne tælles fra det faktiske signal:

Fase	Hvad der måles
signal_to_consumer_wake	fra signal til modtagerens opvågning
cpu_processing	CPU-behandling: simulering og forberedelse af frame-data
cpu_end_to_submit_start	pause fra slutningen af CPU-arbejdet til starten på forberedelsen af afsendelse
workload_submit_cpu_span	forberedelse og registrering af kommandoer til grafik-API’et
submit_start_to_gpu_begin	fra starten på forberedelsen til starten på GPU-arbejdet; dette er ikke ren kølatens
gpu_execution	selve udførelsen af GPU-arbejdet, i GPU-ticks
presentation spans	visning: indpakningen Present og intervaller fra signal og fra slutningen af GPU-arbejdet til ScreenTime

Hver fase angives som en fordeling med statistikker og percentiler. Segmenterne beregnes for hvert par af markeringer separat, ikke ved at trække to medianer fra hinanden. Hvis en fases slutmarkering mangler eller er upålidelig, forbliver dens fordeling tom — der er ingen erstatningsværdier. Timerens forsinkelse (afvigelsen mellem det planlagte tidspunkt og det faktiske signal) registreres som en separat diagnostik før signalet og indgår ikke i vejens samlede værdier.

QPC og egne GPU-timestamps

CPU-tid registreres via QueryPerformanceCounter. For GPU’en placerer motoren to timestamp queries omkring det målte arbejde, henter køens frekvens via GetTimestampFrequency og omregner tick-forskellen til millisekunder:

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

Ifølge Microsofts dokumentation om D3D12 timing afspejler timestamp query arbejdets gennemløb til slutningen af pipelinen, og GPU- og CPU-tællere sammenkædes via GetClockCalibration.

Et kalibreringspar af GPU/QPC gør det muligt at udtrykke afslutningen af GPU-arbejdet på samme tidsskala som signalet:

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

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

Nøjagtigheden af denne vurdering afhænger i høj grad af, hvor præcist CPU- og GPU-urene er afstemt. Den dækker stadig ikke musens USB-vej, tidspunktet for matrixscanning eller pixelrespons. Microsoft beskriver separat nuancerne ved højpræcise QPC-markeringer.

Baseline og Loaded

Baseline måler latenstiden i denne belastnings minimale konfiguration. Loaded arbejder med en GPU-belastning kalibreret til 8,333333 ms, altså til et beregningsbudget på cirka 120 Hz. Den fysiske skærm kan have en anden frekvens.

Kalibreringen ændrer kompleksiteten inde i shaderen i intervallet 1-4096. Antallet af gennemløb forbliver fast: fire post-passes. Først findes et interval omkring den ønskede tid, derefter finjusteres det, og den valgte konfiguration verificeres. For at optage samme tid på et hurtigt grafikkort kræves mere komplekst arbejde.

I ydelsestests er arbejdsmængden fast. I Loaded Latency kalibreres belastningen, så GPU-arbejdstiden er sammenlignelig på tværs af grafikkort. De opnåede tidsstempler normaliseres ikke efter målingen.

Frame-output i latenstesten går gennem en separat præsentationsvej: et kantløst vindue i flip-discard-tilstand, maksimal frame latency 1, det forventede DXGI-objekt og tearing, hvis systemet understøtter det. Denne vej er adskilt fra den faste ydelsesbelastning, som udføres uden for skærmbufferen og ikke udløser Present.

PresentMons rolle

Til visningshændelser bruges biblioteket PresentMon 2.5.1. Det er et ETW-projekt til analyse af grafikbegivenheder i Windows, beskrevet af dets forfattere. Procmon / Process Monitor anvendes ikke i denne målepipeline.

PCBenchmarkX starter sin egen indsamlingssession, filtrerer begivenheder fra sin egen proces og binder frames til softwaresignalerne. Det kræver ingen separat tjeneste og ingen manuel start af en separat PresentMon.

Der gemmes yderligere intervaller:

• fra signal til Present;
• fra Present til ScreenTime;
• fra signal til ScreenTime.

ScreenTime er en softwarehændelse for frame-visning; der bruges ingen fotodiode til at måle lys fra skærmen. I basismodellen CPU/GPU/Latency udgør vægtene for Baseline og Loaded 20/80 inde i latenskomponenten. Visningsmetrikkerne indgår ikke i PC Score; hvad der indgår, er beskrevet i beregningen af point. Start af en ETW-session kan kræve kørsel som administrator eller medlemskab af gruppen “Performance Log Users”. Hvis sessionen ikke kunne startes, udelades denne diagnostikblok, og fejlen registreres eksplicit i resultatet. Fravær af data er ikke det samme som nul latens.

PresentMons GPU-tid gemmes også separat fra den egen D3D12-tid. PresentMons udviklere bemærker begrænsninger i nøjagtigheden af GPU-metrikker ved HAGS. Derfor erstatter motoren ikke sine egne GPU-timestamps med et estimat fra ETW.

Hvad der er udviklet i PCBenchmarkX

I PCBenchmarkX er der udviklet signalgenerator, sammenkædning af frame-faser, CPU-simulering, D3D12-belastninger, kalibrering af Loaded, rækkefølgen af gentagne blokke, indsamling af målinger, statistisk behandling og pointmodel. QPC og D3D12 leveres af Windows. Til indsamling af grafikbegivenheder via ETW bruges det åbne projekt PresentMon.

Beskrivelsen af målingen blev opdateret 2026-10-02 for motoren 0.8.0. Microsofts dokumentation om QPC og D3D12 blev gennemgået igen på denne dato. PresentMon-linket refererer til den anvendte version 2.5.1.