Fallout 4 Version 1.03: Neue Benchmarks - Drawcall-Limit als Fps-Killer

[PCGH-Redaktion]

Jetzt ist Ihre Meinung gefragt zu Fallout 4 Version 1.03: Neue Benchmarks - Drawcall-Limit als Fps-Killer

Nachdem sowohl Nvidia als auch AMD neue Treiber herausgebracht haben und Bethesda das Rollenspiel auf Version 1.3 gepatcht hat, werfen wir einen erneuten Blick auf Fallout 4. Dabei steht uns mit dem Tool ENB-Series erstmals ein Werkzeug zur Verfügung, mit dem sich die Drawcalls auslesen lassen. Somit können wir eine Unbekannte aus der Performance-Gleichung praktisch komplett eliminieren: den berühmt-berüchtigten API-Overhead. Data-Bomb incoming!

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: Fallout 4 Version 1.03: Neue Benchmarks - Drawcall-Limit als Fps-Killer

 

[M4xw0lf]

Ich wiederhole mich, aber diese Engine gehört schon vor Jahren entsorgt.
Was für eine lächerlich inkonsistente Performance da abgeliefert wird.

Btw: was die GPU-load Graphen angeht - ich glaube nicht, dass die Werte der Fury "echt" sind. Vielmehr ist vermutlich die Auslesemethode, mit der die Auslastung bestimmt wird, nicht geeignet. Bei so stark hin und her springender Auslastung müssten sich aller Logik nach die gleichen Sprünge in den Frametimes finden lassen, was aber nicht der Fall ist.
Ist die "Auslastung" vielleicht einfach der anliegende relativ zum maximalen GPU-Takt? Dass der sich je nach Grafiklast stark verändert ist ja bekannt.

Danke für den interessanten Artikel, außerdem

 

[Kyuss89]

Das sind doch Berichte die man als PCGH Leser sehen will! Beide Daumen hoch!

Bin mal gespannt mit welcher Engine die nächsten Spiele von Bethesda rauskommen, Creation hat wirklich seine besten Zeiten hinter sich...

Ist das nächste Spiel nicht Dishonored 2 ?

 

[ravenhearth]

Dishonored 2 wird aber nicht von den Bethesda Game Studios entwickelt, da ist Bethesda nur Publisher. Der erste Teil hat die UE3 benutzt und lief sehr gut.

Für TeS und Fallout brauchen sie einfach eine neue Engine oder müssen Creation wenigstens extrem stark überarbeiten. Ich könnte mir vorstellen dass das mangelhafte Occlusion Culling in Kombination mit der langsamen CPU auch ein Grund für die schlechte Performance auf PS4 und Xbox One ist, Low-Level-APIs zum Trotz.

 

[criss vaughn]

Grandioser Artikel

Zur Frage: Dishonered 1 setzt auf die UE3, daher kann davon ausgegangen werden, dass Dishonored 2 nicht auf die Cryo-Engine setzen wird Zudem wurde beim Trailer Reveal erwähnt, dass die "Void-Engine" (idTech6-Basis) zum Einsatz kommen soll ..

 

[Laggy.NET]

Erstaunlich, wie der Skylake mit 4C4T und 3GHz noch 57 min FPS schafft.

Mein i5 bricht in Der Stadt teilweise auf 40 FPS ein.

Übrigens ist die Schattendistanz hauptverantwortlich für die Einbrüche.

 

[kingkoolkris]

Selbst mit meinem i7-4790k @ 4,6GHz 0 und 2-Way GTX980 SLI @ 1,4GHz gibt's seltene Drops auf 45fps, z.B. auf dem Corvega Assembly Plant. Last auf den beiden Karten ist dabei ~60%.

 

[Kondar]

Erstaunlich, wie der Skylake mit 4C4T und 3GHz noch 57 min FPS schafft.
Mein i5 bricht in Der Stadt teilweise auf 40 FPS ein.
Übrigens ist die Schattendistanz hauptverantwortlich für die Einbrüche.

Skylake mit 4C4T müsste auch ein i5 sein.
Meinst Du ein anderen i5?

@ Creation bzw. Gamebryo
Die Gamebryo wird doch weiterentwickelt warum nicht auf ne akt. Version für FO verwendet?
Die mässige Performace (nur) auf DX11 zu schieben finde ich viel zu einfach.

 

[M4xw0lf]

@ Creation bzw. Gamebryo
Die Gamebryo wird doch weiterentwickelt warum nicht auf ne akt. Version für FO verwendet?
Die mässige Performace (nur) auf DX11 zu schieben finde ich viel zu einfach.

Hm? Das Spiel verwendet doch die "aktuellste" Version der Engine. Aber trotzdem kriegen sie es nicht gebacken, die Drawcalls auf einem einigermaßen konstanten Niveau zu halten, was dann im Zusammenspiel mit DX11 zu den beobachteten Einbrüchen führt. Es liegt also nicht alleine an DX11, sondern vielmehr am veralteten und nicht geeigneten technischen Unterbau der Gamebryo/Creation Engine.

 

[KaneTM]

Sehr schöner Artikel! Danke für die detailierten Ausführungen - was dazugelernt und auch noch gut geschrieben.

 

[Leob12]

Erstaunlich, wie der Skylake mit 4C4T und 3GHz noch 57 min FPS schafft.

Mein i5 bricht in Der Stadt teilweise auf 40 FPS ein.

Übrigens ist die Schattendistanz hauptverantwortlich für die Einbrüche.

40 FPS, ist doch super.
Mein Tiefpunkt waren 12, in der Stadt, ohne das irgendwas los war. Und Drops auf 20 FPS waren auch keine Seltenheit. So macht das Spiel absolut keinen Spaß.

 

[Laggy.NET]

Skylake mit 4C4T müsste auch ein i5 sein.
Meinst Du ein anderen i5?

@ Creation bzw. Gamebryo
Die Gamebryo wird doch weiterentwickelt warum nicht auf ne akt. Version für FO verwendet?
Die mässige Performace (nur) auf DX11 zu schieben finde ich viel zu einfach.

Ich rede vom i5 3470 in meiner Signatur.

Aber da hier einige mit nem i7@ 4,5 GHz ähnliche Probleme haben, scheint PCGH wohl keinen Worst Case gebencht zu haben.

Da spielt man halt schon mal wieder mit dem Gedanken, die CPU mal zu tauschen, aber eigentlich sinnlos, da das Symptom bekämpfung ist und nicht Ursachenbekämpfung, die in dem Fall gravierend ist.

Na ja, es hilft alles nichts, erst wenn DX12 die Muskeln spielen lässt, kann man wieder beurteilen, wie viel CPU Performance nötig ist. Mit dieser DrawCall Limitierung ist das einfach nicht möglich. Mein i5 dümpelt während der Einbrüche bei 60% Last auf allen Kernen herum...

 

[Rolk]

Die eigentliche Benchmarkszene scheint leider immer noch zu fehlen.

 

[g-13mrnice]

Sehr schöner Artikel und großen Respekt für Aufwand und Recherche. Schätze, die Ergebnisse kann man sogar Spieleübergreifend interpretieren? Zum Beispiel CoD. Das die Engine weit über ihrem Zenit ist, war klar. Aber dort kam es ja in den letzten Teilen noch wesentlich krasser zu immensem Speicherhunger und mieser Performance bei durchschnittlicher Optik.

Nur sind neue hauseigene Engine ja leider auch nicht über Nacht hochzuziehen. Sind nicht alle solche Tiere wie die Mannen von PCGH

 

[KI-Pirinha]

Lieber Phillip,
auch wenn alles anschaulich beschrieben ist, werden in dem Artikel doch einige Sachen wie Drawcalls und Polycount durcheinander gewürfelt. Ebenso das was der Scenengraph macht( Drawcalls, approximatives Culling ) und was dann anschließend auf Hardwareebene in der Pipeline( Z-Buffertest, Backface Culling, ....) passiert.
Dem Bus ist es herzlich egal, was die Shader lentzendlich vor der Rasterisierung mit den übergebenen Daten( Lightning, Texturing, Shadowing, ....) machen.

mfg

 

[Deimos]

Toller Artikel!

Btw: was die GPU-load Graphen angeht - ich glaube nicht, dass die Werte der Fury "echt" sind. Vielmehr ist vermutlich die Auslesemethode, mit der die Auslastung bestimmt wird, nicht geeignet. Bei so stark hin und her springender Auslastung müssten sich aller Logik nach die gleichen Sprünge in den Frametimes finden lassen, was aber nicht der Fall ist.
Ist die "Auslastung" vielleicht einfach der anliegende relativ zum maximalen GPU-Takt? Dass der sich je nach Grafiklast stark verändert ist ja bekannt.

Da gibt es sicherlich einige Messungenauigkeiten.
Die Frametimes werden wie ich vermute framegenau mit Fraps erfasst, d.h. auf die Millisekunde genau, während Programme wie Afterburner nur Polling Rates von minimal 100ms hinkriegen.
Selbiges bei GPU-Z.
Wird schon Gründe haben, warum man die Graphen nicht ins selbe Diagramm packt (was grundsätzlich hochinteressant wäre!).


Ich hätte mir schon so oft ein Programm gewünscht, das VRAM-Belegung, GPU-load, usw. auf die Millisekunde genau misst.

 

[Bandicoot]

Tja irgendwann muss mal was neues ran, Schöner Artikel, finde ich auch! Ich glaub das Problem betrifft viele Spiele, nicht nur Fallout.
Ist schon ein bissel wie in der Politik, zu viel Ansturm auf einmal und wo es manchmal herkommt weis keiner!

 

[hauptmann25]

Das liegt doch nicht nur an DX11. So ein Spiel braucht nicht soviele Drawcalls. Das Problem liegt an Bethesdas Faulheit und oder Unachtsamkeit. Beispiel Skyrim und das "Putzen" der Master Files mit "dirty edits" und "deleted references".

Skyrim Mod Tool TES5EDIT : Cleaning your master files (REVISED) - YouTube

Ich kann mir leicht vorstellen dass genau das selbe mit Drawcalls in Fo4 passiert ist. Alten Code hergenommen und nicht gecleaned und alte Drawcalls liegengelassen. Vermutlich sind weniger als 30% der Drawcalls welche die auch wirklich benötigt werden.

 

[Justan Image]

Danke für den großen Aufwand. Bestätigt das, was ich beobachtet habe

Worst-Case-Szenario bei mir ist nach wie vor der Aufzug am Trinity Tower: 15 FPS; dicht gefolgt von Corvega.
Mit 'ner 980 Ti. Anfangs hatte ich eigentlich auch mehr meine CPU (i5 4570) in Verdacht.
Wie hier aufgezeigt wird ist der Schuldige aber ganz klar die sehr veraltete, vermutlich nicht optimierte Engine.

Ich hoffe sehr, das Bethesda für das nächste TES was neues in petto hat

 

[PCGH_Phil]

Lieber Phillip,
auch wenn alles anschaulich beschrieben ist, werden in dem Artikel doch einige Sachen wie Drawcalls und Polycount durcheinander gewürfelt. Ebenso das was der Scenengraph macht( Drawcalls, approximatives Culling ) und was dann anschließend auf Hardwareebene in der Pipeline( Z-Buffertest, Backface Culling, ....) passiert.
Dem Bus ist es herzlich egal, was die Shader lentzendlich vor der Rasterisierung mit den übergebenen Daten( Lightning, Texturing, Shadowing, ....) machen.

mfg

Hi,

Kannst du mir mal spezifisch sagen, was genau du meinst? Mir ist natürlich klar, dass beispielsweise ein hoher Polygoncount nicht gleichzeitig auch eine hohe Anzahl Drawcalls bedeutet, sonst wären wir ja wahrscheinlich schon längst alle in Drawcalls ersoffen
Wenn du das auf den abgebildeten Schutthaufen beziehst, ich wollte nicht, dass man da einen Bezug von Polycount auf Drawcalls herstellt, so wollte ich das nicht verstanden haben - aber das habe ich vielleicht nicht gut genug formuliert. Mir ist eben an ein paar anderen Stellen aufgefallen, dass bei solchen Gebilden häufig auch ein hoher Drawcall-Count vorliegt, das war einfach nur eine Feststellung.

Beim Culling hingegen sehen ich kaum eine andere Erklärung, als dass dieses offenbar massiv mit der Anzahl Drawcalls zusammenhängt. Ich lass mir da aber gern auf die Sprünge helfen

Mir ist auch bewusst, dass es bezogen auf den API-Overhead eher unerheblich ist, was die Drawcalls eigentlich bewirken. Aber offenbar ist das ganze bei Fallout 4 nicht sonderlich geschickt gemacht - Wenn ich mir die Szenen so ansehe, muss ich davon ausgehen, dass die dafü+r nötigen Renderanweisungen alles andere als geschickt gebündelt werden. Ich wage mal zu behaupten, in einer anderen Engine würde man für eine ähnliche Szene weitaus weniger Drawcalls benötigen. Vielleicht wäre das auch mit der Creation Engine möglich, falls dem so wäre, hat das Bethesda aber offenbar nicht hinbekommen oder für nicht erheblich eingestuft. Das kann ich aber nicht beurteilen, dafür fehlt mir die nötige Einsicht und/oder Ahnung.

Wie gesagt, ich lass mich gern belehren, falls sich dazu jemand im Stande hielte.

EDIT: Btw, die Szene ist, wie ihr schon richtig erahnt habt, kein Worst Case. Meine Steam-Cloud wollte mir gestern aus irgendeinem Grund nicht meine daheim erstellten Saves herunterladen, da hatte ich ein paar noch deutlich heftigere Szenarien. Aber die hier ist schon mal ganz gut, vor allem lässt sie sich reproduzierbar ablaufen und so für Benchmarks nutzen, das klappt leider nicht so einfach mit jeder stark limitierenden Szene.

Gruß,
Phil