Cyberpunk 2077 : où passent vraiment vos FPS ? Le guide complet pour traquer chaque milliseconde, NVIDIA Nsight Graphics

Entre DirectX 12, Vulkan, calcul asynchrone, ray tracing, reconstruction temporelle et génération d’images, profiler les performances de jeux PC ne se résume plus à lire un simple overlay. Pour obtenir des réponses fiables, il faut disséquer la répartition des travaux sur le GPU, le comportement des shaders à l’exécution et les véritables limites d’une frame. Voici une méthode concrète avec NVIDIA Nsight Graphics, appliquée à Cyberpunk 2077, pour passer des suppositions aux faits mesurés. Idéal pour comprendre où le GPU dépense son temps et comment gagner des millisecondes sans tâtonner.

Profilage: méthode et outils à connaître

L’analyse des performances PC a gagné en complexité à l’époque de DirectX 12 et Vulkan. Entre le calcul asynchrone, le ray tracing hardware, les techniques temporelles, la génération d’images et le débruitage appuyé par l’apprentissage automatique, une image ne se résume plus à une suite de draw calls rasterisés. Pour comprendre réellement où part la performance, il faut dépasser les overlays basiques et utiliser un outil capable d’exposer la distribution des tâches sur le GPU, le comportement des shaders en temps réel et les étapes qui plafonnent vraiment la frame. C’est précisément le rôle d’un programme comme NVIDIA Nsight Graphics.

Dans ce guide, nous détaillons un flux de travail pratique pour profiler les performances du GPU dans des jeux modernes avec NVIDIA Nsight Graphics, en prenant Cyberpunk 2077 comme étude de cas. Le but n’est pas de déboguer l’image, mais de lire la performance: où le GPU passe du temps, quels types de charges dominent en raster, ray tracing et path tracing, et comment interpréter les résultats via les fonctions phares d’Nsight Graphics comme le GPU Trace Profiler, les Shader Pipelines et les Hotspots. Notre démarche s’appuie sur l’approche d’analyse en Peak-Performance-Percentage de NVIDIA, qui part d’indices matériels au lieu d’hypothèses sur l’usage du GPU par le moteur.

Qu’est-ce que NVIDIA Nsight Graphics ?

NVIDIA Nsight Graphics est l’outil de débogage et de profilage graphique de NVIDIA pour les API modernes, dont Direct3D 12 et Vulkan. Il propose plusieurs activités, mais pour la performance, la plus importante est le GPU Trace Profiler, qui capture une vue détaillée de l’exécution du GPU sur une frame (ou un court intervalle). NVIDIA le décrit comme un « outil pour analyser les scénarios limités par le GPU », en retraçant l’exécution des shaders sur les Streaming Multiprocessors (SM) et en identifiant les opportunités de recouvrement entre graphisme et calcul, alias async compute.

La nuance est importante, car la Graphics Capture sert à figer une frame pour inspecter ressources, état de pipeline ou ordre de dessin, tandis que GPU Trace Profiler vise l’analyse de performance. Il expose l’activité des files GPU — graphiques/direct/3D, compute et copie —, la synchronisation, le timing, le profilage au niveau shader, ainsi qu’un éventail de métriques temporelles pour déterminer si la charge est limitée par l’occupation, la bande passante mémoire, la divergence ou un manque de recouvrement entre files GPU.

Les versions récentes d’Nsight Graphics ont nettement renforcé l’intérêt de GPU Trace Profiler pour l’analyse de jeux. Le Shader Profiler intègre désormais un Flame Graph et, dans les applications D3D12, Nsight peut afficher les charges créées par NGX, incluant les traitements liés au NVIDIA DLSS et autres SDK NVIDIA. Dans les faits, l’outil devient bien plus pertinent pour profiler les jeux PC modernes qui utilisent ray tracing et mises à l’échelle/débruitage temporels dopés au machine learning.

Plusieurs outils de profilage et de débogage GPU coexistent, chacun avec ses forces et cas d’usage. On peut citer RenderDoc, débogueur d’image open source très répandu pour inspecter une frame en détail, et PIX, la suite de Microsoft pour les applications DirectX. À leurs côtés, NVIDIA Nsight Graphics propose des capacités proches mais taillées pour le hardware NVIDIA. Tous sont utiles, mais nous nous concentrons ici sur Nsight Graphics car la machine de test utilise un GPU NVIDIA, et Nsight offre l’intégration, les métriques et les fonctions de profilage les plus profondes pour ce hardware, ce qui en fait le choix le plus adapté pour cette analyse.

La méthodologie de profilage: Peak-Performance-Percentage

Les discussions sur la performance d’un jeu partent souvent d’idées reçues. On voit un graphe de frame time brouillon, on note que le ray tracing est activé et on conclut que « l’RT est le goulot ». Ou on repère une lourde passe de post-traitement et on l’accuse de tout. La méthode Peak-Performance-Percentage fait l’inverse: elle part des métriques d’utilisation du GPU et demande quelles unités sont les plus sollicitées, à quel point elles s’approchent de leur débit maximal (le Speed Of Light ou SOL) et si la charge est vraiment contrainte par ces limites.

Le principe est simple: d’abord, identifier la charge GPU coûteuse. Ensuite, examiner les données de débit haut niveau pour trouver l’unité la plus susceptible de limiter la performance. Si aucune unité n’atteint un pourcentage élevé (défini comme >80% du SOL dans la méthode PPA de NVIDIA), l’objectif est d’améliorer l’utilisation. Si une unité s’approche de sa limite, l’objectif devient de réduire le travail sur cette unité ou de restructurer la charge pour diminuer la pression. C’est une approche plus disciplinée que de juger sur la complexité visuelle.

Pour ce guide, la méthode se marie naturellement avec Nsight Graphics. GPU Trace Profiler donne la chronologie et la vue des files. Top-Level Triage fournit un premier tri global. Les Shader Pipelines identifient les charges shader les plus coûteuses dans une plage donnée. Les sections Shader Pipelines et Hotspots permettent ensuite d’entrer dans ces shaders pour comprendre si les soucis dominants tiennent à la divergence de contrôle, au mix d’instructions, aux dépendances mémoire ou à la taille pure de la charge. La documentation NVIDIA positionne clairement le Shader Profiler comme l’outil pour expliquer pourquoi les shaders stagnent et comment récupérer de la performance sur des charges limitées par les SM.

Configuration de test et stratégie de capture GPU

Nous avons capturé deux frames de Cyberpunk 2077 sur une machine aux caractéristiques suivantes:

• CPU: Intel Core i7-14700K;
• RAM: 32 Go DDR5-7000 CL34;
• Stockage: SSD NVMe PCIe 4.0 de 2 To;
• GPU: NVIDIA GeForce RTX 4090 24 Go;
• Système d’exploitation: Windows 11 25H2;
• Tous les firmwares, pilotes, BIOS et mises à jour OS étaient à jour avant les tests.

Les deux captures (traces) ont été effectuées dans la même scène à une définition de 2560×1440 (1440p), avec deux scénarios distincts:

• Préréglage « Élevé » en raster uniquement
• Préréglage « Élevé » avec path tracing (RT Overdrive) et DLSS Ray Reconstruction en mode Qualité (upscaling et débruitage combinés des effets path tracés)

Ce duo crée une progression claire en complexité de rendu. La frame raster met en avant le pipeline graphique traditionnel, alors que la frame path tracée ajoute une charge bien plus lourde et le débruitage/reconstruction temporelle du DLSS Ray Reconstruction.

Comment profiler un jeu avec Nsight Graphics

Une fois la logique d’Nsight Graphics comprise, le flux de travail devient direct.

1. Lancer l’app NVIDIA et autoriser l’accès aux compteurs de performance du GPU

Ouvrez NVIDIA App, puis allez dans System → Advanced et réglez Manage GPU Performance Counters sur All users. Nsight pourra alors accéder aux compteurs du GPU sans droits administrateur sous Windows:

2. Lancer Nsight Graphics et créer un nouveau projet

Ouvrez Nsight Graphics et créez un nouveau projet via le menu File → New Project… en haut à gauche:

3. Régler la capture et lancer le jeu via Nsight

Dans les réglages de capture de la fenêtre Start Activity, choisissez GPU Trace Profiler comme activité, car il sert à l’analyse de performance plutôt qu’au débogage. Puis, renseignez le chemin direct de l’exécutable du jeu dans Application Executable et non un lanceur indirect. Configurez ensuite comme suit:

• Timeline Metrics : sélectionnez Top-Level Triage
• Enable Real-Time Shader Profiler
• Laissez les options avancées (comme Multi-Pass Metrics) désactivées pour une capture propre

Avec ces réglages, vous récoltez à la fois des métriques d’utilisation haut niveau et des informations de profilage au niveau shader.

Cliquez ensuite sur Launch GPU Trace en bas à droite pour lancer le jeu via Nsight Graphics. L’outil s’injecte alors dans le processus et surveille en temps réel l’activité GPU:

4. Se placer dans une scène de test stable

Une fois dans le jeu:

• Rejoignez une scène représentative (ex.: quartier urbain dense)
• Figez la caméra
• Patientez quelques secondes pour:
  • terminer la compilation des shaders
  • stabiliser la charge GPU

Vérifiez qu’Nsight Graphics est prêt à capturer en confirmant la présence du menu en haut à gauche: Data Collection: Ready (capture hotkey):

5. Capturer une frame (F11)

Appuyez sur F11 (raccourci par défaut) pour déclencher une capture avec GPU Trace Profiler.

Nsight va ensuite:

• Enregistrer les timestamps et métriques GPU
• Capturer les données d’exécution des shaders
• Générer une chronologie détaillée de la frame

Revenez sur Nsight Graphics avec Alt+Tab: la frame capturée apparaît dans une fenêtre. Vous pouvez la renommer, puis choisir de la fermer ou de l’ouvrir dans Nsight:

6. Ouvrir le rapport GPU Trace Profiler

Après ouverture de la trace dans Nsight, vous arrivez sur la vue Timeline principale, avec notamment:

• Graphics queue
• Compute queue
• Métriques d’utilisation par unité GPU
• Shader Pipelines
• Flame Graph
• Hotspots

GPU Trace Profiler utilise des timestamps pour bâtir une chronologie précise des draw/dispatch et de leurs durées d’exécution:

Dans la section suivante, nous interprétons les résultats des deux traces de Cyberpunk 2077 évoquées plus haut.

Étude de cas: Cyberpunk 2077

Pour mettre la méthode en pratique, ils ont capturé et analysé deux traces représentatives de Cyberpunk 2077 avec le GPU Trace Profiler d’NVIDIA Nsight Graphics. La première montre une charge raster classique (1440p préréglage Élevé sans ray/path tracing), pour offrir une base sur la structure et le rendu d’une frame AAA moderne (ici le REDengine 4 de CD Projekt RED). La seconde bascule sur la configuration la plus exigeante du jeu — path tracing (RT Overdrive) avec DLSS Ray Reconstruction en mode Qualité — pour observer l’évolution de la charge lorsque ray tracing avancé et techniques de rendu neuronales entrent en scène. La comparaison met en lumière la montée en complexité des charges GPU et la façon dont Nsight Graphics révèle les goulots, des pipelines raster aux rendus hybrides mêlant compute et ray tracing.

Note importante: l’analyse a été réalisée sur la version commerciale de Cyberpunk 2077, et non une build développeur. Par conséquent, nous n’avions pas accès aux marqueurs internes nommant explicitement les passes (G-Buffer, illumination globale, AO, SSR, tone mapping, post-traitements). Quand l’application les fournit, Nsight Graphics peut les afficher, ce qui éclaire la structure de la frame, mais ils sont en général réservés aux builds instrumentées. Ici, nous nous sommes appuyés sur GPU Trace Profiler, Shader Pipelines et Hotspots pour déduire la structure et isoler les points chauds.

Trace d’une frame raster

Pour illustrer l’usage d’Nsight Graphics, ils ont d’abord capturé et analysé une frame de Cyberpunk 2077 en 1440p préréglage Élevé, avec tous les effets ray/path tracing désactivés. C’est une base propre pour comprendre la structure d’une frame raster moderne et, surtout, ce qui limite sa performance sur les GPU actuels.

À première vue, on s’attendrait à une domination de la soumission géométrie et du pixel shading. Nsight Graphics brosse toutefois un tableau plus nuancé.

Structure de la frame et répartition des charges

En combinant la chronologie de GPU Trace Profiler et les exports par file (graphics et compute avec usage marqué du calcul asynchrone), on reconstruit la frame en grandes régions. Sans marqueurs développeur, on ne peut pas tout nommer précisément, mais la structure reste lisible:

[Initialisation / ombres / pré‑pass profondeur]
↓
[Géométrie principale / G‑buffer (raster riche en draw)]
↓
[Éclairage et traitements de scène tardifs]
↓
[Éclairage indirect, effets en écran (réflexions écran, AO, etc.)]
↓
[Anti-aliasing temporel, post-traitements, tone mapping]
↓
[UI / HUD]

Point clé: la frame est très chargée en fin de pipeline, la plus grosse région — tardive — pesant environ 48,5% du temps GPU en file, loin devant les phases riches en géométrie. Cette zone n’est pas dominée par les draw calls; on y trouve surtout de nombreux dispatch compute, barrières et opérations de gestion mémoire spécifiques à Direct3D 12.

Autrement évoqué, la partie la plus coûteuse de cette frame raster n’est pas le dessin de la scène, mais le traitement de l’éclairage une fois la géométrie rendue. Logique pour le REDengine 4 — comme pour la majorité des moteurs AAA actuels — basé sur le rendu différé.

Les données DXIL de Shader Pipelines confirment ce diagnostic.

Sur la frame sélectionnée, la répartition est la suivante:

• Compute shaders: ~68,8% des exemplaires
• Pixel shaders: ~26,6%
• Vertex shaders: ~3,7%

Plus marquant encore, un seul compute shader pèse près de 29,8% de tous les exemplaires, devenant la charge dominante. Étonnant pour un pipeline raster traditionnel: on voit clairement que les traitements d’éclairage pilotés par le compute occupent l’essentiel du temps.

Analyse des Hotspots

La section Hotspots du Shader Profiler apporte l’indice décisif: le compute shader dominant se concentre sur quelques instructions clés, notamment:

• des accès texture sampleLevel
• des instructions dépendantes de la mémoire à forte latence

Les principales causes de blocage sont:

• Long Scoreboard (LGSB)
• TEX Throttle

D’après la documentation NVIDIA, un Long Scoreboard survient lorsqu’un warp (groupe de 32 threads exécutant la même instruction) attend des données mémoire/texture, tandis que TEX Throttle signale une pression sur le pipeline de texturing.

Le message est limpide: le shader n’est pas ralenti par trop de calculs, mais parce qu’il attend des données, ce qui colle parfaitement avec le diagnostic global.

Analyse de trace

La Trace Analysis d’Nsight relève les problèmes majeurs suivants:

• L2 Limited
• Warp Stalled by L1TEX Long Scoreboard
• Warp Stalled by TEX Throttle

Dans la grille de lecture PPA de NVIDIA, cette combinaison signe une charge limitée par le sous-système mémoire plutôt que le débit de calcul. Plus précisément:

• L2 Limited → pression sur le cache L2 du GPU
• Long Scoreboard → warps en attente de données mémoire/texture
• TEX Throttle → saturation du pipeline de sampling texture, lié au cache L1/Texture présent sur chaque SM

Repenser la « performance raster »

Cette étude rappelle une réalité souvent ignorée des performances GPU modernes:

La rasterisation seule ne dicte plus le coût d’une frame, car même en raster pur:

• La majorité du temps GPU se situe après la soumission de géométrie
• La charge dominante est un traitement d’éclairage piloté par le compute
• La performance dépend du mouvement des données et du comportement mémoire, pas seulement des opérations arithmétiques

C’est pourquoi des indicateurs comme les téraflops, le nombre d’unités de calcul ou même la bande passante brute ne décrivent pas complètement les performances en jeu réelles.

Un GPU moderne est une machine très complexe et fortement pipelineée où caches, latence mémoire, localité des données et ordonnancement des warps jouent un rôle déterminant dans le rendu.

Comme le montre la documentation NVIDIA, des stalls comme Long Scoreboard proviennent souvent de l’attente de lectures mémoire/texture, non d’un manque de puissance de calcul. En clair, un GPU peut afficher un débit théorique colossal et sous-performer si ses shaders manquent de données — c’est exactement ce que révèle ce capture de Cyberpunk 2077.

Trace d’une frame path tracée (DLSS RR Qualité)

Le passage au path tracing recompose profondément la charge GPU, faisant grimper le coût de frame de ~5,9 ms (raster) à environ ~11 ms dans cette capture, malgré le passage combiné d’upscaling et de débruitage du DLSS Ray Reconstruction. Plus important, il change où le temps est dépensé. Plutôt qu’un « gros bloc ray tracing », la frame devient un assemblage hybride où raster, parcours de rayons (intersections rayon/boîte et rayon/triangle) et reconstruction/débruitage temporels basés sur le compute sont étroitement imbriqués.

Malgré la présence d’appels DispatchRays explicites, les Shader Pipelines et les Hotspots indiquent une frame encore très orientée compute, la majorité du temps shader se concentrant sur l’éclairage, la reconstruction temporelle et le débruitage. Les shaders les plus coûteux restent des compute en grille 2D, signe que, même en path tracing, une grande part du temps sert à filtrer, débruiter et assembler l’image plutôt qu’à tracer des rayons.

La Trace Analysis d’Nsight précise le goulot: la frame est avant tout limitée par le L2 et le chemin mémoire, avec des stalls dominants comme Long Scoreboard et TEX Throttle, indiquant des warps fréquemment en attente de données via la hiérarchie mémoire/cache. En d’autres termes, le facteur limitant n’est pas le débit brut des RT Cores en traversée rayon/boîte, mais la capacité du GPU à alimenter efficacement ses unités via la mémoire. C’est cohérent avec les recommandations de profilage: des charges dominées par la latence et la bande passante mémoire n’exploitent pas toujours pleinement le calcul disponible, malgré un débit théorique élevé.

Conséquence importante: les performances en ray tracing ne progressent pas linéairement avec le débit des RT Cores. Même en doublant les taux d’intersection rayon/triangle, les performances réelles resteraient bornées par la localité cache, la latence mémoire et la divergence. Le ray tracing — et plus encore le path tracing — pose autant un problème de mouvement de données que de traversée.

En pratique, cette capture montre que le rendu path tracé moderne s’apparente à un pipeline borné par le compute et la mémoire, où ray tracing, reconstruction temporelle et débruitage forment un système étroitement couplé, et où l’efficacité du sous-système mémoire est décisive.

Au final

NVIDIA Nsight Graphics fait partie des meilleurs outils pour analyser en profondeur les performances d’un GPU NVIDIA dans les jeux DX12 et Vulkan modernes, et GPU Trace Profiler en est la version maîtresse. Il fournit une lecture hardware de la frame, dévoile l’activité des files GPU et leur synchronisation, et — avec le profilage shader en temps réel — ouvre l’accès à Shader Pipelines, Hotspots et même à l’analyse du code shader au niveau intermédiaire (DXIL de Microsoft).

La grande leçon, c’est qu’un profilage utile commence par le tri, pas par l’intuition. Capturez une scène stable, analysez d’abord la chronologie globale, repérez les charges dominantes, puis plongez dans les shaders. C’est le cœur de la méthode Peak-Performance-Percentage de NVIDIA, et une base solide pour comprendre pourquoi une frame coûte cher à rendre sur le GPU.

Cyberpunk 2077 est un cas d’école car il couvre tout le spectre: raster pur, ray tracing hybride, path tracing, avec l’option d’ajouter un upscaling/débruitage temporels via le machine learning. Bien utilisé, Nsight Graphics rend ces transitions visibles d’une manière qu’un simple overlay ne peut pas offrir. Et c’est tout l’intérêt: transformer le comportement et la performance du GPU en faits observables plutôt qu’en suppositions.