Shader-Varianten und Prewarming: Ruckler bei der ersten Verwendung gezielt verringern

Drei Entscheidungen trennen

Ein Shader kann erfolgreich gebaut werden und trotzdem bei der ersten Verwendung eine Pause verursachen. Unity dokumentiert einen Treiberschritt, der eine GPU-spezifische Variante erzeugt, sobald das Rendering sie erstmals benötigt. [1] Die Auswahl der Varianten, das Beibehalten benötigter Varianten im Build und die Vorbereitung der Laufzeit-Pipelines sind als getrennte Entscheidungen zu behandeln. Eine kleine ausführbare Datei belegt nicht, dass jeder benötigte Materialzustand das Stripping überstanden hat.

Kombinationen zählen

Als bewusst vereinfachtes Beispiel dient ein Shader-Pass mit vier unabhängigen binären Feature-Schaltern. Die Zahl der Kombinationen beträgt 2 × 2 × 2 × 2 = 16, noch bevor weitere Passes, Stufen oder Zielkonfigurationen hinzukommen. Erlaubt das Produkt nur drei dokumentierte Kombinationen, sind die übrigen Kombinationen Kandidaten für die Entfernung, sofern kein Übergang zur Laufzeit sie benötigt.

Diese Liste erlaubter Zustände ist explizit zu führen. Darin sind Qualitätswechsel, Ausrüstungswechsel und dynamisch geladene Materialien aufzunehmen. Die Stripping-Hinweise von Unity warnen, dass das Entfernen einer benötigten Variante dazu führen kann, dass die Engine stattdessen eine ähnliche verfügbare Variante wählt. [2] Die visuelle Korrektheit gehört deshalb in die Stripping-Prüfung.

Pipeline-Vorbereitung verstehen

Ein Pipeline State Object (PSO) umfasst mehr als einen Shader-Namen. Die Precaching-Dokumentation von Unreal berücksichtigt Vertex-Informationen und Rendering-Zustand und unterscheidet verpasste Anfragen von solchen, die zu spät fertig werden. Die Kompilierung läuft asynchron und beansprucht CPU- und Speicherressourcen. [3] Wird ein Material in einer einzelnen Vorschauszene vorbereitet, ist damit noch nicht jede Draw-Konfiguration abgedeckt.

Ein praxistaugliches Warmup-Experiment entwerfen

Angenommen sei ein Spiel mit einem Hub, einer Eisarena und einer Fahrzeuggarage. Für jeden Bereich wird eine repräsentative Abfolge der ersten Verwendung aufgebaut. Dabei werden die erlaubten Materialzustände, die relevanten Mesh-Layouts, die Beteiligung an Schatten und die Konfiguration der Zielausgabe durchlaufen. Festgehalten wird, welche Pipeline-Vorbereitungen vor dem Betreten stattfinden und welche weiterhin während des Spiels anfallen.

Verglichen wird ein Durchlauf mit kaltem Treiber-Cache mit einem separaten Durchlauf mit aufgewärmtem Cache. Grafik-API, Treiber, Build und Szenenroute bleiben dabei unverändert. Ladezeit, Speicherdruck und langsame Frames werden gemeinsam gemessen. Ein Warmup, das einen Ruckler in der Arena beseitigt, den Eintritt aber übermässig verzögert oder mit dem Laden von Assets konkurriert, erfordert unter Umständen eine kleinere, gestaffelte Menge. Dies sind vorgeschlagene Experimente, keine Performance-Messungen.

Fehler sichtbar halten

Ein Diagnose-Build, der fehlende Varianten und Pipeline-Misses sichtbar macht, ist beizubehalten. Geprüft werden sowohl die erste Begegnung als auch spätere Übergänge, darunter ein Qualitätswechsel nach dem Laden. Ein Fallback-Material ist nicht schon deshalb zu akzeptieren, weil das Spiel nicht mehr stockt.

Die Cache-Abdeckung ändert sich mit Inhalten, Renderer-Konfiguration und Zielhardware. Nach solchen Änderungen ist die Abfolge der ersten Verwendung erneut zu validieren. Prewarming verschiebt oder vermeidet einen Teil der Vorbereitungsarbeit; es kann nicht garantieren, dass Streaming, Synchronisation oder unabhängige Gameplay-Arbeit nie einen langen Frame verursachen.

Quellen

[1] Shader loading — Unity Technologies.

[2] Strip shader variants — Unity Technologies.

[3] PSO Precaching — Epic Games.