Profiling de frames de CPU e GPU: como encontrar o trabalho que limita o desempenho

Comece com uma pergunta reproduzível

Uma taxa de quadros baixa é uma observação, não um diagnóstico. Escolha uma cena e uma ação do jogador que reproduzam o problema e defina a meta de desempenho. Um combate com muitos personagens em cena e a abertura do inventário podem ter causas diferentes, mesmo que ambos pareçam lentos. Mantenha as capturas separadas para que uma média única não esconda dois problemas sem relação entre si.

Leia as linhas do tempo sobrepostas

A simulação na CPU, o envio de comandos de renderização e a execução na GPU podem ocorrer em paralelo. Por isso, o módulo Highlights do Unity compara separadamente o tempo ativo da CPU e o tempo da GPU com o orçamento de tempo de frame da meta. O cálculo do tempo ativo exclui marcadores de espera específicos. [1] Antes de interpretar uma espera longa, examine a linha do tempo ao redor: a thread pode estar aguardando outra etapa ou o agendamento da apresentação. O nome de um timer, por si só, não indica que há computação útil.

Trabalhe com um orçamento de frame

Para uma meta ilustrativa de 60 quadros por segundo, o orçamento é de cerca de 16,67 ms. Suponha que um frame representativo tenha 10 ms de trabalho na CPU e 14 ms na GPU. Somar os dois valores para afirmar que o frame leva 24 ms ignora a possível sobreposição. Além disso, essas medições inventadas não garantem um intervalo de apresentação de 14 ms: dependências, sincronização e ritmo de entrega dos quadros (pacing) continuam a ter influência.

Agora suponha que reduzir a resolução de renderização diminua o tempo de GPU, enquanto o trabalho da CPU permanece semelhante. Isso é um indício para investigar o trabalho ligado a pixels, não uma prova de que determinado shader seja o responsável. Compare cada passe individualmente antes de escolher uma otimização.

Faça uma comparação controlada

Use um build em hardware-alvo representativo. Registre a versão da engine, a API gráfica, a resolução, as configurações de qualidade e as condições de energia. Repita o mesmo percurso de câmera, incluindo o carregamento de assets e os efeitos que os jogadores realmente encontram. Mantenha as capturas de primeiro uso separadas das capturas em regime estável, feitas após o aquecimento.

Altere uma variável relevante por vez, colete várias execuções e examine a distribuição dos tempos de frame, incluindo os valores atípicos lentos. Correlacione os picos com tarefas da CPU, passes da GPU, alocações e eventos de carregamento. Preserve a captura e a configuração exata para que outro desenvolvedor possa reproduzir a comparação. Relate o intervalo observado e a carga de trabalho em vez de apresentar um único frame favorável como ganho geral de desempenho.

Considere os limites da medição

A instrumentação altera a carga de trabalho. O Frame Timing Manager do Unity é deliberadamente mais restrito que um profiler geral e foi projetado para ter menor overhead, mas suas medições ainda têm limitações conforme a plataforma. [2] Confirme que o contador escolhido é suportado e válido.

Depois de uma mudança, verifique também o resultado visual e a jogabilidade, e não apenas os tempos. Um passe mais curto pode deslocar o gargalo para outro ponto. Acompanhe separadamente o ritmo dos quadros (frame pacing) e a resposta à entrada; um gráfico de throughput estável não basta para demonstrar baixa latência de ponta a ponta.

Fontes

[1] Highlights Profiler module reference — Unity Technologies.

[2] Detecting performance bottlenecks with Unity Frame Timing Manager — Anton Kruglyakov, Unity Technologies.