Unity SRP Batcher: CPU-Vorbereitung optimieren, ohne ihn mit Instancing zu verwechseln

Den aufwendigen Teil der Arbeit identifizieren

Ein Frame mit vielen sichtbaren Objekten kann seine Zeit mit dem Vorbereiten von Draws, dem Ausführen von Shadern, dem Laden von Texturen oder dem Verarbeiten von Geometrie verbringen. Diese Kosten erfordern jeweils unterschiedliche Gegenmassnahmen. Vor Änderungen an der Materialorganisation ist daher zu klären, ob die Rendering-Arbeit der CPU den Frame begrenzt. Eine geringere Anzahl an Draw Calls liefert zwar einen nützlichen Hinweis auf die Übermittlung, ist aber kein vollständiges Mass für die Rendering-Leistung.

Was der Batcher verändert

Der SRP Batcher senkt die CPU-Kosten für Vorbereitung und Absetzen von Draws, die dieselbe Shader-Variante verwenden. Die Materialdaten bleiben im GPU-Speicher erhalten, sodass der Zustand zwischen den Draws günstiger vorbereitet werden kann. Daraus folgt nicht, dass alle diese Objekte zu einem einzigen Draw Call werden. Das beschriebene Verhalten ist für Unity 6.0 dokumentiert. [1]

Zuerst die Kompatibilität prüfen

Eigene Shader benötigen die eingebauten Eigenschaften in UnityPerDraw und die Materialeigenschaften in UnityPerMaterial. Im dokumentierten kompatiblen GameObject-Pfad ist die Verwendung von MaterialPropertyBlock ausgeschlossen. Vor einer Umstrukturierung der Inhalte ist der Kompatibilitätsstatus des Shaders zu prüfen. [2] GPU Instancing hingegen zeichnet Kopien eines Meshes gemeinsam; das Zusammenspiel mit dem SRP Batcher hängt vom Rendering-Pfad ab. Es ist zu verifizieren, welcher Mechanismus die ausgewählten Objekte tatsächlich zeichnet. [3]

Beispiel: ein Bahnsteig

Angenommen, ein Bahnsteig enthält unterschiedliche Kioske, Geländer und Bänke. Ihre Meshes unterscheiden sich, während viele Materialien dieselbe Beleuchtungsvariante mit verschiedenen Farben nutzen. Zunächst wird eine repräsentative Kamerafahrt aufgezeichnet und dabei CPU-Rendering-Zeit, GPU-Zeit und Bildausgabe festgehalten. Danach wird die SRP-Batcher-Kompatibilität für eine kleine Materialgruppe aktiviert oder wiederhergestellt und die Kamerafahrt unter denselben Bedingungen wiederholt. Getrennt davon ist Instancing für eine sich wiederholende Reihe identischer Ticketsperren zu untersuchen. Dieses Experiment ist separat zu halten, damit ein Gewinn durch wiederholte Geometrie nicht der Materialvorbereitung zugeschrieben wird. Wenn eine Farbüberschreibung die Kompatibilität aufhebt, ist eine bewusst gewählte Materialanordnung mit dem Ansatz der Überschreibung zu vergleichen, statt anzunehmen, eines von beidem sei stets günstiger. Es handelt sich um vorgeschlagene Vergleiche, nicht um Benchmark-Ergebnisse.

Grenzen und Interpretation

Beleuchtung, Objektsichtbarkeit, Qualitätseinstellungen und Kamerabewegung sind zwischen den Messungen unverändert zu halten. Unterschiede bei Shader-Keywords können die beabsichtigte Gruppierung aufspalten; deshalb sind die in der Szene verwendeten Varianten zu prüfen und nicht nur der Name des Shader-Assets. Eine Optimierung kann die CPU-Rendering-Zeit verbessern und die Bildrate dennoch unverändert lassen, wenn eine andere Stufe den Frame begrenzt. Umgekehrt kann ein günstiger Durchschnittswert Spitzen verdecken, die durch dynamische Inhalte entstehen. Daher sind mehrere Aufzeichnungen zu vergleichen und die langsamen Abschnitte genauer zu untersuchen. Batching ist nicht global zu deaktivieren, um eine einzelne Objektkategorie zu beheben, solange die Auswirkung auf den Rest der Szene nicht verstanden ist.

Quellen

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