AMD RDNA2 / Navi-2 und "Bignavi"

Naja wenn man halt nicht versteht, dass in dem Lied die Zeile:
I love ya tomorrow!
You're always
A day
Away!

Bedeutet, dass die Zukunft immer einen Tag entfernt ist. Zudem ist es sein Job auch die OEM-Launches zu begleiten als..
Chief Architect of Gaming Solutions ist ein ziemlich einzigartiger Titel. Wie ist er entstanden? Was bedeutet er im Hinblick auf die Aufgaben, die diese Position umfasst?

Meine Position bei AMD und in der Gaming-Branche ist einzigartig und in vielerlei Hinsicht die erste ihrer Art. Aus diesen Gründen war es zunächst einmal gar nicht so klar, wie die Bezeichnung lauten sollte. Dann haben wir uns aber schließlich auf Chief Architect for Gaming Solutions geeinigt.

Was genau die Position beinhaltet, ist in gewisser Weise selbst vertrauliches geistiges Eigentum von AMD. Ich kann also nicht zu viele Details verraten. Was ich aber sagen kann: Man kann davon ausgehen, dass mein Team bei AMD und ich disruptiv arbeiten und Innovation für Gamer ganz in den Mittelpunkt stellen werden. Das gilt für alles, was wir tun.

Hier werden OEM-Marketing und Co-Branding bei AMD neu definiert von ihm. Mal sehen wie das bis Ende des Jahres aussieht.
 
Ich habe noch etwas Spekulatives zum knobeln:

Unter der Annahme die Bandbreite des schnelleren Speicherbereich der kommenden Xbox Konsolen ist im Design jeweils eine Punktlandung des Bedarf je CU kommt man mit Normierung des Taktes und einer angenommenen identischen Reserve für Bandbreite des Headrooms der GPU-Funktionen auf 5.3 GB/s je CU je 1GHz sowie 60 GB/s Headroom für anderen Traffic.

Bei einer angenommenen Big Navi mit 80 CUs bei 1.8 GHz würde man eine Speicherbandbreite von 758 GB/s erwarten plus Headroom für andere Dinge.

Ergänzung
bei RDNA1 sind wir heute mit
40CU@1.75 bei 448 GB/s incl. Headroom vs. theor. RDNA2 bei 369+Headroom (79)
36CU@1.56 bei 336 GB/s incl. Headroom vs. theor. RDNA2 bei 296+Headroom (40)
22CU@1.85 bei 224 GB/s incl. Headroom vs. theor. RDNA2 bei 215+Headroom (9)
 
Zuletzt bearbeitet:
Ja ich habe abgeschaltet als er dem Infinity Cache GDDR6X zugeordnet hat. Das ist Nvidia exklusiver Speicher. Wenn er das noch nicht in seinen Infos hat, dann weiss ich nicht wo er seine anderen her bekommt. Und der Verweis auf Adored macht es um so weniger handfest. Nach 3 min. hatte ich schon das Gefühl, der saugt sich alles aus den Fingern - die Körpersprache war jedenfalls voller solcher Zeichen.
 
Hm, nein das hat er nicht. Er meinte der Cache macht die Performance eines GDDR6x wett, bzw. kann den Nachteil ausgleichen wenn er nicht vorhanden ist. Deshalb das nachfolgende Zitat des RDNA1 Tests mit runtergetaktetem Speicher, das wegen dem besseren Caching auch besser abschneidet als GCN.

Eigentlich verzichte ich auf News von RGT, mir schien das idR nur jeweils zusammengefasstes aus der Gerüchteküche zu sein. Die 128 MB Cache sind allerdings nur bei ihm aufgetaucht.

Zumindest hätte ein entsprechend grosser sehr schneller Zwischenspeicher den Vorteil locker einen Triple-Buffer in 4K aufzunehmen (100MB). Soetwas würde das SI extrem entlasten wenn es als Write Through realisiert würde. Es würde auch ein I/O Chiplet losgelöst von Compute-Chiplets begünstigen. Deshalb gefällt mir die Story.

-----
er fährt fort "unbestätigt"
GDDR6, 256Bit, 16GB, 128 MB Infinity Cache nicht inkludierend, nicht Teil der Cache Hierarchie, Cache definiert Clock-Wall circa bei PS5 Takt (2.23GHz) oder höher bei Golden Samples, 250Watt, und er zweifelt nennt aber den Leak über neue Form von SmartShift.
 
Zuletzt bearbeitet:
Leider hat man von den Ryzen-Produktmanagern nichts gelernt. Hätte man bei BigNavi auch RGB-Kühler verbaut könnte man künftig grosszügig Marktanteile erobern ;)
 
@E555user
Ja da hatte ich mich verhört - sorry für den Einwurf.
 
Der Typ ist das Parade-Youtube-Manchild... kindisch, leicht beleidigt, eingebildet, meint er weiß alles besser... in Wahrheit produziert er nur heiße Luft

Zu viel Eitelkeit und zu wenig Professionalität.
 
Der angebliche 128MB-Cache auf Navi-21 macht durchaus Sinn: der L3 von Zen-2 verbraucht zwar etwa 35mm²/32MB (=140mm²/128MB), aber dieser dürfte ein HP-Cache sein. Die HD-Sram-Cells sollen auf 7nm deutlich dichter sein, zudem dürfte der Cache auf der GPU weniger kompliziert aufgebaut sein, als bei einer CPU, sodass ich hier davon ausgehe, dass er die doppelte Dichte haben dürfte, zumal Navi womöglich sogar in N7+ sein könnte.

Sinn macht ein solcher Cache, weil damit der Datentransfer zum Speicher niedriger wird, was nicht nur billigeren GDDR6 und ein schmaleres Ram-Interface ermöglicht, das günstiger ist weil es das PCB einfacher macht. Der kleinere Ram-Controller spart nämlich wiederum Die-Space ein (was eine Teil des Die-Space vom Cache wett macht) und er reduziert vor allem den sehr energieaufwändigen Speicherzugriff, womit der Energieverbrauch der gesamten Graka sich reduziert, was vor allem für Notebook-Grakas sehr wichtig ist.

Last but not least dürfte ein solches GPU-Design performance-mäßig mit steigenden Takten viel besser skalieren, weil es weniger von der Ram-Anbindung abhängig ist, was meines Erachtens dann interessant ist, wenn man es auf 5nm shrinkt....und was bietet sich meh für 5nm an, als ein einfacher Shrink einer GPU? Ich kann mir sehr gut vorstellen, dass AMD genau das vor hat, nämlich Navi so schnell wie möglich auf 5nm zu shrinken. Damit wird er schneller, billiger und nochmals effizenter.
 
Den RAM gab es schon mal mit der IGP Chipsatzgrafik als Sideport Memory. In Infinity kann man viel hineinspekulieren.

Aufteilung in CU Blöcke mit unterschiedlichen Boosttakt je nach Güte? Würde ein Stück weniger Verbrauch bedeuten.
 
Den RAM gab es schon mal mit der IGP Chipsatzgrafik als Sideport Memory. In Infinity kann man viel hineinspekulieren.
Ich denke eher an Zugewinne der Iris Pro 5200 IGP mit 128MB auf dem Package, das hatte sehr gut funktioniert.
Innerhalb des Die wäre noch vorteilhafter, aber keine gute Vorstufe zu Chiplet GPUs. Als Infinity Cache würde mir ein Cache im Interposer zwischen I/O mit MC, VCE, Command Processor und Geometrie Processor einerseits und einem CU Chiplet auf der anderen Seite gut gefallen.

Wie auch immer die Caches verteilt sind, es müsste zur Weiterentwicklung von RDNA1 passen und vielleicht auch ein wenig für künftige Chiplet GPUs geeignet sein.
 
MLID will von einem Engineering Sample wissen:

Navi21, 60CUs, >2GHz, 256-Bit GDDR6 mit 16GB und einem grossen Satz Caches.
Er erinnert daran, dass bereits M. Cerny in der PS5 Präsentation auf die Lokalität der Daten bei RDNA2 hingewiesen hat, sowie den eigenen Cache Scrubber, der wohl eher nicht Teil von Navi2X sein wird.

Hier nochmal Graphiken zu RDNA1 Caches:
7nm-navi-gpu-a-gpu-built-for-performance-21-1024.jpg


7nm-navi-gpu-a-gpu-built-for-performance-20-1024.jpg
Das Infinity Fabric wird bei RDNA1 erst zwischen dem L2-Cache und dem Speicher genutzt. Das war auch schon bei Vega so.

Evolutionär sollte ein zusätzlicher Cache per IF vor dem L2-Cache sein und das SI auch von Zugriffen durch die Display-Engine entlasten wenn das Render-Target geschrieben und wieder ausgelesen wird, hier an der Stelle SOC Fabric.
7nm-navi-gpu-a-gpu-built-for-performance-22-1024.jpg

Sollte an dem Gerücht von 128 MB IF Cache etwas dran sein könnte aus meiner Sicht am ehesten ein L3 Cache direkt nach dem L2 OnDie Sinn ergeben, der in einem MCM via IF kohärent gehalten würde. Der relativ kleine und schnelle L2 könnte bleiben wie er ist und ein grösserer L3 würde zwischen mehreren Chiplets via IF abgeglichen und gleichzeitig das SI weiter entlasten. Die Shader Engines je Chip würden via L2 austauschen, die einfach vorhandenen Einheiten einer GPU müssten den L3 bemühen. Sollten letztere nicht mit mehreren L3 auf Chiplets umgehen können müsste es ein zentraler L3 sein. Dann müsste der L2 jew. etwas grösser ausfallen um das wieder ausgleichen zu können. Die Schwierigkeit bei GPUs ist, dass der Code immer von einem Scheduling in einer GPU ausgehen will, entsprechend müsste bei Verteilung von Shader Engines auf mehrere Chiplets das Scheduling bzw. Command Processing zentralisiert werden.
 
Ich kapiere das mit dem Cache noch nicht. Kann mir da jemand eine "einfache" Erklärung für geben? - Gerne per PM.
Ich meine wie sollen 128 MB so viele Vorteile haben - wo wir eigentlich über RAM Anbindungen sprechen wo es um 12GB - 16 GB geht. Klar der VRAM ist nicht so schnell [das ist mir auch klar] - aber wie sollen dann 128 MB die ganze Sache so sehr beschleunigen? Ich mein der muss ja die ganze Zeit voll sein [auch wenn man den sehr schnell neu füllen werden kann]. Aber ein Cache spielt doch seine Stärke aus weil man da Daten ablegt die sehr häufig wieder benötigt....
Aber die reine Menge müsste doch bei 3D Bildern deutlich größer sein?!
 
Das kann derzeit keiner erklären wie das Gerücht gemeint ist - es kann auch völliger Humbug sein.
Ich persönlich rechne am ehesten mit etwas wie einem HBCC-Nachfolger der kein HBM benötigt und dafür einen solchen "Infinitiy-Cache" nutzt.
Vom Prinzip wie dieses Schaubild:
GPU_mtk_SO.jpg


Der Zugriff auf die angebundenen Speicherressourcen erfolgt dann über PCIe mit atomic read/write und unified memory. Siehe CCIX.

Die Radeon SSG nutzt das für professionelles Echtzeit-Rendering. AMD hat hier möglicherweise einen Weg gefunden mit DirectStorage Die benötigte Bandbreite zum VRAM zu reduzieren. Nur wie das genau und ob das überhaupt zutrifft weis halt auch noch keiner. Ist nichts bestätigt davon
 
Ich meine wie sollen 128 MB so viele Vorteile haben - wo wir eigentlich über RAM Anbindungen sprechen wo es um 12GB - 16 GB geht.
Das hängt ganz von der Applikation ab und wie diese eine GPU nutzt. Auch PC-Applikationen mit vielen GB RAM Bedarf profitieren von grossen L3 Caches bei der CPU. Es ist ähnlich.
Bei GPUs wurden schon die letzten Jahre mehr und mehr Caches eingeführt um die Datenlokalität relativ zu den Ausführungseinheiten zu erhöhen. Dafür wurde dann z.B. Tile Based Rendering notwendig um für die vielen kleinen Caches gut Ergebnisse zu erzielen. Mit Polaris und Vega wurde GCN für einen gemeinsamen und grösseren L2 Cache umgebaut. Ein L3 oder jede weitere Entwicklug bei Caches wäre eine Weiterentwicklung in diesem Sinne.
Beim Rendern werden mitunter jede menge Speicherpuffer generiert, die Zwischenergebnisse halten bevor der nächste Schritt in der Renderpipeline anliegt. Die Daten sind vielfach grösser als die L2 Caches, enthalten aber nicht die Gigabyte an Texturen. Dort kann ein grösserer Cache entlasten, vgl. Forward vs. Deferred Rendering. Es hängt viel von der Software ab. Da aber die in der Regel gegen eine API programmiert wird und der Treiber und die Hardware das Caching organisieren können liegt es dann am Hardwarehersteller die geeigneten API-Aufrufe mit Code oder Daten der Anwendung zu Cachen um das möglichst gut auszunutzen, das müsste ggf. pro Applikation optimiert werden. Aber selbst wenn man ganz altertümliches immediate Rendering auf ein Target macht und das in mehreren Schritten per überlagerte Dreiecke aufbaut und abschliessend beleuchtet mit Postprocessing und Antialiasing aufhübscht würde selbst bei 4k der notwendige Bildaufbau des Targets in einen 30-40MB grossen Cache beschleunigt gelesen und geschrieben werden können.
Solange das Rendertarget mehrfach in einen Cache passt kann man den Speicherzugriff erheblich entlasten.
 
Sorry aber hilft mir noch immer nicht wirklich weiter.
Generell wie ein Cache funktioniert ist mir klar. Bei CPU`s muss er nicht so groß sein, da hier oft nur Variabeln, Ergebnisse zwischengespeichert werden die man aber im späteren Verlauf immer wieder braucht. Die Beschleunigung resultiert daraus, das man diese häufig benötigten Daten aus dem deutlich schnelleren Cache zieht anstatt jedes mal aus dem RAM oder schlimmer noch von Festplatte zu laden.

Selbes Prinzip gilt ja eigentlich auch bei GPU`s. Nur a) wieso kam vorher keiner auf die Idee [hier habe ich schon Spekulationen zu gehört - Raytracing könnte es Sinnvoll werden lassen - wobei ja auch noch spekuliert wird auf welcher Ebene dieser Cache eingefügt wird - Analogie zur CPU - hier gibt es ja auch verschiedene Level]

Nur reden wir hier von 3D Bildern... Das was wirklich Bandbreite kostet sind doch eher die Texturen - das 3d Polygon Modell selbst sollte ja noch gehen. Texturen passen aber nur bedingt in 128 MB. Das Polygon Modell passt dann schon eher - aber wird auf das so viel zugegriffen während des Rendern?

[Beim Polygon Modell kann ich mir noch eines Vorstellen - das zu Cachen macht in einem Game Sinn - von Frame zu Frame wird dann nur der Bereich des Modells modeliert das sich geändert hat... Drehungen z.B. von Objekten wären ja "recht" einfach umzustezen z.B. - oder lineare Bewegungen durch den Raum]

Oder muss ich es mir eher so vorstellen - das fertige Frame wird gecachet um dann Postprocessing Effekte ablaufen zu lassen? Aber wieviel Frames passen denn in 128 MB? Bei unkomprimierten Bildern in der entsprechenden Auflösung im Zweifel nicht mal ein ganzes oder?

Die Gerüchte gehen ja auch in die Richtung, dass das der Grund sein soll wieso AMD es sich "leisten" kann nur 256 Bit bzw. 384 Bit breite Speicherinterfaces zu nutzen mit Standard GDDR 6. Die ganzen Einheiten auf RDNA2 wollen schließlich ausgelastet werden...

Ich lese mir jetzt mal den Artikel Forward vs. Deferred Rendering durch - vielleicht kommt dann ja die Erkenntnis.
 
@Novasun
Texturen kosten vor allem Speicherplatz und weniger Bandbreite denn die Bandbreitenfresser sind eher die Bereiche wo immer und immer wieder darauf zugegriffen und bearbeitet wird bevor das Bild fertig ist. Ich kann mir vorstellen das der Framebuffer hierfür wichtig ist aber auch der Tiefenpuffer dürfte hier gut zu tuen haben. Mit Sicherheit gibt es dann auch noch diverse andere Aufgaben die ähnliche Anforderungen haben.
Im übrigen gab es schon mehrfach GPUs die auf einen kleinen Zwischenspeicher zur Beschleunigung setzten.
Da wären im Konsolenbereich z.B. diverse xbox Chips die einen zusätzlichen eDRAM besaßen oder Intels Iris Pro Lösung mit zusätzlichem eDRAM.
Der größte Grund warum eine solche Lösung eher ungern eingesetzt wird ist wohl das er vergleichsweise teuer und unflexibel ist.
 
Aber wieviel Frames passen denn in 128 MB? Bei unkomprimierten Bildern in der entsprechenden Auflösung im Zweifel nicht mal ein ganzes oder?
...
Ich lese mir jetzt mal den Artikel Forward vs. Deferred Rendering durch - vielleicht kommt dann ja die Erkenntnis.

Ein Frame hat Pixel in Horizontalen x Vertikale x 3 Farbwerte x 8Bit oder 10Bit bzw. 3 oder 4 Byte je Pixel.
Beii Targets für Zwischenberechnungen können die Byte pro Pixel variieren oder man rechnet auch mal Zwischenschritte in geringerer oder höherer Auflösung. Das Ganze um den Faktor 60 oder simpel auch mal 100 FPS. Dann bekommt man ein Gespür wozu die Bandbreite notwendig ist und bei welcher Grösse. Texturen werden mehrfach in Mipmaps vorgehalten, künftig mit Sampler Feedback könnte dort auch ein grosser Cache jenseits üblicher L2 viele Hits generiere.
 
Zuletzt bearbeitet:
Wenn sie damit performance-technisch an die 3080 rankommen hört sich das doch schonmal ganz gut an! *great*
 
Zurück
Oben Unten