Perfilado de fotogramas en CPU y GPU: cómo encontrar el trabajo limitante

Empieza con una pregunta reproducible

Una tasa de fotogramas baja es una observación, no un diagnóstico. Elige una escena y una acción del jugador que reproduzcan el problema y define el objetivo de rendimiento. Un combate con mucha gente en pantalla y la apertura del inventario pueden tener causas distintas aunque ambos se sientan lentos. Mantén sus capturas separadas para que un único promedio no oculte dos problemas sin relación.

Lee líneas de tiempo superpuestas

La simulación en CPU, el envío de renderizado y la ejecución en GPU pueden solaparse. Por eso el módulo Highlights de Unity compara por separado el tiempo activo de CPU y el tiempo de GPU con el presupuesto de fotograma del objetivo. Su cálculo del tiempo activo excluye marcadores de espera concretos. [1] Antes de interpretar una espera larga, examina la línea de tiempo circundante: el hilo puede estar esperando a otra etapa o a la planificación de la presentación. El nombre de un temporizador, por sí solo, no indica que haya cálculo útil.

Trabaja con un presupuesto de fotograma

Para un objetivo ilustrativo de 60 fotogramas por segundo, el presupuesto es de unos 16,67 ms. Supongamos que un fotograma representativo tiene 10 ms de trabajo de CPU y 14 ms de GPU. Sumarlos para afirmar que el fotograma dura 24 ms ignora el posible solapamiento. Además, estas mediciones inventadas tampoco garantizan un intervalo de presentación de 14 ms: las dependencias, la sincronización y el ritmo de fotogramas (frame pacing) siguen influyendo.

Ahora supongamos que bajar la resolución de renderizado reduce el tiempo de GPU mientras el trabajo de CPU se mantiene parecido. Eso es un indicio para investigar el trabajo ligado a los píxeles, no una prueba de que un shader concreto sea el responsable. Compara cada pasada por separado antes de elegir una optimización.

Captura una comparación controlada

Usa una build en hardware objetivo representativo. Registra la versión del motor, la API gráfica, la resolución, los ajustes de calidad y las condiciones de energía. Repite la misma ruta de cámara, incluidas la carga de assets y los efectos que los jugadores realmente encuentran. Mantén separadas las capturas del primer uso de las capturas en estado estable, una vez calentado el sistema.

Cambia una sola variable relevante, recoge varias ejecuciones e inspecciona la distribución de los tiempos de fotograma, incluidos los valores atípicos lentos. Correlaciona los picos con tareas de CPU, pasadas de GPU, asignaciones de memoria y eventos de carga. Conserva la captura y la configuración exacta para que otro desarrollador pueda reproducir la comparación. Informa del intervalo observado y de la carga de trabajo en lugar de presentar un único fotograma favorable como una mejora general.

Ten en cuenta los límites de la medición

La instrumentación modifica la carga de trabajo. Frame Timing Manager de Unity es deliberadamente más limitado que un profiler general y está diseñado para generar menos sobrecarga, pero sus mediciones siguen teniendo limitaciones según la plataforma. [2] Confirma que el contador elegido sea compatible y válido.

Tras un cambio, comprueba la salida visual y la jugabilidad además de los tiempos. Una pasada más corta puede trasladar el cuello de botella a otro punto. Haz un seguimiento por separado del frame pacing y de la respuesta a la entrada; un gráfico de rendimiento fluido no demuestra por sí solo que la latencia de extremo a extremo sea baja.

Fuentes

[1] Highlights Profiler module reference — Unity Technologies.

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