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.
TestForza 7 Benchmark: Vega hat mehr Benzin im Blut als Pascal
Du darfst nicht außer Acht lassen, dass Du mit Übertaktung der CPU auch den Takt dessen Caches L1+L2 änderst und somit dann wiederum doch die Geschwindigkeit mit der auf den Speicher zugegriffen werden kann...
Und durch das Addieren der Kernzahl, erhältst Du per API schon eine höhere Drawcall- Leistung unter DX12. Unabhängig davon, ob die CPU mit Berechnung der Szene zeitrichtig fertig wird. Zudem erhält man durch die Aktivierung eines Kernes einen l1+l2 Bereich mehr, der sich in einem Cache Hit zusätzlich auszahlen kann.
Das wirkt sich zwar alles nur geringfügig aus, aber zumindest so, dass man messbar davon sprechen könnte, dass die CPU schneller geworden ist, obwohl in Wirklichkeit einfach nur das Umfeld der Kerne nun besser Daten liefern kann.
Ähm wenn der Hauptspeicher der Flaschenhals sein soll, also bereits überlastet ist, wie kann ich dann einen großen Speedup bekommen, wenn ich versuche noch schneller darauf zuzugreifen mit mehr oder schnelleren Kernen ?
Das ist ungefähr so als würde ich versuchen noch mehr aufs Gaspedal zu sappen, obwohl mein Motor schon im Begrenzer ist.
Das mit den Drawcalls ist ja prinzipiell richtig unter DX12, aber wie willst du denn bitte mehr Drawcalls bekommen, wenn dein Speicher bereits dicht macht und die Daten eben nicht schneller zu deiner CPU kommen? Es ist ja schön, dass dein Cache schneller wird, aber das bringt dir nur bedingt was, wenn der Cache auf einen bereits überlasteten RAM zugreifen will.
Heiße Luft da dies eine gleichmäßige Verteilung in dem Zeitraum erfordert.
Die Frametime an sich ist aber die Zeit zwischen 2 Frames und solange wir nicht über 1 FPS reden ist die direkte Übertragung in FPS witzlos.
@Simsp Er hat seine Vermutung doch geschrieben....mehr Kerne haben zusammen mehr Cache Speicher und dann brauchen sie seltener Daten aus dem Ram. Und nur weil der Ram Probleme hat schnell genug Daten zu liefern, heist es ja nicht, dass er 100% der Zeit ausgelastet ist.
Nur weil du mehr Kerne hast, heißt es ja nicht, dass du insgesamt mehr Anfragen an den Ram hast. Du verteilst sie nur mehr und dann können sich Wartezeiten für den Ram verringern.
Meiner Meinung nach ist das aber kaum relevant....mehr Kerne bedeuten auch minimal mehr Verwaltungsaufwand und mehr verschieberei zwischen den Kernen.
Woran es liegt weiß ich nicht genau...man müsste sich genau die Verteilund der Last angucken, verschiedene Ram und CPU Geschwindigkeiten testen.... ganz viele Messungen machen um die Schwankungen besser zu verstehen und gleichzeiting Ram und VRam Auslastung +Frametimegraph beobachten.
Dann sieht man besser woher die Ruckler und Limitierungen kommen...geht die GPU Last runter? Werden Daten in den Ram oder VRAm geladen während die Frametimes ausschlagen? Geht die GPU Last hoch? Wie ist die Last über die Kerne verteilt?
Ergänzung ()
Wadenbeisser schrieb:
Heiße Luft da dies eine gleichmäßige Verteilung in dem Zeitraum erfordert.
Die Frametime an sich ist aber die Zeit zwischen 2 Frames und solange wir nicht über 1 FPS reden ist die direkte Übertragung in FPS witzlos.
Ansichtssache....du könntest natürlich für alle Varianten neue Begriffe einführen....hochgerechnete FPS für die einzelnen Frametimes, die auf eine Sekunde bezogen/hochgerechnet werden....die lokalen FPS für die FPS die wirklich über eine Sekunde gezählt und gemittelt wurden.....und die runtergerechneten FPS für die durchschnittlichen FPS, die von der ganzen Testszene auf eine einzelne Sekunde runtergerechnet wurden.
Sehe ich aber als mehr verwirrend denn hilfreich.....dummer Autovergleich incoming.....
Du guckst doch auch nicht auf deinen Tacho und denkst dir:"Was soll ich denn mit dieser Geschwindigkeitsangabe! Km/h......das ist doch witzlos wenn ich nicht auch eine Stunde gefahren bin! Wie können es die Autobauer wagen die Momentaufnahe auf eine Stunde hochzurechnen?!"
hat aber bei mir in horizon 3 in surfers paradise trotzdem glatt für eine verdopplung der framerate gesorgt und würde es in 7 an den problemstellen auch tun.
deshalb find ich die ganze diskussion hier völlig sinnbefreit.
wartet doch ab, wie die karten performen wenn sie nicht mehr von der cpu ausgebremst werden.
@Wadenbeisser
Und die Frametimes von ms in 1/s umzurechnen ist halt einfach eine andere Darstellung der selben Sache....dummer Autovergleich zwei:
Wenn wir über Autoverbräuche reden, dann vergleichen wir liter pro 100 Km...aber der Engländer oder Amerikaner vergleicht Miles per Gallon...jeder halt das was er eher gewohnt ist.
@ Baal Netbeck
Das ist keine Ansichtssache sonder eine Tatsache.
Du kannst 60 FPS mit einer gleichmßigen Frametime Verteilung haben und 60 FPS bei dem der Frameverlauf für 500ms stockt. Beides sind 60 FPS und nur eines davon wird flüssig erscheinen.
Wenn du es mit 1/s umrechnest bekommst du lediglich den Durchschnittswert.
hat aber bei mir in horizon 3 in surfers paradise trotzdem glatt für eine verdopplung der framerate gesorgt und würde es in 7 an den problemstellen auch tun.
.....
Bewußt den ersten Teil weggelassen weil darin bereits die Antwort steckt?
Wie ich schon mehrfach schrieb, der FPS Wert ist die Anzahl der Bilder in einer Sekunde, die Umrechnung per 1/s ergibt lediglich den Durchschnittswert der Frametimes für diese Sekunde und sagt erstmal 0 über die reale Frametime zwischen 2 Frames aus.
der patch der alle kerne nutzte.
da kam ich in 1440p von knapp unter 60 fps auf 120 bei den strassenbahnschienen und vor allem lief es nun gefühlt flüssig statt dem aktuellen gestottere ohne v-sync von 7 auf meinem 144 hz monitor.
@Simsp Er hat seine Vermutung doch geschrieben....mehr Kerne haben zusammen mehr Cache Speicher und dann brauchen sie seltener Daten aus dem Ram. Und nur weil der Ram Probleme hat schnell genug Daten zu liefern, heist es ja nicht, dass er 100% der Zeit ausgelastet ist.
Nur weil du mehr Kerne hast, heißt es ja nicht, dass du insgesamt mehr Anfragen an den Ram hast. Du verteilst sie nur mehr und dann können sich Wartezeiten für den Ram verringern.
Ja aber der mehr Cache muss auch irgendwoher gefüllt werden. Die CPUs beschäftigen sich ja schließlich nicht den Großteil der Zeit nur mit sich selbst.
Die Anzahl der Anfragen an den RAM bleiben relativ konstant bei Veränderung der Kernzahl. Und das ist genau der Punkt. Der Speicher wird immer gleich belastet. Wenn ich mehr Kerne habe tendentiell sogar eher höher als niedriger, da ja auch noch alle möglichen anderen Sachen im Hintergrund laufen und ich rein theoretisch mehr abarbeiten könnte, also auch mehr Datenrate vom Hauptspeicher brauche, um meine CPU sinnvoll auszulasten.
Forza 7 legt momentan genau wie damals Horizon 3 die Hauptlast auf Core 0. Das Argument von wegen geringere Latenz ist Blödsinn. Kann man auch schön eben genau am Vorgänger sehen. Dadurch dass die CPU Last nach dem Patch gleichmäßiger verteilt wurde, hat sich auch nix großartig an der Latenz geändert. Ich bin überzeugt wenn Forza 7 ein ähnliches Update bekommt werden sämtliche Grafikkarten Ergebnisse nochmal einen deutlichen Sprung nach vorne machen und dann macht es auch Sinn über die Performance einzelner Karten zu reden, wenn es wirklich maßgeblich von der GPU abhängt und nicht durch eine künstlich herbeigeführte Performance-Bremse des Spiels selbst.
Wadenbeisser schrieb:
Bewußt den ersten Teil weggelassen weil darin bereits die Antwort steckt?
Wie ich schon mehrfach schrieb, der FPS Wert ist die Anzahl der Bilder in einer Sekunde, die Umrechnung per 1/s ergibt lediglich den Durchschnittswert der Frametimes für diese Sekunde und sagt erstmal 0 über die reale Frametime zwischen 2 Frames aus.
@ Wadenbeisser Hab ich weggelassen weil Adok sonst den Löschhammer schwingt wegen Komplettzitaten.
Und nein, die Einheit hat keine Schuld! Die arme Einheit 1/s ....Ich habe ja schon versucht es mit Beispielen zu zeigen aber Naja.
Du wirfst Einheit und Messgröße durcheinander! Wenn du Werte vergleichen willst, musst du sie auf die gleiche Einheit bringen!
Was wäre das denn für ein Vergleich wenn das eine in Frames pro Sekunde, das andere in ms und das nächste in Frames pro 25 Sekunden angegeben wird? Wie soll das besser sein?
Du könntest sagen, das bei den Messgrößen besser dabei stehen soll für was sie stehen....das würde halt recht lang werden...wenn da statt: FPS, Durchschnitt: steht...dies sind die Anzahl der Frames im Messzeitraum von 25s durch 25s geteilt.
oder statt 99th Percentile (Frametimes in FPS): Dies ist der Wert der gemessenen Frametimes, der an der oberen Grenze zu den schlechtesten 1% der gemessenen Frametimes liegt...bei ganzzahligen Quotienten etwas anders und dieser Wert, der in ms vorliegt, und bei dem kleinere Werte besser sind, wird auf FPS umgerechnet um wie im Vergleichswert Anzahl der Frames im Messzeitraum von 25s durch 25s geteilt auf längere gleich bessere Balken zu kommen und die Leser nicht zu verwirren.
Und nochmal....mach mal eine Gegenvorschlag.
Ergänzung ()
@SimsP
Ich denke aus der Diskussion steige ich aus .
Ich habe nämlich nicht ganz verstande worauf du hinaus möchtest....
Warum sollte der Cache zwingend gefüllt werden müssen? Der wird mit Daten gefüllt, die gerade gebraucht werden und wenn sie für die nächste Berechnung wieder gebraucht werden(und sie nicht durch andere ersetzt wurden) sind sie noch da und müssen nicht erneut aus dem Ram kommen...klar senkt das die Ramzugriffe.
Klar wäre es schön eine bessere Muticore Unterstützung per Patch zu bekommen....klar würden die GPUs dann besser ausgelastet...aber was das mit Ram zu tun hat weiß ich nicht....sieht man denn Unterschiede mit anderen Ram Geschwindigkeiten? Du verwirrst mich
Das heißt das entweder dein Mathematiklehrer versagt hat oder du 0 Textverständnis besitzt.
@Baal Netbeck
Ich werfe da nichts durcheinander, im Gegenteil.
Wenn du due Framtime als Einzelwert nimmst, also die Zeit zwischen 2 Frames, sagt das herzlich wenig über die Zeiten zwischen den anderen Frames aus die innerhalb der Sekunde berechnet wurden auf die sich die FPS Angabe bezieht. Zudem ist ein Durchschnittswert nunmal der Durchschnitt von allen Werten innerhalb des Zeitraumes. Da werden dann eben auch Ausreißer rechnerisch glatt gebügelt die den flüssigen Ablauf zerstören. Das ist ja schließlich auch das Problem bei dem berüchtigten Mikrorucklern.
Du kann st von einem Einzelwert nicht direkt auf die anderen Werte innerhalb des gewählten Zeitraumes schließen und umgekehrt.
Frametime = Einzelwert
FPS = Wert für eine Zeitspanne
@Wadenbeisser
Du beist dich weiterhin an der Einheit fest! Die Einheit kann nichts dafür! Egal ob Einzelwert oder Durchschnittswert. Die Einheit kann gleich sein.
Um nochmal das Auto zu bemühen....sagst du nicht auch: "ich fahre gerade 100 km/h." ? deiner Logik nach könntest du "Pro Stunde" gar nicht benutzen weil es eine Momentaufnahem ist und "pro Stunde" einen Durchschnitt sugeriert.....Du kannst die km/h in h/km umrechnen und wechselst damit den Umstand, das du fährst kein bisschen. Nur versteht dich keiner weil du dich gegen die Norm stellst.
Beim Tempo von 100 km/h fährst du 100 km in einer Stunde wenn du diese Geschwindigkeit für eine Stunde beihehälst.
Fährst du die erste halbe Stunde 50 km/h und die zweite Hälfte 100 km/h dann bist du wie weit gefahren?
Ein Hoch auf das Schulsystem.....
Ja aber der mehr Cache muss auch irgendwoher gefüllt werden. Die CPUs beschäftigen sich ja schließlich nicht den Großteil der Zeit nur mit sich selbst.
Das ist richtig- Aber bei einer Vermehrung der Cache- Hits durch Vergrößerung eben dessen, bleibt die gesparte Zeit, die man dadurch nicht den RAM belasten musste, tatsächlich für den Verkehr für neue angeforderte Nutzdaten über. Der Cache wirft seine Daten ja nur raus, wenn diese statistisch keinen Nutzen mehr liefern.
Wenn ich mehr Kerne habe tendentiell sogar eher höher als niedriger, da ja auch noch alle möglichen anderen Sachen im Hintergrund laufen und ich rein theoretisch mehr abarbeiten könnte, also auch mehr Datenrate vom Hauptspeicher brauche, um meine CPU sinnvoll auszulasten.
Sehr richtig beobachtet! Deswegen erhalten wir z.B. mit dem neuen Coffee Lake immer öfter Szenarien, an denen der Takt steigt, die FPS aber nicht mehr, obwohl auch die GPU nicht ausgelastet ist.
Was die Bedeutung schnellen RAMs mit niedrigerer Latenz in Zukunft immer mehr hervorheben wird.
@Wadenbeisser
Ja ein Hoch auf das Schulsystem! Du bist super im Antworten ausweichen.
In welcher Einheit gibst du denn dann die momentane Geschwindigkeit an? Was ist dein Gegenvorschlag?
Richtig....es gibt keinen. Vom X Frames pro eine Sekunde willst du auf 1 Frame pro X millisekunden wechseln. Du änderst nur den Bezugspunkt. Die Information ob es ein Einzelereignis oder ein Mittlewert über eine Zeitspanne ist, steckt nicht in der Einheit sondern in der Bezeichnung des Messwertes. Oder wird aus den durchschnittlichen FPS plötzlich ein Einzelwert, wenn ich von 1/s auf ms umrechne?
Oder beim Auto....von ich fahren gerade 100km/h auf..??? in was möchtest du die momentane Geschwindigkeit angeben?
Deiner Logik nach in sowas wie s/m...Mist...ist ja wieder ein Mittelwert....du könntest die Zeitabstände angeben, die von einem Tachosignal Ausschlag zum nächsten vergeht....das wäre dann ein Einzelwert....aber erstens kann damit keiner was anfangen und dann könntest du ihn ja mit dem Wissen um die Umrechnungsfaktoren auf km/h umrechnen...
Wir drehen uns im Kreis....
Ergänzung ()
Ich wäre ja sogar dafür zu haben alles in ms anzugeben....Aber gemischt zerstört doch die Vergleichbarkeit der Werte.
Gruß von der Physik, Geschwindigkeit ist die Strecke die in einer bestimmten Zeit zurück gelegt wird/wurde.
Der Wert auf deinem Tacho sagt dir nichts anderes als das du diese Strecke in einer Stunde zurücklegen kannst wenn du das Tempo beibehälst. Ob du das machst oder nicht ist dein Problem.
Wenn du es genauer haben willst kannst du ja auch m/s nehmen und dich auf die tatsächlich zurückgelegte Strecke beziehen. Viel Spass beim messen, berechnen und protokollieren.
Da dir aber offensichtlich jegliches Verständnis zu dem Thema fehlt empfehle ich dir die weiterhin Schulbank zu drücken.
Ich für meinen Teil bin aufgrund der Sinnlosigkeit der Diskussion raus.
Wenn ich also laut Tacho 100 km/h fahre, tue ich das eigentlich erst, wenn ich auch eine Stunde lang mit dieser Geschwindigkeit gefahren bin? Dann erzähle ich der Polizei beim nächsten Foto, dass ich die 100 km/h innerorts nur für zwei Sekunden gefahren bin und nicht für eine ganze Stunde, daher könne der Vorwurf, ich sei 100 km/h gefahren, gar nicht stimmen. Danke für den guten Tipp!
100km/h ist eine Einheit die wir zur Angabe einer aktuellen Geschwindigkeit nutzen.
Wie Wadenbeisser gesagt hat bezieht sich die Geschwindigkeit auf eine Strecke die Zurückgelegt wurde/wird.
Der Blitzer macht nichts anderes als mehrere Punkte zu messen und das ganze auf km/h hoch zu rechnen.
Geschwindigkeiten kann man nicht festlegen ohne es auf eine Strecke zu beziehen. Also ist jegliche Diskussion über sin und Unsinn des Tachos... Unsinn.
Daher hat er absolut recht.
Mit den FPS kann man kein Mikroruckeln feststellen da die FPS immer nur einen Durchschnittswert über einen gewissen Zeitraum zeigen.
Fallen diese also so stark das man es sieht kann von Mikroruckeln keine rede mehr sein...
60 FPS = 60 Frames Pro Sekunde. Sagt nichts darüber aus ob der 1 Frame länger als der 2 gebraucht hat.
Man kann aus der Frametime eine FPS bilden. Aber nicht aus der FPS die Frametime da man NUR eine durchschnittliche Frametime erhalten würde.
Aber bei 60 FPS ist ja idr. nicht jeder Frame genau gleich schnell Berechnet worden.
.
