Pāriet uz saturu

Aiztures mērīšana un PresentMon

Šajā lapā

PCBenchmarkX atsevišķi mēra iekšējo apstrādes latentumu un kadra izvades latentumu. Šīs programmatūras metrikas neapraksta visu ceļu no peles klikšķa līdz pikseļa iedegšanai ekrānā. Pilns mērīšanas cikls ir aprakstīts metodikā.

Pastāvīga plūsma ģenerē signālus ar deterministiskiem intervāliem 8-12 ms. Ja Windows to atļauj, tā izveido gaidošu augstas precizitātes taimeri; citādi izmanto parastu gaidošu taimeri. Notikuma gaidīšana iztiek bez nepārtrauktas aptaujas, kas aizņemtu kodolu. Sistēmas taimera globālā izšķirtspēja pie tam nemainās.

Katram signālam tiek reģistrēts plānotais termiņš, ģeneratora pamošanās, faktiskais signāls, saņēmēja pamošanās, simulācija, komandu nosūtīšana, GPU laikspiedoli un attēlošanas notikumi. Kopīgs kadra identifikators saista visus posmus.

Plānotais termiņš → ģeneratora pamošanās → signāls
↓
saņēmēja pamošanās
↓
CPU → komandas → GPU
↓
Present → izvades notikums

Šajās lentēs atsevišķi ir redzams gan taimera nokavējums, gan saņēmēja pamošanās latentums. Core Latency sākums ir faktiskais signāls, tāpēc solis no plānotā termiņa līdz signālam šajā metrikā netiek skaitīts.

Rezultāts satur izmērītā ceļa latency_path sadalījumu pa posmiem — atsevišķi Baseline un Loaded. Posmi tiek skaitīti no faktiskā signāla:

Posms Ko mēra
signal_to_consumer_wake no signāla līdz saņēmēja pamošanās
cpu_processing CPU apstrādi: kadra datu simulāciju un sagatavošanu
cpu_end_to_submit_start pauzi no CPU darba beigām līdz nosūtīšanas sagatavošanas sākumam
workload_submit_cpu_span grafiskā API komandu sagatavošanu un ierakstīšanu
submit_start_to_gpu_begin no sagatavošanas sākuma līdz GPU darba sākumam; tas nav tīrs rindas latentums
gpu_execution pašu GPU darba izpildi, GPU taktos
presentation spans attēlošanu: Present ietvaru un intervālus no signāla un no GPU darba beigām līdz ScreenTime

Katrs posms tiek dots ar sadalījumu ar statistikām un procentilēm. Segmenti tiek skaitīti katram atzīmju pārim atsevišķi, nevis atņemot divas mediānas. Ja posma beigu atzīme trūkst vai nav ticama, tā sadalījums paliek tukšs — aizvietotas vērtības netiek izmantotas. Taimera nokavējums (plānotā termiņa un faktiskā signāla atšķirība) tiek reģistrēts kā atsevišķa diagnostika pirms signāla un neietilpst ceļa kopsummas vērtībās.

CPU laiks tiek reģistrēts caur QueryPerformanceCounter. GPU dzinējs izvieto divus timestamp query ap mērāmo darbu, iegūst rindas frekvenci caur GetTimestampFrequency un pārvērš taktu starpību milisekundēs:

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

Saskaņā ar Microsoft dokumentāciju par D3D12 timing, timestamp query atspoguļo darba pabeigšanu līdz konveijera galam, un GPU un CPU skaitītāji tiek sasaistīti caur GetClockCalibration.

GPU/QPC kalibrācijas pāris ļauj izteikt GPU darba pabeigšanu tajā pašā laika skalā kā signālu:

GPU_completion_QPC = calibration_QPC +
(GPU_end − calibration_GPU) × QPC_frequency / GPU_frequency
Core Latency, ms =
(GPU_completion_QPC − signal_QPC) × 1000 / QPC_frequency

Šīs aplēses precizitāte lielā mērā ir atkarīga no tā, cik precīzi ir saskaņoti CPU un GPU pulksteņi. Tā joprojām neaptver peles USB ceļu, matricas skenēšanas laiku vai pikseļa atbildes laiku. Microsoft atsevišķi apraksta augstas precizitātes QPC atzīmju nianses.

Baseline mēra latentumu šīs slodzes minimālajā konfigurācijā. Loaded strādā ar GPU slodzi, kas kalibrēta uz 8,333333 ms, tas ir, uz aptuveni 120 Hz skaitļošanas budžetu. Fiziskajam monitoram var būt cita frekvence.

Kalibrācija maina sarežģītību šeidera iekšienē diapazonā 1-4096. Gājienu skaits paliek fiksēts: četri pēcapstrādes gājieni. Vispirms tiek piemeklēts diapazons ap mērķa laiku, pēc tam tas tiek precizēts un izvēlētā konfigurācija tiek pārbaudīta. Lai aizņemtu to pašu laiku uz ātras videokartes, ir nepieciešams sarežģītāks darbs.

Performance režīmā darba apjoms ir fiksēts. Loaded Latency režīmā slodze tiek kalibrēta, lai GPU darba laiks būtu līdzīgs uz dažādām videokartēm. Iegūtās laika atzīmes pēc mērīšanas netiek normalizētas.

Latentuma testa kadru izvade notiek pa atsevišķu prezentācijas ceļu: bezrāmja logs flip-discard režīmā, maksimālais kadra latentums (maximum frame latency) 1, gaidāmais DXGI objekts un tearing, ja sistēma to atbalsta. Šis ceļš ir atdalīts no fiksētās veiktspējas slodzes, kas tiek izpildīta ārpus ekrāna bufera un neizraisa Present.

Attēlošanas notikumiem tiek izmantota bibliotēka PresentMon 2.5.1. Tas ir ETW grafisko notikumu analīzes projekts Windows vidē, ko aprakstījuši tā autori. Procmon / Process Monitor šajā mērīšanas konveijerā netiek izmantots.

PCBenchmarkX paceļ savu vākšanas sesiju, atlasa sava procesa notikumus un saista kadrus ar programmatūras signāliem. Tam nav nepieciešams atsevišķs serviss un manuāla atsevišķa PresentMon palaišana.

Tiek saglabāti papildu intervāli:

  • no signāla līdz Present;
  • no Present līdz ScreenTime;
  • no signāla līdz ScreenTime.

ScreenTime ir programmatūras kadra attēlošanas notikums; fotodiode gaismas mērīšanai no ekrāna netiek izmantota. Attēlošanas metrikas neietilpst PC Score; kas tajā ietilpst, ir aprakstīts punktu aprēķinā. ETW sesijas pacelšana var prasīt palaišanu administratora vārdā vai dalību grupā “Performance Log Users”. Ja sesiju neizdevās pacelt, šī diagnostikas bloka nebūs, un kļūme tiek fiksēta rezultātā skaidri. Datu trūkums nav vienāds ar nulles latentumu.

PresentMon GPU laiks arī tiek glabāts atsevišķi no paša D3D12 laika. PresentMon izstrādātāji norāda GPU metrikas precizitātes ierobežojumus ar HAGS. Tāpēc dzinējs neaizstāj pašu GPU timestamps ar ETW aplēsi.

PCBenchmarkX ir izstrādāts signālu ģenerators, kadru posmu saskaņošana, CPU simulācija, D3D12 slodzes, Loaded kalibrācija, atkārtojošos bloku secība, mērījumu vākšana, statistiskā apstrāde un punktu modelis. QPC un D3D12 nodrošina Windows. Grafisko notikumu vākšanai caur ETW tiek izmantots atvērtais PresentMon projekts.

Tehniskā informācija un ārējie avoti pārbaudīti 2026-09-20 dzinējam 0.5.2.