AMD Big Navi/RDNA2: 5.120 Shader und zehn Ausbaustufen für Navi 21?
Es gibt neue Gerüchte zu AMDs "Big Navi"-GPU. Angeblich soll diese stolze 5.120 Shader auf rund 505 mm² unterbringen, und von AMD in zahlreichen Ausbaustufen auf den Markt gebracht werden. Neben dem Desktop-Markt sollen auch das Profi-Segment und Apple-Geräte mit dem Chip ausgerüstet werden.
Der vor allem über Twitter bekannte Leaker _rogame hat neue Informationen zu AMDs kommender "Big Navi"-GPU veröffentlicht. Neben den grundlegenden Eckdaten der eigentlich "Navi 21" genannten GPU liefert der Leak auch eine Auflistung der verschiedenen Ausbaustufen und Einsatzgebiete des Chips. Angeblich plant AMD, die Navi-21-GPU in insgesamt zehn Varianten auf den Markt zu bringen.
Zehn Varianten und mehr Shader als jede GCN-GPU
Das mag sich auf den ersten Blick nach unrealistisch viel anhören, doch die Liste von _rogame liefert für jede GPU auch einen passenden Verwendungszweck, sodass das Gesamtbild doch schlüssig ist. Demnach würde Navi 21 für vier Desktop-Grafikkarten und zwei Profi-Modelle genutzt werden. Die übrigen vier Varianten sollen für Apple bereitgestellt werden, um sie im iMac (Pro) und im Mac Pro zu verwenden.
| GPU | PCI ID | Ersatz für / Einsatz im |
|---|---|---|
| Navi 21 XTX | 0x731F:D0 | RX 5700 XT 50th Anniversary |
| Navi 21 XT | 0x731F:D1 | RX 5700 XT |
| Navi 21 XL | 0x731F:D3 | RX 5700 |
| Navi 21 XE | 0x731F:DF | RX 5600 XT |
| Navi 21 Pro-XT | 0x731F:10 | Pro W5700X |
| Navi 21 Pro-XL | 0x731F:12 | Pro W5700 |
| Navi 21 XTA | 0x731F:50 | iMac/iMac Pro |
| Navi 21 XLA | 0x731F:51 | iMac/iMac Pro |
| Navi 21 Pro-XTA | 0x731F:11 | Mac Pro |
| Navi 21 Pro-XLA | 0x731F:13 | Mac Pro |
Informationen zur Leistung von Navi 21 hat _rogame zwar leider nicht parat, dafür aber zur Effizienz und Größe des Chips. Glaubt man seinen Informationen, so soll Navi 21 im Vollausbau auf 80 Compute Units mit 5.120 Shadern setzen. Der Chip soll dafür ungefähr 505 mm² groß werden und eine um 50 Prozent gesteigerte Energieeffizienz aufweisen. Insgesamt wäre Navi 21 somit eine nahezu exakte Verdopplung der Navi-10-GPU, die in der Radeon 5700 XT zum Einsatz kommt: Navi 10 bringt 2.560 Shader auf 251 mm² unter.
Passend zum Thema: Geforce RTX 3000 und AMD RDNA2: Release im September?
Als letzter Teil des Gerüchts vermutet _rogame, dass Navi 10 auch neben den neuen Navi 2X-GPUs noch weiterexistieren wird. Während Navi 21 das High-End-Segment bedienen wird, soll Navi 23 in etwa so groß wie Navi 10 werden und die Mittelklasse abdecken. Für das Einstiegssegment soll dann Navi 10 gedacht sein, wobei es dafür vermutlich kleinere Änderungen an der GPU geben dürfte - dafür spricht das "+" hinter den geleakten Produktnamen. Denkbar wäre beispielsweise eine leicht verbesserte Fertigung wie einst bei der Radeon RX 590.
| GPU | PCI ID | Ersatz für |
|---|---|---|
| Navi 10 XT+ | 731F:E1 | RX 5700 XT |
| Navi 10 XM+ | 731F:E3 | RX 5600M |
| Navi 10 XTE+ | 731F:E7 | RX 5600 XT |
Quelle: Hardwareleaks via Videocardz

V100 und P100 lassen sich so auf PCIe's verpflanzen; und wie man am A100 sieht sind auch abgespeckte Varianten des GA100 kein Problem. NGC ist eine GPU optimierte Umgebung die auf Flexibilität in der Infrastructur ausgelegt wurde und die Containerregistrierung inklusive dazugehöriger Bibliotheken sind per Image für eine optimale GPU Beschleunigung ausgelegt. Quadro vWS kann so als Teil der Cloud Infrastructur dienen und das bietet ein fast zu unbegrenztes Potential, wenn es darum geht Fertigungsverfahren und Herstellung in gewissen Mengen erst Preis bestimmt zugänglich zu machen. Alles andere wäre viel zu teuer und zu unflexibel.
1.) Die Quado-Argumentation ist gut, ich habe sie schon vorher gelesen, aber irgendwie rausgefiltert.
Eine gewisse Funktionsgleichheit
1) FP64 "streichen" bzw. konkret reduzieren in Form der dedizierten Funktionseinheiten, ja, TF32 wird mit Blick auf die Quadro's zweifelsfrei nicht gestrichen werden, ebenso wenig wie bfloat16, zumal wie gesagt, hier kein "Abknipsen einiger Datenpfade" möglich sein wird. Entsprechendes würde höchstwahrscheinlich ein Redesign der Tensor Cores erfordern.
Laß' uns abwarten, dauert ja nicht mehr lange, aber ich denke den Quadro's wird im Vergleich zum GA100 nichts an Funktionalität fehlen, bestenfalls FP64-MMA und natürlich wird die FP64-Leistung deutlich reduziert sein (dazu ggf. das Multi-Instancing).
2) Die Überlegungen haben nichts mit "Sklave von Sony und/oder MS" zu tun. Das sind einfach wirtschaftliche Überlegungen, die AMD zu voraussichtlich derartigen Verträgen brachten. Sony/MS bezahlen AMD exklusiv für die Entwicklung der Konsolen-IP sowie der Fertigung der SoCs. Die SoCs hatten ihr Tapeout zweifelsfrei schon in 2018, jedoch brauchen die beiden Großen für das In-den-Markt-bringen deutlich länger, was bei einem solchen Produkt völlig normal ist. AMD hätte selbstredend vergleichsweise schnell eine dedizierte GPU darauf basierend auskoppeln können. Vielleicht hätten sie erst Ende 2019 launchen können, aber dann mit einem deutlichen Performancesprung (immerhin versprechen sie ja +50 % Perf/Watt), aber das ist nicht geschehen, und das wohl schlicht aus wirtschaftlichen Gründen, denn die Technik hatte man bereits.
Seit dem Turing-Launch hört man von AMD bzgl. Raytracing ausweichende oder vertröstende Worte, "man hielt die Zeit noch nicht für Reif ... den SW-Stack nicht für reif ... wir sind auch dran ... etc." Was hätte man auch anderes sagen sollen? "Ja, von uns wird es auch Raytracing geben, aber erst in 24 Monaten"? Dass man so etwas nicht offen kommunizieren kann und will, dürfte wohl klar sein und erst recht nicht etwas wie "Sorry, aber wir verdienen bald mit Sony/Microsoft gutes und stetiges Geld mit den neuen SoCs und das auch langfristig. Das sind nun einmal deutlich mehr und wesentlich gesichertere Einnahmen, als sich der direkten Konkurrenz durch nVidia im AIB-Markt auszusetzen, bei dem wir nur um die 25 % Marktanteil haben. Dafür habt ihr doch sicher alle Verständnis, dauert also noch ein, zwei Jahre ..."
Unter anderem für genaue derartige Situationen hat man eine Marketingabteilung, die genaue solche Klippen mit schönen Worthülsen umschiffen hilft.
Wie gesagt: Ich erheben nicht den Anspruch darauf die einzige Wahrheit zu kennen, aber das markttechnische Vorgehen weist m. M. n. recht deutlich in diese Richtung. Selbst ein RDNA2-AIB-Launch noch später, so bspw. Anfang diesen Jahres, aber noch deutlich vor nVidia's Produkt-Update wäre für Marketing und Vertrieb ein Freudenfest gewesen aber man sieht ja, wozu es (nicht) gekommen ist.
Und ja, dein produkttechnischer Erklärungsansatz für Renoir ist auch nicht unwahrscheinlich, aber in ebenso der gleichen Weise sehe ich hier keinen Grund, warum der wahrscheinlicher sein sollte, als meine Auslegung. AMD handelt unter rein wirtschaftlichen Gesichtpunkten und RDNA2 ist eine Auftragsfertigung für Sony/MS und die werden zweifelsfrei nicht gewollt haben, dass diese IP schon normal und im Massenmarkt verbreitet ist (inkl. Raytracing), bevor überhaupt die Konsolen in den Markt kommen.
Vielleicht wird man ja mal in 5 oder 10 Jahren in einer Biographei von Raja was dazu lesen?
"Bezüglich des Tiefstapelns, dass müsste AMD im Prinzip die ganze Zeit gemacht". - Nein, nicht unbedingt, denn das ist erstens ein Lernprozess und zweitens bezieht sich die Aussage meinerseits hauptsächlich darauf, dass man im Wesentlichen eine deutlich leistungsfähigere Architektur hatte, diese aber nicht einsetzte/einsetzen durfte. Es ist also eher ein architektonisches als ein fertigungstechnisches Argument. Und an der reinen Transistordichte dürfte man das nicht ganz so leicht festmachen können (insbesondere bspw. ein Vergleich mit dem Zen2-CCD und Renoir dürfte schwer fallen aufgrund der unterschiedlichen Funktionsbereiche, die typischerweise unterschiedliche Logikdichten implementieren), auch wenn hier nVidia zweifelsfrei noch einmal was obendrauf gelegt hat mit einem 66 MTr/mm2-Design im N7 für einen GA100 mit derart hoher Strom/Wärmedichte.
Wie ich schon mal erklärte: Ich denke AMD hat primär RDNA(2) entwickelt und davon RDNA(1) abgeleitet und als RNDA "light" herausgebracht um vorzeitig Revenue zu genenrieren. Vertriebstechnisch ist es natürlich sinnvoller diese dann als RDNA und das später veröffentlichte Produkt als RDNA2 zu benennen, aber letzteres dürfte wohl die primäre Entwicklung gewesen sein. (Jedoch natürlicherweise nicht mehr als ein educated guess, denn AMD wird sich hüten so etwas zu bestätigen, zumindest nicht in absehbarer Zeit.)
Btw ... an Vega 20 hat sich grafiktechnisch nichts Wesentliches verändert; die Funktionseinheiten sind weitestgehend unverändert, die Caches ebenso, im Wesentlichen ist das Leistungsplus auf den höheren Takt und die mehr als doppelt so hohe Speicherbandbreite zurückzuführen. Die Mehrleistung liefert hier hauptsächlich die Adaption auf den neuen Prozess und die schnellere HBM2-Anbindung. Mit einer überarbeiteten Architektur wäre zweifelsfrei deutlich mehr möglich gewesen, wie man bereits an der RX 5700XT sieht. Zwar 100 MHz mehr Boost-Takt, aber dafür 1/3 weniger CUs und nur 44 % der Speicherbandbreite und in WQHD liegt diese dennoch sehr nahe an der Radeon VII, was halt schlicht der überalterten Vega-Architektur zuzuschreiben ist. Und jetzt soll RDNA2 mit einem Perf/Watt-Sprung kommen, jedoch ist diese Architektur ebenfalls aus 2018 (wie Navi 10).
Bitte nicht falsch verstehen, RDNA2 wird auf jeden Fall interessant und möglicherweise gar mit 16 GiB-HBM2 in den TopModellen gepaart werden und wird mögilcherweise eine interessante Alternative werden, aber die hätte möglicherweise auch schon 12 bis 15 Monate früher im Markt sein können, wurde jedoch aus wirtschaftlichen Gründen zurückgehalten.
"Und was auch immer AMD bei ihrer Designmethodik verändert hat, scheint in der Ausprägung eine relativ neue Entwicklung zu sein." Zumindest meiner Argumentation folgend eher nicht.
Aber nun genug von meiner Theorie, schließlich werde ich hier nicht nach Worten bezahlt.
1.) Die Quado-Argumentation ist gut, ich habe sie schon vorher gelesen, aber irgendwie rausgefiltert.
Eine gewisse Funktionsgleichheit für Programmcode und CUDA als Softwareversklavung, ich meine Ökosystem, ist wichtig.
Rein design-technisch stelle ich mir das streichen von FP64/TF32, als sehr gewinnbringend vor.
Zumindest die Wegrationalisierung von FP64 erscheint mir als guter Kandidat, wobei wie gesagt, es kommt darauf an wie intern die Datenpfade verlaufen und was geshared wird und was nicht.
Je nachdem würde sich das gar vom Design nicht wirklich lohnen, da Hand anzulegen.
2.) Wir hatten die Diskussion schon einmal und das Szenario klingt nach wie vor wahnsinnig für mich und ergibt keinen Sinn in der Konstellation.
AMD hätte sich zum Sklaven von Sony und/oder MS gemacht, dabei haben sie eine sehr gute Verhandlungsposition, denn einfach zu Intel oder Nvidia konnten Sony und MS nicht gehen, AMD war praktisch alternativlos, schon wieder.
Warum sollte sich dann AMD in Ketten legen? Springt etwa massiv mehr Geld heraus, als letztes mal?
Und was haben Sony oder Microsoft großartig davon?
Wäre AMD der einzige Player auf dem Markt, wäre es teilweise noch nachvollziehbar, aber AMD zu schwächen, während Nvidia und Intel tanzen können wie sie wollen und gute Produkte abliefern, während AMD irgendein gerupftes Huhn anbieten muss, ja ne.
Es ist mir nicht bekannt, dass jemals ein Konsolendeal zu irgendeinen zeitexklusiven lockdown geführt hat, im Gegenteil ist es lustig wie offen IP geshared wurde, worin andere investiert haben.
IBM hat mit Sony gemeinschaftlich den Cell entwickelt und während das Projekt und einige Komponenten nicht an MS preisgegeben werden durften, haben die das PPU-Design einfach MS angeboten und drei mal verbaut, die Technik in der Xbox360 wurde indirekt von Sony mitfinanziert.
Bei der PS4/Xbox One Generation das Gleiche, extra Arbeit oder Wünsche von Sony für verbesserte ACEs oder Volatile-Bits haben es auch in die Xbox One geschafft.
Und AMD selber hat zwei GCN2-Ableger (dGPU Bonaire und Kabini APU) Monate vor beiden Konsolen gelaunched.
Bei Renoir würde ich auch überhaupt nicht davon ausgehen, dass Verträge der Grund dafür waren.
Da kann man auch in die Vergangenheit schauen, wo es noch gar keine Konsolendeals mit entsprechender Technik gab.
Die erste APU Llano hat eine ältere VLIW5 GPU verwendet, obwohl ein halbes Jahr früher Cayman mit VLIW4-Technik veröffentlicht wurde.
Bei Trinity im Prinzip das gleiche, es gab dann Piledriver mit VLIW4 iGPU, irgendwann im Mai 2012, während Tahiti schon anfangs 2012 verkauft wurde (Ende 2011 noch präsentiert und getestet).
Cape Verde wurde im Februar 2012 gelaunched und Pitcairn im März, man hatte also drei GCN-Chips für Mainstream bis High-End Monate vor Trinity auf dem Markt.
Es gibt auch andere Besonderheiten, zum Beispiel gab es keine APU mit GCN1-Technik, ebenso nicht mit GCN4, wurde übersprungen.
Dämlich in Bezug auf Renoir wäre es auch eine Klausel zu haben, die RDNA1 dGPUs erlaubt , aber als iGPU verbietet.
Ich denke der Grund für RDNA1 (zeitlich) und Renoir hängt einfach vom Projektverlauf, der Manpower und dem Risikomanagement zusammen.
AMD hatte offiziell Navi (RDNA1) für 2018 auf der Roadmap stehen:
https://pbs.twimg.com/med...
Wie soll man das jetzt logisch in eine Welt eines zeitexklusiven Konsolendeals einordnen?
Haben Sony/MS ihre Konsolen auch schon Ende 2018 releasen wollen? Oder wurde von Sony/MS im Nachhinein für Zeitexklusivität extra bezahlt?
Und war der geplante Chip Ende 2018 schon RDNA2?
Ich denke für RDNA1 lief es schlechter, als ursprünglich geplant und für Renoir wollte man nicht auf eine IP setzen, die noch in einer Problemphase steckt.
Die Entwicklung der Konsolen-SoCs mit größeren Teams und relativ späteren Milestones lief dagegen über die Jahre besser.
------
Bezüglich des Tiefstapelns, dass müsste AMD im Prinzip die ganze Zeit gemacht haben, denn Renoir zeigt hat eine 22% höhere Transistordichte gegenüber einem Zen2-Chiplet, der fast zur Hälfte nur aus SRAM besteht, also vielen Transistoren pro mm² und ~58% gegenüber Vega20 (Untere Tabelle):
Transistor Count: A Flawed Metric
Und was die iGPU praktisch an Takt erreicht ist auch sehr stark:
YouTube
7nm Vega als iGPU präsentiert sich deutlich stärker gegenüber den 14nm Vega APUs, als 7nm Vega20 gegenüber 14nm Vega10.
AMD schafft bei dem Projekt sehr hohe Taktraten, vor allem in Relation zur Transistordichte.
Da es bekannte IP ist, kann das Plus nur von einer massiv besseren physischen Implementierung kommen und besseren Laufzeitparametern.
Ich denke das wird auch der Haupttreiber von RDNA2 sein.
Und was auch immer AMD bei ihrer Designmethodik verändert hat, scheint in der Ausprägung eine relativ neue Entwicklung zu sein.
Und wie schon zuvor erklärt, bspw. bfloat16 wird man in den Quadro's brauchen, ebenso wie TF32. Das kann man dort nicht wegrationalisieren, d. h. wenn nVidia nicht noch einen dedizierten Quadro-Chip designed hat **) wird man hier die gleichen Funktionseinheiten unverändert übernehmen und wenn die sich erneut die Basis mit den Consumer-Karten teilen, werden auch diese zumindest im Silizium diese Funktionalität besitzen.
Was man auf den Quadro's zumindest deaktivieren könnte, wäre die FP64-MMA-Funktionalität, was zumindest auch konsistenter erscheinen würde, denn es ist nicht übermäßig wahrscheinlich, dass nVidia von seinem 1:32-FP64-Schema abweichen wird. Aber nur dafür würde man nicht die Tensor Cores überarbeiten. Und gesichert ist das zudem ebensowenig, denn man kann durchaus argumentieren, dass man diese Funktionalität zu Entwicklungszwecken auf den Profikarten aktiviert lässt (denn dafür bezahlt der Kunde ja auch ordentlich).
Bei den Caches wären Anpassungen möglich, so bspw. beim außerhalb der GPCs liegenden L2 sind min. proportionale Anpassungen zu der Anzahl der implementierten SMs wahrscheinlich, aber bei einer so kleinteiligen Dískussion waren wir dann doch noch nicht.
Darüber hinaus würde ich aber nicht zwingend erwarten, dass nVidia bspw. den L1 reduziert, insbesondere nicht, wenn man die RT-Leistung signifikant erhöhen will, möglicherweise gar mit einem nur durchgängig GDDR6-basierten Speicherinterface.
Hinzu kommt auch hier erneut das Problem, dass eine übermäßige Verkleinerung erneut die Quadro's ausbremsen würde, insbesondere, wenn denen deutlich weniger Speicherbandbreite zur Verfügung steht und die dann zusätzlich auch noch ECC implementieren müssen.
*) Und entgegen der Telsa V100 ist die Quadro GV100 ganz klar für Workstations ausgelegt gewesen: "The NVIDIA Quadro GV100 is reinventing the workstation to meet the demands of next-generation ray tracing, AI, simulation, and VR enhanced workflows. It’s powered by NVIDIA Volta, delivering the extreme memory capacity, scalability, and performance that designers, architects, and scientists need to create, build, and solve the impossible."
Eine vermeintlich harte Trennung, bspw. a la "Volta war nur für HPC" ist also unzutreffend (zumal HPC auch nicht gleich AI ist, aber das ufert jetzt aus
**) Ein solcher zusätzlicher Chip würde aber zusätzliche Probleme bzgl. der Chipausbeute mit sich bringen und zudem wird es in absehbarer Zukunft sicherlich auch den GA100 in Form einer PCIe-basierten Einsteckkarte geben, vielleicht gar wieder unter dem Quadro-Brand. (Bei Pascal und Volta hat das so jeweils 9 - 12 Monate gedauert.)
2) AMD hat RDNA und RDNA2 nahezu zeitgleich entwickelt (sofern das überhaupt voneinander unabhängige Entwicklungen waren, was zum. ich pers. bezweifele). Die Konsolen-SoCs wie auch Navi werden ihr Tapeout alle bereits in 2018 gehabt haben. AMD hätte sich RDNA auch gleich sparen und direkt RDNA2 bringen können, jedoch haben sie vertragliche Regularien daran gehindert und selbstredend durften sie nicht einfach etwas sehr RDNA2-ähnliches vorzeitig auf dem PC auskoppeln, weil das nicht weniger ein Vertragsbruch gewesen wäre. Infolgedessen kann man hier schon davon Reden, dass sie nicht alle Möglichkeiten ausgeschöpft haben, bzw. nicht durften, weil die IP exklusive für ihre Auftraggeber vorgesehen war.
In der gleichen Art kann man übrigens auch davon ausgehen, dass der Aufwand noch einmal Old-Vega zu pimpen, um es mit Zen2 in Renoir zu verheiraten, auf die gleichen vertraglichen Einschränkungen zurückzuführen ist. Ein Renoir mit Navi oder gar gleich RDNA2 wäre schlicht ein fast vollwertiger Konsolen-SoC gewesen und das min. 10 Monate bevor letztere überhaupt in den Markt kommen würden. Dass Sony und Microsoft etwas dagegen haben würden, ist leicht nachvollziehbar.
Ich denke schon, dass man hier technisch bewußt tief gestapelt hat um übergangsweise Navi 10 auskoppelte und etwas Revenue zu generieren, denn bereits der N7 hätte deutliche Zugewinne ermöglicht, von denen AMD kaum Gebrauch gemacht hat und architektonisch, wie oben bereits geschrieben ...
Darüber hinaus befand sich der N7 schon seit April 2018 in der HVM und war schon längst ausgereift und laut WikiChip nutzt Navi gar schon den optimierten N7P, der noch einmal etwas mehr Leistung oder Powersavings ermöglicht als der N7.
Und wenn man sich dann noch ansieht, welche beträchtlichen Effizienzsteigerungen nVidia realisiert hat mit Ampere, von denen der Großteil voraussichtlich auf den Node-Wechsel zurückzuführen sein wird (immerhin ein Spung um einen ganzen oder gar 1,5 Full-Nodes) und wenn man bedenkt, dass AMD weiterhin den N7P nutzen wird mit RDNA2 (der N7+ ist höchst unwahrscheinlich aus diversen Gründen, aber selbst der würde die Betrachtung nicht wesentlich verändern), dann bleiben AMD für ihre versprochenen "+50 % Perf/Watt" nur architektonische/implementationstechnische Möglichkeiten zur Realisierung und das würde bedeuten, dass man schon einiges "auf der Straße liegen lassen hat", denn andernfalls könnte man so einen Sprung jetzt nicht realisieren.
Bzgl. nVidia wird man wohl nicht allzu lange warten müssen, die Quadro's würde ich wieder zur Siggraph erwarten. Jedoch scheint es nicht unbedingt so, als wenn AMD zeitnah mit RDNA2 ums Eck käme. Weiteren Gerüchten nach scheint Zen3 sich tatsächlich in Richtung "late, late in 2020" zu verschieben, ggf. gar nach dem Konsolen-Launch und da derartige Äußerungen seitens AMD unisono für Zen3 und RDNA2 auch zusammen getätigt wurden, könnte es sein, dass das AMD-Consumer-Update tatsächlich insgesamt erst sehr spät erfolgen wird. Man wird sehen ...
Den Rest einfach als Stuss abtun, sonst gibt es wieder einen "Kopf und Kragen" Diskurs.