Latenzmessung und PresentMon

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 der Befehle, die GPU-Timestamps und die Anzeigeereignisse protokolliert. Eine gemeinsame Frame-ID verbindet 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 Verzögerung beim Aufwachen 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.

Etappenweise Aufschlüsselung des Latenzpfads

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

Etappe	Was gemessen wird
signal_to_consumer_wake	vom Signal bis zum Aufwachen des Empfängers
cpu_processing	die CPU-Verarbeitung: Simulation und Vorbereitung der Framedaten
cpu_end_to_submit_start	die Pause vom Ende der CPU-Arbeit bis zum Beginn der Vorbereitung des Versands
workload_submit_cpu_span	die Vorbereitung und das Schreiben 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	die Anzeige: die Hülle Present und die Intervalle vom Signal und vom Ende der GPU-Arbeit bis ScreenTime

Jede Etappe 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 Etappe fehlt oder unzuverlässig ist, bleibt ihre Verteilung leer — es gibt keine Ersatzwerte. Die Verspätung des Timers (die 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 die 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 Zeitskala 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 Uhren von CPU und GPU einander zugeordnet werden. 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 Postprocessing-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 eine komplexere Arbeit nötig.

In Leistungstests ist der Arbeitsumfang fest. In Loaded Latency wird die Last kalibriert, damit die Zeit der GPU-Arbeit 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, das erwartete DXGI-Objekt und Tearing, wenn das System es unterstützt. Dieser Pfad ist von der festen Leistungslast getrennt, die außerhalb des Bildschirmpuffers ausgeführt wird und kein Present verursacht.

Die Rolle von PresentMon

Für die Anzeigeereignisse 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 Messkette 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.

Es werden zusätzliche Intervalle gespeichert:

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

ScreenTime ist ein Software-Ereignis der Frame-Anzeige; eine Fotodiode zur Messung des Lichts vom Bildschirm wird nicht verwendet. Im Basismodell CPU/GPU/Latency betragen die Gewichte von Baseline und Loaded 20/80 innerhalb der Latenzkomponente. Die Anzeigemetriken 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. Das Fehlen von Daten ist nicht gleichbedeutend mit 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 Beschreibung der Messung wurde am 2026-10-02 für die Engine 0.8.0 aktualisiert. Die Microsoft-Dokumentation zu QPC und D3D12 wurde an diesem Datum erneut überprüft. Der PresentMon-Link bezieht sich auf die verwendete Version 2.5.1.