Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Frametimes/Performance Comparison on Intel & AMD CPUs
Kannst du mir bitte die originalen csv Dateien von den Messungen zu DyingLight schicken. Da du 144hz und Gysnc hast, wäre das sehr interessant auszuwerten. Vorallen wegen den Framepacing bei Gsync. Wenn es möglich ist, einfach in einen Zip Ordner rein und mir per PN (oder hier rein).
Macht es was aus, dass ich beim G-Sync test zusätzlich per Afterburner, bzw. Riva-Tuner das FPS cap von 140 eingegeben hatte ?
Aktuell teste ich sogar ein 60 FPS cap, da ich ein Spiel habe, wo ich Probleme aufgrund hoher fps vermute. Jedenfalls hatte ich oft freezes in dem Spiel, auch bei hohen fps und ich hab keine Ahnung woran das lag.
Auch bei anderen Spielen Teste ich gerade, ob ich evtl. ein "glatteres Spielgefühl" habe, bei 60 fps cap. Aber das sind nur Ideen, da ich auch bei einem Autorennen bei hohen fps so eine Art "warping" der Gegner hatte, die halt auch hohen Ping hatten. Kann aber alles Zufall gewesen sein, oder überfüllter, schlechterer Server. Da is manchmal ganz schön was los, wenn da 24 Leute gleichzeitig lospreschen, inkl. der ganzen Physik, weil da Sachen durch die Gegend fliegen und das Blech der Autos zerknautscht wird(Wreckfest ).
Mag auch an den niedrigen netzwerkeinstellungen im Spiel gelegen haben. hab die mal erhöht in den Optionen und zuletzt hatte ich das nicht. Allerdings auch 60 FPS cap. Mal schaun ...
Öhm ...
Aber hier erst mal die beiden Dateien....
Ups ... muss die ja erst mal zippen.
Ich habe mir das Framepacing nochmal angesehen und kleine Excel (eigentlich Libre Office) Tabellen erstellt. Allerdings nur für die ersten 1000 Frames, da diese Diagramme nicht so gut skalieren, wie Gaussmath CapFrameX. Man kann aufjedenfall Recht deutlich erkennen, dass einmal Tripple Buffering vsync verwendet wurde und einmal Gsync.
Das ist Recht eindeutig gsync. Man sieht es daran, dass die Frametime (blau) und die Bildschirmzeit zwar recht nah beieinander sind, aber teilweise abweichen. Hättest du kein gsync und kein vysnc oder sonstiges wäre die Linie fast durchgehend deckungsgleich. Hier sieht man wegen der adaptiven Displaysynchronisation häufig kleine Unterschiede. Das liegt wahrscheinlich daran, dass Gysnc einen kleinen Puffer hat und die Frquenz des Bildschirm wohl auch nicht so extrem schnell verändern kann. Das sorgt aber auch dafür, dass die Frameausgabe gleichmäßiger wird.
Hier sieht man ganz eindeutig den Tripple Buffering vsync charakter. Man kann schön die schnellen Wechsel sehen. Da die Framerate von 144fps nicht gehalten werden kann, müssen bestimmte Frames doppelt angezeigt werden, da aller 7ms ein neues Bild angezeigt werden muss. Wenn bisdahin kein Bild da ist, wird das vorherige wieder angezeigt. Auf den Diagramm sind es die ganzen kleinen Linien nach oben. Deswegen fühlt sich gsync auch flüssiger an. Dort wird die Frequenz angepasst, sodass es nicht dazu kommt, dass ein Bild doppelt so lange wie die anderen angezeigt werden muss.
Aufejedenfall danke für die Dateien. Die waren recht aufschlussreich.
Ich habe die ComputerBase Community Bench-Szene nochmal mit der 2080 Ti getestet.
Szene: YouTube
Auflösung: 1440p
Settings: Nvidia Preset mit Raytracing auf Ultra, DLSS on, Ultra Preset, Hairworks und PhysX off, Tesselation off
Bench-Tools: siehe meine Signatur
Ich wollte wissen, wie die CPU hier einwirkt auf die Gesamtperformance, da der FPS Counter immerhin teilweise die 100er Marke überschreitet in der hier gebenchten Szene. Daher habe ich 3.5GHz gegen 4.2GHz gestellt.
Hier mal WWZ Vulkan vs. DirectX 11 mit der 2080 Ti. In der Benchszene sieht es eigentlich ganz gut aus. Allerdings leidet der Vulkan Modus und starken Hängern, die zwischendurch regelmäßig auftreten, außerdem muss sich das Spiel mit Vulkan erst "einruckeln".
Hier mal WWZ Vulkan vs. DirectX 11 mit der 2080 Ti. In der Benchszene sieht es eigentlich ganz gut aus. Allerdings leidet der Vulkan Modus und starken Hängern, die zwischendurch regelmäßig auftreten, außerdem muss sich das Spiel mit Vulkan erst "einruckeln".
Ob das so sein muss weiß ich nicht. Ich dachte eigentlich, dass es extra dafür den Shader Cache gibt. Wenn das bei jedem Start so ist fehlt es evtl. an einem Profil, oder Spiel sieht das eben so vor und cached nichts dauerhaft.
Metro Exodus mit Raytracing + DLSS ist zumeist flüssig und gut spielbar. Es gibt jedoch auch Ausnahmen, wie das folgende Video zeigt. Gerade zum Ende hin ist es sehr hakelig und unangenehm zu spielen.
An dieser Stelle findest du externe Inhalte von Youtube. Zum Schutz deiner persönlichen Daten werden externe Einbindungen erst angezeigt, wenn du dies durch Klick auf "Alle externen Inhalte laden" bestätigst:
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit werden personenbezogene Daten an Drittplattformen übermittelt. Für mehr Informationen besuche die Datenschutz-Seite.
Ich buddel diesen Thread nochmal aus, um hier ein paar Kernskalierungstests zumachen und die Ergebnisse zugänglich zu machen.
Mein erstes Opfer ist Watch_Dogs 1. Die Ergebnisse wurden (natürlich) mithilfe von CapFrameX sowohl aufgenommen, als auch ausgewertet.
Die CPU (der Ryzen 2600x) wurde für den Test auf 3600Mhz festgetaktet. Der Speicher lief mit 3066MHz mit optimierten Subtimings. Als Grafikkarte wurde eine leicht übertaktete GTX 980ti genutzt. Die Settings waren auf ultra, bis auf Texturen, AA, Bewegungsunschärfe und Ambient Occlusion, die jeweils auf den niedrigsten Wert standen. Zudem wurde in der Konfigurationsdatei alle Qualitätseinstellungen auf "PC" gesetzt. Die Auflösung beträgt 1280x720. Bis auf Uplay und CapFrameX lief kein Hintergrund Programm.
Die Ergebnisse sind jeweils aus 3 Durchgängen gemittelt und der Frametimeverlauf wurde von den jeweils mittlersten der Werte genutzt (sonst wären es zu viele Bildchen). Die Benchmarkszene kann man bald hier ansehen.
Die schwächste Konfiguration war 2 Cores mit 4 Threads. Dabei wurde von jeden CCX ein Kern genutzt.
Durchschnittlich wurden 83,4FPS erreicht.
Wie man sieht ist es größtenteils relativ fluffig, es gibt jedoch einige größere Spikes.
Die nächste Konfiguration ist 4 Cores mit 4 Threads. Wie bereits zuvor sind die 4 Kerne gleichmäßig auf die beiden CCX aufgeteilt.
Durchschnittlich wurden hier bereits 101,6FPS erreicht.
Hier sieht man bereits, dass die Spikes deutlich weniger stark ausgeprägt sind. Zudem ist die durchschnittliche Framerate höher.
Der nächste logische Schritt war 4 Cores mit 8 Threads. Also die gleiche Konfiguration wie zuvor allerdings mit SMT.
Die durchschnittliche Framerate stieg hier auf 127,2 an.
Die Spikes sind hier nochmal geringer. Der höchste ist bereits unter 22ms.
Wenn dies schon so gut läuft, sollten 6 Kerne mit 6 Threads ja noch besser laufen oder?
Leider sank die durchschnittliche Framerate auf 111,1 FPS ab.
Die Spikes sind zwar noch geringer, aber die durchschnittliche Framerate ist geringer. Wie kann das sein. SMT ist ja im Normalfall nicht effektiver als Kerne. Selbst bei extremen Leistungsteigerungen von 50% pro Kern, sollte die Leistung mit 6 Kernen ohne SMT ungefähr gleich sein.
Bei 6 Kernen mit SMT ist die Welt wieder in Ordnung.
Der Durchschnitt beträgt jetzt 139,1 FPS.
Die Spikes erreichen ihren Tiefpunkt und die Framerate steigt weiter an. Dies ist bei meinen Ryzen die beste Konfiguration.
Insgesamt skaliert Watchdogs also ganz ordentlich mit mehr Kernen. Verwirrend ist allerdings, dass 4Kerne mit SMT schneller sind, als 6Kerne ohne SMT. Aufgrund dieses Ergebnis habe ich den Benchmark für 6 Kerne ohne SMT und 4 Kerne mit SMT nochmal wiederholt, aber keine nennenswerten Abweichungen gefunden. Es wäre schön, wenn die Communitymitglieder das eventuell gegen checken können. Ich versuche selbst auch noch Licht in das Problem zu bringen.
6 echte Kerne müssen ja nicht notwendigerweise besser als 4 physische und 4 logische sein. Ich denke, das kommt auf den Workload drauf an. Du hast wohl genau so ein Beispiel aufgetan.
Ein bisschen komisch ist es aber schon. Besonders dieser starker Anstieg. Lässt meiner Meinung darauf schließen, dass das Spiel mit genau 6 Threads nicht so gut klarkommt.
Ich habe mal ein paar cinebench runs gemacht.
Mit 6Kernen bekomme ich 862 Punkte. Mit 6 kernen und SMT 1221. Das sind ca. 41,65% Mehrleistung nur durch SMT, was sehr viel ist. Da Cinebench sehr gut skaliert, habe ich einfach 3 Sätze gesprochen und ca 814 Punkte für 4 Kerne mit SMT rausbekommen. Tatsächlich waren es 811 Punkte. Und Cinebench skaliert wirklich sehr stark mit SMT und kommt trotzdem nicht an einen echten 6 Kerner dran.
Ich habe den Bench auch mal mit nur einen CCX und SMT durchlaufen lassen. Durchschnittlich 86,8 FPS. Also deutlich schlechter als ein reiner 4 Kerner und nur minimal besser als ein 2Kerner mit SMT. Und das obwohl die IF ja wegfällt.
Deswegen glaube ich, dass das Spiel keine 6 Threads mag. Zu dem Zeitpunkt gab es als nennenswerte CPUs ja nur den i5 und i7. Also Quadcores mit und ohne SMT. Und auch CPUs mit mehr Kernen, hatten zumindest HTT zur Verfügung.
Letzlich ist es ja auch egal. Wundert mich nur, dass ausgerechnet ein Spiel das Problem zeigt.
Ein Run BF5 (Kampagne/Tirailleur), Auflösung 3440x1440, RT auf High und DLSS off. Ich musste sogar in den Graphen reinzommen, weil ein heftiger Hakler sonst den ganzen Scale kaputt gemacht hätte.
Edit: Und die gleiche Szene nochmal gänzlich ohne RTX Features. Ein deutlicher Hakler taucht auf, ansonsten ist das Spieleerlebnis sehr flüssig.
Metro Exodus, Kapitel "Summer" Anfang im Wald, Auflösung 2560x1440, Ultra Preset, Raytracing auf Ultra, DLSS off (um die reine RT Performance bei WQHD zu haben)
).
Wie immer das aussehen mag. Hoffentlich irgendwas interessantes, oder auffälliges. 
