TP3 : Détection de bottlenecks graphiques

M2P Informatique
OGM
D. Etiemble
2006-2007
TP3 : Détection de bottlenecks graphiques
0 Introduction
Le but de ce TP est l’étude des performances des cartes graphiques via la
détection des bottlenecks.
1 Installation de l’environnement
On utilisera l’outil gDEBugger sous Windows.
Télécharger gDEBugger à l’adresse http://www.gremedy.com/ et installer le
logiciel.
Télécharger un certain nombre de « benchmarks » OpenGL.
On suggère les benchmarks OpenGL à l’adresse
http://download.nvidia.com/developer/SDK/Individual_Samples/samples.html
2
Détection de bottlenecks
gDEBugger permet successivement
- D’éliminer toutes les commandes de dessin : Si, en éliminant toutes les
commandes de dessin, les performances ne s’améliorent pas de manière
significative, alors l’application est limitée par le CPU et GPU.
- De forcer une vue 1x1 pixels. Permet d’identifier les bottlenecks liés aux
opérations de rasterization. Si, en forçant une vue à 1 seul pixel, la
performance de l’application s’améliore, alors l’application est limitée
par les operations de rastérisation.
- De forcer un rendu sans éclairage. Si la performance s’améliore,
l’application est limitée par les calculs d’éclairage
- De forcer l’utilisation de textures 2X1 (1D), 2X2 (2D), 2X2X2 (3D) and 2X2
x 6 (cube map) textures au lieu des textures définies par l’application.
Ceci assure que les données de texture restent dans le cache de textures.
Si la performance s’améliore, alors l’application est limitée par les accès
aux textures.
- De forcer l’utilisation d’un “fragment shader” très simple au lieu du
“fragment shader” défini par l’application. Si la performance s’améliore,
alors l’application est limitée par le « fragment shader ».
Utiliser gDEBugger avec un certain nombre de benchmarks pour déterminer si
ces benchmarks ont des bottlenecks liés à la performance de la carte graphique
utilisée. Si oui, déterminer la cause du bottleneck et examiner s’il est possible de
remédier à la cause du bottleneck.
1
2006