Mesure des latences et PresentMon

Sur cette page

PCBenchmarkX mesure séparément la latence interne de traitement et la latence de sortie de l’image. Ces métriques logicielles ne décrivent pas tout le trajet depuis le clic de souris jusqu’à l’allumage du pixel à l’écran. Le cycle de mesure complet est décrit dans la méthodologie.

Stimulus logiciel propre

Un flux constant génère des signaux à intervalles déterministes de 8-12 ms. Si Windows le permet, il crée un timer en attente de haute précision ; sinon il utilise un timer en attente ordinaire. L’attente de l’événement se passe sans interrogation continue, qui occuperait le noyau. La résolution globale du timer système n’est pas modifiée pour autant.

Pour chaque signal sont journalisés l’échéance planifiée, le réveil du générateur, le signal réel, le réveil du destinataire, la simulation, l’envoi des commandes, les horodatages GPU et les événements de présentation. Un identifiant de frame commun relie toutes les étapes.

Échéance planifiée → réveil du générateur → signal
                                            ↓
                               réveil du destinataire
                                            ↓
                                CPU → commandes → GPU
                                            ↓
                            Present → événement de sortie

Dans ces chaînes, on distingue séparément le retard du timer et la latence de réveil du destinataire. Le début de Core Latency est le signal réel, c’est pourquoi l’étape de l’échéance planifiée au signal n’est pas comptée dans cette métrique.

Décomposition par étapes du trajet de latence

Le résultat contient une décomposition par étapes du trajet mesuré latency_path — séparément pour Baseline et Loaded. Les étapes sont comptées à partir du signal réel :

Étape	Ce qu’elle mesure
`signal_to_consumer_wake`	du signal au réveil du destinataire
`cpu_processing`	le traitement CPU : simulation et préparation des données de la frame
`cpu_end_to_submit_start`	la pause entre la fin du travail CPU et le début de la préparation de l’envoi
`workload_submit_cpu_span`	la préparation et l’écriture des commandes de l’API graphique
`submit_start_to_gpu_begin`	du début de la préparation au début du travail GPU ; ce n’est pas une latence de file pure
`gpu_execution`	l’exécution même du travail GPU, en cycles GPU
presentation spans	la présentation : l’enveloppe `Present` et les intervalles du signal et de la fin du travail GPU jusqu’à `ScreenTime`

Chaque étape est donnée sous forme de distribution avec statistiques et percentiles. Les segments sont calculés pour chaque paire de repères séparément, et non par soustraction de deux médianes. Si le repère final d’une étape est absent ou non fiable, sa distribution reste vide — aucune valeur de substitution n’est fournie. Le retard du timer (écart entre l’échéance planifiée et le signal réel) est enregistré comme diagnostic distinct avant le signal et n’entre pas dans les valeurs totales du trajet.

QPC et GPU timestamps propres

Le temps CPU est enregistré via QueryPerformanceCounter. Pour le GPU, le moteur place deux timestamp query autour du travail mesuré, obtient la fréquence de la file via GetTimestampFrequency et convertit la différence de ticks en millisecondes :

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

D’après la documentation Microsoft sur le timing D3D12, timestamp query reflète l’avancement du travail jusqu’à la fin du pipeline, et les compteurs GPU et CPU sont mis en correspondance via GetClockCalibration.

La paire de calibration GPU/QPC permet d’exprimer l’achèvement du travail GPU sur la même échelle temporelle que le 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

La précision de cette estimation dépend largement de la justesse de la mise en correspondance des horloges CPU et GPU. Elle ne couvre toujours pas le trajet USB de la souris, le temps de balayage de la matrice ou la réponse du pixel. Microsoft décrit séparément les nuances des repères QPC de haute précision.

Baseline et Loaded

Baseline mesure la latence dans la configuration minimale de cette charge. Loaded fonctionne avec une charge GPU calibrée sur 8,333333 ms, soit un budget de calcul d’environ 120 Hz. Le moniteur physique peut avoir une autre fréquence.

La calibration modifie la complexité à l’intérieur du shader dans la plage 1-4096. Le nombre de passes reste fixe : quatre post-passes. D’abord une plage est recherchée autour du temps cible, puis elle est affinée et la configuration choisie est vérifiée. Pour occuper le même temps sur une carte graphique rapide, un travail plus complexe est nécessaire.

Dans Performance, le volume de travail est fixe. Dans Loaded Latency, la charge est calibrée pour que le temps de travail GPU soit proche sur différentes cartes graphiques. Les horodatages obtenus ne sont pas normalisés après la mesure.

La sortie des frames du test de latence passe par un chemin de présentation distinct : fenêtre sans bordure en mode flip-discard, latence de frame maximale (maximum frame latency) 1, objet DXGI attendu et tearing si le système le prend en charge. Ce chemin est séparé de la charge de performance fixe, qui s’exécute hors du tampon d’affichage et ne provoque pas de Present.

Rôle de PresentMon

Pour les événements de présentation, la bibliothèque PresentMon 2.5.1 est utilisée. C’est un projet ETW d’analyse des événements graphiques dans Windows, décrit par ses auteurs. Procmon / Process Monitor n’est pas utilisé dans ce pipeline de mesure.

PCBenchmarkX lance sa propre session de collecte, sélectionne les événements de son processus et relie les frames aux signaux logiciels. Cela ne nécessite ni service séparé ni lancement manuel d’un PresentMon distinct.

Des intervalles supplémentaires sont conservés :

du signal à Present ;
de Present à ScreenTime ;
du signal à ScreenTime.

ScreenTime est un événement logiciel de présentation de la frame ; aucune photodiode pour mesurer la lumière de l’écran n’est utilisée. Les métriques de présentation n’entrent pas dans le PC Score ; ce qui y entre est décrit dans le calcul des points. Le lancement d’une session ETW peut nécessiter une exécution en tant qu’administrateur ou l’appartenance au groupe « Utilisateurs du journal de performances ». Si la session n’a pas pu être lancée, le bloc de ce diagnostic sera absent, et l’échec est consigné explicitement dans le résultat. L’absence de données n’équivaut pas à une latence nulle.

Le temps GPU de PresentMon est également stocké séparément du temps D3D12 propre. Les développeurs de PresentMon signalent les limites de précision des métriques GPU avec HAGS. C’est pourquoi le moteur ne remplace pas ses propres GPU timestamps par une estimation issue d’ETW.

Ce qui a été développé dans PCBenchmarkX

Dans PCBenchmarkX ont été développés le générateur de signaux, la mise en correspondance des étapes de la frame, la simulation CPU, les charges D3D12, la calibration Loaded, l’ordre des blocs répétés, la collecte des mesures, le traitement statistique et le modèle de points. QPC et D3D12 sont fournis par Windows. Pour la collecte des événements graphiques via ETW, le projet open source PresentMon est utilisé.

Les informations techniques et les sources externes ont été vérifiées le 2026-09-20 pour le moteur 0.5.2.