AMD/ATI - Navi 1X (7nm, RDNA1, 2019) & Navi 2X (7nm, RDNA2, 2020) [Archiv] - Seite 54

ianm

2020-10-05, 21:07:44

Never erver. Das "filing Date" (Anmeldetag) liegt am 29.09.2020. Viel zu spät.
Niemand der bei Verstand ist hat so eine Technologie in der Schublade liegen und entwickelt auf dieser Basis, ohne es !!vor!! dem Start der Arbeiten abzusichern.
Ich stelle mir vor, wenn ein Spion das Ding einfach nur einen Tag vorher dingfest macht und AMD dann Millionen für die Lizenzen zahlen muss.... never ever...
Es wird zu 99,99% kein Infinity Cache geben.

Edit: alles zurück... ich habe den Trademark überlesen.. zweifel das trotzdem an, da selbst der Trademark sehr wichtig in diesem Geschäft ist.
Das ist keine Patentanmeldung. Da wird nur der Name trademarked.

Edit: Nun ja, es wird wohl kaum ein Mitbewerber den Namen AMD Infinity Cache nutzen. Im Videogamebereich sind solche Trademarks kurz vor Release auch nicht ungewöhnlich.

Die Gerüchte spitzen sich zu.

Linmoum

2020-10-05, 21:08:24

Du verwechselst gerade Patent und Marke, das oben verlinkte ist letzteres. Da geht es schlicht nur um eine Wortmarke, das Ding kann man auch immer noch Hans-August nennen.

tEd

2020-10-05, 21:23:21

Vorallem wurden Storemi und CDNA auch erst im September "getrademarked"

https://trademarks.justia.com/owners/advanced-micro-devices-inc-2465522/page3

Unicous

2020-10-05, 21:37:01

Adam D.

2020-10-05, 22:21:38

https://videocardz.com/newz/amd-infinity-cache-coming-to-big-navi

Auch von der Seite aus bestätigt, wenn auch mit großem Fragezeichen zum Namen. Bin wirklich sehr gespannt, was AMD da aus dem Hut zaubert. Vielleicht reicht es ja am Ende doch für ne handfeste Überraschung.

Unicous

2020-10-05, 22:35:18

Bestätigt? Huh?:confused:

Da wird gar nichts bestätigt, sondern nur der Tweet und der Eintrag als Quellen genannt.

Linmoum

2020-10-05, 22:37:56

Bestätigt ist relativ, aber:
We have independently confirmed that Big Navi will feature a special cache connected to the memory subsystem.

Ansonsten:

Es braucht jetzt nur zwei Dinge, nachdem Jensen die Bombe hat platzen lassen und die miese Verfügbarkeit für 3080/3090 bis ins Jahr 2021 quasi bestätigt hat:

- Ähnlich gute Performance
- Halbwegs vernünftige Verfügbarkeit

Letzteres wird deutlich wichtiger, wenn Nvidia noch Monate kaum liefern kann. TSMC dürfte weniger das Problem sein und nach Apples (Teil-)Weggang auf N5 und Huaweis Abgang dürften die Chancen zumindest nicht gesunken sein, dass es besser wird. Sie müssen nur aus ihrem Zen2-Fehler gelernt haben, wo sie zugeben mussten, die Nachfrage unterschätzt zu haben. Wenn sie das diesmal nicht tun, dann wird das was.

Platos

2020-10-05, 22:45:55

Dieser Cache ist dann ja im Grunde ein L4 Cache, oder ?

Zergra

2020-10-05, 22:55:06

Ich erwarte bei Navi 21 keine besonders gute Verfügbarkeit, die Konsolen und Zen3 haben da erstmal eine höhere Prio. Ja es gibt mehre Kapazitäten, man muss das ganze aber eben auch bedienen. Die Grafikkarten sind dann am Ende eher unwichtiger.

2020-10-06, 00:04:28

Ich wette es hat etwas mit CDNA zu tun. Wollte ich schon vorhin schreiben. Dem RGT-Typ wurde der Name zugespielt und er hat den Rest darum dann konstruiert und RDNA zugeschrieben.

AMD nutzt "Infinity" zunehmend im professionellen Bereich, CDNA wird als "Infinity Architecture" bezeichnet besonders im Verbund mit den Epyc-Prozessoren:
https://hexus.net/media/uploaded/2020/3/3221a913-91b3-4733-90ba-3b35c108caa3.jpg

edit: Something, something, cache coherency, Infinity Cache...
Wäre dann Infinity Cache ein Cache der über Infinity Fabric angebunden ist?
Wäre es möglich, dass die GPU die Caches der CPU nutzt?
Da war doch so ein Patent vor paar Wochen, wo Stand, dass eine Einheit den Cache der anderen Einheit nutzen kann(?), da gingen alle von L1 innerhalb der GPU aus, aber wenn es so ist, wie die Zen DIEs miteinander kommunizieren, dann könnte es GPU<->CPU sein...

Ja, ich lehne mich total aus dem Fenster :P

nairune

2020-10-06, 00:13:29

Und das soll was bringen?
Ein Cache ist dazu da, die Daten schnell und energieschonend vorzuhalten. Von der CPU ist es physisch super weit weg, das ist weder schnell noch energieeffizient. Dann kannst auch gleich aus dem RAM laden.

pixeljetstream

2020-10-06, 00:56:20

Dieser Cache ist dann ja im Grunde ein L4 Cache, oder ?
NV/AMD GPUs haben auch noch keinen L3.

Platos

2020-10-06, 01:42:43

NV/AMD GPUs haben auch noch keinen L3.

Ups, dann meinte ich wohl ein L3 Cache. Aber dennoch, kann ein simpler 128MB Cache das Bandbreitenproblem einfach so lösen? Kann ich mir irgendwie nicht vorstellen.

N0Thing

2020-10-06, 01:52:36

Genau das kann ich mir auch nicht vorstellen. Wenn es so einfach wäre und man "nur" einen großen Cache in die GPU integrieren müsste, wäre das auch für Intel und Nvidia interessant. Von daher wird es entweder keinen großen Cache auf dem GPU-Die geben, oder es ist ein Tradeoff, bei dem sich AMD im Gegensatz zur Konkurrenz in Verbindung mit der eigenen Architektur einen größeren Vorteil verspricht als ohne. Da die Special-Sauce-Dinge von Vega nicht so der Bringer waren, bin ich da immer noch ziemlich skeptisch.
Mit HBM hätte man eine Technik, die zwar beim zusammenfügen der Grafikkarten-Komponenten größere Kosten verursacht, aber ansonsten Potential für viel Bandbreite und geringere Leistungsaufnahme für das Gesamtkonstrukt verspricht. Ein großer Cache auf dem Die erhöht ebenfalls die Kosten für die Produktion eben dieses GPU-Dies. Da muss AMD schon ziemlich genau und passend in der Vergangenheit kalkuliert haben, damit sich dieser on-chip-cache am Ende auszahlt.

ianm

2020-10-06, 02:39:54

CGIhOnt7F6s

https://abload.de/img/bokze.jpg

RDNA1 already does have shared L1 Cache though from what I can tell.

https://www.amd.com/system/files/documents/rdna-whitepaper.pdf

"a shared graphics L1 cache that serves a group of dual compute units and pixel pipelines. This arrangement reduces the pressure on the globally shared L2 cache, which is still closely associated with the memory controllers."

https://www.reddit.com/r/Amd/comments/j5jazk/amd_infinity_cache_is_real/

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

https://abload.de/img/bndiefyjh1.jpg

amdfanuwe

2020-10-06, 02:50:54

kann ein simpler 128MB Cache das Bandbreitenproblem einfach so lösen?
Ja. Es werden Daten aus dem RAM gelesen, neue Daten berechnet, im RAM abgelegt und später wieder gelesen.
Wenn die zu schreibenden Daten in einem "Cache" abgefangen werden weil sie eh später wieder verworfen werden spart das eine Menge Bandbreite ein.
Den langsamen RAM braucht man dann nur noch um die vom Programmierer vorgegebenen Daten ( Texturen, Geometriemodelle, Programmcode etc.) vorzuhalten.

Hatten wir schon mal vor 3 Wochen.

Muß ja auch kein On Chip Cache sein. Ein schnell angebunderner RAM Chip auf dem Package könnte da auch schon einiges bewirken. Für ein paar Hundert MByte muß es ja kein HBM sein.

Eldoran

2020-10-06, 03:51:27

Ein Grund für Cache statt RAM könnte auch sein, dass es weniger Energie kostet (die Latenz ist bei GPUs weniger interessant) Daten aus dem Cache zu lesen als von externen Speicherchips.

Unicous

2020-10-06, 04:11:43

jfyi, das gepostete Infinity Cache Bild ist ein schlechter photoshop, bitte nicht auf die Idee kommen, das wäre legit. :wink:

BlacKi

2020-10-06, 05:28:41

Nightspider

2020-10-06, 06:21:31

Die PS4 hatte aber auch 2,5x mehr Speicherbandbreite als die Xbox One.

So gravierend ist der Unterschied in der Bandbreite zwischen Ampere und Big Navi aber nicht.

Dazu kommt das L1 und L2 auch schon größer sein könnten.

Und neben 128 und 256 gingen auch 192 und andere Größen.

RitterRost

2020-10-06, 07:58:08

https://abload.de/img/bndiefyjh1.jpg

Vielleicht ist es ja doch ein (nahezu) quadratischer N21 mit HBM daneben - mit aufgefüllten Lücken, die die Wärmeleitpaste verdeckt...

dargo

2020-10-06, 07:58:25

basix

2020-10-06, 08:08:43

Vielleicht ist es ja doch ein (nahezu) quadratischer N21 mit HBM daneben - mit aufgefüllten Lücken, die die Wärmeleitpaste verdeckt...

Sehr unwahrscheinlich bei den Abmassen, welche Coreteks behauptet. 18.5x26mm --> HBM2 ist 7.8x11.9mm --> passt nicht

Dann sind es eher 2x 40 CU Die als dass dort HBM-Stacks verbaut wären :D

RDNA1 already does have shared L1 Cache though from what I can tell.

https://www.amd.com/system/files/documents/rdna-whitepaper.pdf

"a shared graphics L1 cache that serves a group of dual compute units and pixel pipelines. This arrangement reduces the pressure on the globally shared L2 cache, which is still closely associated with the memory controllers."
Das gilt für 2 CUs oder 1 WGP. Das erweiterte L1$-Sharing wäre über vermutlich eine komplette Shader Engine und somit 12-32 CUs.

HOT

2020-10-06, 08:56:19

für ipc könnten 128mb gut sein, aber das, für was wir ein dickes SI benötigen, ist wohl größer als 128mb.

das problem sehe ich genau da wo es schon 2013 lag mit der xbo. https://www.pcgameshardware.de/Xbox-One-Konsolen-232351/News/Xbox-One-32-MiByte-eSRAM-zu-klein-1080p-Sniper-Elite-3-1108861/

4k ist die 4x auflösung von 1080p, genau wie 128mb das vierfache von 32mb ist. zufall?

was ist aber wenn die 32/40cu karte 128mb bekommt(aka 1440p)und die 80cu karte 256mb(aka 4k)?

Darauf bin ich auch schon reingefallen. Das ist kein Framebufferspeicher wie bei der Xbox. Es fehlt ein Baustein zum vollständigen Bild. HBM ist aber raus mit dem Bild, den Quatsch hab eh nie geglaubt, und externe Caches auch. AMD muss irgendwas gemacht haben, dass das effektiv wird. Infinity Architecture ist extrem vielseitig anwendbar, on Chip oder off chip. Kann das was mit Tile based Rendering zutun haben? Hat AMD da vllt. Den letzten Schritt gemacht?

Gipsel

2020-10-06, 08:57:49

NV/AMD GPUs haben auch noch keinen L3.AMD hat aber 3 Cache-Level, nachdem sie mit RDNA die alten L1-Caches praktisch in L0 umbenannt haben und eine zusätzliche Ebene mit dem L1 pro Shader-Array dazwischen gezogen haben (der alte L2 blieb L2). Die Numerierung ist am Ende ja willkürlich.

mksn7

2020-10-06, 09:36:31

https://youtu.be/CGIhOnt7F6s

https://abload.de/img/bokze.jpg

Dieses Paper mit dem shared L1 cache geht ja schon länger rum, aber für mich macht das einfach keinen Sinn. Wenn ein Core daten von einem anderen L1 cache holt, hat das im Vergleich zum L2 die

1. gleiche Bandbreite, da limitiert sicherlich das ganze interconnect zwischen allen CUs. Die injection bandwidth in das interconnect dürfte angepasst sein an die maximale kapazität des interconnects.

2. gleiche Latenz, ob der Zugriff jetzt über das interconnect zum remote L1 oder zu einem L2 cache slice geht dürfte egal sein

3. gleiche/geringere Kapazität, zumindest der L1 in RDNA ist ja nur 4x128kB groß. Das paper scheint allerdings eher von einem L1 im klassischen Stil auszugehen, dann ist es vielleicht Gleischstand.

In den Bildern ist da jeweils die große Wolke als interconnect zwischen CUs und L2s. Aus der high level Sicht ist eine andere CU genausoweit weg wie ein L2 slice, beide hängen an dieser "wolke". Wenn die L1 Inhalte nicht privat sind, warum ist der dann überhaupt nah dran an einer CU? Entweder ist das L1 sharing oder der L2 cache nutzlos.

Edit: Speicherzugriffslatenz dürfte eher steigen, es muss ja erstmal beim remote L1 angefragt werden, und wenn der es nicht hat schickt der ein request zum memory, und dann wird das erst zur anfragenden CU geschickt

Berniyh

2020-10-06, 09:42:47

2. gleiche Latenz, ob der Zugriff jetzt über das interconnect zum remote L1 oder zu einem L2 cache slice geht dürfte egal sein
Wahrscheinlich nicht ganz, denn – sowie ich das verstanden habe – ist der L1 dann ja kategorisiert.
Ob das in der Realität dann auch funktioniert (bzw. ob das überhaupt bei RDNA2 implementiert ist) muss man mal abwarten.

Iscaran

2020-10-06, 09:58:36

Whitepaper Seite 14:
"To efficiently provide data, the RDNA architecture includes three levels of caching – L0 caches within a dual compute unit, a shared L1 cache within an array, and a globally shared L2 cache."

Schaut euch auch das Schaubild auf Seite 17 an (Figure 11)

RDNA1 hat also einen minicache (L0) pro WGP
einen bereits jetzt gesharten Cache (L1) in jedem Shader Array
Sowie den über alle Shader Engines ! gesharten L2 Cache.

Wenn ich ehrlich bin glaube ich fast, das Video bezieht sich ausschliesslich auf die Veränderungen die von GCN/Vega hin zu RDNA1 ! bereits gemacht wurden.

Ansonsten könnte das Video implizieren, daß AMD dies nochmals umstrukturiert.

Ungefähr so:
Der L0 cache ist nicht mehr dediziert pro WGP sondern wird nun mit dem L1 zusammengetan und vermutlich über einen kompletten Array ODER sogar die komplette "engine" hinweg geshared, gleichzeitig wird aber die Organisation und Cacheabfragestruktur verändert.

mksn7

2020-10-06, 10:44:01

basix

2020-10-06, 11:17:17

Dann sind es eher 2x 40 CU Die als dass dort HBM-Stacks verbaut wären :D

Mir kam hier gerade eine etwas verrückte Idee. Zumindest wäre es eine Erklärung für den grossen Unterschied 80 vs. 40CU bei N21 zu N22 als auch 256b, 384b Konfigurationen von N21.

--> N21 = 2x N22 Die

192b * 2 = 384b. Mit schnellerem Speicher und tieferem GPU Takt allenfalls 384b nicht nötig (und "ungünstige" 12/24 GByte VRAM anstatt 16GByte). Anscheinend wurden 384b Varianten ja getestet, würde ebenfalls für die 2xN22 These sprechen. Eigene Die nur für 384b auflegen macht man eher nicht (simulieren natürlich schon)
Dual Graphics Pipe + eine davon deaktiviert. Beide Chips tragen ja eine, aber nur eine wird benötigt
Dito Dual Multimedia Engine. Eine davon wird teildeaktiviert und anderweitig verwendet.
2x 240mm2 = 480mm2 + Spalt ~ 500-520mm2 --> Coreteks Leak + längliche Rechteckform?

Das hätte grosse Vorteile bezüglich Yield. Man wird praktisch alle Die verwenden können. Einzig das "On-Package Crossfire" wäre noch ein ungelöstes Problem. Aber eine Halo Produkt wäre es auf jeden Fall :D

Complicated

2020-10-06, 11:30:19

Der große Unterschied den die im Paper vorschlagen ist ja, dass eine bestimmte Addresse nur in genau einem L1 gecached werden kann und dass remote L1's nach Daten angefragt werden können. Ich denke, beides ist in RDNA1 nicht der Fall
Genau - hier wird eine Methode beschrieben, wie die Replizierung der selben Inhalte in den L1 Caches bereinigt werden kann und dadurch deutlich mehr L1-Hits erzielt werden, weil mehr unterschiedliche Daten in den Caches liegen, anstatt teilweise mehrfach die selben. Das ergibt allerdings einen weiteren Zugriff in der Hierachie, der dazwischen geschoben wurde (analog CPUs im CCD): L0->L1(lokal)->L1(remote)->L2 (mit RDNA eingeführt und dem Shared L1 Cache)

Dadurch verändert sich die Balance der Zugriffe und der L2 erhält deutlich weniger anfragen, wenn diese im L1(remote) vorliegen.

Es entsteht ein Shared L1 Cache der zusätzlich deutlich effizienter ist und in dem Paper eine Reduzierung der L1 Cache-misses um 80% beschreibt. Dadurch weniger L2-Zugriffe.

Iscaran

2020-10-06, 11:32:59

Mir kam hier gerade eine etwas verrückte Idee. Zumindest wäre es eine Erklärung für den grossen Unterschied 80 vs. 40CU bei N21 zu N22 als auch 256b, 384b Konfigurationen von N21.

--> N21 = 2x N22 Die

Das wäre doch gemeinhin das was man zuvor als "Chiplet"-Design => kommt erst mit RDNA 3 abgetan hat (und was ich auch schon spekuliert hatte das man ja z.B. 2x40 CUs mit "je 256 bit" anbinden könnte oder sowas in der Art).

Berniyh

2020-10-06, 11:44:04

Mir kam hier gerade eine etwas verrückte Idee. Zumindest wäre es eine Erklärung für den grossen Unterschied 80 vs. 40CU bei N21 zu N22 als auch 256b, 384b Konfigurationen von N21.

--> N21 = 2x N22 Die

192b * 2 = 384b. Mit schnellerem Speicher und tieferem GPU Takt allenfalls 384b nicht nötig (und "ungünstige" 12/24 GByte VRAM anstatt 16GByte). Anscheinend wurden 384b Varianten ja getestet, würde ebenfalls für die 2xN22 These sprechen. Eigene Die nur für 384b auflegen macht man eher nicht (simulieren natürlich schon)
Dual Graphics Pipe + eine davon deaktiviert. Beide Chips tragen ja eine, aber nur eine wird benötigt
Dito Dual Multimedia Engine. Eine davon wird teildeaktiviert und anderweitig verwendet.
2x 240mm2 = 480mm2 + Spalt ~ 500-520mm2 --> Coreteks Leak + längliche Rechteckform?

Das hätte grosse Vorteile bezüglich Yield. Man wird praktisch alle Die verwenden können. Einzig das "On-Package Crossfire" wäre noch ein ungelöstes Problem. Aber eine Halo Produkt wäre es auf jeden Fall :D
Kann ich mir nicht vorstellen. In dem Fall würde man dennoch die max. mögliche Konfiguration in der FW angeben, so wie ja z.B. auch bei Navi 21 Lite (obwohl ja die XBox nur mit 52 CU ausgeliefertwird).
Und bezüglich der beiden Multimedia Engines von Navi 21: diese sind angeblich asymmetrisch aufgebaut, d.h. die eine unterstützt weniger Codecs (und ist offenbar mehr für Encoding als Decoding ausgelegt).

why_me

2020-10-06, 11:57:02

Dieses Paper mit dem shared L1 cache geht ja schon länger rum, aber für mich macht das einfach keinen Sinn. Wenn ein Core daten von einem anderen L1 cache holt, hat das im Vergleich zum L2 die

Ersetze in dem Vortrag/Paper mal L1 mit L0 und L2 mit L1 für RDNA1 :wink:

Screemer

2020-10-06, 11:58:20

Hast du nicht weil l0 im Fall von rdna1 nicht wie im paper organisiert ist.

mboeller

2020-10-06, 12:24:10

Mir kam hier gerade eine etwas verrückte Idee. Zumindest wäre es eine Erklärung für den grossen Unterschied 80 vs. 40CU bei N21 zu N22 als auch 256b, 384b Konfigurationen von N21.

--> N21 = 2x N22 Die

:)

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12442754&postcount=12786

wobei ich das erweiterte HBM-Interface (incl. Infinity Cache) auch als Brücke zw. den Chiplet gesehen habe, so dass 1 Chiplet auf die volle Bandbreite zugreifen könnte. "Nur" die höhere Latenz würde man "verstecken" müssen.

basix

2020-10-06, 12:28:51

Das wäre doch gemeinhin das was man zuvor als "Chiplet"-Design => kommt erst mit RDNA 3 abgetan hat (und was ich auch schon spekuliert hatte das man ja z.B. 2x40 CUs mit "je 256 bit" anbinden könnte oder sowas in der Art).

Jein. Es wäre eher ein MCM Design als Chiplets (siehe Zen 1 zu Zen 2). Beide Chips würden ja alle Funktionen tragen, bei Chiplets wird die Funktionalität auf verschiedene Chips aufgeteilt. MCD und GCD von RDNA3 wäre dann einfach der nächste konsequente Schritt.

Kann ich mir nicht vorstellen. In dem Fall würde man dennoch die max. mögliche Konfiguration in der FW angeben, so wie ja z.B. auch bei Navi 21 Lite (obwohl ja die XBox nur mit 52 CU ausgeliefertwird).
Und bezüglich der beiden Multimedia Engines von Navi 21: diese sind angeblich asymmetrisch aufgebaut, d.h. die eine unterstützt weniger Codecs (und ist offenbar mehr für Encoding als Decoding ausgelegt).
Vielleicht kann/will man gar nicht alles gleichzeitig nutzen? Ein Die könnte so eine Art "Master" sein und der Slave unterstützt nicht alles (oder ist entsprechend salvaged und 2x "Full Die" ist nie geplant). Dual Pipe Command Processor, Dual VCN, 2x SDMA Engines. Alles doppelt und man hat sich bei N21 ja schon gefragt, wieso das nun doppelt ist. xGMI wird nur beim Dual Die benötigt, deswegen taucht es bei N22 nicht auf. Wäre zudem eine weitere Erklärung, warum N22 und N21 mehr oder minder gleichzeitig kommen werden (ist zumindest mein Informationsstand)

:)

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12442754&postcount=12786

wobei ich das erweiterte HBM-Interface (incl. Infinity Cache) auch als Brücke zw. den Chiplet gesehen habe, so dass 1 Chiplet auf die volle Bandbreite zugreifen könnte. "Nur" die höhere Latenz würde man "verstecken" müssen.

Das geht in die selbe Richtung, einfach noch mit HBM PHY ;) Wieso nicht, xGMI könnte über die HBM-PHY laufen und es wäre eine Erklärung für die spekulierten HBM-SKUs von RDNA2

Lustigerweise haben wir das beide als verrückt deklariert :D

HOT

2020-10-06, 12:29:08

Das ist nur ein Die... das führt doch wieder zu nix.

basix

2020-10-06, 12:38:24

Das ist nur ein Die... das führt doch wieder zu nix.

Spekulationen führen nie zu etwas ausser zu Unterhaltung ;) Aber wenn du den N21 Die ja kennst, wieso zeigst du ihn uns nicht? :love3:

mksn7

2020-10-06, 12:49:02

Genau - hier wird eine Methode beschrieben, wie die Replizierung der selben Inhalte in den L1 Caches bereinigt werden kann und dadurch deutlich mehr L1-Hits erzielt werden, weil mehr unterschiedliche Daten in den Caches liegen, anstatt teilweise mehrfach die selben. Das ergibt allerdings einen weiteren Zugriff in der Hierachie, der dazwischen geschoben wurde (analog CPUs im CCD): L0->L1(lokal)->L1(remote)->L2 (mit RDNA eingeführt und dem Shared L1 Cache)

Dadurch verändert sich die Balance der Zugriffe und der L2 erhält deutlich weniger anfragen, wenn diese im L1(remote) vorliegen.

Es entsteht ein Shared L1 Cache der zusätzlich deutlich effizienter ist und in dem Paper eine Reduzierung der L1 Cache-misses um 80% beschreibt. Dadurch weniger L2-Zugriffe.

Aber gleichzeitig wird der L1 cache (in seiner bisherigen Rolle) dadurch nutzlos. Eine CU wird ja ganz selten einen hit im eigenen L1 mit niedriger Latenz bekommen, stattdessen ist der überwiegende Teil ein remote L1 hit mit deutlich höherer Latenz. Und all die Zugriffe die vorher schön vom privaten, lokalen L1 abgefangen wurden, werden jetzt plötzlich über das interconnect geroutet. Desto länger ich darüber nachdenke desto mehr klingt das wie ein Desaster.

Dieser shared L1 kann also nicht mehr die Aufgabe der L1 caches wie bisher erfüllen, und erfüllt stattdessen die Aufgabe des L2. Und ich sehe nicht, inwiefern es schneller oder energieeffizienter wäre, die Daten von einem remote L1 zu holen statt aus einem L2. Vielleicht ist es das ja aus Hardwareimplementierungsgründen, aber dann kann man sich den L2 sparen.

Ich denke das paper bezieht sich auf eine "klassische" L2/L1 Architektur wie bei GCN und allen (jüngeren) nvidia Architekturen. Bei RDNA könnte man das vielleicht auf Shader Engine Ebene (ist das die richtige Bezeichnung? Halt da wo der L1 geteilt ist) implementieren, mit gesharten L0s. Aber auch dann kann man sich den L1 sparen

prinz_valium_2

2020-10-06, 12:58:22

Schon spannend das wir so wenig wissen diesmal

basix

2020-10-06, 13:00:50

Und noch etwas zur Namensgebung von N21 und N22.

Navy Flounder:
https://www.newworldencyclopedia.org/entry/flounder
https://de.wikipedia.org/wiki/Flunder
not bilaterally symmetrical...
In bilateral symmetry (also called plane symmetry), only one plane (called the sagittal plane) will divide an organism into roughly mirror image halves (with respect to external appearance only). Thus there is approximate reflection symmetry. Often the two halves can meaningfully be referred to as the right and left halves, e.g. in the case of an animal with a main direction of motion in the plane of symmetry.
--> Hälfte eines Ganzen?

Sienna Cichlid:
https://de.wikipedia.org/wiki/Buntbarsche
https://en.wikipedia.org/wiki/Cichlid
Ihre Grundform ist oval, etwas langgestreckt
...
Im Unterschied zu den meisten anderen Fischen haben Buntbarsche auf jeder Kopfseite nur ein Nasenloch. Ihre Seitenlinie ist unterbrochen, ...Division of the lateral line organ into two sections
...
In der Evolutionsbiologie hat die Untersuchung der Cichliden wesentlich zum Verständnis der Mechanismen der Artbildung beigetragen. Die Artenschwärme der Buntbarsche im Victoriasee und ihrer Verwandten in den benachbarten Afrikanischen Großen Seen können als Modell für eine relativ rasche Artenentwicklung betrachtet werden. Zudem sind Buntbarsche bedeutende Forschungsobjekte in der Verhaltensbiologie.

--> Zweigeteilt? Vorspiel für Chiplets? Evolutionsstufe und Analyseobjekt für RDNA3?

Berniyh

2020-10-06, 13:04:02

Und noch etwas zur Namensgebung von N21 und N22.

Navy Flounder:
https://www.newworldencyclopedia.org/entry/flounder

--> Hälfte eines Ganzen?

Sienna Cichlid:
https://de.wikipedia.org/wiki/Buntbarsche
https://en.wikipedia.org/wiki/Cichlid

--> Zweigeteilt? Vorspiel für Chiplets? Evolutionsstufe und Analyseobjekt für RDNA3?
Die Namen werden per Zufallsgenerator erstellt. Da kann man nichts rein interpretieren.

basix

2020-10-06, 13:06:43

Jetzt lass mir doch den Spass :D

Berniyh

2020-10-06, 13:06:56

Vielleicht kann/will man gar nicht alles gleichzeitig nutzen? Ein Die könnte so eine Art "Master" sein und der Slave unterstützt nicht alles (oder ist entsprechend salvaged und 2x "Full Die" ist nie geplant). Dual Pipe Command Processor, Dual VCN, 2x SDMA Engines. Alles doppelt und man hat sich bei N21 ja schon gefragt, wieso das nun doppelt ist. xGMI wird nur beim Dual Die benötigt, deswegen taucht es bei N22 nicht auf. Wäre zudem eine weitere Erklärung, warum N22 und N21 mehr oder minder gleichzeitig kommen werden (ist zumindest mein Informationsstand)
Ja, das kann schon sein, hat man beim Threadripper ja auch gemacht.
Nur … dann würde dennoch auch Navy Flounder xGMI unterstützen.
Und zudem passt es auch von der TCCS her nicht.

Cyberfries

2020-10-06, 13:08:18

N21 = 2x N22 Die

Müssen Chiplets wirklich so oft durchgekaut werden?
Die Konfiguration passt nicht, N22 ist kein halber N21.
Gefühlt täglich kommt ein anderer mit seiner "verrückten" Idee, immer dasselbe.

Und ich sehe nicht, inwiefern es schneller oder energieeffizienter wäre, die Daten von einem remote L1 zu holen statt aus einem L2. n

Sobald der L2 schwieriger erreichbar als der remote-L1 ergibt das Sinn.
Zum Beispiel dann, wenn der L2 nicht mehr auf demselben Die ist

basix

2020-10-06, 13:10:32

Nur … dann würde dennoch auch Navy Flounder xGMI unterstützen.

Muss das so sein? xGMI würde bei N22 nie verwendet werden.

Und zudem passt es auch von der TCCS her nicht.

Wieso nicht? 256b vs. 192b passt doch? Der Vollausbau verwendet die 384b allenfals nie oder die restlichen 128b fallen für xGMI an. Egal, es bleibt spannend ;)

Müssen Chiplets wirklich so oft durchgekaut werden?
Die Konfiguration passt nicht, N22 ist kein halber N21..

Es wären aber keine Chiplets sondern eben MCM. Und dass die Konfiguration nicht passt ist mir bewusst. Da bringe ich aber den Einwand, dass man eben gewisse Chipteile bei diesem Aufbau nicht benötigt oder andersweitig benötigt und somit nicht auf die selbe Weise im Treiber auftauchen. Beweisen kann aktuell niemand das eine oder andere. Aber du darfst es natürlich abkanzeln, ist deine Meinung. Meine ist es nicht ;)

Berniyh

2020-10-06, 13:24:30

Muss das so sein? xGMI würde bei N22 nie verwendet werden.
Ja, aber unterstützen würde der Chip es dennoch.
Wieso nicht? 256b vs. 192b passt doch? Der Vollausbau verwendet die 384b allenfals nie oder die restlichen 128b fallen für xGMI an. Egal, es bleibt spannend ;)
Weil es keinen Sinn macht?
Warum ein 384 Bit Speicherinterface einbauen und dann nicht nutzen?
Selbst wenn der ominöse Cache gut funktioniert, zumindest für die Top-Varianten hätte mehr Speicherbandbreite doch dennoch Vorteile.
Und es würde zudem mehr Spielraum bei der Speicherbestückung geben (also z.B. 20 oder 24 GB Modelle ermöglichen).

Zudem gibt es hier und da auch noch andere Dinge in denen sich die Chips laut Code unterscheiden (hab hier hin und wieder mal was dazu gepostet).

Und mal ganz abgesehen davon: Threadripper hat damals ja auch eher mäßig funktioniert.
Erst mit der vernünftigen Auftrennung bei Zen 2 kam dann der wirklich Durchbruch beim Chiplet Design.
Kann mir einfach nicht vorstellen, dass bei AMDs "großem Comeback" dann so ein halbgarer Ansatz die Basis sein soll.

Chiplets wird man sicher irgendwann umsetzen, aber dann eher Zen 2-Style, d.h. Uncore komplett ausgegliedert und dann noch Compute-Chiplets dran.

Pirx

2020-10-06, 13:31:44

tomshardwares bla zum infinity cache https://www.tomshardware.com/news/amds-infinity-cache-may-solve-big-navis-rumored-mediocre-memory-bandwidth

basix

2020-10-06, 13:49:07

Weil es keinen Sinn macht?
Warum ein 384 Bit Speicherinterface einbauen und dann nicht nutzen?
Selbst wenn der ominöse Cache gut funktioniert, zumindest für die Top-Varianten hätte mehr Speicherbandbreite doch dennoch Vorteile.
Und es würde zudem mehr Spielraum bei der Speicherbestückung geben (also z.B. 20 oder 24 GB Modelle ermöglichen).

Vielleicht geht es gar nicht. Evtl. werden die restlichen 128b für die Chip-to-Chip Kommunikation verwendet (siehe EPYC Socket-to-Socket via PCIe PHY). Und allenfalls sind 24 GByte einfach zu teuer oder die zusätzlich Bandbreite wird nicht benötigt ;) Wer weiss. AMD hätte mit Tonga zumindest einen Präzedenzfall was ungenutzte SI-Ressourcen anbelangt :D

Zudem gibt es hier und da auch noch andere Dinge in denen sich die Chips laut Code unterscheiden (hab hier hin und wieder mal was dazu gepostet).
Das glaube ich dir. Ob das meine These eindeutig widerlegt kann ich aber nicht beurteilen, dazu fehlt mir die Expertise ;)

Chiplets wird man sicher irgendwann umsetzen, aber dann eher Zen 2-Style, d.h. Uncore komplett ausgegliedert und dann noch Compute-Chiplets dran.
Das ist schon so. Ich sähe den 2x N22 Ansatz als Entwicklungsschrit dort hin an.

Um nochmal zu unterstreichen:
Ich will hier keinen 2x N22 erzwingen. Aber in gewisser Weise würde es Sinn ergeben, deswegen finde ich die Idee interessant und man kann darüber diskutieren/spekulieren.

Complicated

2020-10-06, 14:41:05

Aber gleichzeitig wird der L1 cache (in seiner bisherigen Rolle) dadurch nutzlos.
Das wird im Video angesprochen (IPC -5%) und es wird gesagt es wurde gelöst (Seite 14 und 15), jedoch nicht im Details wie - ich denke das wird auch noch eine Weile nicht allzu detailliert bekannt werden. Vielleicht werden am Donnerstag da etwas mehr Informationen Preis gegeben.

Ich denke es steht mit dem neuen Aufbau der Textur-Einheiten im Zusammenhang und den zusätzlich verfügbaren Einheiten für Hybrid-Raytracing. Denn dort muss das ja auch einen Nutzen haben und kann durchaus wohl weiter verwendet werden, auch ohne Raytracing:

Diese "Intersection engine" und "state machine" werden jedenfalls die Details sein, nach denen ich Ausschau halte ;)

BlacKi

2020-10-06, 14:46:43

Schon spannend das wir so wenig wissen diesmal
wir wussten von vega schon 6 monate im vorfeld fast alles wichtige:biggrin:

dargo

2020-10-06, 14:53:27

Raja ist schon länger weg. ;)

Iscaran

2020-10-06, 15:12:10

Interessant THG verlinkt zum Original Paper zu dem Youtube Video mit dem "improved L1 Cache design".
https://adwaitjog.github.io/docs/pdf/sharedl1-pact20.pdf

Das ist bestimmt kein Zufall.

Der entscheidende Unterschied zu RDNA1 wäre also das hier der L1 Cache nochmal so eine Art "micro" Memory Controller (DynEB) bekommt, nebst noch einiger weiterer Details. Siehe Kapitel 4.3 Hardware Overhead im Paper.

Erst dieser erlaubt die IPC Zuwächse und Gesenkte PowerVerbräuche wenn ich das richtig verstehe.

Kap5.4 mit dem DeepLearning verstehe ich aber nicht ganz - untersuchten die da ein Modell von vielen GPU Cores die in einer Art "Mesh" verknüpft sind mit ihrem 28 CU modell ?!?

In 5.5. hingegen beschreiben sie wie sich die Nutzung eines "Cross-Bar" Interconnects anstelle des idealen Meshes auswirkt.

Und auch mit einem derart "vereinfachten" Interconnect sind die IPC-Zuwächse beachtlich:
Außerdem untersuchten Sie auch inwiefern die Sache zu viel-Kernen skaliert und sie finden, daß 56 CUs sogar mehr profitieren als nur 48 CUs oder gar 28 CUs ?
Also gerade für diejenigen Fälle wo man bisher immer ein Problem mit der Skalierung bekam arbeitet der DynEB "Cache" scheinbar extrem gut.

Na, da könnte also wirklich was dran sein an der "Secret Sauce"...

Und die CU parallelen zu real existierenden oder kolportieren GPU Chips sind bestimmt kein Zufall.

Die Arbeitsgruppe hatte eben viele, viele Modelle von GPU Chips durchgerechnet und von diesen wurden dann eben irgendwann die "realen" Chips definiert.

Die Ko-Authoren arbeiten ja auch alle direkt in AMDs Computer Architecture Research Team
https://www.linkedin.com/in/yasuko-eckert-86620546/
https://www.linkedin.com/in/okayiran/
https://www.linkedin.com/in/gabriel-gabe-loh-78ab4459/

Die Gruppe hat auch schon vor EINEM Jahr ein Paper mit nahezu gleichem Inhalt veröffentlicht:
http://okayiran.github.io/docs/pdf/RemoteCore-PACT2019.pdf

Dieselben Leute arbeiten auch am Routing für Chiplets: Zufall ? Eher nicht.
https://ieeexplore.ieee.org/document/8416868

Ich stelle mal die These auf, N21 wird ein erster Testballon für "Chiplets" sein...zumindest für die dafür notwendigen Techniken, aber noch realisiert in einem Monolithischen, oder vielleicht sogar schon MCM-artigen (?) Chip.

2xN22 mit einem Crossbar-Interconnect z.B. ?

Alternativ hat ja in Navi10 der Chip den Aufbau "Shader Engine" => Shader Array => WGPs aus Dual-CUs

Die dual CUs haben den L0 Cache, die WGPs eines Arrays haben EINEN shared L1 Cache
Die Shader Engines der 2 "getrennten" Shader Arrays, verwaltet den L2 Cache.

Was ist nun wenn man die Arrays nun via Crossbar-Interconnect und DynEB "controller" den L1Cache wie beschrieben nutzen lässt. Ggf. könnte man das sogar Shader Engine übergreifend gestalten bei Chips die aus 2 oder mehr SEs bestehen ?

Wenn man damit wirklich so massiv an "bandbreite" sparen kann (effective bandwidth !) dann könnte so eine Organisation, wenn sie denn in der Praxis auch so funktioniert wie im Rechenmodell nicht nur eine natürliche Erklärung für die "nur" 256Bit SI sein, sondern auch passend die +50% P/W erklären (werden direkt im Paper genannt (+49%)) als auch die gesteigerte effektive IPC (+22% oder so).

Kombiniert man das alles nun mit einem 2x40 CU Chip/MCM/Chiplet aus quasi 2 optimierten Navi10 Chips vom Kerndesign her sind das 4 SE ShaderEngines zu je 2 SA ShaderArrays pro SE mit je 5 WGP pro SA zu je 2 CUs pro WGP.

Das erklärt auch den 80/40/32 "leak"....Es sind eigentlich nur 2 "Chips"....ein 40 CU chip und eine 32 CU Chip...

Die 80 ergeben sich dann durch MCM/Chipletisierung whatever aus 2x40 um genau diesen neuen Ansatz zu testen.

Die "Revolution" ist dann eigentlich die, daß das bisher jeder für RDNA3 erwartet hat.

Aber die Zeitskala der Publikationen passt evtl. ganz gut zu einem RDNA2....schliesslich sind die da schon seit Jahren dran...

EDIT: Adaptive Cache Reclustering....das scheint mir das zu sein was hinter DynEB steckt: https://www.freepatentsonline.com/20200293445.pdf
Das Patent ist nun schon 1.5 Jahre offengelegt und damit "aktiv"....das könnte vom Zeitraum her auch schon zu RDNA2 passen.

kabe

2020-10-06, 15:28:12

"a breakthrough gaming architecture" Zitat aus der Ankündigung zur Ankündigung. :eek:

Complicated

2020-10-06, 15:42:45

EDIT: Adaptive Cache Reclustering....das scheint mir das zu sein was hinter DynEB steckt: https://www.freepatentsonline.com/20200293445.pdf
Das Patent ist nun schon 1.5 Jahre offengelegt und damit "aktiv"....das könnte vom Zeitraum her auch schon zu RDNA2 passen.

Screens aus dem Video:
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=71712&d=1601991481

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=71713&d=1601991553

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=71714&d=1601991561

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=71715&d=1601991567

DynEB ist die optimierte Bandbreite laut Berechnung mit Berücksichtigung der Cache Hits

Iscaran

2020-10-06, 15:57:01

DynEB ist die optimierte Bandbreite laut Berechnung mit Berücksichtigung der Cache Hits

Ja - die Authoren bezeichnen damit aber auch ihre Methode der Cache Clusterung.
"4.3 Hardware Overhead
As discussed in Section 3.2 and Section 4.1, our optimized shared L1organization and DynEB do not change the L1 caches or the NoC. We only update the request handling architecture to manage the remote accesses. We synthesized the RTL design of the hardware required for our optimized shared L1 organization using the 65nmTSMC libraries in the Synopsys Design Compiler and estimated the area overhead to be 0.085mm2per core. DynEB leads to an additional area overhead of 0.005mm2per core"

Das ist also offenbar "mehr" als nur die Bezeichnung für die Effective bandwitdht.

X-Bow

2020-10-06, 16:00:00

--> N21 = 2x N22 Die

Rein hypothetische Frage, wäre es im ersten Schritt nicht einfacher aus einem N21 zwei N22 Dies zu machen als anders herum?

Sprich: 2x N22 = N21

Complicated

2020-10-06, 16:14:13

Das ist also offenbar "mehr" als nur die Bezeichnung für die Effective bandwitdht.
Ich sagte nicht es ist "nur die Bezeichnung". Ich sagte da ist die Formel wie sich das zusammensetzt. Alle Faktoren werden in dem Video beschrieben, auch das L1-Clustering wird 5 min vorher beschrieben. Daraus ergibt sich der Faktor Home(Replies) in der Formel. Es ist eben ein dynamischer Wert der vom Workload abhängt, der unterschiedliche Hit-/Miss-Raten hat. Aber offensichtlich wird ausreichend Bandbreite eingespart um mit einem 256-bit Interface klar zu kommen.

Iscaran

2020-10-06, 16:21:11

:up: Ah Check . Hatte deine Aussage dahingehend falsch verstanden.

ianm

2020-10-06, 16:23:26

Rein hypothetische Frage, wäre es im ersten Schritt nicht einfacher aus einem N21 zwei N22 Dies zu machen als anders herum?

Sprich: 2x N22 = N21
Das ist sicher das wo sie mit RDNA3 hin möchten, dann kannst du mehrere Chiplets skalieren. Ähnliches entwickelt Intel mit XE ja auch.

Die Frage ist, ob AMD bei RDNA2 noch einen monolithischen Ansatz verfolgt und mehrere Chips auflegt. Den Gerüchten nach scheint das so zu sein.

Was ich spannend finde, optimistisch auf die Folie gerechnet:
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=71712&d=1601991481

Nehmen wir den Navi10 (5700 XT) 4K Performance Index als Grundlage: 156% @40CU, 225W (wobei ich kaum weniger Performance UV@150W habe)

Idealfall Navi21?: 156% *2 (80CU) *1,22= ~380% PI @~300W (oder etwas weniger)
GeForce RTX 3090 Ampere GA102, 82 SM @ 384 Bit, 24 GB GDDR6X 364% $1499 24. Sept. 2020
GeForce RTX 3080 Ampere GA102, 68 SM @ 320 Bit, 10 GB GDDR6X 325% $699 17. Sept. 2020
Wäre ein Grund warum Nvidia diese Generation bessere Angebote macht?

Iscaran

2020-10-06, 16:28:03

Idealfall Navi21?: 156% *2 (80CU) *1,22= ~380% PI @~300W (oder etwas weniger)

WENN das alles so stimmt und performt - dann müsste das hinkommen. Bzw. Die Taktratensteigerung käme eigentlich auch noch dazu. Die Gerüchte sprechen ja von Navi2x @>2GHz

Und die Skalierung von 40 auf 80 CU ist sicher nicht 2x sonder weniger als das....fragt sich halt wieviel weniger.

ianm

2020-10-06, 16:31:19

Stimmt, Taktraten. Es bleibt auf jeden Fall spannend. Vor allem weil AMD hier wirklich einen interessanten Ansatz entwickelt hat, weg vom reinen mehr an Takt, CUs, Bandbreite etc.

Berniyh

2020-10-06, 16:32:11

Also angenommen Navi 21 käme wirklich in MCM (was ich bezweifle), dann könntet ihr aber wirklich alle eure Leaker in die Tonne kloppen, denn es gab nichts was darauf hingedeutet hätte. :P
Ok, abgesehen davon, dass in manchen Punkten Navi 21 gerade ein doppelter Navi 22 zu sein scheint.

ianm

2020-10-06, 16:36:31

Designed bestimmt als doppelter Navi 22, daher auch die drei bisher genannten Chipgrößen. Chiplets sicher erst mit RDNA3. Und da gibt es dann Gerüchte zu riesigen Caches.

nKJ9amSDIE0

Berniyh

2020-10-06, 16:58:10

"Instant Load Times" als Begriff/Bezeichnung ist ja auch schon totaler Blödsinn. xD

basix

2020-10-06, 17:06:47

Rein hypothetische Frage, wäre es im ersten Schritt nicht einfacher aus einem N21 zwei N22 Dies zu machen als anders herum?

Sprich: 2x N22 = N21

Schwierig zu sagen. Prinzipiell ja, aber du müsstest dennoch Datenleitungen routen und Abstände fürs Dicing vorsehen. Schlussendlich würdest du nicht viel gewinnen, ausser dass allenfalls das Routing noch auf dem selben Silizium passiert.

Etwas ähnliches wird bei der Wafer Scale Engine von Cerebras gemacht (Link (https://www.servethehome.com/cerebras-wafer-scale-engine-ai-chip-is-largest-ever/)). Dort werden einzelne Chips belichtet aber noch auf dem Wafer miteinander verbunden. Damit könnte man aus zwei Chips einen einzelnen zusammenfrickeln.

Also angenommen Navi 21 käme wirklich in MCM (was ich bezweifle), dann könntet ihr aber wirklich alle eure Leaker in die Tonne kloppen, denn es gab nichts was darauf hingedeutet hätte. :P
Ok, abgesehen davon, dass in manchen Punkten Navi 21 gerade ein doppelter Navi 22 zu sein scheint.

Wen interessieren Leaker? Wir sind das 3DC und (Traum)denken uns selbst was aus ;)

Die Leaker stochern bei RDNA2 doch auch alle im dunkeln (selbst die, welche bisher eine relativ gute Trefferqoute hatten). Deswegen glaube ich, dass sehr viele vermeintliche Leaks einfach Falschinformationen sind. Wir glauben an bestimmte Chipgrössen von 240, 340, 427 oder 505mm2. Wer sagt, dass die stimmen? Bei Ampere waren die realen Chipflächen und Transistorzahlen nicht mal nahe an den Spekulationen dran.

HOT

2020-10-06, 18:06:55

2x N2x ist BS, da würd ich gar nicht mit anfangen. Wenn dann wird alles in Chiplets aufgetrennt, aber nicht so. Das ist aber erst was für RDNA4, RDNA3 wird lediglich ein I/O-Chiplet mitbringen.

basix
glaub ich nicht. Am wahrscheinlichsten ist weiterhin 80CUs auf ca. 500mm² und 256Bit GDDR6, nach wie vor. Zusätzlich gibts halt den Inifnity Cache, das Ganze ist KI und RT-fähig und weiteres Unbekanntes. Ob man sich das nicht vorstellen kann oder anderes spielt dabei keine Rolle, das ist nunmal die Gerüchtelage. Klar kann das trotzdem völlig anders sein, war es bei Ampere aber ebenfalls nicht, hier stimmte ja fast alles (bis auf den Coprozessor, was ich von Anfang an für BS gehalten habe i.Ü., genau wie das ganze HBM-Gespinne. Entweder ganz HBM oder gar nicht. Mischformen sind 100% sinnfrei und erst recht nicht wirtschaftlich).

mksn7

2020-10-06, 20:36:43

Wenn man damit wirklich so massiv an "bandbreite" sparen kann (effective bandwidth !) dann könnte so eine Organisation, wenn sie denn in der Praxis auch so funktioniert wie im Rechenmodell nicht nur eine natürliche Erklärung für die "nur" 256Bit SI sein, sondern auch passend die +50% P/W erklären (werden direkt im Paper genannt (+49%)) als auch die gesteigerte effektive IPC (+22% oder so).

Das mag ja aus Performancesicht tatsächlich irgendwie funktionieren, mit mehr Bandbreite und kürzeren Latenzen (was ich mir immer noch nicht vorstellen kann). Aber das wird sicher nicht das Bandbreitenproblem lösen. Die Kapazität wäre nicht oder nicht wesentlich größer als die L2 caches jetzt auch schon. Wie soll da bitte Speicherbandbreite gespart werden?

Man ist sich ja schon nicht sicher ob denn ein 128MB cache ausreichen würde, um genug Bandbreite zu sparen damit ein 256bit Speicherinterface langt. Ein 80x128kb = 10MB (sehr großzüge Abschätzung der L1/L0 Gesamtkapazität) großer cache kann das sicher noch weniger.

basix

2020-10-07, 09:01:36

Das mag ja aus Performancesicht tatsächlich irgendwie funktionieren, mit mehr Bandbreite und kürzeren Latenzen (was ich mir immer noch nicht vorstellen kann). Aber das wird sicher nicht das Bandbreitenproblem lösen. Die Kapazität wäre nicht oder nicht wesentlich größer als die L2 caches jetzt auch schon. Wie soll da bitte Speicherbandbreite gespart werden?

Man ist sich ja schon nicht sicher ob denn ein 128MB cache ausreichen würde, um genug Bandbreite zu sparen damit ein 256bit Speicherinterface langt. Ein 80x128kb = 10MB (sehr großzüge Abschätzung der L1/L0 Gesamtkapazität) großer cache kann das sicher noch weniger.

Im Paper geht es zum Grossteil um Latenzen und IPC. Da mehr Requests über den L1$ abgewickelt können, ergibt das wie im Paper beschrieben einen Netto-Latenzgewinn (28 cycles private, average +54 cycles für shared L1 requests, average 247 cycles für L2 requests) und dazu einen Netto-Bandbreitengewinn.
Aber ich glaube die relevanten Zahlen in dieser Frage sind die L1$ Miss Rate und die L2$+Memory Reply Bandwidth. Ersteres sinkt um ~57% (DynEB) und letzteres im Idealfall um ~40-60% (siehe angehängte Grafiken). Nicht in allen Fällen, aber den meisten.
Also wenn die benötigte L2$ Reply Bandbreite halbiert wird, gehe ich davon aus dass auch Anforderungen an die Off-Chip Bandbreite stark sinken. Wie stark kann ich nicht genau sagen (L2 Bandbreite von Navi 10 ist ~4x wie die Off-Chip Bandbreite).
Jemand mit Ahnung kann hier gerne seine Einschätzung abgeben oder mich korrigieren. Die im Paper simulierte GPU weist deutlich kleinere Caches als RDNA1 auf. Wie sich RDNA also mit den im Paper beschriebenen Methoden verhält, kann ich nur schwer beurteilen.

Note:
Der DynEB-L1$ scheint mehr Performance zu generieren wie ein verdoppelter L1$, was ich ziemlich erstaunlich finde. Damit liesse sich viel flächen- und energiefressender Cache einsparen.
Und gleichzeitig erhält man eine höhere IPC und es kostet praktisch keine zusätzliche Chipfläche. Und obendrauf kommen noch stark erhöhte Datenlokalität sowie L2 / off-chip Bandbreitenreduktion (was bei Chiplets enorm wichtig sein wird).
Das hört sich fast nach "heiligem Gral" an. Einziges Problem: Wieso sind AMD oder Nvidia nicht schon früher auf so eine durchschlagskräftige Lösung gekommen? So extrem exotisch scheint mir ein Shared-L1 nicht zu sein (natürlich, der Teufel liegt im Detail / der Umsetzung).
Der Shared-L1 scheint anhand dem Paper effektiver als die meisten Kompressionstechniken und L2-Caches dieser Welt zu sein. Das Branding mit "Infinity Cache" würde sich hier definitiv anbieten: Unendliche Möglichkeiten :D
...We observe that Shared++ and DynEB improves IPC over Private(2x)by 8% and 4%, respectively. This shows that by enabling a shared L1 organization, we can perform better compared to a system with double the L1 cache resources without the extra cost/overhead of increasing the L1 cache size (84% cache area overhead...

Was mir beim Paper ebenfalls durch den Kopf gegangen ist, ist die Skalierung mit mehr CUs. Umso mehr CUs (und somit Shared-L1), desto grösser sind die Vorteile.
Das könnte eine Erklärung sein, wieso eine 80CU GPU mit z.B. 256bit/16Gbps auskommen kann und eine 40CU GPU 192b/14Gbps benötigt. Die 80 CU Variante hat +52% Bandbreite, aber allenfalls eine erhöhte Bandbreiteneffizienz durch das Mehr an L1$. Der Effekt der erhöhten Effizienz bei mehr CUs scheint mir aber relativ stark (zu stark?).

Wenn man die Konsolen in die Betrachtung miteinzieht, scheint die PS5 einigermassen ins Bild zu passen (~192b für GPU und somit ~336 GByte/s, ~64b für CPU), etwas overengineered bei der Bandbreite.
Die mittlere Bandbreite der XBSX (~500 GByte/s total, ~400 GByte/s für die GPU) liegt im Verhältnis zur Rechenleistung auf ähnlichem Niveau wie die PS5, passt also auch ungefähr - auch wenn es auf den ersten Blick nicht direkt so scheint.
Beide Konsolen wären hinsichtlich Bandbreite etwas overengineered verglichen mit den dGPUs, aber das war bei der PS4 aber auch so und die Jaguar-CPU war viel schwächer als Zen 2 (CPU klaut GPU Bandbreite).

Ist jetzt alles ein bisschen Kaffeesatzleserei, aber die 192b und 256b könnten tatsächlich passen. Und das wäre einfach unglaublich.

Cyberfries

2020-10-07, 09:30:38

In der Nacht gabs widersprüchliche Twitter-Gerüchte.

Videocardz spricht von "Jebaiting", AIB-Quellen würden von BigNavi gegen GA104/3070 sprechen
NVIDIA jebaited AMD.
- Big Navi perf target was GA104.
- NVIDIA upgraded 3080 to GA102
- AMD now targets 3070
- NVIDIA announced Ampere at lower than expected price
- AMD announced Oct 28 event
- NVIDIA postponed the launch to Oct 29

Just what we gathered this week from AIBs

_rogame lehnt das ab und spricht von N22 nahe der 3070 und dass AMD die AIBs trollt.
> AMD now targets 3070

3070 is barely matching a stock 2080 Ti
It seems AMD is keeping Navi21 closer to its chest while trolling AIBs with Navi22
A highly clocked 40CU RDNA2 (Navi22) should land around 3070

Und Avery78 gibt noch etwas konkretere Vorhersagen ab:
These were some of the re-forecasted targets had heard for RDNA2
Navi 23 = ~150W = 2080S +5-10% perf.
Navi 22 = ~225W = 2080Ti ~+15% perf.
Navi 21 = ~275W = 2080Ti. ~+40% perf.
(Pre-PCB build and testing) maybe something changed along the way or AIBs are not seeing the big ones.
Schränkt das aber insofern ein, als dass die N21/N22/N23-Zuordnung nicht stimmen kann/muss.
Er schließt auch nicht aus, dass diese Informationen falsch sind.

why_me

2020-10-07, 09:33:20

@basix: Die 192bit bei N22 sind vermutlich eher der Speichermenge als der Bandbreite geschuldet.

E: Alleine die Annahme, dass 80 CUs nur auf die Performance von 48 SMs der 3070 bzw 68 der 2080 TI kommen sollen, ergibt überhaupt keinen Sinn.

Der_Korken

2020-10-07, 09:38:01

Und Avery78 gibt noch etwas konkretere Vorhersagen ab:
These were some of the re-forecasted targets had heard for RDNA2
Navi 23 = ~150W = 2080S +5-10% perf.
Navi 22 = ~225W = 2080Ti ~+15% perf.
Navi 21 = ~275W = 2080Ti. ~+40% perf.
(Pre-PCB build and testing) maybe something changed along the way or AIBs are not seeing the big ones.
Schränkt das aber insofern ein, als dass die N21/N22/N23-Zuordnung nicht stimmen kann/muss.
Er schließt auch nicht aus, dass diese Informationen falsch sind.

Das passt ja überhaupt nicht zu den bisherigen Gerüchten. N21 wäre damit nur 22% schneller als N22 trotz doppelter CUs und +33% Bandbreite. Der 225W-Chip wäre imho eher ein N21-Salvage und der 150W-Chip erst N22. 2080S+10% ist jetzt nicht so weit von der 2080Ti entfernt und wäre immer noch 40% schneller als die 5700XT. Mehr kann man von einem 40CU-Chip nun wirklich nicht erwarten.

Linmoum

2020-10-07, 09:39:08

Videocardz hat nicht Unrecht, whycry verwechselt nur N21 mit N22. Was nicht nur anhand bekannter Spezifikationen wenig logisches Denken erfordert.

Laut Gerüchteküche soll N21 zum Start ja Referenz-only sein und N22 dafür direkt mit Customs starten. Kann sich jeder selbst denken, von was die AiB in dem Fall keine Infos haben.

HOT

2020-10-07, 09:45:09

Da fehlt auch die zweite Salvagestufe. N21 mit 60 CUs und >2,0GHz wäre ca. 20% schneller als N22 mit 40 CUs und 2,5GHz. Das ganze Targeting würde ich als Finte ansehen, um die "Experten"-Gemeinde durcheinanderzubringen. Glatte Fehlinfo.

unl34shed

2020-10-07, 09:56:56

Also wenn die benötigte L2$ Reply Bandbreite halbiert wird, gehe ich davon aus dass auch Anforderungen an die Off-Chip Bandbreite stark sinken. Wie stark kann ich nicht genau sagen (L2 Bandbreite von Navi 10 ist ~4x wie die Off-Chip Bandbreite).

Ich bezweifle, dass es Auswirkungen auf die Memory Bandwidth haben wirs. Bei N10 ist der L1 ein write through Cache, daher muss der L2 alle Daten vorhalten, die im L1 geladen sind. Dadurch dass es weniger duplicates gibt, sparst du dir Bandbreite zum L1, die Daten werden nur ein mal für alle SAs gelesen und nicht mehrmals für die einzelnen SAs/L1.

Vom Grafikspeicher brauchst du aber immernoch die gleiche Bandbreite.

Durch den effektiv größeren L1 könnten Daten allerdings länger im L2 vorgehalten werden. Ich kann mir aber nicht vorstellen, dass das viel ausmachen wird.

Berniyh

2020-10-07, 09:59:29

Wie stark kann ich nicht genau sagen (L2 Bandbreite von Navi 10 ist ~4x wie die Off-Chip Bandbreite).
Jemand mit Ahnung kann hier gerne seine Einschätzung abgeben oder mich korrigieren.
Das ist doch das wesentliche Problem: niemand (außerhalb von AMD) kann das wirklich, da das sehr spezifisch für die genaue Umsetzung der GPU sein dürfte.
Zumal die Simulation in dem Beitrag ja auch den Optimalfall betrifft, d.h. in der Realität kann es schon noch mal anders aussehen.

Daher rätseln ja auch alle rum wie das mit dem 256 Bit GDDR6 Interface funktionieren soll.

Es kristallisiert sich langsam heraus, dass AMD mit RDNA2 ziemlich hoch pokert.
Hoffen wir mal, dass es kein Bluff ist.

dargo

2020-10-07, 10:08:30

Das wäre ein Traum. =)
https://twitter.com/Avery78/status/1313614442907623424

Die AIBs können dann gerne mit 300+W kommen um die 3090 anzugreifen.

Edit:
Ups... zu langsam. :redface:

E: Alleine die Annahme, dass 80 CUs nur auf die Performance von 48 SMs der 3070 bzw 68 der 2080 TI kommen sollen, ergibt überhaupt keinen Sinn.
Richtig... mit 80 CUs wäre schon RDNA1 drüber.

Adam D.

2020-10-07, 10:22:24

Das wäre ein Traum. =)
https://twitter.com/Avery78/status/1313614442907623424

Die AIBs können dann gerne mit 300+W kommen um die 3090 anzugreifen.

Edit:
Ups... zu langsam. :redface:

Richtig... mit 80 CUs wäre schon RDNA1 drüber.
Mein "too good to be true"-Seismograph schlägt aus :eek: :D

Wenn N21XT mit 16Gb zwischen 3070 und 3080 landet - das wäre wirklich spitze. Preis wahrscheinlich dann 599$?

Cyberfries

2020-10-07, 10:23:25

Wie gesagt an den Gerüchten passt vieles nicht.
Weder N21 (videocardz) noch N22 (rogame) sollte in der Nähe der 3070 sein.
Und die Abstände bei Avery sind einfach zu klein, Sinn ergibt das nur, wenn die Zuordnung N22,N21salvage,N21 wäre.

Selbst dann sind die Leistungswerte sehr optimistisch.
N21 bei ca. 350%, das ist fast 3090-Niveau, N21salvage bei ca.290%, N22 bei ca. 220%
Die ganzen Werte sind etwa 10% zu hoch, das sollte maximal 320%, 260%, 190% sein.

HOT

2020-10-07, 10:27:13

Das sind ja alles nur Einschätzungen, denn kennen kann keiner die Performance. Einen Treiber wird es ja auch noch nicht geben und ein finales BIOS ebenfalls nicht, also jedenfalls nichts, was leaken könnte. Die Boarddesgins werden jetzt in den letzten Zügen liegen.

Berniyh

2020-10-07, 10:30:16

dargo

2020-10-07, 10:33:31

Wie gesagt an den Gerüchten passt vieles nicht.
Weder N21 (videocardz) noch N22 (rogame) sollte in der Nähe der 3070 sein.
Und die Abstände bei Avery sind einfach zu klein, Sinn ergibt das nur, wenn die Zuordnung N22,N21salvage,N21 wäre.

Ihr geht zu sehr auf irgendwelche unwichtigen Bezeichnungen ein. Natürlich gehe ich bei der 225W GPU von einem N21 Salvage aus. Und die 150W GPU dann N22. Warum sollte ein 40 CU RDNA2 225W verballern wenn das schon RDNA1 tut? ;)

Selbst dann sind die Leistungswerte sehr optimistisch.
N21 bei ca. 350%, das ist fast 3090-Niveau, N21salvage bei ca.290%, N22 bei ca. 220%
Die ganzen Werte sind etwa 10% zu hoch, das sollte maximal 320%, 260%, 190% sein.
Ich wüsste nicht was daran zu optimisch wäre. N21 soll 80 CUs haben, GA102 hat 82 CUs. Das ist im Prinzip das Selbe. N21 wird mit höheren Frequenzen kommen (kein riesen Unterschied, ich gehe beim Takt von etwa +8-10% aus). Schon RDNA1 war beim gleichen Takt und gleichen CUs minimal vor Turing (Vergleich allerdings bei 1,5GHz, ergo etwas näher am Sweetspot). Perf/W soll bei RDNA2 gegenüber RDNA1 höher ausfallen als bei Ampere vs. Turing. 10% in die eine oder andere Richtung ist dann imo auch wurscht. Besonders bei den angegebenen Wattagen sofern die überhaupt stimmen.

Iscaran

2020-10-07, 10:34:52

Ich bezweifle, dass es Auswirkungen auf die Memory Bandwidth haben wirs. Bei N10 ist der L1 ein write through Cache, daher muss der L2 alle Daten vorhalten, die im L1 geladen sind. Dadurch dass es weniger duplicates gibt, sparst du dir Bandbreite zum L1, die Daten werden nur ein mal für alle SAs gelesen und nicht mehrmals für die einzelnen SAs/L1.

Vom Grafikspeicher brauchst du aber immernoch die gleiche Bandbreite.

Ich hoffe du kannst englisch. Lies dir mal die PDFs die ich verlinked habe durch. Ich bin leider nicht vom Fach und mir fehlt einiges an Wissen über die Prozesse die im Detail bei Caching/memory controlling ablaufen, aber so wie das verstehe, soll genau dieses "Wunder" das DynEB-Cache Modell möglich machen. Es reduziert die tatsächlich benötigte Bandbreite indem man das unnötige replizieren, einlagern, auslagern etc. von Daten im L1 Cache DEUTLICH reduziert. Ein Hitraten-Erhöhung von 80-90% in den "getesteten" 28 Applikationen.

Das heisst man kann "Nutzung" der Bandbreite faktisch fast verdoppeln, da die Menge der zu transferierenden Daten eben faktisch derart reduziert wird.

Ein 256 Bit SI ist dann praktisch so effizient wie ein 512Bit SI.

Das ist der Kernpunkt des DynEB-Modells.
EDIT: Hier nochmal der Link direkt: https://adwaitjog.github.io/docs/pdf/sharedl1-pact20.pdf

mksn7

2020-10-07, 10:42:12

Im Paper geht es zum Grossteil um Latenzen und IPC. Da mehr Requests über den L1$ abgewickelt können, ergibt das wie im Paper beschrieben einen Netto-Latenzgewinn (28 cycles private, average +54 cycles für shared L1 requests, average 247 cycles für L2 requests) und dazu einen Netto-Bandbreitengewinn.

Das stellt auch ein wenig klar, welche Architektur da als Basis dient, denn 28 cycles Latenz für einen L1 Hit ist genau die L1 hit latency von Volta/Turing/Ampere. (Allerdings ist der L1 im paper winzig, mit 16kB.) Bei GCN und RDNA ist diese Latenz selbst im nähesten Cache wesentlich höher (~90-120 cycles). Der shared L1 von RDNA kanns also nicht sein, der ist noch weiter weg. Irgendwie kann ich mir nicht vorstellen, dass ein remote L1 access nur 54 cycles drauf legt. In der Welt die sich das paper vorstellt wäre ein remote L1 access schneller als heute ein private L0 cache hit bei RDNA!

Es ist als Aussenstehender sehr schwer abzuschätzen, wie schnell und mit welchen Kosten verbunden ein gewisses Hardwarekonstrukt in einer Siliziumimplementierung tatsächlich ist. Irgendeinen Grund muss es wohl geben, dass ein Volta L1 nur 28 cycles braucht, aber ein RDNA L0 90 cycles. Oder wo die ~250 cycles (passt übrigens gut zu Voltas L2) für einen L2 cache Zugriff herkommen. Aber von all den Datenpunkten, die man an vorliegenden Chips sehen kann, hab ich das Gefühl dass ein Zugriff über ein komplexes interconnect immer mit viel Latenz verbunden ist, und dass daher ein großer Teil der L2 Latenz kommt.

Aber ich glaube die relevanten Zahlen in dieser Frage sind die L1$ Miss Rate und die L2$+Memory Reply Bandwidth. Ersteres sinkt um ~57% (DynEB) und letzteres im Idealfall um ~40-60% (siehe angehängte Grafiken). Nicht in allen Fällen, aber den meisten.
Also wenn die benötigte L2$ Reply Bandbreite halbiert wird, gehe ich davon aus dass auch Anforderungen an die Off-Chip Bandbreite stark sinken. Wie stark kann ich nicht genau sagen (L2 Bandbreite von Navi 10 ist ~4x wie die Off-Chip Bandbreite).
Jemand mit Ahnung kann hier gerne seine Einschätzung abgeben oder mich korrigieren. Die im Paper simulierte GPU weist deutlich kleinere Caches als RDNA1 auf. Wie sich RDNA also mit den im Paper beschriebenen Methoden verhält, kann ich nur schwer beurteilen.

Nochmal: der L2 wird nicht effektiver (=weniger misses), dadurch dass er weniger requests erhält. Die Zugriffe auf Addressen die ohne L1 einen miss erzeugen, erzeugen danach immer noch einen miss. Also gleiche Anzahl an misses, aber weniger hits, weil mehr potentielle hits schon vom shared L1 bedient wurden. Die hit rate des L2 sinkt einfach nur, was ihn im Grenzfall (der shared L1 hat gleiche oder größere Kapazität als der L2) nutzlos macht, mit 0% hitrate.

Ich würde einfach nicht soviel Bedeutung in ein einzelnes Paper geben. Die hatten halt eine Idee, haben die mal ein bisschen simuliert, und haben dann mit richtiger Benchmarkauswahl und richtige Auswahl der Parameter sich die Welt schöngerechnet, sodass am Schluss irgendwie ein Nettogewinn dabei rumkommt. Das ist durchaus ein interessanter Datenpunkt, sowas mal durchzuspielen, aber man darf die Behauptungen in einem paper nicht derart für bare Münze nehmen. Beispielsweise sind echte L1's meistens größer als im paper. Für größere L1 ist der Effekt vielleicht geringer, aber indem die richtige Basiskonfiguration gewählt wurde, hat man einen Vorteil. (Ich behaupte nicht dass das so ist, nur dass man durch die richtige Auswahl der Umstände
besser wegkommt)

Berniyh

2020-10-07, 10:42:18

Ich wüsste nicht was daran zu optimisch wäre. N21 soll 80 CUs haben, GA102 hat 82 CUs. Das ist im Prinzip das Selbe. N21 wird mit höheren Frequenzen kommen. Schon RDNA1 war beim gleichen Takt und gleichen CUs minimal vor Turing (Vergleich allerdings bei 1,5GHz, ergo etwas näher am Sweetspot). Perf/W soll bei RDNA2 gegenüber RDNA1 höher ausfallen als bei Ampere vs. Turing.
Ähm … Bandbreite?

Ja, AMD hat mutmaßlich eine Special Sauce um dem entgegenzuwirken, aber niemand weiß ob das zufriedenstellend funktioniert und wenn ja, ob es genügt auch in der Spitze anzugreifen.

Berniyh

2020-10-07, 10:43:12

Ich hoffe du kannst englisch. Lies dir mal die PDFs die ich verlinked habe durch. Ich bin leider nicht vom Fach und mir fehlt einiges an Wissen über die Prozesse die im Detail bei Caching/memory controlling ablaufen, aber so wie das verstehe, soll genau dieses "Wunder" das DynEB-Cache Modell möglich machen. Es reduziert die tatsächlich benötigte Bandbreite indem man das unnötige replizieren, einlagern, auslagern etc. von Daten im L1 Cache DEUTLICH reduziert. Ein Hitraten-Erhöhung von 80-90% in den "getesteten" 28 Applikationen.

Das heisst man kann "Nutzung" der Bandbreite faktisch fast verdoppeln, da die Menge der zu transferierenden Daten eben faktisch derart reduziert wird.
In einer idealisierten Simulation. ;)

dargo

2020-10-07, 10:48:15

Ähm … Bandbreite?

Meinst du ernsthaft AMD entwickelt eine 80 CU GPU um sie nachher an mangelnden Bandbreite verhungern zu lassen? Ich bitte dich... dann hätte AMD von Anfang an mit deutlich weniger CUs geplant.

Adam D.

2020-10-07, 10:53:22

Meinst du ernsthaft AMD entwickelt eine 80 CU GPU um sie nachher an mangelnden Bandbreite verhungern zu lassen? Ich bitte dich... dann hätte AMD von Anfang an mit deutlich weniger CUs geplant.
Ohne dass jetzt allzu kritisch zu meinen: AMD hat sich in der Vergangenheit schon ab und zu mal ordentlich verkalkuliert. Ich glaube zwar auch nicht, dass das dieses Mal Vega-Ausmaße annimmt, aber man muss schon wirklich hoffen, dass ihre Cache-Secret-Sauce (oder was auch immer) in der Praxis auch wirklich funktioniert.

Berniyh

2020-10-07, 10:55:43

Meinst du ernsthaft AMD entwickelt eine 80 CU GPU um sie nachher an mangelnden Bandbreite verhungern zu lassen? Ich bitte dich... dann hätte AMD von Anfang an mit deutlich weniger CUs geplant.
Nein, meine ich nicht, aber sämtliche Spekulationen bzgl. Performance sind daher einfach nutzlos, da keiner weiß wie effektiv die Maßnahmen wirklich sind.

dargo

2020-10-07, 10:58:32

Ohne dass jetzt allzu kritisch zu meinen: AMD hat sich in der Vergangenheit schon ab und zu mal ordentlich verkalkuliert. Ich glaube zwar auch nicht, dass das dieses Mal Vega-Ausmaße annimmt, aber man muss schon wirklich hoffen, dass ihre Cache-Secret-Sauce (oder was auch immer) in der Praxis auch wirklich funktioniert.
Falls nicht gibts halt Shitstorm... zurecht.

basix

2020-10-07, 10:59:01

Ich würde einfach nicht soviel Bedeutung in ein einzelnes Paper geben. Die hatten halt eine Idee, haben die mal ein bisschen simuliert, und haben dann mit richtiger Benchmarkauswahl und richtige Auswahl der Parameter sich die Welt schöngerechnet, sodass am Schluss irgendwie ein Nettogewinn dabei rumkommt. Das ist durchaus ein interessanter Datenpunkt, sowas mal durchzuspielen, aber man darf die Behauptungen in einem paper nicht derart für bare Münze nehmen.

Mir ist völlig klar, dass das Paper idealisierte Resultate präsentiert und je nach Chip und dessen Konfiguration / Umsetzung ganz andere Resultate herauskommen. Dennoch sind die Resultate interessant.

Und dem Paper "viel Bedeutung" beimessen ist fast übertrieben. Das Paper zeigt zumindest auf, wie man Energieeffizienz eines Chips deutlich steigern kann und dass man damit Bandbreite sparen kann. Und das macht es dann interessant: RDNA2 wird mit genau diesen Eigenschaften in Verbindung gebracht. Und das Paper ist deutlich konkreter in seiner Auslegung als ein ominöser "Infinity Cache" mit z.B. 128 MByte ;)

@Performance Gerüchte:
Wenn jemand glaubt, dass ein 80 CU Chip Mühe mit einer 3070 hat, dem ist nicht zu helfen. Wenn AMD bei 2x CUs 1.8x Scaling hinbekommt, 1.1x IPC drauflegt und den Takt von RDNA1 beibehält, landen wir auf 2x 5700XT Performance. Die Werte fürs Scaling und die IPC sind nicht völlig verkehrt und der Takt auch nicht (siehe XBSX und PS5). Ich denke auch, dass eher der kleinere Chip mit der 3070 konkurriert (deutliches Taktplus bei 40 CU vorausgesetzt).

@dargo:
Es kann schon sein, dass der 40 CU Chip 220W verbrät. Wieso? 2.5 GHz und 1.1x IPC ergeben +50% Performance einer 5700XT. Und was hat uns AMD prognostiziert? +50%/W --> passt

dargo

2020-10-07, 11:06:35

@dargo:
Es kann schon sein, dass der 40 CU Chip 220W verbrät. Wieso? 2.5 GHz und 1.1x IPC ergeben +50% Performance einer 5700XT. Und was hat uns AMD prognostiziert? +50%/W --> passt
Ja... das stimmt. Mit den +15% auf 2080TI würde das auch passen. Letztere liegt nämlich ca. +55% vor RX 5700XT. Was mir dabei nicht passt ist der zu kleine Leistungsabstand zwischen N21 und N22 bei doppelten CUs. Bei den Angaben wäre N21 nur 22% schneller als N22. :freak:

basix

2020-10-07, 11:13:19

Was mir dabei nicht passt ist der zu kleine Leistungsabstand zwischen N21 und N22 bei doppelten CUs.

Wer sagt das der so klein ist? :whisper: :deal: :D

Wenn N22 wirklich 200+W verbrät und 2.5GHz hoch taktet, erwarte ich einfach deutlich reduzierte Taktraten bei N21. Das steigert die Energieeffizienz enorm (und man erhält noch automatisch den Overclockers Dream für die Enthusiasten :freak:).

Sagen wir mal 80 zu 40 CU, 1.8x Scaling, 0.85x Takt --> N21 = N22 + 50%. Das passt dann auch in die 280W zu 200W sowie 256b/16Gbps zu 192b/14Gbps Geschichte . Klar, N21 käme dann auf irgendwo auf 3080-3090 FE Niveau und wäre sehr stark von AMD.

HOT

2020-10-07, 11:15:27

Ich schätze mal nachdem man an keine wirklich relevanten Infos mehr ran kommt (außer dem was eh schon bekannt ist wie die Anzahl der CUs) werden jetzt halt Performance-Hochrechnungen gepostet.
Da kann man sich hinterher immer rausreden, dass das nur irgendwelche Zielwerte waren oder irgendwas über- oder unterschätzt wurde.
Is halt nix handfestes.

Was allerdings plausibel erscheint, ist, dass AMD ja eine Zielsetzung für BN vorgegeben hat für den Chip. Der sollte sicherlich mindestens 40% über der 2080Ti rauskommen als unterste Marke, also >100% über N10XT. Sowas könnte durchaus bekannt sein. Ob das letztendlich so ist, werden wir aus Performanceleaks erfahren, sobald die Kartenhersteller auch Treiber haben.

Der_Korken

2020-10-07, 11:16:22

... aber so wie das verstehe, soll genau dieses "Wunder" das DynEB-Cache Modell möglich machen. Es reduziert die tatsächlich benötigte Bandbreite indem man das unnötige replizieren, einlagern, auslagern etc. von Daten im L1 Cache DEUTLICH reduziert. Ein Hitraten-Erhöhung von 80-90% in den "getesteten" 28 Applikationen.

Das heisst man kann "Nutzung" der Bandbreite faktisch fast verdoppeln, da die Menge der zu transferierenden Daten eben faktisch derart reduziert wird.

Ein 256 Bit SI ist dann praktisch so effizient wie ein 512Bit SI.

Nein, das ergibt keinen Sinn. Wenn du Speicheranfragen abfangen willst, dann musst du die Daten dafür irgendwo auf dem Chip haben. Das heißt, Speicherbandbreite kannst du nur dann einsparen, wenn du in Summe mehr Daten auf dem Chip hältst. Wo die liegen ist nebensächlich, aber vorhanden müssen sie sein.

Nehmen wir N10 mal als Beispiel: Angenommen du hast nur Redundanz in den kleinen Cache-Stufen. Dann kannst du effektiv nur so viele Daten auf dem Chip halten, wie in den größten Cache reinpassen, also 4MB. Der best case wäre nun, dass alle Caches auf dem Chip unterschiedliche Daten haben und jeder Zugriff über alle Caches läuft, um den Platz bestmöglich auszunutzen (das ist effizienztechnisch natürlich totaler Blödsinn, aber es geht hier um den konstruierten best case). Dann würdest du 4MB (L2) + 4x128KB (L1) + 40x16KB (L0) = 5,125MB an Daten unterbekommen. Das sind 30% mehr als im worst case, trotz optimistischster Annahmen.

Daraus ergibt sich keine nennenswerte Erhöhung der Hitrate auf den ganzen Chip bezogen. Da würde es schon mehr bringen, den L2-Cache auf 6 oder 8MB zu vergrößern und wenn das so viel brächte, hätte man es längst gemacht. Der shared cache kann innerhalb der SAs Datentransfers sparen bzw. die Wege verkürzen, was auch die Performance verbessert, aber die geringe Speicherbandbreite ist eine ganz andere Baustelle.

dargo

2020-10-07, 11:16:36

Wer sagt das der so klein ist? :whisper: :deal: :D

Jetzt sag nicht N21 legt auf die 2080TI ~80% drauf sonst fällt Dural gleich um. :D

Wenn N22 wirklich 200+W verbrät und 2.5GHz hoch taktet, erwarte ich einfach deutlich reduzierte Taktraten bei N21. Das steigert die Energieeffizienz enorm (und man erhält noch automatisch den Overclockers Dream für die Enthusiasten :freak:).

Sagen wir mal 80 zu 40 CU, 1.8x Scaling, 0.85x Takt --> N21 = N22 + 50%. Das passt dann auch in die 280W zu 200W sowie 256b/16Gbps zu 192b/14Gbps Geschichte . Klar, N21 käme dann auf irgendwo auf 3080-3090 FE Niveau und wäre sehr stark von AMD.
Ähm... 85% von 2,5Ghz sind immer noch stolze 2125Mhz. :tongue: Mit so hohen Taktraten rechne ich nicht mal bei N21. Und, dass AMD am Desktop unter 1825Mhz der XBSX geht kann ich mir nicht wirklich vorstellen. Da wäre es wirtschaftlicher N21 mit 64 CUs zu bringen.

Berniyh

2020-10-07, 11:22:24

Was allerdings plausibel erscheint, ist, dass AMD ja eine Zielsetzung für BN vorgegeben hat für den Chip. Der sollte sicherlich mindestens 40% über der 2080Ti rauskommen als unterste Marke, also >100% über N10XT. Sowas könnte durchaus bekannt sein. Ob das letztendlich so ist, werden wir aus Performanceleaks erfahren, sobald die Kartenhersteller auch Treiber haben.
Ja, das stimmt schon, aber wie ich oben schon schrieb:
AMD pokert hier ziemlich hoch.
Es ist halt nicht garantiert, dass das auch wirklich gut geht (bzw. für uns zumindest nicht abschätzbar).

basix

2020-10-07, 11:24:18

Ähm... 85% von 2,5Ghz sind immer noch stolze 2125Mhz. :tongue: Mit so hohen Taktraten rechne ich nicht mal bei N21. Und, dass AMD am Desktop unter 1825Mhz der XBSX geht kann ich mir nicht wirklich vorstellen. Da wäre es wirtschaftlicher N21 mit 64 CUs zu bringen.

Ja klar, ist es. Aber bei perfektem f*U^2 Scaling ergibt das +60% Energieeffizienz. Ist idealisiert und die Welt ist nicht immer so perfekt, aber der Effizienzsprung sollte sehr deutlich sein. Und wenn es dann halt "nur" 2.0GHz wären, wäre die Performance immer noch enorm.

Was allerdings plausibel erscheint, ist, dass AMD ja eine Zielsetzung für BN vorgegeben hat für den Chip. Der sollte sicherlich mindestens 40% über der 2080Ti rauskommen als unterste Marke, also >100% über N10XT. Sowas könnte durchaus bekannt sein. Ob das letztendlich so ist, werden wir aus Performanceleaks erfahren, sobald die Kartenhersteller auch Treiber haben.
Ich habe noch etwas gegraben. Eine 980 war +20% schneller wie eine 780 Ti, die 1080 war +30% schneller als die 980 Ti, die 2080 Ti war +30-40% schneller wie eine 1080 Ti. Eine interne Zielvorgabe von 2080 Ti +40% würde also sehr viel Sinn machen, da man damit auf Augenhöhe oder etwas über der zweitschnellsten SKU landen würde. Für die schnellste reicht es vielleicht nicht, bei einer zweiten Turing-artigen Generation evtl. aber doch.

HOT

2020-10-07, 11:25:07

dargo
diese Taktraten halte ich für sicher angesichts dessen, dass die sogar auf der PS5 erreicht werden. Zur Erinnerung, die Taktraten der Konsolen in der Vergangenheit waren immer sehr konservativ angesetzt und bei der XBox ist das auch noch so.
Schon der interne Vega von Cezanne soll 2150MHz packen, das ist schon sehr krass, wenn man bedenkt, dass V10 so um die 1,3GHz lief und mit extremen Schmerzen Richtung 1,6 schaffte...

Ja, das stimmt schon, aber wie ich oben schon schrieb:
AMD pokert hier ziemlich hoch.
Es ist halt nicht garantiert, dass das auch wirklich gut geht (bzw. für uns zumindest nicht abschätzbar).

NV hat IIRC mal geschrieben, dass sie vorher ziemlich exakt die Leistungsdaten kennen, bevor der Chip in Silizium zurückkommt. Das dürfte bei AMD nicht anders sein. Pokern war das vllt. Anfang der 2000er, das kann sich heute keiner mehr leisten. Wer reden hier direkt von zweistelligen Millionenkosten.

Complicated

2020-10-07, 11:25:56

Es reduziert die tatsächlich benötigte Bandbreite indem man das unnötige replizieren, einlagern, auslagern etc. von Daten im L1 Cache DEUTLICH reduziert. Ein Hitraten-Erhöhung von 80-90% in den "getesteten" 28 Applikationen.
Vorsicht, an dieser Stelle hat man schnell den falschen Basiswert. Das Paper spricht von einer Reduzierung der L1-Misses. Die L1-Hits werden dadurch nicht automatisch um 80% erhöht. Das kann deutlich mehr oder auch weniger sein prozentual, abhängig von dem vorher herrschenden Miss/Hit-Ratio.

Iscaran

2020-10-07, 11:26:22

Das stellt auch ein wenig klar, welche Architektur da als Basis dient, denn 28 cycles Latenz für einen L1 Hit ist genau die L1 hit latency von Volta/Turing/Ampere. (Allerdings ist der L1 im paper winzig, mit 16kB.) Bei GCN und RDNA ist diese Latenz selbst im nähesten Cache wesentlich höher (~90-120 cycles). Der shared L1 von RDNA kanns also nicht sein, der ist noch weiter weg. Irgendwie kann ich mir nicht vorstellen, dass ein remote L1 access nur 54 cycles drauf legt. In der Welt die sich das paper vorstellt wäre ein remote L1 access schneller als heute ein private L0 cache hit bei RDNA!

Es ist als Aussenstehender sehr schwer abzuschätzen, wie schnell und mit welchen Kosten verbunden ein gewisses Hardwarekonstrukt in einer Siliziumimplementierung tatsächlich ist. Irgendeinen Grund muss es wohl geben, dass ein Volta L1 nur 28 cycles braucht, aber ein RDNA L0 90 cycles. Oder wo die ~250 cycles (passt übrigens gut zu Voltas L2) für einen L2 cache Zugriff herkommen. Aber von all den Datenpunkten, die man an vorliegenden Chips sehen kann, hab ich das Gefühl dass ein Zugriff über ein komplexes interconnect immer mit viel Latenz verbunden ist, und dass daher ein großer Teil der L2 Latenz kommt.

Woher hast du diese Angaben zur Latenz der Caches ?
AFAIK hat RDNA bereits die Latenz und den Durchsatz der CUs gegenüber GCN massiv verbessert (siehe Figure 8 im Whitepaper: https://www.amd.com/system/files/documents/rdna-whitepaper.pdf )
oder auch hier:
https://gpuopen.com/wp-content/uploads/2019/08/RDNA_Architecture_public.pdf
z.B. auf Folie19 steht die Latenz des LDS (local-data-share, vermute mal das ist der L0-Cache der CUs selbst) wurde halbiert von GCN auf RDNA.

Und auch hier - der Hauptgrund warum RDNA soviel IPC draufgelegt hat gegenüber GCN war die Umorganisation des Caches:
https://fuse.wikichip.org/news/3331/radeon-rx-5700-navi-and-the-rdna-architecture/2/

Vielleicht war das eben alles nur der Schritt 1 auf dem Weg dahin dass man eigentlich diesen DynEB-Cache realisieren wollte. Denn dieser setzt ja voraus, daß man einen "zentralisiert"-Verwalteten L1-Cache hat der über alle CUs geshared ist.

Übrigens ist es natürlich kein Zufall dass man die Volta 28cycle Latenz nimmt für die Simulation...wird sogar als Qelle angegeben im Paper Literaturstelle [31] ist eine extensive Beschreibung von Simulationssoftwares für unter anderem die GV100 Architektur.

Vielleicht hat man sich an dieser orientiert, weil man weiss dass sie recht ähnlich/gut zur RDNA passt (rein vom Modell her ?).

mksn7

2020-10-07, 11:28:16

mksn7

2020-10-07, 11:32:31

Woher hast du diese Angaben zur Latenz der Caches ?
AFAIK hat RDNA bereits die Latenz und den Durchsatz der CUs gegenüber GCN massiv verbessert (siehe Figure 8 im Whitepaper: https://www.amd.com/system/files/documents/rdna-whitepaper.pdf )
oder auch hier:
https://gpuopen.com/wp-content/uploads/2019/08/RDNA_Architecture_public.pdf
z.B. auf Folie19 steht die Latenz des LDS (local-data-share, vermute mal das ist der L0-Cache der CUs selbst) wurde halbiert von GCN auf RDNA.
Und auch hier - der Hauptgrund warum RDNA soviel IPC draufgelegt hat

LDS ist nicht das Gleiche wie der L0, das sind bei RDNA sogar separate Strukturen. Bei Volta ist das die gleiche hardware, aber shared memory loads sind trotzdem schneller weil keine tags gecheckt werden müssen.

Volta L1/L2 hab ich selbst gemessen. Die GCN/RDNA Zahlen hab ich nach kurzem Suchen aus dem beyond3D forum:
https://forum.beyond3d.com/threads/amd-navi-speculation-rumours-and-discussion-2019.61042/page-45

With respect to the lower-latency hierarchy:
Per a GDC 2018 presentation on engine optimizations (https://gpuopen.com/gdc-2018-presentations/, one by Timothy Lottes), a GCN vector L1 hit has a latency of ~114 cycles. So I guess RDNA dropping its cache hit latency down to 90 cycles is better than nothing. Going by the reverse-engineering of Volta (https://arxiv.org/pdf/1804.06826.pdf) AMD is about three times slower rather than about four times slower at the L1. GPU L1 aren't speed demons, obviously, and Volta appears to have latencies close to GCN at the L2 and beyond.

Ich würde dem Glauben schenken.

dargo

2020-10-07, 11:33:09

dargo
diese Taktraten halte ich für sicher angesichts dessen, dass die sogar auf der PS5 erreicht werden. Zur Erinnerung, die Taktraten der Konsolen in der Vergangenheit waren immer sehr konservativ angesetzt.

Ich noch nicht...

* feste Taktangaben gibt es nicht da Spiele unterschiedliche Lasten haben, ergo gehe ich eher bei den 2,2/2,5Ghz von max. Frequenzen für den Arbeitsbereich in der Spannungskurve aus.
* das Volumen der neuen Konsolen hat zugenommen, ergo könnte man hier die TDPs erhöhen. Die 1172Mhz der XB1X sind auch nicht so wahnsinnig weit von den 1340Mhz der RX 580 am Desktop entfernt. Und die Desktop-Variante hat sogar 4 CUs weniger.

Schon der interne Vega von Cezanne soll 2150MHz packen, das ist schon sehr krass, wenn man bedenkt, dass V10 so um die 1,3GHz lief und mit extremen Schmerzen Richtung 1,6 schaffte...

Öhm... V10 LCE mit 1,7+Ghz war überhaupt kein Problem. :confused: Was dich limitiert hat war der enorme Anstieg beim Verbrauch mit hohen Frequenzen.

Edit:
Stinknormale Referenz V64 unter Wasser mit >1,8Ghz.

9g_syedkCJg

Troyan

2020-10-07, 11:33:57

Ein 256bit Interface ist vollkommen ausreichend, wie die 3070 zeigt. Mit 16GBit/s und 80CUs schafft AMD so bestimmt 80% Skalierung von der 5700XT.

Wieso Leute mehr erwarten, ist mir schleierhaft. Auch AMD ist der Physik unterlegen und das Skalieren nach oben ist viel schwieriger als nach unten.

HOT

2020-10-07, 11:34:59

dargo
Die TDPs erhöhen sich in erster Linie aufgrund der CPUs. Wir sind hier von Mobil-pipi-CPUs auf echte Desktop-Stiere mit hohen Taktraten gewechselt. Die GPUs werden eher weniger TDP zur Verfügung haben. Nicht umsonst wird die CPU bei der PS5 auch noch heruntergetaktet, wenn die GPU-Takte hochgehen. Das Budget ist und bleibt extrem eingeschränkt auf der Konsole. Optimierter Konsolentakt ohne ms-genaue Taktanpassungen im Turbo für RDNA2 würde ich weiterhin auf 1,85GHz einschätzen, das gilt aber nicht für Desktop, hier wird man erheblich darüber rauskommen. Obs jetzt 2,5GHz sind, lass mal dahingestellt sein, aber 2,2 ist absolut realistisch - die Konsole machts ja sogar vor. Da würd ich eher sogar von mehr ausgehen, wenn die TDP keine Rolle spielt (tut sie offenbar aber, was ich gut finde).

Iscaran

2020-10-07, 11:36:28

Nein, das ergibt keinen Sinn. Wenn du Speicheranfragen abfangen willst, dann musst du die Daten dafür irgendwo auf dem Chip haben. Das heißt, Speicherbandbreite kannst du nur dann einsparen, wenn du in Summe mehr Daten auf dem Chip hältst. Wo die liegen ist nebensächlich, aber vorhanden müssen sie sein.

Nehmen wir N10 mal als Beispiel: Angenommen du hast nur Redundanz in den kleinen Cache-Stufen. Dann kannst du effektiv nur so viele Daten auf dem Chip halten, wie in den größten Cache reinpassen, also 4MB. Der best case wäre nun, dass alle Caches auf dem Chip unterschiedliche Daten haben und jeder Zugriff über alle Caches läuft, um den Platz bestmöglich auszunutzen (das ist effizienztechnisch natürlich totaler Blödsinn, aber es geht hier um den konstruierten best case). Dann würdest du 4MB (L2) + 4x128KB (L1) + 40x16KB (L0) = 5,125MB an Daten unterbekommen. Das sind 30% mehr als im worst case, trotz optimistischster Annahmen.

Das Problem ist aber das sehr oft vielfach redundant Daten abgerufen transferiert werden, die eben in dem "lokalen" Cache liegen aber eben nicht abgegriffen werden können weil die vielen mini-caches eben genau nichts voneinander Wissen.

DynEB setzt genau hier an - indem die Verwaltung/Organisation der 40 L1-Caches der WGPs umstrukturiert werden.

Jeder L1-Hit erzeugt automatisch KEINE neue Anfrage an den L2 und von dort weitergehend über das SI ins RAM bzw auf die Festplatte.

Deswegen ist die Hitratenerhöhung auch so wichtig und skaliert laut Paper und den Arbeiten des Kollegen Wang Literatur [67] aus dem DynEB Paper auch deswegen direkt mit der IPC.
"An increase in on-chipmemory hit rate can lead to a proportional decrease in memorytraffic, translating into performance improvements for memory-intensive programs [45,67]. Therefore, researchers in the past haveinvested significant efforts in improving cache performance viahardware and software methods [24, 26, 27, 29, 32, 54, 73"

Vorsicht, an dieser Stelle hat man schnell den falschen Basiswert. Das Paper spricht von einer Reduzierung der L1-Misses. Die L1-Hits werden dadurch nicht automatisch um 80% erhöht. Das kann deutlich mehr oder auch weniger sein prozentual, abhängig von dem vorher herrschenden Miss/Hit-Ratio.

Stimmt...danke für die Richtigstellung und Anmerkung.
Wenn ich schon 80% Hitrate habe (und damit 20% Miss) würde eine Reduktion der Missrate um 80% also einer Erhöhung der Hitrate von 80 => 96 % gleichkommen.
Gesetzt den Fall das dies auch 1:1 mit der IPC skalieren würde wäre das also ein IPC-Gewinn von 20%.

Im Paper war die Rede davon dass der L1 Cache aufgrund seiner vielen Verdoppelungen aber eben eine sehr schlechte Hitrate hat. Deswegen würde ich annehmen dass da noch viel Platz nach "oben" ist in Richtung 100%.

Complicated

2020-10-07, 11:36:36

80% weniger L2 Zugriffe durch den L1 reduziert auch Anzahl der Misses im L2 und damit den Speicherzugriff->Bandbreite ist reduziert. Um wieviel zeigt die Formel zur Berechnung von DynEB
.We observe that Shared++ and DynEB improves IPC over Private(2x)by 8% and 4%, respectively. This shows that by enabling a shared L1 organization, we can perform better compared to a system with double the L1 cache resources without the extra cost/overhead of increasing the L1 cache size (84% cache area overhead...

dargo

2020-10-07, 11:39:38

dargo
Die TDPs erhöhen sich in erster Linie aufgrund der CPUs.
Das ist jetzt nicht dein ernst oder? :freak: Schau dir mal die Frequenzen der CPUs in den Konsolen an, auch im Hinblick auf SMT on/off. Zudem haben die CPUs den halben L3 vom Desktop. Mich würde es sehr überraschen wenn diese CPUs mehr als 45W verbrauchen. Dabei nicht vergessen... alle 8 Cores bzw. 16 Threads werden sowieso nicht in Games verwendet.

Adam D.

2020-10-07, 11:43:33

basix

2020-10-07, 11:46:25

Ich noch nicht...

* feste Taktangaben gibt es nicht da Spiele unterschiedliche Lasten haben, ergo gehe ich eher bei den 2,2/2,5Ghz von max. Frequenzen für den Arbeitsbereich in der Spannungskurve aus.
* das Volumen der neuen Konsolen hat zugenommen, ergo könnte man hier die TDPs erhöhen. Die 1172Mhz der XB1X sind auch nicht so wahnsinnig weit von den 1340Mhz der RX 580 am Desktop entfernt. Und die Desktop-Variante hat sogar 4 CUs weniger.

Bei einer PS5 kommen 2.23 GHz heraus. Was man hierbei beachten muss: Jede PS5 schaft diese Taktraten. Dort wird also noch etwas Reserve vorhanden sein. Bei dGPUs kann man zusätzlich noch Binning und deutlicheres Salvaging betreiben, ohne dass der Yield komplett absackt. Deswegen sind Taktraten im Bereich 2.3...2.5 GHz mMn gesetzt. Dein Beispiel mit der XB1X geht ja auch in diese Richtung. Konsolenchips +10% Takt.

Ein 256bit Interface ist vollkommen ausreichend, wie die 3070 zeigt. Mit 16GBit/s und 80CUs schafft AMD so bestimmt 80% Skalierung von der 5700XT.

Ist die Frage, welche Performance man anstrebt ;) Bei 3070 Performance scheint 256b mit 14Gbps zu reichen. Visiert man eher 3090 FE Performance an, wird es langsam knapp ;) Und das ist eben die grosse Frage, welche momentan noch unbeantwortet ist (oder die 256b waren ein reiner Hoax)

Berniyh

2020-10-07, 11:53:03

NV hat IIRC mal geschrieben, dass sie vorher ziemlich exakt die Leistungsdaten kennen, bevor der Chip in Silizium zurückkommt. Das dürfte bei AMD nicht anders sein. Pokern war das vllt. Anfang der 2000er, das kann sich heute keiner mehr leisten. Wer reden hier direkt von zweistelligen Millionenkosten.
Jein, der Poker beginnt halt immer früher und gerade wenn man in einer Situation wie AMD ist (keinen dedizierten High-End Chip mehr seit X Jahren), dann kann man es sich auch nicht leisten etwaige Projekte bei denen der Poker evtl. nicht so gut ausgeht wieder zu verwerfen.

Und gerade Nvidia scheint sich ja mit Ampere schon so ein bisschen verpokert zu haben (ok, evtl. nicht nur bei der Aufstellung des Chips, sondern auch bei der Fertigung).
Ob und wie das bei AMD ausgeht steht halt in den Sternen.

Ich will RDNA2 auch überhaupt nicht schlecht reden (ich werde ja selbst wahrscheinlich eine der Karten kaufen), nur seh ich halt auch noch überhaupt keinen Grund auf den Hypetrain aufzusteigen. ;)

Und ich bleibe wie gesagt bei meiner Aussage: Performance-Vorhersagen zu RDNA2 sind derzeit ziemlicher Bullshit.
Ok, mit Ausnahme von manchen grundlegenden Aussagen, wie z.B. dass ein 80CU Navi 21 dann doch etwas mehr als 30% auf einen Navi 10 drauf packen sollte, aber das ist halt auch ein ziemlicher No-Brainer.

dargo

2020-10-07, 11:54:21

Bei einer PS5 kommen 2.23 GHz heraus. Was man hierbei beachten muss: Jede PS5 schaft diese Taktraten. Dort wird also noch etwas Reserve vorhanden sein. Bei dGPUs kann man zusätzlich noch Binning und deutlicheres Salvaging betreiben, ohne dass der Yield komplett absackt. Deswegen sind Taktraten im Bereich 2.3...2.5 GHz mMn gesetzt. Dein Beispiel mit der XB1X geht ja auch in diese Richtung. Konsolenchips +10% Takt.

Eine PS5 hat nur 36 CUs. Damit geht dir der Verbrauch noch nicht so durch die Decke. ;) Ich sage ja nicht, dass N22/N21 diese Frequenzen nicht schafft! Ich zweifle nur diese Frequenzen bei einer Referenzkarte an.

Troyan

2020-10-07, 11:55:18

Ist die Frage, welche Performance man anstrebt ;) Bei 3070 Performance scheint 256b mit 14Gbps zu reichen. Visiert man eher 3090 FE Performance an, wird es langsam knapp ;) Und das ist eben die grosse Frage, welche momentan noch unbeantwortet ist (oder die 256b waren ein reiner Hoax)

Da AMD keine Ahnung hat, was nVidia macht, geht es erstmal rein um AMD. Und da sollte man 80% bei Verdopplung als realistisches Ziel sehen. GA104 im Vollausbau mit 16GBit/s schafft fast die 80% auf 5700XT.

Und GA104 hat 6 Rasterizer, 96ROPs, ~22TFLOPs FP32 Leistung. Das muss AMD zahlenmäßig erstmal erreichen. Die 3090 ist auch nicht 80% schneller als eine 3070 trotz dem die Karten 80% mehr Rechenleistung und 100% mehr Bandbreite hat.

Der_Korken

2020-10-07, 11:56:09

Das Problem ist aber das sehr oft vielfach redundant Daten abgerufen transferiert werden, die eben in dem "lokalen" Cache liegen aber eben nicht abgegriffen werden können weil die vielen mini-caches eben genau nichts voneinander Wissen.

DynEB setzt genau hier an - indem die Verwaltung/Organisation der 40 L1-Caches der WGPs umstrukturiert werden.

Jeder L1-Hit erzeugt automatisch KEINE neue Anfrage an den L2 und von dort weitergehend über das SI ins RAM bzw auf die Festplatte.

Der L2 ist (Stand jetzt) aber um ein vielfaches größer als all die L1- und L0-Caches zusammen. Selbst wenn du alle Caches so zusammenschaltest, dass jeder auf alles zugreifen kann und jede Cache-Line ausgenutzt wird, kommst du im Beispiel von N10 nur auf 30% mehr Cache gegenüber dem worst case, dass nur der L2 zur Verfügung steht. Welche Caches intern die misses und hits erzeugen ist für den VRAM egal, denn es geht darum: Welche Daten, die ich vorher aus dem VRAM holen musste, liegen jetzt bereits auf dem Chip.

Deine Ausführung würde nur dann Sinn ergeben, wenn RDNA keinen L2 hätte und sozusagen jeder L1 direkt auf den VRAM zugreift. Dann ist die zuvor eingesparte Bandbreite zum L2 plötzlich eingesparte Bandbreite zum VRAM.

80% weniger L2 Zugriffe durch den L1 reduziert auch Anzahl der Misses im L2 und damit den Speicherzugriff->Bandbreite ist reduziert. Um wieviel zeigt die Formel zur Berechnung von DynEB

Die Schlussfolgerung stimmt so nicht. Wie Iscaran bereits schrieb, kann die L2 hitrate sogar sinken. Hitrate ist Anzahl misses geteilt durch Anzahl Anfragen. Wenn der L2 weniger Anfragen bekommt, aber genauso viele misses erzeugt (was ohne sharing nicht in den L2 gepasst hat, wird es auch hinterher nicht, denn L0 und L1 sind read-only), dann sinkt rechnerisch die hit rate.

Wie bereits geschrieben: Die Einsparungen verlaufen zwischen L1 und L2. Der L2 ist aber schon über den ganzen Chip geshared, da kann man nichts zusätzlich mehr sharen.

Complicated

2020-10-07, 11:59:36

Die Schlussfolgerung stimmt so nicht. Wie Iscaran bereits schrieb, kann die L2 hitrate sogar sinken.
Vorsicht mit der Verknüpfung: Wenn 80% weniger L2-Anfragen kommen muss sich die Hit-/Missrate nicht verändern im L2. Er bekommt dennoch 80% weniger Anfragen wegen 80% Miss-Reduzierung im L1. Das bedeutet, dass man die selbe Leistung mit 80% weniger L2 erhält oder die L2-Kapazität um den Faktor 5 erhöht - Milchmädchenmässig gesehen.

dargo

2020-10-07, 12:02:14

Und GA104 hat 6 Rasterizer, 96ROPs, ~22TFLOPs FP32 Leistung. Das muss AMD zahlenmäßig erstmal erreichen.
Geht dieser Ampere-TFLOP bullshit wieder los? :facepalm: GA102 hat 36 TFLOPs. Warum ist der keine ~140% schneller als die 2080TI? Für wie blöd hälst du die Leute hier eigentlich? Wenn man Gaming-Ampere auf den FP32 Durchsatz alleine runterbricht ist Ampere eine Luftpumpe.

basix

2020-10-07, 12:08:00

Eine PS5 hat nur 36 CUs. Damit geht dir der Verbrauch noch nicht so durch die Decke. ;) Ich sage ja nicht, dass N22/N21 diese Frequenzen nicht schafft! Ich zweifle nur diese Frequenzen bei einer Referenzkarte an.

Das hätte N22 mit 40 CUs ja auch ;) Ich gehe deswegen bei N22 >PS5 Takt aus. Bei N21 wird er wahrscheinlich etwas niedriger sein. Wir reden prinzipiell ja vom gleichen ;)

why_me

2020-10-07, 12:08:34

Der_Korken

2020-10-07, 12:13:17

Wenn 80% weniger L2-Anfragen kommen muss sich die Hit-/Missrate nicht verändern im L2. Er bekommt dennoch 80% weniger Anfragen wegen 80% Miss-Reduzierung im L1. Das bedeutet, dass man die selbe Leistung mit 80% weniger L2 erhält oder die L2-Kapazität um den Faktor 5 erhöht - Milchmädchenmässig gesehen.

Die Hit/missrate ist schwer vorherzusagen, sie kann sicherlich auch gleichbleiben, auch wenn ich das für sehr unwahrscheinlich halte. Die Missrates der Cache-Stufen sind keine unabhängigen Zufallsvariablen. Die L0- und L1-Caches sind write-through-caches. Ich bin mir gerade nicht sicher, ob das auch eine Inklusion impliziert.

Falls ja, dann würde das bedeuten, dass egal wie die L0 und L1 organisiert sind, es befänden sich immer die gleichen 4MB im L2. Alles was ohne sharing einen L2-miss erzeugt hat, würde dann auch mit sharing einen L2-miss erzeugen. Dadurch dass der L2 80% weniger Anfragen erhält, würde die Hitrate massiv sinken. Insbesondere würde aber keine Speicherbandbreite gespart.

Falls nein, ist es komplizierter, aber es ist sehr wahrscheinlich dass die L2-misses ohne sharing immer noch L2-misses bleiben, weil in Summe einfach nicht viel mehr Daten auf dem Chip liegen als ohne sharing.

basix

2020-10-07, 12:14:21

Edit:
Stinknormale Referenz V64 unter Wasser mit >1,8Ghz.

https://youtu.be/9g_syedkCJg
0°C Open Window WaKü ist aber nicht "stinknormal" :freak:

Falls ja, dann würde das bedeuten, dass egal wie die L0 und L1 organisiert sind, es befänden sich immer die gleichen 4MB im L2. Alles was ohne sharing einen L2-miss erzeugt hat, würde dann auch mit sharing einen L2-miss erzeugen. Dadurch dass der L2 80% weniger Anfragen erhält, würde die Hitrate massiv sinken. Insbesondere würde aber keine Speicherbandbreite gespart.

Somit steigert ein Shared-L1 die Performance, IPC, Energieeffizienz, Datenlokalität und Abhängigkeit von Cache Grössen (kleinere Caches bringen immer noch viel Performance). Den L2 könnte man wohl auch etwas effizienter nutzen. Die Anforderungen an die Off-Chip Bandbreite würden aber nicht gross sinken. Netto immer noch ein grosser Gewinn.

dargo

2020-10-07, 12:19:36

Das hätte N22 mit 40 CUs ja auch ;) Ich gehe deswegen bei N22 >PS5 Takt aus.
2300-2400Mhz sind auch größer PS5 und weniger als 2500Mhz. :P

Und wie soll der Vollausbau von GA104 80% schneller als die 5700 XT sein, wenn die 3070 +- (eher - nach den Zahlen zur 3080) auf dem Niveau der 2080 ti liegen soll. :confused: Soviel können die 2 SMs nicht bringen....
Der redet einfach bullshit. Die RTX 3070 wird sich im Schnitt schon unter der RTX 2080TI positionieren, ergo grob +45-50% auf RX 5700XT. Wie Troyan da bei +2SM auf +80% kommt kann er uns mal gerne vorrechnen.

0°C Open Window WaKü ist aber nicht "stinknormal" :freak:

MNCmvWmcAW0

Besser? Oder willst du mit mir jetzt über 100Mhz schwadronieren? Ich hatte selbst eine V64 LCE, also erspare es dir.

Brillus

2020-10-07, 12:22:15

Vorsicht mit der Verknüpfung: Wenn 80% weniger L2-Anfragen kommen muss sich die Hit-/Missrate nicht verändern im L2. Er bekommt dennoch 80% weniger Anfragen wegen 80% Miss-Reduzierung im L1. Das bedeutet, dass man die selbe Leistung mit 80% weniger L2 erhält oder die L2-Kapazität um den Faktor 5 erhöht - Milchmädchenmässig gesehen.

Disclaimer: wie ich es verstanden habe ist L2 inclusive, wenn das nicht stimmt ist der Rest des Post falsch.

Um genau sein muss sich wenn man dadurch die Anfragen auf L2 reduziert die Hitrate senken. Wenn L2 z.b. 90% Hitrate hat und man nun 80% der Anfragen wegnimmt hat man danach nur 50% Hitrate. Weil man nur Anfragen wegnehem kann die in einem L1 sind, das aber Daten sind die im L2 sind also Hits erzeugt hätten.

basix

2020-10-07, 12:24:59

Um wieder eine höhere L2-Hitrate zu erzielen, würde ein vergrösserter L2 reichen, stimmt das? Das sollte dann auch die Off-Chip Bandbreite reduzieren.

Brillus

2020-10-07, 12:27:23

Um wieder eine höhere L2-Hitrate zu erzielen, würde ein vergrösserter L2 reichen, stimmt das? Das sollte dann auch die Off-Chip Bandbreite reduzieren.

Ja wenn es um die geht könnte man ihn aber einfach so vergrößern ohne dieses gesharte einzubauen.

basix

2020-10-07, 12:34:47

Naja, damit gewinnt man dann aber eben nicht so viel IPC und Energieeffizienz. Ausserderm scheint man mit dem shared L1 weniger sensitiv auf die Cache-Grösse zu sein, was schlecht balancierte Anwendungen / Outliers ausbügeln sollte. Zudem stehen Spiele und Raytracing auf Bandbreite und Latenz ;)

Mein Gedanke war eher, dass eine niedrige Hitrate im Prinzip auf einen ineffektiven Cache hindeuten. Will man dessen Effektivität wieder steigern, müsste man ihn vergrössern.

why_me

2020-10-07, 12:41:04

Mein Ganke war eher, dass eine niedrige Hitrate im Prinzip auf einen ineffektiven Cache hindeuten. Will man dessen Effektivität wieder steigern, müsste man ihn vergrössern.

Was man ja scheinbar mit den angeblichen 128 MB macht.

basix

2020-10-07, 12:43:34

Wenn das denn stimmt ;) Aber ja, dem wäre dann so. Die Frage wäre dann noch ob L2 oder L3. An L3 glaube ich irgendwie nicht. Bei GA100 ist der L2 48MB gross ;)

Troyan

2020-10-07, 12:47:24

Und wie soll der Vollausbau von GA104 80% schneller als die 5700 XT sein, wenn die 3070 +- (eher - nach den Zahlen zur 3080) auf dem Niveau der 2080 ti liegen soll. :confused: Soviel können die 2 SMs nicht bringen....

Weil 5% mehr Rechenleistung und 15% mehr Bandbreite in bis zu 15% Mehrleistung münden. Und oh Wunder, 1,5x * 1,15 sind 1,725% (3070 ist 50%+ schneller).

Und das mit 256bit Interface. Warum also sollte AMD das nicht schaffen?

Brillus

2020-10-07, 12:49:56

basix

2020-10-07, 12:53:01

Das schon. Die im Paper kolportierten +50% Energieeffizienz und +20% IPC (bei DNN Anwendungen auch 2-3x) wird man mit einem grösseren L2 nicht erreichen. Das wollte ich damit sagen.

Der_Korken

2020-10-07, 12:53:52

Wenn das denn stimmt ;) Aber ja, dem wäre dann so. Die Frage wäre dann noch ob L2 oder L3. An L3 glaube ich irgendwie nicht. Bei GA100 ist der L2 48MB gross ;)

Der L2 wäre sonst 128 mal so groß wie 8x128kB L1. Das rechtfertigt imho schon eine Zwischenstufe mit besseren Latenzen und kürzeren Wegen.

why_me

2020-10-07, 12:58:23

Weil 5% mehr Rechenleistung und 15% mehr Bandbreite in bis zu 15% Mehrleistung münden. Und oh Wunder, 1,5x * 1,15 sind 1,725% (3070 ist 50%+ schneller).

Und das mit 256bit Interface. Warum also sollte AMD das nicht schaffen?

:confused::confused::confused: Du hast geschrieben: "GA104 im Vollausbau mit 16GBit/s schafft fast die 80% auf 5700XT." -> Das schreibst du als wäre es ein Fakt

Aber scheinbar meinst, dass für 2080 Ti Performance der 3070, die 448GB/s reichen und mit 512GB/s dann auch 80% möglich sind -> theoretische Betrachtung, da stimme ich dir dann auch eventuell zu.

Kleiner Tipp: Du solltest vielleicht etwas auf deine Formulierung achten :wink:

E:
Der L2 wäre sonst 128 mal so groß wie 8x128kB L1. Das rechtfertigt imho schon eine Zwischenstufe mit besseren Latenzen und kürzeren Wegen.

Auch wenn die Zugriffe auf den L2, wie im Paper beschrieben, stark reduziert werden?
Bleibt spannden, ob und wie es AMD am Ende in RDNA2 umgesetzt hat.

basix

2020-10-07, 13:18:41

Der L2 wäre sonst 128 mal so groß wie 8x128kB L1. Das rechtfertigt imho schon eine Zwischenstufe mit besseren Latenzen und kürzeren Wegen.

Wie kommst du auf 8*128kB? Bei 80 CU wären es doch 40 WGP und somit 40*128kB=5120kB?

Viel naheliegender sehe ich eigentlich, dass der L2 auf 128 Mbit und somit 16 MByte aufgebohrt wird. Das wäre verdoppelte L2 Kapazität verglichen mit allen L1 Caches und vierfache Kapazität verglichen zur GDDR6-Bandbreite. Effektivität des Caches gesteigert, ohne dass man den Chip aufbläht.

HOT

2020-10-07, 13:25:16

Was ich bei deinem Argument immer nicht verstehe ist, dass du enormen Wert darauf legst, architektonisch die Konsolen-SOCs von den Desktop-Karten zu unterscheiden, aber gleichzeitig die Taktraten der Konsolen als Maßstab für RX6000 definierst. Das passt doch irgendwie nicht zusammen.
Nene, ich schrieb immer, dass die Implemtentation auf den PC GPUs neuer ist. Warum sollte diese Iteration weniger takten als die Konsole? Das ergibt einfach keinen Sinn, ganz im Gegenteil, man wird auf dem PC eher noch höhere Taktraten sehen.

Adam D.

2020-10-07, 13:49:37

Nene, ich schrieb immer, dass die Implemtentation auf den PC GPUs neuer ist. Warum sollte diese Iteration weniger takten als die Konsole? Das ergibt einfach keinen Sinn, ganz im Gegenteil, man wird auf dem PC eher noch höhere Taktraten sehen.
Aber was heißt denn neuer? Neuer wie völlig neuer Ansatz mit Cache? Woher wissen wir denn, dass solche Überlegungen nicht auch maßgeblichen Einfluss auf Taktbarkeit etc. haben?

Cyberfries

2020-10-07, 14:05:52

Bisher wissen wir über Unterschiede zwischen xBox und RDNA2 nur Linux-Einträge wie num_packer (Rasterizer).
Bei der xBox bereits neue CUs umgesetzt, der Rest noch von RDNA1?

Zur PS5 ist ja noch nichts auf Architekturbasis bekannt.
Außer - wilde Träumerei - wenn xBox N21lite ist, könnte die PS5 dann N22 sein?
PS5 dann näher an RDNA2, deshalb die hohen Taktraten? 6700-Daten dann unbekannt, mglw doch 48-56CU?

edit: gerade selbst einen Fehler in der Träumerei bemerkt - Interface passt nicht.

Der_Korken

2020-10-07, 14:08:26

Auch wenn die Zugriffe auf den L2, wie im Paper beschrieben, stark reduziert werden?
Bleibt spannden, ob und wie es AMD am Ende in RDNA2 umgesetzt hat.

Dazu müsste das Sharing überhaupt auf L1-Ebene umgesetzt worden sein. Allein das halte ich schon für fraglich, weil die L1-Slices der einzelnen SAs teilweise weiter voneinander entfernt sind als der L2 vom L1. Man könnte höchstens die beiden Slices poolen, die zur selben SE gehören, weil die direkt nebeneinanderliegen. Ich würde eher vermuten, dass man innerhalb eines SAs die L0-Caches der CUs zusammenschaltet. Und dann ist man noch lange nicht bei 80% Zugriffsreduktion, denn im Paper wurden dafür 28 CUs zusammengeschaltet, während es bei N21 max. 10 wären (auf L0-Ebene) bzw. 8 (auf L1-Ebene). Je kleiner der Pool, desto kleiner der Benefit.

Wie kommst du auf 8*128kB? Bei 80 CU wären es doch 40 WGP und somit 40*128kB=5120kB?

Die CUs sind L0. Ich meinte den L1 von den einzelnen SAs. Kann natürlich sein, dass die bei RDNA2 nicht mehr 128KB groß sind, aber da kommen sie zumindest her.

basix

2020-10-07, 14:16:43

Ich habe die Angabe aud dem RDNA Whitepaper wohl missverstanden
The graphics L1 cache is shared across a group of dual compute units...
Hier ist bei "group" das Shader Array und nicht ein einzelnes WGP gemeint =)

Complicated

2020-10-07, 14:38:18

Das ist hier ab Minute 3:36 alles erklärt:

https://www.youtube.com/watch?v=CGIhOnt7F6s

Edit: Danke :)
Edit2: nach erneutem editieren gehts nicht mehr...
Edit3: mir zu blöd....

Zergra

2020-10-07, 14:40:59

Das ist hier ab Minute 3:36 alles erklärt:

https://youtu.be/CGIhOnt7F6s
https://youtu.be/CGIhOnt7F6s

Hm...mach ich mit dem Youtube Tag etwas falsch?
https://youtu.be/CGIhOnt7F6s

CGIhOnt7F6s

Das muss in den Tag.

davidzo

2020-10-07, 14:59:49

Bisher wissen wir über Unterschiede zwischen xBox und RDNA2 nur Linux-Einträge wie num_packer (Rasterizer).
Bei der xBox bereits neue CUs umgesetzt, der Rest noch von RDNA1?

Ein Grund, wieso man bei den Konsolen auf einen eher klassischen Ansatz beim Speicherinterface und Cache gesetzt hat, könnte sein dass es sich hier um eine APU handelt. Wer weiß ob eine CPU mit der neuen Cachestruktur bzw. den Latenzen des neuen Speichercontrollers so klar kommt. Zumindest aber verkompliziert dass deutlich die Auslegung eines solchen cache-systems, da ja gemeinsame memory adressing benutzt wird, was Implikationen auf die GPU-caches haben kann.

Iscaran

2020-10-07, 15:01:52

Onur Kayiran, Mohamed Ibrahim, Adwait Jog und andere arbeiten bei AMD schon seit längerer Zeit an der Throughput-Optimierung und den Caches:
https://www.amd.com/en/corporate/research-reports-2018
EDIT: Einfaches googlen nach den Titeln liefert eigentlich zu allen Reports auch die PDFs./EDIT.

RDNA und die damit einhergenden drastischen Verbesserungen in der IPC und P/W relativ zu GCN/Vega sind sicherlich ein ERSTES Resultat des ganzen.

Und mir scheint als ob RDNA nur ein erster Zwischenschritt zur Realisierung all der Konzepte darstellt die diese Jungs in den letzten Jahren so getrieben haben:

Wenn ich den Abstract hier so lese scheint eine "Throughput" Erhöhung um 20% möglich zu sein und zwar auf Workgroup ebene (Workgroup = 1 WGP ?).
https://ieeexplore.ieee.org/document/8327013
Hier das pdf: https://adwaitjog.github.io/docs/pdf/pbs-hpca18.pdf

Aus dem Artikel stammt dieses Bild (siehe Anhang), das die notwendigen Veränderungen im Hardware-Aufbau zeigt um so etwas wie das "DynEB" zu realisieren.

Und die Jungs arbeiten auch daran die ISA zu optimieren um möglichst cache optimiert zu funktionieren.
http://jiemingyin.github.io/docs/HPCA2018.pdf

Ebenfalls schon über 2 Jahre alt:Modular Routing Design for Chiplet-based Systems https://okayiran.github.io/docs/pdf/Routing-ISCA2018.pdf
Die Beschreibung hier geht IMO auch einher mit soetwas wie der Nutzung eines DynEB-Moduls zur Cache-Optimierung. (seht euch mal Figure 2 an !!!)
"In this section, we evaluate a 64-CU system consisting of four chiplets, each with 16 CUs organized as a 4×4 mesh.8
Each chiplet is connected to the interposer through four boundary routers. "

Das ist meiner Meinung nach die Beschreibung einer RDNA Shader Engine ..allerdings bestehend aus 8 WGPs (=16 CUs) angeordnet in einem 4er Chipletdesign auf einem Chip.

Das sind also für AMD "alte" Daten...denn die Publikation dazu ist ja schon von 2018 (d.h. DAVOR wurde das gemacht und "abgeschlossen") - man veröffentlicht so etwas nicht vorab...

Umgemünzt auf RDNA2....vielleicht sehen wir wirklich schon "Chiplets" nämlich die Shader Engines (bestehend aus je 2 "arrays". Vielleicht hab man das deswegen in RDNA1 schon so genannt um damit die Vorstufe der Assemblierbarkeit und Machbarkeit zu testen.

Und hier haben dieselben Leute beschrieben wie der neue Workgroup Scheduler arbeiten muss um optimal die lokal im cache vorliegenden daten optimal weiter zu nutzen:
Quantifying Data Locality in Dynamic Parallelism in GPUs
https://adwaitjog.github.io/docs/pdf/2019_SIGMETRICS_2_Xulong.pdf

Das sind vermutlich nicht zufällig die +20% IPC die RDNA pro WG drauflegt relativ zu GCN (1WG = 1 WGP wenn ich das so richtig verstanden habe).

Ich glaube jetzt langsam dass AMD hier wirklich NUR mit 256 bit GDDR6 kommt für Navi2x.

Und zwar, WEIL hier ein großer Durchbruch gelungen ist die Shader Array/ Cache Struktur zu optimieren welche eben genau den Durchsatz drastisch erhöht durch eine signifikant verbesserte Art von Cache-Optimierung, welche offenbar "application specific" arbeiten kann. Also möglicherweise "trainiert" sich der Chip die Organisation des Caches je nach Datenflow selbst...so daß bei nicht all zu krass wechselndem Input der Cache schon nach kurzer Zeit "optimal" konfiguriert ist um den Data flow zu optimal verabeiten.
Was letztlich zu einer "Einsparung" an benötigten GPU-RAM-Bandbreite von vielleicht +50% führt bei gleichzeitig starken Einsparungen was Powereinsatz für die Verarbeitung der Informationen bedingt (AMD sagte ja selbst P/W von RDNA2 ist +50% relativ zu RDNA1 !)

Berniyh

2020-10-07, 15:11:23

hm, sollte ich an der Stelle erwähnen, dass es da Funktionen zum GDDR6 Memory Training gibt? :D

Gibt aber tatsächlich auch ähnliches bei Vega schon, insofern ist das vermutlich nix neues. ;)

btw. weiß hier zufällig jemand was TCA (bei Vega) bzw. GL2A (bei RDNA1/2) bedeutet?

Ravenhearth

2020-10-07, 15:20:23

https://digistatement.com/wp-content/uploads/2020/10/bO8npNRR5VBRudFL.jpghttps://i.imgur.com/JxRiMWt.png

Hmmm.... :freak:

Iscaran

2020-10-07, 15:23:21

Iscaran

2020-10-07, 15:32:51

basix

2020-10-07, 15:33:54

Wie schon im PCGH Forum geschrieben wurde:

Big Navi ist tot! Lang lebe Long Navi! :D

Iscaran

2020-10-07, 15:35:27

Complicated

2020-10-07, 15:36:26

Das TCA/LCA-Paper liest sich wie eine allgemeine Beschreibung des FCL/RMB:
https://ft.ornl.gov/~lees2/papers/CF12.pdf

Fusion Compute Link.
The FCL provides a highlatency, low bandwidth from the GPU cores to theCPU cache. It’s arbitrated by the UNB, and has thecapability to snoop CPU cache transactions, providingfor full coherency between the CPU and GPU. Due toits low bandwidth (compared to other memory pathsin the system), it should primarily be used for fine-grained data sharing between the CPU and GPU.

Radeon Memory Bus.
The RMB is a much widerbus that connects the GPU cores to the “local” parti-tion of physical memory and mimics the performanceof RAM access in a discrete GPU–high latency andhigh bandwidth. It bypasses all cache (except L1 andtexture), and can saturate DRAM bandwidth

why_me

2020-10-07, 15:36:53

Btw. kann jemand japanisch ?
https://www.coelacanth-dream.com/posts/2020/09/
https://www.coelacanth-dream.com/posts/2020/09/23/rdna_2-note-2020-09-23/
https://www.coelacanth-dream.com/posts/2020/09/23/rdna_2-note-2020-09-23/#shader-array

Google kann das :biggrin:

Hier die unteren beiden links:
https://translate.google.com/translate?sl=auto&tl=de&u=https%3A%2F%2Fwww.coelacanth-dream.com%2Fposts%2F2020%2F09%2F23%2Frdna_2-note-2020-09-23%2F%23shader-array
https://translate.google.com/translate?sl=auto&tl=de&u=https%3A%2F%2Fwww.coelacanth-dream.com%2Fposts%2F2020%2F09%2F23%2Frdna_2-note-2020-09-23%2F

Cyberfries

2020-10-07, 15:37:58

(1WG = 1 WGP wenn ich das so richtig verstanden habe).

Bin mir nicht sicher ob man das gleichsetzen darf, klingt für mich so,
als ob die Größe einer WG flexibel wäre, während eine WGP ja eine starre Einheit zweier CUs ist.

"In this section, we evaluate a 64-CU system consisting of four chiplets, each with 16 CUs organized as a 4×4 mesh.

Auch hier bin ich nicht voll mit WGPs einverstanden, alleine schon wegen dem jeder CU einzeln zugeordneten L1$.
Allerdings irritiert mich da auch die Anbindung des L2$ an die mittleren 8CU,
während nur 4 davon an den Interposer verknüpft werden, kann also sein, dass das Bild nicht 100% akkurat ist.

btw. weiß hier zufällig jemand was TCA (bei Vega) bzw. GL2A (bei RDNA1/2) bedeutet?

Zwar hat Iscaran bereits geantwortet, doch hätte ich raten müssen, hätte ich auf global L2 array getippt.
Bei N10 sind die 16tccs in zwei großen Haufen platziert, äquivalent N22 zwei Haufen, zwei arrays/arbiter?

Hmmm.... :freak:

War auch mein erster Gedanke - die Form ist überraschend ähnlich, nur die Größe passt (angeblich) nicht.

X-Bow

2020-10-07, 15:40:48

Btw. kann jemand japanisch ?
https://www.coelacanth-dream.com/posts/2020/09/
https://www.coelacanth-dream.com/posts/2020/09/23/rdna_2-note-2020-09-23/
https://www.coelacanth-dream.com/posts/2020/09/23/rdna_2-note-2020-09-23/#shader-array

Oder chinesisch?
https://www.chiphell.com/forum.php?mod=viewthread&tid=2264233&mobile=1

E: Wenn man dass durch den Google-Übersetzer jagt klingt das eher nach reiner Speku von PolyMorph (kennt den wer?)

Iscaran

2020-10-07, 15:48:29

Auch hier bin ich nicht voll mit WGPs einverstanden, alleine schon wegen dem jeder CU einzeln zugeordneten L1$.
Allerdings irritiert mich da auch die Anbindung des L2$ an die mittleren 8CU,
während nur 4 davon an den Interposer verknüpft werden, kann also sein, dass das Bild nicht 100% akkurat ist.

Mit Sicherheit ist das nicht 100% "RDNA2" - oder auch nur annähernd das was wir als RDNA1 kennen. Aber das sind die Forschungs-/Entwicklungsarbeiten dazu IMHO.

Zwar hat Iscaran bereits geantwortet, doch hätte ich raten müssen, hätte ich auf global L2 array getippt.
GL2A :-)

Bei N10 sind die 16tccs in zwei großen Haufen platziert, äquivalent N22 zwei Haufen, zwei arrays/arbiter?

War auch mein erster Gedanke - die Form ist überraschend ähnlich, nur die Größe passt (angeblich) nicht.

Jeder Array braucht seinen eigenen Arbiter (?) um den Cache zu verwalten, wenn ich die ganzen Forschungspaper einigermaßen richtig verstehe.

Das würde doch dann passen.

why_me

2020-10-07, 15:52:39

Oder chinesisch?
https://www.chiphell.com/forum.php?mod=viewthread&tid=2264233&mobile=1

E: Wenn man dass durch den Google-Übersetzer jagt klingt das eher nach reiner Speku von PolyMorph (kennt den wer?)

Natürlich ist das reine Speku, das Bild ist glaube ich schon vor 1-2 Monaten durch die Foren gegeistert.

Iscaran

2020-10-07, 15:59:03

https://translate.googleusercontent.com/translate_c?depth=1&pto=aue&rurl=translate.google.com&sl=auto&sp=nmt4&tl=de&u=https://www.coelacanth-dream.com/posts/2020/08/18/hc32-matome_1/&usg=ALkJrhhFJsOSQfb1JsbNJ6IFX-JaBCtfDg

Das ist interessant: Hier wird die Packdichte am Beispiel der Zen Cores verglichen und zwar zwischen 7nm und dem 7nm "verbessert" Prozess der bei der XBox kommt.

RDNA2 soll doch auch auf 7nm+ oder so ("verbessert" ?) kommen.

So oder so der Zen Kern hat sich um ca 5% beim Kern und ca 15% beim L3 Cache verkleinert.

Gemäß dem hier w#ren von den 361 mm^2 des XBoxs Chips ca. nur 57 mm^2 die 8 Zen Kerne ?!?

Wow...blieben fast 300 mm^2 für den "GPU-Part".

basix

2020-10-07, 16:02:02

Gemäß dem hier w#ren von den 361 mm^2 des XBoxs Chips ca. nur 57 mm^2 die 8 Zen Kerne ?!?

Wow...blieben fast 300 mm^2 für den "GPU-Part".

Es gibt ein gutes Video von DF, wo die Flächenmasse anhand des Hot Chips Die Shots erläutert werden. Die komplette GPU benötigt 170mm2, dazu kommen noch I/O, VCN und Speicherinterface. Die 8C auf dem XBSX Chip benötigen ca. 40mm2, gleich wie bei Renoir.

Der_Korken

2020-10-07, 16:25:28

Und hier haben dieselben Leute beschrieben wie der neue Workgroup Scheduler arbeiten muss um optimal die lokal im cache vorliegenden daten optimal weiter zu nutzen:
Quantifying Data Locality in Dynamic Parallelism in GPUs
https://adwaitjog.github.io/docs/pdf/2019_SIGMETRICS_2_Xulong.pdf

Das ist in Bezug auf Speicherbandbreite schon wesentlich interessanter. Habe nur den Abstract gelesen, weil ich vom Rest eh nicht so viel verstehen werde:

We observe that, for DP applications, data reuse is highly irregular and is heavily dependent on the application and its input. Thus, existing techniques cannot exploit data reuse efectively for DP applications. To this end, we first conduct a limit study on the performance improvements that can be achieved by hardware schedulers that are provided with accurate data reuse information. This limit study shows that, on an average, the performance improves by 19.4% over the baseline scheduler. Based on the key observations from the quantitative analysis of our DP applications, we next propose LASER, a Locality-Aware SchedulER, where the hardware schedulers employ data reuse
monitors to help make scheduling decisions to improve data locality at runtime.

Wenn ein Frame so berechnet wird, dass die Teile, die die selben Daten nutzen, zeitlich dicht zusammen und auf den selben CUs berechnet werden, dann spart man insgesamt tatsächlich Speicherbandbreite ein, weil die Datenlokalität höher ist und die Caches besser ausgenutzt werden. Unabhängig davon wie die Caches intern realisiert sind. Wenn mehr aus dem Cache gerechnet wird, dann schlägt natürlich eine Verbesserung auf Cache-Ebene stärker durch. Diese Verbesserungen gehen also Hand in Hand. Gipsel hatte damals zu Pascal-Zeiten auch mal aufgedröselt, wie die ganzen Verbesserungen (Cache-Hierachie, Kompression Tiled Rendering) ineinandergreifen und dass es nicht DAS Killerfeature gibt, welches Maxwell damals so effizienz gemacht hat.

Angesichts der ganzen Möglichkeiten, die sich hier auf Architetkur-Ebene bieten, sind die ganzen Diskussionen um 8 CUs mehr oder weniger fast schon Schall und Rauch :D

Iscaran

2020-10-07, 16:31:15

@Der_Korken:
Ja ich hab eigentlich auch nur Abstract/Conclusion gelesen und ein bisschen querbeet + Bilder.

Die Daten die zu einem Frame gehören kennt man ja aber eigentlich, d.h. wenn der CacheController (nenne ich jetzt mal so), also das Ding das das DynEB macht, z.B. die Daten anhand dessen ob sie zu Frame1 gehören oder zu Frame2 gehören markiert...und falls so etwas z.B. vorher nicht gemacht wurde, dann könnten diese ganzen Bandbreiten-Effekte einfach damit zusammenhängen.

So oder so - vielleicht gibt AMD morgen ein ganz klitze-klein wenig was Preis :-). Ich hoffe es jedenfalls.

dargo

2020-10-07, 16:33:01

https://digistatement.com/wp-content/uploads/2020/10/bO8npNRR5VBRudFL.jpghttps://i.imgur.com/JxRiMWt.png

Hmmm.... :freak:
Immer diese Scheibchen. :D

Wie schon im PCGH Forum geschrieben wurde:

Big Navi ist tot! Lang lebe Long Navi! :D
;D :uup:

Btw. kann jemand japanisch ?
https://www.coelacanth-dream.com/posts/2020/09/
https://www.coelacanth-dream.com/posts/2020/09/23/rdna_2-note-2020-09-23/
https://www.coelacanth-dream.com/posts/2020/09/23/rdna_2-note-2020-09-23/#shader-array
Nimm doch einfach den Google-Übersetzer.

Edit:
Kannst du damit was anfangen?
BIG_PAGE-Funktion zum Einsparen von Bandbreite
Es wird als eine Funktion beschrieben, die den Datenverkehr zwischen CB (Befehlspuffer?) / DB ( Datenpuffer ?) / TCP reduziert, wenn der Puffer einer bestimmten Ausrichtung entspricht .
radv: Setzen Sie BIG_PAGE, um die Leistung unter GFX10.3 (f4d86169) zu verbessern. · Commits · Mesa / mesa · GitLab
Es ist unklar, wofür TCP steht, aber es scheint sich auf den L1-Vektor-Cache in der CU zu beziehen (L0-Vektor-Cache in der RDNA-Architektur). 3

Darüber hinaus hat die RDNA 2 / GFX 10.3- Generierung Maßnahmen implementiert, um Speicherbandbreite im Render-Backend-Teil und im Teil, der sich auf den Frame-Puffer bezieht, zu sparen, z. B. die Größe des Blocks, der Farbkomprimierung und DCC (Delta Color Compression) ausführt. 4
Diese Funktionen sind auch für dGPUs mit dediziertem Breitbandspeicher wirksam. Ich denke jedoch, dass sie besonders für APUs nützlich sind, bei denen die Bandbreite eingeschränkt ist, da sie mit der CPU gemeinsam genutzt wird.

https://gitlab.freedesktop.org/mesa/mesa/-/commit/f4d861696dfb11dc2b6242a683a13238981f705f?merge_request_iid=6482

Berniyh

2020-10-07, 16:34:48

TCA = tightly coupled accelerator ?
https://books.google.de/books?id=HNm9BwAAQBAJ&pg=PA469&lpg=PA469&dq=TCA+memory+access+driver&source=bl&ots=LSQWzwSm9Y&sig=ACfU3U1P_ocJIS6fCHnaX2dfg2t-xIhZJg&hl=de&sa=X&ved=2ahUKEwiy7cGGyaLsAhWNy6QKHWN2DUcQ6AEwA3oECAIQAg#v=onepage&q=TCA%20memory%20access%20driver&f=false
http://www1.cs.columbia.edu/~luca/research/cota_DAC15.pdf

GL2A = GL2 Arbiter ?
Wird hier als Equivalent zu TCA bei Navi10/14 beschrieben ?
https://www.coelacanth-dream.com/posts/2020/01/14/amdgpu-abbreviation/
Danke ja, das scheint korrekt zu sein. Weiß zwar trotzdem nicht wirklich was damit anzufangen, aber zumindest der Begriff wäre damit aufgelöst. ;)

Danke für die Seite die werde ich mir mal abspeichern, das könnte hier und da beim Lesen des Codes hilfreich sein.

Berniyh

2020-10-07, 16:36:10

Umio Yasuno hat offenbar auf Github eine größere Repository von Firmwares liegen:
https://github.com/Umio-Yasuno/unofficial-amdgpu-firmware-repo

Arcturus
Sienna Cichlid
Navy Flounder
Navi10, 12, 14 usw.
Das sind halt die die man aus den diversen Treibern und dem linux-firmware repo bekommt.
Discovery Binary wäre interessanter. ;)

Dural

2020-10-07, 16:44:22

Sony hat ein Teardown Video mit der PS5 online gestellt: 350Watt NT, 120x45mm Lüfter, Flüssigmetall WP... das hört sich alles extrem nach den maximal 150Watt für die GPU von dargo an. ;)

https://www.computerbase.de/2020-10/sony-playstation-5-teardown/

Linmoum

2020-10-07, 16:45:59

Jo, das kann GPU-only gut passen. PS4 Pro hat übrigens ein 310W PSU und zieht irgendwas um die 170W unter Volllast.

Dural

2020-10-07, 16:54:35

Auch interessant: der Sony Mensch spricht von schwieriger Kühlung der APU.

Die Gerüchte besagen auch das die GPU mit dem hohen Takt Probleme macht und die Ausbeute schlecht sei.

dildo4u

2020-10-07, 16:57:18

Passt nicht zur Sony Aussage das sie im ersten Jahr mehr PS5 als PS4 verkaufen wollen auch hätten sie dann nicht das 399€ Modell gebracht.

https://www.videogameschronicle.com/news/sony-expects-playstation-5-sales-to-top-7-million-by-march-2021/

Adam D.

2020-10-07, 16:59:44

Auch interessant: der Sony Mensch spricht von schwieriger Kühlung der APU.

Die Gerüchte besagen auch das die GPU mit dem hohen Takt Probleme macht und die Ausbeute schlecht sei.
Ach die Gerüchte sind jetzt auf einmal glaubhaft? Verstehe :freak: Und was heißt schon schwierig zu kühlen: die ersten Erfahrungsberichte bescheinigen dem Teil eine beeindruckende Laufruhe. Also wie immer nur substanzloses blablablub von dir.

dargo

2020-10-07, 17:01:52

Ach die Gerüchte sind jetzt auf einmal glaubhaft? Verstehe :freak: Und was heißt schon schwierig zu kühlen: die ersten Erfahrungsberichte bescheinigen dem Teil eine beeindruckende Laufruhe. Also wie immer nur substanzloses blablablub von dir.
Du musst einfach Dural verstehen... alle Gerüchte zu AMD-GPUs die in irgendeiner Weise negativ sind sind einfach Fakten. ;)

Daredevil

2020-10-07, 17:02:13

dargo

2020-10-07, 17:06:11

Nicht Ampere blockiert die AIBs sondern Nvidia bzw. Samsung. ;)

Iscaran

2020-10-07, 17:13:20

@dargo:

Edit:
Kannst du damit was anfangen?

https://gitlab.freedesktop.org/mesa/mesa/-/commit/f4d861696dfb11dc2b6242a683a13238981f705f?merge_request_iid=6482

Der Google-Übersetzer sagt zu den Gedanken des netten Japaners:

Darüber hinaus hat die RDNA 2 / GFX 10.3 Maßnahmen implementiert, um Speicherbandbreite im Render-Backend-Teil und im Teil, der sich auf den Frame-Puffer bezieht, zu sparen, z. B. die Größe des Blocks, der Farbkomprimierung und DCC (Delta Color Compression) ausführt.
Diese Funktionen sind auch für dGPUs mit dediziertem Breitbandspeicher wirksam. Ich denke jedoch, dass sie besonders für APUs nützlich sind, bei denen die Bandbreite eingeschränkt ist, da sie mit der CPU gemeinsam genutzt wird.

Scheint mir irgendwie auf eine weitergehende Cache-Optimierung wie sie nun seit einigen Seiten in der Diskussion ist hinzuweisen.

Adam D.

2020-10-07, 17:20:04

Sagt mal, wenn ampere die AIBs aktuell „blockiert“, da die Nachfrage riesig ist und die Preise, die abgerufen werden, ebenso, blockiert das nicht auch die Produktion von AMD?
Ist das Stückchenweise ausgeben und der Druck, den den AIBs verspüren ( außer die exklusiven AIBs von AMD ) so groß, dass sie AMD vielleicht vernachlässigen könnten?
Es geht ja darum, Geld zu verdienen, das geht bei Nvidia gerade sehr gut. ( mondpreise... )

Würde ich natürlich sehr schade finden, könnte aber ne fiese Strategie von Nvidia sein. :K
Womit sind die AIBs denn beschäftigt, wenn sie keine GPUs von Nvidia bekommen? An sich ist es doch eher eine große Chance, wenn AMD ein gutes Produkt wortwörtlich abliefert. Nachfrage genug scheint ja da zu sein. GDDR6X brauchen sie auch nicht, falls der knapp sein sollte (wozu ich keine Infos habe).

dargo

2020-10-07, 17:22:34

Selbst wenn es so wäre geht das Sapphire, Asrock, Powercolor und XFX am Allerwertesten vorbei was Nvidia macht.

https://digistatement.com/wp-content/uploads/2020/10/bO8npNRR5VBRudFL.jpghttps://i.imgur.com/JxRiMWt.png

Hmmm.... :freak:
Das ist der PS5 SoC du Sack. :ubash:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12451871&postcount=14647

Berniyh

2020-10-07, 18:19:41

@Iscaran:
So vom ersten Anschauen würde ich nicht auf Cache-Optimierungen tippen, sondern das generelle Layout der GPU.

bzgl. der Cache-Geschichten würde ich darauf tippen, dass wenn das stimmt, es absolut transparent gegenüber der Software abläuft, d.h. komplett in Hardware implementiert ist.
Selbst wenn es so wäre geht das Sapphire, Asrock, Powercolor und XFX am Allerwertesten vorbei was Nvidia macht.

Das ist der PS5 SoC du Sack. :ubash:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12451871&postcount=14647
Dann wissen wir zumindest woher der "Leaker" neulich sein Chip Foto her hatte. :freak:

dargo

2020-10-07, 18:22:06

Dann wissen wir zumindest woher der "Leaker" neulich sein Chip Foto her hatte. :freak:
Genau. ;D

Edit:
Wobei der Leak trotzdem N21 darstellen könnte. Mir kommt der PS5 SoC schmaler vor. Und die Bauteile um den SoC herum sind auch anders angeordnet als beim Leak.

Daredevil

2020-10-07, 19:03:58

Womit sind die AIBs denn beschäftigt, wenn sie keine GPUs von Nvidia bekommen?
Ist das so? Ich hatte mal von asus gelesen, dass sie Probleme mit der Fertigung haben, also halt nicht den Bedarf der Bestellungen decken können und es nicht an GPUs mangelt.
Deswegen schrieb ich ja hier, wenn die AIBs ihre Kapazitäten erhöhen, könnte AMD darunter vielleicht leiden?

dargo

2020-10-07, 19:11:30

Ist das so? Ich hatte mal von asus gelesen, dass sie Probleme mit der Fertigung haben, also halt nicht den Bedarf der Bestellungen decken können und es nicht an GPUs mangelt.

Link? Zumal ASUS wohl kaum offiziell zugeben wird, dass die zu wenig GPUs bekommen.

Deswegen schrieb ich ja hier, wenn die AIBs ihre Kapazitäten erhöhen, könnte AMD darunter vielleicht leiden?
ASUS und Radeon ist eh wayne. Dort hatte ASUS noch nie mit guter Kühlung geglänzt. Bei Radeon ist Referenz nach wie vor Sapphire, Powercolor und eventuell MSI. Wobei mich MSI bei Navi10 eher enttäuscht hat. Riesen Materialaufwand und trotzdem keine überragende Kühlung (zu laut). Und das war sogar eine non XT mit ~125W GPU-Power da oftmals per Default taktlimitiert.

davidzo

2020-10-07, 19:30:17

Genau. ;D

Edit:
Wobei der Leak trotzdem N21 darstellen könnte. Mir kommt der PS5 SoC schmaler vor. Und die Bauteile um den SoC herum sind auch anders angeordnet als beim Leak.

Das ist ein relativ kleiner chip und Package, eher wie Navi10 oder GA104. Das passt nicht zu einer highend Karte, aber sehr gut zum eher sparsamen PS5 soc. Es sind etwa dieselben Abmessungen wie der PS4 soc mit ebenfalls 256bit, der DIE ist sogar kleiner.
Die Widerstandsnetzwerke und drosselspulen sind ziemlich sicher 0201, also 0.6*0.3mm bzw im Falle der resistorarray 0,8*0,6*0.35. Größere packages wären für den DIE zu dick und würden an den Kühler stoßen. In dem leakfoto sind diese aber viel kleiner als beim PS5 So, es ist aber ziemlich sicher dieselbe baugröße. Ein Die ist auch selten höher als 0.7mm und der Dieshim ist ebenso eher dünner. Man sieht eigentlich auch an den Leiterbahnen dass das ein eher kleines package ist, also eher 40x40mm.

Das was wir auf der Platinenrückeite vom N21 engineeringboard gesehen haben gehört zu einem viel größeren package. Das Drosselspulenarray und der Andruckrahmen sieht sogar größer aus als bei Vega64, wobei das nicht viel heißen muss.https://wccftech.com/amd-radeon-rx-vega-and-polaris-gpu-engineering-boards-spotted/
BTW, da sieht man das AMD für die Vega56 mal ein 3080-like superkurzes PCB und Kühler geplant hatte, nur ohne die verspielten V-förmigen lamellen und die Vaporchamber die die Heatpipes verbindet.

Navi21 könnten eher 45*45 bis 50*50mm, sieht aber auf dem Card shot auch eher nach einem länglichen package aus.Nicht quadratisch wäre ein Novum für AMD.

Nazar

2020-10-07, 19:42:00

Sagt mal, wenn ampere die AIBs aktuell „blockiert“, da die Nachfrage riesig ist und die Preise, die abgerufen werden, ebenso, blockiert das nicht auch die Produktion von AMD?
Ist das Stückchenweise ausgeben und der Druck, den den AIBs verspüren ( außer die exklusiven AIBs von AMD ) so groß, dass sie AMD vielleicht vernachlässigen könnten?
Es geht ja darum, Geld zu verdienen, das geht bei Nvidia gerade sehr gut. ( mondpreise... )

Würde ich natürlich sehr schade finden, könnte aber ne fiese Strategie von Nvidia sein. :K

Es kann nur dann etwas "blockiert" sein, wenn etwas vorhanden ist, um es blockieren zu können. De facto gibt es keine Chips die irgend etwas blockieren können oder glaubst du ernsthaft das Gesülze der Lederjacke, dass nicht zu wenig Chips da sind, sondern die Nachfrage zu hoch ist? :freak:
Igor selbst hatte mal erklärt, dass die AIBs sich über einen Mangel von Ampere Chips beschweren und sie nicht mal ansatzweise ihre Produktstraßen auslasten können. Was soll da also wo blockiert sein? :confused:

SKYNET

2020-10-07, 20:06:21

ianm

2020-10-07, 20:10:03

http://m.quickmeme.com/img/79/79af6b3bc5b23131ace1d835c402fa444ebd7cfc574c6b040665280337e74d7e.jpg

Achill

2020-10-07, 20:37:33

ich sehe es kommen... navi21 ist nen SoC... rdna2 80CUs und zen3 8C/16T... somit ist die graka dann komplett autonom und muss keine umwege mehr über die CPU machen... das würde das gesammtsystem massivs beschleunigen, dann würde auch die SSD auf der rückseite vom PCB sinn ergeben über die spekuliert wurde.

Fast ... der SoC ist in Absprache mit Sony so umgesetzt, sodass man jetzt auch am PC mit M+K oder Pad die PS5 exclusives auf BigFatNavi spielen kann - unabhängig ob jetzt Windows, Linux oder Mac als Host für In- und Output der benötigten Peripherie zum Einsatz kommt. TRUE! :freak: :D ;)

Fun Fakt ist dann auch, dass zukünftige MacPro-User mit Apple-CPUs weiterhin auf x64 bei Bedarf zurück greifen können - also x64 to go.

gedi

2020-10-07, 21:15:57

=Floi=

2020-10-07, 21:39:19

keine umwege mehr über die CPU machen... das würde das gesammtsystem massivs beschleunigen,

wegen der intel cpu? :ugly:

theoretisch gäbe es für so eine karte schon kunden. Es gibt ja wirklich noch genig rechner mit 4-6 kerne.

NV phantasierte ja mal etwas mit arm kernen in der gpu. Eventuell bringt das AMD. An sich wäre das für bestimmte aufgaben ganz cool.

Berniyh

2020-10-07, 21:54:17

Genau. ;D

Edit:
Wobei der Leak trotzdem N21 darstellen könnte. Mir kommt der PS5 SoC schmaler vor. Und die Bauteile um den SoC herum sind auch anders angeordnet als beim Leak.
Er sagt er hat für die Seiten 29.5 und 18.5 gemessen. Das gibt ein Seitenverhältnis von 1.6:1.
Die PS5 hat ein Seitenverhältnis von etwa 1.8:1:
https://forum.planet3dnow.de/index.php?threads/amd-opn-chaos-eine-%C3%9Cbersicht-der-neuen-amd-cpus-und-apus-2020-08-24.433472/page-4#post-5303013

Berniyh

2020-10-07, 22:48:40

Ich hab mir mal den Spaß gemacht ein bisschen zum potentiellen Release-Datum diverser Chips zu spekulieren. :D

Basis ist Patch Datum des asic Patches im Linux Kernel sowie Release Datum. Daraus ergibt sich die Differenz in Tagen:
Navi 10: 17
Navi 12: 273
Navi 14: 150
Renoir: 344
Sienna Cichlid/Navi 21: 147

Navi 10 war auffällig spät, was aber evtl. der Tatsache geschuldet war, dass AMD damals noch etwas mehr hinten dran war mit der Code Veröffentlichungen und, dass es ja die erste RDNA Implementierung überhaupt war.
Navi 12 taugt als Referenz auch nicht wirklich, da Custom Project, würde ich auch außen vor lassen.
Bleiben Navi 14, Renoir und Sienna Cichlid. Navi 14 war ja tatsächlich eher 1-1.5 Monate früher erwartet worden. Renoir hingegen ist auffällig spät, war aber meines Wissens ursprünglich eher zu Jahresbeginn erwartet worden.
Generell scheint mir ca. 150 Tage jedenfalls ein halbwegs vernünftiger Wert zu sein.

Daraus ergibt sich dann (120 Tage / 150 Tage / 180 Tage)
Navy Flounder / Navi 22: 12.11.2020 / 12.12./2020 / 11.01.2021
Green Sardine / Lucienne: 04.02.2021 / 06.03.2021 / 05.04.2021
Dimgrey Cavefish / Navi 23: siehe Lucienne
Van Gogh: 28.01.2021 / 27.02.2021 / 29.03.2021

Ist natürlich alles andere als dingfest, siehe Renoir. ;)
Insbesondere, wenn es sich Chips handelt, die potentiell nur an OEMs gehen oder evtl. gar Custom sind (kann man bei Van Gogh, Lucienne und Navi 23 derzeit nicht wirklich komplett ausschließen, wobei es zumindest bei Van Gogh eher unwahrscheinlich ist, wenn die geleakte Roadmap stimmt).
Dennoch kann man daraus vermuten, dass ein Release von Navi 22 noch in diesem Jahr recht wahrscheinlich ist und Navi 23 durchaus im ersten HJ 2021 zu erwarten wäre.
Und selbst wenn es derzeit so geplant wäre, kann sich ein Release immer noch verschieben (wie vermutlich bei Navi 14 passiert).

Und, und ich habe gelernt, dass Navi eigentlich für Ivan steht, aber das nur am Rande. :D

SKYNET

2020-10-08, 00:50:54

wegen der intel cpu? :ugly:

theoretisch gäbe es für so eine karte schon kunden. Es gibt ja wirklich noch genig rechner mit 4-6 kerne.

NV phantasierte ja mal etwas mit arm kernen in der gpu. Eventuell bringt das AMD. An sich wäre das für bestimmte aufgaben ganz cool.

kommt grad ne meldung beim boot "this CPU is not compatible with this graphics pls upgrade to a highend CPU from AMD n shred ur silicon crap from intel somewhere" ;D

BigKid

2020-10-08, 08:44:28

... das Gesülze der Lederjacke, dass nicht zu wenig Chips da sind, sondern die Nachfrage zu hoch ist? :freak:
Wir haben nicht zu wenig zu essen - die Leute haben einfach zuviel Hunger...
Wenn er das so gesagt hat ist das doch Neusprech...
Wenn sie nach dem letzten Launches inklusive Mining-Run tatsächlich von der Nachfrage überrascht worden sind (was er vermutlich ausdrücken wollte) dann hat da aber jemand seine Hausaufgaben nicht gemacht...

Piefkee

2020-10-08, 09:18:17

Adam D.

2020-10-08, 09:30:12

ianm

2020-10-08, 09:32:19

Die Frage ist jetzt halt, ob XT 3080 oder 3070-Gegner ist.
80 CUs. Die Frage kannst du dir auch selber beantworten...

WedgeAntilles

2020-10-08, 09:38:44

80 CUs. Die Frage kannst du dir auch selber beantworten...

Wie oft hieß es das in den letzten Jahren? Dass es absolut 100% sicher sei, dass das neue Produkt von AMD was weiß ich wie gut werden wird?

Wir werden es sehen.

Linmoum

2020-10-08, 09:41:11

Das hieß es immer, weil man dachte, dass AMD es mit GCN irgendwann endlich mal schafft, die vorhandene Rohleistung auf die Straße zu bringen. Die Frage stellt sich seit RDNA aber nicht mehr.

Zergra

2020-10-08, 09:43:42

Doch tut sie, bei RDNA gibt es bis jetzt nur einen 40CU Chip, wie das ganze bei 80CU aussieht weiß noch keiner. Die 256bit bestärken mich daran, das der Chip unter der 3080 landen wird.

Linmoum

2020-10-08, 09:48:26

Polaris hatte auch nur 36CU und konnte die Rohleistung nicht annähernd auf die Straße bringen. Und nur das SI isoliert betrachten ist naiv.

ianm

2020-10-08, 09:49:25

Dann schau dir die Patente der letzten Tage nochmal an. AMD hat gute Ideen. Heute räumt Zen 3 erstmal ab, in drei Wochen dann hoffentlich RDNA2.

Vor Dezember und den 20/16GB Karten bleibt Nvidia sowieso uninteressant.

WedgeAntilles

2020-10-08, 09:56:26

Dann schau dir die Patente der letzten Tage nochmal an. AMD hat gute Ideen. Heute räumt Zen 3 erstmal ab, in drei Wochen dann hoffentlich RDNA2.

Das Potential bestreite ich nicht.
Aber es hier als Fakt darzustellen und jeden, der zweifelt fast als Idioten ist halt schlicht falsch.

Bei Zen3 ist klar, dass wir heute etwas Gutes sehen werden. Da gibt es ja genug Leaks von Benches, damit man da seit Monaten quasi von Monat zu Monat freudiger auf die offizielle Vorstellung wartet :)
RDNA2 kann gut werden, kann ein Reinfall werden.

Das wir bisher keinerlei Benchs oder ähnliches von RDNA2 geleakt bekommen deutet für micht jedenfalls nicht auf einen riesigen Erfolg hin.
Klar, das muss auch nichts heißen.
Es gibt Punkte die auf einen großen Erfolg von RDNA2 hindeuten.
Und es gibt Punkte, die auf eine Enttäuschun hindeuten.

Wer welche Punkte wie gewichten will bleibt jedem selber überlassen.

Wie eben gesagt - es wird sich zeigen wie gut RDNA2 wird, Stand heute ist da gar nichts sicher.

Zergra

2020-10-08, 10:04:32

Dann schau dir die Patente der letzten Tage nochmal an. AMD hat gute Ideen. Heute räumt Zen 3 erstmal ab, in drei Wochen dann hoffentlich RDNA2.

Patente bedeuten erstmal überhaupt nichts! Nur das man mal in die Richtung gedacht hat. Ob das etwas bringt oder sinnvoll umsetzbar ist, hat damit nichts zu tun.

Ich würde mich freuen wenn AMD mal wieder konkurrenzfähig wäre, aber dafür sind einfach noch zuviele Punkte offen.

Iscaran

2020-10-08, 10:08:25

Ich hab noch ein wenige auf Coelacanths Seite rumgegraben:

Viel interessanter finde ich, daß es eine PCI-ID für Navi21 Lite gibt
gfx 1020
https://translate.googleusercontent.com/translate_c?depth=1&pto=aue&rurl=translate.google.com&sl=auto&sp=nmt4&tl=de&u=https://www.coelacanth-dream.com/posts/2020/06/22/amdgpu-gpuid-mean/&usg=ALkJrhhNfXadF7D5gEmi1aPNzhbX4rh0zA

"RDNA 2 / Navi2x zu gewidmet ist (gfx103x). (gfx102x) wurde übersprungen, ist aber vorhanden, und Navi21_Lite / nv21_lite wird als gfx1020 bezeichnet . Es gibt auch Navi10_Lite / nv10_lite für 3 gfx1000 mit dem Codenamen Ariel ."

Die PCI IDs scheinen aus dem RocM zu stammen.

Ebenfalls interessant: LLVM hat Ray Tracing Befehle für RDNA2 erhalten (das ist wohl die korrekte Übersetzung und nicht "späte Rennen")
https://translate.googleusercontent.com/translate_c?depth=1&pto=aue&rurl=translate.google.com&sl=auto&sp=nmt4&tl=de&u=https://www.coelacanth-dream.com/posts/2020/09/17/llvm-amd-gfx1030-rt-inst/&usg=ALkJrhiad3JO-ggA_-Ty3p7fiSpU6HMijA

Auch auffälig: Sienna Cichlid Chips tragen ZWEI MediaEngines ?!?
"Nur Sienna Cichlid hat zwei VCN3s
....
Es besteht die Möglichkeit, dass die Schaltkreise, die für die Teilung nicht erforderlich sind, entfernt wurden. Da dies jedoch zusätzlichen Aufwand erfordert, sind die Funktionen asymmetrisch, aber ich denke, dass beide tatsächlich in derselben Schaltung implementiert sind.
Durch die klare Trennung der Rollen wird es jedoch einfacher, den Stromverbrauch durch ein Power-Gating zu reduzieren, das die Stromversorgung des Geräts stoppt.
Im Vergleich zu Navy Flounder mit einem VCN3 wird Sienna Cichlid hinsichtlich der Energieeffizienz überlegen sein , obwohl es mehr Chipgröße und mehr Transistoren haben wird."

https://translate.googleusercontent.com/translate_c?depth=1&pto=aue&rurl=translate.google.com&sl=auto&sp=nmt4&tl=de&u=https://www.coelacanth-dream.com/posts/2020/09/01/rdna_2-note-2020-09-01/&usg=ALkJrhhyLet4mTVXOKs5lV0ztNc4F1kjfg

Das ergibt doch eigentlich nur Sinn, wenn man sich damit irgendwie die Erstellung einer neuen Maske oder so spart, oder das ganze eben als ein 2-Chip-Modul konstruiert ist (aus z.B. 2x N22). Die verdoppelte MediaEngine ist halt dann "überflüssig" - man nutzt es aber um durch besseres PowerGating ein bissel strom zu sparen und das Codieren respektive De-Codieren wird dann auf je 1 dedizierte Mediaengine verteilt.
Bei Flounder und Cavefish gibt es nur 1 Mediaengine die BEIDES in einem macht.

Und dann bin ich noch auf diese Unterschiede bzgl. MAD und FMA Befehlen gestoßen die auch Coelacanth merkwürdig findet:
https://translate.googleusercontent.com/translate_c?depth=1&pto=aue&rurl=translate.google.com&sl=auto&sp=nmt4&tl=de&u=https://www.coelacanth-dream.com/posts/2020/09/16/amd-gcn-rdna-fma-mad/&usg=ALkJrhiGQWqoSSRRlN3XyHqXm8jYRqxA4g

Dazu kann ich aber keine Wertung vornehmen - vielleicht kann jemand anderes damit mehr anfangen. Allerdings scheint RDNA1 also Navi10 hier noch "herkömmlich" zu arbeiten, erst GFX1030 führt die MAD-Operation über FMA durch gemäß Treibereintrag ?

Das einzige was ich ganz unten bei diesem Eintrag noch finde ist folgende Spekulation:
"Es wird angenommen, dass der Grund, warum der MAD-Rechner in RDNA 2 / GFX 10.3 (wahrscheinlich) weggelassen wurde, darin besteht, die Montagedichte von WGP (2CU) zu erhöhen, aber die Richtigkeit kann nicht garantiert werden. Ich wäre dankbar, wenn AMD die Details erklären könnte."

Das könnte ich als Idee verstehen wie AMD die Packdichte in den CUs erhöhen möchte von RDNA1 => RDNA2 ?

Und noch eine kleiner Brocken...hier erläutert AMD Memory Hierarchy von GCN und RDNA im Vergleich, für die deutlich qualifizierteren hier die damit mehr anfangen können:
https://gpuopen.com/wp-content/uploads/2019/08/RDNA_Architecture_public.pdf
viele Der weiter oben verlinkten Paper scheinen da bereits teilweise eingeflossen zu sein...aber eben noch nicht alles.
Ein Weiteres Indiz das RDNA2 nochmals deutlich an der Memory Hierarchie "schraubt".

ianm

2020-10-08, 10:10:04

Wo nenne ich jemanden einen Idioten?

RDNA war auf seinem Level konkurrenzfähig zu Turing. Und altert AMD üblich wieder besser als Nvidia. Die 3070 landet in Nvidias ausgesuchten Benchmarks auf 2080ti Niveau. Wie aussagekräftig diese waren hat man bei der 3080 gesehen. Hinzu kommen nur 8GB RAM.

Doppelt soviele CUs, höhere IPC, mehr RAM und dann nur 2080ti Niveau? Wer glaubt sowas?

Kriegsgeier

2020-10-08, 10:21:57

RDNA2...kann ein Reinfall werden.

Das schließe ich aus, denn wir haben die Daten von XBox SERIES X:

RDNA2 mit 56 CUs + 8 Kern ZEN2 + Rest = Netzteil ca. 300 Watt!

Bei ca. 12 TFlops! Las es dir auf der Zunge zergehen: ca. 12 TF bei sagen wir mal 130-150 Watt (reine GPU + 16 GB GDDR6)

Berniyh

2020-10-08, 10:31:11

Viel interessanter finde ich, daß es eine PCI-ID für Navi21 Lite gibt
gfx 1020
Das ist keine PCI ID, sondern eine AMD-interne GPU ID. ;)
Dass die Lite 10.2 ist und nicht 10.3 wie Navi 21 wissen wir schon seit Ewigkeiten.
Daher war auch damals schon die Vermutung, dass das irgendein Dev Board, Prototyp oder Zwischenschritt war.
Übrigens gibt es auch van Gogh Lite, was 10.4 ist, also mutmaßlich nach RDNA2.
van Gogh selbst ist 10.3.
Auch auffälig: Sienna Cichlid Chips tragen ZWEI MediaEngines ?!?
"Nur Sienna Cichlid hat zwei VCN3s
Haben wir hier doch schon breit diskutiert. ;)
Die eine von beiden unterstützt weniger Codecs.
Derzeit wird im Linux Kernel eine zum Dekodieren und eine zum Enkodieren verwendet, wobei das explizit als provisorisch kommentiert ist, könnte also sein, dass sich das irgendwann noch ändert.

basix

2020-10-08, 10:32:31

Das schließe ich aus, denn wir haben die Daten von XBox SERIES X:

RDNA2 mit 56 CUs + 8 Kern ZEN2 + Rest = Netzteil ca. 300 Watt!

Bei ca. 12 TFlops! Las es dir auf der Zunge zergehen: ca. 12 TF bei sagen wir mal 130-150 Watt (reine GPU + 16 GB GDDR6)

Beide Konsolen werden bei ca. 200W Realverbrauch landen. Zieht man die 30W für die CPU ab (Renoir Power Scaling (https://www.reddit.com/r/Amd/comments/iadj1o/performancepower_ryzen_7_3700x_vs_ryzen_7_pro/)), nimmt noch 90% Netzteil als auch VRM Effizienz in die Rechnung rein, dann landen wir bei 130-140W für den gesamten Rest bestehend aus GPU, VRAM, SSD, Laufwerk und Lüfter. 80 CU bei 2.0 GHz und 280W sind somit mehr als realistisch. Besteht halt nur noch die Frage nach dem Scaling, IPC und Speicherbandbreite. Rechenleistung in FLOPS gemessen wird genug vorhanden sein.

Kriegsgeier

2020-10-08, 10:35:05

so ist es noch besser!

Das wäre also die Leistung von NAVI 22 mit 150 Watt (weniger als GTX1080 (diese hatte ca. 180-200Watt)) bei fast einer RTX 2080Ti Leistung

basix

2020-10-08, 10:43:19

150W sind vermutlich etwas sportlich, vor allem wenn N22 so hoch takten soll. 180W könnte aber hinkommen. Das wäre wohl immer noch ein gutes Stück besser als +50% Perf/W.

Iscaran

2020-10-08, 10:47:48

Haben wir hier doch schon breit diskutiert. ;)

OK :-).

Die eine von beiden unterstützt weniger Codecs.
Derzeit wird im Linux Kernel eine zum Dekodieren und eine zum Enkodieren verwendet, wobei das explizit als provisorisch kommentiert ist, könnte also sein, dass sich das irgendwann noch ändert.

Nein das mit den Codecs bezieht sich auf die Varianten der VCE3, es gibt VCE3.00, 3.01 und 3.02 wenn ich das grad richtig zusammen bringe.

HOT

2020-10-08, 10:48:52

Das schließe ich aus, denn wir haben die Daten von XBox SERIES X:

RDNA2 mit 56 CUs + 8 Kern ZEN2 + Rest = Netzteil ca. 300 Watt!

Bei ca. 12 TFlops! Las es dir auf der Zunge zergehen: ca. 12 TF bei sagen wir mal 130-150 Watt (reine GPU + 16 GB GDDR6)
Das Netzteil wird auf dem Sweet Spot betrieben, das dürfte ca. 170-190W sein. Das ist der gesamt Stromverbrauch des Systems!

Wenn XSX tatsächlich GFX1020 ist, ist das evtl. sogar eher ein RDNA1 mit RT. Ich sag das schon seit nem halben Jahr, die XBox ist erheblich älter als die RDNA2-GPUs. Die Entwicklung des Konsolen SoCs dauert viel viel länger als ne GPU.

Szudri

2020-10-08, 10:50:13

Doch tut sie, bei RDNA gibt es bis jetzt nur einen 40CU Chip, wie das ganze bei 80CU aussieht weiß noch keiner. Die 256bit bestärken mich daran, das der Chip unter der 3080 landen wird.

RDNA wurde gemacht um die nicht mehr vorhandenen Skalierungseffekte bei GCN mit >64CU zu korrigieren, nur um mit RDNA2 das ganze dann genauso schlimm zu machen wie bei GCN. Im Ernst?

Die haben dann also nichts gemacht um das Problem zu lösen. ;D

+100%CU, +IPC Verbesserungen, +Takt = evtl. +46% mehr Leistung.
Das Ding bräuchten die gar nicht releasen mit 80CU so unfassbar ineffizient wäre es.

Edit: Klarstellung, die Rechnung bezieht sich auf die schwadronierten 2080Ti Performance, die mal rumgegeistert ist. Und das % vergessen.

basix

2020-10-08, 10:50:35

Wenn XSX tatsächlich GFX1020 ist, ist das evtl. sogar eher ein RDNA1 mit RT.

...und allen DX12U Features. Irgendwie unwahrscheinlich. MS selbst sagt doch "full RDNA2"?

Diese News lesen sich sogar eher umgekehrt: RDNA2 = XBSX, RDNA1.5+ = PS5
https://www.xboxdynasty.de/news/xbox-series-x/amd-bestaetigt-volle-rdna-2-unterstuetzung-fuer-xbox-series-x-im-gegensatz-zur-playstation-5/
https://www.sportsgaming.win/2020/07/ps5-is-architecture-not-rdna-2-sony.html

WedgeAntilles

2020-10-08, 10:57:17

Wo nenne ich jemanden einen Idioten?

Das war nicht auf dich bezogen oder wörtlich gemeint.
Ging darum, dass einem von vielen das völlige Unverständnis entgegenschlägt, wenn man an RDNA2 noch Zweifel hat, so nach dem Mott: "OMG, wie kann man denn skeptisch sein, ist doch absolut sicher dass RDNA2 Klasse wird"
Da schwingt dann ja oft "wie doof muss man sein, dass nicht zu sehen" mit.

Wie gesagt, war nicht auf dich direkt bezogen, sorry falls das falsch rüberkam. :)

Ich selber zweifle noch, hoffe aber auf eine gute Karte von AMD.
Denn auch wenn ich Nvidia klar bevorzuge ist eines sicher: Starke AMD Konkurrenz ist für jeden Nvidia-Käufer super. Teurer werden die Nvidia Karten nämlich definitiv nicht, wenn AMD stark ist. :)
In 3 Wochen wissen wir mehr und heute Abend freu ich mich erstmal auf Zen3, der wird nämlich zu 99,9% im neuen Rechner verbaut werden :)

Berniyh

2020-10-08, 11:03:24

OK :-).

Nein das mit den Codecs bezieht sich auf die Varianten der VCE3, es gibt VCE3.00, 3.01 und 3.02 wenn ich das grad richtig zusammen bringe.
Ne, eine der Einheiten unterstützt – derzeit – weniger Codecs und wird daher nur für Enkodieren verwendet.
Ob das auch in Hardware gegossen ist oder nur der (derzeitigen) Implementierung in der Software ist nicht klar.

dargo

2020-10-08, 11:49:23

NAVI 21 XTX - AMD's biggest secret, AIBs were not officially told about it yet, performance is unknown. Might launch as a reference-only model first. It has more CUs than Navi 21 XT.

Hmm... das sind damit wohl doch drei Ausbaustufen mit N21 "garantiert". :uponder:

150W sind vermutlich etwas sportlich, vor allem wenn N22 so hoch takten soll. 180W könnte aber hinkommen. Das wäre wohl immer noch ein gutes Stück besser als +50% Perf/W.
Also wenn der volle N22 die 180W schafft wird der Salvage die 150W auch schaffen. :)

...und allen DX12U Features. Irgendwie unwahrscheinlich. MS selbst sagt doch "full RDNA2"?

Diese News lesen sich sogar eher umgekehrt: RDNA2 = XBSX, RDNA1.5+ = PS5
https://www.xboxdynasty.de/news/xbox-series-x/amd-bestaetigt-volle-rdna-2-unterstuetzung-fuer-xbox-series-x-im-gegensatz-zur-playstation-5/
https://www.sportsgaming.win/2020/07/ps5-is-architecture-not-rdna-2-sony.html
Übrigens... Sony selbst vergleicht afaik die 36 CUs der PS5 mit 52 CUs der PS4. Den Taktunterschied betrachtet man dabei sicherlich nicht. Die Frequenzen bei der PS4 sind ja mickrig mit 800Mhz.

Berniyh

2020-10-08, 12:06:11

Hmm... das sind damit wohl doch drei Ausbaustufen mit N21 "garantiert". :uponder:
Wobei es auch denkbar wäre, dass AMD eine mögliche XTX vorerst zurückhält, ähnlich wie man es bei Zen 2 schon gemacht hat (3950X, 3990X) und vermutlich auch bei Zen 3 machen wird (5950X).

dargo

2020-10-08, 12:07:33

Meinst du AMD wartet mit der XTX ob Nvidia einen Konter hat? :D

Adam D.

2020-10-08, 12:09:25

Wobei es auch denkbar wäre, dass AMD eine mögliche XTX vorerst zurückhält, ähnlich wie man es bei Zen 2 schon gemacht hat (3950X, 3990X) und vermutlich auch bei Zen 3 machen wird (5950X).
Der Unterschied ist nur, dass die XTX einen direkten Konkurrenten hätte. Der 3950X war mehr ein I-Tüpfelchen. Da Nvidia erstmal alles rausgehauen hat, leuchtet es mir nicht ein, warum AMD da etwas zurückhalten sollte.

[MK2]Mythos

2020-10-08, 12:27:13

ChaosTM

2020-10-08, 12:31:07

Man hätte noch 2 fette CUs die man drauflegen könnte, aber dann hat man womöglich nicht genug Quadros - die gehen aber sowas von vor.. ;)

Berniyh

2020-10-08, 12:32:39

Meinst du AMD wartet mit der XTX ob Nvidia einen Konter hat? :D
Der Unterschied ist nur, dass die XTX einen direkten Konkurrenten hätte. Der 3950X war mehr ein I-Tüpfelchen. Da Nvidia erstmal alles rausgehauen hat, leuchtet es mir nicht ein, warum AMD da etwas zurückhalten sollte.
Das kann auch einfach Strategie sein, um eben später noch mal einen separaten Launch zu haben und so mehr Aufmerksamkeit zu bekommen.
Außerdem kann es noch andere Gründe geben wie Yield, Binning etc. was ja vermutlich beim 3950X das Problem war.

Ich würde einfach nur nicht davon ausgehen, dass AMD gleich sämtliche Varianten vorstellt, sei es nach oben oder nach unten hin.
Auch, ob Navy Flounder direkt mit vorgestellt wird oder dann erst irgendwann gegen Dez/Jan muss man abwarten.

dargo

2020-10-08, 12:32:39

Man hätte noch 2 fette CUs die man drauflegen könnte, aber dann hat man womöglich nicht genug Quadros - die gehen aber sowas von vor.. ;)
Logisch... dort gibts fette Marge.

Das kann auch einfach Strategie sein, um eben später noch mal einen separaten Launch zu haben und so mehr Aufmerksamkeit zu bekommen.

Das kannst du dir aber eigentlich nur leisten wenn die XT die 3090 schon schlägt.

Adam D.

2020-10-08, 12:36:01

Das kann auch einfach Strategie sein, um eben später noch mal einen separaten Launch zu haben und so mehr Aufmerksamkeit zu bekommen.
Außerdem kann es noch andere Gründe geben wie Yield, Binning etc. was ja vermutlich beim 3950X das Problem war.

Ich würde einfach nur nicht davon ausgehen, dass AMD gleich sämtliche Varianten vorstellt, sei es nach oben oder nach unten hin.
Auch, ob Navy Flounder direkt mit vorgestellt wird oder dann erst irgendwann gegen Dez/Jan muss man abwarten.
Man stelle sich jetzt die Situation vor, dass AMD die 3080 mit der XT erreicht (was ja nicht ausgeschlossen ist). Das wäre doch marketing-technisch absolut bekloppt, hier nicht noch mit der XTX anzutreten, wenn der Konkurrent sein gesamtes Lineup vorgestellt hat.

dargo

2020-10-08, 12:38:54

Man stelle sich jetzt die Situation vor, dass AMD die 3080 mit der XT erreicht (was ja nicht ausgeschlossen ist). Das wäre doch marketing-technisch absolut bekloppt, hier nicht noch mit der XTX anzutreten, wenn der Konkurrent sein gesamtes Lineup vorgestellt hat.
Jein... stelle dir vor die XT ist bei der 3080 oder leicht drüber. Kostet 599-649$, hat 16GB Vram und verbraucht 275W. Ich glaube außer Fans die sowieso nur Geforce kaufen würde keinen mehr die 3080 10GB interessieren. Wichtig wäre hierbei natürlich gute Verfügbarkeit und nicht so ein Desaster wie bei GA102.

btw.
Ich bin mir nicht mal sicher ob AMD marketingtechnisch mit der 3090 überhaupt vergleichen will. Das Ding ist mit 1499$ verdammt teuer und möglicherweise zielt AMD auf diese geringe Zielgruppe beim Gaming gar nicht erst ab. Wenn N21 mit 16GB kommt macht es auch wenig Sinn sich gegen die 24GB 3090 zu stellen. Es sei denn AMD kann sich mit N21 performancemäßig wirklich gegen die 3090 stellen dann spricht auch nicht viel dagegen. 16GB reichen heute für alle Games aus.

[MK2]Mythos

2020-10-08, 12:40:49

Man hätte noch 2 fette CUs die man drauflegen könnte, aber dann hat man womöglich nicht genug Quadros - die gehen aber sowas von vor.. ;)
Wenn man sich mal anguckt, was für Netzteile die 3090 schon abschießt, dann sehe ich auch da eine wirklich harte Grenze. Es dürfte klar sein, dass nvidia da nichts noch wilderes auf den Markt loslassen kann und will.

Berniyh

2020-10-08, 12:50:15

Adam D.

2020-10-08, 12:51:03

Jein... stelle dir vor die XT ist bei der 3080 oder leicht drüber. Kostet 599-649$, hat 16GB Vram und verbraucht 275W. Ich glaube außer Fans die sowieso nur Geforce kaufen würde keinen mehr die 3080 10GB interessieren. Wichtig wäre hierbei natürlich gute Verfügbarkeit und nicht so ein Desaster wie bei GA102.
Aber das schließt doch nicht aus, dass man gleichzeitig alles dafür tun sollte, den Marketing-Win mitzunehmen. Wenn AMD mit der 3090 gleichziehen kann, werden sie das auch tun - auch wenn wir hier von einem Bereich reden, wo eh nicht viele Karten über den Tresen gehen.

(PS: Deine P/L-Einschätzung ist ganz schön optimistisch :eek: )

dargo

2020-10-08, 12:53:44

(PS: Deine P/L-Einschätzung ist ganz schön optimistisch :eek: )
Naja... NV hat mit 699$ auch tief gestappelt. ;) Die Straßenpreise sprechen natürlich eine andere Sprache momentan.

ChaosTM

2020-10-08, 12:58:38

Mythos;12453101']Wenn man sich mal anguckt, was für Netzteile die 3090 schon abschießt, dann sehe ich auch da eine wirklich harte Grenze. Es dürfte klar sein, dass nvidia da nichts noch wilderes auf den Markt loslassen kann und will.

Da bald Quadros kommen mit Vollausbau und 48gb, kommt früher oder später auch was für uns Con(Pro)sumer. (Titan) Der Aufwand steigt halt ziemlich für die Platinen etc. Bei 3k Verkaufspreis (Schätzung) tut das aber nicht weh.

add.: ich hoffe auf eine AMD Karte mit 32 GB. Aber nur sinnvoll wenn man dem NV Dickschiff sehr nahe kommt.

dargo

2020-10-08, 13:16:33

Was willst du mit 32GB in Games? :uconf3: Reine Geldverschwendung. Zumal du dann auch die Karte doppelseitig bestücken musst.

basix

2020-10-08, 13:27:32

Mythos;12453101']Wenn man sich mal anguckt, was für Netzteile die 3090 schon abschießt, dann sehe ich auch da eine wirklich harte Grenze. Es dürfte klar sein, dass nvidia da nichts noch wilderes auf den Markt loslassen kann und will.

10% liegen noch drin mit 84 SMs und stark selektierten Chips ("Titan"), ohne dass zwingend die Leistungsaufnahme steigen muss. Die Karte gäbe es wohl nur in homöopathischen Dosen, wäre aber dennoch die mit dem längsten Balken.

Wenn AMD mit der XT die 3080 überflügeln sollte und allenfalls sogar an der 3090 kratzen sollte (ist möglich, aber optimistisch), würde ich die XTX auch noch zurückhalten, vielleicht anteasern. Ausser man ist gleich 10+% schneller als die 3090 und bringt dazu eine 32GB "Fury Edition" obendrauf ("FE" :D), dann kann man mit einem Big Bang RDNA2 veröffentlichen. Das ist aber dann sehr optimistisch ;)

Ich denke, wir können realistischerweise eine Karte erwarten, welche mit der 3080 konkurriert. Das wäre schon ziemlich stark von AMD. Alles was schneller als eine 3080 ist, wäre eine positive Überraschung. Begrüssen würden wir hier das wohl aber alle.

Berniyh

2020-10-08, 13:45:05

Was willst du mit 32GB in Games? :uconf3: Reine Geldverschwendung. Zumal du dann auch die Karte doppelseitig bestücken musst.
Ich denke eine 32GB Variante wäre ähnlich der VII (welche an der Stelle ja auch eigentlich viel zu viel VRAM und Bandbreite hatte) eher eine Abwandlung einer Pro Version des Chips (auch wenn Navi 21 natürlich eindeutig auf Consumer ausgelegt wäre).
Dafür käme dann das HBM Interface zum Einsatz (aktuell gehen wir ja immer noch davon aus, dass Navi 21 in irgendeiner Form beides kann).
Mit HBM2 ist 32 GB dann wiederum kein Problem, auch in zwei Stacks.

ChaosTM

2020-10-08, 13:45:07

Was willst du mit 32GB in Games? :uconf3: Reine Geldverschwendung. Zumal du dann auch die Karte doppelseitig bestücken musst.

Windows 10 darauf installieren zb. :)

Für 8K Spielereien werden 16 leider auch schon knapp. Siehe Auslastung bei den 8k Tests der 90er. 22+ wurden da erreicht..
Lieber zu viel als zu wenig, selbst wenn es nur für sinnfrei Spielereien ist.

Berniyh

2020-10-08, 13:58:36

Für 8k langt es auch sich in 4-5 Jahren eine neue Karte zu kaufen. ;)

dargo

2020-10-08, 14:02:08

Windows 10 darauf installieren zb. :)

:ucrazy2:

ChaosTM

2020-10-08, 14:02:52

Die Produktzyklen werden immer länger. Könnte sein dass ich die Karte diesmal 4-5 Jahre haben werde
8K ist noch kein "muss haben" für mich.

Digidi

2020-10-08, 14:12:03

Die Produktzyklen werden immer länger. Könnte sein dass ich die Karte diesmal 4-5 Jahre haben werde
8K ist noch kein "muss haben" für mich.

Die Theorie habe ich auch und dershalb Ziehen die Preise an. Bei der nächsten Generation werden wir dann wohl 2500 für die Top Karten sehen, Irgendwie muss man ja den Umsatz und die Gewinne pro Jahr steigern. Wenn da länger nichts neues kommt geht dies nur über Preissteigerungen.

dargo

2020-10-08, 14:14:53

Die Produktzyklen werden immer länger.
Weil die IHVs noch bei den alten Fertigungsdesigns hängen. Sobald Chiplets serienreif sind wird sich das ändern. Ich erwarte als Vorstufe schon die Auslagerung vom IO. Das spart auch schon einiges an Kosten wenn du den IO im reifen, älteren und günstigeren Prozess fertigen lassen kannst.
https://www.reddit.com/r/Amd/comments/er9gkx/navi_10_ir_die_shot_from_fritzchen_fritz_link/

Leonidas

2020-10-08, 15:24:38

Full ack, er verzapft den gleichen Humbug, der auch überall geschrieben wird.

Mit dem Unterschied, das die Schreiberlinge in aller Regel so ehrlich sind, ihre Quellen zu benennen, so dass man alles zuordnen kann. Im Sinne des Videos ist nix mehr zuordnenbar, da ist alles ein Brei. Egal ob man später noch irgendwelche Links notiert.

Es passt im Sinne von: "Das ist der aktuelle Gerüchte-Stand." Es passt überhaupt nicht im Sinn von "ICH bringe jetzt Neuheiten."

N80 doch mit HBM? https://coreteks.tech/articles/index.php/2020/10/01/radeon-6900xt-specs-leak-competes-with-rtx-3090/

Ghost Motley will £100 spenden, wenn das wahr wird:
https://twitter.com/ghost_motley/status/1313937389673381888

Picojoule pro Bit bei 21 Gbps vs 14 Gbps, hier 15% sparsamer bei signifikant mehr Bandbreite - laut Micron.

Jo ... aber die Speicherchip-Hersteller rechnen sicherlich nur ihren Speicher selber, nicht das dafür notwendige Interface. Dies könnte diese Rechnung potentiell umdrehen (muß es natürlich nicht, ich kann nur spekulieren).

Wenn das stimmt sieht es nicht nach HBM aus, wobei er sagt es wäre nicht die XTX Variante sonder XT/XL.

Immer wieder lustig Leute anzutreffen, die tatsächlich glauben, die XL/XT/XTX Varianten eines Chips würden auf reiner HW-Ebene irgendwie anders aussehen. Da muß ich dann leider das grundlegende Technik-Verständnis dieser Leute anzweifeln.

nordic_pegasus

2020-10-08, 17:15:30

Immer wieder lustig Leute anzutreffen, die tatsächlich glauben, die XL/XT/XTX Varianten eines Chips würden auf reiner HW-Ebene irgendwie anders aussehen. Da muß ich dann leider das grundlegende Technik-Verständnis dieser Leute anzweifeln.

MLID hat spekuliert, dass ein Professional-Chip mit HBM-Interface existiert, welcher eventuell als XTX verwurstet werden könnte (vielleicht als Salvage?).

Ansonsten ist es natürlich deppert zu glauben, dass man 3 Ausbaustufen eines Chips mit unterschiedlichem SI ausstatten kann.

Gipsel

2020-10-08, 17:17:18

MLID hat spekuliert, dass ein Professional-Chip mit HBM-Interface existiert, welcher eventuell als XTX verwurstet werden könnte (vielleicht als Salvage?).Das ist dann aber per Definition keine XTX-Version eines Chips sondern ein anderer Chip. Und der Professional-Chip mit HBM namens Arcturus hat eine andere Architektur, ist im Grafikbereich stark beschnitten, also als Spielechip ungeeignet.

Elite_Warrior

2020-10-08, 17:38:13

Obendrauf wird wohl kein Raytracing vorhanden sein. Sowieso macht CDNA für gaming wohl null Sinn. Wenn Navi 10 mit 40CU bei einer Vega7 mit 60CU auf Augenhöhe operiert, dann macht die Verdopplung beider Chips auch kein Unterschied. Besonders weil die schlechtere Auslastung im Rendern bei deutlich mehr CU das Scaling kaputt macht.

XTX gab auch schon bei Navi 10 und das waren extra gebinte und hochgezüchtet Chips für die 50th Anniversary Edition.

Berniyh

2020-10-08, 17:51:02

Das ist dann aber per Definition keine XTX-Version eines Chips sondern ein anderer Chip. Und der Professional-Chip mit HBM namens Arcturus hat eine andere Architektur, ist im Grafikbereich stark beschnitten, also als Spielechip ungeeignet.
Es könnte sein, dass Navi 24 so ein Chip ist. Aber da wüsste MLID mit Sicherheit nix von.
(Ok, ich glaube er weiß auch sonst von nix, aber ich will da jetzt an der Stelle auch keinen Streit vom Zaun brechen.)

Eigentlich aber war ja die Spekulation, dass Navi 21 auf irgendeine Art auch HBM ansteuern kann (was ich persönlich mir irgendwie nicht vorstellen kann, aber komplett auszuschließen ist es nicht).
Grund für diese Annahme ist (neben diversen Gerüchten), dass Navi 21 diverse Korrekturfunktionen unterstützt die man sonst eigentlich nur bei den Chips mit HBM Speicher findet:
https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd/amdgpu/?h=amd-staging-drm-next&id=8f06611b8ae94c0adb5eb2dbb13c532b1f2cfb7e
https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd/amdgpu?h=amd-staging-drm-next&id=c88067911022843b1c9bafef998e0d2504c303ef

umc_v8_7.c wird auch explizit nur von Navi 21 verwendet:
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c?h=amd-staging-drm-next#n616
https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd/amdgpu/?h=amd-staging-drm-next&id=83911e9d94bdc2f68312340946c31ba1392e8a2f

Dabei ist es natürlich nicht ausgeschlossen, dass AMD jetzt sowas auch für GDDR6 implementiert hat, aber es wurde halt von verschiedenen Quellen (auch von mir, hatte was zu dem Patch im Thread hier geschrieben) als Hinweis auf HBM interpretiert.
Ich glaube inzwischen auch selbst nicht mehr wirklich dran, dass es Navi 21 mit HBM geben wird, aber so ganz von ungefähr kommt das halt dann doch nicht.;)