Passez toujours par votre contact des relations développeurs / DPM avant de solliciter l’ATG. Il fournit des ressources susceptibles de résoudre les problèmes avant l’escalade.
Préalable : mener d’abord l’investigation sur le threading
Avant de solliciter l’ATG, parcourez Recherche des problèmes de threading. 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 code et son comportement attendu : les points chauds apparaissent généralement plus vite lorsque votre équipe mène l’investigation en premier. Coordonnez-vous ensuite avec votre Developer Partner Manager (DPM). Il définit la portée de la collaboration et sert d’intermédiaire.Informations idéales à fournir
Transmettez les éléments suivants à l’ATG plusieurs jours à l’avance afin que tout problème puisse être résolu avant la date de début officielle :- Build de profilage fonctionnel du titre (avec marqueurs PIX)
- Symboles (PDB) pour chaque exécutable et DLL du build
- Au moins cinq comptes d’utilisateur dans le sandbox correspondant, si nécessaire pour exécuter le titre
- Liste des zones problématiques et des commandes de débogage permettant d’accéder directement à chacune
- Liste des zones connues comme respectant le budget pour servir de référence
- Liste des problèmes déjà connus dont la résolution est en cours
- Vues d’ensemble architecturales de haut niveau (affinité de threads attendue, priorités, budgets)
- Un point de contact (nom + adresse e-mail) dans l’équipe de développement pour les questions de suivi
Build fonctionnel du titre
Un build fonctionnel permet à l’ATG de réaliser ses propres captures avec les options les plus pertinentes et d’itérer sur des captures ciblées en fonction de ce que révèlent les captures précédentes. Fournissez les symboles correspondants pour tous les exécutables et DLL. Pour les comptes de test du sandbox, générez-les vous-même dans Partner Center ou demandez à votre DPM si vous n’y avez pas directement accès.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, associer un point chaud à une zone qui respecte le budget lui fournit une référence essentielle pour la comparaison.Divers
- Listez les problèmes déjà connus afin que l’ATG ne refasse pas le même travail.
- Fournissez un point de contact pour les questions pendant l’investigation.
- Incluez des vues d’ensemble de l’architecture / des budgets (affinité de threads, priorités, pools de mémoire).
Captures
Si vous ne pouvez pas fournir de build fonctionnel, fournissez des captures PIX des zones problématiques connues ainsi que les 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 schémas de chargement.
- Memory : au moins les trois premières options pour l’analyse des schémas d’allocation.
- GPU timings : disponible uniquement lorsque le titre est démarré avec le pilote graphique instrumenté (défini dans le code ou remplacé via les paramètres de console de XBOX Manager).
Allocateurs personnalisés
Si votre titre utilise un allocateur de mémoire personnalisé, balisez-le à l’aide des événements d’allocateur personnalisé du GDK : Activez Custom allocator events dans les options de capture Timing.Attendre le traitement des symboles
Avant d’enregistrer une capture, laissez PIX terminer le traitement des symboles (une barre de progression apparaît dans le coin supérieur droit). Un enregistrement avant la fin déclenche un avertissement et produit une capture plus difficile à partager.Événements, marqueurs et noms de threads PIX
Les captures Timing nécessitent des événements / marqueurs PIX suffisamment granulaires pour identifier où le temps est passé. La rigueur est essentielle :- Surveillez les paires
PIXBeginEvent/PIXEndEventnon appariées : elles invalident les captures. PrivilégiezPIXScopedEvent, qui se ferme à la sortie de la portée. - Utilisez la version CHAR (ANSI) des événements PIX (deux fois 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, en incluant si possible les noms des ressources.
- Encapsulez les boucles d’attente active dans 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, streaming.
- Nommez chaque thread créé par le titre avec
SetThreadDescription. PIX et Visual Studio affichent tous deux ces noms, et votre titre peut les relire viaGetThreadDescription.
Résumé
Des données de performances de qualité sont ce qui rend une collaboration productive. La première chose que demande l’ATG, ce sont les captures et métadonnées décrites ci-dessus : les préparer à l’avance accélère toute la collaboration. En cas de doute, privilégiez davantage de données.Documentation d’API associée
- Référence de l’API PIX3 :
PIXBeginEvent/PIXEndEvent/PIXScopedEvent/PIXRecordMemoryAllocationEvent/PIXRecordMemoryFreeEvent.