Baal Netbeck
Fleet Admiral
- Registriert
- Apr. 2008
- Beiträge
- 11.958
Dies ist ein ausgelagertes Thema aus diesem Hauptthread:
https://www.computerbase.de/forum/t...kussion-zu-spieletests.1728575/#post-20678303
Intro:
The Witcher 3 ist eines der großen Rollenspiele der letzten Jahre.
Die Grafik ist überwiegend sehr schön und die Welt riesig und abwechslungsreich.
Die technische Umsetzung ist relativ interessant. Das Spiel braucht viel Grafik Power und ist daher fast immer GPU limitiert.
Wenn viele NPCs in der Nähe sind steigt die Belastung für die CPU deutlich an. Ein einfacher Quadcore kommt hier an seine Grenzen
Dieses Spiel war es auch, dass mich in Richtung von Spielebenchmarks geschubst hat....weil es erst sauber lief und dann irgendwann furchbar ruckelte...Ich scheinbar nicht der einzige war aber niemand eine allgemeingültige Lösung gefunden hat.
Auch jetzt bin ich noch nicht richtig dahinter gekommen wie man dem Problem entgegen tritt.....vor allem weil es vermutlich mehrere Probleme sind.
Dieser Test ist daher der vielschichtigste, weil ich besonders viele Punkte untersuchen wollte um ein vollständigeres Bild zu erhalten.
Die Testkandidaten sind mein Ryzen 1800X in verschiedenen Konfigurationen gegen einen i5 3570K.
Beide mit meiner Vega64 LC(undervolted) gepaart.
In diesem Review zeige ich diverse Aspekte wie:
Einflüsse von 4 vs 8 Kernen, SMT an/aus, Skalierung mit Ramgeschwindigkeit, verschiedene CCX Konfigurationen für Ryzen. IPC Vergleiche, Einfluss des HBCC, Einfluss von CPU und RAM Optimierungen, Windows 7 vs. 10, meine Testszene gegenüber der von CB, Framelimiter und eine Betrachtung der Infinity Fabric Skalierung.
Fangen wir mit meiner Testszene an.
https://www.youtube.com/watch?v=Z6IqAUiVxfo&index=13&list=PLP9fskJGwUOT5CByAJMJrXaggyMuUgsFt
Meine Testszene zeigt Novigrad bei Nacht.
Viele NPCs stehen und laufen herum.
Es gibt Feuer, nahes Wasser, schnelle Kamerabewegungen, Gegner in der Nähe und ich bin zufrieden mit der Reproduzierbarkeit.
Wer die Szene selbst testen möchte findet hier das benutzte savegame sowie eine Anleitung(auf Englisch):
https://drive.google.com/drive/folders/1Hahuj2q234W1LTFi5WLAZOo_uR4tF-qu?usp=sharing
Alle wichtigen Optionen sind dem Video zu entnehmen.
Frametimegraphen:
Hier der Vergleich meines Ryzen 1800X@3,8GHz und des Ivy Bridge i5 mit 4,4GHz
Es gibt Bereiche, wie z.B. am Anfang und gegen Ende, wo der Ryzen und der i5 die gleiche Leistung liefern. Hier sind beide im GPU limit.
Die meisten Bereiche laufen schlechter auf dem i5. Er zeigt höhere Frametimes, mehr Mikroschwankungen sowie öfter auftretende und höhere Peaks....kein Wunder denn er ist immer wieder zu 100% auf allen Kernen ausgelastet.
Doch auch der Ryzen hat immer wieder Peaks, die zwar selten über 16.66ms(unter 60 FPS Grenze) gehen, teilweise aber trotzdem leicht spürbar sind.
Über die drei besten Messungen, aus fünf gemachten, geschah dies im Schnitt 1,4 +- 0,5 mal pro Messung.
Für den i5 waren es 35,1 +- 3,3 mal pro Messung.
Beides zeigt jedoch einen optimalen Fall, bei dem Spiel/Grafiktreiber/Windows was auch immer den Testbereich bereits "gelernt" haben.
Installiert man das Spiel neu, verschiebt es an einen anderen Ort, macht ein Grafikkartentreiber update, ändert im Vega Treiber die HBCC Größe....manchmal reichen auch Windows updates oder Änderungen im Bios...oder auch kein erkennbaren Grund....
.....dann hat man fiese Nachladeruckler, bis die Szene wieder "angelernt" wurde.
Dafür scheint man bis zu 20min durch Novigrad laufen und reiten zu müssen und immer wieder den Testbereich durchlaufen zu müssen, bis man nur noch eine geringe Wahrscheinlichkeit auf diese Nachladeruckler hat.
Wenn man den PC neu gestartet hat und wieder ins Spiel geht, kann es zwar in der Anfangsphase noch vereinzelt ruckeln aber der Lernprozess scheint gut zu wirken und man kann zuverlässig messen...zumindest wenn man eine Methode wie meine verwendet.
Wenn nicht, dann sieht das Ergebnis teilweise so aus:
Ich hatte nebenbei den Ressourcenmonitor offen und scheinbar greift das Spiel bei diesen Rucklern auf verschiedene Dateien zu, die von ein paar MB über mehrere hundert MB bis zu mehreren GB(z.B. texture.cache 3,5GB) groß sind.
Das Spiel ruckelt dann nicht nur, es pausiert praktisch kurz und es stört gewaltig.
Ich habe das Spiel auf zwei schnellen Sata SSDs und auch auf meiner Nvme 960Pro installiert und nichtmal die 960 pro konnte das Problem verhindern...Die Ruckler sind nicht wirklich reproduzierbar, aber ich würde gefühlt noch nicht einmal sagen, dass es mit der 960 besser geworden wäre.
Und das alles auf einem 8 Kerner mit viel mehr Leistung als für das Spiel nötig sein sollte, 32GB 3200MHz CL14 er Ram, der 50000MB/s read schafft(Aida64)...und einer Vega64 LC mit übertakteten 8GB HBM2.
Einem aktuellen Windows 10, das für die Tests sauber installiert und nur mit dem nötigsten ausgerüstet wurde.
HPET war aus und für die Tests war nur Fraps offen(ohne Fraps kommen die Nachladeruckler ebenfalls).
Die Auflösung ist 1440p@144Hz(freesync aus).
Es scheint auch kein AMD Problem zu sein, denn ich hatte solche Probleme schon mit meinem i5 3570K und mit meiner Nvidia GTX 680 bei 1080p @60Hz.... damals liefen Kleinigkeiten anders und die Grafikeinstellungen und Auflösung war anders...deshalb verstecke ich die Beispiele mal in einem Spoiler:
Die gezeigten Frametimeverläufe waren jeweils die zweit besten was die 0.1% low Werte angeht.
Um diesem Auf und Ab der Frametimes eine quantitative Entsprechung zu geben benutze ich eine Reihe statistischer Werte die ich aus der Auswertung von jeweils fünf Messungen gewinne.
Wenn sich trotz "Anlernphase" in bis zu zwei Messungen einzelne Nachladeruckler ergeben sollten, gehen diese nicht in die Ergebnisse ein, weil automatisch die zwei schlechtesten Werte verworfen werden.
Vergleichen wir also die Systeme quantitativ:
i5 vs. Ryzen
Zur Erklärung des Diagramms:
Ich habe direkt eine Reihe Vergleichswerte dargestellt.
Wenig überraschend ist der Ryzen mit vollen 8 Kernen und SMT die schnellste CPU und der i5 mit stock Taktraten die langsamste.
Übertaktet kämpft der i5 mit vier Zen Kernen ohne SMT.
Beim Durchschnitt verliert er, bei den 0.1% low gewinnt er jedoch deutlich.
Geben wir den vier Zen Kernen SMT, reicht das bereits um ihn sehr nah an die Ergebnisse der 8 Kerne zu bringen.
Das sieht man auch schön im Framtetimeverlauf.
Die Verläufe und auch die Frametimepeaks unterscheiden sich nur wenig. Die 4 Kerne mit SMT zeigen leicht größere Schwankungen und die Peaks sind in der Regel minimal größer.
Mit Basis Taktraten und freigegebenem Ram, ist der i5 3570K dann deutlich abgeschlagen und fällt öfter unter die 60 FPS(0.1% low)
Noch schlechtere 0.1% low Werte zeigt nur die 2+2 Konfiguration ohne SMT....wobei die Fehlerbalken zeigen, dass die Unterschiede nicht reproduzierbar genug sind um einen zuverlässigen Unterschied zu erkennen. Eine mögliche Erklärung versuche ich weiter unten zu geben..
Ryzen CCX Konfiguration und SMT
Einige der Ergebnisse kennen wir ja schon aus dem vorherigen Absatz....
So z.B. wie SMT bei 4 Kernen große Verbesserungen bringt. aber nicht ganz an 8 Kerne ran kommt.
Neue Informationen wären:
Mit 8 Kernen und 3,8GHz ist es hingegen egal ob SMT an oder aus ist.
Bei 3200MHz Ram und ohne SMT, liegen die Unterschiede von 2+2 zu 4+0 im Bereich der Messungenauigkeit.
Man könnte einen leichten Vorteil für 4+0 hineininterpretieren.
Die Nachteile durch die Infinity Fabric Komunikation werden also fast vollständig durch den schnellen Ram und den doppelten L3 Cache aufgefangen.
Gegenüber den 8 Kernen liegen beide weit zurück, wie dieses Beispiel an Frametimeverläufen zeigt:
Die 4+0 Konfiguration mit nur 2,8GHz muss sich deutlich geschlagen geben und fällt auf 30 FPS.
Das eine GHz mehr Takt von 2,8 auf 3,8GHz entspricht 36% mehr Takt und bringt 17,2% mehr avg FPS und 30.3% mehr 1% low....Im Durchschnitt fallen die Unterschiede weniger stark auf, weil Teile des Tests weiterhin GPU limitiert laufen.
Erst bei den 1% low Werten sieht man die wahren Vorteile der Taktsteigerung, die hier sehr gut skaliert.
Leistungsaufspaltung beim i5
Es zeigt sich eine starke Abhängigkeit von der Geschwindigkeit des DDR3 Speichers.
So zeigt sich kein Unterschied zwischen einem Stock i5 3570K mit 1600MHz Ram zu einer Übertaktung auf 4,4GHZ mit nur 133MHZ Ram.
Die 133MHz weniger Ram Takt gleichen die 800MHz mehr CPU Takt(i5 3570K hat einen allcore Takt von 3,6GHz) aus!
Gehen wir weitere 133MHz weiter runter auf 1066MHz, verlieren die 4,4GHz sogar gegen die 2,8GHz!
Der Wechsel von 1333 auf 1866 macht also aus dem 40% schnelleren Ram 22,9% mehr avg FPS aus und 24,3% mehr 1% low.
Von 2,8 zu 4,4GHz sind es 57% mehr Takt. Dies führt zu einer Steigerung der avg FPS von 34,5% und 44,5% bei den 1% low.
Ein starker Gewinn durch schnelleren Ram und ebenfalls ein guter Gewinn bei den 1% low durch mehr Takt.
IPC Vergleich
Drei mal vier Kerne, ohne HT/SMT, bei 2,8GHz im Vergleich.
Wie schon vorher gesehen haben die vier Zen Kerne ohne SMT Probleme bei den 0.1% low Werten...sie zeigen also mehr/höhere Frametimepeaks.
Doch auch im klassischen Durchschnitt sind die Ergebnisse nicht so gut wie in anderen Spielen.
Mit 2133MHz liegen Zen und ivy Bridge gleichauf. Erst der schnelle Ram bringt einen deutlichen Unterschied.
Die Zen Kerne aus der 1000er Serie zeigt also erst dann eine deutlich bessere IPC, wenn schneller Ram verwendet wird.
Und hat mehr Probleme mit Frametimepeaks.
DDR3 Ram Skalierung
Wie schon vorher gesehen, reagiert The Witcher 3 mit dem i5 3570K gut auf schnellen Ram.
Der Wechsel von 1066 auf 1866 MHz macht aus dem 75% schnelleren Ram ganze 43,6% mehr avg FPS und 44,1% mehr 1% low.
Die 0.1% low steigen um 43,6%.
Der Verlauf lässt erahnen, dass die Skalierung noch gut zu höheren Taktraten weiter geht.
Mit langsamem Ram ist The Witcher 3 damit deutlich schlechter zu spielen....zumindest in einer solchen Szene mit vielen NPCs.
DDR4 Ram Skalierung
Da wir mit 8 Kernen praktisch die ganze Zeit im GPU limit laufen, zeigen sich durch schnelleren Ram kaum Unterschiede. Selbst die 0.1% low Werte verbessern sich nur leicht.
Das Ram OC verhindert also keine Frametimepeaks...es schwächt sie nur minimal ab.
Zusätzlich zu den Werten mit 8 Kernen habe ich noch vier Datenpunkte für 4 Kerne beigefügt.
In Gold die Werte für die avg FPS und in Türkis die Werte für die 1% low bei 4 Zen Kernen ohne SMT.
Der Wechsel von 2133 auf 3200 MHz macht aus dem 50% schnelleren Ram mit 8 CPU Kernen nur 1,2% mehr avg FPS und 3,6% mehr 1% low.
Die 0.1% low steigen um magere 5%.
Bei 4 CPU Kernen(2+2) sind die Steigerungen besser.
Die avg FPS steigen um 17,9%, die 1% low um 17,8% und die 0.1% low um 11,3%.
HBCC settings
Alle Werte liegen innerhalb der Messungenauigkeit....Das Spiel reagiert gar nicht auf die Veränderung des zugewiesenen Speichers.
Ryzen optimieren und übertakten
Obwohl meine Optimierung immerhin 100MHz mehr allcore Takt liefert und auch der Ram durch die Subtimings 9,6% mehr Leserate hat, lassen sich kaum Unterschiede zu Stock Taktraten mit docp Profil messen.
Das liegt sicherlich an dem mit 8 Kernen fast durchgängig vorhandenen GPU limit. Erst im rechten Bereich zeigen sich minimale Vorteile durch die Optimierungen.
Wenn man bedenkt, dass man sich am GPU limit bewegt, fallen die Unterschiede der Bios default Einstellungen stärker aus als ich gedacht hätte.
Es sind immer noch keine deutlichen Unterschiede aber sie sind zuverlässig messbar.
Einfuss von Ramtakt auf den Infinity Fabric
Hintergrund:
Ganz wichtig sind hier die Fehlerbalken!
Die geringen Unterschiede von 2+2 zu 4+0 Konfiguration sorgen für relativ große Fehlerbalken im Vergleich zu den errechneten Daten.
Es folgen daraus also keine sonderlich vertrauenserweckenden Ergebnisse.
Das Verhalten gleicht aber dem was ich schon in einigen anderen Spielen feststellen konnte.
Im oberen Bereich bei den durchschnittlichen FPS bewirkt der schnellerer IF eine Steigerung der FPS.
Im unteren Bereich kehrt sich das Bild um.
Meine Theorie ist, dass zwar weiterhin der schnellere IF den 2+2 hilft schneller Drawcalls usw. zu bearbeiten, es jedoch einen viel größeren Effekt gibt, der dies verdeckt.
Der untere Bereich zeigt mehr von Frametimeschwankungen und Frametimepeaks.
Und bei 4+0 müssen sich 4 Kerne 8MB L3 Cache teilen, während bei 2+2 jeweils zwei Kerne sich 8MB teilen.
Die doppelte Menge an L3 Cache federt viel besser den langsamen Ram ab und das führt dazu, dass 2+2 weniger unter der gesunkenen Ram Geschwindigkeit leidet.
Die Folge sind größere Gewinne durch schnellen Ram bei 4+0 bzw. weniger Verluste durch langsamen Ram bei 2+2.
Irgendjemand müsste mal einen Ryzen 3 1200 mit der gleichen Methode gegen die 4+0 messen. Denn der 1200 hat eine 2+2 Konfiguration aber nur 4MB für zwei je zwei Kerne aktiv.
Es macht sicherlich noch Unterschiede, ob sich vier 8MB teilen oder zwei 4MB....aber es wäre deutlich besser zu vergleichen.....selbst kaufen fand ich für so ein Experiment etwas zu teuer....Mindfactory will 79€ haben und Ebay mindestgebot 50€ oder 75€ Sofortkauf....muss nicht sein.
Windows 10 vs. 7
Wie man sieht hat Window 7 keinen guten Stand gegenüber Windows 10.
Auch wenn die avg FPS teilweise minimal besser sind, läuft The Witcher 3 unter Windows 7 tendenziell schlechter und gerade bei den 0.1% low Werten fällt es deutlich ab.
Wie man den Frametimeverläufen entnehmen kann, sind die Frametimeschwankungen minimal stärker und es gibt mehr Frametimepeaks.
Schauen wir uns die Skalierung mit CPU Takt und Ramtakt unter Windows 7 an:
Es scheint keine qualitativen Unterschiede zum Verhalten bei Windows 10 zu geben.
CPU Takt bleibt wichtig und Ram Takt ist sehr wichtig.
Windows 7 scheint dabei die gleichen Probleme für den i5 zu machen wie wir sie vorher bei 4 Zen Kernen ohne SMT gesehen haben.
Es kommt vermehrt zu Frametimepeaks, die die 0.1% low Werte verschlechtern.
Die Peaks sind allerdings nicht so schlimm wie die Nachladeruckler, über die ich am Anfang geredet habe.
Im nächsten Absatz suche ich nach eine Lösung.
Frametimelimiter
The Witcher 3 bringt von Haus aus die Möglichkeit mit, die FPS auf 60 oder 30 zu limitieren.
Warum sollte man sowas überhaupt machen wollen?
Ein legitimer Grund kann sein, dass man Strom sparen und seinen PC leiser laufen lassen möchte.
Wer eigentlich 70+ FPS erreichen würde, aber der Meinung ist, dass ihm auch 60 oder gar 30 reichen kann so die Arbeit für den PC deutlich senken.
Die Arbeit für den PC senken kann jedoch auch weitere Vorteile haben.
Wenn die FPS hoch sind, müssen öfter die Drawcalls von der CPU abgearbeitet werden und die CPU Belastung steigt.
Gerade bei nur vier Kernen und in solch CPU intensiven Testszenen entlastet dies die CPU(vor allem den RenderThread bei AMD+ DX11).
Eine starke Grafikkarte oder niedrige Einstellungen sorgen zwar für mehr avg FPS und auf den ersten Blick eine bessere Performance, aber es kann dazu kommen, dass einzelne CPU Kerne oder gar die ganze CPU durch die zusätzliche Arbeit überlastet werden und dann wichtige Berechnungen nicht rechtzeitig fertigstellen können.
Es kommt zu mehr Rucklern als mit weniger FPS!
Das zeigt sich auch teilweise in anderen Spielen. Hier ein Video wo darüber im Falle von GTA V berichtet wird:
Man könnte die Grafikeinstellungen erhöhen und damit die FPS drücken, jedoch fällt es schwerer eine Balance zu finden.
Nicht nur die Anforderungen an die CPU ändern sich je nach Spielsituation, auch die Anforderungen an die Grafikkarte schwanken.
Läuft es in einer Szene mit 60 FPS im GPU limit, kann eine andere Szene (auch im GPU limit) nur noch 45 FPS erreichen und dann fühlt es sich unsauber an wegen der Grafikkarte.
Ein limitieren der FPS bei Grafikeinstellungen für höhere FPS entspannt die Situation und sollte überall eine konstante Leistung bieten.
Ich habe meine Untersuchungen mit limitierten FPS auf dem i5 3570K und unter Windows 7 gemacht, weil sich hier zuverlässig einzelne Ruckler, auch in die guten Frametimemessungen verirrt haben.
Ich hätte vermutlich auch den Ryzen mit vier Kernen und ohne SMT nehmen können. Das Verhalten scheint das gleiche zu sein.
Fangen wir mit der Übertaktung auf 4,4GHz und 1866er DDR3 Ram an:
Wie man sieht zwingt der 60 FPS limiter wie erwartet die Frametimes um eine Linie bei 16,66 ms.
Es ist leider kein perfekter Verlauf aber man sieht, wie der Bereich der Schwankungen schmaler wird.
Und auch wenn es immer noch einige Peaks gibt, die mit ihren um die 25 ms je nach Empfindlichkeit des Spielers sichtbar sind, so bleiben doch die einzelnen großen Peaks wie sie die unlimitierte Messung zeigt aus.
Ein ähnliches Bild zeigt sich bei stock Taktraten und 1600er Ram:
Die Frametimes der unlimiterten Messung wandern näher an die 16,66 ms heran und wo sie sich überschneiden, werden die Frametimeschwankungen der auf 60 FPS begrenzten Messung wieder größer.
Trotzdem verhindert die Limitierung relativ gut die großen Frametimepeaks.
Die gezeigten Frametimegraphen waren jeweils die zweitbeste aus Messungen was die 0.1% low Werte angeht.
Um nicht zu viel in Einzelmessungen zu interpretieren, vergleiche ich jetzt wieder die gemittelten Statistikwerte aus den besten drei.
Logischerweise zeigt die Limitierung auf 60 FPS große generelle Einbußen.
Was uns jedoch interessiert sind die 0.1% low und hierliegen beide gleichauf.
Das ist etwas entäuschend, waren doch die Frametimegraphen der Einzelmessungen sehr vielversprechend.
Wären die Fehlerbalken nicht so groß, würde es jedoch nach eine kleinen Sieg für den Frametimelimiter aussehen.
Gucken wir uns also die Stock Taktraten an:
Das sieht in der Tat gut aus.
Weil die avg FPS ohne limiterung nicht ganz so hoch ausfallen, sind die generellen Verluste geringer und der Sieg bei den 0.1% low Werten zeigt, dass die FPS Limitierung hier die gewünschte Wirkung zeigt.
Senken wir den CPU Takt auf 2,8GHz, nutzen aber schnellen Ram:
Auch unlimitiert schafft der i5 jetzt nur knapp über 70 avg FPS.
Der Einfluss der Limitierung schwindet also und auch wenn es so aussieht, als würde es bei den 0.1% low weiterhin einen kleinen Vorteil für den limiter geben reicht die Reproduzierbarkeit nicht aus um dies zu bestätigen.
Senken wir auch noch den Ram Takt:
Jetzt sinken die FPS unter das 60 FPS limit und das Vorhaben wird nutzlos.
Mit Limitierung liegt alles minimal niedriger, was vermutlich auf einzelne gute Frametimes zurückzuführen ist, die eingentlich den Schnitt leicht heben und jetzt eingebremst werden.
Es gibt ja auch noch die 30 FPS Einstellung also gucken wir uns diese an:
Hier vergleiche ich nur meine schnellste und die langsamste Version der ivy Bridge i5.
Denn schlechter als unlimitiert oder mit 60 FPS Begrenzung läuft es sowieso.
Die Frage war hier eher ob man überhaupt Unterschiede findet obwohl die Grenze so niedrig liegt.
Wie man sieht gibt es diese durchaus.
Mit schnellerer CPU und mit mehr Ramtakt ist es also weiterhin besser möglich die Frametimes stabil zu halten.
-------------------------
Es lohnt sich also durchaus darüber nachzudenken solche Limiter zu nutzen.
In diesen Tests zu The Witcher 3 waren die Vorteile allerdings auf einen speziellen Bereich beschränkt. Die CPU durfte nicht zu langsam sein aber auch nicht zu schnell, damit es sich gelohnt hat.
Es wäre eventuell praktisch weitere Abstufungen zu testen. Ein Limit auf 75 FPS für schnelle CPUs oder 45-50FPS für langsame CPUs wäre meiner Meinung nach ideal....am besten einfach individuell wählbar.
Es gibt ja auch externe Limiter aber diese kommen oft mit anderen Problemen daher.
Vergleich von zwei Testszenen.
Computerbase hat inzwischen The Witcher 3 aus ihrem CPU Testparcour entfernt.
2017 war es aber noch Bestandteil und wurde als Beispiel aufgeführt, für ein völlig GPU limitiertes Spiel.
Im Test zum i3 7350K anfang 2017 gewinnt dieser mit leichtem Vorsprung den The Witcher 3 Test bei 1080p mit einer übertakteten GeForce GTX 980 Ti.
Eine zwei Kern/4Thread CPU mit 4,2GHz stock Takt gewinnt gegen i7 7700K und alles andere.
Eine Übertaktung auf 5,1GHz bringt nur 0,2% mehr Leistung und ein i5 2500K(allcore Boost 3,4GHz), der sogar ein paar Prozent langsamer sein sollte als mein i5 3570K liegt nur 5 % zurück.
Quelle: https://www.computerbase.de/2017-01/intel-core-i3-7350k-test-overclocking/5/#diagramm-the-witcher-3-high-end-gpus-im-vergleich
Der ganze Test schreit danach das es sich hier um ein Spiel handelt, dass so gut wie gar keine Ansprüche an die CPU stellt und keine Vorteile aus mehr CPU Kernen zieht.....das schreibt CB zumindest im Zusammenhang mit mittelklasse CPUs:
"In The Witcher 3 liegen alle CPUs sehr dicht beisammen, die Wahl der CPU ist praktisch irrelevant."
Das passt nicht mit meinen Ergebnissen zusammen und daher ist es interessant die genutzten Testsequenzen einmal genauer anzuschauen:
Hier kann man sich die Testszene von CB angucken:
https://www.computerbase.de/2015-10...tem-amd-intel-2015/3/#abschnitt_the_witcher_3
Und so habe ich versucht die Testszene nachzustellen:
https://www.youtube.com/watch?v=RRzarVOZGqg&index=12&list=PLP9fskJGwUOT5CByAJMJrXaggyMuUgsFt
Es ist sicherlich nicht perfekt, ich laufe am "Strand" etwas zu mittig und gehe weniger gradlinig aber das sollte nur minimale Unterschiede machen.
Auch nutze ich nicht die höchsten Grafikeinstellungen und eine stärkere GPU. Es sollten sich also eher mehr Unterschiede zeigen als bei CB, die nur um die 70 FPS erreicht haben, wo meine Systeme um die 100 FPS schaffen.
Schauen wir uns also meine Ergebnisse in dieser Testszene an.
Die i5 füttern die Vega64 scheinbar minimal schneller mit Daten, so dass selbst die 2,8GHz gegen den Ryzen gewinnt.
Hier wäre ein 2700X interessant um zu sehen ob die verbesserten Latenzen von Zen+ dies ausgleichen.
Der ganze rechte Bereich zeigt hingegen keine Unterschiede mehr zwischen dem Ryzen und dem übertakteten i5.
Mit nur 2,8GHz muss der i5 hier etwas federn lassen, hält aber immer noch die 60FPS.
Auch mit meinem Aufbau sehe ich also in dieser nachgestellten CB Testszene die gleichen Ergebisse wie CB.
Solange die CPU nicht total langsam ist, scheint sie ziemlich egal.
Schauen wir uns die Ergebnisse im Vergleich zu meiner Testszene aus Novigrad an.
Erstmal nur für den i5:
Die beiden oberen Daten(hellere Farben) haben wir schon im vorherigen Diagramm sehen können.
Neu sind die etwas dunkleren Farben, die meiner Testszene entspringen.
Wo bei der CB Szene die 1,6GHz weniger Takt trotzdem die gleichen avg FPS schaffen und nur etwas mehr Frametimeschwankungen haben, fallen die Unterschiede in meiner Szene deutlich aus.
Die generelle Performance ist geringer und der Unterschied zu 2,8GHz sind gewaltig.
....Weiter im nächten Beitrag....
https://www.computerbase.de/forum/t...kussion-zu-spieletests.1728575/#post-20678303
Intro:
The Witcher 3 ist eines der großen Rollenspiele der letzten Jahre.
Die Grafik ist überwiegend sehr schön und die Welt riesig und abwechslungsreich.
Die technische Umsetzung ist relativ interessant. Das Spiel braucht viel Grafik Power und ist daher fast immer GPU limitiert.
Wenn viele NPCs in der Nähe sind steigt die Belastung für die CPU deutlich an. Ein einfacher Quadcore kommt hier an seine Grenzen
Dieses Spiel war es auch, dass mich in Richtung von Spielebenchmarks geschubst hat....weil es erst sauber lief und dann irgendwann furchbar ruckelte...Ich scheinbar nicht der einzige war aber niemand eine allgemeingültige Lösung gefunden hat.
Auch jetzt bin ich noch nicht richtig dahinter gekommen wie man dem Problem entgegen tritt.....vor allem weil es vermutlich mehrere Probleme sind.
Dieser Test ist daher der vielschichtigste, weil ich besonders viele Punkte untersuchen wollte um ein vollständigeres Bild zu erhalten.
Die Testkandidaten sind mein Ryzen 1800X in verschiedenen Konfigurationen gegen einen i5 3570K.
Beide mit meiner Vega64 LC(undervolted) gepaart.
In diesem Review zeige ich diverse Aspekte wie:
Einflüsse von 4 vs 8 Kernen, SMT an/aus, Skalierung mit Ramgeschwindigkeit, verschiedene CCX Konfigurationen für Ryzen. IPC Vergleiche, Einfluss des HBCC, Einfluss von CPU und RAM Optimierungen, Windows 7 vs. 10, meine Testszene gegenüber der von CB, Framelimiter und eine Betrachtung der Infinity Fabric Skalierung.
Fangen wir mit meiner Testszene an.
https://www.youtube.com/watch?v=Z6IqAUiVxfo&index=13&list=PLP9fskJGwUOT5CByAJMJrXaggyMuUgsFt
Meine Testszene zeigt Novigrad bei Nacht.
Viele NPCs stehen und laufen herum.
Es gibt Feuer, nahes Wasser, schnelle Kamerabewegungen, Gegner in der Nähe und ich bin zufrieden mit der Reproduzierbarkeit.
Wer die Szene selbst testen möchte findet hier das benutzte savegame sowie eine Anleitung(auf Englisch):
https://drive.google.com/drive/folders/1Hahuj2q234W1LTFi5WLAZOo_uR4tF-qu?usp=sharing
Alle wichtigen Optionen sind dem Video zu entnehmen.
Frametimegraphen:
Hier der Vergleich meines Ryzen 1800X@3,8GHz und des Ivy Bridge i5 mit 4,4GHz
Es gibt Bereiche, wie z.B. am Anfang und gegen Ende, wo der Ryzen und der i5 die gleiche Leistung liefern. Hier sind beide im GPU limit.
Die meisten Bereiche laufen schlechter auf dem i5. Er zeigt höhere Frametimes, mehr Mikroschwankungen sowie öfter auftretende und höhere Peaks....kein Wunder denn er ist immer wieder zu 100% auf allen Kernen ausgelastet.
Doch auch der Ryzen hat immer wieder Peaks, die zwar selten über 16.66ms(unter 60 FPS Grenze) gehen, teilweise aber trotzdem leicht spürbar sind.
Über die drei besten Messungen, aus fünf gemachten, geschah dies im Schnitt 1,4 +- 0,5 mal pro Messung.
Für den i5 waren es 35,1 +- 3,3 mal pro Messung.
Beides zeigt jedoch einen optimalen Fall, bei dem Spiel/Grafiktreiber/Windows was auch immer den Testbereich bereits "gelernt" haben.
Installiert man das Spiel neu, verschiebt es an einen anderen Ort, macht ein Grafikkartentreiber update, ändert im Vega Treiber die HBCC Größe....manchmal reichen auch Windows updates oder Änderungen im Bios...oder auch kein erkennbaren Grund....
.....dann hat man fiese Nachladeruckler, bis die Szene wieder "angelernt" wurde.
Dafür scheint man bis zu 20min durch Novigrad laufen und reiten zu müssen und immer wieder den Testbereich durchlaufen zu müssen, bis man nur noch eine geringe Wahrscheinlichkeit auf diese Nachladeruckler hat.
Wenn man den PC neu gestartet hat und wieder ins Spiel geht, kann es zwar in der Anfangsphase noch vereinzelt ruckeln aber der Lernprozess scheint gut zu wirken und man kann zuverlässig messen...zumindest wenn man eine Methode wie meine verwendet.
Wenn nicht, dann sieht das Ergebnis teilweise so aus:
Ich hatte nebenbei den Ressourcenmonitor offen und scheinbar greift das Spiel bei diesen Rucklern auf verschiedene Dateien zu, die von ein paar MB über mehrere hundert MB bis zu mehreren GB(z.B. texture.cache 3,5GB) groß sind.
Das Spiel ruckelt dann nicht nur, es pausiert praktisch kurz und es stört gewaltig.
Ich habe das Spiel auf zwei schnellen Sata SSDs und auch auf meiner Nvme 960Pro installiert und nichtmal die 960 pro konnte das Problem verhindern...Die Ruckler sind nicht wirklich reproduzierbar, aber ich würde gefühlt noch nicht einmal sagen, dass es mit der 960 besser geworden wäre.
Und das alles auf einem 8 Kerner mit viel mehr Leistung als für das Spiel nötig sein sollte, 32GB 3200MHz CL14 er Ram, der 50000MB/s read schafft(Aida64)...und einer Vega64 LC mit übertakteten 8GB HBM2.
Einem aktuellen Windows 10, das für die Tests sauber installiert und nur mit dem nötigsten ausgerüstet wurde.
HPET war aus und für die Tests war nur Fraps offen(ohne Fraps kommen die Nachladeruckler ebenfalls).
Die Auflösung ist 1440p@144Hz(freesync aus).
Es scheint auch kein AMD Problem zu sein, denn ich hatte solche Probleme schon mit meinem i5 3570K und mit meiner Nvidia GTX 680 bei 1080p @60Hz.... damals liefen Kleinigkeiten anders und die Grafikeinstellungen und Auflösung war anders...deshalb verstecke ich die Beispiele mal in einem Spoiler:
Hier ein Beispiel, wo ich von meinem i5 mit GTX 680 unter Windows 7 auf Ryzen 1800X mit der gleichen GTX 680 unter Windows 10 gewechselt bin:
Mit dem i5 war The Witcher 3 praktisch unspielbar gewesen...und ich war Happy wie der Ryzen so unglaublich viel besser lief.
Hier ein Beispiel, wo ich den i5 + GTX 680 mit Windows 10 probiert habe und plötzlich war es ebenfalls viel besser:
Dann hatte ich geschlussfolgert, dass es die Schuld von Windows 7 gewesen sein muss.
Ich hatte extra eine frische Windows 7 installation genutzt(das Spiel aber nicht angelernt) und sah wieder die gleichen Probleme.....Problem gefunden dachte ich damals.
Was ich inzwischen widerlegen konnte....wäre auch komisch gewesen, wenn niemand unter Windows 7 eine größere NPC Ansammlung hätte besuchen können.
Ich greife das Thema "Win 7 vs. Win 10" etwas vor und zeige schonmal diesen Vergleich mit dem i5 und Vega64:
wie man sieht ist Windows 7 etwas schlechter aber nicht generell für die Nachladeruckler verantwortlich.
Eventuell war der vorherige Nvidia Treiber unter Windows 7 nicht "lernfähig" oder sowas...ich weiß es nicht.
Weitere Beispiele wären z.B. von CB selbst.
Quelle:( https://www.computerbase.de/2017-03...cher-3-frametimes-ryzen-7-1800x-gegen-fx-8370 )
CB nutzt eine sehr anspruchslose Testszene und umso verwunderlicher ist es, hier überhaupt solche Probleme zu sehen....dazu weiter unten mehr.
oder in diesem Video von Digital Foundry:
https://youtu.be/4RMbYe4X2LI?t=4m6s
Bei 4:09 hat der i5 7600 einen heftigen Frametimepeak(bei Digital Foundry von oben nach unten), zwei Sekunden später folgen die beiden Ryzen.
Oder an dieser Stelle, wenn Gerald in die Stadt reitet:
https://youtu.be/Rutk9ErhKG4?t=3m41s
Diverse Foren sind ebenfalls voll mit Leuten die über starke Ruckler klagen und mal hilft ihnen nichts und mal berichten sie von Wunderheilung aber immer mit unterschiedlichen Lösungen:
Wie ich oben schon angemerkt habe gibt es auch weitere Probleme, in die man laufen kann.
Das soll es dazu erstmal gewesen sein, konzentrieren wir uns wieder auf die eigentliche Performance des Spiels....
Mit dem i5 war The Witcher 3 praktisch unspielbar gewesen...und ich war Happy wie der Ryzen so unglaublich viel besser lief.
Hier ein Beispiel, wo ich den i5 + GTX 680 mit Windows 10 probiert habe und plötzlich war es ebenfalls viel besser:
Dann hatte ich geschlussfolgert, dass es die Schuld von Windows 7 gewesen sein muss.
Ich hatte extra eine frische Windows 7 installation genutzt(das Spiel aber nicht angelernt) und sah wieder die gleichen Probleme.....Problem gefunden dachte ich damals.
Was ich inzwischen widerlegen konnte....wäre auch komisch gewesen, wenn niemand unter Windows 7 eine größere NPC Ansammlung hätte besuchen können.
Ich greife das Thema "Win 7 vs. Win 10" etwas vor und zeige schonmal diesen Vergleich mit dem i5 und Vega64:
wie man sieht ist Windows 7 etwas schlechter aber nicht generell für die Nachladeruckler verantwortlich.
Eventuell war der vorherige Nvidia Treiber unter Windows 7 nicht "lernfähig" oder sowas...ich weiß es nicht.
Weitere Beispiele wären z.B. von CB selbst.
Quelle:( https://www.computerbase.de/2017-03...cher-3-frametimes-ryzen-7-1800x-gegen-fx-8370 )
CB nutzt eine sehr anspruchslose Testszene und umso verwunderlicher ist es, hier überhaupt solche Probleme zu sehen....dazu weiter unten mehr.
oder in diesem Video von Digital Foundry:
https://youtu.be/4RMbYe4X2LI?t=4m6s
Bei 4:09 hat der i5 7600 einen heftigen Frametimepeak(bei Digital Foundry von oben nach unten), zwei Sekunden später folgen die beiden Ryzen.
Oder an dieser Stelle, wenn Gerald in die Stadt reitet:
https://youtu.be/Rutk9ErhKG4?t=3m41s
Diverse Foren sind ebenfalls voll mit Leuten die über starke Ruckler klagen und mal hilft ihnen nichts und mal berichten sie von Wunderheilung aber immer mit unterschiedlichen Lösungen
:Wie ich oben schon angemerkt habe gibt es auch weitere Probleme, in die man laufen kann.
Das soll es dazu erstmal gewesen sein, konzentrieren wir uns wieder auf die eigentliche Performance des Spiels....
Um diesem Auf und Ab der Frametimes eine quantitative Entsprechung zu geben benutze ich eine Reihe statistischer Werte die ich aus der Auswertung von jeweils fünf Messungen gewinne.
Wenn sich trotz "Anlernphase" in bis zu zwei Messungen einzelne Nachladeruckler ergeben sollten, gehen diese nicht in die Ergebnisse ein, weil automatisch die zwei schlechtesten Werte verworfen werden.
Vergleichen wir also die Systeme quantitativ:
i5 vs. Ryzen
Zur Erklärung des Diagramms:
Aufgetragen auf der y- Achse sind die "inversen Frametimes". Das sind im Grunde die FPS aber halt nicht durch "Zählen von Frames über einen Zeitraum" bestimmt, sondern über den Kehrwert der Frametimes gebildet.
Wenn ihr hier bei einem Wert links(avg FPS) 44 in 1/s seht, dann würde euch Fraps auch 44 FPS anzeigen.
Aus dem Frametimeverlauf bestimme ich einen effektiven Frametimeverlauf. Diesen habe ich ausführlich im Hauptthread unter "Nomenklatur" diskutiert.
"avg eff FPS" ist der Kehrwert des Durchschnitts dieses effektiven Frametimeverlaufs.
Um so stärker dieser Wert gegenüber den avg FPS abfällt um so stärker sind die relativen Schwankungen der Frametimes ....eine Art "Mikroschwankungsindikator".
Es folgen die Xth percentile und X% low Werte, die sich Stück für Stück immer weiter den schlechten Frametime Werten zuwenden und daher für das Spielgefühl besonders wichtig sind.
5%low und 99th percentile sind dabei noch eher auf den allgemeinen Spielfluss konzentriert und bekommen wenig bis nichts von einzelnen Frametimepeaks(Rucklern) mit.
Die letzten drei Werte werden je nach Spiel mehr oder weniger von diesen Frametimepeaks dominiert und sind meiner Meinung nach oft das beste Mittel um zu beschreiben ob und wie "Ruckelig" sich das Spiel anfühlt.
Leider basieren sie nur auf einem kleinen Teil der Frametimes und daher unterliegen sie größeren Ungenauigkeiten.
Auch wenn ich die 0,1% low Werte sehr schätze, bieten sie oft zu schlechte Reproduzierbarkeiten und daher bin ich ein großer Fan der 1% low Werte.
Diese sind in der Regel noch gut zu reproduzieren und entsprechen sinnvoll dem Spielgefühl.
Die Linien zwischen den Symbolen sind extra gestrichelt, da sie nur zur besseren Lesbarkeit beitragen sollen und keine Punkte dazwischen suggerieren sollen.
In der Legende sieht man die Symbolformen und Farben der verscheidenen Testkandidaten.
Die Wertepunkte selbst sind Durchschnittswerte aus den drei besten Werten von fünf Messungen und haben zusätzlich Fehlerbalken, die sich aus der empirischen Standardabweichung dieser drei besten Werte ergeben.
Wenn ihr hier bei einem Wert links(avg FPS) 44 in 1/s seht, dann würde euch Fraps auch 44 FPS anzeigen.
Aus dem Frametimeverlauf bestimme ich einen effektiven Frametimeverlauf. Diesen habe ich ausführlich im Hauptthread unter "Nomenklatur" diskutiert.
"avg eff FPS" ist der Kehrwert des Durchschnitts dieses effektiven Frametimeverlaufs.
Um so stärker dieser Wert gegenüber den avg FPS abfällt um so stärker sind die relativen Schwankungen der Frametimes ....eine Art "Mikroschwankungsindikator".
Es folgen die Xth percentile und X% low Werte, die sich Stück für Stück immer weiter den schlechten Frametime Werten zuwenden und daher für das Spielgefühl besonders wichtig sind.
5%low und 99th percentile sind dabei noch eher auf den allgemeinen Spielfluss konzentriert und bekommen wenig bis nichts von einzelnen Frametimepeaks(Rucklern) mit.
Die letzten drei Werte werden je nach Spiel mehr oder weniger von diesen Frametimepeaks dominiert und sind meiner Meinung nach oft das beste Mittel um zu beschreiben ob und wie "Ruckelig" sich das Spiel anfühlt.
Leider basieren sie nur auf einem kleinen Teil der Frametimes und daher unterliegen sie größeren Ungenauigkeiten.
Auch wenn ich die 0,1% low Werte sehr schätze, bieten sie oft zu schlechte Reproduzierbarkeiten und daher bin ich ein großer Fan der 1% low Werte.
Diese sind in der Regel noch gut zu reproduzieren und entsprechen sinnvoll dem Spielgefühl.
Die Linien zwischen den Symbolen sind extra gestrichelt, da sie nur zur besseren Lesbarkeit beitragen sollen und keine Punkte dazwischen suggerieren sollen.
In der Legende sieht man die Symbolformen und Farben der verscheidenen Testkandidaten.
Die Wertepunkte selbst sind Durchschnittswerte aus den drei besten Werten von fünf Messungen und haben zusätzlich Fehlerbalken, die sich aus der empirischen Standardabweichung dieser drei besten Werte ergeben.
Ich habe direkt eine Reihe Vergleichswerte dargestellt.
Wenig überraschend ist der Ryzen mit vollen 8 Kernen und SMT die schnellste CPU und der i5 mit stock Taktraten die langsamste.
Übertaktet kämpft der i5 mit vier Zen Kernen ohne SMT.
Beim Durchschnitt verliert er, bei den 0.1% low gewinnt er jedoch deutlich.
Geben wir den vier Zen Kernen SMT, reicht das bereits um ihn sehr nah an die Ergebnisse der 8 Kerne zu bringen.
Das sieht man auch schön im Framtetimeverlauf.
Die Verläufe und auch die Frametimepeaks unterscheiden sich nur wenig. Die 4 Kerne mit SMT zeigen leicht größere Schwankungen und die Peaks sind in der Regel minimal größer.
Mit Basis Taktraten und freigegebenem Ram, ist der i5 3570K dann deutlich abgeschlagen und fällt öfter unter die 60 FPS(0.1% low)
Noch schlechtere 0.1% low Werte zeigt nur die 2+2 Konfiguration ohne SMT....wobei die Fehlerbalken zeigen, dass die Unterschiede nicht reproduzierbar genug sind um einen zuverlässigen Unterschied zu erkennen. Eine mögliche Erklärung versuche ich weiter unten zu geben..
Ryzen CCX Konfiguration und SMT
Einige der Ergebnisse kennen wir ja schon aus dem vorherigen Absatz....
So z.B. wie SMT bei 4 Kernen große Verbesserungen bringt. aber nicht ganz an 8 Kerne ran kommt.
Neue Informationen wären:
Mit 8 Kernen und 3,8GHz ist es hingegen egal ob SMT an oder aus ist.
Bei 3200MHz Ram und ohne SMT, liegen die Unterschiede von 2+2 zu 4+0 im Bereich der Messungenauigkeit.
Man könnte einen leichten Vorteil für 4+0 hineininterpretieren.
Die Nachteile durch die Infinity Fabric Komunikation werden also fast vollständig durch den schnellen Ram und den doppelten L3 Cache aufgefangen.
Gegenüber den 8 Kernen liegen beide weit zurück, wie dieses Beispiel an Frametimeverläufen zeigt:
Die 4+0 Konfiguration mit nur 2,8GHz muss sich deutlich geschlagen geben und fällt auf 30 FPS.
Das eine GHz mehr Takt von 2,8 auf 3,8GHz entspricht 36% mehr Takt und bringt 17,2% mehr avg FPS und 30.3% mehr 1% low....Im Durchschnitt fallen die Unterschiede weniger stark auf, weil Teile des Tests weiterhin GPU limitiert laufen.
Erst bei den 1% low Werten sieht man die wahren Vorteile der Taktsteigerung, die hier sehr gut skaliert.
Leistungsaufspaltung beim i5
Es zeigt sich eine starke Abhängigkeit von der Geschwindigkeit des DDR3 Speichers.
So zeigt sich kein Unterschied zwischen einem Stock i5 3570K mit 1600MHz Ram zu einer Übertaktung auf 4,4GHZ mit nur 133MHZ Ram.
Die 133MHz weniger Ram Takt gleichen die 800MHz mehr CPU Takt(i5 3570K hat einen allcore Takt von 3,6GHz) aus!
Gehen wir weitere 133MHz weiter runter auf 1066MHz, verlieren die 4,4GHz sogar gegen die 2,8GHz!
Der Wechsel von 1333 auf 1866 macht also aus dem 40% schnelleren Ram 22,9% mehr avg FPS aus und 24,3% mehr 1% low.
Von 2,8 zu 4,4GHz sind es 57% mehr Takt. Dies führt zu einer Steigerung der avg FPS von 34,5% und 44,5% bei den 1% low.
Ein starker Gewinn durch schnelleren Ram und ebenfalls ein guter Gewinn bei den 1% low durch mehr Takt.
IPC Vergleich
Drei mal vier Kerne, ohne HT/SMT, bei 2,8GHz im Vergleich.
Wie schon vorher gesehen haben die vier Zen Kerne ohne SMT Probleme bei den 0.1% low Werten...sie zeigen also mehr/höhere Frametimepeaks.
Doch auch im klassischen Durchschnitt sind die Ergebnisse nicht so gut wie in anderen Spielen.
Mit 2133MHz liegen Zen und ivy Bridge gleichauf. Erst der schnelle Ram bringt einen deutlichen Unterschied.
Die Zen Kerne aus der 1000er Serie zeigt also erst dann eine deutlich bessere IPC, wenn schneller Ram verwendet wird.
Und hat mehr Probleme mit Frametimepeaks.
DDR3 Ram Skalierung
Wie schon vorher gesehen, reagiert The Witcher 3 mit dem i5 3570K gut auf schnellen Ram.
Der Wechsel von 1066 auf 1866 MHz macht aus dem 75% schnelleren Ram ganze 43,6% mehr avg FPS und 44,1% mehr 1% low.
Die 0.1% low steigen um 43,6%.
Der Verlauf lässt erahnen, dass die Skalierung noch gut zu höheren Taktraten weiter geht.
Mit langsamem Ram ist The Witcher 3 damit deutlich schlechter zu spielen....zumindest in einer solchen Szene mit vielen NPCs.
DDR4 Ram Skalierung
Da wir mit 8 Kernen praktisch die ganze Zeit im GPU limit laufen, zeigen sich durch schnelleren Ram kaum Unterschiede. Selbst die 0.1% low Werte verbessern sich nur leicht.
Das Ram OC verhindert also keine Frametimepeaks...es schwächt sie nur minimal ab.
Zusätzlich zu den Werten mit 8 Kernen habe ich noch vier Datenpunkte für 4 Kerne beigefügt.
In Gold die Werte für die avg FPS und in Türkis die Werte für die 1% low bei 4 Zen Kernen ohne SMT.
Der Wechsel von 2133 auf 3200 MHz macht aus dem 50% schnelleren Ram mit 8 CPU Kernen nur 1,2% mehr avg FPS und 3,6% mehr 1% low.
Die 0.1% low steigen um magere 5%.
Bei 4 CPU Kernen(2+2) sind die Steigerungen besser.
Die avg FPS steigen um 17,9%, die 1% low um 17,8% und die 0.1% low um 11,3%.
HBCC settings
Alle Werte liegen innerhalb der Messungenauigkeit....Das Spiel reagiert gar nicht auf die Veränderung des zugewiesenen Speichers.
Ryzen optimieren und übertakten
Obwohl meine Optimierung immerhin 100MHz mehr allcore Takt liefert und auch der Ram durch die Subtimings 9,6% mehr Leserate hat, lassen sich kaum Unterschiede zu Stock Taktraten mit docp Profil messen.
Das liegt sicherlich an dem mit 8 Kernen fast durchgängig vorhandenen GPU limit. Erst im rechten Bereich zeigen sich minimale Vorteile durch die Optimierungen.
Wenn man bedenkt, dass man sich am GPU limit bewegt, fallen die Unterschiede der Bios default Einstellungen stärker aus als ich gedacht hätte.
Es sind immer noch keine deutlichen Unterschiede aber sie sind zuverlässig messbar.
Einfuss von Ramtakt auf den Infinity Fabric
Hintergrund:
Wer sich mit Ryzen beschäftigt hat, der wird öfter gehört haben, dass Ryzen schnellen Ram braucht, weil sonst die Kommunikation zwischen den CCX durch einen lansamen IF behindert wird.
Aber ist dem auch so? Ich habe noch keinen brauchbaren Test gesehen, der das untersucht hat und habe mir was eigenes überlegt.
Theoretisch ist da schonmal was dran. Gerade in neueren PC Spielen wird die Arbeit auf mehrere Kerne aufgeteilt und es findet viel Kommunikation statt um alles synchron zu halten und die Ergebnisse zusammenzuführen.
Der IF ist an den Takt des Ram gekoppelt und es gibt Veröffentlichungen, die zeigen das sich die Latenzen von einem CCX zum anderen mit schnellerem Ram verbessern.
Die Frage ist, ob dies rein theoretisch ist oder wirklich so signifikant, dass es sich auch in der Spieleperformance niederschlägt.
Leider steigt mit schnellerem Ram auch die Spieleperformance und es wird schwer zu sehen, was davon die IF Verbesserung war und was einfach der schnelle Ram.
Die IF Unterschiede von 2+2 zu 4+0 werden durch den doppelten L3 Cache bei 2+2 verschleiert.
Vorgehen
Bei den Ryzen 8 Kernern hat man die Möglichkeit über das Bios Kerne zu deaktivieren und dies habe ich einmal als 2+2 und einmal als 4+0 Konfiguration gemacht. SMT war deaktiviert.
Dann habe ich beides einmal mit 2133 und einmal mit 3200er Ram getestet.
Dann habe ich den prozentualen Performance Gewinn(2133 zu 3200) einmal für 2+2 und für 4+0 ermittelt und die Differenz gebildet.
Unter der Annahme, das der Gewinn durch den schnelleren Ram gleich sein sollte, zeigt die Differenz also den reinen Einfluss durch den beschleunigten IF.
Die Ergebnisse beruhen allerdings auf je vier fehlerbehafteten Größen und wenn man mit Gaußscher Fehlerfortpflanzung die Fortpflanzung dieser Fehler in das Endergebnis berechnet, zeigen sich leider große Unsicherheiten.
Aber ist dem auch so? Ich habe noch keinen brauchbaren Test gesehen, der das untersucht hat und habe mir was eigenes überlegt.
Theoretisch ist da schonmal was dran. Gerade in neueren PC Spielen wird die Arbeit auf mehrere Kerne aufgeteilt und es findet viel Kommunikation statt um alles synchron zu halten und die Ergebnisse zusammenzuführen.
Der IF ist an den Takt des Ram gekoppelt und es gibt Veröffentlichungen, die zeigen das sich die Latenzen von einem CCX zum anderen mit schnellerem Ram verbessern.
Die Frage ist, ob dies rein theoretisch ist oder wirklich so signifikant, dass es sich auch in der Spieleperformance niederschlägt.
Leider steigt mit schnellerem Ram auch die Spieleperformance und es wird schwer zu sehen, was davon die IF Verbesserung war und was einfach der schnelle Ram.
Die IF Unterschiede von 2+2 zu 4+0 werden durch den doppelten L3 Cache bei 2+2 verschleiert.
Vorgehen
Bei den Ryzen 8 Kernern hat man die Möglichkeit über das Bios Kerne zu deaktivieren und dies habe ich einmal als 2+2 und einmal als 4+0 Konfiguration gemacht. SMT war deaktiviert.
Dann habe ich beides einmal mit 2133 und einmal mit 3200er Ram getestet.
Dann habe ich den prozentualen Performance Gewinn(2133 zu 3200) einmal für 2+2 und für 4+0 ermittelt und die Differenz gebildet.
Unter der Annahme, das der Gewinn durch den schnelleren Ram gleich sein sollte, zeigt die Differenz also den reinen Einfluss durch den beschleunigten IF.
Die Ergebnisse beruhen allerdings auf je vier fehlerbehafteten Größen und wenn man mit Gaußscher Fehlerfortpflanzung die Fortpflanzung dieser Fehler in das Endergebnis berechnet, zeigen sich leider große Unsicherheiten.
Ganz wichtig sind hier die Fehlerbalken!
Die geringen Unterschiede von 2+2 zu 4+0 Konfiguration sorgen für relativ große Fehlerbalken im Vergleich zu den errechneten Daten.
Es folgen daraus also keine sonderlich vertrauenserweckenden Ergebnisse.
Das Verhalten gleicht aber dem was ich schon in einigen anderen Spielen feststellen konnte.
Im oberen Bereich bei den durchschnittlichen FPS bewirkt der schnellerer IF eine Steigerung der FPS.
Im unteren Bereich kehrt sich das Bild um.
Meine Theorie ist, dass zwar weiterhin der schnellere IF den 2+2 hilft schneller Drawcalls usw. zu bearbeiten, es jedoch einen viel größeren Effekt gibt, der dies verdeckt.
Der untere Bereich zeigt mehr von Frametimeschwankungen und Frametimepeaks.
Und bei 4+0 müssen sich 4 Kerne 8MB L3 Cache teilen, während bei 2+2 jeweils zwei Kerne sich 8MB teilen.
Die doppelte Menge an L3 Cache federt viel besser den langsamen Ram ab und das führt dazu, dass 2+2 weniger unter der gesunkenen Ram Geschwindigkeit leidet.
Die Folge sind größere Gewinne durch schnellen Ram bei 4+0 bzw. weniger Verluste durch langsamen Ram bei 2+2.
Irgendjemand müsste mal einen Ryzen 3 1200 mit der gleichen Methode gegen die 4+0 messen. Denn der 1200 hat eine 2+2 Konfiguration aber nur 4MB für zwei je zwei Kerne aktiv.
Es macht sicherlich noch Unterschiede, ob sich vier 8MB teilen oder zwei 4MB....aber es wäre deutlich besser zu vergleichen.....selbst kaufen fand ich für so ein Experiment etwas zu teuer....Mindfactory will 79€ haben und Ebay mindestgebot 50€ oder 75€ Sofortkauf....muss nicht sein
.Windows 10 vs. 7
Wie man sieht hat Window 7 keinen guten Stand gegenüber Windows 10.
Auch wenn die avg FPS teilweise minimal besser sind, läuft The Witcher 3 unter Windows 7 tendenziell schlechter und gerade bei den 0.1% low Werten fällt es deutlich ab.
Wie man den Frametimeverläufen entnehmen kann, sind die Frametimeschwankungen minimal stärker und es gibt mehr Frametimepeaks.
Schauen wir uns die Skalierung mit CPU Takt und Ramtakt unter Windows 7 an:
Es scheint keine qualitativen Unterschiede zum Verhalten bei Windows 10 zu geben.
CPU Takt bleibt wichtig und Ram Takt ist sehr wichtig.
Windows 7 scheint dabei die gleichen Probleme für den i5 zu machen wie wir sie vorher bei 4 Zen Kernen ohne SMT gesehen haben.
Es kommt vermehrt zu Frametimepeaks, die die 0.1% low Werte verschlechtern.
Die Peaks sind allerdings nicht so schlimm wie die Nachladeruckler, über die ich am Anfang geredet habe.
Im nächsten Absatz suche ich nach eine Lösung.
Frametimelimiter
The Witcher 3 bringt von Haus aus die Möglichkeit mit, die FPS auf 60 oder 30 zu limitieren.
Warum sollte man sowas überhaupt machen wollen?
Ein legitimer Grund kann sein, dass man Strom sparen und seinen PC leiser laufen lassen möchte.
Wer eigentlich 70+ FPS erreichen würde, aber der Meinung ist, dass ihm auch 60 oder gar 30 reichen kann so die Arbeit für den PC deutlich senken.
Die Arbeit für den PC senken kann jedoch auch weitere Vorteile haben.
Wenn die FPS hoch sind, müssen öfter die Drawcalls von der CPU abgearbeitet werden und die CPU Belastung steigt.
Gerade bei nur vier Kernen und in solch CPU intensiven Testszenen entlastet dies die CPU(vor allem den RenderThread bei AMD+ DX11).
Eine starke Grafikkarte oder niedrige Einstellungen sorgen zwar für mehr avg FPS und auf den ersten Blick eine bessere Performance, aber es kann dazu kommen, dass einzelne CPU Kerne oder gar die ganze CPU durch die zusätzliche Arbeit überlastet werden und dann wichtige Berechnungen nicht rechtzeitig fertigstellen können.
Es kommt zu mehr Rucklern als mit weniger FPS!
Das zeigt sich auch teilweise in anderen Spielen. Hier ein Video wo darüber im Falle von GTA V berichtet wird:
Man könnte die Grafikeinstellungen erhöhen und damit die FPS drücken, jedoch fällt es schwerer eine Balance zu finden.
Nicht nur die Anforderungen an die CPU ändern sich je nach Spielsituation, auch die Anforderungen an die Grafikkarte schwanken.
Läuft es in einer Szene mit 60 FPS im GPU limit, kann eine andere Szene (auch im GPU limit) nur noch 45 FPS erreichen und dann fühlt es sich unsauber an wegen der Grafikkarte.
Ein limitieren der FPS bei Grafikeinstellungen für höhere FPS entspannt die Situation und sollte überall eine konstante Leistung bieten.
Ich habe meine Untersuchungen mit limitierten FPS auf dem i5 3570K und unter Windows 7 gemacht, weil sich hier zuverlässig einzelne Ruckler, auch in die guten Frametimemessungen verirrt haben.
Ich hätte vermutlich auch den Ryzen mit vier Kernen und ohne SMT nehmen können. Das Verhalten scheint das gleiche zu sein.
Fangen wir mit der Übertaktung auf 4,4GHz und 1866er DDR3 Ram an:
Wie man sieht zwingt der 60 FPS limiter wie erwartet die Frametimes um eine Linie bei 16,66 ms.
Es ist leider kein perfekter Verlauf aber man sieht, wie der Bereich der Schwankungen schmaler wird.
Und auch wenn es immer noch einige Peaks gibt, die mit ihren um die 25 ms je nach Empfindlichkeit des Spielers sichtbar sind, so bleiben doch die einzelnen großen Peaks wie sie die unlimitierte Messung zeigt aus.
Ein ähnliches Bild zeigt sich bei stock Taktraten und 1600er Ram:
Die Frametimes der unlimiterten Messung wandern näher an die 16,66 ms heran und wo sie sich überschneiden, werden die Frametimeschwankungen der auf 60 FPS begrenzten Messung wieder größer.
Trotzdem verhindert die Limitierung relativ gut die großen Frametimepeaks.
Die gezeigten Frametimegraphen waren jeweils die zweitbeste aus Messungen was die 0.1% low Werte angeht.
Um nicht zu viel in Einzelmessungen zu interpretieren, vergleiche ich jetzt wieder die gemittelten Statistikwerte aus den besten drei.
Logischerweise zeigt die Limitierung auf 60 FPS große generelle Einbußen.
Was uns jedoch interessiert sind die 0.1% low und hierliegen beide gleichauf.
Das ist etwas entäuschend, waren doch die Frametimegraphen der Einzelmessungen sehr vielversprechend.
Wären die Fehlerbalken nicht so groß, würde es jedoch nach eine kleinen Sieg für den Frametimelimiter aussehen.
Gucken wir uns also die Stock Taktraten an:
Das sieht in der Tat gut aus.
Weil die avg FPS ohne limiterung nicht ganz so hoch ausfallen, sind die generellen Verluste geringer und der Sieg bei den 0.1% low Werten zeigt, dass die FPS Limitierung hier die gewünschte Wirkung zeigt.
Senken wir den CPU Takt auf 2,8GHz, nutzen aber schnellen Ram:
Auch unlimitiert schafft der i5 jetzt nur knapp über 70 avg FPS.
Der Einfluss der Limitierung schwindet also und auch wenn es so aussieht, als würde es bei den 0.1% low weiterhin einen kleinen Vorteil für den limiter geben reicht die Reproduzierbarkeit nicht aus um dies zu bestätigen.
Senken wir auch noch den Ram Takt:
Jetzt sinken die FPS unter das 60 FPS limit und das Vorhaben wird nutzlos.
Mit Limitierung liegt alles minimal niedriger, was vermutlich auf einzelne gute Frametimes zurückzuführen ist, die eingentlich den Schnitt leicht heben und jetzt eingebremst werden.
Es gibt ja auch noch die 30 FPS Einstellung also gucken wir uns diese an:
Hier vergleiche ich nur meine schnellste und die langsamste Version der ivy Bridge i5.
Denn schlechter als unlimitiert oder mit 60 FPS Begrenzung läuft es sowieso.
Die Frage war hier eher ob man überhaupt Unterschiede findet obwohl die Grenze so niedrig liegt.
Wie man sieht gibt es diese durchaus.
Mit schnellerer CPU und mit mehr Ramtakt ist es also weiterhin besser möglich die Frametimes stabil zu halten.
-------------------------
Es lohnt sich also durchaus darüber nachzudenken solche Limiter zu nutzen.
In diesen Tests zu The Witcher 3 waren die Vorteile allerdings auf einen speziellen Bereich beschränkt. Die CPU durfte nicht zu langsam sein aber auch nicht zu schnell, damit es sich gelohnt hat.
Es wäre eventuell praktisch weitere Abstufungen zu testen. Ein Limit auf 75 FPS für schnelle CPUs oder 45-50FPS für langsame CPUs wäre meiner Meinung nach ideal....am besten einfach individuell wählbar.
Es gibt ja auch externe Limiter aber diese kommen oft mit anderen Problemen daher.
Vergleich von zwei Testszenen.
Computerbase hat inzwischen The Witcher 3 aus ihrem CPU Testparcour entfernt.
2017 war es aber noch Bestandteil und wurde als Beispiel aufgeführt, für ein völlig GPU limitiertes Spiel.
Im Test zum i3 7350K anfang 2017 gewinnt dieser mit leichtem Vorsprung den The Witcher 3 Test bei 1080p mit einer übertakteten GeForce GTX 980 Ti.
Eine zwei Kern/4Thread CPU mit 4,2GHz stock Takt gewinnt gegen i7 7700K und alles andere.
Eine Übertaktung auf 5,1GHz bringt nur 0,2% mehr Leistung und ein i5 2500K(allcore Boost 3,4GHz), der sogar ein paar Prozent langsamer sein sollte als mein i5 3570K liegt nur 5 % zurück.
Quelle: https://www.computerbase.de/2017-01/intel-core-i3-7350k-test-overclocking/5/#diagramm-the-witcher-3-high-end-gpus-im-vergleich
Der ganze Test schreit danach das es sich hier um ein Spiel handelt, dass so gut wie gar keine Ansprüche an die CPU stellt und keine Vorteile aus mehr CPU Kernen zieht.....das schreibt CB zumindest im Zusammenhang mit mittelklasse CPUs:
"In The Witcher 3 liegen alle CPUs sehr dicht beisammen, die Wahl der CPU ist praktisch irrelevant."
Das passt nicht mit meinen Ergebnissen zusammen und daher ist es interessant die genutzten Testsequenzen einmal genauer anzuschauen:
Hier kann man sich die Testszene von CB angucken:
https://www.computerbase.de/2015-10...tem-amd-intel-2015/3/#abschnitt_the_witcher_3
Und so habe ich versucht die Testszene nachzustellen:
https://www.youtube.com/watch?v=RRzarVOZGqg&index=12&list=PLP9fskJGwUOT5CByAJMJrXaggyMuUgsFt
Es ist sicherlich nicht perfekt, ich laufe am "Strand" etwas zu mittig und gehe weniger gradlinig aber das sollte nur minimale Unterschiede machen.
Auch nutze ich nicht die höchsten Grafikeinstellungen und eine stärkere GPU. Es sollten sich also eher mehr Unterschiede zeigen als bei CB, die nur um die 70 FPS erreicht haben, wo meine Systeme um die 100 FPS schaffen.
Schauen wir uns also meine Ergebnisse in dieser Testszene an.
Die i5 füttern die Vega64 scheinbar minimal schneller mit Daten, so dass selbst die 2,8GHz gegen den Ryzen gewinnt.
Hier wäre ein 2700X interessant um zu sehen ob die verbesserten Latenzen von Zen+ dies ausgleichen.
Der ganze rechte Bereich zeigt hingegen keine Unterschiede mehr zwischen dem Ryzen und dem übertakteten i5.
Mit nur 2,8GHz muss der i5 hier etwas federn lassen, hält aber immer noch die 60FPS.
Auch mit meinem Aufbau sehe ich also in dieser nachgestellten CB Testszene die gleichen Ergebisse wie CB.
Solange die CPU nicht total langsam ist, scheint sie ziemlich egal.
Schauen wir uns die Ergebnisse im Vergleich zu meiner Testszene aus Novigrad an.
Erstmal nur für den i5:
Die beiden oberen Daten(hellere Farben) haben wir schon im vorherigen Diagramm sehen können.
Neu sind die etwas dunkleren Farben, die meiner Testszene entspringen.
Wo bei der CB Szene die 1,6GHz weniger Takt trotzdem die gleichen avg FPS schaffen und nur etwas mehr Frametimeschwankungen haben, fallen die Unterschiede in meiner Szene deutlich aus.
Die generelle Performance ist geringer und der Unterschied zu 2,8GHz sind gewaltig.
....Weiter im nächten Beitrag....
Zuletzt bearbeitet:
