Radeon RX 6000 und Geforce RTX 3000 im Latenzvergleich: Was bringen große Caches und Latenzen?

[Atma]

Ein kurzer Blick auf die andere Grafik zeigt, das direkte Pendant, die RX 6900 XT ist durchgängig schneller als die RTX 3090, selbst zwischen 8 und 64 KB.

Tja, aber nur in der Theorie.

 

[hanfi104]

Ja, kommt drauf an was limitiert.

Die OC Tests kennst du doch sicherlich

RAM-OC auf AMD Ryzen 3000 im Test

Im RAM-OC-Test trifft AMD Ryzen 3000 auf XMP-Profile, hohe Taktraten und optimierte Timings. Das Übertakten ist deutlich einfacher geworden.

www.computerbase.de

In den meisten fällen resulitieren die höheren FPS durch die reduzierte Latenz (von 100ns bei 2400CL16 bis <65ns 3800CL14)

 

[ChrisMK72]

Ja, is klar ...
Mir ging's ja nur um den Unterschied bei der GPU, wenn die GPU der limitierende Faktor ist.

Aber da kann man ja im Grunde sich einfach die GPU Benchmarks anschauen.

Ich mein, wenn ich in WQHD keinen Speicherüberlauf hab und die FPS eh limitiere, da "genug", was heißt dann der Unterschied dort in der Grafik(in der echten Zockpraxis) ?

Ja klar. Schneller is besser.
Im Endeffekt spielen dann aber auch wieder Sachen wie G-sync rein, was ich mir kaufe und wie sich das auswirkt.


Ach ... alles nich so einfach.

 

[BigYundol]

Als Zocker schau ich auf die Percentiles, die Framevarianzen und die Framelatenz. Ø- und Peak-FPS sind Wurscht.

 

[-THOR-]

Hab vorhin in nem anderen Thread schon geschrieben.

Die latenzen wirken sich auf die Performance der CPU oder in dem Fall GPU aus.
Das war dann aber auch schon alles.

Durch bessere Latenzen verbessern sich weder Frametimes bzw. Varianzen, noch hat man weniger Ruckler!

Frametimes sind im ms Bereich, das hier ist Nanosekundenbereich. GEWALTIGER Unterschied.

z.B. werden die Frametimes im CPU limit nicht glatter, nur weil man die Latenzen bzw. Timings seines RAM runter setzt.
Die CPU performance steigt, aber die Varianzen bleiben genauso holprig wie vorher, da es nicht die Latenzen des Speichers sind, die für Varianzen oder Hänger im Frameverlauf sorgen.

Leider werfen manche Leute das wohl in einen Topf.
Von wegen wenn man seine RAM Timings nicht optimiert, erhält man niemals saubere Frametimes - völliger unsinn. Wäre aber schön, wenns so einfach wäre. Einfach von CL 18 auf CL 16, schon sind die Microruckler im CPU Limit weg. Tja, so läuft das nicht...

 

[ChrisMK72]

Peak-FPS sind Wurscht

Ja, so mach ich das schon lange. P1/P5 sind mir wichtiger. Deswegen limitiere ich die fps ja auch auf den Wert, wo's mir "reicht". Ob ich 150, oder 850 fps maximal hab is mir wurscht, da ich aktuell immer auf 70 fps limitiere, da ich das ganz angenehm empfinde zum Zocken und nicht (nutzlos) zu viel Strom verpulvere.

Deswegen hab ich mich ja gefragt, was das nun konkret für eine Relevanz hat, mit diesem Unterschied dort, im echten Zockalltag.

Ich lass einfach mal stehen schneller is besser.
Seh ich ja ein, da ich ja beim Speicher auch zusehe, nicht sehr langsamen zu nutzen und auch bei der CPU.

edit: In so fern leuchten mir auch die Beispiele mit dem RAM OC ein.

 

[raPid-81]

Hat vielleicht jemand mehr Infos zu dem Thema? Also ab welcher Auflösung die Latenz irrelevant wird?

Ich erkläre es mir so:

In 1080p / 720p sind die FPS sehr hoch, dadurch werden sehr viele Frames mit demselben Textur-Inhalt gerendered, die Renderpipeline greift größtenteils auf den schnellen Infinity-Cache zu da die Texturen dort bereits vorliegen - ergo ist hier jede Nanosekunde wichtig.

In WQHD / 4K sind die FPS niedriger und die Daten passen nicht komplett in den Infinity Cache, somit bringt der schnelle Cache hier nichts. Die Renderpipeline ist hier der limitierende Faktor, nicht die Zugriffszeit auf den VRAM.

Was auf welche Auflösung zutrifft ist geraten, und den Rest hab ich mir auch zusammengereimt.

 

[Olstyle]

Ist halt ein klassischer Fall von "Kleinvieh macht auch Mist". Wenn man einen Datensatz 10.000mal pro Frame braucht(oder 100 Datensätze 100mal) sind 100ns Unterschied plötzlich 1ms(=10% der Zeit bei 10ms Frametime=100FPS) mehr Zeit in der die GPU nicht rechnet sondern wartet.
Natürlich kann man das nicht direkt in FPS umrechnen, aber anders herum sind solche Themen oft spannend um zu verstehen warum eine CPU/GPU jetzt schneller ist als das alte Modell. Bei Zen2 zu Zen3 lässt sich z.B. sehr viel auf den Cache zurückführen.

 

[hanfi104]

z.B. werden die Frametimes im CPU limit nicht glatter, nur weil man die Latenzen bzw. Timings seines RAM runter setzt.
Die CPU performance steigt, aber die Varianzen bleiben genauso holprig wie vorher, da es nicht die Latenzen des Speichers sind, die für Varianzen oder Hänger im Frameverlauf sorgen.

Die Aussage ist zu pauschal. Mit RAM OC, bzw. Timing Optimierung kannst du erheblich dein CPU Limit anheben (also min FPS hoch / Zeit Frame to Frame runter) und dadurch auch deine Varianz (in Kombi mit einem FPS Limiter) reduzieren. Bzw kannst du den Framelimiter höher setzen, sofern er durch die CPU limitiert wird) Auch reagieren nicht alle Spiele gleich. Manche lieben Latenzen (die Regel) manche brauchen eher die Bandbreite (RAM Takt).

 

[Birdy84]

Ja und was bringt jetzt?

Diese theoretischen Ergebnisse helfen ggf. bei der Performanceanalyse.

 

[-THOR-]

Die Aussage ist zu pauschal. Mit RAM OC, bzw. Timing Optimierung kannst du erheblich dein CPU Limit anheben (also min FPS hoch / Zeit Frame to Frame runter) und dadurch auch deine Varianz (in Kombi mit einem FPS Limiter) reduzieren. Bzw kannst du den Framelimiter höher setzen, sofern er durch die CPU limitiert wird) Auch reagieren nicht alle Spiele gleich. Manche lieben Latenzen (die Regel) manche brauchen eher die Bandbreite (RAM Takt).

Öhm ja, das stimmt natürlich.

Wenn du die CPU Leistung anhebst und du vorher im CPU limit warst und somit schlechtere Frametimes hattest, dann werden die Frametimes natürlich besser, wenn du dann durch die zusätzliche CPU Leistung (dank besserer RAM Timings) wieder stärker ins GPU limit kommst.

Ich hab das aber jetzt mal bewusst außen vor gelassen, weil das eben zu nem Trugschluss führt.
Das wäre ein ähnlicher Trugschluss wie wenn die CPU egal wäre nur weil man in 4K spielt.

Das mag zwar gewissermaßen zutreffen ist aber einfach das falsche Fazit. (beim 4K Beispiel liegts eben an der vergleichsweise niedrigen Framerate die erreicht werden muss und nicht an der Auflösung)

 

[hanfi104]

Du sagst RAM OC verbessert das CPU limit aber es verbessert es nicht?
Eine höhere absolute Leistung ist die Verbesserung, auch in den Frametimes.

 

[ChrisMK72]

Hanfi, Alk und Olstyle haben für mich jedenfalls Erklärungen geliefert, die ich kapiere(so als einfacher Zocker) und nachvollziehen kann.

Danke.

Auch der Speicher OC Vergleich war gut in Zusammenhang mit anderen Hinweisen, dass es sich auch um tausende Berechnungen handeln kann, die sich halt summieren.

Also Kleinvieh x 10000 macht auch Mist !

PS: Seht einfach zu, dass ihr "genug" fps habt !

 

[Rollora]

Hanfi, Alk und Olstyle haben für mich jedenfalls Erklärungen geliefert, die ich kapiere(so als einfacher Zocker) und nachvollziehen kann.

Danke.

Auch der Speicher OC Vergleich war gut in Zusammenhang mit anderen Hinweisen, dass es sich auch um tausende Berechnungen handeln kann, die sich halt summieren.

Also Kleinvieh x 10000 macht auch Mist !

PS: Seht einfach zu, dass ihr "genug" fps habt !

Im Prinzip gehts darum.
Die CPUs bzw GPUs haben pro Sekunde ein paar Millionen Cachezugriffe. Wenn jeder Zugriff schneller geht, ist das für die Milliarden von Berechnungen die sie durchführen einfach besser, geht einfach alles schneller. Es hat aber eigentlich kaum Auswirkungen auf die gemessene Bildlatenz.
Wem die Bildlatenz wichtig ist, der sollte ohnedies auf einem CRT spielen

Darüber hinaus sind solche Tests einfach interessant um die Architekturen im Detail miteinander vergleichen. Früher war es üblich einfach nur Füllraten usw zu vergleichen. Oder Polygonmengen

 

[gerX7a]

Anbei eine geringfügig erweiterte Variante:

RDNA2/Navi21:

• bündelt in etwa (nicht genau) zwei CUs pro WGP und hat hier entsprechend 2 x 16 KB L0 (zusätzlich das übliche Gedöns: Instruction Cache, "K"onstant Cache, Registers)
• bündelt 5 Work Group Processors (also 10 CUs und etwas mehr) in einer Shader Engine, die über 128 KB L1 verfügt
• danach gibt es den globalen L2, hier 4 MB auf dem großen Chip, der für alle Shader Engines genutzt wird
• und neu ist nun der 128 MB große L3 als zusätzliche Cachestufe, bevor es auf den GDDR6-Speicher geht

Die Cachebereiche in der Grafik sind bewusst überlappend dargestellt und nur grob zu verstehen. Beispielsweise der L3 wird eine best case Latenz von etwa 114 ns haben, der L2 etwa bei um die 90 ns und ab etwa 4 MB sieht man die beginnende Übergangsphase, wo im L2 immer mehr Cache Misses auftreten und man zunehmen auf den L3 zugreifen muss, bevor dann ab etwa 8 MB der Großteil aller Prüfzugriffe zu einem Miss führt und fast alles auf dem L3 landet. Bereits ab > 32 MB sieht man dann die Cache Misses im L3 langsam beginnen zuzunehmen und die gemittelte Latenz wächst an und ab 256 MB ist man gemittelt schon fast mit der GDDR6-Latenz unterwegs, da nur noch wenige Prüfzugriffe zu einem L3-Cache Hit führen.

Letzten Endes nice to know, aber eher für Architekten interessant. Als Gamer kann man einfach auf das Endresultat schauen. Beispielsweise in 4K werden Texturen und sämtliche andere Maps so groß und vor allem die ganzen Buffer (Depth Buffer, usw.) so groß, dass der L3 zunehmend weniger ausreichend/passend dimensioniert ist und dessen Hitrate laut AMD auf etwas 57 % abfällt, was erklärt, warum die RDNA2-Karten in 4K relativ gesehen etwas stärker an Leistung verlieren, denn hier müssen mehr Speicherzugriffe bis auf das langsame GDDR6 durchgereicht werden, das hier nur mit 512 GB/s liefern kann.

Ampere/GA102:

• verwendet bis zu 128 KB dynamischen L1 pro SM (also pro 64/128 CUDA-Cores; daneben gibt es natürlich auch L0 Instruction Caches und Register Files, etc.)
• dynamisch deshalb, weil der Cache hier in vorgegebenem Rahmen frei konfiguriert werden kann von 128 KB L1 Data + 0 KB Shared Memory bis hinunter zu 28 KB L1 Data + 100 KB Shared Mem, was je nach Workload zur Optimierung genutzt werden kann
• danach folgen 6 MB L2 mit anscheinend einer Latenz von um die 130 ns (512 KB pro Speichercontroller)
• und danach geht es hier auf den OC-GDDR6, der mit in diesem Fall 936 GB/s die Blocktransfers deutlich schneller durchführen kann und daher auch in 4K etwas besser wegkommt

Abschließende Anmerkungen: Eine direkte Bewertung in Richtung wie es hier stellenweise für eine "Leistungsbetrachtung" versucht wird, ist problematisch, da hier viele Komponenten in die Gesamtbetrachtung einfließen.
Beispielsweise würde ich der Aussage im Artikel "... aufgrund der besseren Latenz für Anfragen zwischen L2 und L0 Cache bei der Radeon an, dass daraus die grundlegend etwas bessere Performance der Radeons in niedrigeren Auflösungen resultiert" eher widersprechen und stattdessen die deutliche Gap ab etwa 6+ MB im Graphen für den beobachteten Vorteil verantwortlichen machen. Der L3 von RDNA2 ist grundsätzlich zu klein um alle Daten vorzuhalten und wird selbst bei kleinen Auflösungen und Texturgrößen regelmäßig Datenzeilen überschreiben/neuladen und auf den GDDR6 zugreifen müssen, jedoch werden diese Zugriffe bei kleineren Auflösungen deutlich seltener vorkommen, sodass die gemittelten rund 100 - 120 ns Differenz hier deutlicher zum Tragen kommen dürften im Vergleich zum Zugriff bei der RTX 3090 auf den OC-GDDR6.
In der unteren Cache-Hierarchie dagegen ist Ampere nahe an den ALUs deutlich schneller und im mittleren Segment ist das RDNA2-Design etwas schneller, jedoch hat Ampere in beiden Fällen die größere Cache-Kapazität, sodass Misses etwas seltener vorkommen dürften als auf der RDNA2-Archtiektur, sodass ich eher den L3 (hier marketingtauglich als "Infinity Cache" bezeichnet) für den Hautpverantwortlichen halte.

*) In der Standard-Cache-Konfiguration hat der GA102 5,125 MB L1 (maximal 10,25 MB) und zudem 6 MB L2. Mit RDNA2 ist der Vergleich nur beim L2 noch einigermaßen direkt möglich. Hier stehen 4 MB bei RDNA2 dann 6 MB bei Ampere gegenüber. Der Vergleich nahe an den ALUs ist dagegen aufgrund der zusätzlichen Stufe bei RDNA2 nicht mehr ganz so einfach. Der L0 ist am schnellsten und noch am ehesten mit dem L1 bei Ampere vergleichbar, kommt aber nur auf insgesamt 1,25 MB bei der RX 6900 XT. Die WGPs werden bei der RX 6900 XT in acht Shader Engines gebündelt, die noch mal jeweils über 128 KB L1 verfügen, d. h. im best case kann man den typischen 5,125 MB L1 bei Ampere maximal 2,25 MB L0 + L1 gegenüberstellen.

 

[RX480]

Die CacheMisses(x) nehmen zwar in 4k zu, aber die minFps sind noch ausreichend gut bei der 6800XT@SAM.
(Control mal Außen vor, ist eh ne komische Engine)
Die größere 3080 kann etwas mehr in 4k von rBar profitieren.

Ob der Gewinn mit XYZ klein oder groß ist sollte man net nur an Zahlen fest machen.
Wichtig ist das Gameplayfeeling, wie Inputlag oder ob man die 60fps schafft, um Tearing zu vermeiden.

(x) CacheMiss bedeutet net automatisch, das die komplette Information fehlt, sondern meist muss nur ein
kleinerer Teil über die 256 bit nachgeholt werden.
Mit SAM/rBar spielen sicher auch sehr kleine Datenpakete von der CPU ne Rolle.
Je eher geladen, desto weniger Leerlauf = sparsamer. Deswegen gibts Mehrleistung für lau.

 

[Nathenhale]

@gerX7a
Man darf auch nicht vergessen das Ampere durch seine Architektur von Natur aus in geringeren Auflösungen bzw. In Spielen die viele Integer Berechnungen machen Nachteile zu RDNA 2 hat.
Stichwort: Doppelte Floting points operations bei Ampere.
Zusammengefasst:
Höhere Auflösungen:
Hit Rate des L3 Caches bei RDNA 2 sinkt -> Leistunges verlust
Ausnutzung der der GPU steigt bei Ampere -> Leistung Steigt

 

[RX480]

FP16x2 bei RDNA 2 vs FP16 x1 bei Ampere
Könnte bei HDR10@LP ne Rolle spielen.(in Godfall kanns Jeder selber testen)

Ampere ist nach m.E. durch den INT+FP16-Kompromiss net gerade optimiert für Gaming.
Für jede INT oder FP16-Operation fällt ne FP32 weg.(war bei Turing net so)

 

[gerX7a]

@RX480: Ob die "minFps ausreichend" sind oder nicht ist eine rein subjekte Betrachtung und liegt damit außerhalb meiner Betrachtung. Fakt ist, dass wenn man die Leistungskurven und Auflösungsskalierungen der beiden GPU-Serien gegenüberstellt, RDNA2 relativ gesehen in 4k stärker abfällt als Ampere, was schlicht an dem L3 liegt **), der aus Gründen der Wirtschaftlichkeit nur eine beschränkte Größe auf dem Die haben darf (Wafer-Kosten) und bei 4K in Relation gesetzt so klein wird, dass die Leistungseinbußen größer ausfallen. Das sind keine "Welten" *) , aber die Unterschiede sind deutlich zu sehen und klar auf den L3 und die deutlich steigende Zahl an Cache Misses zurückzuführen (wie es auch AMD selbst erklärt). Für 4K ist offensichtlich eine RTX 3090 oder bald eine RTX 3080 Ti die bessere Wahl i. V. z. einer RX 6900 XT (auch bereits ohne die bessere Raytracing-Performance oder DLSS; was aber selbstredend keinen daran hindern muss mit bspw. seiner RX 6900 XT glücklich zu sein, denn die ist dennoch eine gute Karte).

*) Wobei natürlich auch das subjektiv ist. Im PCGH-Test mit 20 Titeln ist die RX 6900 XT i. V. z. RTX 3090 quasi durchgehend langsamer, in acht Titeln gar um >= 20 % langsamer und bereits bei zwei weiteren Titel > 18 % langsamer. Der Mittelwert über alle 20 Titel liegt bei 17,1 % langsamer als die RTX 3090 in 4K mit Max-Settings.

Ergänzend: In 1440p ändert sich das Bild jedoch nicht übermäßig. Der Mittelwert verringert sich nur auf 13,5 % langsamer als die RTX 3090. Erst mit aktiviertem SAM kann die Karte hier signifikant besser abschneiden bei den 20 Titeln, bleibt aber dennoch gemittelt 9,9 % langsamer als die RTX 3090 in 1440p bei Max-Details bei der PCGH. Aktiviert man auch auf der Ampere-Karte ResBAR; wird der Abstand wieder ein wenig größer.
(Ein deutlich besseres Bild in 1440p zeigt sich (ohen SAM) erst im Vergleich zur RTX 3080. Hier ist die RX 6900 XT im Mittel über alle 20 Titel nur noch 3,4 % langsamer als die RTX 3080.)

**) Natürlich in Kombination mit dem deutlich langsameren GDDR6.

***) Ergänzend zu FP16: Der Vergleich ist unzutreffend. RNDA2 hat bzgl. FP16 keinen architektonischen Vorteil ggü. Ampere.

RX 6900 XT: 46,1 TFlops
RTX 3090 FE: 35,7 TFlops

Der Unterschied ist im höheren Takt der RDNA2-GPU begründet, der Durchsatz ist in beiden Architekturen gleich. Bei Ampere schreibt man aktuell lediglich "1x", da man die zusätzliche FP32-Einheit nicht auf eine FP16-Prozessierung erweitert hat.
Darüber hinaus ist das bei Ampere auch lediglich die FP16-Leistung exklusive der Tensor Cores; mit diesen ist die FP16-Leistung gar noch um ein Vielfaches höher.

@Nathenhale: "Ampere Integer-Nachteile"? Rein architektonisch hat Ampere diesbezüglich grunsätzlich keinen Nachteil, eher gar einen Vorteil, denn Ampere kann hier gar eine INT-Op und eine FP-Op parallel ausführen, was RDNA2 nicht kann. Und bezüglich des reinen INT-Durchsatzes der ALUs dürften beide Designs in etwa vergleichbar schnell sein.
Was jedoch einen Unterschied ausmachen wird, ist der deutlich höhere Takt bei RDNA2, d. h. dieses kann tendenziell schon etwas mehr INT-Ops prozessieren, kommt aber bei FP-Ops nicht mit, da Ampere hier gar zwei Operationen parallel prozessieren kann.
Was jedoch schwer fällt, ist die Relevanz diesbezüglich auch schlüssig zu belegen. Es zeigen sich zwar eindeutige Unterschiede zwischen einzelnen Engines und gar auch nur in bestimmten Titel, jedoch bleibt die Frage hier unbeantwortet, ob bessere Ergebnisse bei RDNA2 hier speziell auf diesen "Integer-Vorteil" oder eher allgemein auf eine grundlegend bessere Engine-Optimierung für die RDNA-Architektur zurückzuführen sind?

*) Ergänzend bleibt zu berücksichtigen, dass die Relevanz an INT-Ops grundsätzlöich in jeder GameEngine kleiner ist als die von FP-Ops, d. h. der deutliche Taktunterschied führt nicht zu einer äquivalent höheren, relevanten INT-Performance. Der Anteil der INT-Operationen schwankt von Engine zu Engine und selbst zwischen Titeln auf einer Engine und liegt bei etwa 15 % bis voraussichtlich bestenfalls 33 % INT-Ops (anteilig).

 

[RX480]

Darüber hinaus ist das bei Ampere auch lediglich die FP16-Leistung exklusive der Tensor Cores; mit diesen ist die FP16-Leistung gar noch um ein Vielfaches höher.

Sparsity ist net in Games nutzbar, ist ein Sonderfall für Workstation-Anwendungen

btw.
Ampere vs Turing beim Nutzen von INT+FP16: