Unity SRP Batcher : optimiser la préparation côté CPU sans le confondre avec l'instancing

Identifier le travail coûteux

Une frame comportant de nombreux objets visibles peut passer son temps à préparer les draws, exécuter les shaders, récupérer des textures ou traiter la géométrie. Ces coûts appellent des remèdes différents. Avant de modifier l'organisation des matériaux, déterminez si le travail de rendu du CPU limite réellement la frame. Un nombre de draw calls plus faible est un indice utile sur la soumission, mais il ne suffit pas à mesurer les performances de rendu.

Ce que change le batcher

Le SRP Batcher réduit les coûts de préparation et d'envoi côté CPU pour les draws qui utilisent la même variante de shader. Les données de matériau restent en mémoire GPU, ce qui rend la préparation de l'état entre deux draws moins coûteuse. Cela ne signifie pas que tous ces objets sont fusionnés en un seul draw call. Le comportement décrit ici est documenté pour Unity 6.0. [1]

Vérifier d'abord la compatibilité

Les shaders personnalisés doivent déclarer les propriétés intégrées dans UnityPerDraw et les propriétés de matériau dans UnityPerMaterial. Le chemin compatible documenté pour les GameObject exclut l'utilisation de MaterialPropertyBlock. Consultez l'état de compatibilité du shader avant de restructurer le contenu. [2] Le GPU instancing, lui, dessine ensemble des copies d'un même mesh ; son interaction avec le SRP Batcher dépend du chemin de rendu. Vérifiez quel mécanisme dessine réellement les objets sélectionnés. [3]

Exemple : un quai de gare

Imaginons un quai avec des kiosques, des garde-corps et des bancs variés. Leurs meshes diffèrent, tandis que de nombreux matériaux utilisent la même variante d'éclairage avec des couleurs différentes. Commencez par capturer un parcours de caméra représentatif et relevez le temps de rendu CPU, le temps GPU et le rendu visuel. Activez ensuite ou rétablissez la compatibilité avec le SRP Batcher pour un petit groupe de matériaux, puis rejouez le même parcours dans les mêmes conditions. Étudiez à part l'instancing pour une rangée répétée de portiques de validation identiques. Gardez cette expérience distincte, afin qu'un gain dû à la géométrie répétée ne soit pas attribué à la préparation des matériaux. Si une surcharge de couleur rompt la compatibilité, comparez une organisation délibérée des matériaux à l'approche par surcharge, sans supposer que l'une ou l'autre soit toujours moins coûteuse. Il s'agit de comparaisons proposées, et non de résultats de benchmark.

Limites et interprétation

Conservez le même éclairage, la même visibilité des objets, les mêmes réglages de qualité et le même mouvement de caméra d'une mesure à l'autre. Des différences de mots-clés de shader peuvent fragmenter le regroupement prévu : examinez donc les variantes réellement utilisées par la scène, et pas seulement le nom de l'asset de shader. Une optimisation peut améliorer le temps de rendu CPU sans changer la fréquence d'images si une autre étape limite la frame. À l'inverse, une moyenne favorable peut masquer des pics causés par du contenu dynamique. Comparez plusieurs captures et examinez les intervalles lents. Ne désactivez pas le batching globalement pour corriger une seule catégorie d'objets tant que l'effet sur le reste de la scène n'est pas compris.

Sources

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