Accueil Nos publications Blog DirectX : Débogage graphique avec Windows Phone 8.1

DirectX : Débogage graphique avec Windows Phone 8.1

DirectX Avec Windows Phone 8.1, Microsoft a fait un grand bond en avant dans le rapprochement entre Windows et Windows Phone.

Et DirectX n’est pas en reste de ce côté, avec l’arrivée de Direct2D, DirectWrite, WIC, certaines nouveautés de DirectX 11.2. Je parlerai de ces sujets dans d’autres articles dans pas longtemps.

Aujourd’hui je vais parler de l’outil de débogage graphique, qui a fait son apparition dans Visual Studio 2012 avec l’arrivée de Windows 8. Mais malheureusement il était limité jusqu’à aujourd’hui aux Windows Store Apps. Tout ceci n’est que du passé puisque l’on va voir que le SDK Windows Phone 8.1 et Visual studio 2013 Update 2 comble ce manque.

Mise en place

Tout d’abord pour mettre à jour Visual Studio 2013 avec l’update 2 RC, il suffit de se rendre ici

Pour ne pas nous éparpiller, nous allons partir d’un projet existant pour faire la démo. J’ai choisi de prendre le marble maze game, qui est disponible dans sa version Windows Phone 8.1 ici

Une fois la solution ouverte, il est possible de lancer une session de débogage graphique, soit grâce à l’icone debug dans la barre d’outils, soit en appuyant sur ALT+F5, soit en allant dans le menu Déboguer -> Graphics -> Démarrer les diagnostics.
debug_menu

Si le débogueur graphique est attaché correctement vous devriez apercevoir ce message en haut de l’écran du téléphone :
debug_header

Attention toutefois avec Windows Phone, il n’est possible que d’ouvrir une seule session de diagnostique en même temps. Si vous essayez d’en ouvrir plusieurs, vous obtiendrez ce joli message :
error_multiple

Rien de dramatique, et le message est assez explicite, il suffit de ne garder qu’un fichier *.vsglog ouvert en même temps.

Capture de frames

Maintenant que la session de débogage est lancée, il est possible de capturer des frames, afin de les décortiquer par la suite. Pour commencer il faut définir le nombre de frames qui seront capturées à chaque demande.

Il suffit pour cela de choisir la valeur voulue dans la barre d’outils grâce à cette liste déroulante captured_frames.

Dans notre cas nous allons choisir 1 seule frame par capture. Mais pour observer ce qu’il se passe dans le cas d’une animation, augmenter la valeur peut-être utile.

Ensuite pour déclencher la capture, comme pour démarrer la session, il y a plusieurs points d’entrée :

  • Le bouton capture_frame dans la barre d’outils
  • CTRL+F12
  • Via le menu Déboguer -> Graphics -> Capturer le frame

capture_frame_menu

Une fois les frames capturées, vous devriez avoir cet écran là :
frame_list

En bas, sont listées les frames capturées pendant la session, au centre en gros c’est la frame actuellement sélectionnée. En haut à gauche, on peut apercevoir la RenderTargetView dans laquelle a été rendu la frame, ainsi que l’action qui appelé le rendu de cette frame. Ce qui est pratique, c’est que les éléments en bleu sont cliquables, et le lien nous envoi vers les propriétés du descripteur de l’objet au moment du rendu.
rtv_action

Liste des événements

Après avoir sélectionné une frame, il est possible d’obtenir plusieurs types d’informations grâce à différentes fenêtres (disponible via le menu : Déboguer -> Graphics). L’une d’entre elles est la liste des événements.

Grâce à cette fenêtre, tous les événements de rendu de la frame sont listés. Pour les événements Draw, on a même le détail de la configuration du Pipeline( et l’on peut même savoir si la valeur a été modifié par cette frame ou “hérité” d’une frame précédente ) comme on peut le voir ici :
event_list

Table des objets

Cette fenêtre va permettre d’avoir la liste des ressources (Buffers, Shaders, Textures, States, etc …) actuellement allouées.

Il faut d’abord sélectionner un événement dans la fenêtre précédente, puis la liste apparaitra avec une colonne Actif, qui indique si la ressource est utilisée par l’événement sélectionné, ainsi que la taille occupée en mémoire.

resources_table

Etapes de canalisation

Cet écran représente graphiquement les différentes étapes du pipeline :
Pipeline

Ici les quatre images correspondent à :

  • Les données d’entrée brutes des sommets
  • La sortie du Nuanceur de sommets (vertex shader)
  • La sortie du Nuanceur de pixels (pixel shader)
  • Le résultat final de l’événement de rendu

La chose très pratique également, c’est qu’il est possible grâce à l’icone play de déboguer le HLSL. Oui, oui, rentrer en mode pas à pas et regarder la valeur des variables !
hlsl_debug

Historique des pixels

Après avoir sélectionné un pixel de la frame dans la fenêtre principale du fichier de diagnostic, la fenêtre historique des pixels s’ouvrira. Dans cette dernière, on pourra voir la valeur RGBA finale du pixel ainsi, que toutes les valeurs et les étapes de rendu par lesquelles il est passé.
pixel_history

Et comme dans la fenêtre sur les étapes de canalisation, il est possible de lancer le débogueur HLSL.

Analyse des frames

Nouveauté de l’update 2 de Visual Studio 2013, il est maintenant possible d’obtenir le diagnostique d’une frame en utilisant l’onglet Analyse des frames.

Après avoir lancer l’analyse, on se retrouve avec l’écran suivant :
frame_analysis

Pour chaque événement de rendu, l’analyse va nous donner le temps passé pour cet événement. En plus de cela, elle va également nous donner le temps qui se serait écoulé pendant un événement avec certains paramétrages (comme l’anti-aliasing par exemple). Les deux tableaux donnent les même informations, le premier est juste plus “visuel”.

Cette analyse va permettre de voir plus rapidement les optimisations possibles.

Tous les détails sur cette analyse sont disponibles ici

Conclusion

La documentation de l’outil de débogage graphique est .

Comme on a pu le voir, même si ce n’était qu’un aperçu, cet outil est très performant. Il devient même indispensable une fois qu’on y a gouté.

Une très bonne nouvelle donc qu’il soit maintenant disponible pour Windows Phone.

A bientôt.