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 d’événement se passe de sondage continu, 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 sont visibles 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 le pas entre l’échéance planifiée et le signal n’est pas compté 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 pure latence de file
`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 le passage 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 la fin 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 ni 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 les tests de 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 repères temporels 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’écran et ne provoque pas 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 employé 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 n’est utilisée pour mesurer la lumière de l’écran. Dans le modèle de base CPU/GPU/Latency, les poids de Baseline et Loaded sont de 20/80 au sein du composant de latence. 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 est développé dans PCBenchmarkX

Dans PCBenchmarkX sont 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 de 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 ouvert PresentMon est utilisé.

La description de la mesure a été mise à jour le 2026-10-02 pour le moteur 0.8.0. La documentation Microsoft sur QPC et D3D12 a été revérifiée à cette date. La référence PresentMon se rapporte à la version utilisée 2.5.1.