• Hallo Gast, du kaufst gerne günstig ein und erfährst oft vor deinen Freunden von interessanten Angeboten? Dann kannst du dein Talent als Schnäppchenjäger jetzt zu Geld machen und anderen PCGH-Lesern beim Sparen helfen! Schau einfach mal rein - beim Test der Community Deals!

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

PCGH-Redaktion

Kommentar-System
Jetzt ist Ihre Meinung gefragt zu Radeon RX 6000 und Geforce RTX 3000 im Latenzvergleich: Was bringen große Caches und Latenzen?

Bei Grafikkarten wird das Thema Caches und deren Latenzen oft nicht in der Breite betrachtet wie andere Aspekte. Bei Chips & Cheese stellte man sich nun die Frage, wie die Entwicklung über die letzten Jahre generell war und inwieweit sich Radeon RX 6000 und Geforce RTX 3000 unterscheiden.

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

lastpost-right.png
Zurück zum Artikel: Radeon RX 6000 und Geforce RTX 3000 im Latenzvergleich: Was bringen große Caches und Latenzen?
 

Tolotos66

Volt-Modder(in)
Deswegen läuft meine Vega so gut :D
Topic: Interessantes Thema und könnte tatsächlich in Zukunt noch wichtiger werden > Softwareentwicklung.
Gruß T.
 

raPid-81

Freizeitschrauber(in)
Doch was bringt das in der Praxis? Der Autor von Chips & Cheese nimmt 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.
Hier wäre interessant zu sehen welcher Bereich welche Auflösung betrifft, leider schweigt sich die Quelle darüber aus.
 

ChrisMK72

PCGH-Community-Veteran(in)
Naja ... so lange das nicht unter 20 ms sinkt ...

Die ns hier(hab ich das richtig gesehen, auf dem Bild ?) ... keine Ahnung, was das überhaupt für ne Auswirkung beim Zocken für sagen wir mal 70 fps haben soll. Das sind ja nicht mal 10 ms(wären 10 ms 100 fps ?).

Is ms nicht schon ne tausendstel Sekunde, oder sowas ? Und was is dann ns ?

Mal eben in wiki gucken ....


edit:

Öhm ... ja ! :D

1.jpg


:confused:


edit2:

Ok, sagen wir mal, meine 3080 wäre jetzt ganze 100 ns "langsamer" als eine XY.

Das wären dann 0,00000001 Sekunde ? Oder so ?

Was is das dann in FPS ? :D

Ich rate mal: 0 (Null)


edit: Sry, ich weiß auch nicht, was heute wieder in meinem Kaffee war ! ;)
Kaffee 3.jpg



Ja und was bringt jetzt?
Zeitvertreib beim Kaffee, würd' ich sagen.
 
Zuletzt bearbeitet:

Symb0

Schraubenverwechsler(in)
Ob´s jetzt ne Nanosekunde oder Millisekunde sind ist auch egal.
Mein ICE in den Nerven ist mit ü30 schon lange abgefahren ^^
 

ΔΣΛ

PCGH-Community-Veteran(in)
Wo anders habe ich gelesen, dass sich dies nur auf niedrige Auflösungen auswirkt, wer also in UHD spielt wird davon wenig bis nichts mitbekommen, da der Cache zu klein ist.
 

hanfi104

Volt-Modder(in)
Hier wäre interessant zu sehen welcher Bereich welche Auflösung betrifft, leider schweigt sich die Quelle darüber aus.
Hohe Auflösung interessiert eher Bandbreite, FPS eher Latenz.Das sind eher grundtendezen, da hängt natürlich deutlich mehr dran.

Am Ende ist es vom Workload abhängig, wie die Balance zwischen Latenz, Bandbreite und Rechenleistung auszusehen hat.
 

ChrisMK72

PCGH-Community-Veteran(in)
Wie soll man auch 100 ns mitkriegen ? Dass man das überhaupt messen kann, finde ich schon faszinierend.


edit:

1.jpg



edit: In der Tat fänd ich das schon fast interessanter, womit man solche geringen Unterschiede wie 7ns, oder 100ns genau misst.
Das is echt spannend.

hat eine Testmethode mit OpenCL entwickelt

edit:

Was wären denn die 7ns Unterschied, aus dem Anfangsbereich in Sekunden ?

0,000000007 Sekunde ?
edit: Eine ms wären ja 0,001. Also weit, weit weg davon.

Ja, da muss man ziemlich genau und flink sein, mit der Stoppuhr. ;)
 
Zuletzt bearbeitet:

Placebo

BIOS-Overclocker(in)
Naja ... so lange das nicht unter 20 ms sinkt ...

Die ns hier(hab ich das richtig gesehen, auf dem Bild ?) ... keine Ahnung, was das überhaupt für ne Auswirkung beim Zocken für sagen wir mal 70 fps haben soll. Das sind ja nicht mal 10 ms(wären 10 ms 100 fps ?).

Is ms nicht schon ne tausendstel Sekunde, oder sowas ? Und was is dann ns ?
Es kommt nicht nur darauf an, wie schnell etwas passiert, sondern auch wie oft es benötigt wird ;) Cache-Zugriffe hast du im Prinzip bei fast jeder noch so kleinen Berechnung
 

Incredible Alk

Moderator
Teammitglied
Was wären denn die 7ns Unterschied, aus dem Anfangsbereich in Sekunden ?

0,000000007 Sekunde ?
edit: Eine ms wären ja 0,001. Also weit, weit weg davon.

Ja, da muss man ziemlich genau und flink sein, mit der Stoppuhr. ;)
Irgendwie hab ich die ganze Zeit gehofft dass ihr nur schlechte Witze macht aber das Thema schon verstanden habt. Da das anscheinend nicht so ist und Speicherlatenzen mit Framelatenzen verwechselt werden hier ein Denkanstoß:

Taktet doch euren RAM von 3600 mal auf 1866MHz runter. Dadurch erhöht sich die Latenz von grob 80 auf 160ns. Sind ja nur 0,00000008s Unterschied, das merkt man ja ganz sicher nicht... :rolleyes:

Es würde auch sicher keiner merken, wenn die Latenzen 10 mal so hoch wären und die GPU 50% der Zeit auf Daten warten müsste und die Auslastung nie über 50% käme. Sibd ja nurn paar Nanosekunden.
 

ChrisMK72

PCGH-Community-Veteran(in)
Es kommt nicht nur darauf an, wie schnell etwas passiert, sondern auch wie oft es benötigt wird ;) Cache-Zugriffe hast du im Prinzip bei fast jeder noch so kleinen Berechnung

Ja, ich denke da kommen auch noch viel mehr Sachen zusammen, bis dann wirklich das eine Bild auf dem Monitor erscheint, weswegen ich mich gefragt habe, was das im normalen Zockbereich bei sagen wir z.B. 50-100 fps so für Auswirkungen hat, die 7ns, oder die 100ns.

Beim Zocken geht's doch um Bilder pro Sekunde. Wobei ich da schon froh bin, wenn ich über 60-70 fps habe.
Machen da 100ns den Braten fett ?

Taktet doch euren RAM von 3600 mal auf 1866MHz runter. Dadurch erhöht sich die Latenz von geob 80 auf 160ns. Sind ja nur 0,00000016s Unterschied, das merkt man ja ganz sicher nicht...
Is das echt so einfach vergleichbar ?
Summiert sich das so derbe auf echt spürbare Unterschiede(also jetzt bei dem GPU Speicher) ?

Ich meine ... ob ich mit 60 oder 100 fps zocke, da merk ich den Unterschied.
Was machen denn da die 100ns dann in FPS aus ?
 
Zuletzt bearbeitet:

hanfi104

Volt-Modder(in)
Dein Prozi muss tausende von Berechnungen machen, um 1 Bild für dein Game rauszudrücken.
Sagen wir 100 FPS (=10ms Zeit für einen Frame)
Man darf also maximal 10 ms brauchen, eher <<10ms, Grafikkarte möchte sicher auch noch rechnen.
Gehen wir von einer 10.000 Berechnungen aus, die alle im RAM angefragt werden müssen.
10.000 * 200 ns = 2 ms. Die CPU wartet für seine Operationen alleine schon gesamt 2 ms, ohne selbst Arbeit zu erledigen.

Ist natürlich eine Milchmädchen Rechnung, denn zwischendrin kommen andere Funktionen hinzu wie Out of Order execution usw. Aber das sollte doch reichen um die ns in Relation zu bringen.
 

ChrisMK72

PCGH-Community-Veteran(in)
Ok, danke. Es geht also um ein Vielfaches des Unterschiedes.

Trotzdem würde mich am Ende des Tages mal ein echtes Zockbeispiel interessieren, bezüglich des gezeigten Unterschieds(im Bild des Artikels), da ich einfacher Zocker bin.
Und Zocker checken die FPS.

Verstehe ich das also richtig, dass man den Unterschied konkret dieses Vergleichs(oben im Bild) im Endergebnis gar nicht genau sagen kann, da ja ganz viele andere Einflüsse auch noch hereinfließen und man gar nicht weiß, wo wie viele Berechnungen statt finden ?

Also einfacher gesagt: Weniger Latenz is besser und wenn man genug fps hat, hat man genug fps.
 

Incredible Alk

Moderator
Teammitglied
Was machen denn da die 100ns dann in FPS aus ?
Wenns blöd läuft den Unterschied obs 150 oder 5 fps sind.

Ihr müsst verstehen dass es keinen direkten Zusammenhang gibt, genausowenig wie es einen zwischen beispielsweise cpu takt und fps gibt. Je nach Spiel, Einstellungen, Situation usw kanns völlig egal sein ob deine CPU mit 2 oder 4 GHz läuft - oder ersteres wird unspielbar ruckelig.
 

hanfi104

Volt-Modder(in)
Ja, kommt drauf an was limitiert.
Die OC Tests kennst du doch sicherlich
In den meisten fällen resulitieren die höheren FPS durch die reduzierte Latenz (von 100ns bei 2400CL16 bis <65ns 3800CL14)
 

ChrisMK72

PCGH-Community-Veteran(in)
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. ;)
 
T

-THOR-

Guest
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. :ugly: Tja, so läuft das nicht...
 

ChrisMK72

PCGH-Community-Veteran(in)
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.
 
Zuletzt bearbeitet:

raPid-81

Freizeitschrauber(in)
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. :ugly:
 

Olstyle

Moderator
Teammitglied
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

Volt-Modder(in)
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).
 
T

-THOR-

Guest
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

Volt-Modder(in)
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

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

Danke. :daumen:

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 ! :D :daumen:
 

Rollora

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

Danke. :daumen:

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 ! :D :daumen:
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

Software-Overclocker(in)
Anbei eine geringfügig erweiterte Variante:
rdna2_ampere_cache_latencies.png

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.
 
Zuletzt bearbeitet:

RX480

Volt-Modder(in)
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.
 

Anhänge

  • rBar vs SAM_minFps@4k.JPG
    rBar vs SAM_minFps@4k.JPG
    74 KB · Aufrufe: 12
Zuletzt bearbeitet:

Nathenhale

Software-Overclocker(in)
@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

Volt-Modder(in)
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)
 
Zuletzt bearbeitet:

gerX7a

Software-Overclocker(in)
@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).
 
Zuletzt bearbeitet:

RX480

Volt-Modder(in)
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:
 

Anhänge

  • Ampere vs Turing.JPG
    Ampere vs Turing.JPG
    157,7 KB · Aufrufe: 11
  • Spasity not Gaming.JPG
    Spasity not Gaming.JPG
    90,9 KB · Aufrufe: 9
Zuletzt bearbeitet:
Oben Unten