Baal Netbeck
Fleet Admiral
- Registriert
- Apr. 2008
- Beiträge
- 12.348
Dies ist ein ausgelagertes Thema aus diesem Hauptthread:
https://www.computerbase.de/forum/t...kussion-zu-spieletests.1728575/#post-20678303
Jedes Spiel hat unterschiedliche Ansprüche an die Art und Länge der Testsequenz und wird stark durch die Einstellungen im Spiel und auch im Grafiktreiber beeinflusst.
Habe ich bei den ersten Punkten noch eine klare Meinung, komme ich gerade bei den Grafikeinstellungen ins grübeln
Anzahl der Messungen:
Die eigentliche Messung:
Warum Fraps?
Ist FCAT jetzt der Heilige Gral und was Fraps aufnimmt ist Mist?
Was man bei Grafikkartentests bevorzugt ist sicherlich streitbar.
Für CPU Tests, wo hoffentlich die GPU auf die CPU wartet, sind Programme wie Fraps das Mittel der Wahl, weil sie zeigen wie gleichmäßig die Ausgangsdaten kommen und was die GPU damit macht gehört nicht vorrangig in den Test.
Da Fraps schon seit Ewigkeiten nicht mehr entwickelt wird, ist die Kompatibilität mit DX12 unzureichend. So sieht man das Overlay nicht. Das ist nicht weiter schlimm, da die Messung funktioniert aber in Forca 7 ging auch das nicht. Da muss ich eventuell irgendwann das Tool wechseln.
Auch stürzen AotS und RottR beim Start ab, wenn Fraps offen ist. ich muss erst die Spiele starten und dann erst Fraps.
Art der Messung:
Finden und optimieren einer Spielszene:
Einstellungen anpassen:
Ich habe mich mit der Vega64 erstmal auf einen Mittelweg mit Tendenz zu hohen Einstellungen begeben. Ich habe 1440p eingestellt und versucht die Grafik so zu optimieren, dass ich gut spielbare avg FPS habe bei möglichst guter Optik.
Ich teste also die einzelnen Optionen durch und versuche zu entscheiden wo der subjektiv beste Kompromiss aus Optik und avg FPS liegt.
Beispiele:
Was uns dann zum Thema Grafikkartentreiber bringt.
Zurück zu den Grafikeinstellungen.....
Was meint ihr?
Sollte man in Mischfällen die GPU Auslastung hart senken.... auf Kosten der Optik? Oder das höchste Preset wählen...oder individuell auf Optik gehen? Eine bestimmte avg FPS Zahl anvisieren? Oder alles auf höchste FPS auslegen?
https://www.computerbase.de/forum/t...kussion-zu-spieletests.1728575/#post-20678303
Jedes Spiel hat unterschiedliche Ansprüche an die Art und Länge der Testsequenz und wird stark durch die Einstellungen im Spiel und auch im Grafiktreiber beeinflusst.
Habe ich bei den ersten Punkten noch eine klare Meinung, komme ich gerade bei den Grafikeinstellungen ins grübeln
Anzahl der Messungen:
Das ich es für nötig halte mehrere Messungen je Sequenz zu machen habe ich bereits bei der Diskussion über die Benchmarkszenen deutlich gemacht.
So zerstören z.B. Nachladeruckler die Reproduzierbarkeit der ersten Messung in einigen Spielen.
Anhang anzeigen 653329
Weshalb man diese schonmal aussortieren kann oder nicht in den Durchschnitt einfließen lassen sollte.
Dann sollte man immer über mindestens drei Messungen mitteln. Gerade die Zahl und Stärke von Ausreißern ist sonst nicht zuverlässig abschätzbar. Aber auch für avg FPS ist es wichtig, denn nur so sieht man, wenn einzelne Messungen misslungen sind.
Gerade in CPU Tests, spielen Hintergrundprozesse(meist von Windows) eine große Rolle.
Sucht Windows nach Updates, indiziert eine Festplatte, oder macht sonstwas, dann hat das teils deutliche Einflüsse und sollte nicht der getesteten Hardware angelastet werden.
Daher ist es praktisch, wenn gleich 5 Messungen gemacht werden.
Ich wende dann ein C+ Programm an, um die Mittelwerte und Fehlerabweichungen der drei besten Werte zu bestimmen. So werden Probleme mit bis zu zwei Messungen automatisch herausgefiltert.
Das Mitteln über mehrere Messungen erlaubt auch die Angabe von Fehlerabschätzungen. Eine wichtige Angabe, gerade wenn die Ergebnisse nahe beieinander liegen und so verhindert werden kann, dass Leser diese kleinen Unterschiede zu ernst nehmen.
Auch wenn es eigentlich deutlich mehr Messungen als drei benötigt um zuverlässig zu funktionieren, ist die Angabe einer empirischen Standardabweichung hier der beste Weg.
Bei mehreren Messungen in z.B. RPGs, kann man die Messungen aneinanderreihen indem man Schleifen läuft.
So spart man sich Ladezeiten sowie mögliche Nachladeruckler(wenn beim laden Daten aus dem VRam fliegen).
Dabei muss sichergestellt sein, dass die Messungen nicht driften...so z.B. in City Skylines...hier musste ich jedes Mal neu laden.
So zerstören z.B. Nachladeruckler die Reproduzierbarkeit der ersten Messung in einigen Spielen.
Anhang anzeigen 653329
Weshalb man diese schonmal aussortieren kann oder nicht in den Durchschnitt einfließen lassen sollte.
Dann sollte man immer über mindestens drei Messungen mitteln. Gerade die Zahl und Stärke von Ausreißern ist sonst nicht zuverlässig abschätzbar. Aber auch für avg FPS ist es wichtig, denn nur so sieht man, wenn einzelne Messungen misslungen sind.
Gerade in CPU Tests, spielen Hintergrundprozesse(meist von Windows) eine große Rolle.
Sucht Windows nach Updates, indiziert eine Festplatte, oder macht sonstwas, dann hat das teils deutliche Einflüsse und sollte nicht der getesteten Hardware angelastet werden.
Daher ist es praktisch, wenn gleich 5 Messungen gemacht werden.
Ich wende dann ein C+ Programm an, um die Mittelwerte und Fehlerabweichungen der drei besten Werte zu bestimmen. So werden Probleme mit bis zu zwei Messungen automatisch herausgefiltert.
Das Mitteln über mehrere Messungen erlaubt auch die Angabe von Fehlerabschätzungen. Eine wichtige Angabe, gerade wenn die Ergebnisse nahe beieinander liegen und so verhindert werden kann, dass Leser diese kleinen Unterschiede zu ernst nehmen.
Auch wenn es eigentlich deutlich mehr Messungen als drei benötigt um zuverlässig zu funktionieren, ist die Angabe einer empirischen Standardabweichung hier der beste Weg.
Bei mehreren Messungen in z.B. RPGs, kann man die Messungen aneinanderreihen indem man Schleifen läuft.
So spart man sich Ladezeiten sowie mögliche Nachladeruckler(wenn beim laden Daten aus dem VRam fliegen).
Dabei muss sichergestellt sein, dass die Messungen nicht driften...so z.B. in City Skylines...hier musste ich jedes Mal neu laden.
Man braucht ein Programm zum aufnehmen der Framezeiten und gut definierte Start- und Endzeitpunkte.
Ich nutze dafür Fraps, weil es sehr schlicht gehalten ist und selbst keinen Einfluss auf die Leistung hat.
Ich speichere vor allem die Frametimes und habe mir einen Hotkey eingerichtet.
Je nach Spiel starte und beende ich damit die Messung oder ich stelle eine Zeit ein und starte nur manuell.
Eine feste Zeit ist gerade für integrierte Benchmarks angenehm. In anderen Fällen ist das aber schlecht möglich, weil ich einen festen Satz an Aktivitäten abarbeiten möchte und wenn ich dafür eine Sekunde länger oder kürzer brauche, will ich nicht von der festen Zeit abgewürgt werden oder tatenlos auf das Ende der Messung warten.
In Starcraft 2 und Heroes of the Storm gibt es noch die Besonderheit, dass die ingame Sekunden keinen echten Sekunden entsprechen. Hier sollte man sich fest an den ingame Timer oder die voreingestellte Fraps Benchmarkzeit halten und nicht wechseln.
Ich nutze dafür Fraps, weil es sehr schlicht gehalten ist und selbst keinen Einfluss auf die Leistung hat.
Ich speichere vor allem die Frametimes und habe mir einen Hotkey eingerichtet.
Je nach Spiel starte und beende ich damit die Messung oder ich stelle eine Zeit ein und starte nur manuell.
Eine feste Zeit ist gerade für integrierte Benchmarks angenehm. In anderen Fällen ist das aber schlecht möglich, weil ich einen festen Satz an Aktivitäten abarbeiten möchte und wenn ich dafür eine Sekunde länger oder kürzer brauche, will ich nicht von der festen Zeit abgewürgt werden oder tatenlos auf das Ende der Messung warten.
In Starcraft 2 und Heroes of the Storm gibt es noch die Besonderheit, dass die ingame Sekunden keinen echten Sekunden entsprechen. Hier sollte man sich fest an den ingame Timer oder die voreingestellte Fraps Benchmarkzeit halten und nicht wechseln.
Wenn die Angaben, die ich im Internet finden konnte stimmen, hält Fraps die Zeitpunkte fest wenn die Spieleengine die Daten für einen neuen Frame an die API weitergibt.
Vorrangegangen muss natürlich die Grafikkarte einen neuen Frame angefordert haben.
Zwischen diesem Zeitpunkt und dem erscheinen auf dem Bildschirm vergehen also noch einige Schritte.
Die API und der Treiber müssen arbeiten(Drawcalls beanspruchen soweit ich das verstanden habe erst jetzt Rechenzeit) und die GPU muss das Bild erstmal rendern und dann muss die Bildausgabe es noch losschicken(Monitoreinflüsse ignorieren wir mal).
Seit dem "Skandal" um "Microruckeln" auf multi-GPU Systemen, haben AMD und Nvidia ihren Grafikkarten beigebracht die Abstände zwischen den Frames zu glätten bevor sie zum Monitor gesendet werden.
Sehen kann man diese Funktion über den Vergleich mit FCAT Analysen.
Dabei wird den Frames am Rand ein farbiger Balken als Overlay hinzugefügt. Die Farben wechseln von Frame zu Frame und folgen einer vorbestimmten Schleife, so dass die Reihenfolge klar ist.
Das Monitorsignal wird dupliziert und von einem zweiten PC Frame für Frame aufgenommen, so wie es ein 60Hz Monitor darstellen würde.
Anhand des Overlays kann nun eine genaue Analyse der Aufzeichnung erfolgen, die Länge der Balken entspricht der Frametime(setzt sich auch über mehrere "Monitorbilder" fort und es können extrem kleine "Bildspalten" sogenannte "runts" detektiert werden, die von Fraps als volle Frames gezählt werden, auf dem Monitor aber keinen Mehrwert bieten oder sogar störend wirken sollen.
"drops", sind Frames die zwar an die Grafikkarte weitergegeben wurden, die aber gar nicht ausgegeben werden. Zu erkennen am Überspringen einer Farbe.
Siehe dieser Artikel:
http://techreport.com/review/24553/inside-the-second-with-nvidia-frame-capture-tools/9
Dabei sollte man zwischen Multi-GPU Systemen und single GPU Systemen unterscheiden. Mit mehr als einer GPU sehe ich das beworbene Framepacing positiv.
Aber nicht wirklich bei single GPUs.
Vergleicht man die Fraps Messung der Frametimes mit den FCAT Frametimes zeigt sich eine starke Glättung der Frametimeschwankungen. Die Frames kommen gleichmäßiger auf den Monitor und Fraps ist ein Miesepeter.
Vorrangegangen muss natürlich die Grafikkarte einen neuen Frame angefordert haben.
Zwischen diesem Zeitpunkt und dem erscheinen auf dem Bildschirm vergehen also noch einige Schritte.
Die API und der Treiber müssen arbeiten(Drawcalls beanspruchen soweit ich das verstanden habe erst jetzt Rechenzeit) und die GPU muss das Bild erstmal rendern und dann muss die Bildausgabe es noch losschicken(Monitoreinflüsse ignorieren wir mal).
Seit dem "Skandal" um "Microruckeln" auf multi-GPU Systemen, haben AMD und Nvidia ihren Grafikkarten beigebracht die Abstände zwischen den Frames zu glätten bevor sie zum Monitor gesendet werden.
Sehen kann man diese Funktion über den Vergleich mit FCAT Analysen.
Dabei wird den Frames am Rand ein farbiger Balken als Overlay hinzugefügt. Die Farben wechseln von Frame zu Frame und folgen einer vorbestimmten Schleife, so dass die Reihenfolge klar ist.
Das Monitorsignal wird dupliziert und von einem zweiten PC Frame für Frame aufgenommen, so wie es ein 60Hz Monitor darstellen würde.
Anhand des Overlays kann nun eine genaue Analyse der Aufzeichnung erfolgen, die Länge der Balken entspricht der Frametime(setzt sich auch über mehrere "Monitorbilder" fort und es können extrem kleine "Bildspalten" sogenannte "runts" detektiert werden, die von Fraps als volle Frames gezählt werden, auf dem Monitor aber keinen Mehrwert bieten oder sogar störend wirken sollen.
"drops", sind Frames die zwar an die Grafikkarte weitergegeben wurden, die aber gar nicht ausgegeben werden. Zu erkennen am Überspringen einer Farbe.
Siehe dieser Artikel:
http://techreport.com/review/24553/inside-the-second-with-nvidia-frame-capture-tools/9
Dabei sollte man zwischen Multi-GPU Systemen und single GPU Systemen unterscheiden. Mit mehr als einer GPU sehe ich das beworbene Framepacing positiv.
Aber nicht wirklich bei single GPUs.
Vergleicht man die Fraps Messung der Frametimes mit den FCAT Frametimes zeigt sich eine starke Glättung der Frametimeschwankungen. Die Frames kommen gleichmäßiger auf den Monitor und Fraps ist ein Miesepeter.
Für Grafikkartentests bin ich mir noch nicht sicher wie ich das bewerten soll. FCAT hat seine Vorteile, aber tendenziell bin ich da eher auf der Seite von Fraps.
Zumindest bei CPU Tests ist Fraps aber meiner Meinung nach definitiv vorzuziehen.
Fraps ist der heilige Grahl und FCAT misst Mist.
Es kommt nicht nur auf die Gleichmäßigkeit des Monitorsignals an sondern auch auf den Inhalt der Frames. Die von Fraps festgehaltenen Zeitpunkte für die Frames sind so nah an der Spieleengine wie möglich und damit auch so nah wie möglich an der Ingamezeit.
Um die von FCAT gemessenen Frametimes zu glätten muss die Grafikkarte meinem Verständnis nach alle "normal" ankommende und "normal" gerenderte Frames kurz zurückhalten.
Nur dann kann sie "verspätet" ankommende aber normal gerenderte frames oder "normal" ankommende aber " länger" gerenderte Frames verzögerungsfrei losschicken, damit die Ausgabe regelmäßiger wird...zu schnell fertige oder zu früh ankommende Frames kann sie einfach länger als die normalen zurückhalten.
Dann sieht die Gleichmäßigkeit in FCAT besser aus, aber es wird ein weiterer input delay erzeugt und das Problem wird nur verschoben.
Anstatt einen regelmäßigen Inhalt unregelmäßig darzustellen wird ein unregelmäßiger Inhalt regelmäßig dargestellt!
Was meine ich damit?
Nehmen wir an das die Monitoraktualisierungsrate hoch ist...also kleine zeitliche Abstände gegenüber den zeitlichen Abständen der Frames.
Nehmen wir weiterhin an, in der Ingame Zeit läuft eine schnelle Animation ab....irgendwas geht von rechts nach links durchs Bild...Fraps zeigt in den Frametimes erst normale Abstände, dann einen längeren, gefolgt von kürzeren und dann wieder normale.
Kommen die Frames genau so zum Monitor, sind die Abstände erst gleichmäßig, dann warten wir einen längeren Zeitraum auf das nächste Bild...das Auge ist verwirrt weil das Objekt nicht wie erwartet weiterrückt....und dann taucht das Objekt in größerem Abstand wieder auf.
Zwar an der richtigen Stelle um die Bewegung fortzuführen aber mit einem sichtbaren Sprung...daraufhin folgen kürzere Aktualisierungen, die das Auge als normal ignoriert.
Jetzt kommt das frame pacing ins Spiel und nach den normalen Abständen, die die Grafikkarte verzögert ausgegeben hat, folgt der größere Abstand.
Das frame pacing sendet ihn ohne Verzögerung(nehmen wir an, das es für perfekte Gleichmäßigkeit reicht) aber sein Inhalt ist zeitlich verschoben bezüglich der vorangegangenen Frameinhalte.
Sein Inhalt ist also "aktueller" und verglichen mit den "künstlich gealterten" Inhalten der vorangegangenen Frames zeigt er das Objekt weiter vorne. Die nächsten Abstände sind kürzer und werden künstlich verlängert.
Anstatt eine gleichmäßige Bewegung unterschiedlich abgehackt zu zeigen, sieht es jetzt für das Auge so aus als würde das Objekt erst stark beschleunigen um dann abzubremsen um wieder in Einklang mit der ursprünglichen Bewegung zu kommen.
Was davon besser und angenehmer ist kann ich nicht sagen. Ich würde sagen es ist ähnlich schlecht aber betrachtet man die FCAT Analyse sieht alles super aus und die Animation scheint perfekt dargestellt obwohl sie das nicht ist.
Zumindest bei CPU Tests ist Fraps aber meiner Meinung nach definitiv vorzuziehen.
Fraps ist der heilige Grahl und FCAT misst Mist.
Es kommt nicht nur auf die Gleichmäßigkeit des Monitorsignals an sondern auch auf den Inhalt der Frames. Die von Fraps festgehaltenen Zeitpunkte für die Frames sind so nah an der Spieleengine wie möglich und damit auch so nah wie möglich an der Ingamezeit.
Um die von FCAT gemessenen Frametimes zu glätten muss die Grafikkarte meinem Verständnis nach alle "normal" ankommende und "normal" gerenderte Frames kurz zurückhalten.
Nur dann kann sie "verspätet" ankommende aber normal gerenderte frames oder "normal" ankommende aber " länger" gerenderte Frames verzögerungsfrei losschicken, damit die Ausgabe regelmäßiger wird...zu schnell fertige oder zu früh ankommende Frames kann sie einfach länger als die normalen zurückhalten.
Dann sieht die Gleichmäßigkeit in FCAT besser aus, aber es wird ein weiterer input delay erzeugt und das Problem wird nur verschoben.
Anstatt einen regelmäßigen Inhalt unregelmäßig darzustellen wird ein unregelmäßiger Inhalt regelmäßig dargestellt!
Was meine ich damit?
Nehmen wir an das die Monitoraktualisierungsrate hoch ist...also kleine zeitliche Abstände gegenüber den zeitlichen Abständen der Frames.
Nehmen wir weiterhin an, in der Ingame Zeit läuft eine schnelle Animation ab....irgendwas geht von rechts nach links durchs Bild...Fraps zeigt in den Frametimes erst normale Abstände, dann einen längeren, gefolgt von kürzeren und dann wieder normale.
Kommen die Frames genau so zum Monitor, sind die Abstände erst gleichmäßig, dann warten wir einen längeren Zeitraum auf das nächste Bild...das Auge ist verwirrt weil das Objekt nicht wie erwartet weiterrückt....und dann taucht das Objekt in größerem Abstand wieder auf.
Zwar an der richtigen Stelle um die Bewegung fortzuführen aber mit einem sichtbaren Sprung...daraufhin folgen kürzere Aktualisierungen, die das Auge als normal ignoriert.
Jetzt kommt das frame pacing ins Spiel und nach den normalen Abständen, die die Grafikkarte verzögert ausgegeben hat, folgt der größere Abstand.
Das frame pacing sendet ihn ohne Verzögerung(nehmen wir an, das es für perfekte Gleichmäßigkeit reicht) aber sein Inhalt ist zeitlich verschoben bezüglich der vorangegangenen Frameinhalte.
Sein Inhalt ist also "aktueller" und verglichen mit den "künstlich gealterten" Inhalten der vorangegangenen Frames zeigt er das Objekt weiter vorne. Die nächsten Abstände sind kürzer und werden künstlich verlängert.
Anstatt eine gleichmäßige Bewegung unterschiedlich abgehackt zu zeigen, sieht es jetzt für das Auge so aus als würde das Objekt erst stark beschleunigen um dann abzubremsen um wieder in Einklang mit der ursprünglichen Bewegung zu kommen.
Was davon besser und angenehmer ist kann ich nicht sagen. Ich würde sagen es ist ähnlich schlecht aber betrachtet man die FCAT Analyse sieht alles super aus und die Animation scheint perfekt dargestellt obwohl sie das nicht ist.
Für CPU Tests, wo hoffentlich die GPU auf die CPU wartet, sind Programme wie Fraps das Mittel der Wahl, weil sie zeigen wie gleichmäßig die Ausgangsdaten kommen und was die GPU damit macht gehört nicht vorrangig in den Test.
Da Fraps schon seit Ewigkeiten nicht mehr entwickelt wird, ist die Kompatibilität mit DX12 unzureichend. So sieht man das Overlay nicht. Das ist nicht weiter schlimm, da die Messung funktioniert aber in Forca 7 ging auch das nicht. Da muss ich eventuell irgendwann das Tool wechseln.
Auch stürzen AotS und RottR beim Start ab, wenn Fraps offen ist. ich muss erst die Spiele starten und dann erst Fraps.
Art der Messung:
Integrierter Benchmark oder nachgespielte Szene? Oder eine Videosequenz in Ingame-Grafik?
Gute Frage.
Hier heißt es Ausprobieren....ist ein integrierter Benchmark vorhanden oder eine passende Videosequenz, muss man diese testen und sehen ob sie auch repräsentativ für das eigentliche Spielen ist. Kamerasprünge sind problematisch bei der Auswertung und entsprechen normalerweise nicht dem was beim spielen passiert. Auch gibt es hier tendenziell keinen Input des Spieler oder Berechnungen für KI Gegner.
Was für Benchmarks von Grafikkarten nicht relevant und sogar vorteilhaft ist, bekommt in CPU Tests einen faden Beigeschmack, wenn die Arbeit der CPU durch feste Skripte vereinfacht wird.
Trotz eigentlich fester Skripte bedeuten solche Szenen nicht immer auch reproduzierbare Ergebnisse.
Der Mafia 2 Benchmark zeigt kleine Unterschiede im Ablauf.
Der Dirt Rally Benchmark wechselt teilweise die Kamerapositionen und so sind einige der Messungen super vergleichbar und dann sind wieder welche dabei, die aus der Reihe fallen. Zusätzlich gibt es bei den Sprüngen der Kamerapositionen Ausreißer in den Frametimes, die man beim Spielen nicht hat und auch an bestimmten Stellen kommt es zu Bildfehlern, die ebenfalls beim Spielen nicht da sind.
Ashes of the Singularity reduziert für CPUs mit weniger als 6 Kernen stark die Partikeldichte und deshalb sehen mehr Kerne im Spiel kein Land gegen 4 Kerner....Im integrierten Benchmark wiederum werden die 4 Kerner zu der gleichen höheren Partikeldichte gezwungen und sehen gegen die 6+ Kerner kein Land. Ich habe das nicht selbst getestet...habe aber auch nicht von einer Änderung der Praktik gehört.
Hier von den Entwicklern bestätigt:
http://steamcommunity.com/app/507490/discussions/0/133261369998039885/
Egal was man testet, es ist unbefriedigend. Eine Spieleszene lässt CPUs anders arbeiten und benachteiligt jene, die eigentlich mehr leisten könnten. Und eine Benchmarkszene zeigt die wahren Unterschiede der CPUs, aber davon sieht der Spieler im Spielealltag nichts. Dabei soll hier im integrierten Benchmark korrekte KI Berechnungen und alles ablaufen....sehr schade, dass es dann diese Diskrepanz zum Spielealltag gibt.
Gute Frage
. Hier heißt es Ausprobieren....ist ein integrierter Benchmark vorhanden oder eine passende Videosequenz, muss man diese testen und sehen ob sie auch repräsentativ für das eigentliche Spielen ist. Kamerasprünge sind problematisch bei der Auswertung und entsprechen normalerweise nicht dem was beim spielen passiert. Auch gibt es hier tendenziell keinen Input des Spieler oder Berechnungen für KI Gegner.
Was für Benchmarks von Grafikkarten nicht relevant und sogar vorteilhaft ist, bekommt in CPU Tests einen faden Beigeschmack, wenn die Arbeit der CPU durch feste Skripte vereinfacht wird.
Trotz eigentlich fester Skripte bedeuten solche Szenen nicht immer auch reproduzierbare Ergebnisse.
Der Mafia 2 Benchmark zeigt kleine Unterschiede im Ablauf.
Der Dirt Rally Benchmark wechselt teilweise die Kamerapositionen und so sind einige der Messungen super vergleichbar und dann sind wieder welche dabei, die aus der Reihe fallen. Zusätzlich gibt es bei den Sprüngen der Kamerapositionen Ausreißer in den Frametimes, die man beim Spielen nicht hat und auch an bestimmten Stellen kommt es zu Bildfehlern, die ebenfalls beim Spielen nicht da sind.
Ashes of the Singularity reduziert für CPUs mit weniger als 6 Kernen stark die Partikeldichte und deshalb sehen mehr Kerne im Spiel kein Land gegen 4 Kerner....Im integrierten Benchmark wiederum werden die 4 Kerner zu der gleichen höheren Partikeldichte gezwungen und sehen gegen die 6+ Kerner kein Land. Ich habe das nicht selbst getestet...habe aber auch nicht von einer Änderung der Praktik gehört.
Hier von den Entwicklern bestätigt:
http://steamcommunity.com/app/507490/discussions/0/133261369998039885/
Egal was man testet, es ist unbefriedigend. Eine Spieleszene lässt CPUs anders arbeiten und benachteiligt jene, die eigentlich mehr leisten könnten. Und eine Benchmarkszene zeigt die wahren Unterschiede der CPUs, aber davon sieht der Spieler im Spielealltag nichts. Dabei soll hier im integrierten Benchmark korrekte KI Berechnungen und alles ablaufen....sehr schade, dass es dann diese Diskrepanz zum Spielealltag gibt.
Finden und optimieren einer Spielszene:
Entscheidet man sich für eine nachgespielte Szene, wird es besonders kompliziert.
Für einen CPU Test, empfehle ich eine on-screen-display Einblendung mit mindestens VRam und GPU/CPU Auslastung mitlaufen zu lassen(FPS sowieso und ebenfalls noch einen Frametimegraph) und erstmal eine Weile verschiedene Situationen zu beobachten.
Viele NPCs, viele kämpfende Einheiten, viele Physikeffekte usw. sind in der Regel Dinge die man sucht um eine CPU intensive Szene zu finden. Hier hilft es auch weniger Kerne und weniger CPU Takt zu verwenden, so sieht man eher Unterschiede.
Hat man solche Szenen gefunden, muss herausgefunden werden ob eine Reproduzierbarkeit gegeben ist.
Das heißt einige Male messen und sehen ob es brauchbar ist.
Wenn nein, kann man versuchen die Durchführung durch den Tester zu verbessern.
Mit besser definierten Abläufen, weniger Eingaben oder anderen Verbesserungen.
Eventuell muss die Messzeit erhöht werden um die Schwankungen auszugleichen.
Oder es muss eingesehen werden, dass die Szene nicht geeignet ist und nach anderen Möglichkeiten gesucht werden.
In einigen Spielen ging das so weit, dass ich nur feste Kamerapositionen benutzt habe(Prison Architect und City Skylines).
In anderen Spielen habe ich die Testzeit verlängert(Witcher 3, Witcher 2, AC3).
Gerade in open-world-Spielen kann das Nachladen von Gebieten und automatische Speicherpunkte die Messung stören.
Für einen festen Platz in einem Testparcour sicherlich ungeeignet, aber als Spezialbetrachtung in einem Spiele-Technikcheck durchaus interessant. So habe ich bei Ghost Recon Wildlands(nur kurz an einem Gratiswochenende mit meiner RX Vega angetestet), feststellen können, das ich die Texturen von Ultra bis runter auf Mittel stellen muss um zuverlässig Nachladeruckler beim Autofahren zu vermeiden. Was schade ist, wenn bei Ultra Texturen der VRam kaum halb gefüllt ist und die besseren Texturen sonst keine Mehrleistung fordern.
Mit mehr Zeit hätte hier ein Einfluss der Ram Speed und so weiter interessant sein können. Aber um es mir zu kaufen fand ich das Spiel zu schlecht.
Für einen CPU Test, empfehle ich eine on-screen-display Einblendung mit mindestens VRam und GPU/CPU Auslastung mitlaufen zu lassen(FPS sowieso und ebenfalls noch einen Frametimegraph) und erstmal eine Weile verschiedene Situationen zu beobachten.
Viele NPCs, viele kämpfende Einheiten, viele Physikeffekte usw. sind in der Regel Dinge die man sucht um eine CPU intensive Szene zu finden. Hier hilft es auch weniger Kerne und weniger CPU Takt zu verwenden, so sieht man eher Unterschiede.
Hat man solche Szenen gefunden, muss herausgefunden werden ob eine Reproduzierbarkeit gegeben ist.
Das heißt einige Male messen und sehen ob es brauchbar ist.
Wenn nein, kann man versuchen die Durchführung durch den Tester zu verbessern.
Mit besser definierten Abläufen, weniger Eingaben oder anderen Verbesserungen.
Eventuell muss die Messzeit erhöht werden um die Schwankungen auszugleichen.
Oder es muss eingesehen werden, dass die Szene nicht geeignet ist und nach anderen Möglichkeiten gesucht werden.
In einigen Spielen ging das so weit, dass ich nur feste Kamerapositionen benutzt habe(Prison Architect und City Skylines).
In anderen Spielen habe ich die Testzeit verlängert(Witcher 3, Witcher 2, AC3).
Gerade in open-world-Spielen kann das Nachladen von Gebieten und automatische Speicherpunkte die Messung stören.
Für einen festen Platz in einem Testparcour sicherlich ungeeignet, aber als Spezialbetrachtung in einem Spiele-Technikcheck durchaus interessant. So habe ich bei Ghost Recon Wildlands(nur kurz an einem Gratiswochenende mit meiner RX Vega angetestet), feststellen können, das ich die Texturen von Ultra bis runter auf Mittel stellen muss um zuverlässig Nachladeruckler beim Autofahren zu vermeiden. Was schade ist, wenn bei Ultra Texturen der VRam kaum halb gefüllt ist und die besseren Texturen sonst keine Mehrleistung fordern.
Mit mehr Zeit hätte hier ein Einfluss der Ram Speed und so weiter interessant sein können. Aber um es mir zu kaufen fand ich das Spiel zu schlecht.
Hat man das OSD oder einen zweiten Monitor, kann man den Einfluss der Einstellungen direkt sehen. Ein CPU Test soll meiner Meinung nach nicht im GPU Limit stattfinden. Das kann man als Einzelbeispiel einfügen, aber ein Test der keine Unterschiede zwischen den CPUs zeigt ist wenig hilfreich.
Gerade die Anzahl von NPCs, Sichtweiten und Physikeffekte belasten in der Regel die CPU und sollten hochgeschraubt werden. Auch Partikeleffekte gehen oft auf die CPU.
Kantenglättung, AF, Texturqualität und vieles mehr geht nur auf die GPU. Hier kann es zusätzlich dazu kommen, dass der VRam vollläuft und das sollte möglichst vermieden werden. Denn sonst kommt es zu zusätzlichen Ramzugriffen, die die Vergleichbarkeit zerstören können oder wie in Prey automatisch andere Texturen erzwingen, was dann alles durcheinander bringt.
Die Auflösung ist in der Regel auch nur von der GPU abhängig aber soweit ich weiß gibt es auch davon abhängige Effekte, die auf der CPU laufen und daher kann man das nicht generell sagen.
Generell geben mehr Objekte, mehr oder komplexere Drawcalls und höhere FPS natürlich auch mehr Drawcalls. Das steigert die CPU Last und zeigt eher Unterschiede. Ich würde natürlich versuchen mehr Objekte zu bevorzugen, weil es mehr CPU Last bedeutet.
Aber bei den höheren FPS um jeden Preis, bin ich unschlüssig.
Ist das Spiel auch auf höchsten Einstellungen komplett CPU limitiert dann verwende ich natürlich auch diese Einstellungen.
Mit meiner alten GTX680, musste ich, in neueren Spielen, praktisch immer alle Grafikeinstellungen aufs Minimum stellen und nur die potenziell CPU lastigen Einstellungen hoch halten, um nicht so oft im GPU limit zu hängen.
Aber idealerweise nimmt man für CPU Tests ja eine schnelle GPU und da stellt sich die Frage ob man wirklich alles aufs Minimum setzen sollte, sodass neueste Spiele aussehen wie ums Jahr 2000.
Die neue Vega64 LC bietet mir jetzt die Möglichkeit auch hohe Einstellungen zu wählen, ohne gleich im GPU limit zu hängen.
Sollte man mit dem reduzieren der GPU Last nicht aufhören, wenn man eine gut spielbare Performance erreicht hat?
Oder sollte man es soweit treiben, bis CPU A P99 Werte von 190 FPS erreicht und CPU B 250FPS?
Manch einer wird sagen es zeigt Unterschiede also ist es relevant....andere sagen, das doch niemand merkt und mit Grafikeinstellungen für ca. 120 avg FPS es flüssig ist und beide CPUs das locker schaffen.
Seit ich die RX Vega habe weiß ich nicht wie ich das handhaben soll.
Denn auch diese GPU kann ich in den meisten neuen Spielen in die Knie zwingen und irgendwann sehe ich dann wieder nichts mehr von der CPU oder ich bleibe bei den super niedrigen Einstellungen und teste etwas das realistisch gesehen, so gut wie niemand einstellen würde.
Gerade die Anzahl von NPCs, Sichtweiten und Physikeffekte belasten in der Regel die CPU und sollten hochgeschraubt werden. Auch Partikeleffekte gehen oft auf die CPU.
Kantenglättung, AF, Texturqualität und vieles mehr geht nur auf die GPU. Hier kann es zusätzlich dazu kommen, dass der VRam vollläuft und das sollte möglichst vermieden werden. Denn sonst kommt es zu zusätzlichen Ramzugriffen, die die Vergleichbarkeit zerstören können oder wie in Prey automatisch andere Texturen erzwingen, was dann alles durcheinander bringt.
Die Auflösung ist in der Regel auch nur von der GPU abhängig aber soweit ich weiß gibt es auch davon abhängige Effekte, die auf der CPU laufen und daher kann man das nicht generell sagen.
Generell geben mehr Objekte, mehr oder komplexere Drawcalls und höhere FPS natürlich auch mehr Drawcalls. Das steigert die CPU Last und zeigt eher Unterschiede. Ich würde natürlich versuchen mehr Objekte zu bevorzugen, weil es mehr CPU Last bedeutet.
Aber bei den höheren FPS um jeden Preis, bin ich unschlüssig.
Ist das Spiel auch auf höchsten Einstellungen komplett CPU limitiert dann verwende ich natürlich auch diese Einstellungen.
Mit meiner alten GTX680, musste ich, in neueren Spielen, praktisch immer alle Grafikeinstellungen aufs Minimum stellen und nur die potenziell CPU lastigen Einstellungen hoch halten, um nicht so oft im GPU limit zu hängen.
Aber idealerweise nimmt man für CPU Tests ja eine schnelle GPU und da stellt sich die Frage ob man wirklich alles aufs Minimum setzen sollte, sodass neueste Spiele aussehen wie ums Jahr 2000.
Die neue Vega64 LC bietet mir jetzt die Möglichkeit auch hohe Einstellungen zu wählen, ohne gleich im GPU limit zu hängen.
Sollte man mit dem reduzieren der GPU Last nicht aufhören, wenn man eine gut spielbare Performance erreicht hat?
Oder sollte man es soweit treiben, bis CPU A P99 Werte von 190 FPS erreicht und CPU B 250FPS?
Manch einer wird sagen es zeigt Unterschiede also ist es relevant....andere sagen, das doch niemand merkt und mit Grafikeinstellungen für ca. 120 avg FPS es flüssig ist und beide CPUs das locker schaffen.
Seit ich die RX Vega habe weiß ich nicht wie ich das handhaben soll.
Denn auch diese GPU kann ich in den meisten neuen Spielen in die Knie zwingen und irgendwann sehe ich dann wieder nichts mehr von der CPU oder ich bleibe bei den super niedrigen Einstellungen und teste etwas das realistisch gesehen, so gut wie niemand einstellen würde.
Ich teste also die einzelnen Optionen durch und versuche zu entscheiden wo der subjektiv beste Kompromiss aus Optik und avg FPS liegt.
Beispiele:
Sichtweiten, NPC Häufigkeiten, Tierhäufigkeiten usw. werden weiterhin maximiert.
AF...wenn ich bis 8x noch deutliche Unterschiede sehe aber zu 16x Unterschiede suchen muss, bleibt es auf 8x auch wenn es eventuell kaum/keine Leistung kostet.
Umgebungsverdeckung....Aus, SSAO oder HBAO+? Der Einfluss auf die Atmosphäre ist meiner Meinung nach immens. Aber reicht nicht auch SSAO? Meistens würde ich es als den besseren Kompromiss vorziehen.
und und und...
und Tessellation! Es sieht so viel besser aus, aber kostet leider auch deutlich mehr Leistung. Bei Grafikkartentests müsste man sich jetzt noch Gedanken machen bezüglich der Fairness, falls Nvidia bei der Entwicklung die Finger im Spiel hatte und mit sinnlos hohen Einstellungen versucht AMD zu benachteiligen.
Ich entscheide mich in der Regel für Gelände-Tessellation, aber gegen Hairworks, Turf usw.
AF...wenn ich bis 8x noch deutliche Unterschiede sehe aber zu 16x Unterschiede suchen muss, bleibt es auf 8x auch wenn es eventuell kaum/keine Leistung kostet.
Umgebungsverdeckung....Aus, SSAO oder HBAO+? Der Einfluss auf die Atmosphäre ist meiner Meinung nach immens. Aber reicht nicht auch SSAO? Meistens würde ich es als den besseren Kompromiss vorziehen.
und und und...
und Tessellation! Es sieht so viel besser aus, aber kostet leider auch deutlich mehr Leistung. Bei Grafikkartentests müsste man sich jetzt noch Gedanken machen bezüglich der Fairness, falls Nvidia bei der Entwicklung die Finger im Spiel hatte und mit sinnlos hohen Einstellungen versucht AMD zu benachteiligen.
Ich entscheide mich in der Regel für Gelände-Tessellation, aber gegen Hairworks, Turf usw.
Was uns dann zum Thema Grafikkartentreiber bringt.
Eigentlich offtopic, weil es eben bei wechselnden Grafikkarten wichtig wird, aber es gibt ja inzwischen auch vermehrt Tester, die CPUs mit verschiedenen GPU Kombinationen testen.
So finden sich in den Radeon Einstellungen eine Option zum Tessallations-Modus, der standardmäßig auf "AMD optimiert" steht. Wenn ich das richtig verstanden habe begrenzt es die Tessellations-Stufe auf 16x um Nvidia Gameworks Titel wie The Witcher 3 davon abzuhalten sowas wie 64x zu nutzen und AMD Karten zu benachteiligen.
Ob das nur fair, unfair, oder irgendwas dazwischen ist, will ich ohne weiteres testen nicht sagen, aber wenn Grafikkartenvergleiche gemacht werden, sollte man einen Blick auf diese Optionen werfen.
Auch Freesync ist so eine Sache....eigentlich konnte ich in Spielen keine Nachteile feststellen, aber in 3DMark wurde ich darauf hingewiesen dass es an ist und auch die Scores waren damit schlechter. Das muss ich weiter untersuchen....für CPU Tests würde ich es aber aus lassen.
So finden sich in den Radeon Einstellungen eine Option zum Tessallations-Modus, der standardmäßig auf "AMD optimiert" steht. Wenn ich das richtig verstanden habe begrenzt es die Tessellations-Stufe auf 16x um Nvidia Gameworks Titel wie The Witcher 3 davon abzuhalten sowas wie 64x zu nutzen und AMD Karten zu benachteiligen.
Ob das nur fair, unfair, oder irgendwas dazwischen ist, will ich ohne weiteres testen nicht sagen, aber wenn Grafikkartenvergleiche gemacht werden, sollte man einen Blick auf diese Optionen werfen.
Auch Freesync ist so eine Sache....eigentlich konnte ich in Spielen keine Nachteile feststellen, aber in 3DMark wurde ich darauf hingewiesen dass es an ist und auch die Scores waren damit schlechter. Das muss ich weiter untersuchen....für CPU Tests würde ich es aber aus lassen.
Zurück zu den Grafikeinstellungen.....
Klar sind die Fälle, die absolut CPU limitiert sind. Von meinen Spielen z.B. Starcraft 2, Heroes of the Storm, Prison Architect, Witcher 1, Anno1404, Rome TW....Da kann ich einfach die höchsten Grafikeinstellungen wählen und bin fertig.
Auch relativ klar wird es meiner Meinung nach bei Spielen, die sich nicht für die CPU interessieren. Bei denen man die Grafikeinstellungen so weit runter schrauben kann bis es grottig aussieht und das Spiel trotzdem nichtmal ansatzweise auf andere CPUs reagiert. Diese kann man in einem CPU test rauswerfen...eventuell erwähnen, dass CPUs egal sind und gut.
Aber bei den anderen Spielen, die eine Mischung aus CPU und GPU limit zeigen, wo man mit Grafikeinstellungen diese Limitierungen verschieben kann, da fangen die Probleme an.
Es gibt auch verschieden Typen von Verhalten. Manche wechseln die Limitierung phasenweise...Dirt Rally z.B. ist auf 1440p und mit meinen auf Optik optimierten Einstellungen größtenteils GPU limitiert...aber Stellenweise wechselt das und die GPU ist nur noch 70-90% ausgelastet.
Andere Spiele reagieren subtil. Da is die GPU Auslastung eigentlich bei 98-99% aber je nach CPU Geschwindigkeit verschiebt sich das minimal nach oben oder unten und es zeigen sich doch kleine CPU Auswirkungen. Besonders bei Tests mit Vega zeigt sich, dass leichtes nachlassen in der GPU Auslastung den Takt senkt. Mehr FPS den Takt steigert und viele Einflüsse mehr...es ist einfach schwer vorherzusehen.
Und dann gibt es die Spiele, die "Schluckauf" bekommen. Wie z.B. The Witcher 3 vor allem mit Windows 7. Die avg FPS sind teils gar höher als unter Windows 10, aber in unregelmäßigen Abständen kommt es zu richtigen Unterbrechungen im Spielverlauf.
Die GPU Auslastung zeigt Wechsel von einem GPU limit in ein kurzzeitiges hartes CPU limit und oder Nachladeruckler. Durchaus interessant aber nicht einfach zu messen.
Dieses Theme ist schwer zu reproduzieren und scheint mit neueren Grafikkartentreibern nur noch vermehrt nach deren Installation/update oder so für eine bestimmte Zeit zu existieren.
Auch relativ klar wird es meiner Meinung nach bei Spielen, die sich nicht für die CPU interessieren. Bei denen man die Grafikeinstellungen so weit runter schrauben kann bis es grottig aussieht und das Spiel trotzdem nichtmal ansatzweise auf andere CPUs reagiert. Diese kann man in einem CPU test rauswerfen...eventuell erwähnen, dass CPUs egal sind und gut.
Aber bei den anderen Spielen, die eine Mischung aus CPU und GPU limit zeigen, wo man mit Grafikeinstellungen diese Limitierungen verschieben kann, da fangen die Probleme an.
Es gibt auch verschieden Typen von Verhalten. Manche wechseln die Limitierung phasenweise...Dirt Rally z.B. ist auf 1440p und mit meinen auf Optik optimierten Einstellungen größtenteils GPU limitiert...aber Stellenweise wechselt das und die GPU ist nur noch 70-90% ausgelastet.
Andere Spiele reagieren subtil. Da is die GPU Auslastung eigentlich bei 98-99% aber je nach CPU Geschwindigkeit verschiebt sich das minimal nach oben oder unten und es zeigen sich doch kleine CPU Auswirkungen. Besonders bei Tests mit Vega zeigt sich, dass leichtes nachlassen in der GPU Auslastung den Takt senkt. Mehr FPS den Takt steigert und viele Einflüsse mehr...es ist einfach schwer vorherzusehen.
Und dann gibt es die Spiele, die "Schluckauf" bekommen. Wie z.B. The Witcher 3 vor allem mit Windows 7. Die avg FPS sind teils gar höher als unter Windows 10, aber in unregelmäßigen Abständen kommt es zu richtigen Unterbrechungen im Spielverlauf.
Die GPU Auslastung zeigt Wechsel von einem GPU limit in ein kurzzeitiges hartes CPU limit und oder Nachladeruckler. Durchaus interessant aber nicht einfach zu messen.
Dieses Theme ist schwer zu reproduzieren und scheint mit neueren Grafikkartentreibern nur noch vermehrt nach deren Installation/update oder so für eine bestimmte Zeit zu existieren.
Was meint ihr?
Sollte man in Mischfällen die GPU Auslastung hart senken.... auf Kosten der Optik? Oder das höchste Preset wählen...oder individuell auf Optik gehen? Eine bestimmte avg FPS Zahl anvisieren? Oder alles auf höchste FPS auslegen?
Zuletzt bearbeitet:
