Latency-måling og PresentMon

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

Egen softwaremæssig stimulus

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 ved dette.

For hvert signal logges den planlagte frist, 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 trin sammen.

Planlagt frist → 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ågningsforsinkelse separat. Start på Core Latency er det faktiske signal, derfor tælles trinnet fra planlagt frist til signal ikke med i denne metrik.

Trinvis opdeling af forsinkelsesvejen

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

Trin	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 af forberedelsen af afsendelse
workload_submit_cpu_span	forberedelse og skrivning af kommandoer til grafik-API’et
submit_start_to_gpu_begin	fra starten af forberedelsen til starten af GPU-arbejdet; dette er ikke ren køforsinkelse
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

Hvert trin 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 et trins sløjfemærke mangler eller er upålideligt, forbliver dets fordeling tom — der er ingen erstatningsværdier. Timerens forsinkelse (afvigelsen mellem planlagt frist og faktisk signal) registreres som en separat diagnostik før signalet og indgår ikke i vejens samlede værdier.

QPC og egne GPU-tidsstempler

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 enden af pipelinen, og GPU- og CPU-tællere sammenkædes via GetClockCalibration.

Et kalibreringspar 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 alligevel ikke musens USB-vej, matrixscanningstiden eller pixelresponset. Microsoft beskriver separat nuancerne ved højpræcise QPC-markeringer.

Baseline og Loaded

Baseline måler forsinkelsen 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 måltiden, derefter finpudses det, og den valgte konfiguration verificeres. For at optage samme tid på et hurtigt grafikkort kræves mere komplekst arbejde.

I Performance 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 fra forsinkelsestesten går gennem en separat præsentationsvej: et kantløst vindue i flip-discard-tilstand, maksimal frame-forsinkelse (maximum frame latency) 1, det forventede DXGI-objekt og tearing, hvis systemet understøtter det. Denne vej er adskilt fra den faste performancebelastning, 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, udvælger hændelser fra sin egen proces og binder frames til softwaresignalerne. Det kræver ikke en separat tjeneste og manuel start af en separat PresentMon.

Følgende yderligere intervaller gemmes:

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

ScreenTime er en softwaremæssig frame-visningshænding; der bruges ikke en fotodiode til at måle lys fra skærmen. Visningsmetrikker indgår ikke i PC Score; hvad der indgår, er beskrevet i beregningen af point. Opstart af en ETW-session kan kræve kørsel som administrator eller medlemskab af gruppen “Performance Log Users”. Hvis sessionen ikke kunne startes, vil denne diagnostikblok ikke være til stede, og fejlen registreres eksplicit i resultatet. Manglende data er ikke lig med nul forsinkelse.

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-tidsstempler med et estimat fra ETW.

Hvad der er udviklet i PCBenchmarkX

I PCBenchmarkX er der udviklet signalgenerator, sammenkædning af frame-trin, 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.

Tekniske oplysninger og eksterne kilder er verificeret 2026-09-20 for motor 0.5.2.