AMD/ATI - RDNA3 (Navi 3X, Radeon RX 7000 Serie, tlw. Chiplets, 5/6 nm, 2022) [Archiv] - Seite 4

Edgecrusher86

2021-07-28, 12:06:43

Hm, also ich weiß ja nicht, aber die bisherigen Prognosen erscheinen doch viel zu hoch zu sein.
RDNA3 ~ 2,7x RDNA2 und AD102 ~ 2,2x, selbst mit 60WGP (15360SP) und 144SM (18432CC) und je TSMC N5(P) plus z.B. 50% verbesserte Effizienz auf die Vorgänger-Generationen.

Dann bräuchte auch AMD locker 450W TGP und NV sicherlich 50-75W mehr, sollte man wieder auf G6X setzen.
Bei solchen Verbrauchswerten sind AiOs für die Referenzkarten eigentlich Pflicht, sollen es keine 3 bis 3,5 Slot-Monster werden.

Mal eine ganz grobe Rechnung:

AMD RDNA3 -> + 170% auf RDNA2 -> Boost durch Einheiten +110% (60 WGP) auf die Straße gebracht (3x SPs verbaut) - Taktratenboost + 30% (3 GHz zu ~ 2,3 GHz der RX 6900XT).

NV AD102 -> + 120% auf GA102 -> Boost durch Einheiten + 60% auf die Straße gebracht (+ 71% verbaut) - Taktratenboost + 40% (2,5 GHz zu ~ 1,8 GHz der RTX 3090).

Nahe liegend wäre doch eigentlich, dass man, um die Effizienz im neuen Prozess massiv zu steigern neben sehr großen Caches und massiv Einheiten wäre die beste Methode sicher niedrige Taktraten
[z.B. max. 10% Mehrtakt] und entsprechend geringe Spannungen. Also mehr oder weniger 50-70% Mehrleistung auf die aktuelle Generation bei ähnlichen Power-Budgets fände ich sinnvoller -
am liebsten maximal 300W TGP auf beiden Seiten. Mehr ist höchstens im Winter angenehm. :D

Man muss ja auch bedenken, dass zu schnelle Karten gar nicht im Sinne der Hersteller sein dürfen - das Groß der Gamer würde bei über doppelter Leistung doch sogar zwei Generationen aussetzen und nicht eine.
Da müsste man schon seitens der Devs mit extremen RT-Einsatz entgegen wirken - aber im Prinzip bleibt die gemeinsame Basis ja PS5 & Series X - also kann man auch nicht übertreiben,
denn dann wäre auch mithilfe FSR nur 4K30 machbar [optional vielleicht noch einen 4K60 Performance-Mode exkl. RT]. Gut, hier wären natürlich eine PRO und Gegenpart möglich in zwei oder drei Jahren.

Bezüglich MSRPs erwarte ich $/€ 1499 für das AMD-Topmodell "7900XT(X)" und $/€ 1749-1999 bei NV für die RTX 4090 - was die Straßenpreise betrifft: Bestimmt wieder + $/€ 500-1000; wenn das mal schickt.

Daredevil

2021-07-28, 12:08:20

Warum sollte sie im Nichts verpuffen und wo schafft man mit einer 6900XT/3090 in UHD konstante 60fps+ (wohlgemerkt nicht avg.)?

Bei 8 von 17 Spielen im CB-Parcours schaffen 3090/6900XT keine 60fps (die mit 59fps habe ich mal zu 60+ gezählt, ansonsten wären es 10 von 17). Und iirc nutzt CB in UHD auch gar nicht immer max. Settings, damit eben noch eine gute Performance herumkommt.

Ansonsten ist die Frage, was der Anspruch ist. Wenn ich wirklich will, dann kann ich selbst den Hexer mit Mods und Ini-Tweaks auf einer 6900XT in UHD problemlos auf <30fps drücken. Und das Ding ist von 2015.
Und Raytracing nicht vergessen. Zum Beispiel CP2077 läuft laut PCGH auf 4K mit DXR Psycho mit 22fps oder so, und das auf einer 3090 ;) Ja, DLSS gibts noch. Sag das heute aber einer AMD-GPU.

Man löst damit ja nicht nur die "Performance-Probleme" von heute sondern stellt sich auch den Anforderungen der Spiele der Zukunft. Nicht jeder kauft jedes Jahr eine neue GPU. Meine wird bald 3-jährig :D
Daredevil hat schon wieder vergessen das noch kein einziges NextGen Spiel auf dem PC released wurde und das einzige Crossgen Spiel Cyberpunk scheiße läuft.

PS: 5K sieht besser aus als 4K.
Mal fernab vom Preis, gerade PC-Spieler haben in der Vergangenheit immer maximale Leistung bei Grafikkarten auch problemlos nutzen können.

Das ist auch schon seit Ewigkeiten so.

Wer das bezahlen will ist logisch, wirklich nur diejenigen, die entweder viel Zeit und Freude mit ihrem Hobby verbringen oder jene, die nicht viel Zeit haben, dafür aber maximale Unterhaltung mit bester Optik haben wollen.

Spielst du denn gerne alles auf Minimum? Mal an Next-Gen gedacht?

Diese Siliziummonster kommen doch erst spät 2022 auf den Markt, meinst du da stagnieren die Spiele-Anforderungen plötzlich?

Ich verstehe das alles, sonst hätte ich ja auch keine 3090.
Aber jeder dieser potentiellen Käufer könnte heute auch schon eine 3090 im SLI haben, wie viele Leute gibt es hier im Forum, die damit rum laufen?
Das meinte ich damit.

Schneller ist immer besser, aber es gibt Grenzen. Grenzen, die in den nächsten Jahren eingerissen werden, heute aber relevant sind.
Gerade bei AMD werden Grenzen aktuell rapide eingerissen, weswegen die nächste Gen schon deutlich schneller sein könnte und es sich schlicht nicht lohnt, "für die letzten wenige Prozente" das doppelte zu bezahlen.

Ich bemerke selbst bei mir, das ich meine 3090 selten mit voller Leistung fahren lasse. Weil es schlicht schon reicht, sie mit 1800Mhz, 1500mhz und gar 1000Mhz laufen zu lassen. Ausnahmen machen in der Tat nur Raytracing Spiele oder schlecht optimierte AAA Games.
Der Großteil fliegt aber in 4k davon, weswegen man in der Tat schon auf 6k+ gehen kann, oder halt in HighFPS spielt. ( Ziel ist bei mir immer 120fps )

Jeder der in den letzten Jahren zum Gaming nen 16c+ Prozessor gekauft hat, weil der "Zukunftssicher" ist, kennt das.
Jede neue Generation mit halb soviel Kernen lässt die vergangene weit zurück.

PS: Ich halte die Arme aber gerne offen, wenn AMD hier wegfliegen sollte. :D

The_Invisible

2021-07-28, 12:21:36

Daredevil hat schon wieder vergessen das noch kein einziges NextGen Spiel auf dem PC released wurde und das einzige Crossgen Spiel Cyberpunk scheiße läuft.

PS: 5K sieht besser aus als 4K.

Diese NextGen Sprünge verschwimmen immer mehr, man sehe sich nur mal die Leistungssteigerungen bis zur PS4/XBoxOne an und danach... es werden zudem anscheinend auch Zwischenkonsolen eingeschoben womit man über Zeit noch weniger einen Leistungssprung hat

Die Zeiten wo PS3/4 noch 16 mal so viel Speicher/Flops hatten sind vorbei, dort hat natürlich auch die grafische Qualität immer immens zugelegt.

Beim Flightsim 2020 musste man auch recht viel optimieren damit es auf den Konsolen mit 30fps läuft. Wüsste daher nicht welches "NextGen" Spiel erscheinen soll das alle aktuellen Karten obsolet macht.

Nightspider

2021-07-28, 12:27:52

Der Flightsim ist aber auch nicht gerade optimiert oder ressourcenschonend auf den Markt gekommen.

Schau dir Ratchet & Clank an, an besten im 40fps Modus.

Aber jeder dieser potentiellen Käufer könnte heute auch schon eine 3090 im SLI haben, wie viele Leute gibt es hier im

Der war gut.

SLI ist tot und war früher schon nur mittelmäßig toll.

Daredevil

2021-07-28, 12:42:18

Schau dir Ratchet & Clank an, an besten im 40fps Modus.

"Next Gen" ist für dich also, wenn das Spiel mit 20fps weniger läuft wie ein Mario auf der Switch? ;D
Das Märchen der "Next Gen" Spiele wird nicht geschrieben werden, wenn aktuelle Konsolen jetzt schon Probleme haben, ihre Last Gen Titel ordentlich in 4k zu befeuern.
Zusätzlich kommt noch das schlecht performende Raytracing von AMD dazu, welches ebenfalls "Next Gen" ist.
Einzig und alleine FSR kann die Konsolen und wirkliche "Next Gen" Spiele retten, wenn man nicht mit Daumenkino Geschwindigkeit spielen will.

SLI ist tot und war früher schon nur mittelmäßig toll.
Und was sagt dir, dass AMDs MCM alles besser macht?
Sowas hier war auch nur hoch spezielle Hardware, die sehr teuer war.
https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fwww.hartware.de%2Fwp-content%2Fuploads%2F2019%2F06%2FAMD-Radeon-Pro-Vega-II-Duo-Platine.jpg&f=1&nofb=1

Nightspider

2021-07-28, 13:11:58

Weil MCM sich nach außen eher wie ein einzelner Chip verhält und das Ganze eben als Ersatz für große monolithische Chips gedacht ist.

Gerade das die neuen Konsolen bei vollen Effekten mit Raytracing bei optimierten Spielen schon keine 60 sondern nur 30/40fps schaffen spricht doch dafür das man am PC noch mehr GPU Leistung benötigen wird für hohe FPS.

vinacis_vivids

2021-07-28, 14:22:38

Natürlich ist MCM besser, weil die zunehmenden random-Zugriffe auf den großen IF$ schneller und energiesparender sind als die Zugriffe auf den VRAM-Speicher (langsam und energieintensiv).

Vorteile:
-Mehr CU`s -> schneller
-Mehr Cache -> schneller
-Mehr Speicher -> höhere Auflösung, mehr Assets
-Energiesparender -> Einsparung der Bandbreite ggü. 2xGPU Lösung
-Einsparung von Bauteilen ggü. 2xGPU Lösung
-Platzsparend -> Wenig Raum, viel Leistung
-höhere Effizienz
-Einsparung der Kontrolllogik, I/O ggü. 2xGPU Lösung
-Leistungskrone als Nr.1 im GPU Markt

Nachteile:
-Treiberentwicklung
-auf dem ersten Blick für den Laien teuer in der Anschaffung
-Umgewöhnung der Kunden auf MCM

Insgesamt überwiegen die Vorteile und deshalb ist MCM unvermeidlich.

Daredevil

2021-07-28, 14:47:40

Natürlich ist das sinnvoll, AMDs großer Durchbruch in der CPU Sparte hat ja mit den Chiplets und dem Cache bei den GPUs begonnen, wo man "viel bekommt, wenig bezahlt", egal ob AMD oder halt der Endkunde.
Kompromisse muss man allerdings auch eingehen, AMD ist immer noch ( mit riesigen Schritten ) am optimieren.

Ich glaube nicht, dass das die Endlösung für alle Probleme ist, aber 2021/2022 ( Chip shortage ) ist es definitiv etwas, womit AMD große Schritte gehen kann und ein Alleinstellungsmerkmal hat, durch die Erfahrung der letzten Jahre.

vinacis_vivids

2021-07-30, 08:38:27

Wurde das hier schon gepostet?

https://twitter.com/Olrak29_/status/1419702500945371150/photo/1

https://abload.de/img/e7pldjovuaqjgtuurkr8.png

512MB IF$ mit einer eigenen/getrennten Clock Domain und dieses massivste Kraftwerk mit 15360SPs

Kommt natürlich auch drauf an wie der workgroup distributor die SIMD32 ansteuern kann.

Speicherbestückung: Pro Shader Engine können 4 oder 8GB GDDR6 angesteuert werden.
Das ergibt also eine Speicherbstückung von max. 24GB für den single Chip und 48GB für den MCM N31 als Consumer/Gamer Variation.

Ich denke beide Gruppen werden bedient werden und für Gamer reicht generell der single Chip mit 24GB und 7680SPs. Mit leichten IPC Verbesserungen sind +50% Leistung gegenüber der RX6900XT drin.

Bei 6 64-bit-controller sind es 384bit SI für den MCM und 192bit für den singel Chip.
Da der IF$ ausgebaut wird, steigt die Bandbreite deutlich langsamer als Chips ohne IF$.

MCM N31 - 7900XTX
GPU-CLK ~ 3,0 Ghz
15360SPs
fp32 ~ 92,16 Tflops :eek:
fp16 ~ 184,320 Tflops :eek:
512MB IF$ :eek:
48GB GDDR6 16 Gbps
384bit SI
768GB/s Bandbreite

Da das SI doch relativ schmal bleibt, ist der Energieverbrauch sehr gut zu kontrollieren. Statt TBP 500W können es auch "nur" 400W für den MCM sein, was ja sehr gut ist, weil für den Singelchip dann 250W rauskommen.

Interessant sind die 512MB IF$ um auch für echtes natives 8K die entsprechende hitrate zu erreichen. 256MB IF$ für den singel-Chip reicht dann für 5K bzw. 6K native- Rendering-Auflösung.

Anschaffung wird entsprechend teuer was 8K Monitor und 8K GPU angeht, spart schon mal das entsprechende Kleingeld ihr lieben ;D

dargo

2021-07-30, 08:45:02

Anschaffung wird entsprechend teuer was 8K Monitor und 8K GPU angeht, spart schon mal das entsprechende Kleingeld ihr lieben ;D
Pfff... es gibt noch nicht mal 4k GPUs die schnell genug für mich sind und du träumst schon von 8k? :tongue:

basix

2021-07-30, 08:55:21

MCM N31 - 7900XTX
GPU-CLK ~ 3,0 Ghz
15360SPs
fp32 ~ 92,16 Tflops :eek:
fp16 ~ 184,320 Tflops :eek:
512MB IF$ :eek:
48GB GDDR6 16 Gbps
384bit SI
768GB/s Bandbreite

Das ist deutlich zu optimistisch.

Momentan gehen alle von 256b SI und entsprechend 16/32 GByte Speicher aus
3.0 GHz? Bei so vielen SPs höchst unwahrscheinlich. Auch mit neuer Architektur, N5P, Chiplets, grossen IF$ und 500W. Ich wäre ziemlich zufrieden, wenn es 2.5 GHz bei 400W werden. Ich lasse mich gerne überraschen ;) Aber glauben tue ich daran nicht.

Geldmann3

2021-07-30, 09:21:39

Das ist deutlich zu optimistisch.

Momentan gehen alle von 256b SI und entsprechend 16/32 GByte Speicher aus
3.0 GHz? Bei so vielen SPs höchst unwahrscheinlich. Auch mit neuer Architektur, N5P, Chiplets, grossen IF$ und 500W. Ich wäre ziemlich zufrieden, wenn es 2.5 GHz bei 400W werden. Ich lasse mich gerne überraschen ;) Aber glauben tue ich daran nicht.

Von 3Ghz gehe ich ebenfalls nicht aus. Doch von 512MB IF + 32GB bei den Topmodellen durchaus.

Zossel

2021-07-30, 09:45:24

HOT

2021-07-30, 09:57:35

Bei den Verbräuchen, die da im Raum stehen? Knapp 3GHz sind kein Problem. Der wird sicherlich noch ein bisschen besser taktbar sein als N21.

Modelle mit 1 GCD wird es mMn nicht geben. Nur 2x N31 (voll und salvage), 2x N32 (voll und salvage), alles darunter N33. Das wird sich angesichts des N33 einfach nicht lohnen.

Ich denke aber auch, dass N31 192Bit GDDR hat, beide dann 384Bit, also dann 24GB. Der kleinere N32 wird jeweils 128Bit haben, da werden die kolpotierten 256Bit herkommen. Auch N33 wird mMn 256Bit oder 192Bit haben, wahrscheinlich eher 256Bit und dafür einen erheblich kleineren IF$.

Cyberfries

2021-07-30, 10:19:39

Wurde das hier schon gepostet?

War auch bereits in den News.

Speicherbestückung: Pro Shader Engine können 4 oder 8GB GDDR6 angesteuert werden.

So funktioniert das nicht, Shader Engines und Speicherinterface hängen in keinem Verhältnis zueinander.
Siehe 5600xt mit 192bit und 2SEs.

... und für Gamer reicht generell der single Chip mit 24GB und 7680SPs.

Es gibt keinen N31 single Chip. Sowohl N31 als auch N32 haben 2 GCD.

So sollten auch grössere Verlustleistungen beherrschbarer werden.

Gibt doch bereits Karten mit 420w unter Luft von MSI und Zotac.
Von Galax gibt es sogar eine 460w 3090.

Wenn AMD 512 MByte V-Cache verbauen sollte, müssten es total dann nicht 544 MByte IF$ sein?

Würde mich wundern wenn es Ryzen V-Cache ist und keine eigenständige Lösung.
Das wären sehr viele Ebenen sehr kleiner Chips in einem unpraktischen Formfaktor, 512mb sind in 7nm nur 288mm².
Und nach derzeitigen Gerüchten schreibt AMD Modularität eher klein, legt eigene GCD für jeden Chip auf.
edit: Ist der Ryzen-L3$ nicht auch langsamer angebunden als der Inf$?

-------------------------
Zur Preisdiskussion:
Ich denke nicht, dass wir N31 als klassisches Topmodell sehen können, als N21-Nachfolger.
Es scheint so, als wolle AMD hier eine neue Klasse über dem bisherigen Portfolio eröffnen.
Nachfolger von N21 wird N32, auch preislich.

Zossel

2021-07-30, 10:38:10

Gibt es mittlerweile eine einheitliche Sicht wie die Multichip-GPUs von AMD aussehen?
Also welche Einheiten auf welchem Chip liegen, welche Verbindungen aus den Dies raus gehen?
Wie ist da der aktuelle Stand der Dinge?

Nightspider

2021-07-30, 10:39:57

Ich denke nicht, dass wir N31 als klassisches Topmodell sehen können, als N21-Nachfolger.
Es scheint so, als wolle AMD hier eine neue Klasse über dem bisherigen Portfolio eröffnen.
Nachfolger von N21 wird N32, auch preislich.

Alles andere ist auch realitätsfernes Denken.

Alleine der MCD wird schon größer wie die GPU einer aktuellen ~~400 Euro Grafikkarte.

Mit 6nm MCD wird man vielleicht leicht darunter kommen.

davidzo

2021-07-30, 10:43:14

Ich schlage *ATX-Mainboards vor wo ein Slot für die GPU auf der bisherigen Rückseite des Mainboards sitzt und die GPU von einem Tunnelkühlkörper oder einem Towerkühler gekühlt werden um gleiche Richtung des Luftstroms für CPU und GPU zu haben.

So in dieser Art:
https://www.ien-dach.de/uploads/tx_etim/LA_LAV_gr.jpg

So sollten auch grössere Verlustleistungen beherrschbarer werden.

Das sind die Fischer Elektronik Lüfteraggregate. Sowas ist gedacht um da viele mostfets dranzuschrauben und so die wärme über die ganze Außenfläche verteilt einzuleiten. Für eine GPU mit einem single hotspot sind die nicht effektiv.

Bei soviel Gegendruck wie so ein Tunnel verursacht wären vermutlich auch Radiallüfter besser, da höherer statischer Druck als Axialgebläse. Und damit wären wir wieder bei der klassischen Blowerkarte - nur eben in 4-6 Slot statt den üblichen 2 Slot.

Die enorme Lamellenlänge täuscht auch sehr über die Leistungsfähigkeit hinweg, da mit zunehmender Länge der Flow laminarer wird und eine dicke Gleitschicht bildet die den Wärmetransfer stört. Es gibt ein paar Research papers dazu die beweisen dass unterbrochene oder versetzte, also staggered Fins ab bestimmten Längen gut die doppelte Kühlleistung bringen.
Es würde sich also durchaus lohnen den Kühler seitlich anzubohren um den laminaren Flow zu stören.

Betrachtet man einen OEM PC als geschlossenes System wäre die Lüfterposition wie im Server sicherlich sehr effektiv.
Aber in Zeiten von Riesengehäusen mit unbegrenztem Airflow unter über und neben der GPU, sind 3x 100mm Lüfter mit einem triple oder qudadrupleslot Lamellenpaket drunter immer effektiver als ein einzelner 120er mit einem Strangprofil oder "Tunnelkühlkörper"

basix

2021-07-30, 12:33:03

Würde mich wundern wenn es Ryzen V-Cache ist und keine eigenständige Lösung.
Das wären sehr viele Ebenen sehr kleiner Chips in einem unpraktischen Formfaktor, 512mb sind in 7nm nur 288mm².
Und nach derzeitigen Gerüchten schreibt AMD Modularität eher klein, legt eigene GCD für jeden Chip auf.
edit: Ist der Ryzen-L3$ nicht auch langsamer angebunden als der Inf$

Den Zen V-Cache zu nehmen würde einfach deutliche Skalen-Effekte zusammen mit den CPUs erlauben, den man mit einem einzelnen 250...300mm² MCD nicht hat. Ausserdem kann über die Stack Höhe die Kapazität variiert werden.

Und was ist am Formfaktor unpraktisch? Ist ein Stacked-Cache mit 36mm² Fläche, mehr nicht. Da emfpinde ich ein grosses Die als deutlich unpraktischer.

Und zur Modularität:
Laut bondrewd sind es zwei verschiedene GCD für N31 und N32 aber das selbe MCD. Da macht V-Cache nochmals deutlich mehr Sinn (N32 = reduzierte Stack-Höhe). MCD + IF$ sind identisch und erlauben Skaleneffekte + MCD Salvaging zwischen N31 und N32. 2x GCDs reduziert die Kosten vs. monolithisch, auch wenn immer 2x GCDs verbaut werden.

-> Das alles empfinde ich schon als ziemlich modular.

Zwei unterschiedliche GCDs für N31/32 ist einfach ein Kostenfrage als auch eine Frage der Portfolioauslegung: N32 ist vermutlich das, was wir max. monolithisch gesehen hätten und wird vermutlich den 300W Platz im Portfolio bekommen. N31 ist dann die Over-the-top Lösung, um endlich die unangefochtene Performance-Krone zu erhalten.

Cyberfries

2021-07-30, 13:58:13

Gibt es mittlerweile eine einheitliche Sicht wie die Multichip-GPUs von AMD aussehen?

News (http://www.3dcenter.org/news/hardware-und-nachrichten-links-des-28-juli-2021) vom 28.: Nur Inf$ im MCD

Und was ist am Formfaktor unpraktisch?

Vielleicht nicht die perfekte Begrifflichkeit. Ein dünner hoher Stapel erschwert Wärmeabfuhr und Herstellung.
Zwei große Chips (ca.18mm Kantenlänge) mit einer nur 6mm breiten Brücke zu verbinden angesichts der Datenmenge...
Wenn überhaupt könnte ich mir noch mehrere Stapel auf einem breiteren MCD vorstellen.

basix

2021-07-30, 15:20:35

AffenJack

2021-07-30, 16:01:44

N31 GCD Tapeout anscheinend geschehen. Wieso geht man immer noch von Q3/2022 aus? Das sind >10 Monate zwischen Tapeout und Release?! Normal sind eher 6...9 Monate. Ich bin stark der Meinung, dass wir N31 in Q2/2022 (April oder Mai) sehen werden (9...10 Monate seit Tapeout). Evtl. nicht in riesigen Stückzahlen aber weniger knapp alls bei N21 Release.

Nein, normal sind eher 9-12 Monate. Es sind 6-9 Monate vom Zeitpunkt, wo das Silizium vom Fertiger zurück kommt.

N31 hatte kein Tapeout und kommt Q4 22 laut Greymon55, auf dessen Infos der Großteil der aktuellen Spekus basieren:

Greymon55
AD102 and Navi31 have not been taped out yet.

Greymon55
Navi31 will not be released in Q3 2022.

Greymon55
October can be expected.

https://twitter.com/greymon55/status/1421067669889974276

Linmoum

2021-07-31, 17:59:49

Geisterte womöglich auch schon mal irgendwo durch die Gerüchteküche, aber laut Bondrewd (https://forum.beyond3d.com/posts/2217589/) kommen N33 und darunter in N6 (statt N5). Ergibt dann auch irgendwie Sinn, warum AMD auf den öffentlichen Roadmaps bei RDNA3 nur von "Advanced Node" spricht und nicht - wie bei Zen4 - konkret von N5.

Alles in N5 wäre aber auch Wahnsinn. Wenn man den MCD sowie alles unterhalb von N32 in N6 fertigen lässt, hat man mit N5 natürlich deutlich mehr Spielraum, zumal man mit möglichen <350mm² eines GCD (bei N31) auch sehr gute Yields haben dürfte. Beim MCD und N6 sowieso.

Cyberfries

2021-07-31, 19:05:27

War schonmal da.

Der interessantere Punkt ist ohnehin seine Kehrtwende bezüglich Speichercontroller - jetzt doch im MCD?

Bullsh1t_Buster (https://twitter.com/Bullsh1t_buster/status/1421074387231334400) hat währenddessen zu einer Wutrede gegen wjm4176 ausgeholt. Kurzfassung: Bisher kein N31 tapeout.

basix

2021-08-01, 03:19:50

Etwas anderes bezüglich MCD hat mMn noch nie Sinn gemacht. MCD = SI, IO, Command Processor Master, Display, Multimedia. GCD = Shader Engines + L2

tEd

2021-08-01, 13:47:40

Kein Display,Multimedia im MCD

https://forum.beyond3d.com/posts/2217578/

MCDs are N6 and they don't contain video cores or display cores or anything like that.

basix

2021-08-01, 13:54:58

OK, dafür den IMC, 2 Posts weiter ;)
https://forum.beyond3d.com/posts/2217589/

Note: Dein Link zeigt nicht auf den angegebenen Post.

tEd

2021-08-01, 14:07:03

OK, dafür den IMC, 2 Posts weiter ;)
https://forum.beyond3d.com/posts/2217589/

Note: Dein Link zeigt nicht auf den angegebenen Post.

Ja , IMC war ja auch korrekt ;)

basix

2021-08-01, 14:10:42

Die letzten Posts von Bondrewd tendieren beim Aufbau in eine noch etwas andere Richtung
https://forum.beyond3d.com/posts/2217703/
https://forum.beyond3d.com/posts/2217707/

"MCDs are the cache dies."

"Two GCD and fuckton of MCD."

"You add MCDs you scale the bandwidth up, be it interdie, LLC, offchip, you name it."

Edit:
Ich nehme an, AMD kann hierfür ebenfalls den "SRAM Optimized" Prozess wie beim V-Cache verwenden? Ansonsten werden die MCDs ziemlich gross.

Nightspider

2021-08-01, 14:24:18

Ich nehme an, AMD kann hierfür ebenfalls den "SRAM Optimized" Prozess wie beim V-Cache verwenden? Ansonsten werden die MCDs ziemlich gross.

Davon ist auszugehen.

basix

2021-08-01, 14:32:37

Was ich eigentlich bis anhin dämlich fand, ist evtl. gar nicht so tragisch: IO, Video- & Multimedia-Engine sowie PCIe nicht auf dem GCD anstatt MCD zu haben.

Der Anteil der Chipfläche an IO-PHY ist auch mit PCIe und Display nicht extrem gross. Und man kann es bei zwei GCDs einigermassen gut aufteilen: Pro GCD 1x Display Core Next 4.0, 1x HDMI, 1x DP, 1x Video Core Next 4.0, 8x PCIe Lanes. Nutzen kann man alle Funktionsblöcke und hat nicht irgendwo einen Haufen ungenutzter Chipfläche. Dann hat man verglichen zu heute +1x HDMI, aber das ist auch gut so (oder man macht es auf dem PCB via DP zu HDMI-Konverter und hat 2x DP pro GCD). Die Logik von DCN und VCN skalieren ja gut mit dem Prozess, was auch nicht schlecht ist.

Edit:
Hab schnell nachgeschaut. DP zu HDMI Konverter kosten nicht die Welt. Für AMD und den entsprechenden Stückzahlen wohl <5$
Beispiel: https://www.digikey.ch/product-detail/de/kinetic-technologies/MCDP2900A4T/2763-MCDP2900A4TCT-ND/9350828

tEd

2021-08-01, 14:48:24

..oder doch 2 verschiedene GDC für N31 und N32...alles verwirrend :freak:

basix

2021-08-01, 15:13:45

Laut aktuellen Gerüchten:
- N31 GCD = 30 WGP (120CUs nach RDNA2 Verständnis)
- N32 GCD = 20 WGP (80 CUs)

Platos

2021-08-01, 15:24:06

Kann mir mal jemand WGP erklären? Irgendwie ist mir wohl die Definition davon entgangen...

tEd

2021-08-01, 15:30:13

Laut aktuellen Gerüchten:
- N31 GCD = 30 WGP (120CUs nach RDNA2 Verständnis)
- N32 GCD = 20 WGP (80 CUs)

Das verwirrende ist Bondrewd sagt dass N32 keine 3 Chiplet hat also nur eine GCD
DegustatoR said: ↑

3 die solution

Not really. diese aber mehr als 30WGP hat

DegustatoR said: ↑

N32 won't be more than 30.

who said that?

basix

2021-08-01, 15:34:13

Kann mir mal jemand WGP erklären? Irgendwie ist mir wohl die Definition davon entgangen...

RDNA1: WGP = 2 CU -> 2*64x FP32
RDNA2: WGP = 2 CU -> 2*64x FP32
RDNA3: WGP = 4 CU -> 4*64x FP32 (laut Gerüchten)

AMD sagt dem WGP (Work Group Processor) auch Dual-Compute-Unit (siehe RDNA Whitepaper)

Edit:
Das verwirrende ist Bondrewd sagt dass N32 keine 3 Chiplet hat also nur eine GCD diese aber mehr als 30WGP hat
Auflösung: 2x GCD mit jeweils 20WGP und >1 MCD (siehe mein Schaubild ein paar Posts vorher) ;)

Linmoum

2021-08-01, 15:43:11

Er sagt in Bezug auf N32 relativ klar:
It will be interesting to see how it would compare to a single die solution of similar complexity.

Don't think a 160SM single die is really feasiable.Das ist schon recht deutlich auf die spekulierte 20WGP/80CU Config pro GCD bei N32 (2xGCD = 160CU = 160SM).

Alles andere ergibt auch keinen Sinn, weil die Lücke zwischen N31 und N32 dann einfach massiv wäre. So viele Salvages wirst du nie im Leben haben, das sind schließlich keine kleinen Zen-Chiplets.

Edit: Oder eben das was basix schreibt, es gibt mehr als 1 MCD.

basix

2021-08-01, 15:44:57

Zwischen N32 und N33 ist aber bei 80 zu 160 CU ebenfalls eine grosse Lücke. Und noch mehr, wenn N33 in 6nm kommen sollte.

Edit:
Das N32 GCD ist vermutlich im Bereich 200...250mm2 gross. Das gibt nicht viel Aussschuss und man müsste das GCD ziemlich weit runterstutzen, um nahe an die N33 SKUs zu kommen. Am Ende benötigt N32 Salvage weniger vie Saft wie der N33 Top Dog und ist +30% schneller.

Linmoum

2021-08-01, 15:47:02

Naja, da kannst du zur Not halt einen 120CU-Salvage dazwischen schieben.

Aber bei 240CU und 80CU? Das wäre dann noch mal was anderes. ;)

basix

2021-08-01, 15:48:05

240 zu 80 macht definitv keinen Sinn ;)

AffenJack

2021-08-01, 16:19:56

Die letzten Posts von Bondrewd tendieren beim Aufbau in eine noch etwas andere Richtung
https://forum.beyond3d.com/posts/2217703/
https://forum.beyond3d.com/posts/2217707/

Edit:
Ich nehme an, AMD kann hierfür ebenfalls den "SRAM Optimized" Prozess wie beim V-Cache verwenden? Ansonsten werden die MCDs ziemlich gross.

Ein MCD wird auf keinen Fall auf einem GCD sitzen, wie in deinem Bild. Mit dem Cache im MCD könntest du den MCD nur über Shader des GCD setzen. Das wird man aus thermischen Gründen auf keinen Fall machen. Entweder es ist ne Lösung ohne 3d Stacking oder der MCD ist unten.

Neurosphere

2021-08-01, 16:31:08

basix

2021-08-01, 16:36:52

Ein MCD wird auf keinen Fall auf einem GCD sitzen, wie in deinem Bild. Mit dem Cache im MCD könntest du den MCD nur über Shader des GCD setzen. Das wird man aus thermischen Gründen auf keinen Fall machen. Entweder es ist ne Lösung ohne 3d Stacking oder der MCD ist unten.

Bingo ;)

Nennt sich InFO-LSI bei TSMC und ist ähnlich wie Intels EMIB, nur mit 25um Pitch anstatt 55um: https://www.anandtech.com/show/16031/tsmcs-version-of-emib-lsi-3dfabric
Das MCD übernimmt hier die Funktion der LSI-Bridge.

Cyberfries

2021-08-01, 21:47:43

Etwas anderes bezüglich MCD hat mMn noch nie Sinn gemacht.

Wurde aber so a) in Patenten beschrieben und b) von mehreren Stellen geleakt, erst kürzlich nochmal bestätigt.

Das verwirrende ist Bondrewd sagt dass N32 keine 3 Chiplet hat also nur eine GCD diese aber mehr als 30WGP hat

Nicht Chiplet - Die. Allein das ist ein Unterschied. Und die Aussage "nicht 3" bedingt nicht, dass es nur 2 sein müssen.
Wenn sich noch jemand außer mir wundert woher das Zitat stammt: Posts #533 auf Seite 27.

Ein MCD wird auf keinen Fall auf einem GCD sitzen, wie in deinem Bild.

Thermisch problematisch ist es nur, wenn Shader überdeckt sind. Wenn sich GCD und MCD nur minimal überdecken kein Thema.
Könnte auch Sinn ergeben die Die möglichst weit voneinander entfernt zu platzieren.

Bleibt es bei einem RA pro CU, oder halt 4 pro WGP oder wird AMD einen anderen Weg gehen?

Der innere Aufbau einer RDNA3-WGP ist derzeit unbekannt, da sind viele Möglichkeiten denkbar.
Im beyond3d-Forum wurde unter anderem auch eine Reduktion der Textur-Einheiten diskutiert, aber als problematisch befunden.

-----------------------

Die bisherige Deutung von N31 = 2x GCD + 1x MCD scheint nicht mehr zu reichen.
Sind wir überhaupt noch sicher, dass das Die, das GCDs verbindet das MCD ist?

Könnte genauso gut sein, dass es ein ABD (active bridge die) oder ein iod (i/o die) gibt, auf das MCDs gestapelt werden.
Vielleicht ist das die Auflösung für die einander widersprechenden Thesen: "kein IO im GCD" und "kein SI im MCD".

------------------------
....
Ausserdem kann über die Stack Höhe die Kapazität variiert werden.
....
Da macht V-Cache nochmals deutlich mehr Sinn (N32 = reduzierte Stack-Höhe).

Zum Stapeln in mehrerern Ebenen schreibt Bondrewd: "Only 2-hi for now. (https://forum.beyond3d.com/posts/2217754/)"
Es war und ist eben nicht zu erwarten, dass AMD direkt bei der ersten gestapelten Generation auf mehrere Ebenen setzt.
Ein Schritt nach dem andern.

basix

2021-08-01, 23:02:41

Wurde aber so a) in Patenten beschrieben und b) von mehreren Stellen geleakt, erst kürzlich nochmal bestätigt.

Weiss ich ;) Nur wurde nie schlüssig aufgezeigt, wie dann eine sinnvolle Umsetzung aussieht. Wie gesagt hat man im schlimmsten Fall viele redundante / doppelt vorhandene Funktionsblöcke.

Zum Stapeln in mehrerern Ebenen schreibt Bondrewd: "Only 2-hi for now. (https://forum.beyond3d.com/posts/2217754/)"
Es war und ist eben nicht zu erwarten, dass AMD direkt bei der ersten gestapelten Generation auf mehrere Ebenen setzt.
Ein Schritt nach dem andern.

2-hi kann aber vieles bedeuten:
- MCD + GCD gestapelt
- MCDs auf dein ABD gestapelt
- Das noch bei potentiell mehrere MCDs / Stapel

Aber wieso kommst du auf die Idee mit dem ABD überhaupt? Ich sehe keinen Vorteil, eher Nachteile. Die MCDs können ja selbst die Aufgabe des ABD übernehmen.

davidzo

2021-08-02, 12:39:04

Wie wird man sich Ray Tracing bei RDNA3 vorstellen können? Bleibt es bei einem RA pro CU, oder halt 4 pro WGP oder wird AMD einen anderen Weg gehen?

Sollte es so bleiben, dürfte es wohl auch mit der CU Anzahl vermutlich nicht gegen Lovelace reichen.

Jo, das wird wirklich interessant bei RDNA3 weil wir dazu noch so gut wie nicht s wissen! Wenn es bei 2 RA pro WGP bleibt, dann würde sich ja die RT-Leistung pro Alu halbieren. Das kann also unmöglich der Fall sein. Bisher hat AMD die RAs allerdings auch pro CU gerechnet, also 1 RA pro CU, welche es ja künftig nicht mehr als zählbare Einheit gibt.
Von daher wäre das naheliegende Minimum wenn ein WGP nun 4 RA enthält, also gleiche Verhältnisse. Wahrscheinlicher ist allerdings dass AMD das auf 8 RA aufbohrt, da bei RDNA3 nun die Erfahrungen gegen Turing und Amperes RT Implementierung mit einfließen könnten.
Allgemein scheinen die RAs weder in den Dieshots noch in AMDs Schematischen Darstellungen viel Fläche zu verbrauchen. Eine Verdopplung würde also nichtmal viel Diefläche kosten. Und BVH wird dank der Aluaufstockung und größerem+schnellerem Cache ja auch deutlich performanter sein.

basix

2021-08-02, 13:02:40

Ist die Frage, ob die RA oder die CUs selbst die Leistung limitieren oder nicht. Soweit ich weiss, gibt es da keine näheren Infos dazu. Und wie viele RA ist eigentlich auch egal. Evtl. werden sie einfach doppelt und dreimal so schnell und können auch noch BVH Traversal.

aufkrawall

2021-08-02, 13:53:05

Kein BVH Traversal in Hardware wär ein harter Fail, wenn laut Linux-Treibern das auch Intel können wird.

basix

2021-08-02, 14:11:48

Ich hoffe auch, dass sie das können. Irgendeiner der RDNA3-Treiber Gurus hier, ob im Treiber dazu was ersichtlich ist?

aufkrawall

2021-08-02, 14:16:13

Gibt noch keinen Linux Treiber-Support für RDNA3. Vermutlich wär das auch eher in den Userspace-Treibern zu erkennen und amdvlk-open kann immer noch schlicht gar kein RT. Bei Intel weiß man es afair durch Mesa, was AMD für Vulkan aber weitestgehend links liegen lässt...

HOT

2021-08-02, 15:45:11

Wird sowieso spannend, wie die nächste Generation mit RT umgeht. Mit "nur" BHV-Beschleunigung wird man da hoffentlich nicht mehr kommen. Da wird man noch etwas mehr Komplexität bringen müssen und das wird mMn auch so kommen. Schon Intel wird spannend, da hier die Entwicklung ja schon mit den ersten Erfahrungen von RT in der Paxis eingeflossen sind.
RDNA2 ist ja im Prinzip von Ende 18 aus der Entwicklung in die Fertigung, Tapeout für beide Konsolen waren ja Anfang 19 irgendwann. AMD konnte ja in der RDNA2-Entwicklung nicht wissen, dass NV da schon weiter geht in Sachen RT, daher würd ich das bei AMD jetzt nicht zu hoch gängen. PC RDNA2 orientiert sich ja annährend vollständig an der XBox-Implementation. Jetzt geht es bei AMD ja auch in eine reine PC-Entwicklung bei RDNA3, von daher würd ich nicht damit rechnen, dass man hier wieder im Sparmodus bleibt. Kostengründe wie bei GCN gibts da ja auch nicht mehr. Man wird da jetzt nicht wie bei GCN die Entwicklung klein halten und die konkrete Chipentwicklung einbremsen, sondern man wird bei RDNA3 schon bringen was auch möglich ist.

davidzo

2021-08-02, 15:52:55

Kein BVH Traversal in Hardware wär ein harter Fail, wenn laut Linux-Treibern das auch Intel können wird.

Wieso ist das gleich ein fail?
Es ist doch von Vorteil wenn man statt dedizierter Einheiten universelle nimmt, die sowohl in einem rasterizing, compute als auch mit noch stärkerer RT Nutzung skalieren. Feste Verhältnisse bleiben entweder unausgelastet oder limitieren sogar die maximale RT Leistung.

Gerade wenn die Aluleistung um mehr als Faktor 3 steigt und der IFCache sich vervierfacht sollte das doch kein problem sein dass BVH etwas Aluleistung abzwackt. Im Gegensatz zu RDNA2 wird RDNA3 doch Compute Power im Überfluss haben, während die SEs pro Dies sogar weniger werden, also primitve setup, scheduler, etc. - Mich würde es nicht wundern dass Alu Auslastung bei RDNA3 sogar zurück geht, ähnlich wie bei Turing vs Ampere und erst bei voller RT Auslastung oder in Compute Szenarien die volle Alu Rohleistung durchschlägt.

Und wer sagt dass BVH Traversal im moment überhaupt der limitierende Faktor bei AMDs RT Leistung ist? Vielleicht sind es auch die Ray Accelerators pro CU die momentan limitieren?
Außerdem ist BVH tranversal ja in Hardware. Ist ja nicht so als wenn das irgendwie vom Treiber bzw. über die CPU kommt, das läuft ja schon über die ALUs und den IFcache. Und Ray acceleraturs gibt es ja sowieso pro CU, nur eventuell eben nicht in der richtigen Anzahl.

Ich denke es wäre falsch von AMD dieses besser auslastbare Modell von RT Beschleunigung vorschnell aufzugeben und zu festen, nicht skalierbaren Funktionsblöcken wie nvidia über zu gehen. Bloß weil das in der ersten Gen noch nicht die richtigen Proportionen waren heißt ja nicht dass der Ansatz an sich ineffzient oder nicht skalierbar wäre.

einfach die µarch von nvidia nach zu konstruieren, bloß weil die Referenzplattform für RT Entwicklung und Optimierung bisher Geforce RTX war, das würde bedeuten dass man plant immer 1-2 Generationen hinter nvidia zu liegen. Ich denke man muss da schon seinen eigenen Weg gehen und genau wie Intel mangelt es AMD ja auch nicht an Expertise in dem Bereich. Alle drei (+ powerVR) Firmen haben schon frühere Erfahrungen mit RT, auf FPGAs, Larabee, ex Caustic enwickler, etc. - die beobachten das schon seit 20 jahren...

aufkrawall

2021-08-02, 16:09:16

Wieso ist das gleich ein fail?
Es ist doch von Vorteil wenn man statt dedizierter Einheiten universelle nimmt, die sowohl in einem rasterizing, compute als auch mit noch stärkerer RT Nutzung skalieren. Feste Verhältnisse bleiben entweder unausgelastet oder limitieren sogar die maximale RT Leistung.

RT belastet die Shader schon durchs Denoising massiv.

Gerade wenn die Aluleistung um mehr als Faktor 3 steigt und der IFCache sich vervierfacht sollte das doch kein problem sein dass BVH etwas Aluleistung abzwackt. Im Gegensatz zu RDNA2 wird RDNA3 doch Compute Power im Überfluss haben, während die SEs pro Dies sogar weniger werden, also primitve setup, scheduler, etc. - Mich würde es nicht wundern dass Alu Auslastung bei RDNA3 sogar zurück geht, ähnlich wie bei Turing vs Ampere und erst bei voller RT Auslastung oder in Compute Szenarien die volle Alu Rohleistung durchschlägt.

Da ist dein Blick etwas sehr aufs Highend verengt.

Ich denke es wäre falsch von AMD dieses besser auslastbare Modell von RT Beschleunigung vorschnell aufzugeben

Das mit dem "besser auslastbar" ist nur eine Hypothese von dir, keine Tatsache.

HOT

2021-08-02, 16:37:54

Ist doch logisch, dass man das besser auslasten kann, wenn es generalisiert abläuft. Man wird die gesamten ALUs umgestalten und optimieren müssen, um das beste Ergebnis aus beiden Welten zu vereinigen. Es gab mal so ne theoretische Einordnung auf Leos Hauptseite der RT-Generationen. Leider finde ich das nicht wieder ;). Vllt. hat das ja jemand parat.
NVs Lösung wird sicher so auch nicht bleiben. Lovelace sehe ich als Endpunkt der "Maxwell"-Reihe (Goldwaage bitte zuhause lassen). Danach gehts auf Chiplets und da ist ein kompletter Reroll nötig. Da wird NV auch schon fieberhaft dran arbeiten.

basix

2021-08-02, 16:49:25

RT wird aufgrund der massiven Anzahl an TFLOPs und dem grösseren IF$ weniger stark reinhauen wie bei RDNA2, auch wenn sie ansonsten gar nichts an der Architektur ändern würden. Liegt in der Natur der Sache von breiteren Chips. Und das wird von N34 bis N31 so sein.

Wie es AMD schlussendlich umsetzt ist mir egal. AMD hat hier selbst mehrere Ziele: Leistungsstark, energie- und flächeneffizient, flexibel einsetzbar. Welcher Mix es am Schluss wird, sehen wir dann. Zu wünschen wäre zumindest, dass der FPS Drop bei Heavy-RT (z.B. CP2077, Control, Minecraft RTX) in die Nähe von Ampere kommt. Dann kann man nicht mehr von RT-Schwäche reden.

HOT

2021-08-02, 16:52:57

Wie gesagt fänd ich das aber eher enttäuschend. Ich würde schon sagen, dass da mehr Hardware nötig ist, um den Framedrop weiter zu verringern. Aber schon Ampere zeigt, dass das offenbar gar nicht so einfach ist, wahrscheinlich aus den von dir vorgetragenen Gründen.

aufkrawall

2021-08-02, 16:53:15

Zu wünschen wäre zumindest, dass der FPS Drop bei Heavy-RT (z.B. CP2077, Control, Minecraft RTX) in die Nähe von Ampere kommt.
Ich fürchte nur, auch ganz unabhängig von den fps wird das Erlebnis in solchen "RTX-Titeln" durch den Treiber weiterhin bescheiden bleiben. Dass sich Nvidia beim Einfluss auf Studios die Butter vom Brot nehmen lassen wird, darf bezweifelt werden. Wobei das Problem bei AMD imho eher Unlust und Versagen ist, gezielte Nadelstiche durch NV direkt eher weniger.

HOT

2021-08-02, 16:55:32

Ich fürchte nur, auch ganz unabhängig von den fps wird das Erlebnis in solchen "RTX-Titeln" durch den Treiber weiterhin bescheiden bleiben. Dass sich Nvidia beim Einfluss auf Studios die Butter vom Brot nehmen lassen wird, darf bezweifelt werden. Wobei das Problem bei AMD imho eher Unlust und Versagen ist, gezielte Nadelstiche durch NV direkt eher weniger.

Für die Behauptung hätt ich gern mal einen Nachweis. Wo ist da der Treiber das Problem. AMD hat halt weit weniger Rohleistung, dass es da bei Heavy-RT-Titeln wie Cyberpunk oder Control hapert halte ich für logisch, oder noch schlimmer, die Pathtracing-Geschichten wie Minecraft.

basix

2021-08-02, 16:59:09

aufkrawall

2021-08-02, 17:05:47

Für die Behauptung hätt ich gern mal einen Nachweis.
Nachweis: aufkrawalls Erfahrung aus erster Hand.
Control: Denoiser in Astralebene kaputt
WD Legion: Monatelang Grafikfehler, nach Spielupdate "nur" noch sporadische Treiber-Crashes mit temporalem Upsampling, durch Adrenalin 21.6 Performance-Regression vom ohnehin mieserablen Niveau
WoW: "AMD" RT-Schatten kosten >50% Performance auf der 6800, mit der 3060 eher 1/3
Doom Eternal: Unrunde Frametimes bei Kameradrehungen, mit NV komplett glatt
Battlefield V: Verzerrte Reflexionen von Objekten wie Booten, mit 21.6 waren die Reflexionseigenschaften von Materialen offenbar zusätzlich völlig regressed
Cyberpunk: RT erst Monate später für AMD, nutzlose Performance (jetzt mal ganz unabhängig von der Sinnhaftigkeit der RT-Implementierung in diesem Spiel...)

Hätte ich noch mehr Spiele im Vergleich, wäre die Liste sicherlich noch länger. Wer AMD kauft, muss damit rechnen, dass die Chance auf kaputtes RT in Spiel X wesentlich höher ist. Glaub es oder lass es, nicht mein Schaden. :cool:

AffenJack

2021-08-02, 17:09:18

Nvidia schmeisst einfach deutlich mehr HW auf RT. Wenn das langsamer wäre als AMDs Ansatz, wäre das ziemlich traurig. Nichtsdestotrotz kann man mit vielen CUs, geschickten Datenpfaden und IF$ schon etwas schnelles und effizientes kreieren. Ob schneller oder effizienter als Nvidias Ansatz? Keine Ahnung.

Effizient? Wohl kaum. Es war eigentlich immer deutlich effizienter spezifische Recheneinheiten zu haben. Wenn AMD weiterhin stärker auf Shader setzt, wird man bei höherer RT Auslastung auch weiterhin deutlich mehr Leistung verlieren. Es wäre dann eher AMD, die deutlich mehr Hardware auf RT schmeißen als Nvidia.

Ich gehe aber nicht davon aus, dass dies der Fall ist. Bei RDNA2 hatte man noch zu wenig Zeit, um eine komplexere RT Beschleunigung einzubauen. Bei RDNA3 erwarte ich da deutlich mehr.
Außer AMD entscheidet sich bewusst eine Blokadetaktik, wie Nvidia mit DX10.1 zu fahren. Dann würde es Sinn machen RT nicht groß weiter auszubauen bis zu einer späteren Gen. Mit den Konsolen hätte AMD durchaus die Marktmacht dafür. Ich hoffe aber, dass sie es nicht machen.

HOT

2021-08-02, 17:47:01

Nachweis: aufkrawalls Erfahrung aus erster Hand.
Control: Denoiser in Astralebene kaputt
WD Legion: Monatelang Grafikfehler, nach Spielupdate "nur" noch sporadische Treiber-Crashes mit temporalem Upsampling, durch Adrenalin 21.6 Performance-Regression vom ohnehin mieserablen Niveau
WoW: "AMD" RT-Schatten kosten >50% Performance auf der 6800, mit der 3060 eher 1/3
Doom Eternal: Unrunde Frametimes bei Kameradrehungen, mit NV komplett glatt
Battlefield V: Verzerrte Reflexionen von Objekten wie Booten, mit 21.6 waren die Reflexionseigenschaften von Materialen offenbar zusätzlich völlig regressed
Cyberpunk: RT erst Monate später für AMD, nutzlose Performance (jetzt mal ganz unabhängig von der Sinnhaftigkeit der RT-Implementierung in diesem Spiel...)

Hätte ich noch mehr Spiele im Vergleich, wäre die Liste sicherlich noch länger. Wer AMD kauft, muss damit rechnen, dass die Chance auf kaputtes RT in Spiel X wesentlich höher ist. Glaub es oder lass es, nicht mein Schaden. :cool:

Und das soll alles Schuld des Treibers sein? ;D
Eher nein. Einiges davon sind glaub ich eher "unglückliche Umstände". MMn sind die meisten RT-Implementationen in Spielen bislang einfach Schrott, vor allem die in Cyberpunk.

Effizient? Wohl kaum. Es war eigentlich immer deutlich effizienter spezifische Recheneinheiten zu haben. Wenn AMD weiterhin stärker auf Shader setzt, wird man bei höherer RT Auslastung auch weiterhin deutlich mehr Leistung verlieren. Es wäre dann eher AMD, die deutlich mehr Hardware auf RT schmeißen als Nvidia.

Ich gehe aber nicht davon aus, dass dies der Fall ist. Bei RDNA2 hatte man noch zu wenig Zeit, um eine komplexere RT Beschleunigung einzubauen. Bei RDNA3 erwarte ich da deutlich mehr.
Außer AMD entscheidet sich bewusst eine Blokadetaktik, wie Nvidia mit DX10.1 zu fahren. Dann würde es Sinn machen RT nicht groß weiter auszubauen bis zu einer späteren Gen. Mit den Konsolen hätte AMD durchaus die Marktmacht dafür. Ich hoffe aber, dass sie es nicht machen.

Das ist schlichtweg falsch. AMD hatte alle Zeit der Welt und hat es ignoriert, bzw. man hat es bei der Implemetation der XBox gelassen. Die Grafikchips sind mehr als ein halbes Jahr später ins Tapeout gegangen nach dem XBox-SoC ohne jegliche größere Änderung. AMD hätte weit mehr Arbeit in die PC-Variante stecken können, hat man aber absichtlich nicht getan sondern die Konsolen-Implementation quasi 1:1 in den PC gebracht. RDNA3 wird weit mehr Rohleistung ggü. Lovelace mitbringen als RDNA2 vs. Ampere, die Situation ist also nicht vergleichbar.

aufkrawall

2021-08-02, 17:56:22

Und das soll alles Schuld des Treibers sein? ;D

Wenn man es durch neue Treiber eigentlich nur noch weiter verschlimmert anstatt verbessert, ist das zumindest nicht gerade rühmlich.
Ist jetzt müßig, darüber zu spekulieren, wie es mit besserer Hardware von AMD wird. Als Optimist könnte man meinen, durch leistungsfähigere Hardware wird es besser. Meine Befürchtung geht aber eher in die Richtung, dass noch weiter zunehmende Komplexität für eine Verbesserung eher hinderlich sein wird.
Anyhow, wird man dann sehen. Bis dahin empfehle ich GeForces (mit genug VRAM), wenn man RT möglichst oft nutzen will.

HOT

2021-08-02, 18:06:15

[...]
Anyhow, wird man dann sehen. Bis dahin empfehle ich GeForces (mit genug VRAM), wenn man RT möglichst oft nutzen will.
Dem kann ich nur voll zustimmen ;).

unl34shed

2021-08-02, 18:47:05

Aber selbst die 3000 Gen ist doch noch nicht wirklich schnell genug für RT ohne DLSS

robbitop

2021-08-02, 19:11:46

FF HW ist immer energieeffzienter und kleiner. Dafür kann sie eben nur eines. Ob sich das lohnt hängt immer von den Anwendungen und der Nutzungsgrad für den die FF HW da ist ab. Oft ist FF HW der effziientere Weg (sowohl Fläche als auch Energie). Der Nutzungsgrad wird wahrscheinlich eher steigen.

Am Ende müssen die Simulationen von AMD das aufzeigen. Und das muss auch keine statische Entscheidung sein. Wenn der Nutzungsgrad und die Auslastung steigt kann sich von einer uArch zur nächsten die Entscheidung auch mal drehen.

Niemand in dieser Runde hat die Qualifikation noch die Daten, um es spezfisch für diesen Fall sicher beurteilen zu könnrn. Also ob sich mehr RT HW für RDNA3 lohnt oder GP HW die sinnvollere Wahl ist.

basix

2021-08-02, 20:01:45

Ich glaube es gibt, egal wie die Umsetzung dann aussieht, ein deutliches Indiz, dass RDNA3 deutlich stärker bei RT performen wird: AMD will mit N31 die absolute Leistungskrone erobern. Sind sie mit Raster ein bisschen vorne aber mit RT (deutlich) hinten, reicht das mMn nicht.

Beispiel:
Laut CB liegt bei 4K und einer 6900XT 3.4x FPS zwischen RT off und RT on (Control + CP2077). Bei einer 3090 sind es 2.1x. Dadurch gewinnt Nvidia sage und schreibe +60% an relativer Performance verglichen mit RDNA2. Macht AMD hier keine Fortschritte, kann N31 noch so gerne 2.7x so schnell wie N21 bei Raster sein. Nvidia würden +70% Performance auf eine 3090 für die RT-Leistungskrone genügen (angenommen selbe RT-Skalierung wie GA102).

Das noch mit DLSS 2.x oder 3.x garniert, ohne entsprechenden AMD Gegenpart (FSR 1.0 reicht dazu noch nicht): Nvidia läge wieder vorne.

Edit:
Und es gibt auch ausserhalb von RT Cores Möglichkeiten um die RT Performance und Effizienz zu erhöhen. Hier von Intel, wie sie den BVH in 1/3 der Speichergrösse pressen: https://www.embree.org/papers/2019-HPG-ShortStack.pdf
Im Paper erwähnen sie auch, dass Geometrie-Kompression von Vorteil wäre (bei RDNA laut B3D nicht komprimiert: https://forum.beyond3d.com/posts/2186916/) und das bald die Latenz und Bandbreite, um die BVH Leafs zu laden, zum Problem wird. Was wäre für letzteres nicht besser geeignet wie der Shared-L1$ aus einem der AMD-Patente und ein noch grösserer und schnellerer IF$ ;)

Edit 2:
Gibt noch keinen Linux Treiber-Support für RDNA3. Vermutlich wär das auch eher in den Userspace-Treibern zu erkennen und amdvlk-open kann immer noch schlicht gar kein RT. Bei Intel weiß man es afair durch Mesa, was AMD für Vulkan aber weitestgehend links liegen lässt...
https://forum.beyond3d.com/posts/2210904/

Neurosphere

2021-08-02, 21:47:23

aufkrawall

2021-08-02, 22:09:59

Edit 2:

https://forum.beyond3d.com/posts/2210904/
Ja, das ist für RADV und RDNA2. Dessen 3rd Party Entwickler haben aber vorab keinen Zugang zu künftiger AMD-Hardware. Vielleicht ein paar Wochen oder, mit ganz viel Wohlwollen von AMD, ein paar Monate vor Release (aber wohl eher nicht).

HOT

2021-08-02, 22:13:33

Da sehe ich auch das Problem wenn es beim jetzigen Konzept mit 1 RA pro CU bleibt und sonst keine Änderungen vorgenommen werden gegenüber Lovelace.

Könnte man eigentlich FF RT auch in einen extra Chip auslagern wenn man im MCM Bereich ist, oder wird das zu viel Ping Pong?
Das kommt einfach darauf an, wie leistungsfähig der RA ist ;).

gedi

2021-08-02, 22:14:14

Ich fürchte nur, auch ganz unabhängig von den fps wird das Erlebnis in solchen "RTX-Titeln" durch den Treiber weiterhin bescheiden bleiben. Dass sich Nvidia beim Einfluss auf Studios die Butter vom Brot nehmen lassen wird, darf bezweifelt werden. Wobei das Problem bei AMD imho eher Unlust und Versagen ist, gezielte Nadelstiche durch NV direkt eher weniger.

Der grüne Fanboy mal wieder. Dein Gelaber ist unerträglich, zumal du 60 FPS mit deiner Karte noch nicht mal auf dem Desktop schaffst! RT kennst du du nur vom Hörensagen oder krassem Upsampling, von daher solltest du echt raus sein.

So oft wie du Standbilder oder komprimierte Videos vergleichst, da kommt mir echt das Kotzen - sorry. Deine Meinung ist wie immer nur subjektiv und hat mit der Realität, wie eigentlich immer, nichts zu tun.

Daredevil

2021-08-02, 22:18:55

Man macht es sich immer leicht, jemanden als Fanboy zu betiteln, aber aufkrawall ist sicherlich keiner derjenigen. Im Gegensatz zu vielen hier, inkl. mir, hat er schon beides im System gehabt und ja, er ist pingelig, deswegen sieht er halt auch die Unterschiede.
Das geht sowohl in die eine, als auch in die andere Richtung.

davidzo

2021-08-02, 22:44:16

Dass sich Nvidia beim Einfluss auf Studios die Butter vom Brot nehmen lassen wird, darf bezweifelt werden.

Entwickler entwickeln nicht nur für eine GPU Architektur. Wieso DXR bisher nur für RTX optimiert wurde liegt daran dass zum Entwicklungszeitpunkt der meisten games schlicht keine andere Architektur verfügbar war.
Da nun aber die Konsolen mitmischen kannst du dir sicher sein dass die Studios sich nicht mehr nur mit RTX beschäftigen, sondern nur noch an universellen DXR Implementierungen arbeiten.

Battlefield V: Verzerrte Reflexionen von Objekten wie Booten, mit 21.6 waren die Reflexionseigenschaften von Materialen offenbar zusätzlich völlig regressed
Cyberpunk: RT erst Monate später für AMD, nutzlose Performance (jetzt mal ganz unabhängig von der Sinnhaftigkeit der RT-Implementierung in diesem Spiel...)

Lol, zum Launch von RTX gab es kein einziges Spiel welches das unterstützte und selbst Bf V als einziges Spiel im gleichen jahr hat dann noch monatelang Grafikfehler produziert und die Performance war erst mit dem Update 4 Monate nach dem Launch der RTX Karten akzeptabel.

Das ist jetzt nicht nur ein AMD Problem, das war schon immer so mit neuen Technologien. Erst muss die Hardware da sein, dann die Treiber und schlussendlich müssen die Entwickler das auch noch implementieren, was bei bereits vor Jahren gelaunchten Titeln keine Selbstverständlichkeit ist.

Effizient? Wohl kaum. Es war eigentlich immer deutlich effizienter spezifische Recheneinheiten zu haben.

Kommt darauf an welches System man betrachtet und was man mit Effizienz meint. Ich meine damit die PPA. Es ist extrem Flächeneffizient wenn man gar keine Extra Einheiten braucht, bzw. diese auch für etwas anderes verwenden kann wenn sie gerade nicht ausgelastet sind.
Und was die Energiekosten der Alus angeht, da überwiegen doch bald die Kosten der Speicher-zugriffe. BVH Traversal wäre ohne reordering of memory access durch die TMUs und die direkte Cache Anbindung extrem ineffizient weil es sehr viele random memory accesses während der ray traversal erzeugt.
Deswegen sitzen die RT Cores bei Nvidia ja auch an den TMUs und dem L1D cache. Ein teil des RT Leistungszuwachs von Ampere vs Turing geht sicher auch auf den vergrößerten L1d Cache zurück.

Mich nervt hier ein bisschen die Mär von Nvidias "reiner hardware Lösung". Das ist mitnichten der Fall, nvidia s RTX ist eine Mischlösung aus Treiber, Compiler, Firmware und hardwareinheiten und auch nvidia greift auf die TMUs zurück um random ray memory acesses zu sortieren und gruppieren. Auch nvidia nutzt den L1D cache für BVH Daten um den speicherzugriffen und ggf. großen buffern die man sonst hätte zu entgehen. Nur sind die RT Shader programme anscheinend bei turing und Ampere nicht auf den normalen Alus laufen können, wieso auch immer.

Und es gibt auch ausserhalb von RT Cores Möglichkeiten um die RT Performance und Effizienz zu erhöhen. Hier von Intel, wie sie den BVH in 1/3 der Speichergrösse pressen: https://www.embree.org/papers/2019-HPG-ShortStack.pdf

Im Paper erwähnen sie auch, dass Geometrie-Kompression von Vorteil wäre (bei RDNA laut B3D nicht komprimiert: https://forum.beyond3d.com/posts/2186916/) und das bald die Latenz und Bandbreite, um die BVH Leafs zu laden, zum Problem wird. Was wäre für letzteres nicht besser geeignet wie der Shared-L1$ aus einem der AMD-Patente und ein noch grösserer und schnellerer IF$ ;)

Danke, interessanter Hinweis das auch Intel das so sieht dass Speicher bzw. Speicherzugriff bei BVH ein wesentliches Nadelöhr ist.
Ja, ich sehe das auch so, BVH sollte weniger das Problem sein wenn man massig Alus hat und eine Cache-Anbindung die im Vergleich zu Ampere noch ihres gleichen sucht (shared L1s, riesiger L2 + IF$).

Da sehe ich auch das Problem wenn es beim jetzigen Konzept mit 1 RA pro CU bleibt und sonst keine Änderungen vorgenommen werden gegenüber Lovelace.

Aber es gibt keine CUs mehr, also verändern sich die RAs pro WGP sowieso damit es nicht zu einem krassen Missverhältnis zwischen RAs und Alu-Leistung kommt. Wahrscheinlich erhöht man das Verhältnis aus RAs zu ALUs in einem WGP (= 8 RAs pro WGP) oder man vergrößert deren einzelnen Durchsatz.

Könnte man eigentlich FF RT auch in einen extra Chip auslagern wenn man im MCM Bereich ist, oder wird das zu viel Ping Pong?
Unsinn, man braucht die L1 caches und TMUs für memory access reordering. Das wäre ein Rückschritt zu den fixed function Beschleunigern, eigenem speicher etc. wie damals die caustic karten. Wäre in vielen punkten redundant.

basix

2021-08-02, 23:09:55

Hier noch die interessante Conclusion des Intel Papers:
5. Conclusion and Future Work
We have proposed a generalization of binary BVH traversal with a short stack to BVHs with an arbitrary width. Our algorithm does not require additional data in the BVH nodes or separate structures in memory to backtrack traversal. Compared to a full stack, our algorithm requires 3× less stack memory and only increases the number of traversal steps by a small percentage. We also introduce an extension of our traversal algorithm for stack culling that can reduce the number of expensive ray primitive intersection tests with a small overhead in the number of traversal steps.

Our approach lends itself naturally to a dedicated hardware implementation where the available on-chip memory is heavily constrained. However, with an implementation that uses compressed BVH nodes as well as our short stack traversal algorithm, the latency and bandwidth for fetching leaf geometry is likely to become the next dominant bottleneck.

Although we do apply some degree of geometry compression by converting triangle pairs to quads, a more effective geometry compression scheme could be an important goal for the future.
- Etwas weniger Intersection-Arbeit
- Dafür etwas mehr BVH Traversal und nur 1/3 der Caching-Grösse
- Weitere BVH-Kompression wäre ein grosser Vorteil
- Latenz und Bandbreite wird zunehmend das Nadelöhr

konkretor

2021-08-04, 08:00:37

https://videocardz.com/newz/amd-navi-31-navi-32-and-navi-33-gpu-block-diagrams-by-olrak-visualize-rdna3-rumors

dargo

2021-08-04, 09:25:12

N33 soll mit 5120 SPs nur ein 128Bit SI abbekommen? Kommt mir recht unglaubwürdig vor wenn man das mit N21 vergleicht.

M4xw0lf

2021-08-04, 11:10:55

N33 soll mit 5120 SPs nur ein 128Bit SI abbekommen? Kommt mir recht unglaubwürdig vor wenn man das mit N21 vergleicht.
Der Infinity Cache wird dafür verdoppelt. Schon nicht so übel für den kleinsten Chip.

davidzo

2021-08-04, 11:19:29

https://videocardz.com/newz/amd-navi-31-navi-32-and-navi-33-gpu-block-diagrams-by-olrak-visualize-rdna3-rumors

Irgndwie macht es keinen Sinn für Navi32 einen eigenen MCD aufzlegen mit 384 statt 512mb cache, eigene GCDs mit nur 2 statt 3SEs. Das ist zu nah an einer Salvagelösung von Navi31, die im Zweifelsfalle sogar günstiger wäre als zwei zusätzliche N5 und N6 Chips, Maskensets, Fertigungslinien etc.

Navi32 macht imo nur Sinn wenn wenigstens ein DIE wiederverwendet wird, also z.B. die GCDs mit 2SE Salvage sind und nur auf einen neuen kleineren MCD kommen (dann aber eher nur 256mb um den Abstand zu wahren) Alternativ die vorgeschlagene Singlechip GCD Lösung auf einem kleinen MCD.

N33 soll mit 5120 SPs nur ein 128Bit SI abbekommen? Kommt mir recht unglaubwürdig vor wenn man das mit N21 vergleicht.

In WQHD und 1080p ertrinkt navi21 geradezu in Bandbreite. Hitrate ist 74% und 80% und selbst in 4K bringt chiptakt immer noch mehr als Speichertakt auf navi21. Man ist also immer noch nicht besonders bandbreitenlimitiert. Mit einem größeren IF$ sollte es kein problem sein das SI weiter zu verkleinern, zumal das die neue sweetspotkarte für WQHD wird, die 4K Karte ist Navi32.

HOT

2021-08-04, 12:16:34

N32 wird einfach ne Salvage-Variante des MCDs bekommen.

Nightspider

2021-08-04, 12:33:01

Für Navi33 wurde Navi 21+60% gemunkelt oder?

Kriegt man schon 16GB an ein 128Bit SI?

Spart man durch 128Bit SI so viel ein das sich ein doppelter IF$ lohnt in 5nm ?

Weiß jemand wie viel mm^2 ein 128B SI in 7nm benötigt hat?

Irre ich mich oder müsste Navi33 nicht auch noch recht gewaltige 400-430mm2 erreichen?
Selbst mit halbem SI müsste wegen dem doppelten Cache selbst bei kleinerer Strukturbreite bei diesen beiden Teilen insgesamt mehr Fläche benötigt werden als bei N21.

basix

2021-08-04, 12:54:19

Die Grösse des IF$ erlaubt eine breite Anzahl an Möglichkeiten des Speicherinterfaces.

Meine Speku:
|N31|N32|N33 v1|(N33 v2)|N34 v1|(N34 v2)
SPs|15'360|10'240|5120|5120|2560|2560
# MCDs|4|3|n.a.|n.a.|n.a.|n.a.
Speicherinterface [bit]|256|192|128|192|96|128
Speichertransferrate [GT/s]|16|16|16|16|16|16
Speicherbandbreite [GByte/s]|512|384|256|384|192|256
Infinity Cache [MByte]|512|384|160|96|96|64
Target Resolution|4K+|4K|1440p|1440p|1080p|1080p
IF$ Missrate @ Target Resolution [%] (est.)|23|26|25|35|25|30
Effective Bandwidth @ Target Resolution [GByte/s] (est.)|2226|1478|1024|1097|768|853
VRAM [GByte]|32|24|16|12|12|8

Edit:
Kriegt man schon 16GB an ein 128Bit SI?

Spart man durch 128Bit SI so viel ein das sich ein doppelter IF$ lohnt in 5nm ?

Weiß jemand wie viel mm^2 ein 128B SI in 7nm benötigt hat?
16 GByte @ 128bit = Ja, allerdings 2x 16GBit Module pro 32bit Channel. 32Gbit Module könnte es in Zukunft allerdings geben.
N33 & N34 sollen noch N6/N7 sein
64bit @ N7 ~16mm2 (von irgendeiner ungenauen Messung von jemandem)

dargo

2021-08-04, 13:00:29

Der Infinity Cache wird dafür verdoppelt.
Ops... glatt übersehen. Das wäre schon wirklich extrem mit nem 128Bit SI und "fetten" 5120SPs. :tongue: Dürfte wieder einiges beim Stromverbrauch bringen.

btw.
Was bekommt dann ein N34? 64-96Bit SI? :freak:

HOT

2021-08-04, 13:46:54

Auch 128Bit aber kein oder nur sehr wenig IF$ ;). Mal sehen, was N6 so an Cache-Packdichte besser macht als N7.

mboeller

2021-08-04, 13:47:43

Irgndwie macht es keinen Sinn für Navi32 einen eigenen MCD aufzlegen mit 384 statt 512mb cache, eigene GCDs mit nur 2 statt 3SEs. Das ist zu nah an einer Salvagelösung von Navi31, die im Zweifelsfalle sogar günstiger wäre als zwei zusätzliche N5 und N6 Chips, Maskensets, Fertigungslinien etc.

sind das nicht 6/4/2 GCD mit 3/2/1 MCD + V-Cache für den iF$?

Navi34 wäre dann die kleine Lösung mit 1 GCD+1 MCD (ohne oder nur sehr kleiner iF$)

Linmoum

2021-08-04, 14:27:16

GCD+MCD sollen nach bisheriger Gerüchtelage nur N31/N32 bekommen, alles darunter bleibt monolithisch, dafür aber womöglich N6.

AffenJack

2021-08-04, 15:13:06

Was bekommt dann ein N34? 64-96Bit SI? :freak:

Guck dir N24 an. Der wird auch mit 64Bit spekuliert.

Irgndwie macht es keinen Sinn für Navi32 einen eigenen MCD aufzlegen mit 384 statt 512mb cache, eigene GCDs mit nur 2 statt 3SEs. Das ist zu nah an einer Salvagelösung von Navi31, die im Zweifelsfalle sogar günstiger wäre als zwei zusätzliche N5 und N6 Chips, Maskensets, Fertigungslinien etc.

Die MCD sollen nicht monolytisch sein, wenn man Bondrewed glauben schenkt. Dann ist das egal. N31 4 MCD mit je 64Bit, N32 3 MCD mit je 64Bit. Daher werden die MCD wiederverwendet.

HOT

2021-08-04, 16:43:11

Gibt keine Lösung mit nur einem Chiplet. Alle Chiplet-Lösung haben 2 GCDs, anders ergibt das einfach keinen Sinn. Alles darunter scheint monolithisch und 6nm, das ist auch das sinnvollste, was AMD machen konnte. Die Packdichte ausnutzen und dafür den günstigeren Prozess nehmen ist für die kleineren Grafikchips einfach ne richtig gute Idee, denn damit macht man N5 frei für die großen Produkte und CPUs. Die Masse bekommt dann N6 und die Kapazitätsprobleme entschärfen sich.

davidzo

2021-08-04, 16:50:29

Guck dir N24 an. Der wird auch mit 64Bit spekuliert.

Die MCD sollen nicht monolytisch sein, wenn man Bondrewed glauben schenkt. Dann ist das egal. N31 4 MCD mit je 64Bit, N32 3 MCD mit je 64Bit. Daher werden die MCD wiederverwendet.

Hm, aber was ist dann mit der active bridge? Die MCDs müssen doch irgendwie unter mehreren GCDs liegen damit sie die Chips verbinden können.
Sind das so streifen von silizium als GCD Unterlage, EMIB Style, von denen dann bei Navi31 eben einfach mehr drunter passen weil der DIE Länger/breiter ist?

Auch wäre dann chiplets überhaupt kaum im Vorteil beim Yield im vergleich zu einer salvagelösung. Wenn man GCDs in die kleinste EInheit als 128mb/64bit unterteilt kann man die bei einem Fehler nicht salvagen. Der Yield geht dadurch deutlich runter und das trotz des super aufwändigen Packaging. Man könnte auch einfach einen großen 512mb/256bit MCD nehmen und als salvage nur 384mb/192bit nutzen.

Finde dann aber immer noch dass ein 3xSE GCD und ein 2xSE GCD zu nah aneinander liegen als dass es dafür einen eigenen chip geben muss.

Cyberfries

2021-08-04, 17:24:27

Dürfte wieder einiges beim Stromverbrauch bringen.

Irgendwie müssen sie ja den dicken Chip mobile-tauglich bekommen.

sind das nicht 6/4/2 GCD mit 3/2/1 MCD + V-Cache für den iF$?

Die Radeon-Lösung sollte man nicht mit Ryzen vergleichen. Das Ziel ist ein anderes ist (und damit auch die Methoden).
Es geht NICHT um Kostenersparnis und Gleichteil-Strategie, sondern darum die Grenzen der Fertigung zu umgehen.
N31 und N32 mit gleichem MCD, anderen GCD und jeweils 2GCD + x MCD.

Hm, aber was ist dann mit der active bridge? Die MCDs müssen doch irgendwie unter mehreren GCDs liegen damit sie die Chips verbinden können.

Die beiden Chips müssen sich nur teilweise überlappen.

Finde dann aber immer noch dass ein 3xSE GCD und ein 2xSE GCD zu nah aneinander liegen als dass es dafür einen eigenen chip geben muss.

Da müsste immerhin ca.30% deaktiviert werden. Bei der 6800 ists gerade mal halb so viel.

Man könnte auch einfach einen großen 512mb/256bit MCD nehmen und als salvage nur 384mb/192bit nutzen.

Denk an die Möglichkeit Cache zu stapeln.

32Gbit Module könnte es in Zukunft allerdings geben.

Was außerhalb der Spezifikation läge...
Wenn wir aber schon über Speziallösungen nachdenken ... 32 Gbit oder 24 Gbit?

davidzo

2021-08-04, 17:40:54

Was außerhalb der Spezifikation läge...
Wenn wir aber schon über Speziallösungen nachdenken ... 32 Gbit oder 24 Gbit?

Der GDDR6 Standard sieht 32Gbit schon vor, wurde aber afaik noch von keinem DRAM-Hersteller angekündigt.
Speziallösungen sind aber eher nvidias Stil, AMD versucht das tunlichst zu vermeiden seit dem 4gb hbm Fiji debakel.

Ich glaube nicht dass man 16 Chips auf dem PCB bzw. rückseiten anordnen wird. Das macht die Einsparungen durch die geringe busbreite beinahe zunichte. Double sided soldering ist aufwändig und teuer und die zwei verschiedenen soldersorten die man benötigt bedeuten dass es Abstriche bei yield und/oder Haltbarkeit der solderjoints gibt. für ein paar caps ist das easy, aber doublesided GDDR wie bei der 3090 ist eine teure angelegenheit in der Fertigung die man bei volumenmodellen unbedingt vermeiden will.

AffenJack

2021-08-04, 17:56:02

Hm, aber was ist dann mit der active bridge? Die MCDs müssen doch irgendwie unter mehreren GCDs liegen damit sie die Chips verbinden können.
Sind das so streifen von silizium als GCD Unterlage, EMIB Style, von denen dann bei Navi31 eben einfach mehr drunter passen weil der DIE Länger/breiter ist?

Keine Ahnung, aber es spricht doch nix gegen, dass 4 MCDs in Reihe die zwei GCDs verbinden und diese eher länglich sind.

Auch wäre dann chiplets überhaupt kaum im Vorteil beim Yield im vergleich zu einer salvagelösung. Wenn man GCDs in die kleinste EInheit als 128mb/64bit unterteilt kann man die bei einem Fehler nicht salvagen. Der Yield geht dadurch deutlich runter und das trotz des super aufwändigen Packaging. Man könnte auch einfach einen großen 512mb/256bit MCD nehmen und als salvage nur 384mb/192bit nutzen.

Was willst du denn da groß salvagen? Das ist ein Memory controller mit Cache mit nicht gerade riesiger Diesize. Beim Cache könntest du doch eh so designen, dass du 130mb oder so verbaust, um kleine Fehler zu salvagen, wenn du es wirklich brauchst. Anschließend werden nur gute Dies benutzt, daher ist der Packaging Yield das einzige Risiko.

Finde dann aber immer noch dass ein 3xSE GCD und ein 2xSE GCD zu nah aneinander liegen als dass es dafür einen eigenen chip geben muss.

50% Steigerungen ist doch oftmal üblich für einen weiteren Chip. Nvidia hat teilweise für viel kleinere Sprünge eigenen Chips gehabt. Vor allem ist Die Size in 5nm einfach extrem teuer. Da lohnt das auf jeden Fall.

mboeller

2021-08-04, 18:28:11

Auch wäre dann chiplets überhaupt kaum im Vorteil beim Yield im vergleich zu einer salvagelösung.

1 GCD hat 32 WGP von denen nur 30 aktiviert sind.

Bei den Konsolen-SoC funktioniert das ja auch und der Yield ist gut, soweit ich das mitbekommen habe.

basix

2021-08-04, 20:08:58

Auch wäre dann chiplets überhaupt kaum im Vorteil beim Yield im vergleich zu einer salvagelösung. Wenn man GCDs in die kleinste EInheit als 128mb/64bit unterteilt kann man die bei einem Fehler nicht salvagen. Der Yield geht dadurch deutlich runter und das trotz des super aufwändigen Packaging. Man könnte auch einfach einen großen 512mb/256bit MCD nehmen und als salvage nur 384mb/192bit nutzen.

Dieses "EMIB" nennt sich InFo_LSI bei TSMC und habe ich vor ein paar Seiten schon erwähnt. Yield ist ein Thema, aber so solchen Verbindungen werden immer redundante Leitungen vorgesehen. Yield sollte pro MCD + GCD Verbindung >99% liegen, sonst wäre das nicht gut.

Edit:
Das MCD wird auch mit "high density" SRAM wie bei Zens V-Cache inkl. 64bit SI wohl ~80-90mm2 schwer sein. Das teilt man lieber auf, wenn man das auch für den kleinen N32 nutzen will ;)

Ich glaube nicht dass man 16 Chips auf dem PCB bzw. rückseiten anordnen wird. Das macht die Einsparungen durch die geringe busbreite beinahe zunichte.

Welchen Chip sprichst du an? N31, N32 oder N33? Bei N33 und 16 GByte reichen normale 16Gbit Chips (8 Stück auf der Top Seite, wie bei einem 256b SI). Bei N32 und 192bit und 2x Chips pro Controller landet man bei 384bit mässigen 12 Chips. Das geht noch Single Sided auf die Platine. Nur bei der Top Notch und extrem teuren N31er müsste man auf Double Sided Bestückung gehen. So extrem teuer ist das bei normalen GDDR6 nicht (verglichen mit G6X). Das gibt es schon ewigs bei Workstation Grafikkarten, welche im Falle von Nvidia Kraten oftmals dann noch ein 384b anstatt 256b Interface mitbringen.

50% Steigerungen ist doch oftmal üblich für einen weiteren Chip. Nvidia hat teilweise für viel kleinere Sprünge eigenen Chips gehabt. Vor allem ist Die Size in 5nm einfach extrem teuer. Da lohnt das auf jeden Fall.

Für den Big Chip sind +50% wirklich nicht unüblich. Ich denke aber, dass N32 eigentlich dem entspricht, was wir heute als Enthusiast ansehen. N31 macht mMn eine neue "Halo Over the Top" Kategorie auf. Titan / Fury mässig

1 GCD hat 32 WGP von denen nur 30 aktiviert sind.
Nicht nötig, wenn es unter dem 30er WGP einen 28er geben kann. Zudem soll ein GCD bei N32 zwei Shader Engines und bei N31 drei Shader Engines tragen. 30 / 3 = Passt. 32 / 3 = Ehm, eher nicht.

davidzo

2021-08-04, 20:21:32

1 GCD hat 32 WGP von denen nur 30 aktiviert sind.

Bei den Konsolen-SoC funktioniert das ja auch und der Yield gut, soweit ich das mitbekommen habe.

Wie soll das funktionieren, es sind ja 3SE und 2x SA. Wenn spare WGPs vorhanden wären, dann wären es mindestens 33, also 11WGP pro SE oder gar 36, also 1x spare pro SA.
Außrdem geht es bei den navi31 leaks ja bisher nicht um SKUs, sondern den chip, also würde ich schon stark vermuten dass das der Vollausbau ist und cutdown für yieldverbesserung nachträglich gemacht wird wenn man den genauen yield kenn und nicht bereits vor dem tapeout.
Das hieße dann eher wir können uns auf 27WGP oder 24WGP gefasst machen von theoretischen 30 pro GCD.

Dieses "EMIB" nennt sich InFo_LSI bei TSMC und habe ich vor ein paar Seiten schon erwähnt. Yield ist ein Thema, aber so solchen Verbindungen werden immer redundante Leitungen vorgesehen. Yield sollte pro MCD + GCD Verbindung >99% liegen, sonst wäre das nicht gut.
Du Superschlauer! Wie ich das vor nem Jahr samt Folien mal hier gepostet habe ;D -Info-LSI ist bekannt ;)
Schon klar das TSMC das kann, aber kleine Brücken waren bisher weder tsmcs noch AMDs stil. Gerade weil der Die aktiv ist und cache enthalten ist, macht es viel mehr Sinn die TSVs auf ein größere Fläche zu verteilen als auch noch innerhalb des GCDs cache DIEs zu stacken um einen kleineren brückenchip hin zu bekommen. Das macht das packaging unnötig teuer wenn man das auch in wenigen layern in einem GCD hin bekommt. Ich bezweifle auch dass man die angestrebte Bandbreite und Latenzen für einen Grafikchip erreichet wenn man nur geringe Flächen des Chips für die Durchkontaktierung mit TSVs verwendet.
Wenn dann sind die Brückenchips mit Cache +SI aktiv und schon etwas größer und die Kontakte gut verteilt. Was mir dann aber nicht in den Kopf will ist wieso ein monolitischer Cachechip mit 25% salvagemöglichkeit nicht billiger und effizienter ist als drei/vier einzelne die man jedes mal wegschmeißen muss wenn beim 64bit SI auch nur ein Bit kaputt ist.

basix

2021-08-04, 20:59:05

Du Superschlauer!
Danke! Ehre, wem Ehre gebührt ;D

Zum Rest:
Keine Ahnung wie heikel SI-Fehler sind. Bei AMD anscheinend nicht so sehr wie bei Nvidia, da die Karten typischerweise das volle SI mitbringen. Evtl. sind es auch 66bit auf dem Chip :D

InFo-LSI (25um Pitch, hallo Intel ;D) hatte die Quali glaube ich auch erst Q1/Q2-2021. Stile können sich also ändern ;)

Ich erwarte auch nicht, dass man die MCDs stacked. Die werden nebeneinandergelegt, dadurch sollte man recht viel Fläche für TSVs bekommen. Bandbreiten-Density sollte man mit total ~300-350mm2 MCD Fläche schon gut verteilen können.

Was mir eher ein wenig Kopfzerbrechen bereitet: Die Form des MCD und des GCD. Es müsste eine eher längliche Form wie z.B. der PS5 SoC sein. z.B. 6*12mm beim MCD. Die GCDs wären dann ihrer Seite auch sehr länglich, z.B 22*11mm 24*14mm beim N21 GCD mit einem leichten Überlapp der MCDs.

Leonidas

2021-08-08, 03:51:25

1 GCD hat 32 WGP von denen nur 30 aktiviert sind.
Bei den Konsolen-SoC funktioniert das ja auch und der Yield ist gut, soweit ich das mitbekommen habe.

Macht man bei PC-Grafikchips nicht. Man entwickelt immer den vollen Chip (und gibt selbigen auch so an) - und schaut nachher, was davon schaltet man frei.

Beispiel: Die letzten HPC-Chips von NV. Immer korrekt mit der richtigen SM-Anzahl vorab gemeldet. Die offizielle Vorstellung lief dann immer mit kleinerer Nummer ab.

fondness

2021-08-09, 15:13:04

Die Radeon-Lösung sollte man nicht mit Ryzen vergleichen. Das Ziel ist ein anderes ist (und damit auch die Methoden).
Es geht NICHT um Kostenersparnis und Gleichteil-Strategie, sondern darum die Grenzen der Fertigung zu umgehen.
N31 und N32 mit gleichem MCD, anderen GCD und jeweils 2GCD + x MCD.

Naja, wenn man schon auf ein solches Multi-Chip-Design setzt, ist es schon recht naheliegend auch eine "Gleichteil-Strategie" zu fahren. Die Vorteile sind immerhin evident was Kosten und time-to-market betrifft. Man braucht sich ja nur mal ansehen, wie ewig lange AMD jetzt benötigt, um alle Navi2x-Chips auszurollen. Jetzt kommt endlich Navi23 und irgendwann gegen Jahresende dann Navi24. Das ist man von AMD gar nicht mehr gewohnt, bei den CPUs braucht es nur ein neues Chiplet und man kann defacto direkt alle Märkte bedienen, das ist schon ein immenser Vorteil in einem schnellen und competitiven Markt.

amdfanuwe

2021-08-09, 15:49:36

Man braucht sich ja nur mal ansehen, wie ewig lange AMD jetzt benötigt, um alle Navi2x-Chips auszurollen.
Das liegt wohl an den Kapazitätsbeschränkungen. N23 war sicherlich schon für Anfang des Jahres geplant.
Bei Kapzitätsmangel würden auch mit Chiplets nur die höher margigen Produkte bedient, sähe es also genauso aus.

AffenJack

2021-08-09, 16:30:52

Mal wieder neue Aussagen von Bondrewed zu Navi, die nicht so toll sind:
But 450 buck range is 12GB now.
Gets down to 8 next year unless somehow lucky and JEDEC updates G6 spec and all.

https://forum.beyond3d.com/posts/2218062/

Also laut ihm nächstes Jahr wahrscheinlich mehr Geschwindigkeit als ne 69XT, aber nur 8GB Ram für 500$.

Sonst müsste man mit 128Bit doppelseitig bestücken. Ich hab aber generell noch so meine Zweifel an den Gerüchten. Alleine das man den Bandbreitenbedarf nochmal halbieren soll mit der nächsten Gen.

basix

2021-08-09, 17:34:57

Das halte ich für BS. 8GByte sind für eine 1080p Karte noch OK. Für alles andere nicht. Momentan ist das Lineup ja so:
- N21 = 4K --> 16GB
- N22 = 1440p --> 12GB
- N23 = 1080p --> 8GB
- N24 = 1080p / Mobile --> 6GB
Das macht Sinn und ist ausgewogen keine der GPUs wird bei der Zielauflösung VRAM Probleme bekommen. Mit Ausnahme N24 evtl. einen Ticken mehr als nötig, aber es hält die nächsten 2-3 Jahre.

Bei den RDNA3 Gerüchten und N33 und 80 CUs sehe ich das eher so:
- N31 = High FPS 4K oder 4K+ --> 16...32GB --> 256bit
- N32 = 4K --> 20...24 GB --> 160...192bit (20GByte = Salvage)
- N33 = 1440p --> 12GB --> 192bit
- N34 = 1080p --> 8GB --> 128bit
- APUs = Low End

N33 ist auch so ein deutlicher Rückschritt was GByte/Performance angeht. Für 1440p Gaming aber noch OK. Aber <12 GByte kann ich mir einfach nicht vorstellen. Das wäre noch grotesker als es die 3080 schon heute ist (noch weniger Speicher bei schnellerer GPU und 2 Jahre später).
Vielleicht gibt es noch die tiefste Salvage-SKU bei 10GB (N33) und 6GB (N34). Das macht Sinn und tut niemandem weh, da die Option nach oben vorhanden ist.

Ich habe bereits hier (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12753140#post12753140) geschrieben, wie ich mir ein sinnvolles Lineup vorstelle.

Edit:
Noch was zum Raytracing. Bei Minecraft RTX werden 15% für Cache Updates, 40% für RT und 45% fürs Denoising aufgewendet (https://youtu.be/TVtSsJf86_Y?t=1746) (Performance auf Turing). Grossteil des Denoisings beinhaltet SVGF (https://cg.ivd.kit.edu/publications/2017/svgf/svgf_preprint.pdf). Neuere Denoiser sind nochmals +50% schneller (https://developer.nvidia.com/blog/nvidia-real-time-denoiser-delivers-best-in-class-denoising-in-watch-dogs-legion/). Mittels viel FP32 Leistung und starker Cache Performance kann man so also auch ohne höhere RT-Leistung deutlich an Performance gewinnen.

Leonidas

2021-08-14, 13:54:11

N31/33 erstmals seitens AMD-Dokumentationen (Treiber?) erwähnt:
https://twitter.com/KOMACHI_ENSAKA/status/1426503707592511488

HOT

2021-08-14, 14:02:01

basix
Einen N34 wird es wohl nicht geben, der ist bislang auch noch nie erwähnt worden. Ich halte die Theorie, dass alles unter N33 ein refreshter N2x ist für absolut plausibel. Man braucht keine neuen Desings und verwendet halt dennoch N6 für diese Produkte. RT-Leistung ist bei dieser Leistungsklasse eh egal.
N24 wird mMn weiterhin 128Bit haben aber keinen IF$ mehr, was ja bei P11 und P12 genau so. Mal sehen, welche Fertigung der Chip überhaupt nutzt.

Cyberfries

2021-08-14, 14:29:42

"Untenrum auffüllen mit N2x" sagt sich so einfach...
Wird N33 tatsächlich (wie öfters spekuliert) angesetzt als mobile-Chip mit höherer Leistung als N21 und 8GB Ram,
wird das Portfolio ziemlich merkwürdig - angesichts N22 als nächstkleinerem Chip mit 12GB Ram und 230w Leistungsaufnahme.

Auch N22 refresht in 6nm hilft da wenig, eigentlich ist ein N34 zwingend notwendig als N23-Ersatz,
denn ich kann mir N33 kaum in einem Notebook mit 50w-Grafik vorstellen.

HOT

2021-08-14, 14:47:33

Ich glaube nicht, dass N33 besonders schneller als N21 wird (außer RT), denn der wird ja zwar 128MB IF$ haben aber nur ein 128Bit Speicherinterface. Der Chip ist ja nur für WQHD gedacht, da spielt es ja keine Rolle, ob der in UHD langsamer wird. Das ist dann ein bisschen so wie N23 vs. N10. Ich denke auch, dass N33 6nm wird und nicht 5nm. Das passt sehr gut.
Und bis die Dinger kommen wird mMn 24Gb oder gar 32Gb Speicher spruchreif sein mMn. 24Gb ist ja gerüchteweise schon auf dem Weg, damit hätte N33 dann 12GB. Passt doch sehr gut.

Also mMn Specs:

N31/2:
2GCDs (N5) + MCD (N6) mit insgesamt 256MB IF$ und 256Bit GDDR6, 24GB 18GT/s dank 24Gb-Chips und 16GB 18GT/s dank 16Gb-Chips
N33 in N6 mit 40WGPs+128 MB IF$ und 128Bit GDDR6, 12GB 18GT/s dank 24Gb-Chips.
N22 in N6
N23 in N6
N24 in ?

vinacis_vivids

2021-08-14, 15:27:48

https://digideutsche.com/nachrichten/amd-rdna-3-navi-31-und-navi-33-gpus-der-naechsten-generation-auf-der-rocm-opengpu-plattform-aufgefuehrt/

Navi33 hat eine ähnliche Leistung wie N21, verbraucht aber wegen dem schmalen SI und 6nm nur noch ~200W statt ~330W. Auch der große IF-Cache spielt eine entscheidende Rolle.

https://abload.de/img/1628023634_808_amd-rdrajxt.png

Bei 128bit SI kommen dann allerdings "nur" 8GB VRAM raus, was eher für WQHD spricht und weniger UHD, wobei der Cache anscheinend auch Einfluss auf die nutzbare VRAM-Größe hat.

Die Umgewöhnung der Kunden wird nicht einfach werden, die sich bei N21 an 16GB gewöhnt haben :D

Mit kleineren internen Verbesserungen für RT, größerer Cache, höherer Takt wird N33 vermutlich leicht schneller sein als N21 :eek:

Das MCM-Modell sollte dann die Tür für 6K-8K Auflösung eröffnen, sicherlich dann auch mit einem FSR-Update.

dargo

2021-08-14, 15:32:25

Wer kauft sich Ende 2022 einen N33 mit der Performance von >=N21 mit nur 8GB? :ucrazy:

w0mbat

2021-08-14, 15:53:42

Jeder, der eine bekommt :ugly:

Neurosphere

2021-08-14, 16:49:47

Wer kauft sich Ende 2022 einen N33 mit der Performance von >=N21 mit nur 8GB? :ucrazy:

Wir reden über Midrange für maximal WQHD. Ob 8GB nun top sind oder nicht, aber unmöglich ist es nicht das sowas kommt und auch gekauft wird. Die Frage ist ja auch immer wie Effizient das ganze genutzt wird.

dargo

2021-08-14, 17:00:36

Jeder, der eine bekommt :ugly:
In der aktuellen Marktsituation würde ich dir da sogar absolut zustimmen. :ulol: Nee, aber ernsthaft... das wäre wirklich übel. Gibts da keine Aussichten für 2022 mit 4GB GDDR6 pro Chip?

davidzo

2021-08-14, 17:20:08

Was mich noch ein bisschen stutzig macht ist der Rückgang an der Anzahl an Shader engines.

Das halbiert die Rasterizer + prim units und sollte damit schon einen spürbar negativen Effekt auf die Geometrieleistung (Tesselation?) haben.
Und das ist ein Bereich wo AMD ohnehin hinten liegt, mit nur 4x primitve setup und Raster engines die zusammen 4 dreiecke pro takt schaffen. Nvidia hat in GA102 immerhin 7x stück, je ein RE pro GPC und sogar 42x polymorph engines, je eine pro TPC.
Ein grund wieso navi22 so nah an navi23 liegt ist doch gerade diese Halbierung der Geometrie-ressourcen auf nur noch 2x prim units und rasterizer, genau wie bei navi23.

Bei navi31 ist eine gewisse Steigerung noch vorhanden, von 4(navi21) auf insgesamt 6 SE. pro GCD-Chip geht es aber sogar zurück, von 4 auf 3. Aber spätestens bei Navi33 sieht das doch so aus, als wenn AMD einen Schritt zurück zu GCN, also mehr Compute, weniger Rasterizing Effizienz/Auslastung geht.

Und die Verdopplung der Alus pro WGP, wird auch Auswirkungen haben auf die zur verfügung stehende LDS Bandbeite und Größe in diesem WGP. Der L1 im Shader Array muss damit ebenfalls doppelt so groß und schnell werden um pro Alu die gleiche Leistung zu liefern.

Wie schafft man das ohne dass die Auslastung der Alus drunter leidet?

robbitop

2021-08-14, 17:48:15

Ein ziemliches hin und her bei GPUs in Bezug auf Granularität. Das betrifft hier zwar die Anzahl der FPs pro SM dient aber sicherlich einer gewissen Analogie:

Tesla: 8 FP pro SM
Fermi: 32 FP pro SM
Kepler: 192 FP pro SM
Maxwell/Pascal: 128 FP pro SM
Volta/Turing: 64 FP pro SM
Ampere: 128 FP pro SM

Und jedes Mal wird was anderes erzählt. Wird es grober heißt es mehr throughput. Wird es granularer heißt es die Granularität hilft.

Bei AMD ist es ähnlich gewesen wenn man bis in in die VLIW Zeit zurück und noch davor zurückschaut.

Es ist interessant, dass es nicht kohärent in eine Richtung sich entwickelt.

Wahrscheinlich ist es jedes Mal etwas anders wie man mit so wenig wie möglich Transistoren die meiste Performance erreichen kann ausgehend von der letzten uArch.

davidzo

2021-08-14, 18:29:48

Ich glaube wirklich mit Maxwell hatte man eine art zeitlich lokales Optimum gefunden.
Die Karten sind extrem gut gealtert, wenn man mal bedenkt dass sie mit total groben 28nm Chips heute noch GTX1650 bis 1660ti Leistung abliefern (GM204 -GM200) und das bei für heutige Maßstäbe noch akzeptablem verbrauch. Und der 16nm Refresh mit Pascal ist heute mit der 1050 immer noch vertreten und ziemlich konkurrenzfähig in seiner Leistungsklasse und Effizienz.

Davor waren es andere Themen die das Leistungsverhalten beeinfluss haben. Mit GCN ist AMD lange Zeit bei der Geometrieleistung hinterhergehinkt und nvidia hat das mit Hairworks und intensiver Tesselation Promotion geschickt auszunutzen gewusst. Mit der Zeit ist der Fokus auf Geometrie verschwunden und GCN Karten sind in modernen Spielen ihren Kepler Gegenstücken spürbar überlegen.
Ein ähnliches Spiel sieht man heutzutage mit Raytracing, wer weiß denn schon wo die Spiele in 2-3 Jahren geschweige denn 6-8 Jahren den Fokus drauf legen.

Ich kann mir aber vorstellen dass es heute Maxwell/Pascal/Ampere der kleinste gemeinsame Nenner für Spieleentwickler sind.

Eine neue µArch ist letztendlich eine Wette auf die Zukunft der Spiele-Softwareentwicklungs Trends in 3-4 Jahren. Klar dass da nvidia mit ihren größeren Manpower und massiv größeren Dveloper-Relations Programmen meistens die bessere Glaskugel besitzt. Aber die Industrie ist ja nicht komplett intransparent. Da kriegt man schon viel mit und viele Top Hardwarentwickler wechseln durchaus mal den Arbeitgeber um den eigenen Marktwert zu erhöhen.

OgrEGT

2021-08-15, 10:23:55

reaperrr

2021-08-15, 14:16:10

Wer kauft sich Ende 2022 einen N33 mit der Performance von >=N21 mit nur 8GB? :ucrazy:
Jeder, der nicht vorhat, in absehbarer Zeit seinen 1080p-Bildschirm aufzurüsten und dafür noch jahrelang nahezu alle anderen Einstellungen bis zum Anschlag hochdrehen möchte :wink:

Die Anforderungen an die Rechenleistung je Pixel sind schon immer (deutlich) schneller gestiegen als die Speicheranforderungen je Pixel.

Was mich noch ein bisschen stutzig macht ist der Rückgang an der Anzahl an Shader engines.
6nm bietet nur unwesentlich mehr Packdichte als 7nm und N33 ist vom Marktsegment (leider nicht unbedingt vom Preis) wohl eher als N23-Nachfolger zu sehen.

Im Grunde wird das vom Aufbau am ehesten ein N22 mit verdoppelten ALU-SIMDs je WGP, schmalerem SI, eventuell dafür mehr IF$ (bin da wg. 6nm aber noch skeptisch, mehr als 128MB kann ich mir eig. nicht vorstellen) und allgemeinen Architekturverbesserungen.

Tippe auch, dass der nur durch deutlich höhere Taktraten an die (Raster-)N21-Leistung rankommt, und auch nicht überall. Bondrewd sagte 30-50% schneller als 6700 XT, und ne 69XT ist eigentlich immer zwischen 45-50% schneller.
Also wird N33 vmtl. nur in Situationen, wo die uArch-Verbesserungen voll durchschlagen (und die Bandbreite nicht so wichtig ist), mal vor ner 69XT landen, die Raster-Leistung je ALU je Takt wird wahrscheinlich aber deutlich niedriger sein.

Tippe auch auf nur 64 ROPs.

basix

2021-08-15, 20:02:27

Höhere Taktraten und dann nur auf N21 Niveau macht keinen Sinn. Vor allem, wenn N31 2.5-2.7x schneller als N21 werden soll. RDNA3 hätte dann ein überirdisches Scaling bezüglich mehr Recheneinheiten oder nochmals deutlich mehr Takt.

vinacis_vivids

2021-08-15, 20:48:10

Höhere Taktraten für N33 müssen min. 3.0Ghz GPU-CLK her, weil die guten Samples bei N23 schon 2.7-2.8Ghz bei Luftkühlung erreichen.

Ich denke AMD wird auch den Cache noch höher Takten, um die Hitrate zu verbessern und damit kleinen Speicher SI mit 8GB noch besser auszunutzen.

Die neue Aufteilung in WGP Gruppen spricht für eine Verdopplung der RT-Ausführungseinheiten und das ist wohl mit die größte Neuerung. Statt 80-RT Cores bei N21 wird N33 160 RT-Cores haben und das begründet auch den vergleichsweise vergrößerten Cache gegenüber N23.
Das sollte auch den RT-Rückstand ohne großen Aufwand gegenüber NV wettmachen.

Die RT-Cores brauchen schnellen Cache wegen der discard-Fähigkeit, die mit dem Takt (Latenz) skaliert.

N33
5120SP fp32
160RT Cores
3.0Ghz GPU-CLK
~30,7 Tflop/s fp32
128MB IF$
8GB VRAM GDDR6
128bit SI
256GB/s

So ein 6nm-Ding bei ~200W wird einige Käufer finden, weil es bei Rasterizing der schnellste Singel-Chip sein wird und bei RT mächtig aufholt. N33 wird der reinste Cashcow bei AMD und eine Massenära bei mixed RZ/RT - Rendering auslösen.

AMD wird den GPU-Markt über Jahre dominieren können, bye bye Nvidia :D

Platos

2021-08-15, 21:05:02

Was ziehst du dir eigentlich täglich rein:confused:

Muss ja harter Stoff sein.

Neurosphere

2021-08-15, 21:21:01

Die neue Aufteilung in WGP Gruppen spricht für eine Verdopplung der RT-Ausführungseinheiten und das ist wohl mit die größte Neuerung. Statt 80-RT Cores bei N21 wird N33 160 RT-Cores haben und das begründet auch den vergleichsweise vergrößerten Cache gegenüber N23.
Das sollte auch den RT-Rückstand ohne großen Aufwand gegenüber NV wettmachen.

Wo nimmst du das denn nun her? Das sich bei den RA was tut kann man vermuten, aber in welchem Sinne ist doch vollkommen unbekannt!

Orko

2021-08-15, 22:42:57

Ich denke AMD wird auch den Cache noch höher Takten, um die Hitrate zu verbessern

HiHiHi ... der ist mal wieder gut ... ein echter vinacis_vivids !

Wenn das mal nur so einfach wäre mit dem Hitrate erhöhen, dann könnte man sich ja glatt ne Menge teure Die-Fläche sparen.

Badesalz

2021-08-15, 22:52:16

Eigentlich erwarte ich an sich aubch, daß sich das meiste bei RT tun wird und der Rest dem untergeordnet ist.
Bei non-RT FPS können sie mittlerweile schon brauchbar nur von P/L leben.

davidzo

2021-08-15, 23:42:51

6nm bietet nur unwesentlich mehr Packdichte als 7nm und N33 ist vom Marktsegment (leider nicht unbedingt vom Preis) wohl eher als N23-Nachfolger zu sehen.

in 2022? Schön wärs. Nein AMD rückt mit dem ganzen portfolio eine Stufe höher. N31ist über der 6900xt angesiedelt, also in der 1500-2000€ Klasse, N32 wird das 600-1000€ Segment das aktuell mit N21 bedient wird übernehmen und N33 wird der klassische performance sweetspot, also 6700xt, 3070 Niveau für 400-500€.

Im Grunde wird das vom Aufbau am ehesten ein N22 mit verdoppelten ALU-SIMDs je WGP, schmalerem SI, eventuell dafür mehr IF$ (bin da wg. 6nm aber noch skeptisch, mehr als 128MB kann ich mir eig. nicht vorstellen) und allgemeinen Architekturverbesserungen.

Jo, single-DIe kann ich mir auch nicht soviel cache vorstellen, nur gestacked als günstiger extrachip. Sonst wird das in 6nm ein chip der flächenmäßig noch zwischen N21 und N22 liegt, also viel zu teuer für die geplante Richtung.
Ich kann mir sogar ein 96mb oder kleineren cache vorstellen für die geplante Klasse - wobei dann die 128bit echt arg zu wenig wären.

Tippe auch auf nur 64 ROPs.
Sehr wahrscheinlich.

Höhere Taktraten und dann nur auf N21 Niveau macht keinen Sinn. Vor allem, wenn N31 2.5-2.7x schneller als N21 werden soll. RDNA3 hätte dann ein überirdisches Scaling bezüglich mehr Recheneinheiten oder nochmals deutlich mehr Takt.
Ich glaube auch nicht an so viel mehr Takt. Ich glaube eher an Verbrauchstuning und Packdichte. Nur mit geringen Herstellungskosten kann man den Chip so günstig im Performancesegment anbieten. Und 128bit SI deutet echt auf Mobileeinsatz und einen starken Fokus auf Energieefizienz hin.
Der Chip wird für Navi21 das was Navi23 für Navi10 ist. Also reduziertes SI, aber etwa gleiche Rechenleistung und insgesamt günstiger herzustellen und Effizienter.

basix

2021-08-16, 08:19:50

128bit und somit nur 8GByte halte ich bei dieser Performance für zu wenig. Das Ding wird vermutlich schneller als eine 6900XT. Und bei aktiviertem RT sind 8GByte auch bei niedrigen Auflösungen voll. 12 GByte wären da deutlich sinnvoller, untenrum allenfalls abgerundet mit N22/N23.

Das würde dann etwa so aussehen:
|N31|N32|N33|N23
SPs|15'360|10'240|5120|2048
# MCDs|4|3|n.a.|n.a.
Speicherinterface [bit]|256|192|192|128
Speichertransferrate [GT/s]|16|16|16|16
Speicherbandbreite [GByte/s]|512|384|384|256
Infinity Cache [MByte]|512|384|96|32
Target Resolution|4K+|4K|1440p|1080p
IF$ Missrate @ Target Resolution [%] (est.)|23|26|35|50
Effective Bandwidth @ Target Resolution [GByte/s] (est.)|2226|1478|1097|512
VRAM [GByte]|32|24|12|8

Klar, 32 GByte sind Overkill. Etwas anders könnte das aussehen, wenn AMD an 24GBit Chips rankommt. Dann könnte man folgende SI anbieten:
|N31|N32|N33|N23
Speicherinterface [bit]|256|192|128|128
Infinity Cache [MByte]|512|384|128|32
VRAM [GByte] |24|18|12|8

HOT

2021-08-16, 08:36:39

Samsung will doch bald 24Gb DDR5-Chips anbieten, ich denke, es wird 24Gb auch als GDDR6 geben. Aber ich denke, es ist von allen möglichen Seiten her relativ klar, dass N33 bei 12GB landen dürfte.
Rasterleistung in etwa auf N21-Niveau, RT-Leistung deutlich darüber, 12GB RAM und deutliche Abschläge ab UHD, die Die Größe dürfte von >500mm² auf ca. 440mm² sinken, die TBP von 300W auf 220-250W. Das Ding wird ein Konkurrenzprodukt für die 3080Ti in FHD und WQHD, jedoch nicht in UHD.

basix

2021-08-16, 13:15:57

Von LPDDR4X gibt es bereits 24 Gbit: https://www.computerbase.de/2019-10/samsung-24-gbit-dram-12-gb-lpddr4x-umcp/

24 Gbit für DDR5 ist wie du sagst angekündigt: https://www.tomshardware.com/news/samsung-develops-24gb-ddr5-drams-768gb-modules-enroute

Leonidas

2021-08-16, 14:05:16

Jeder, der eine bekommt :ugly:

Böse :up:

Wer kauft sich Ende 2022 einen N33 mit der Performance von >=N21 mit nur 8GB? :ucrazy:

Ich hoffe immer noch, das AMD am Ende doch 1,5-GByte-Speicherchips hervorzaubert. Würde alle Probleme lösen.

Samsung will doch bald 24Gb DDR5-Chips anbieten, ich denke, es wird 24Gb auch als GDDR6 geben.

Das Samsung diese DDR5-Chips fertigt, macht zwar Hoffnung - sagt aber letztlich Nullkommanix aus. In der Spezifikation steht 1,5 GByte pro Chip schon seit GDDR5X, technisches Hexenwerk ist es sowieso nicht.

Am Ende muß es irgendeiner groß bestellen, damit es wirklich hergestellt wird.

basix

2021-08-16, 14:17:59

Im Grunde ist 24 Gbit der nächste logische Schritt. Von 16 auf 32 ist ein sehr grosser Schritt in Zeiten, wo die DRAM-Skalierung stark abgenommen hat (=hohe Speichermengen sind teuer = wirtschaftlicher Druck + Hohe Fabauslastung=Druck auf knappe Waferkapazität=erhöhte Waferkosten=zusätzlicher wirtschaftlicher Druck). Und zudem auf Seiten SW immer mehr in Richtung Ausnutzung von Streaming von der SSD gearbeitet wird, womit sich der Druck auf die DRAM Kapazität reduzieren sollte (Direct Storage, Sampler Feedback Streaming, Next Gen Konsolen, UE5 Nanite, ...).

Vorteil von AMD: Mittels IF$ können sie die Speichermenge und Speicherbandbreite voneinander entkoppeln. Je nach verfügbarem Speicher werden SI-Breite sowie IF$-Kapazität gewählt, sodass es für die Zielauflösung passt.

HOT

2021-08-16, 14:25:52

1,5Gb hat keiner gebraucht bisher. Das ist bie 2,5Gb einfach was anderes. Man sieht es ja, es wird ja 2,5Gb für uDIMM geben, das ist bei 1,5Gb nicht der Fall. Genauso siehts mit GDDR aus. Es ist klar, dass man mehr Gb braucht für die kleineren Speicherinterfaces, denn auch die kleineren Karten werden ja mehr Speicher bekommen. Es ist keine Frage des ob sondern nur des wann und bis Ende 22 vergeht ja noch ein bisschen. Ich halte die Chance für sehr hoch, dass sowas kommen wird, einfach weil absolut klar ist, dass die Nachfrage besteht.

Leonidas

2021-08-16, 14:46:14

https://digideutsche.com/nachrichten/amd-rdna-3-navi-31-und-navi-33-gpus-der-naechsten-generation-auf-der-rocm-opengpu-plattform-aufgefuehrt/

Hinweis:
Die Seite ist eine reine Abschreib-Übung von WCCF Tech:
https://wccftech.com/amd-next-gen-rdna-3-navi-31-navi-33-gpus-listed-in-rocm-opengpu-platform/

davidzo

2021-08-16, 15:36:16

Hinweis:
Die Seite ist eine reine Abschreib-Übung von WCCF Tech:
https://wccftech.com/amd-next-gen-rdna-3-navi-31-navi-33-gpus-listed-in-rocm-opengpu-platform/

Ja und der WTF-tech Artikel ist selber nur eine Kompilation aus den aktuellen und älteren Spekulationen auf Twitter. Nichts neues oder eigenes dabei...

dargo

2021-08-16, 16:42:46

Ich hoffe immer noch, das AMD am Ende doch 1,5-GByte-Speicherchips hervorzaubert. Würde alle Probleme lösen.

Das lese ich schon seit mehreren GPU-Generationen. Passiert ist bisher nichts in diese Richtung. Ich finde eh diese Beschränkung auf 1GB bis 2GB Chips bescheuert. Gerade durch die 1,5GB wäre man bei der Gestaltung des eigenen Portfolios einiges flexibler.

vinacis_vivids

2021-08-16, 18:46:33

AffenJack

2021-08-22, 14:15:34

Navi31 soll wohl im Oktober sein Tapeout haben laut dem guten Greymon:

Greymon55
@greymon55
A huge star will set in two months.

https://twitter.com/greymon55/status/1427582900598304768

Also alles nach Plan für Release Q3/Q4 22.

fondness

2021-08-22, 14:20:02

Hm, da könnte durchaus auch noch Ende Q2 machbar sein. Gamma Cassiopeiae ist dann also wohl der interne Navi31 Codename.

Geldmann3

2021-08-22, 14:21:44

Ich glaube nicht an 1.5GB Chips im Alleingang bei AMD und 8GB sind nicht mehr vermittelbar für 1440p. Da müssen 12GB her was 192bit SI wahrscheinlich macht (siehe 6700XT)

N33 aka 7700XT wird ein mix aus N23-6700XT (VRAM, SI, IF$) und N21-XTXH (Shader, Takt) mit verbesserten RT-Cores und Einsparung der Fläche durch 6nm.

N33
5120SP fp32
160RT Cores
3.0Ghz GPU-CLK
~30,7 Tflop/s fp32
96MB IF$
12GB VRAM GDDR6
192bit SI
384GB/s

Das stimmt mit basix gut überein und diese spekulierte Version ist deutlich runder für 1440p. ~15% Flächenersparnis für 6nm gegenüber 7nm und kleinerer Cache als N21 kommt der N33 auf 360-370mm² und 250W TDP

PS.: Die Konkurrenz braucht 628mm², 912.4 GB/s und 400W für die gleiche Leistung ;D

Das ist nicht nur ein Quantensprung, sondern ein Sprung durchs Wurmloch in die Zukunft. Huang kriegt in echt viele viele graue Haare! ;D

Vermutlich wird AMD bei den Refreshes nicht sonderlich an der Raytracing-Performance schrauben.
Schätze prozentual zur Raster-Performance weniger als 5%, doch ich weiß es nicht.

Bei den RDNA3 Karten gehe ich dann jedoch von einem ähnlichen Verhältnis von Rasterizing/Raytracing Performance aus, wie es bei der RTX 3000er Serie der Fall ist.

Ich denke einfach nicht, dass AMD noch viel Geld und Zeit in die Evaluierung von alten, neu aufgesetzten Grafikarchitekturen stecken möchte, weshalb wir eher nur kleine Optimierungen, etwas mehr Takt, etwas schnelleren Speicher und mit gekreuzten Fingern einen Port auf TSMCs 6nm Prozess sehen werden.

Weil ich vermute, dass selbst ein leicht beschnittener Navi 33 Chip bereits eine RTX 3090 marginal schlagen kann, (Ich weiß, klingt etwas verrückt, dass der schwächste Navi3x Chip bereits eine RTX 3090 leicht schlägt und das bei deutlich weniger Stromverbrauch) denke ich, dass AMD alles, bis hoch zum 600€ Bereich, mit leicht getunten Refreshes füllen wird. Ich weiß, das klingt ebenfalls verrückt und enttäuschend, doch 7nm ist einfach günstiger und die Leute kaufen sowieso alles aus den Regalen weg, daher halte ich es 2022 für schlau von AMD, den Bedarf des Marktes erstmal (mit etwas scheinbar Neuem) zu bedienen und 7nm, 6nm + 5nm kann man eh nebeneinander laufen lassen. Da man dafür jedoch eine getunte 6800 XT mit einem, ich nenne es mal Navi21+ Chip, braucht, kann man auch gleich wieder den Vollausbau mit 80CUs verkaufen.

Erinnert mich sehr an die R9 300er Serie, in welcher ebenfalls Refreshes zu sehen waren, bis hoch zu den Fury Karten.
Die in meinen Augen ein absoluter Flop waren, weil sie NUR 4GB HBM Speicher verbaut hatten.
Mit 8GB HBM Speicher hätte man gut gegen die 980 Ti dagestanden, doch das war zurzeit technisch leider noch nicht möglich.

Daher kann ich mir gut vorstellen, dass die Fury Karten die Ehre ihres Namens aus den frühen 2000ern in der nächsten Generation wieder herstellen werden.

Wie ich mir das Lineup der RX 7000er Serie anhand der neuesten Informationen vorstelle, zeige ich in diesem Video.

RIMSlmrUKTw

AffenJack

2021-08-22, 14:26:21

Hm, da könnte durchaus auch noch Ende Q2 machbar sein. Gamma Cassiopeiae ist dann also wohl der interne Navi31 Codename.

Wie soll das gehen? Greymon sagt nicht umsonst Oktober 22 Release für N31.
1 Jahr ist der normale Zyklus von Tapeout zum Release, im allerbesten Fall mal 9 Monate. Aber die Durchlaufzeiten in den Fabriken und Zeit zum Evaluieren wird mit kleineren Nodes und mehr Transistoren eher länger, als kürzer. Insbesondere bei N31, wo man erstmal ein komplett neues Packagedesign hat, wenn die Gerüchte stimmen.

fondness

2021-08-22, 14:28:21

Wie soll das gehen?

Gibts du dir die Antwort nicht selbst? :confused:

im allerbesten Fall mal 9 Monate.

9 Monate waren in der Vergangenheit nicht so selten. Kann aber sein, dass es durch den Chiplet Aufbau etwas länger dauert. Auch 6 Monate gabs hin und wieder, allerdings eher nicht bei einer neuen Architektur sondern Refreshes.

AffenJack

2021-08-22, 14:47:12

Gibts du dir die Antwort nicht selbst? :confused:

Selbst im allerbesten Fall wären wir bei Oktober + 9 Monate gleich Anfang Q3 22. Aber das ist im neuen Prozess und großen chip komplett unrealistisch.

9 Monate waren in der Vergangenheit nicht so selten. Kann aber sein, dass es durch den Chiplet Aufbau etwas länger dauert. Auch 6 Monate gabs hin und wieder, allerdings eher nicht bei einer neuen Architektur sondern Refreshes.

Beispiele? Bei einem Big Chip im neuen Prozess? Wann waren das da mal 9 Monate?
Vega war 12 Monate, Navi21 war 12 Monate. Dabei war N21 noch nicht mal ein neuer Prozess oder Veränderungen im Packaging.
Jedes mal kommt hier diese Diskussion auf, dass der Chip nach 9 Monaten releast, nur kommt das merkwürdigerweise nie vor. Aber klappt bestimmt, wie schon bei N21, wo hier nach dem Tapeout soviele von Q2 ausgingen, weil es ja so schnell geht.

DozerDave

2021-08-22, 17:37:02

Vermutlich wird AMD bei den Refreshes nicht sonderlich an der Raytracing-Performance schrauben.
Schätze prozentual zur Raster-Performance weniger als 5%, doch ich weiß es nicht.

Bei den RDNA3 Karten gehe ich dann jedoch von einem ähnlichen Verhältnis von Rasterizing/Raytracing Performance aus, wie es bei der RTX 3000er Serie der Fall ist.

Ich denke einfach nicht, dass AMD noch viel Geld und Zeit in die Evaluierung von alten, neu aufgesetzten Grafikarchitekturen stecken möchte, weshalb wir eher nur kleine Optimierungen, etwas mehr Takt, etwas schnelleren Speicher und mit gekreuzten Fingern einen Port auf TSMCs 6nm Prozess sehen werden.

Weil ich vermute, dass selbst ein leicht beschnittener Navi 33 Chip bereits eine RTX 3090 marginal schlagen kann, (Ich weiß, klingt etwas verrückt, dass der schwächste Navi3x Chip bereits eine RTX 3090 leicht schlägt und das bei deutlich weniger Stromverbrauch) denke ich, dass AMD alles, bis hoch zum 600€ Bereich, mit leicht getunten Refreshes füllen wird. Ich weiß, das klingt ebenfalls verrückt und enttäuschend, doch 7nm ist einfach günstiger und die Leute kaufen sowieso alles aus den Regalen weg, daher halte ich es 2022 für schlau von AMD, den Bedarf des Marktes erstmal (mit etwas scheinbar Neuem) zu bedienen und 7nm, 6nm + 5nm kann man eh nebeneinander laufen lassen. Da man dafür jedoch eine getunte 6800 XT mit einem, ich nenne es mal Navi21+ Chip, braucht, kann man auch gleich wieder den Vollausbau mit 80CUs verkaufen.

Erinnert mich sehr an die R9 300er Serie, in welcher ebenfalls Refreshes zu sehen waren, bis hoch zu den Fury Karten.
Die in meinen Augen ein absoluter Flop waren, weil sie NUR 4GB HBM Speicher verbaut hatten.
Mit 8GB HBM Speicher hätte man gut gegen die 980 Ti dagestanden, doch das war zurzeit technisch leider noch nicht möglich.

Daher kann ich mir gut vorstellen, dass die Fury Karten die Ehre ihres Namens aus den frühen 2000ern in der nächsten Generation wieder herstellen werden.

Wie ich mir das Lineup der RX 7000er Serie anhand der neuesten Informationen vorstelle, zeige ich in diesem Video.

https://youtu.be/RIMSlmrUKTw

Hat der Typ das Intro von Igors Lab genutzt?

Geldmann3

2021-08-22, 18:17:21

https://youtu.be/RIMSlmrUKTw

Hat der Typ das Intro von Igors Lab genutzt?

Der Typ bin ich und nein, das Intro ist sozusagen von derselben Stange (https://www.renderforest.com/de/template/computer-system-logo-reveal) von der alle Intros von Igors Lab zu sein scheinen. :D

maximus_hertus

2021-08-23, 16:35:15

Nett gemacht, aber das Lineup ergibt nicht so viel Sinn. Viel zu viele SKUs. Ach die Preise sehe ich so nicht. Aber es ist nur ein imo ;)

FarCry

2021-08-23, 17:19:56

Wie ich mir das Lineup der RX 7000er Serie anhand der neuesten Informationen vorstelle, zeige ich in diesem Video.

13 Modelle einer Serie? Echt jetzt?
Komm schon, ein bissel mehr Realismus täte gut. Auch bei Prognosen. :biggrin:

Geldmann3

2021-08-23, 17:54:14

13 Modelle einer Serie? Echt jetzt?
Komm schon, ein bissel mehr Realismus täte gut. Auch bei Prognosen. :biggrin:

Die HD 7000er Serie hatte sogar 23 Modelle und es würde zudem die Chance bestehen, dass AMD die Refreshes noch vor den RDNA3 Modellen auf den Markt wirft, das gezeigte Lineup daher einen ziemlich langen Zeitraum abdeckt.

Neurosphere

2021-08-23, 17:54:44

https://abload.de/img/screenshot2021-08-231edkdj.jpg

Geldmann3

2021-08-23, 17:58:39

https://abload.de/img/screenshot2021-08-231edkdj.jpg

Keine 30er und 27er WGP Modelle? Woher nimmt AMD dann die Chips für die großen Dual-Chipmonster?

Oder meinst Du, dass sie diese Dies ausschließlich für die Dual-Karten verwenden wollen?

Bisher haben wir es bei Consumer-Hardware noch nie in der Geschichte gesehen, dass ein Die nur deshalb aufgesetzt wurde, um in einem Multi-Chip-Verbund genutzt zu werden. Weder bei CPUs noch bei GPUs.
Ich gehe davon aus, dass AMD hier den Ryzen Ansatz fahren wird, nur die effizienteren (selektierten) Chips verwendet man in den MCM-Karten, damit der Stromverbrauch nicht durch die Decke geht.

basix

2021-08-23, 18:22:08

Geldmann3

2021-08-23, 18:44:53

Die RDNA2 Refreshes machen Sinn, aber nicht mit N21. Ersetze die 7600/7700er mit N33, dann passt das. N33 soll ~440mm2 gross sein und somit kleiner als N21 und deutlich höhere RT-Leistung mitbringen. Da lohnt sich N21 einfach nicht.

- N32 kann man wie N21 recht weit zurückstutzen (z.B. 2x 15 WGP), N33 ist dann nicht mehr so weit weg. Das passt von der Lücke her.

Jope, genau den Gedanken hatte ich bei der Erstellung der Liste auch, der 6900 XT Refresh ist so ineffizient. Doch zwei Sachen haben dagegen gesprochen. Erstens habe ich noch nicht das Geringste von einem kleineren Navi3x Chip als 18WGPs gehört. (Hat natürlich nicht unbedingt etwas zu bedeuten.) Und zweitens sind die 5nm Kontingente bei TSMC sehr stark von Apple und Co ausgebucht, da scheinen zu Beginn fast keine Wafer für AMD frei. Doch ich weiß es nicht^^ wir werden sehen.

Die R9 390 und R9 390X waren damals in einer ähnlichen Situation ebenfalls ineffizient, weshalb mich der Refresh damals gewundert hatte.

basix

2021-08-23, 19:07:17

N33 soll noch in 6nm daherkommen ;)

Geldmann3

2021-08-23, 19:14:35

Das würde natürlich einiges ändern.

Nach allem was ich bisher gehört habe, soll nur das MCD und vielleicht noch die 7nm Refreshes in 6nm kommen, da die Portierung von 7nm relativ einfach sein soll.
Die GCDs sollten jedoch komplett für 5nm entwickelt sein.

basix

2021-08-23, 19:28:19

Genau, die GCDs von N31 und N32 kommen in 5nm. Die MCDs, N33 und RDNA2 Refreshes in 6nm. Soweit der aktuelle Gerüchtestand.

HOT

2021-08-23, 19:34:08

Also nach dem, was für Preisregionen die neuen Chiplet-GPUs ansteuern könnten, dürfte tatsächlich 7xxx nicht unbedingt zielführend sein als Namensgebung. Man könnte diesen GPUs tatsächlich andere Namen geben als die übliche modellnummer und das restliche Lineup einfach so beziffert lassen wie jetzt auch.

Also
N33 XT -> 7800XT
N33 XL -> 7800
N22 XT N6 -> 7700XT
N22 XL N6 -> 7700
N23 XT N6 -> 7600XT
N23 XL N6 -> 7600
usw.

Für die Chiplet Dinger könnte man tatsächlich ein Fury-Derivat auspacken wie Fury II MAXX oder sowas, also vielleicht

N31 XT -> Fury II MAXX
N31 XL -> Fury II
N32 XT -> 7900XT
N32 XL -> 7900

Oder man lässt einige ne halbe Nummer absteigen, also

N33 XL -> 7700XT
N22 XT -> 7700

oder sowas. Wär natürlich blöd wenn der Yield gut ist, denn die meisten kaufen glaub ich lieber XT-Varianten. Alles ein bisschen tricky.

Geldmann3

2021-08-23, 19:36:17

Ich bin echt gespannt.^^

Um ehrlich zu sein, ich bezweifle es eher, dass sie Navi 31 für 5nm und Navi 33 für 6nm entwickelt haben. Das MCD sollte sich dediziert entwickeln lassen, den Grfaikchip für unterschiedliche Fertigungsverfahren aufzusetzen allerdings einen riesen Rattenschwanz hinter sich herziehen.

6nm spart zwar etwas Platz aber wahrscheinlich kaum Strom gegen 7nm. Vllt. 10%, eher nur 5?
Beim Speichermodul kein großes Problem, bei einem Grafikchip, welchen man auch noch im Verbund betreiben möchte allerdings durchaus.

HOT

2021-08-23, 19:40:20

Die 6nm sind schlichtweg billiger und man benötigt die 5nm für die CPUs. Die paar GCDs bei den hohen Preisen fallen da nicht ins Gewicht, ne komplette Mainstream-GPU-Serie aber schon. Ich finde es extrem schlau, die GPUs, auf die es ankommt in N5 zu fertigen und den Rest auf N6 zu belassen und auch N33 in N6 zu lassen. Denn ob der ein paar W mehr verbaucht ist nicht so wichtig, die Leistung wird der Chip in dem Preisbereich auch bringen.
Und wenn N31 mit mehreren IODs per TSVs gestackt ist ergibt das auch wieder Sinn, einen monolithischen N33 zu basteln (neben dem Offensichtlichen, der Fertigung).
Ich möchte dezent auf das Cores on Uncore hinweisen:
https://www.techpowerup.com/img/2CZiSsAk4nT51SbO.jpg

Quelle:
https://www.techpowerup.com/285852/amd-envisions-direct-circuit-slicing-for-future-3d-stacked-dies

Geldmann3

2021-08-23, 19:46:53

Die 6nm sind schlichtweg billiger und man benötigt die 5nm für die CPUs. Die paar GCDs bei den hohen Preisen fallen da nicht ins Gewicht, ne komplette Mainstream-GPU-Serie aber schon. Ich finde es extrem schlau, die GPUs, auf die es ankommt in N5 zu fertigen und den Rest auf N6 zu belassen.

Ich befürchte einfach, dass es ein großer Aufwand ist Navi3x für zwei Architekturen Nodes zu entwickeln. Man optimiert auf ein bestimmtes Fertigungsverfahren hin. So ist die Optimierung auf 7nm einer der größten Faktoren, welcher der 6700 XT 32% mehr Performance als der 5700 XT verleiht. Taktnormiert sind die beiden nahezu gleich schnell, die 6700 XT manchmal 2% schneller, wegen dem Infinity Cache und ein paar Änderungen im Chipdesign. Doch die 6700 XT kann dank Optimierung bei gleicher Leistungsaufnahme wesentlich höher takten und fast nur daher kommen die 32% Mehrperformance.

Neurosphere

2021-08-23, 19:50:59

Keine 30er und 27er WGP Modelle? Woher nimmt AMD dann die Chips für die großen Dual-Chipmonster?

Sie sind erstmal nur Monster wenn wir davon ausgehen das MCM genausogut wie Monolitisch skaliert. Außerdem könnte der Stromhunger oben begrenzent wirken.

Oder meinst Du, dass sie diese Dies ausschließlich für die Dual-Karten verwenden wollen?

Es ist nach allen Gerüchten nix geplant richtung 30 WGP.

- N32 kann man wie N21 recht weit zurückstutzen (z.B. 2x 15 WGP), N33 ist dann nicht mehr so weit weg. Das passt von der Lücke her.

Bei den "kleinen" Chips dürfte der Yield ziemlich gut sein, fraglich ob AMD sich gute Chips so runterschneiden will.

Bisher haben wir es bei Consumer-Hardware noch nie in der Geschichte gesehen, dass ein Die nur deshalb aufgesetzt wurde, um in einem Multi-Chip-Verbund genutzt zu werden. Weder bei CPUs noch bei GPUs.
Ich gehe davon aus, dass AMD hier den Ryzen Ansatz fahren wird, nur die effizienteren (selektierten) Chips verwendet man in den MCM-Karten, damit der Stromverbrauch nicht durch die Decke geht.

Zum einen sehe ich das bei meinem Zen 3 Ryzen nicht das AMD so etwas tut, hast du da nen Link zu(?), und zum anderen erfolgt bei GPUs die Selektion eher über das OC Vermögen, sieht man ja auch bei dieser Generation deutlich.

HOT

2021-08-23, 19:51:37

Geldmann3
Was für 2 Architekturen? Die basteln halt N3x auf N5 und N6. Man wird RDNA3 ja soweiso auch für N6 bringen, da ein IOD von Raphael ja eh N6 mit RDNA3 IP wird, wie es aussieht.

Neurosphere

2021-08-23, 19:53:07

Wird Raphael nicht mit RDNA2 kombiniert?

Geldmann3

2021-08-23, 19:54:14

Es ist nach allen Gerüchten nix geplant richtung 30 WGP.

Zwar nicht direkt, allerdings immerhin 2x30WGP. Da stecken die 30WGP Dies schließlich schon drin.

Geldmann3

2021-08-23, 19:55:10

Geldmann3
Was für 2 Architekturen? Die basteln halt N3x auf N5 und N6. Man wird RDNA3 ja soweiso auch für N6 bringen, da ein IOD von Raphael ja eh N6 mit RDNA3 IP wird, wie es aussieht.

Oh sorry, meinte nicht Architekturen, sondern Nodes.

HOT

2021-08-23, 19:55:46

Wird Raphael nicht mit RDNA2 kombiniert?
Lt ursprünglichen Roadmap Leak ist es RDNA3, sieht man allerdings nur an der Färbung ;).

https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-2223-august-2020

Neurosphere

2021-08-23, 20:07:29

Lt ursprünglichen Roadmap Leak ist es RDNA3, sieht man allerdings nur an der Färbung ;).

https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-2223-august-2020

https://videocardz.com/newz/amd-zen4-ryzen-cpus-confirmed-to-offer-integrated-graphics

https://cdn.videocardz.com/1/2021/08/AMD-Ryzen-Zen4-NAVI2.jpg

Hier wird von Navi 2 bei Raphael geschrieben.

Zwar nicht direkt, allerdings immerhin 2x30WGP. Da stecken die 30WGP Dies schließlich schon drin.

Es wird sich vermutlich nicht lohnen nur ein GCD mit einem MCD zu kombinieren.

Mir fehlt aber noch was zu deiner Ryzen Aussage, hast du da nun einen Link?

HOT

2021-08-23, 20:08:18

Danke für die Aufklärung ;).

Geldmann3

2021-08-23, 20:34:06

https://videocardz.com/newz/amd-zen4-ryzen-cpus-confirmed-to-offer-integrated-graphics

https://cdn.videocardz.com/1/2021/08/AMD-Ryzen-Zen4-NAVI2.jpg

Hier wird von Navi 2 bei Raphael geschrieben.

Es wird sich vermutlich nicht lohnen nur ein GCD mit einem MCD zu kombinieren.

Mir fehlt aber noch was zu deiner Ryzen Aussage, hast du da nun einen Link?

Leider nicht, ich schließe das nur aus meinen Erfahrungen beim Rechner Zusammenbau. Man würde davon ausgehen, dass ein 5950X auf jeden Fall eine bessere Kühlung benötigt als ein 5900X, habe allerdings schon öfter erlebt, dass das nicht der Fall war.

Daraus schließe ich, dass die besten Dies für die 5950X selektiert wurden.
War allerdings recht nah am Release, dass ich Rechner zusammengebaut habe, eventuell gibt sich das mit der Zeit?
Hat jemand anderes vielleicht auch Erfahrungen dazu?

Außerdem erreichst Du mit den CPUs höher im Lineup in der Regel höhere Taktraten, was ebenfalls auf eine Selektierung hindeutet. Mein 5600X macht z.b. schon bei 4,75Ghz auf einem Kern schlapp und ,,Business-Stable" läuft der erst bei 4,615Ghz oder so. Dagegen habe ich noch nie einen 5950X gesehen, der nicht mindestens 4,85Ghz stabil auf einem Kern schafft. Oft schaffen die das mit entsprechender Spannung und Kühlung sogar auf allen Kernen.

Meine Erfahrung bei den höheren Chips ist einfach bessere OC-Eigenschaften und weniger Hitzeentwicklung beim gleichen Takt, manchmal sogar trotz mehr Kernen.

HOT

2021-08-23, 20:49:09

Dafür gibts doch Salvage-Varianten?! Es ist doch klar, dass es ne Salvage-Stufe für N31 geben wird.

vinacis_vivids

2021-08-23, 21:19:00

Bei Navi21 ist das bereits der Fall mit der Takt,- und Kernselektion. Allerdings etwas anders ausgelegt als bei den CPU`s.

Navi 21 XTXH - max GPU-CLK ~ 2500Mhz (max. Cores) 06/2021
Navi 21 XTX - max GPU-CLK ~ 2250Mhz (max. Cores) 10/2020
Navi 21 XT - max GPU-CLK ~ 2250Mhz (weniger Cores) 10/2020
Navi 21 XL - max GPU-CLK ~ 2100Mhz (weniger Cores) 10/2020

Bei Navi21 XTXH kann man mit OC per Luft schon an die 2.85Ghz kommen. Unter Wasser sind mit mods. 2.9-3.0Ghz kurzzeitig in wenigen Anwendungen erreichbar.

Die Taktverbesserungen werden allerdings auch nach unten weitergereicht zur N22 2.5-2.6Ghz und N23 ~ 2.6-2.7Ghz.

Bin gespannt was die Taktdomain bei N3X singel-chip bringt und bleibe bei den ~3.0Ghz, zumindest für N33 was wieder eine Verbesserung von ~10% ausgehend von N23. Die größeren N32 und N31 werden sicherlich weniger Takt haben, weil sie massivste mehr Cores/Caches haben. Bei den größeren GPU-Chips frisst Takt nach oben hin zuviel Energie, die man per Luft nicht mehr vernünftig kühlen kann ~ 300W

Im Professionellen-Business Bereich:
Die mGPU N21 Modelle mit 32GB VRAM lässt sich AMD/Apple übrigens mittlerweile sehr gut bezahlen:
https://www.apple.com/de/shop/product/MJ093ZM/A/radeon-pro-w6800x-duo-mpx-modul
-> 5.750,00€

https://www.apple.com/de/shop/product/MJ103ZM/A/radeon-pro-w6900x-mpx-modul
-> 6.900,00€

gedi

2021-08-23, 21:37:28

amdfanuwe

2021-08-23, 22:07:29

3G@1.2V sind bei der XTXH unter Wasser, nochmals selektiert (thx an Sapphire) möglich, allerdings 0.0 sinnvoll. Performancegain weniger als 2% zu 2850@1,106V mit offenem PL! Ersparnis - 70W für quasi nix (max. 420W zu 345W ASIC-Power).
Solange es welche gibt die dafür nen Aufpreis zahlen, wirds halt gemacht.
-----------
Bei der Fertigung hat man immer unterschiedliche Qualitäten. Gaußsche Glockenkurve bzw. Normalverteilung.
Die Ätzprozesse und Photolacke haben halt immer kleine Abweichungen.
Sei es von der Wafermitte nach außen hin oder eben von Wafer zu Wafer oder je nach Charge der Lacke und Säuren.
Versucht man zwar im Verlauf der Produktion zu verbessern, aber 100% gleiche Chips bekommt man nie raus.
Nach den ersten paar Wafern schaut man sich die Chips an und kann dann festlegen wie selektiert wird.
Salvage heißt auch nicht, dass ein Fehler im Chip ist. Kann auch nur eine Einheit auf dem Chip sein, die den vorgegebenen Takt oder Verbrauch nicht schafft. Die wird dann abgeschaltet und der Chip als teildefekt, salvage, verkauft.

Gratzner

2021-08-23, 22:08:28

Man optimiert auf ein bestimmtes Fertigungsverfahren hin. So ist die Optimierung auf 7nm einer der größten Faktoren, welcher der 6700 XT 32% mehr Performance als der 5700 XT verleiht. Taktnormiert sind die beiden nahezu gleich schnell, die 6700 XT manchmal 2% schneller, wegen dem Infinity Cache und ein paar Änderungen im Chipdesign. Doch die 6700 XT kann dank Optimierung bei gleicher Leistungsaufnahme wesentlich höher takten und fast nur daher kommen die 32% Mehrperformance.

Also das RDNA2 höher takten kann, kommt im wesentlichen nicht durch Anpassungen, das Transistoren schneller schalten.

Solche Taktsprünge kommen heutzutage im wesentlichen durch mehr Pipeline-Stages. Mehr Pipeline-Stages erhöhen zwar den Takt, aber im Gegenzug dauert eine Rechenoperation länger, weil die Operation immer durch alle Stages muss.

Eine Pipeline teilt ja eine Recheneinheit in mehrer Stages (deutsch Stufen) auf. Der Takt wird hierdurch nur noch durch die schlechtmöglichste Signallaufzeit (kritischer Pfad) einer Stages, statt der gesamten Recheneinheit, limitiert. Also, überhaupt eine Pipeline hinzuzufügen verringert somit die schlechtmöglichste Signallaufzeit, die ein Signal pro Takt zurücklegen muss. Ist die Recheneinheit schon "gepipelined", kann man die Zahl der Stages weiter erhöhen. Dadurch wird die schlechtmöglichste Signallaufzeit weiter geringer, aber eine Rechenoperation muss aber nach wie vor durch die gesamte Recheneinheit und ist diese "gepipelined" eben durch alle Stages dieser Recheneinheit.

Das mehr an Performance muss tatsächlich durch höhere Parallelität kommen. Wieviel Parallelität durch bessere Logik kommt und wieviel durch den Cache kommt, welcher die Latenzen der Datenbeschaffung aus dem Speicher im Mittel stark verringert, kann ich nicht sagen.
--
Ich bin mir ziemlich sicher, man kann bei den großen Entwicklern (Intel, Nvidia, etc) immer davon ausgehen, das die nicht einfach mal 30% zusätzliche Schaltgeschwindigkeiten bei den Transistoren im Prozessordesign liegen lassen. Ja aber Takt ist halt nicht die Schaltgeschwindigkeit der Transistoren und kann ohne schnelleres schalten, wie ich es beschrieb, tatsächlich um 30% erhöht werden, wie es auch zwischen RDNA1 und 2 passiert ist.

Ich will nicht ausschließen, das tatsächlich mal 30% mehr Takt durch schnellere Transistoren kommen, das wäre aber dann durch ein besseres Fertigungsverfahren

Geldmann3

2021-08-23, 22:18:46

Also das RDNA2 höher takten kann, kommt im wesentlichen nicht durch Anpassungen, das Transistoren schneller schalten.

Solche Taktsprünge kommen heutzutage im wesentlichen durch mehr Pipeline-Stages. Mehr Pipeline-Stages erhöhen zwar den Takt, aber im Gegenzug dauert eine Rechenoperation länger, weil die Operation immer durch alle Stages muss.

Eine Pipeline teilt ja eine Recheneinheit in mehrer Stages (deutsch Stufen) auf. Der Takt wird dadurch nur noch die schlechtmöglichste Signallaufzeit einer Stages, statt der gesamten Recheneinheit, limitiert. Also, überhaupt eine Pipeline hinzuzufügen verringert somit die schlechtmöglichste Signallaufzeit, die ein Signal pro Takt zurücklegen muss. Ist die Recheneinheit schon "gepipelined", kann man die Zahl der Stages weiter erhöhen. Dadurch wird die schlechtmöglichste Signallaufzeit weiter geringer, aber eine Rechenoperation muss aber nach wie vor durch die gesamte Recheneinheit und ist diese "gepipelined" eben durch alle Stages dieser Recheneinheit.

Das mehr an Performance muss tatsächlich durch höhere Parallelität kommen.

Wieviel Parallelität durch bessere Logik kommt und wieviel durch den Cache kommt, welcher die Latenzen der Datenbeschaffung aus dem Speicher im Mittel stark verringert, kann ich nicht sagen. Ich bin mir ziemlich sicher, man kann bei den großen Entwicklern (Intel, Nvidia, etc) immer davon ausgehen, das die nicht einfach mal 30% zusätzliche Schaltgeschwindigkeiten bei den Transistoren im Prozessordesign liegen lassen. Ja aber Takt ist halt nicht die Schaltgeschwindigkeit der Transistoren und kann ohne schnelleres schalten, wie ich es beschrieb, tatsächlich um 30% erhöht werden, wie es auch zwischen RDNA1 und 2 passiert ist. Ausnahme wäre halt, es kommt ein riesen Fertigungsprung, zu mindestens im Sinne der Taktbarkeit, was zwischen RDNA1 und 2 nicht passiert ist

Interessant, danke für die Info!

Du meinst also wir haben mehr Takt, dadurch müssen die Rechenoperationen allerdings durch mehr Pipeline-Stages bis sie abgeschlossen sind und die Mehrperformance kommt durch die insgesamt gesteigerte Parallelität?

Gratzner

2021-08-23, 22:30:28

Korrekt Ich habe sogar in Erinnerung, das Computerbase in einen ihrer Artikel es auch mal Nebenbei erwähnt hat, das RDNA2 tatsächlich mehr stages hat.

Aber bei RDNA2 heißt das nicht zwangsweise, das AMD die Parallelität hauptsächlich durch bessere Logik so stark verbessert hat. Es kann tatsächlich auch durch die kürzere Latenzen aufgrund des infinity cache kommen. Da kann ich nichts dazu sagen. (ich habe es nochmal wiederholt, weil es gibt hier ein paar Leute, die haben ...nunja... Talent solche Sachen gezielt falsch zu verstehen)

reaperrr

2021-08-24, 02:28:09

Interessant, danke für die Info!

Du meinst also wir haben mehr Takt, dadurch müssen die Rechenoperationen allerdings durch mehr Pipeline-Stages bis sie abgeschlossen sind und die Mehrperformance kommt durch die insgesamt gesteigerte Parallelität?

Irgendwo - sollte entweder anandtech oder computerbase gewesen sein, aber ich bin gerade zu faul zu suchen - wurde die IPC zwischen N10 (5700XT) und N22 (6700XT) bei gleichem Takt verglichen, und N10 bzw. RDNA1 hat etwas besser abgeschnitten.

Die Mehrperformance von RDNA2 bei weitgehend identischen Specs (CUs, ROPs etc.) kommt also allein vom höheren Takt und der hohen Bandbreite des IF$, die Architektur als solche ist durch die etwas längere Pipeline (und vielleicht auch die halbierten Z/Stencil ROPs je RBE) ansonsten sogar leicht langsamer.
Spielt halt nur keine große Rolle, solange die längere Pipeline + IF$ die Effizienz und Taktbarkeit derart erhöhen.

Geldmann3

2021-08-24, 03:25:27

Irgendwo - sollte entweder anandtech oder computerbase gewesen sein, aber ich bin gerade zu faul zu suchen - wurde die IPC zwischen N10 (5700XT) und N22 (6700XT) bei gleichem Takt verglichen, und N10 bzw. RDNA1 hat etwas besser abgeschnitten.

Die Mehrperformance von RDNA2 bei weitgehend identischen Specs (CUs, ROPs etc.) kommt also allein vom höheren Takt und der hohen Bandbreite des IF$, die Architektur als solche ist durch die etwas längere Pipeline (und vielleicht auch die halbierten Z/Stencil ROPs je RBE) ansonsten sogar leicht langsamer.
Spielt halt nur keine große Rolle, solange die längere Pipeline + IF$ die Effizienz und Taktbarkeit derart erhöhen.

Hier (https://www.youtube.com/watch?v=ZIDi_PI8R8o) ein ganz gutes Video dazu.
Wobei man im Optimalfall noch die Speicherbandbreite des Vrams angepasst hätte.
Obwohl man diese andererseits ebenfalls zur Architektur und damit IPC zählen könnte.
Bei CPUs ändert man schließlich auch nicht die Geschwindigkeit der Caches, wenn man IPC-Vergleiche fährt.
Man könnte bei CPU-IPC-Vergleichen die Ramgeschwindigkeit anpassen, wäre wohl der bessere Vergleich.
Doch auch hier könnte man wiederum argumentieren ,,Pech für die CPU, wenn sie nur langsamen Ram unterstützt."

basix

2021-08-24, 08:24:23

Irgendwo - sollte entweder anandtech oder computerbase gewesen sein, aber ich bin gerade zu faul zu suchen - wurde die IPC zwischen N10 (5700XT) und N22 (6700XT) bei gleichem Takt verglichen, und N10 bzw. RDNA1 hat etwas besser abgeschnitten.

Bei CB: https://www.computerbase.de/2021-03/amd-radeon-rdna2-rdna-gcn-ipc-cu-vergleich/#abschnitt_gcn_vs_rdna_vs_rdna_2_benchmarks_in_full_hd

Bei FullHD ist Navi 10 schneller, in WQHD Navi 22.

Iscaran

2021-08-24, 11:56:03

Bei CB: https://www.computerbase.de/2021-03/amd-radeon-rdna2-rdna-gcn-ipc-cu-vergleich/#abschnitt_gcn_vs_rdna_vs_rdna_2_benchmarks_in_full_hd

Bei FullHD ist Navi 10 schneller, in WQHD Navi 22.

Ob das mit SAM noch so Bestand hat das Ergebnis von März 2021?

BlacKi

2021-09-06, 20:51:07

https://abload.de/img/screenshot2021-08-231edkdj.jpg
da bin ich aber mal gespannt ob der IC wirklich noch skaliert. die folie hier zeigt was ernüchterndes.

https://www.pcgameshardware.de/screenshots/original/2021/02/AMD-RDNA-2_Infinity-Cache_Hit-Rates-vs.-Capacity-pcgh.png

https://www.pcgameshardware.de/Radeon-RX-6600-XT-Grafikkarte-277709/Tests/Benchmark-Review-kaufen-Preis-6600-XT-vs-3060-Ti-1377026/galerie/3483234/?fullsize

aufkrawall

2021-09-06, 21:06:53

Muss man hier jetzt wirklich anmerken, dass du für schnellere GPUs mehr Cache brauchst, um das Hit-Verhältnis von den 128MB für Navi 21 aufrecht zu erhalten?

BlacKi

2021-09-06, 21:36:44

but at huge area cost

aufkrawall

2021-09-06, 21:53:25

Hat sie aber auch nicht davon abgehalten, gleich auf 128MB zu gehen.

BlacKi

2021-09-06, 22:27:58

von 64/96 gabs nochmal halbwegs einen sprung auf 128mb, at a cost of 94mm². 4k würde mit 512mb zwar noch gut weiterskalieren, aber alleine 377mm² in 7nm kosten XD das wären immernoch bestimmt +-325mm€ in 6nm.

robbitop

2021-09-06, 23:25:30

Mein Tip wäre, dass man mittelfristig Cache stackt. Ggf ja sogar mal mit 1T SRAM/eDRAM. Man kann sich dann ja den entsprechenden Fertigungsprozess aussuchen, der dafür geeignet ist (Cache Chiplets). Dann kann man die Cachenge weiter erhöhen.

basix

2021-09-06, 23:35:48

@Blacki
Du nimmst die falsche Basis. Ich denke du kannst eher die Density des V-Caches annehmen und dazu 6nm anstatt 7nm. Da können es dann auch ~250...290mm2 für 512 MB sein. Genau deswegen machen Chiplets so viel Sinn: Optimale Technologie für die entsprechenden Funkionsblöcke.

Wird es deswegen günstig? Definitiv nicht. 4x MCD in 6nm werden evtl. so teuer wie N10 oder N23. Die GCDs werden etwa so teuer wie N22, evtl. etwas mehr. Dafür wird die Top SKU mit 2x N5P Chiplets vermutlich auch das dreifache einer 6700XT kosten.

@Robbi
Cache Stacking würde Sinn machen, ja. Das kritische scheint die Verbindung zwischen den GCD zu sein. Das müsste man dann etwas anders als mit den MCD lösen und dennoch den Cache Unified halten.

BlacKi

2021-09-06, 23:57:59

ich glaube 512mb werden so oder so zu teuer werden. der performance effekt wäre nicht groß genug um die mehr kosten zu rechtfertigen.

gibts eigentlich was neues an der gddr front? gddr5x gabs ja auch nur eine generation. steht denn sowas wie gddr7 vor der tür?

ich geh mal in den passenden thread lesen...

Linmoum

2021-09-07, 00:16:30

Bei einer scheinbaren Verdreifachung der ALUs stellt sich sicherlich nicht mehr die Frage, ob relativ gesehen ein paar mm² mehr Cache jetzt in irgendeiner Form "zu teuer" wären. Das spielt dann auch überhaupt keine Rolle mehr, das riecht nach den bisherigen Gerüchten stark nach einem MCM-Approach der Marke "wir hauen alles rauf, was möglich ist".

BlacKi

2021-09-07, 00:18:07

bei 500w+ oder was. glaub ich nicht.

iamthebear

2021-09-07, 00:48:43

Die 6900 XT hat 300W
5nm braucht hat 30% weniger Verbrauch oder anders herum man wird einen GCD mit 50% mehr Einheiten auch bei 300W schaffen.

Packt AMD nun 2 GCDs auf ein chiplet, dann wäre das mit den Taktraten der 6900 XT etwas zu viel. Allerdings ist diese auch relativ hoch getaktet.
Reduziert AMD nun den Takt um 10-20% (was in etwa 2.4x -2.7x 6900XT bedeutet), so sollten 200W pro GCD einfach möglich sein, womit man wieder im kühlbaren Bereich ist.

Der zusätzliche Cache ist von der Verlsutleistung nicht relevant, da Cache relativ wenig verbraucht solange er nur Daten speichert aber nicht aktiv arbeitet.

Persönlich halte ich 512MB für durchaus realsitisch. Erstens muss man ja die Hitrate massiv steigern wenn diese Monster GPU trotzdem mit 256 bit GDDR6 gut laufen soll. Und zweitens werden damit auch sicher deutlich aufwändigere Einstellungen gespielt werden also entweder 8K (eventuell mit FSR UQ falls es nicht ganz reicht) oder es wird in 4K native mit RT Ultra gespielt was alles deutlich mehr VRAM braucht.

Es ist natürlich vollkommen klar, dass das keine 700 Euro Karte werden wird.

Leonidas

2021-09-10, 13:15:21

Radeon RX 7000 und GeForce RTX 40 sollen nahezu zeitgleich im Oktober 2022 antreten
https://www.3dcenter.org/news/geruechtekueche-radeon-rx-7000-und-geforce-rtx-40-sollen-nahezu-zeitgleich-im-oktober-2022-antr

Nightspider

2021-09-10, 16:44:25

Und erst hieß es AMD viel eher und NV viel später. ;D

Leonidas

2021-09-10, 16:58:07

Natürlich sollte man abwarten, was dann real im Jahr 2022 passiert ... aber irgendwie eine gewisse Nähe zum Verlauf früherer Generationen ist da schon spürbar. Bleibt zu hoffen, dass sich wenigstens die Performance-Prognose zu RDNA3 halten läßt.

Neurosphere

2021-09-15, 09:18:32

Wie soll man denn die Angaben von Greymon zu den Releasezeiten sehen? Bisher sollte N31/32 eigentlich immer als erstes kommen im Q3. Wurde das nun verworfen? Oder steht N31 so für sich alleine das er eigentlich wirklich außerhalb der Reichweite von Nutzern (Preis) und NV (Leistung) liegt und N33 das eigentlich Zugpferd ist und der Gegner von AD102?

Leonidas

2021-09-15, 10:19:32

Nein, N33 ist zweifellos nur N21 + bißchen was. Das ist eigentlich als Start einer neuen Generation extrem suboptimal, weil zudem durch das kleinere Interface auch noch limitiert auf kleinere Auflösungen - und damit nicht einmal eine Ablösung der 6900XT, sondern nur eine (schnellere) der 6700XT.

AMD muß also schnellstmöglich N31 bringen. Ich hoffe das Greymon sich hierbei irrt und das zumindest grob gleichzeitig kommt.

AffenJack

2021-09-15, 17:38:51

Und erst hieß es AMD viel eher und NV viel später. ;D

Das hieß es bei den letzten Gens immer und es wurde nie war. Die übliche Träumerei.

Wie soll man denn die Angaben von Greymon zu den Releasezeiten sehen? Bisher sollte N31/32 eigentlich immer als erstes kommen im Q3. Wurde das nun verworfen? Oder steht N31 so für sich alleine das er eigentlich wirklich außerhalb der Reichweite von Nutzern (Preis) und NV (Leistung) liegt und N33 das eigentlich Zugpferd ist und der Gegner von AD102?

Bei N32 wurde schon öfter gesagt, dass er später kommt. N32 soll ein 2023 Produkt sein. Zuletzt hieß es schon einige Male, dass N33 als erstes kommt. Ist auch gut möglich, weil 6nm. Nur ging man da von Q3 für N33 aus. Jetzt scheint es eher, dass N33 doch etwas später kommt und N31 wie geplant eben in Q4.

@Leonidas
Wie kommst du darauf, dass N33 nur N21 + bisschen was wäre?
Das Ding wird den ganzen neuen Shaderaufbau haben wie N31/32. Das einzige was fehlen wird dürfte eben MCM sein. AMD wird da keine verschiedenen Architekturen in N3X haben.

Leonidas

2021-09-18, 07:58:42

Wie kommst du darauf, dass N33 nur N21 + bisschen was wäre?
Das Ding wird den ganzen neuen Shaderaufbau haben wie N31/32. Das einzige was fehlen wird dürfte eben MCM sein. AMD wird da keine verschiedenen Architekturen in N3X haben.

Richtig, es hat den Architektur-Vorteil. Aber dafür kleines Interface und selbe Anzahl an FP32. Da sehe ich keinen großen Spielraum für Mehrperformance.

Neurosphere

2021-09-18, 10:31:09

Richtig, es hat den Architektur-Vorteil. Aber dafür kleines Interface und selbe Anzahl an FP32. Da sehe ich keinen großen Spielraum für Mehrperformance.

+15% rein für die Arch könnten realistisch sein. Dazu vermutlich Verbesserungen am Cache die den Abfall in hohen Auflösungen etwas besser dämpfen.

15%+ in FHD bis 20%+ in 4K düften drin sein. Dann käme man auch in die Nähe der prognostizierten Werte für Navi31.

vinacis_vivids

2021-09-18, 10:48:12

Die uArch Verbesserungen ergeben mehr GPU-CLK, also auf 3.0Ghz, später vllt. auf 3.2Ghz.
Die Hitrate des IF-$ wird sicherlich krass verbessert und die Kohärenz zum V-Cache des Zen3+ wird hergestellt. Das vergrößert den verfügbaren (physisch + virtuell) Cache um das vielfache. Die 12/16C CPUs sollen ja mit 192MB L3 kommen. Addiert man die spekulierten 96MB von der singel-GPU dazu, sind es summarum 288MB IF$.

Allerding wird N33 vermutlich häufiger, also preisbedingt eher mit 6C/8C Zen3+ und 96MB L3-Cache kombiniert werden, was summarum 192MB entspricht.

192MB (96MB + 96MB) kohärenter IF$ bei N33 & Zen3+ ist mehr als N21 & Zen3 mit 128MB + 32MB ~ 160MB. Also stärkere Leistung in allen Auflösungen und der GPU-CLK kommt noch mehr zur Geltung, was die u.a. die sehr wichtige discard-rate erhöht.

Die nutzbare Bandbreite steigt auf 2000GB/s, da würde ich bei N33 das SI sogar auf 128bit kürzen.

Allerdings steht dem entgegen, dass Leute auch teilweise nur die AMD-GPU kaufen und von der blauen Konkurrenz die CPU, weshalb AMD auch beim Singel-GPU eine beachtliche Performance bringen muss.

Der N33 wird sehr sehr interessant, weil die uArch Verbesserungen in Richtung CPU-GPU stärker sein wird.

Vermutlich kann der User dann endlich N33 preiswert aufrüsten und später noch ne andere Navi-GPU dazustecken.
Weil nicht jeder sich sofort ein MCM-Modell leisten kann, aber dennoch mGPU nach und nach (bei vorhandenen Finanzen) den Performancevorteil nutzen darf.

Zurzeit haben ja nur die Miner Nutzen von mGPU und die Gamer schauen eher in die Röhre. Wird Zeit, dass AMD endlich eine weitere Innovation bringt, freut mich mega :D

Neurosphere

2021-09-18, 18:40:51

Was hat der Cache der GPU mit dem der CPU zu tun?

vinacis_vivids

2021-09-18, 18:48:35

Kohärenz.

iamthebear

2021-09-18, 19:49:19

Irgendwie kann ich mir den Sinn dahinter nicht wirklich vorstellen.
Über den PCIe Bus auf fremde Caches zuzugreifen ist sowohl von der Bandbreite als auch von der Latenz her langsamer als gleich auf den eigenen VRAM zuzugreifen.

Was Navi33 angeht so bezweifle ich, dass es hier überhaupt Verbesserungen zur 6900 XT geben wird. Die Anforderung wird hier sein Navi 21 ohne zusätzlichen Transistoreinsatz so zu gestalten, dass er mit 128 Bit Interface läuft und dabei nur moderat Leistung verliert.
Und wenn dabei die Performance 10% fällt: Wen kümmert es, wenn dies der Nachfolger zur 6700 XT ist, die nur die halbe FP32 Anzahl hat.

Navi32 ist dann der eigentliche Navi21 Nachfolger. Hier gibt es dasselbe Interface, vermutlich 256MB IC und doppelte FP32 Anzahl in derselben Preis und TDP Klasse.

Navi31 wird dann ein riesiges Monster im Titan Style. Bei 2K UVP spielen die Kosten für die 512MB IC auch keine Rolle mehr genauso wenig wie die AIO im Referenzdesign.

Neurosphere

2021-09-18, 20:28:26

Kohärenz.

Was heißt Kohärenz? Kann der Cache des einen überhaupt in irgendeiner Weise auf den des anderen zugreifen und hat das einen Mehrwert?

vinacis_vivids

2021-09-18, 21:28:34

Der L3 Cache sowohl auf der GPU (IF$) als auch auf der CPU(V-Cache) kann zusammengeführt werden und die Hitrate in allen Auflösungen deswegen erhöhen. Kohärenz bedeutet, dass der Cache die gleichen Daten hat. Das vereinfacht und kürzt den Datentransfer zwischen CPU und GPU und spart Energie.
Da Ray-Tracing auch sehr speicherintensiv ist und den IF$ mitnutzt, braucht AMD eine Lösung, die auch wirtschaftlich machbar ist. Derzeit ist bei 128MB eine gewisse Sättigung zu beobachten (bei Rasterizing).
Bei Ray-Tracing hilft sicherlich die Expansion und Mitnutzung des V-Cache der CPU. Bei Verdopplung der Ray-Tracing Cores muss der Cache ausgebaut werden, aber eben auch nicht zu massiv. Im Prinzip kann die Schnittpunkberechnung mehr auf die CPU übertragen werden (mittels kohärenten IF$ + V-Cache abgespeichert) und die GPU kümmert sich weiterhin hauptsächlich ums rendering.

Das beschleunigt die Berechnungen massivst für Ray-Tracing und lastet die CPU auch in höheren Auflösungen besser aus.

Nightspider

2021-09-18, 22:38:00

Was denkst du denn zu glauben wie hoch die Latenz wäre, wenn die GPU auf den CPU Cache zugreifen würde? :ugly:

Sollen die Daten dann über den schmalen PCI Express Bus geschickt werden? Der wäre etwa Faktor 100 zu klein.

Du fantasierst da was zusammmen. Weniger Gras rauchen!

Und Raytracing würde nicht durch V-Cache beschleunigt werden. Der Infinity Cache liefert genug Bandbreite und kurze Latenzen.
Navi 21 hat mehr Bandbreite und kürzere Latenzen als Nvidias 3000 Serie und trotzdem stinkt man bei RT ab.

vinacis_vivids

2021-09-19, 09:35:21

https://abload.de/img/radeon-rx-6800-xt-uart7keo.png

Die errechneten RT-Daten werden in den IF$ abgespeichert, von daher ist eine Erweiterung des IF$ durch die Mitnutzung vom CPU-Cache sehr sinnvoll.

Es geht darum, die Last der RT-Berechnungen, einerseits deren Berechnung & Vorhersage, andererseits deren Speicherung & Verwerfung weiter zu vereinfachen bzw. Energie zu sparen.

Bei einer Änderung der CUs zugunsten der Expansion vvlt. auf 8 Ray/Bos intersection per CU-CLK und 2 Ray/Triangle intersection per CU-CLK brauchst du automatisch mehr IF$, am besten die Mitnutzung des V-Cache der CPU um eine Überlastung des IF$ zu verhindern.

Orko

2021-09-19, 10:42:54

Die von vinacis_vivids vorgestellten Gedanken ergeben bei APUs (CPU + iGPU) Sinn.

1) CPU und GPU auf demselben Chip, ein grosser L3 Cache (Infinity Cache, V-Cache) bedient sowohl CPU als auch GPU, Aufteilung dynamisch

2) ggf noch CPU und GPU als MCM nahe beieinander im selben APU Package und per Infinity Fabric mit hoher Bandbreite (viel höher als PCIe) verbunden.

Für dGPUs (hier im Kontext diskutiert: der N33 Chip) sind sie meiner Meinung nach sinnlos.

Zum einen würde jede Art von L3 Chache "Sharing" zwischen CPU und GPU sehr stark in die jeweiligen Chiparchitekturen eingreifen, was bei unterschiedlichen Herstellern von CPUs und GPUs und unterschiedlichsten Kombinationen dieser wohl kaum umzusetzen wäre.

Zum anderen ist der Sinn von Caches, Daten nahe (geringe Latenz, hohe Bandbreite) den Rechenwerken vorzuhalten. Bei dGPUS: Die von der dGPU wahrscheinlich benötigten Daten im den Cache Stufen der dGPU, und die von der CPU wahrscheinlich benötigten Daten im den Cache Stufen der CPU.

HOT

2021-09-19, 10:50:56

Da glaub ich kaum, dass es ne APU mit VCache geben wird und bisher können die IGPs nicht auf den L3$ zugreifen, das sieht jetzt auch nicht so aus, als wär das bei Rembrandt und van Gogh der Fall.

basix

2021-09-19, 11:03:06

Umso mehr L3$, desto mehr würde es sich aber lohnen. Kommt eine APU mit V-Cache: Mit sehr hoher Wahrscheinlichkeit ist dann eine gemeinsame Nutzung möglich. Evtl. fix partitioniert, um die Komplexität in Grenzen zu halten.

Aber auch ohne V-Cache würde es sich lohnen, wenn man z.B. auf 32MB L3$ gehen würde. Bei hoher 3D-Last z.B. 16MB für die iGPU, bei tiefer z.B. nur 4-8MB. Dies ist aber komplexer. Die iGPU Partition sollte nämlich in einer anderen Clock-Domain laufen usw.

robbitop

2021-09-19, 11:44:01

davidzo

2021-09-19, 12:00:35

Starke iGPs werden vom Markt einfach nicht stark genug belohnt. Große iGPs und große (teure Caches) oder teureres Packaging machen dann ökonomisch wenig Sinn, wenn man mit der erhöhten Siliziumfläche andere SKUs die mehr Marge bringen verkaufen könnte oder einfach mehr APUs. Solange der Markt besonders starke iGPs nicht mit deutlich höherer Nachfrage und erhöhter Marge belohnt wird die Motivation das zu tun nicht gerade steigen.

Wäre cool - aber außerhalb der Nerds (die nahezu irrelevant für den Gesamtmarkt sind) gibt es leider zu wenig Markt dafür.

Ja, das ist die ewige Leier die man von den OEMs hört. Der Fehler wird immer beim Konsumenten gesucht, nicht etwa in schlechtem Marketing dass sich seit seit Jahrzehnten auf diskrete Lowend GPUs eingeschossen hat weil das dem Kunden vermeintlich einfacher zu erklären ist. Bis der merkt wie schlecht das gesamte Package aus performance, akkulaufzeit, formfaktor, Geräuschkulisse ist.

Dass Apple seine Marktanteile mit genau dem Konzept einer sehr starken IGP kontinuierlich ausbaut ist dann halt selbst verschuldet. Das ist die eigene Faulheit der OEMs beim Marketing.

Dasselbe hat man schon bei Flashspeicher erlebt. Eigentlich ein No-brainer für mobilgeräte. Apple hat schon 2012 die gesamte Produktreihe auf flash umgestellt, aber die PC OEMs haben noch bis heute gerne große SATA HDDs verbaut, damit man dem Kunden einfacher "möglichst viel Terabytes" bieten kann.

Dieses Marketing des geringsten Widerstands, das wiederholte Verscheißern der eigen Kunden führt langfristig halt zum Verlust an Marktanteilen.
Und das sogar trotz dessen dass Apple mit Butterfly, der nicht-upgradebarkeit, nichtreparierbarkeit etc. noch ihre eigenen Baustellen aufgemacht haben.

basix

2021-09-19, 13:30:32

Es geht beim IF$ ja nicht nur um grosse und schnelle iGPUs:

Energieeffizienz
Synergienutzen von Chipanteilen, womit im Endeffekt je nach Auslegung sogar mehr Chips pro Wafer anfallen können (z.B. im Falle getrennter L3$ und IF$)
Positive Marketingwirkung / Tech-Leader Image. IF$ hat mMn ein sehr positives Image beim Konsumenten. Dieses Image hätte zudem eine übergreifende Konsumentenwirkung bei APUs zu dGPUs und vice versa
Nach Gerüchten will AMD und Nvidia aus dem LowEnd GPU Markt langsam aussteigen. Im Mobile Sektor kann man das nicht mit Gebrauchtmarkt-GPUs gegen unten hin abrunden. Stärkere iGPUs wären da von Vorteil. IF$ wäre generell eine Verbesserung. V-Cache könnte hier noch eine Option nach oben hin öffnen. Bei Bedarf kann ein Kunde eine APU mit V-Cache kaufen und somit mehr GPU-Leistung erhalten, sagen wir mal +50% da entferntes Bandbreitenlimit. Standard APUs sind von den zusätzlichen Kosten nicht betroffen. Somit kein Nachteil für die Standard-SKUs aber ein Vorteil mit relativ minimalem Aufwand für AMD.

Platos

2021-09-19, 14:07:47

Was heisst denn Low-End für dich? 1050 oder 1030? Weil 1030-er Nachfolger gibts schon lange nicht mehr. Und 1050/1050Ti sind/waren sehr beliebte Karten bzw. sind das beliebte Preisklassen.

genervt

2021-09-19, 15:45:54

1030er respektive RX 550er, glaube das war der letzte bei AMD sind schon tot.
Es geht darum die 1050er obsolet zu machen.

Platos

2021-09-19, 16:27:05

Das bräuchte aber so riiichtig fette iGPUs (man m¨sste ja nicht mit einer 1050 konkurrieren sondern mit einer 3050). Also müsste man mehrere CPU Serien aufsetzen, denn im Laptopmarkt brauchen viele keine so krasse iGPU. Für den Kunden am Desktop aber auch maximal beschissen, wenn man eigentlich im Preisbereich 150-200$ kaufen will und somit nicht mehr upgraden kann. Denn man müsste dann ja schliesslich ständig ne neue CPU kaufen und vermutlich sogar ein neues Mainboard oder mit Pech gar neuen RAM.

Also das wäre sehr schlecht aus Kundensicht.

Aber passt ja zu den beiden. Zuerst die teuren Grafikkarten anbieten und erst später das 300$ Segment abdecken und dann kann man schon wieder einen Refresh bringen und verkauft dann einfach die ehemaligen 300$-Karten für 200$ (oder aber auch nicht billiger...). Also im Preisbereich von 150-200$ würde man dann eben immer alte ware kriegen. Geil :D

Naja, nvidia will ja sowieso den Gebrauchtmarkt killen, indem sie "Minging-Karten" einführen, die dann faktisch E-Waste im Schnelldurchlauf werden und nicht mehr nutzbar sind als Gamer.

basix

2021-09-19, 17:42:48

Lowend = 1080p60 @ Medium Settings, auch bei einigermassen modernen Spielen

Das schafft keine heutige iGPU zufriedenstellend. Wäre nach heutigen GPU Massstäben wohl so ~1050 Ti

Nightspider

2021-09-19, 17:45:14

Glaub Mining Karten die in Grönland laufen haben eine geringere Betriebstemperatur als die Gamer Karten im 0815 Komplett PC. ^^

Wüsste aber auch nicht wo das Problem wäre wenn AMD zukünftig zwei mobile Serien rausbringen würde. AMD hat mittlerweile genug Ressourcen um stärker zu diversifizieren.
Machen sie teilweise auch schon mit Raphael der ebenfalls für Laptops kommt.

Würde mich nicht wundern wenn wir vers. IGP Ausbaustufen 2023/24 sehen werden.

Selbst wenn man sie nur durch V-Cache unterscheiden würde, könnte man da preislich und von der Performance größere Unterschiede realisieren.

Platos

2021-09-19, 17:53:17

Habe kein Problem damit, wenn CPU Hersteller das machen, aber wenn dann keine GPUs mehr im Preisbereich 150-200Euro zu kaufen sind, dann habe ich schon eins damit und das wäre vermutlich die Folge davo. Ist dann vom Prinzip die selbe Entwicklung wie eben bei Laptops, in denen heuzutage alles verlötet ist bzw, nicht erweiterbar. Das brauchen wir nicht im Desktop.

davidzo

2021-09-19, 18:26:02

Was heisst denn Low-End für dich? 1050 oder 1030? Weil 1030-er Nachfolger gibts schon lange nicht mehr. Und 1050/1050Ti sind/waren sehr beliebte Karten bzw. sind das beliebte Preisklassen.

Lowend heißt für mich GP107 und TU117 sowie neuerdings auch GA107 mit, die zusammen sicher 50% Marktanteil der Notebooks mit diskretem Grafikchip ausmachen. Diese Chips werden mit kastriertem Speicherinterface und limitierter TDP in Designs eingebaut die in allen Lebenslagen mit einer starken APU statt platz- und TDP-fressender Billig-GPU einen besseren Nutzwert hätten.

Sieht man ja am M1, die integrierte GPU bringt 1650m Leistung, hat aber einen Verbrauch und Akkulaufzeit mindestens so gut wie ne Intel IGP.
Dass die Bandbreitenschonenden Maßnahmen jetzt an TBDR liegen und nicht an IFcache ist ein unerhebliches Detail, denn die wesentlichen Merkmale sind gegeben: Ein monolitischer Chip mit monolitischem, breiten SI, bei dem die GPU über 5Mrd Transistoren verbrauchen darf, mehr als die CPU-Kerne ohne SI.

Platos

2021-09-19, 19:18:22

Laptop und Dekstop sind aber auch 2 versch. Dinge. Beim Laptop kann man de facto sowieso keine GPUs tauschen. Ist zwar ne unnötige Verschwendung für die meisten (die wenigsten brauchen M1 Grafikleistung), aber wenn man bei Laptops ne extra Serie aufsetzen will/würde, dann bitte.

Und ja, Apple geht ja auch immer mehr in Richtung alles in einem Bauteil bzw. alles verlötet. Also upgraden unmöglich. Bei Laptops macht man das vlt. weniger und zocken tun da vermutlich sowieso die wenigsten mit nem graphisch hohen Anspruch.

Aber wie gesagt, am Desktop ist das ne andere Baustelle. Wenn man dann in dem Bereich keine Grafikkarten mehr kriegt, dann schiessen sich Desktophardwareverkäufer ins eigene Bein. Für's Gaming am Desktop will man sowas eher nicht, denke ich und wenn man nicht mal upgraden kann, dann kann man ja gleich nen Laptop kaufen mit Monitor. Dann hat man beides in einem.

Also am Desktop schiessen sie sich damit ins eigene Bein.

basix

2021-09-19, 21:58:55

Geht aber wohl nicht viel anders, da 150$ dGPUs nur noch geringe Margen abwerfen würden. Ergo: Es lohnt sich nicht gegenüber teureren dGPUs. Eine LowEnd GPU von 2022-2023 sollte 6-8 GByte Speicher mitbringen und der Chip wäre vermutlich ebenfalls 150-200mm2 gross. Da die Top Notch Prozesse viel teurer sind als früher und der Speicher ebenfalls teurer ist (Menge * Preis/GByte) sind dGPUs in diesem Bereich für die Hersteller wohl einfach nicht attraktiv genug. Ob man zwei GPUs verkauft oder nur eine ist eigentlich egal, wenn man mit letzterem mehr Geld verdient.

davidzo

2021-09-20, 00:36:33

Laptop und Dekstop sind aber auch 2 versch. Dinge.

Klar, aber die Rede war doch von APUs, wo die im Hochpreissegment Sinn machen?
Desktop braucht nur ne Office-IGP, das ist klar. Aber der größere Markt ist nunmal mobile und nicht Desktop.

Wenn man dann in dem Bereich keine Grafikkarten mehr kriegt, dann schiessen sich Desktophardwareverkäufer ins eigene Bein. Für's Gaming am Desktop will man sowas eher nicht, denke ich und wenn man nicht mal upgraden kann, dann kann man ja gleich nen Laptop kaufen mit Monitor. Dann hat man beides in einem.

Also am Desktop schiessen sie sich damit ins eigene Bein.
Ne klar, ich halte zwar die GPUknappheit am Desktop für eine vorrübergehende Erscheinung, aber gaming PCs mit APUs sind echt nicht die Zukunft. Die Gamingnische bedient ja ganz andere Bedrüfnisse, "customization" etc. - Gaming PCs mit APUs gibts ja schon, nennt sich halt nur Konsole.
Mobile mach APU aber schon Sinn und ich denke auch das Mobile weiter auf Kosten des Desktops an Marktanteilen gewinnt, auch beim Gaming, auch wenn da vorrübergehend jetzt mal eine Pause war.

basix

2021-09-20, 11:36:53

Die zusätzliche dGPU bei Notebooks, welche nichtmal viel schneller ist als die iGPU, ist einfach sinnfrei. Heute begründet man das mit Marketing, dGPUs verkaufen sich laut diesen Aussagen einfach besser.

Was ist, wenn man hier an dieser Stelle V-Cache & Infinity-Cache in den Marketing-Ring werfen kann? Ebenfalls gut verwertbare Marketing-Wirkung und effektiv ein Unterschied in der HW. Für AMD ist das deutlich günstiger herzustellen, man verdrängt eine potentielle Nvidia GPU (Marktanteile) und für die OEMs ist es ebenfalls ein Vorteil (günstiger, kleiner, energieeffizienter). Das frei werdende Power Budget für die dGPU kann man zudem teilweise der APU zuführen (z.B. höhere iGPU Taktraten für mehr Performance).

Man nehme als Beispiel eine RDNA2 GPU mit 12 CUs, siehe Van Gogh:

Standard: 10 CUs, max. 2.0 GHz
V-Cache Edition: 12 CUs, 2.5 GHz -> +50% Performance

12 CUs entsprechen 768 SPs. Bei 2.5 GHz ergibt das 3.8 TFlops. Eine 1650m hat 1024 SPs bei max. 1.56 GHz und somit 3.2 TFlops. Die IPC von RDNA2 und Turing ist faktisch identisch. Somit sollte die V-Cache Edition die 1650m schlagen können. Auch für eine RTX 3050m, RX 5500M/5300M oder GTX 1060m könnte es reichen. Nvidia macht mit ihren Mobile GPUs viel Kohle, speziell seit Pascal. Hier mit einer für AMD sehr günstigen Lösung entgegen halten zu können wäre sehr vorteilhaft.

Edit:
DDR5 sollte günstiger als GDDR6 sein und man spart sich "redundanten" Speicher für die GPU. In Zeiten von hohen Speicherpreisen und GDDR6 Knappheit ebenfalls ein Vorteil.

Edit 2:
Ein 1080p Framebuffer mit 8bit Farbtiefe pro Kanal ist ziemlich genau 6 MByte gross. Könnte man also im IF$ vorhalten ;)

Nightspider

2021-09-20, 12:09:19

Selbst 16MB wären schon ziemlich winzig in 6nm.
Wenn man den mit einem Layer V-Cache auf 48MB verdreifachen könnte würde das viel bringen.
Wobei sich der Aufwand mit stacking für+32MB wahrscheinlich kaum lohnt bzgl Kosten/Nutzen Verhältnis.
Dann vielleicht eher eine APU ohne IF$ und eine Pro Version mit +64MB V-Cache.
Erstere müsste über den DRAM gefüttert werden und zweitere würde durch den extra Cache massiv beschleunigt werden.

Halte da auch +50% für möglich.

Aber ja, AMD könnte für Rembrandt beliebige Größen nehmen, auch sowas wie 6 oder 12MB IF$.
Wobei der gestackte Cache dann die höhere Latenz hätte, da flächenmäßig größer.

mboeller

2021-09-20, 12:13:11

V-Cache Edition: 12 CUs, 2.5 GHz -> +50% Performance
[/LIST]

sollte nicht bereits die zusätzliche Bandbreite durch den V-Cache für eine min. 50% bessere Performance sorgen, selbst mit 10CU und 2GHz?

Nightspider

2021-09-20, 12:16:12

50% gegenüber der H-Cache™ Variante. ;)

mboeller

2021-09-20, 12:34:00

found at @ Beyond3d:

https://diit.cz/clanek/amd-naznacila-mozne-dalsi-vyuziti-infinity-cache

die google-Übersetzung bzw. die automatische edge-Übersetzung ist ganz gut

Narolf

2021-09-20, 12:43:39

Was heisst denn Low-End für dich? 1050 oder 1030? Weil 1030-er Nachfolger gibts schon lange nicht mehr. Und 1050/1050Ti sind/waren sehr beliebte Karten bzw. sind das beliebte Preisklassen.
Also laut Gerüchten soll der sub-400$ Markt mittelfristig nicht mehr mit dGPUs bedient werden, bzw nicht mit dGPUs aus den dann aktuellen GPU-Generationen. (https://youtu.be/HDnwT5h472c?t=808)

Wäre sicher für sehr viele Leute (mich eingeschlossen) recht bitter. Eventuell könnte man iGPUs ganz gut pushen per größerem Cache, aber da stellt sich dann die Frage, wie teuer diese APUs werden.

mboeller

2021-09-20, 13:39:06

12 CUs entsprechen 768 SPs. Bei 2.5 GHz ergibt das 3.8 TFlops.

... also eine XBox Series S. Mit V-Cache sollte sogar die verfügbare Bandbreite in etwa passen.

basix

2021-09-20, 13:47:47

sollte nicht bereits die zusätzliche Bandbreite durch den V-Cache für eine min. 50% bessere Performance sorgen, selbst mit 10CU und 2GHz?

Wenn bandbreitenlimitiert ist das möglich, ja. Vega 8 ist je nach Messung stark bandbreitenlimitiert. Es gab irgendwo einen Test mit 12W vs. 25W (CB User Test (https://www.computerbase.de/2020-07/lenovo-ideapad-5-amd-ryzen-7-4800u-test/)), wo man trotz deutlich reduziertem CPU und GPU Takt fast die gleiche Performance erhielt. Takt der GPU war glaube ich so 1.75 GHz vs. 1.4 GHz. Andere Tests (z.B. bei Anandtech (https://www.anandtech.com/show/16446/amd-ryzen-9-5980hs-cezanne-review-ryzen-5000-mobile-tested/11)) mit 35W SKus haben diesen Effekt aber nicht gezeigt, das kann aber auch an den langsameren Timings des LPDDR4X liegen.

Wie sich das bei Rembrandt mit der 12 CU RDNA2 GPU zusammen mit LPDDR5 mit bis zu 6400 MT/s verhält werden wir sehen. Theoretisch ist die neue GPU in etwa 2x so schnell wie Vega 8 bei identischen Taktraten. Das würde vermutlich ziemlich gut mit der gesteigerten Bandbreite einhergehen. Bei normalem DDR5 sollt Rembrandt nur bis 5200 MT/s spezifiziert sein. Mal schauen, ob und wann etwas limitiert. 32 MByte Infinity Cache wäre für ein Notebook genug, ergäbe bei 1080p nämlich in etwa eine Verdopplung der effektiven Bandbreite. 64 MByte mehr als genug, dann ca. 3x effektive Bandbreite (ergäbe bei DDR5-5200 eine effektive Bandbreite von ~250 GByte/s). Ein 64 MByte Slice V-Cache würde fast wie die Faust aufs Auge passen.

Sunrise

2021-09-20, 14:03:15

Also laut Gerüchten soll der sub-400$ Markt mittelfristig nicht mehr mit dGPUs bedient werden, bzw nicht mit dGPUs aus den dann aktuellen GPU-Generationen. (https://youtu.be/HDnwT5h472c?t=808)

Wäre sicher für sehr viele Leute (mich eingeschlossen) recht bitter. Eventuell könnte man iGPUs ganz gut pushen per größerem Cache, aber da stellt sich dann die Frage, wie teuer diese APUs werden.
Wir steuern auf einen Markt zu, der erhöhte Preise bereits eingepreist hat und zugleich es weiterhin nur limitierte Fertigungskapazitäten gibt.

AMD sollte so gut als möglich untenrum alles mit iGPUs bedienen, den oberen Mainstream, High-End und Enthusiast dann mit diskreten Lösungen, welche auch natürlich deutlich teurer werden müssen und kann dann den Bedarf damit etwas abfedern (Margen).

Das würde natürlich sehr gut gehen, wenn die Mehrleistung kommender Generationen einhergeht mit einer Fertigung, die nicht nur auf einen Top-Node schielt, weshalb man jetzt wohl auch MCM ins Spiel bringt. MCM wird nicht billig(er), aber man ist flexibler (Kapazität) und untenrum kann man weiterhin monolitisch fahren.

Platos

2021-09-20, 15:04:10

Klar, aber die Rede war doch von APUs, wo die im Hochpreissegment Sinn machen?
Desktop braucht nur ne Office-IGP, das ist klar. Aber der größere Markt ist nunmal mobile und nicht Desktop.

Ja, grundsätzlich dürfte es die Situation im Laptopmarkt für die meisten nicht verschlechtern, da man GPUs sowieso nicht aufrüsten kann dort. Das stimmt natürlich.

Grundsätzlich bin ich aber auch der Meinung, dass Erweiterbarkeit und Reparierbarkeit im Laptopmarkt extrem schlecht ist und auch immer schlechter wird. Also eig. sollte eher die Entwicklung in die andere Richtung das Bestreben sein m.M.n

Das trifft allerdings auch wirklich nur auf Gaminggrafikkarten zu. Bei Laptops sind oftmals auch dGPUs dabei, die kaum schneller sind als die iGPU und das halte ich sogar für absolut unnötig. Macht das Produkt nutlr teurer und vor allem ist es auch noch eine zusätzliche Ressourcenverschwendung. Als bei dGPUs, die nur leicht besser sind, kann man gerne nur eine iGPU verwenden.

Platos

2021-09-20, 15:12:04

Also laut Gerüchten soll der sub-400$ Markt mittelfristig nicht mehr mit dGPUs bedient werden, bzw nicht mit dGPUs aus den dann aktuellen GPU-Generationen. (https://youtu.be/HDnwT5h472c?t=808)

Wäre sicher für sehr viele Leute (mich eingeschlossen) recht bitter. Eventuell könnte man iGPUs ganz gut pushen per größerem Cache, aber da stellt sich dann die Frage, wie teuer diese APUs werden.

Das wäre wirklich recht bitter. Damit schiessen sich GPU Hersteller inseigene bein, denn dadurch wird PC Gaming (noch) mehr zum teuren Spass und die Konsole wird dann automatisch attraktiver. Damit verlieren sie viele Kunden.

Vor allem müssten die alten Karten auch noch günstiger sein. Eine 3060 müsste dann schliesslich in einem Jahr für 200 Angeboten werden. Ich glaube aber nicht daran...Einerseits fände ich das nicht zwingend schlecht, denn damit wäre es möglich, direkt zum Launch der grossen Karten, auch (preislich) kleine Karten zu verkaufen. Diese müssten dann aber wie gesagt auch wirklich den Preis einer Klasse weiter unten haben (glaube ich nicht drann, siehe 2060). Andererseits ist es auch schlecht, denn die im niedrigeren Preislevel kriegen dann einfach nur "alte Ware" mit alten Features und evtl. dann auch weniger Speicher (weil die neue Gen mehr bietet)?

basix

2021-09-20, 15:32:49

Eine 2060S für 249$ wäre doch eine gute Abrundung gegenüber der 3060. Wird aber wohl echt nicht passieren. Featuretechnisch zum jetzigen Zeitpunkt aber up-to-date.

Ob man direkt vom Hersteller oder ab Gebrauchtmarkt "alte" Ware kaufen kann, ist preislich kein riesiger Unterschied für den Kunden. Für den Hersteller und die Marge allenfalls schon eher. Mit einem alten Chip bleibt man aber beim alten Node und hat keine NRE Kosten fürs Design und Testing. Da kann man mit reduzierter Marge leben und eine 2060S ist ja Salvage von TU106.

Platos

2021-09-20, 16:10:27

Ja, aber wenn man jetzt eine 3070 als 4060 recycliert, dann hätte diese nur 8GB, was dann eben nachteilig wäre. Allerdings habs ja mal Gerüchte, dass es eine 12GB 2060 geben soll. Das wäre Grundsätzlich ok, sofern sie dann auch nur (eher) 229$ kostet (nicht 249).

Aber so oder so, für keinen der beiden Preise wird das passieren, denke ich. Und wenn die Preise in Neukauf so hoch sind, sind leider auch die Gebrauchtpreise Wucher. Aber stimmt schon, Gebraucht kaufen ist im Normalfall eig. immer billiger. Ich habe meine 1070Ti für 150 Euro gekauft. Will ich die doppelte Perfomance pro Euro haben, müsste ich sehr lange warten (ne 4060 wird vermutlich gerade mal die doppelte Perf. bei doppeltem Preis liefern).

Mit gebraucht meine ich natürlich wirklich aus erster Hand und nicht die ganzen Ebay-Reseller, die Ware aufkaufen und zu unattraktiven Preisen wieder verkaufen.

basix

2021-09-20, 17:03:18

Ich hätte eher die 3060 als 4050 reingeschoben und für die 4060 gibt es einen eigenen Chip ;) xx60 wären somit immer aktuell (Performance-Klasse) und Mainstream (xx50er) wären auf der LastGen Architektur.

Und eine 2060 12GB macht einfach keinen Sinn. Eine 2060S benutzt ebenfalls TU106, hat 8 GByte und wäre für das Portfolio am unteren Ende einfach sinnvoller. Von mir aus kann man eine 2060 8GB machen (entweder gleicher Salvage oder reduzierter Takt), damit man genug Abstand zwischen der 3060 hat (ca. +20%).

vinacis_vivids

2021-09-24, 10:59:41

Der_Korken

2021-09-24, 11:27:37

Für Leute, die den Begriff Kohärenz vllt. noch Nachholbedarf haben

scnr, aber wenn ich das hier lese

Ein höherer IF Takt auf 2,4-2,5Ghz+ ist somit auch denkbar, um einerseits Kohärenz von DDR5-4800/5000+ zu erreichen. Andererseits die Cache-Hitrate bei gleicher Größe zu erhöhen.

solltest du vielleicht nochmal nachlesen, was Kohärenz bedeutet: https://de.wikipedia.org/wiki/Cache-Koh%C3%A4renz

Und die Hitrate eines Caches hängt nicht vom Takt oder irgendeiner Busbreite ab, sondern nur von Größe, Assoziativität und Organisation (Verdrängungs- und Prefetching-Strategie).

basix

2021-09-24, 17:04:10

Ich habe mal als aus Spass die Speicherbandbreiten vs. Flops von Tahiti und N31 verglichen. Werte/Spezifikationen für N31 sind die aktuellen aus der Gerüchteküche. Fortführung von diesem Post hier: https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12749703#post12749703

|N31 Full|HD 7970|Faktor
Chip|N31|Tahiti|
SPs|15'360 (120 WGP)|2048|7.5x
Taktrate|2.5 GHz (Annahme)|0.925 GHz|2.7x
Rohleistung |76.8 TFlops|3.79 TFlops|20.3x
Speicherinterface|256bit|384bit|0.67x
Speicherübertragungsrate|16 GT/s|5.5 GT/s|2.91x
Speicherbandbreite|512 GByte/s|264 GByte/s|1.94x
Infinity Cache|512 MByte|n.a.|
Infinity Cache Hitrate @ 4K|~0.81|n.a.|
Effektive Bandbreite @ 4K|~2700 GByte/s|264 GByte/s|~10.2x
Relative TFlops / Effektive Bandbreite @ 4K|1.99|1.0|1.99x

Fun Facts:

RDNA3 im Maximalausbau hätte somit nur gerade mal ein verdoppeltes Flops/Byte Verhältnis wie Ur-GCN. Das mit deutlich grösseren L1/L2 Caches, Color Compression usw.
Gerade mal verdoppelte Speicherbandbreite in 11 Jahren
Bei der selben Zeitdifferenz von der HD7970 aus gesehen (z.B. GeForce 3 oder Radeon 8500) liegt das Verhältnis der Speicherbandbreite bei ~30x (ca. 8 GB/s). Bei N31 ist selbst die durch den Infinity-Cache gesteigerte effektive Bandbreite mit einem Faktor von 10x deutlich geringer.
Noch extremer die Rechenleistung: 8.8 GFlops einer 8500 (https://www.forum-3dcenter.org/vbulletin/archive/index.php/t-387568.html) (welche eigentlich keine FP32 Flops sind, da 16bit Fixed Point) verglichen mit 3790 GFlops einer 7970 sind ein Faktor von 430x. Da ist N31 vs. Tahiti mit Faktor 20x deutlich bescheidener ausgefallen ;)

Der_Korken

2021-09-24, 18:23:59

Fun Facts:

RDNA3 im Maximalausbau hätte somit nur gerade mal ein verdoppeltes Flops/Byte Verhältnis wie Ur-GCN. Das mit deutlich grösseren L1/L2 Caches, Color Compression usw.
Gerade mal verdoppelte Speicherbandbreite in 11 Jahren
Bei der selben Zeitdifferenz von der HD7970 aus gesehen (z.B. GeForce 3 oder Radeon 8500) liegt das Verhältnis der Speicherbandbreite bei ~30x (ca. 8 GB/s). Bei N31 ist selbst die durch den Infinity-Cache gesteigerte effektive Bandbreite mit einem Faktor von 10x deutlich geringer.
Noch extremer die Rechenleistung: 8.8 GFlops einer 8500 (https://www.forum-3dcenter.org/vbulletin/archive/index.php/t-387568.html) (welche eigentlich keine FP32 Flops sind, da 16bit Fixed Point) verglichen mit 3790 GFlops einer 7970 sind ein Faktor von 430x. Da ist N31 vs. Tahiti mit Faktor 20x deutlich bescheidener ausgefallen ;)

Schon interessant, wie "wenig" sich das letzte Jahrzehnt getan hat im Vergleich zu dem davor. Du könntest vielleicht noch hinzufügen wie stark sich die Fertigung verbessert hat (150nm -> 28nm müssten 5 Fullnodes sein, 28nm -> 5nm dagegen nur 2,5 oder 3 (je nachdem ob man 5 als vollen Sprung zählt) und wie sich der Verbrauch verändert hat (Radeon 8500 dürfte max. 25W gehabt haben, die 7970 so um die 200W und N31 weiß man noch nicht so genau, aber es wird wohl nicht nochmal Faktor 8 sein).

Orko

2021-09-24, 21:56:58

Für Leute, die den Begriff Kohärenz vllt. noch Nachholbedarf haben:
Bei RDNA3 wird auch die Entwicklung der Infinity Fabric interessant.

https://tech4gamers.com/amd-extends-infinity-fabric-bus-technology-to-enable-coherence-between-cpus-and-gpus/

https://abload.de/img/amd-infinity-fabric-bfckjz.jpg

Auf der rechten Slide sieht man, dass bei Kohärenz auf Cache (Speicherebene) die Codes & Befehle auf der CPU sofort ohne Umwege auf der GPU ausgeführt werden können und somit um ein vielfache beschleunigt sind.

https://abload.de/img/amd-infinity-fabric-bbtj9c.jpg

Die Vereinfachung der Codes wird absolut genial sein :eek:

Mal schauen wie weit RDNA3 sein wird, natürlich braucht es dazu mind. Zen3, am besten natürlich +V-Cache.

Die letzte Entwicklung des Infinity Fabric ist bei ~ 2Ghz für Zen3 & RDNA2 und 512bit Breite.
Allerdings ist die letzte Entwicklung noch mit 12nm I/O gemacht worden.

Bei RDNA2 taktet der die Fabric ja von 1,4Ghz base bis 1,94Ghz boost.

Bei RDNA3 kann es sein, dass der IF gen3 I/O auf 7nm schrumpft und 1024bit Breite erlaubt. Ein höherer IF Takt auf 2,4-2,5Ghz+ ist somit auch denkbar, um einerseits Kohärenz von DDR5-4800/5000+ zu erreichen. Andererseits die Cache-Hitrate bei gleicher Größe zu erhöhen. Das spart Fläche und die Grafikkarten bleiben für den Gamer bezahlbar.

Insgesamt ist RDNA3 hochinteressant :eek:

1) Kohärenz

In deinem Post #957 beziehst du dich auf Kohärenz im Sinne von Cache-Kohärenz und erkläst das folgendermaßen:

Der L3 Cache sowohl auf der GPU (IF$) als auch auf der CPU(V-Cache) kann zusammengeführt werden und die Hitrate in allen Auflösungen deswegen erhöhen. Kohärenz bedeutet, dass der Cache die gleichen Daten hat. Das vereinfacht und kürzt den Datentransfer zwischen CPU und GPU und spart Energie.

In deinem Post #990 geht es um "Memory Coherency" wie auf den verlinkten Folien deutlich zu sehen ist. Also dass CPU(s) und GPU(s) gegenseitig direkt auf den jeweiligen anderen Arbeitsspeicher zugreifen können (vereinfacht ausgedrückt). Mit Daten-Caches (wie z.B. Infinity-Cache oder V-Cache) hat das erst mal nichts zu tun.

Mein Eindruck:
Du verquirlst gedanklich unter dem Stichwort Kohärenz einige Themen die an sich separat stehen, und bezeichnest dies dann auch noch ironischerweise passend mit "Kohärenz auf Cache (Speicherebene)".

2) Memory Kohärenz

In deinem Post #957 geht es um Memory Kohärenz.

In dem verlinkten tech4gamers Artikel wird Bezug genommen auf EPYC-Prozessoren und Instinct-Beschleuniger. Von RDNA3 steht in dem Artikel (im Gegensatz zu deinem Post) kein einziges Wort.

Mein Eindruck:
Es geht im tech4gamers Artikel um Rechenzentren und Supercomputer (EPYC und CDNAx), nicht um Consumer (Ryzen / Threadripper und RDNAx). Du verquirst auch hier gedanklich eher unterschiedliche Themen.

Meiner Meinung nach macht das Ausschöpfen der leichteren Programmierung durch diese Memory Kohärenz nur dann Sinn, wenn CPU(s) und GPU(s) ausschließlich von AMD kommen, also wenn eine "übliche umfangreichere allgemeinere" Programmierung deshalb entfallen kann. Für Consumer Graphikkarten ist dies nicht der Fall. Für Rechenzentren / Supercomputer / Konsolen-Chips schon.

3) Beschleunigung

Deine Aussage: "... die Codes & Befehle auf der CPU sofort ohne Umwege auf der GPU ausgeführt werden können und somit um ein vielfache beschleunigt sind."

In den verlinkten Folien steht dass das Programmieren (Programm Code schreiben) durch Memory Kohärenz deutlich vereinfacht wird. Davon dass diese Programmcodes und Befehle deutlich schneller ausgeführt werden, steht da nichts. Diese Interpretation wird von dir aus der Luft gegriffen.

4) Wirrwarr

Deine Aussage: "Bei RDNA3 kann es sein, dass der IF gen3 I/O auf 7nm schrumpft und 1024bit Breite erlaubt. Ein höherer IF Takt auf 2,4-2,5Ghz+ ist somit auch denkbar, um einerseits Kohärenz von DDR5-4800/5000+ zu erreichen. Andererseits die Cache-Hitrate bei gleicher Größe zu erhöhen. Das spart Fläche und die Grafikkarten bleiben für den Gamer bezahlbar."

IF Takt und CPU-RAM Takt u.a. bei Ryzen CPUs sind miteinander verknüpft.

Die Punkte Taktrate, Cache-Hitrate, und Kohärenz (sowohl in deiner Auslegung Cache-Kohärenz, also auch in Memory Kohärenz) haben an sich primär nichts miteinander zu tun.

Auch die IF Taktraten innerhalb einer Ryzen-CPU und die innerhalb einer RDNA-Graphikkarte haben wenig miteinander zu tun, wenn der Link zwischen diesen z.B. per IF-over-PCIe erfolgt.

Aussagen und Schlussfolgerungen die du aus einer gedanklichen Vermengung solcher Punkte zu ziehen versuchst sind sinnlos.

---

Mein persönlicher Eindruck nach Lesen von etlichen deiner Posts:

Du argumentierst mit viel Enthusiasmus. Aber leider auch mit viel Halbwissen welches du dann gerne mit viel Phantasie zu deinem eigenen Weltbild zusammensetzt. Wobei es diesem deinem Weltbild dann gerne an Kohärenz mit der Realität mangelt.

Typisches Merkmale sind:
- Themen die an sich separat stehen werden von dir gerne zu einem Eintopf verarbeitet
Beispiel 1: Daten Cache + Level Stufen in der Brach Prediction -> Brach Prediction Cache
Beispiel 2: Cache Kohärenz und Memory Kohärenz -> Kohärenz auf Cache (Speicherebene)
- Du argumentiert meistens auf dem Level von technischen Schlagworten, aber nicht auf dem Level von tiefergreifenden Erklärungen oder gar Verständnis

Für ein reines Trollen ist der Aufwand den du da treibst viel zu hoch.
Das möchte ich also explizit nicht unterstellen.

Deine Posts lesen sich auf den ersten Blick beeindruckend (Tech-Blabla).

Auf den zweiten Blick erzeugen diese phantastischen Logik-Chimären zumindest bei mir für Heiterkeit und ungehemmte Lachanfälle. Manchmal regen sie mich auch zum Nachdenken an (Was hat er/sie da nur genau gemeint? Macht das überhaupt Sinn so? Macht das irgendwie anders Sinn?)

Also - Bitte von meiner Kritik nicht beeindrucken lassen & munter weiter posten.

edit:Typos

vinacis_vivids

2021-09-24, 22:36:48

IF-Cache und Hitrate:
Ähäm, die Hitrate des IF-Cache lässt sich sehr wohl beeinflussen. Derzeit ist die Clock-Domain bei 1.4-1.94Ghz. Höherer Takt bedeutet auch höhere discard rate (Verwerfung aus dem Cache) und führt mit höherer Wahrscheinlichkeit zu Treffer.

Kohärenz:
Kohärenz zwischen V-Cache (CPU) und IF-Cache (GPU) ist wesentlich für die Entlastung der GPU. Warum? Die (Vor) Berechnung kann nahezu komplett(und parallel) von der CPU übernommen werden un den kohärenten Cache bereit gestellt werden. Die GPU braucht selbst nichts mehr übersetzen und kann gleich auf dem IF-Cache zugreifen und rendering betreiben. Spart alles Zeit.

Warum bringt Kohärenz was?
Das wird fürs Ray-Tracing besonders interessant, weil AMD da keine extra Einheiten braucht, sondern es in die CUs integriert. Und da die Ray-Tracing Daten im IF-Cache erzeugt, kopiert und gelöscht werden, kann das auch die CPU direkt übernehmen.
Das spart ne Menge Zeit/Energie für die GPU, die dann noch mehr Drawcalls machen kann.

In höheren Auflösungen brauchst du auch eine höhere CPU-Auslastung, um aus mGPU System mehr rauszuholen.

Mit das Interessanteste wird sein, die Sprungvorhersage der CPU bei den Drawcalls der GPU mizunutzen.

Was derzeit bei RDNA2 mit dem auf Nvidia optimierten RT-Code passiert ist unbefriedigend. Die RDNA2-GPU ist dauernd beschäftigt irgendwelche RT-Variablen in den IF-Cache zu schreiben und lässt sich vom wesentlichen ablenken. Das geht viel besser als was derzeit abgeht.