Débogage sur coeurs graphiques Intel®

A condition de maîtriser quelques principes de base et de savoir manier certains des outils qui sont à la disposition de la communauté des développeurs, le débogage sur cœurs graphiques Intel® peut être très simple. Toutes les méthodes abordées dans le document proposé ici sont faciles à mettre en œuvre et rendent cette opération aussi simple qu’elle peut l’être sur d’autres composants graphiques du marché.

D’abord, il faut bien comprendre qu’Intel propose deux types de solutions graphiques intégrées : les cœurs graphiques GMA (Graphics Media Accelerator) de série 3000 et de série X3000. De même que pour leurs homologues GMA 900 plus anciens, les cœurs graphiques GMA de série 3000 réalisent toujours les opérations TnL (Transform & Lighting) de manière « logicielle » (c’est-à-dire sur le processeur) par l’entremise du pipeline PSGP (Processor Specific Graphics Pipeline) de la couche HAL (Hardware Abstraction Layer) de Direct3D*. Les modèles de série X3000, quant à eux, les effectuent tantôt de manière « logicielle », tantôt de manière « matérielle » (sur le GPU), cela en fonction des impératifs de charge. Certaines charges telles que celles qui s’appuient sur DirectX* 8 ou antérieur, sont très bien adaptées à un traitement par ce pipeline du processeur par rapport au pipeline DirectX 9 du moteur de la série X3000.

Depuis plusieurs années, l’un des outils les plus intéressants dans ce contexte est l’utilitaire 3D-Analyze* (voir figure 1).

Figure 1. Utilitaire 3D-Analyze.

L’un des premiers contrôles qu’effectuent les ingénieurs d’Intel lorsqu’ils testent une application qui refuse de fonctionner sur les cœurs graphiques de série 3000 consiste à vérifier si celle-ci est capable de gérer les opérations TnL de manière logicielle. Il est en effet possible qu’elle prévoie leur traitement matériel, alors que ces moteurs graphiques ne gèrent pas ce type de traitement. L’utilitaire 3D-Analyze possède à ce titre de nombreuses fonctions très utiles, dont l’une lui permet de « leurrer » (spoof) une application pour lui faire croire que le sous-système graphique est capable de gérer les opérations TnL. Pour déterminer si le problème vient de ce que l’application ne reconnaît pas les opérations TnL logicielles, il suffit en l’occurrence de cocher l’option « emulate HW TnL caps » de l’outil (cf. figure 1, en haut) et d’exécuter l’application directement à partir de celui-ci. Si l’application fonctionne normalement avec cette option, c’est a priori que le problème est lié à la prise en charge des opérations TnL logicielles.

On peut également effectuer un autre type de contrôle, à savoir en forçant le traitement logiciel des opérations TnL dans 3D-Analyze sur une configuration équipée par ailleurs d’une carte graphique de milieu de gamme, aux performances équivalentes. Dans ce cas, si l’application continue de se bloquer, c’est que le problème n’est pas lié au cœur graphique Intel, ni à son pilote, mais, là encore, à la prise en charge des opérations TnL logicielle. Dans le cas contraire, autrement dit si l’application fonctionne correctement, le problème peut provenir d’un bogue du pilote Intel, à signaler alors sur le forum correspondant et à élucider sur le site du support pour les cœurs graphiques Intel®.

3D-Analyze propose aussi une option « debug logging », qui crée un fichier journal dans le dossier de l’application en test. Si, dans ce fichier, figurent les mentions D3DCREATE_PUREDEVICE ou D3DCREATE_HARDWARE_VERTEXPROCESSING sans que le D3DCREATE_SOFTWARE_VERTEXPROCESSING ordinal ne soit déclaré, c’est que l’application ne fonctionne pas sur les cœurs graphiques Intel GMA série 3000. Autrement dit, le développeur applicatif du programme Direct3D* ne gère pas le traitement logiciel des vertex.

La troisième méthode pour déterminer si l’application décide d’elle-même, dans certains cas, de ne pas exploiter le cœur graphique Intel consiste à se servir de 3D-Analyze pour remplacer les identifiants Vendor et Device par ceux d’une carte graphique dont on sait qu’elle est compatible. Cet outil propose en effet deux champs (VendorID et DeviceID) qui permettent de forcer ce paramétrage. A ce titre, la lecture du de l’Intel Software Network qui aborde les « Idées fausse sur les cœurs graphiques Intel » devrait dissiper les doutes que pourraient avoir les développeurs sur les capacités de ces composants.

Si vous pensez que l’application est limitée au niveau du débit de remplissage (fill rate), sachez que l’outil permet aussi, grâce à son option « disable textures », de désactiver les textures. Cette situation est plus fréquente pour les bancs d’essai que pour les jeux, mais l’outil n’en permet pas moins de s’en assurer dans le second cas si l’on a des doutes. Le choix de cette option revient à supprimer les textures de la scène concernée, ce qui réduit le temps système correspondant au remplissage.

Si l’on craint par ailleurs que l’application ne rencontre un problème de débit pour le nuanceur de pixels (pixel shader), on peut se servir là encore de 3D-Analyze pour forcer l’application à passer par défaut à une version plus ancienne (1.1, par exemple).

Il s’agit là d’une technique très utilisée pour le débogage des nuanceurs de pixels sur cœurs graphiques Intel.

Il faut d’abord comprendre ce que gère le cœur graphique considéré. Pour ce faire, on utilise l’outil DXCaps Viewer que comporte le SDK DirectX (dans le dossier des utilitaires), ce qui permet de comprendre plus facilement les messages de débogage. Les capacités du composant concerné (caps) se trouvent alors dans <Composant> > D3D Device Types > HAL > Caps. Pour obtenir des informations détaillées sur une capacité, on consultera la documentation du SDK DirectX.

Pour corriger les bogues Direct3D, l’une des techniques les plus utiles consiste d’abord à lancer la version de débogage de Direct3D* (Debug Runtime), en s’assurant au préalable que la version la plus récente du SDK DirectX 9.0 est installée sur le système (téléchargement Microsoft gratuit). Ce SDK est en général mis à jour tous les deux mois. Cette activation se réalise par le biais du panneau de configuration DirectX, situé dans le dossier Utilities du kit.

En n’oubliant pas de repasser en mode Retail après les tests, on peut alors employer un outil comme DebugView* ou DebugMon* pour prendre connaissance des messages d’erreur et ainsi déterminer a priori la raison pour laquelle une application se bloque. En revanche, il ne faut pas utiliser 3D-Analyze ni FRAPS* en mode débogage, ni changer de version de Runtime pendant que tournent ces outils, car cela susciterait un conflit avec leur fonctionnement.

A noter que PIX ne fonctionne qu’avec les applications Direct3D ; pour leurs homologues OpenGL*, on utilisera par exemple glIntercept*. Dans le cadre de cet article, nous nous limiterons à l’outil de débogage de Microsoft. Il s’agit d’un instrument très intéressant pour l’analyse des problèmes de performances, car il permet une analyse jusqu’au niveau d’une trame ou d’un flux de trames. De plus, comme c’est le débogueur de nuanceurs DirectX privilégié, connaître ses particularités ne peut qu’être utile à tous les développeurs.

La figure 2 reprend l’écran de paramétrage initial pour déboguer une application sous PIX.

Figure 2. Microsoft* PIX.

La vue avancée donne accès à des options supplémentaires. Les constantes du nuanceur et les blocages sur celles-ci fournissent une bonne indication de ce qui bride les performances. C’est d’ailleurs également le cas pour les appels par trame de SetRenderTarget. Si celui-ci est appelé plusieurs fois par trame et s’il y a plus de dix appels par trame, l’incidence sur les performances des cœurs graphiques Intel risque en effet d’être importante.

La meilleure méthode pour obtenir des informations est de chiffrer des pertes d’images isolées ou de flux complets (frame drops) et de les publier sur http://software.intel.com/en-us/forums/. Les exemples PIX d’images de flux sont préférables pour un débogage post-mortem. L’extension pour les résultats PIX d’images isolées est la même que pour les flux complets, à savoir .PIXRun. De plus, leur transmission dans un format chiffré représente la meilleure méthode pour communiquer les problèmes relevés sous PIX à la communauté des développeurs sur architecture Intel. N’oubliez pas, en revanche, que les exemples de flux complets issus de PIX sont souvent extrêmement volumineux et qu’il vaut donc mieux ne retenir et n’enregistrer que les parties directement concernées.

Il est par ailleurs conseillé de toujours utiliser la version la plus récente de PIX, qui est d’ailleurs mis à jour régulièrement. Celui-ci propose également une fonction de capture d’une seule trame (en phase de rendu) (« single-frame capture »). Sélectionner l’outil (PIXWIN) est une astuce qu’emploient de nombreux développeurs pour supprimer de l’exemple le traitement sans rendu, par le biais de l’option de ligne de commande « –playstandalone <nom>.pixrun ». Cette astuce est largement plus adaptée aux charges volumineuses (bancs d’essai et jeu), mais elle fonctionne aussi très bien pour de plus petites.

Le fait de fournir un fichier de flux est très utile pour déterminer pourquoi une application ne fonctionne pas, mais les captures d’images sont précieuses elles aussi. Si le flux enregistré fonctionne sur un GPU d’un autre fabricant, c’est peut-être que le pilote comporte un bug, auquel cas l’équipe chargée des pilotes graphiques chez Intel se penchera immédiatement sur la question et le bogue en question sera corrigé dans une prochaine version du pilote concerné. Pour transmettre une capture de flux, il suffit de sélectionner « Call replayable stream ».

Une dernière technique d’optimisation consiste à utiliser des bandes de triangles (triangle strips) au lieu de listes de triangles, afin de réduire le temps système VB, ce qui s’effectue en général à l’aide d’outils de génération de contenu comme Maya* ou 3D Studio Max*. Il s’agit d’ailleurs là d’une astuce d’optimisation du code qui est valable pour tous les sous-systèmes graphiques.

L’utilisation judicieuse des outils mentionnés dans cet article ne peut être qu’extrêmement profitable pour le débogage ou le développement logiciel sur toutes les plates-formes équipées d’un coprocesseur graphique intégré. De plus, le fait de maîtriser les particularités des cœurs graphiques Intel vous permettra d’élargir votre clientèle au-delà des seuls utilisateurs de solutions graphiques de très haut de gamme.

Chuck De Sylva est Software Applications Engineering Manager à l’Intel Software & Solutions Group. Lui et sont équipe sont chargés de l’optimisation des performances des logiciels grand public et jeux de pointe pour les PC de bureau d’architecture Intel. A son précédent poste chez Intel, il développait des pilotes. Il a ainsi participé à l’élaboration et au déploiement des premiers pilotes pour périphériques USB et AGP (GART) ainsi que pour les premiers sous-systèmes graphiques d’Intel (i740/810[e]).