Passez toujours par votre contact des relations avec les développeurs / DPM avant de faire appel à l’ATG. Il fournit des ressources susceptibles de résoudre les problèmes avant une escalade.
Étape préalable : effectuez d’abord l’enquête sur les threads
Avant de faire appel à l’ATG, parcourez Trouver les problèmes de threads. Ce sont les mêmes premières étapes que l’ATG effectue au début d’une collaboration, et c’est vous qui connaissez le mieux votre propre code et le comportement attendu : les points chauds ressortent généralement plus vite lorsque votre équipe enquête en premier. Coordonnez-vous ensuite avec votre Developer Partner Manager (DPM). Il établit la portée de la collaboration et agit comme votre agent de liaison.Renseignements idéaux à fournir
Remettez les éléments suivants à l’ATG plusieurs jours à l’avance afin que tout problème puisse être résolu avant la date officielle de début :- Un build de profilage fonctionnel du titre (avec des marqueurs PIX)
- Les symboles (PDB) de chaque exécutable et DLL du build
- Au moins cinq comptes d’utilisateur dans le bac à sable (sandbox) correspondant, si nécessaire pour exécuter le titre
- La liste des zones problématiques et les commandes de débogage pour accéder à chacune
- La liste des zones connues comme respectant le budget, qui serviront de références
- La liste des problèmes déjà connus dont la résolution est en cours
- Des vues d’ensemble de l’architecture de haut niveau (affinité de threads attendue, priorités, budgets)
- Une personne-ressource (nom + courriel) dans l’équipe de développement pour les questions de suivi
Build fonctionnel du titre
Un build fonctionnel permet à l’ATG d’effectuer ses propres captures avec les options les plus pertinentes et d’itérer sur des captures ciblées en fonction de ce que les captures précédentes révèlent. Fournissez les symboles correspondants pour tous les exécutables et toutes les DLL. Pour les comptes de test du bac à sable, générez-les vous-même dans Partner Center ou demandez-les à votre DPM si vous n’y avez pas accès directement.Zones problématiques et zones de référence
Fournissez des commandes de débogage ou des étapes reproductibles qui mènent directement aux points chauds connus. Comme l’ATG n’a aucune visibilité sur les budgets de votre titre, jumeler un point chaud avec une zone qui respecte le budget lui donne une référence essentielle pour la comparaison.Divers
- Énumérez les problèmes déjà connus afin que l’ATG ne refasse pas le même travail.
- Fournissez une personne-ressource pour les questions pendant l’enquête.
- Incluez des vues d’ensemble de l’architecture et des budgets (affinité de threads, priorités, pools de mémoire).
Captures
Si vous ne pouvez pas fournir un build fonctionnel, fournissez des captures PIX des zones problématiques connues, accompagnées des symboles correspondants.Durée des captures
- Durée idéale : 15 à 30 secondes.
- Pour les pics, incluez plusieurs secondes avant et après le pic.
- Utilisez Capture Title Startup si vous devez tracer le comportement au lancement.
- Effectuez toutes les captures sur un build empaqueté.
Options de capture PIX Timing recommandées
Paramètres minimaux :- File Accesses : nécessaire pour l’analyse des modèles de chargement.
- Memory : au moins les trois premières options pour l’analyse des modèles d’allocation.
- GPU timings : offert seulement lorsque le titre est démarré avec le pilote graphique instrumenté (défini dans le code ou remplacé au moyen des paramètres de console de XBOX Manager).
Allocateurs personnalisés
Si votre titre utilise un allocateur de mémoire personnalisé, marquez-le à l’aide des événements d’allocateur personnalisé du GDK : Activez Custom allocator events dans les options de capture Timing.Attendez la fin du traitement des symboles
Avant d’enregistrer une capture, laissez PIX terminer le traitement des symboles (une barre de progression s’affiche dans le coin supérieur droit). Enregistrer avant la fin déclenche un avertissement et produit une capture plus difficile à partager.Événements PIX, marqueurs et noms de threads
Les captures Timing nécessitent des événements / marqueurs PIX suffisamment granulaires pour déterminer où le temps est passé. La rigueur est importante :- Surveillez les paires
PIXBeginEvent/PIXEndEventnon appariées : elles invalident les captures. PrivilégiezPIXScopedEvent, qui se ferme lorsqu’il sort de la portée. - Utilisez la version CHAR (ANSI) des événements PIX, qui utilise moitié moins de mémoire que la variante WCHAR, sauf si vous avez besoin du DBCS.
- Utilisez des marqueurs à granularité fine (jusqu’au niveau de la mise à jour de chaque entité) afin de pouvoir localiser les points chauds.
- Donnez aux événements des noms descriptifs, y compris les noms des ressources lorsque c’est possible.
- Encadrez les boucles d’attente active avec des événements afin que l’ATG puisse mesurer le temps d’inactivité / de blocage.
- Ajoutez des événements de haut niveau pour les grandes phases : simulation, rendu, workers, diffusion en continu.
- Nommez chaque thread créé par le titre avec
SetThreadDescription. PIX et Visual Studio affichent tous deux ces noms, et votre titre peut les relire au moyen deGetThreadDescription.
Résumé
Des données de performances de qualité sont ce qui rend une collaboration productive. Les premières choses que l’ATG demande sont les captures et les métadonnées décrites ci-dessus : les préparer à l’avance accélère toute la collaboration. En cas de doute, privilégiez plus de données.Documentation d’API connexe
- Référence de l’API PIX3 :
PIXBeginEvent/PIXEndEvent/PIXScopedEvent/PIXRecordMemoryAllocationEvent/PIXRecordMemoryFreeEvent.