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

Balken, Kurven oder doch beides? Wie zeigen, wie wir die Grafikkarten- bzw. Spiele-Performance messen sowie aus- und bewerten. Dazu gehört natürlich auch unsere selbst programmierte Software, die wir heute erstmals im Detail vorstellen.

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.

Weitere interessante Tests und Artikel zum Thema Grafikkarten
>>>   Pascal-Roundup: GeForce GTX 1070 und GeForce GTX 1080 im Vergleich
>>>   Pascal-Roundup #2: Nvidias GeForce GTX 1060 im Vergleich
>>>   Nvidia GeForce GTX Titan X (Pascal, Launch-Artikel)
>>>   Nvidia GeForce GTX 1080 Founders Edition (Launch-Artikel)
>>>   Nvidia GeForce GTX 1070 Founders Edition (Launch-Artikel)
>>>   Nvidia GeForce GTX 1060 Founders Edition (Launch-Artikel)
>>>   Nvidia GeForce GTX 1060 3G (MSI GeForce GTX 1060 Gaming X 3G)
>>>   Nvidia GeForce GTX 1050 und GTX 1050 Ti (Pascal, Launch-Artikel)
>>>   Passiv-Umbau GeForce GTX 1050 Ti (Pascal)
>>>   Effizienzanalyse & Leistungsaufnahme: GeForce GTX 1070/1080 vs. GTX 980 Ti
>>>   AMD Radeon RX 480 (Launch-Artikel)
>>>   AMD Radeon RX 480 im Detail: Leistungsaufnahme, Board-Layout & Normen
>>>   AMD Radeon RX 480: Neuer Treiber entlastet das Mainboard deutlich
>>>   AMD Radeon RX 470 4GB (Polaris, Launch-Artikel)
>>>   AMD Radeon RX 460 4GB (Polaris, Launch-Artikel)
>>>   Maxwell-Roundup: GeForce GTX 970 und GeForce GTX 980 im Vergleich

>>>   How-to-Guide: Grafikkartenkühlung und Wärmeleitpaste optimieren

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.


Enthusiast-System
Mainstream-PC
Prozessor:
Intel Core i7 6950X @4.2 GHz
AMD FX 8350 @stock
Kühlung:
Open-Loop Wasserkühlung
be quiet! Dark Rock Pro 3
Arbeitsspeicher
16 GB Corsair DDR4 3400
16 GB DDR3 1866
Mainboard
MSI X99A Gaming Pro
MSI Gaming 970
System-SSD
1TB, Intel SSD 5
Betriebssystem:
Windows 10 Build 1607 (10.0.14393.51)
Grafiktreiber
Crimson 16.8.2
GeForce 372.54  WHQL

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.

Erstelle einen neuen Thread im Artikel-Forum über dieses Thema
Dieser Thread ist für Kommentare geschlossen
12 Kommentare
Im Forum kommentieren
    Dein Kommentar
  • Tesetilaro
    vielen Dank für dieses Update!!! sehr spannend und für mich wird das geruckel bei eigentlich "hohen framerates" endlich nachvollziehbar und nachweisbar...
    0
  • gt_dev_sda
    Jetzt wäre es nur noch nett die Farbwiedergabe, -auflösung, -reproduzierbarkeit und was einem sonst noch in diesem Bereich einfällt, zu messen (bei gleichem Monitor). Gefühlt gibt es auch da Unterschiede, aber ob das Gefühl stimmt?
    0
  • Tesetilaro
    also ich kann Dir sagen - ich mußte definitiv an den einstellungen schrauben als ich von 290x auf 980 ti umgestiegen bin - das sah auf ansonsten gleicher hardware, inkl. monitor vollkommen anders aus...
    0
  • nWo
    schöner test und erklärung!
    0
  • Postguru
    zum Thema FPS vs. Leistungsaufnahme
    ich finde es etwas verwirrend und gegenüber AMD sogar unfair ... den die Graphen suggerieren das der Intel einen Bruchteil ca 1/4 vom AMD benötigt ... was wenn man genau hinschaut überhaupt nicht stimmt ..der Intel Graph beginnt mit 40W als Nulllinie und endet bei 140 W !!! bei dem AMD Graphen beginnt die Nulllinie Korrekt bei 0W und endet bei 100W . Klar das Intel derzeit die Nase vorn hat was die Effizenz angeht aber so .. ist dies einfach unprofessionell ... intel bewegt sich auf dem Graph zwischen 55W und 80W Spitze bei 100W ! bei AMD sie die sache etwas anders aus bei 70W bis 100W ohne dabei eine extreme Spitze zu sehen .. da ja der Graph nur bis 100W geht ... d.h. wenn man es richtig liest ..liegen die niedrigsten Werte bei gerade mal 15W die maximalen sind bei 20W mehrverbrauch von AMD man wenn man die 100W Spitze von Intel ignoriert ...


    Tip fürs nächste mal: generell gleiche Skalierung verwenden ... ggf händisch nachhelfen ..
    0
  • FormatC
    Da wir als neutrale Beobachter nicht hyperventilieren, habe ich die Skalierung mit Absicht so gelegt, dass der Endwert in etwa der TDP entspricht, was beim Intel ein Delta von 140 Watt ergibt. BEIDE Achsen haben also die gleiche Skalierung von 100 Einheiten! Hätte ich beim Intel die Achse des FX genutzt, hätte man die Kurven nicht mehr auseinanderhalten können, weil sie hinter den FPS verschwinden.

    Du unterstellst hier Absichten, auf die ein Nicht-Fanboy gar nicht erst kommen würde Der normalgebildete Anwender wird eh immer emotionlos auf die Achsenbeschriftung schauen. Im Übrigen wird diese Konstellation mit verschiedenen CPUs eh nicht mehr auftreten. :D
    0
  • Postguru
    Ich weise ledeglich auch einen Inhalt hin der nicht korrekt ist .. wenn die Darstellung der nach dem TDP ausgelegt ist ..hätte es einen Hinweis geben können .. aber selbst das passt nicht weil der FX 8350 eine TDP von 125W hat ...

    Das verschieben von Skalen ist immer mit vorsicht zu geniesen .. wenn sowas gemacht wird sollte dann auch eine Erklärung dazu geben .. das selbe hat man dann wenn irgendein Grafikkartenhersteller Balkendiagramme nimmt und erstmal 100FPS abscheidet um dann die letzten 5 FPS mehr darzustellen als wäre das neue 3 mal schneller ;) es gibt die Doppelte Wellenliene die quer zur Linie läuft ..das bedeutet das es gekürz wurde ..
    0
  • FormatC
    Beide Skalen haben einen Bereich von je 100 Watt, die Kurven sind also gleich skaliert.
    0
  • derGhostrider
    Postguru: der Artikel verweist MEHRFACH darauf, dass es nur um die Messverfahren geht. NICHT um die zur Anschauung verwendete Hardware.

    Solange die Achsenbeschriftung vollständig ist, ist alles i.O.!
    Du kannst de X-Achse dort schneiden lassen, wo es Dir gefällt. Vor allem, wenn der Schnittpunkt eindeutig gekennzeichnet ist.
    0
  • derGhostrider
    Nachtrag: ich wüsste prinzipiell gerne mal, welche Berechnung Excel gar nicht kann, also was unmöglich sein soll.
    Klingt für mich so nämlich nicht nachvollziehbar.
    0
  • FormatC
    Anonymous sagte:
    Nachtrag: ich wüsste prinzipiell gerne mal, welche Berechnung Excel gar nicht kann, also was unmöglich sein soll.
    Klingt für mich so nämlich nicht nachvollziehbar.


    Rekursive Berechnungen, längere Schleifen, flexible Filter und das Handling von bis zu 60.000 Datensätzen sind in dieser grottenlahmen Tabellenkalkulation schlicht unmöglich. VBA ist eine lahme Krücke und bleibt es auch. Und dann versuche mal, z.B. 6700 frame time Einträge auf eine gemeinsame Achse mit einem Datensatz von z.B. 600 Einträgen zu bringen. Dann müsste ich den mit der kleineren Anzahl linear interpolieren, was Ewigkeiten dauert.
    0
  • derGhostrider
    Ohne die Details zu kennen kann ich dazu nichts sagen. Möchte ich auch gar nicht. Ich muss ja nicht allem zustimmen bzw von allem überzeugt sein, was da gemacht wird.
    0