SRP Batcher de Unity: optimizar la preparación en la CPU sin confundirlo con el instancing

Identificar el trabajo costoso

Un fotograma con muchos objetos visibles puede invertir tiempo en preparar los draws, ejecutar shaders, obtener texturas o procesar geometría. Cada uno de estos costes requiere una solución distinta. Antes de cambiar la organización de los materiales, conviene determinar si el trabajo de renderizado de la CPU es lo que limita el fotograma. Un menor número de draw calls es un indicio útil sobre el envío de draws, pero no mide por completo el rendimiento de renderizado.

Qué cambia el batcher

El SRP Batcher reduce los costes de preparación y envío en la CPU para los draws que usan la misma variante de shader. Los datos del material persisten en la memoria de la GPU, lo que permite preparar el estado entre draws de forma más económica. Esto no significa que todos esos objetos pasen a ser una sola draw call. El comportamiento al que se hace referencia está documentado para Unity 6.0. [1]

Comprobar primero la compatibilidad

Los shaders personalizados necesitan las propiedades integradas en UnityPerDraw y las propiedades del material en UnityPerMaterial. La ruta compatible documentada para GameObjects excluye el uso de MaterialPropertyBlock. Conviene revisar el estado de compatibilidad del shader antes de reestructurar el contenido. [2] El GPU instancing, en cambio, dibuja juntas varias copias de una malla; su interacción con el SRP Batcher depende de la ruta de renderizado. Hay que verificar qué mecanismo dibuja realmente los objetos seleccionados. [3]

Ejemplo: un andén de ferrocarril

Imaginemos un andén con quioscos, barandillas y bancos variados. Sus mallas son distintas, pero muchos materiales usan la misma variante de iluminación con colores diferentes. Primero se captura un recorrido de cámara representativo y se registran el tiempo de renderizado de la CPU, el tiempo de GPU y el resultado visual. Después se activa o se repara la compatibilidad con el SRP Batcher en un grupo pequeño de materiales y se repite el recorrido en las mismas condiciones. Por separado, se investiga el instancing en una fila repetida de torniquetes de billetes idénticos. Este experimento debe mantenerse aparte para no atribuir a la preparación de materiales una mejora que proviene de la geometría repetida. Si una sobrescritura de color rompe la compatibilidad, hay que comparar una organización deliberada de materiales con el enfoque de la sobrescritura, en lugar de suponer que uno de los dos siempre es más barato. Se trata de comparaciones propuestas, no de resultados de benchmarks.

Límites e interpretación

Hay que mantener igual la iluminación, la visibilidad de los objetos, los ajustes de calidad y el movimiento de la cámara entre una medición y otra. Las diferencias en las keywords de los shaders pueden fragmentar la agrupación prevista, así que conviene inspeccionar las variantes que usa realmente la escena y no solo el nombre del asset del shader. Una optimización puede mejorar el tiempo de renderizado de la CPU y dejar la tasa de fotogramas sin cambios si otra etapa limita el fotograma. A la inversa, un promedio favorable puede ocultar picos causados por contenido dinámico. Se recomienda comparar varias capturas y examinar los intervalos lentos. No se debe desactivar el batching de forma global para resolver una sola categoría de objetos hasta entender el efecto sobre el resto de la escena.

Fuentes

1. Scriptable Render Pipeline Batcher in URP — Unity Technologies.
2. SRP Batcher compatibility — Unity Technologies.
3. GPU instancing — Unity Technologies.