Latenzmessung und PresentMon

Auf dieser Seite

PCBenchmarkX misst die interne Verarbeitungslatenz und die Latenz der Frame-Ausgabe getrennt. Diese Software-Metriken beschreiben nicht den gesamten Weg vom Mausklick bis zum Leuchten des Pixels auf dem Bildschirm. Der vollständige Messzyklus ist in der Methodik beschrieben.

Eigener Software-Stimulus

Ein kontinuierlicher Strom erzeugt Signale mit deterministischen Intervallen von 8-12 ms. Wenn Windows es zulässt, erstellt er einen wartenden Timer hoher Präzision; andernfalls verwendet er einen gewöhnlichen wartenden Timer. Das Warten auf das Ereignis kommt ohne kontinuierliches Polling aus, das den Kernel beanspruchen würde. Die globale Auflösung des Systemtimers ändert sich dabei nicht.

Für jedes Signal werden der geplante Termin, das Aufwachen des Generators, das tatsächliche Signal, das Aufwachen des Empfängers, die Simulation, das Senden von Befehlen, die GPU-Timestamps und die Präsentationsereignisse protokolliert. Eine gemeinsame Frame-ID verknüpft alle Etappen.

Geplanter Termin → Aufwachen des Generators → Signal
                                            ↓
                               Aufwachen des Empfängers
                                            ↓
                                CPU → Befehle → GPU
                                            ↓
                            Present → Ausgabeereignis

In diesen Ketten sind sowohl die Verspätung des Timers als auch die Aufwachverzögerung des Empfängers separat sichtbar. Der Beginn der Core Latency ist das tatsächliche Signal, daher wird der Schritt vom geplanten Termin bis zum Signal in dieser Metrik nicht gezählt.

Stufenweise Aufschlüsselung des Latenzpfads

Das Ergebnis enthält eine stufenweise Aufschlüsselung des gemessenen Pfads latency_path — getrennt für Baseline und Loaded. Die Stufen werden ab dem tatsächlichen Signal gezählt:

Stufe	Was gemessen wird
`signal_to_consumer_wake`	vom Signal bis zum Aufwachen des Empfängers
`cpu_processing`	CPU-Verarbeitung: Simulation und Vorbereitung der Frame-Daten
`cpu_end_to_submit_start`	Pause vom Ende der CPU-Arbeit bis zum Beginn der Vorbereitung des Versands
`workload_submit_cpu_span`	Vorbereitung und Aufzeichnung der Befehle der Grafik-API
`submit_start_to_gpu_begin`	vom Beginn der Vorbereitung bis zum Beginn der GPU-Arbeit; dies ist nicht die reine Warteschlangenlatenz
`gpu_execution`	die eigentliche Ausführung der GPU-Arbeit, in GPU-Takten
presentation spans	Anzeige: die Hülle `Present` und die Intervalle vom Signal und vom Ende der GPU-Arbeit bis `ScreenTime`

Jede Stufe wird als Verteilung mit Statistiken und Perzentilen angegeben. Die Segmente werden für jedes Paar von Markierungen separat berechnet, nicht durch Subtraktion zweier Mediane. Wenn die Endmarkierung einer Stufe fehlt oder unzuverlässig ist, bleibt ihre Verteilung leer — es gibt keine Ersatzwerte. Die Verspätung des Timers (Abweichung zwischen geplantem Termin und tatsächlichem Signal) wird als separate Diagnose vor dem Signal erfasst und geht nicht in die Summenwerte des Pfads ein.

QPC und eigene GPU timestamps

Die CPU-Zeit wird über QueryPerformanceCounter erfasst. Für die GPU platziert die Engine zwei timestamp queries um die gemessene Arbeit, ermittelt die Frequenz der Warteschlange über GetTimestampFrequency und rechnet die Tick-Differenz in Millisekunden um:

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

Laut Microsoft-Dokumentation zu D3D12 timing spiegelt timestamp query den Durchlauf der Arbeit bis zum Ende der Pipeline wider, und GPU- und CPU-Zähler werden über GetClockCalibration verknüpft.

Ein Kalibrierungspaar aus GPU/QPC ermöglicht es, den Abschluss der GPU-Arbeit auf derselben Zeitachse auszudrücken wie das Signal:

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

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

Die Genauigkeit dieser Schätzung hängt weitgehend davon ab, wie genau die CPU- und GPU-Uhren einander zugeordnet sind. Sie deckt trotzdem weder den USB-Pfad der Maus noch die Scanzeit der Matrix oder die Reaktion des Pixels ab. Microsoft beschreibt die Nuancen hochpräziser QPC-Markierungen separat.

Baseline und Loaded

Baseline misst die Latenz in der minimalen Konfiguration dieser Last. Loaded arbeitet mit einer GPU-Last, die auf 8,333333 ms kalibriert ist, also auf ein Rechenbudget von etwa 120 Hz. Der physische Monitor kann eine andere Frequenz haben.

Die Kalibrierung verändert die Komplexität innerhalb des Shaders im Bereich 1-4096. Die Anzahl der Durchläufe bleibt fest: vier Post-Durchläufe. Zuerst wird ein Bereich um die Zielzeit herum gesucht, dann wird er verfeinert und die gewählte Konfiguration überprüft. Um auf einer schnellen Grafikkarte dieselbe Zeit zu beanspruchen, ist komplexere Arbeit nötig.

In Performance ist der Arbeitsumfang fest. In Loaded Latency wird die Last kalibriert, damit die GPU-Arbeitszeit auf verschiedenen Grafikkarten ähnlich ist. Die erhaltenen Zeitmarkierungen werden nach der Messung nicht normalisiert.

Die Frame-Ausgabe des Latenztests läuft über einen separaten Präsentationspfad: ein rahmenloses Fenster im Modus flip-discard, maximale Frame-Latenz (maximum frame latency) 1, ein DXGI-Warteobjekt und Tearing, wenn das System es unterstützt. Dieser Pfad ist von der festen Performance-Last getrennt, die außerhalb des Bildschirmpuffers ausgeführt wird und kein Present auslöst.

Die Rolle von PresentMon

Für die Präsentationsereignisse wird die Bibliothek PresentMon 2.5.1 verwendet. Dies ist ein ETW-Projekt zur Analyse von Grafikereignissen in Windows, beschrieben von seinen Autoren. Procmon / Process Monitor wird in dieser Messpipeline nicht eingesetzt.

PCBenchmarkX startet eine eigene Sammlungssitzung, filtert die Ereignisse seines Prozesses heraus und verknüpft die Frames mit den Software-Signalen. Dafür ist kein separater Dienst und kein manueller Start eines separaten PresentMon nötig.

Zusätzliche Intervalle werden gespeichert:

vom Signal bis Present;
von Present bis ScreenTime;
vom Signal bis ScreenTime.

ScreenTime ist ein Software-Ereignis der Frame-Präsentation; eine Fotodiode zur Messung des Lichts vom Bildschirm wird nicht verwendet. Die Präsentationsmetriken gehen nicht in den PC Score ein; was in ihn eingeht, ist in der Berechnung der Punkte beschrieben. Das Starten einer ETW-Sitzung kann den Start als Administrator oder die Mitgliedschaft in der Gruppe „Benutzer der Leistungsprotokolle“ erfordern. Wenn die Sitzung nicht gestartet werden konnte, fehlt dieser Diagnoseblock, und der Fehler wird im Ergebnis ausdrücklich festgehalten. Fehlende Daten sind nicht gleich null Latenz.

Die GPU-Zeit von PresentMon wird ebenfalls getrennt von der eigenen D3D12-Zeit gespeichert. Die Entwickler von PresentMon weisen auf Genauigkeitsgrenzen der GPU-Metriken bei HAGS hin. Daher ersetzt die Engine die eigenen GPU timestamps nicht durch eine Schätzung aus ETW.

Was in PCBenchmarkX entwickelt wurde

In PCBenchmarkX wurden der Signalgenerator, die Zuordnung der Frame-Etappen, die CPU-Simulation, die D3D12-Lasten, die Kalibrierung von Loaded, die Reihenfolge der wiederholten Blöcke, die Erfassung der Messungen, die statistische Verarbeitung und das Punkte-Modell entwickelt. QPC und D3D12 stellt Windows bereit. Für die Erfassung der Grafikereignisse über ETW wird das offene Projekt PresentMon verwendet.

Die technischen Angaben und externen Quellen wurden am 2026-09-20 für die Engine 0.5.2 geprüft.