Redaktion intern: So messen und bewerten wir die Grafik-Performance

PresentMon: Frame Times für DirectX, OpenGL und Vulkan messen

Spätestens seit der Einführung von DirectX 12, Windows UWP und Vulkan standen wir erneut vor der Aufgabe, eine zumindest weitgehend verlässliche Ermittlung der Renderzeiten aller einzelnen Frames zu schaffen, auf deren Basis wir unsere Auswertungen aufbauen können. Denn Fraps funktioniert hierfür nicht mehr und war auch sonst nicht so verlässlich wie gemeinhin oft angenommen.

Da kam uns allen Andrew Lauritzen – seines Zeichens ein Grafik-Guru von Intel – gerade recht, der der Allgemeinheit ein neues Tool namens PresentMon kostenlos auf GitHub zur Verfügung stellte, das einer seiner Kollegen programmiert hatte.

Die Idee hinter ist PresentMon so einfach wie clever: Man überwacht den Event-Tracing-Stack von Windows, sammelt die gewünschten Informationen aller bekannten APIs wie DirectX (9 bis 12), OpenGL oder auch Vulkan und arbeitetet diese dann für die Anwender so auf, dass sie leicht verständlich in einer CSV-Datei gesammelt werden können, die man dann später nach eigenen Vorstellungen auswerten kann.

Doch auch PresentMon unterliegt natürlich technischen Einschränkungen, da es auf der Betriebssystemebene fungiert, und kann Methoden wie FCAT nicht zu 100 Prozent ersetzen. Darüber hinaus verzichtet PresentMon aktuell auf ein grafisches Overlay in den getesteten Anwendungen, so dass man in jedem Fall auf eine Datei-Protokollierung angewiesen ist. Was PresentMon jedoch so interessant macht ist der Umstand, dass alle derzeit gängigen APIs erfasst werden können

Der Nachteil für den Anwender ist der recht umständliche und auch zeitraubende Umgang mit dem Tool, das als reine Kommandozeilen-Anwendung funktioniert und selbst über keinerlei grafische Oberfläche verfügt. Die zu übergebenden Parameter sind vielfältig und beinhalten auch Informationen, die man sich normalerweise händisch im System (z.B. im Task-Manager) besorgen muss.

Erfassung leicht gemacht: Das PresentMon-GUI

Folgerichtig fiel der Entschluss, für den internen Gebrauch eine eigene Anwendung zu entwickeln, die sowohl PresentMon startet, steuert und überwacht, und andererseits zeitgleich noch weitere Informationen sammelt, die dann für eine umfassendere Auswertung und Präsentation der Ergebnisse dient.

So haben wir in unserem Tool alle häufig genutzten Benchmark-Spiele mit je einem einmalig anzulegenden (und auch zu bearbeitenden) Profil hinterlegt, das anwendungsabhängig automatisch dann zur Steuerung der PresentMon-Parameter dient, wenn eine der gespeicherten Anwendungen erkannt wird.

Dazu haben wir auch ein eigenes, frei konfigurierbares Hot-Key-System implementiert, mit dem sich PresentMon starten, automatisch steuern (Aufzeichnungszeit, Voreinstellungen) und bedarfsweise auch manuell beenden lässt, während wir uns im Spiel oder einer bestimmten grafischen Anwendung befinden. Eine nette weibliche Stimme informiert uns dabei über den Erfolg (oder Misserfolg) der gewünschten Aktion.

Systemdaten sammeln leicht gemacht

Was in PresentMon jedoch fehlt, muss auf anderem Wege und möglichst synchron eingesammelt werden. Aida64 von FinalWire Ltd. ist als registrierte Engineering-Version in der Lage, die verschiedensten Sensoren der restlichen Hardware-Komponenten wie Mainboard, Grafikkarte, Arbeitsspeicher oder festen Datenspeichern auszulesen.

Um dies möglichst verzögerungsfrei und ohne zusätzlichen Overhead in Echtzeit zu lösen, setzen wir nicht auf HWInfo, wo die Schnittstelle über eine DLL gelöst wird, sondern auf Aida64, wo wir direkt auf den Speicher zugreifen können, in dem die Sensorwerte vom Loop abgelegt werden.

Um auch die Datenträgerzugriffe zu minimieren, schreiben wir diese zweite Log-Datei zunächst in den Arbeitsspeicher (die Größe ist dafür gering genug) und erst dann auf den Datenträger, wenn auch die Protokolldatei von PresentMon geschlossen wurde.

Da PresentMon leider keinen Zeitstempel nutzt, setzen wir den Beginn unserer Aufzeichnungen auf den ersten, tatsächlich erfassten Protokollvorgang von PresentMon und führen die Zeiterfassung parallel in unserer eigenen Log-Datei. Dieser Stempel ist nötig, um externe Messungen wie beispielsweise an unseren Oszilloskopen automatisch steuern bzw. die Logs abgleichen zu können.

Auswertung der Daten und Aufarbeitung für die Ergebnis-Präsentation

All diese Daten ergeben einen riesigen Haufen binärer Informationen, der erst einmal bewältig werden will. Dafür nutzen wir ebenfalls eine eigens für diesen Einsatz von uns selbst programmierte Software, die die beiden Log-Dateien zusammenführt und all die nötigen mathematischen Berechnungen durchführt, die auf Grund ihrer Komplexität und des erheblichen Umfangs nur schwer oder überhaupt nicht mit Excel ausführbar wären.

 

Mit unserem Log-File-Interpreter der dritten Generation können wir exakt diese Berechnungen im Handumdrehen erledigen und auch neue Auswertungen bei Bedarf implementieren. Was wir genau auswerten und wie dann die Ergebnisse aussehen, das erklären wir gleich anhand eines ganz konkreten Beispiels mit zwei unterschiedlichen Grafikkarten und einem DirectX12-Spiel.

Unser Ziel ist ja, dass unsere Leser die angebotenen Auswertungen auch einfach und korrekt aufnehmen und verstehen können, denn wenn wir im Verlaufe unserer Arbeit eines gemerkt haben, dann ist es der Umstand, dass Balkengrafiken wie die nachfolgende leider nur die halbe Wahrheit sind und ab und an sogar lügen, dass sich selbige biegen.

 

 

Wir sehen minimale, maximale und durchschnittliche FPS-Werte, wobei absolut nichts über das wahre Performance-Gefühl und mögliche (Mikro-)Ruckler ausgesagt wird. Um aber diese ungemein wichtigen Aussagen treffen zu können, benötigen wir mehr als nur diese Endwerte.

Wir bewerten stattdessen den gesamten Verlauf unseres Benchmark-Durchlaufs einschließlich aller Nebeninformationen, was zum Teil zu sehr interessanten und oft auch abweichenden Einschätzungen führt, die uns die einfachen Balken frech verschweigen.

Zwei Grafikkarten, zwei Testsysteme, ein Benchmark

Da es uns hier NICHT vorranging um den Vergleich der MSI GeForce GTX 1060 Gaming X 6G mit der MSI Radeon RX 480 Gaming X 8G, wohl aber um die Erklärung dessen geht, was und wie wir messen bzw. auswerten, nutzen wir zur besseren Vergleichbarkeit und dem einfacheren Verständnis einen einzigen Benchmark für beide Karten und Testsysteme.

Hier setzen wir auf Hitman, mit dem wir jeweils beide Grafikkarten unter DirectX11 und 12 auf zwei sehr unterschiedlichen Plattformen benchmarken. Dies ist natürlich nur eine Momentaufnahme, aber wir wollen ja hier und heute unser System und Vorgehen erklären und nicht die Karten selbst bewerten.

Eine Anmerkung zum Schluss: Wir werden in kommenden Tests natürlich nicht alle hier vorgestellten Ausgabemöglichkeiten einsetzen, sondern von Fall zu Fall entscheiden, was für den jeweiligen Artikel wirklich wichtig ist. Sollten neue Auswertungen hinzukommen, werden wir auch diesen Grundlagenartikel aktualisieren, denn er wird nun auch als in anderen Artikeln verlinkte Informationsquelle dienen, um überflüssige Textdoppler zu vermeiden.