Sempre trabalhe com seu contato de relações com desenvolvedores / DPM antes de envolver o ATG. Eles fornecem recursos capazes de resolver problemas antes do escalonamento.
Etapa preliminar: execute primeiro a investigação de threading
Antes de envolver o ATG, siga o guia Como encontrar problemas de threading. Essas são as mesmas primeiras etapas que o ATG executa no início de um engajamento, e você conhece melhor seu próprio código e o comportamento esperado — os pontos críticos geralmente aparecem mais rápido quando sua equipe investiga primeiro. Em seguida, coordene com seu Developer Partner Manager (DPM). Ele define o escopo do engajamento e atua como seu intermediário.Informações ideais a fornecer
Entregue o seguinte ao ATG vários dias antes para que quaisquer problemas possam ser resolvidos antes da data oficial de início:- Build de perfil funcional do título (com marcadores do PIX)
- Símbolos (PDBs) de todos os executáveis e DLLs do build
- Pelo menos cinco contas de usuário na sandbox correspondente, se necessário para executar o título
- Lista de áreas problemáticas e comandos de depuração para ir diretamente a cada uma
- Lista de áreas que se sabe estarem dentro do orçamento para servir como referência
- Lista de problemas já conhecidos com resoluções em andamento
- Visões gerais de alto nível da arquitetura (afinidade de threads esperada, prioridades, orçamentos)
- Um ponto de contato (nome + email) na equipe de desenvolvimento para perguntas de acompanhamento
Build funcional do título
Um build funcional permite que o ATG faça as próprias capturas com as opções mais relevantes e itere em capturas focadas com base no que as capturas anteriores revelarem. Envie os símbolos correspondentes de todos os executáveis e DLLs. Para contas de teste da sandbox, gere-as você mesmo no Partner Center ou peça ao seu DPM caso não tenha acesso direto.Áreas problemáticas e de referência
Forneça comandos de depuração ou etapas reproduzíveis que levem diretamente aos pontos críticos conhecidos. Como o ATG não tem visibilidade dos orçamentos do seu título, associar um ponto crítico a uma área executada dentro do orçamento oferece a eles uma referência essencial para comparação.Diversos
- Liste os problemas já conhecidos para que o ATG não duplique o trabalho.
- Forneça um ponto de contato para perguntas durante a investigação.
- Inclua visões gerais de arquitetura / orçamento (afinidade de threads, prioridades, pools de memória).
Capturas
Se não for possível fornecer um build funcional, forneça capturas do PIX das áreas problemáticas conhecidas junto com os símbolos correspondentes.Duração da captura
- Duração ideal: 15–30 segundos.
- Para picos, inclua vários segundos antes e depois do pico.
- Use Capture Title Startup se precisar rastrear o comportamento de inicialização.
- Faça todas as capturas em um build empacotado.
Opções recomendadas de captura de Timing do PIX
Configurações mínimas:- File Accesses — necessário para a análise de padrões de carregamento.
- Memory — pelo menos as três primeiras opções, para a análise de padrões de alocação.
- GPU timings — disponível apenas quando o título é iniciado com o driver gráfico instrumentado (definido no código ou substituído pelas configurações do console no XBOX Manager).
Alocadores personalizados
Se o seu título usa um alocador de memória personalizado, marque-o usando os eventos de alocador personalizado do GDK: Habilite Custom allocator events nas opções de captura de Timing.Aguarde o processamento de símbolos
Antes de salvar uma captura, deixe o PIX concluir o processamento de símbolos (uma barra de progresso aparece no canto superior direito). Salvar antes da conclusão dispara um aviso e gera uma captura mais difícil de compartilhar.Eventos, marcadores e nomes de threads do PIX
As capturas de Timing exigem eventos / marcadores do PIX com granularidade suficiente para identificar onde o tempo é gasto. A disciplina é importante:- Fique atento a pares de
PIXBeginEvent/PIXEndEventsem correspondência — eles invalidam as capturas. PrefiraPIXScopedEvent, que é fechado ao sair do escopo. - Use a versão CHAR (ANSI) dos eventos do PIX — metade da memória da variante WCHAR — a menos que você precise de DBCS.
- Use marcadores detalhados (até o nível de atualização por entidade) para que os pontos críticos possam ser localizados.
- Dê nomes descritivos aos eventos, incluindo nomes de ativos quando possível.
- Envolva loops de espera ativa em eventos para que o ATG possa medir o tempo ocioso / bloqueado.
- Adicione eventos de alto nível para as fases principais: simulação, renderização, workers, streaming.
- Nomeie cada thread criada pelo título com
SetThreadDescription. O PIX e o Visual Studio exibem esses nomes, e seu título pode lê-los de volta por meio deGetThreadDescription.
Resumo
Dados de desempenho de qualidade são o que impulsiona um engajamento produtivo. A primeira coisa que o ATG solicita são as capturas e os metadados descritos acima — prepará-los com antecedência acelera todo o engajamento. Em caso de dúvida, prefira fornecer mais dados.Documentação de API relacionada
- Referência da API PIX3 —
PIXBeginEvent/PIXEndEvent/PIXScopedEvent/PIXRecordMemoryAllocationEvent/PIXRecordMemoryFreeEvent.