CPU- und GPU-Frame-Profiling: die limitierende Arbeit finden

Mit einer wiederholbaren Fragestellung beginnen

Eine niedrige Bildrate ist eine Beobachtung, keine Diagnose. Zuerst eine Szene und eine Spieleraktion wählen, die das Problem reproduzieren, und das Performanceziel festlegen. Ein stark bevölkerter Kampf und das Öffnen des Inventars können unterschiedliche Ursachen haben, auch wenn sich beides langsam anfühlt. Die Captures beider Fälle getrennt halten, damit ein einzelner Durchschnittswert nicht zwei voneinander unabhängige Probleme verdeckt.

Überlappende Timelines lesen

CPU-Simulation, Render-Submission und GPU-Ausführung können sich überlappen. Das Highlights-Modul von Unity vergleicht deshalb CPU-Aktivzeit und GPU-Zeit jeweils einzeln mit dem Ziel-Frame-Budget. Bei der Berechnung der Aktivzeit werden bestimmte Warte-Marker herausgerechnet. [1] Vor der Deutung einer langen Wartezeit die umliegende Timeline prüfen: Der Thread kann auf eine andere Stufe oder auf das Scheduling der Bildausgabe warten. Der Name eines Timers allein sagt nicht, ob dahinter sinnvolle Berechnung steckt.

Ein Frame-Budget durchrechnen

Für ein beispielhaftes Ziel von 60 Bildern pro Sekunde beträgt das Budget rund 16,67 ms. Angenommen, ein repräsentativer Frame enthält 10 ms CPU-Arbeit und 14 ms GPU-Arbeit. Beide zu addieren und daraus einen Frame von 24 ms abzuleiten, ignoriert mögliche Überlappung. Diese erfundenen Messwerte garantieren auch kein Präsentationsintervall von 14 ms: Abhängigkeiten, Synchronisation und Pacing spielen weiterhin eine Rolle.

Angenommen, eine geringere Rendering-Auflösung senkt die GPU-Zeit, während die CPU-Arbeit ähnlich bleibt. Das ist ein Hinweis, pixelbezogene Arbeit zu untersuchen, aber kein Beweis, dass ein bestimmter Shader verantwortlich ist. Vor der Wahl einer Optimierung die einzelnen Passes miteinander vergleichen.

Einen kontrollierten Vergleich aufnehmen

Einen Build auf repräsentativer Zielhardware verwenden. Engine-Version, Grafik-API, Auflösung, Qualitätseinstellungen und Energiebedingungen festhalten. Dieselbe Kamerafahrt wiederholen, einschliesslich des Ladens von Assets und der Effekte, die Spielern tatsächlich begegnen. Captures der ersten Nutzung von solchen im aufgewärmten, stabilen Zustand getrennt halten.

Jeweils eine relevante Variable ändern, mehrere Durchläufe sammeln und die Verteilung der Frame-Zeiten untersuchen, auch die langsamen Ausreisser. Spitzen mit CPU-Tasks, GPU-Passes, Allokationen und Ladeereignissen korrelieren. Capture und genaue Konfiguration aufbewahren, damit andere Entwickler den Vergleich reproduzieren können. Das beobachtete Intervall und die Last angeben, statt einen einzelnen günstigen Frame als allgemeine Beschleunigung darzustellen.

Messgrenzen berücksichtigen

Instrumentierung verändert die Last. Der Frame Timing Manager von Unity ist bewusst enger gefasst als ein allgemeiner Profiler und auf geringeren Overhead ausgelegt, seine Messungen unterliegen aber dennoch plattformspezifischen Einschränkungen. [2] Prüfen, ob der gewählte Zähler unterstützt wird und gültige Werte liefert.

Nach einer Änderung neben den Zeiten auch Bildausgabe und Gameplay kontrollieren. Ein kürzerer Pass kann den Engpass an eine andere Stelle verschieben. Frame-Pacing und Eingabereaktion getrennt verfolgen; ein gleichmässiger Durchsatzgraph belegt für sich allein keine niedrige Ende-zu-Ende-Latenz.

Quellen

[1] Highlights Profiler module reference — Unity Technologies.

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