Bericht Architektur Deep Dive: So sollen AMDs CDNA-5-GPUs Platzhirsch Nvidia Paroli bieten

CDLABSRadonP... schrieb:
Naja, dann sind AVX-CPUs halt auch GPUs. Der Trick, wieso Larrabee im Gegensatz zu den Xeon Phi eine werden sollte war ja gerade die Nutzbarmachung dieser Rechenleistung für Grafik.
Es gibt schnelle und langsame Vektorrechner.

ETI1120 schrieb:
Es ist gerade die Hardware die das größte Risiko für AMD ist. Das Heliosrack sieht ganz toll aus. Aber es muss eben in hoher Stückzahl produziert werden. Dass die Hardware in den Netzwerktrays nicht von AMD ist, ist eben auch ein Risikofaktor.
AMD hat diese Rack-Butze gekauft:
https://www.heise.de/news/Milliarde...haeft-von-ZT-Systems-an-Sanmina-10389108.html

Und die Switches basieren IMHO auf Chips von Broadcom. Diese Switches basieren auf Ethernet, sind also auch für andere Märkte geeignet.
NV macht immer noch Infiniband? Hat Infiniband außerhalb von NV einen signifikanten Markt?

Daher ist das eher nicht direkt vergleichbar. Oder sollte AMD deiner Meinung noch eine Stahl-Hersteller kaufen weil die Rack ja auch Stahl benötigen? Analüsten labern schon immer viel wenn der Tag lang ist.

Colindo schrieb:
CDNA hatte aber nie die Bezeichnung "L0-Cache" oder? Da war doch immer die klassische L1 und L2 Struktur.
Na ja, zieh dir mal rein wie groß die Register mittlerweile in die diesen Dinger sind, das ist mittlerweile in-memory-computing im L0, Register waren quasi schon immer ein L0.

8-1080.51fd406b.png


Locuza schrieb:
Es ist ja nicht nur der weitgehende Verzicht auf FF HW für die Grafikausgabe, sondern allgemein der Verzicht auf die Grafikausgabe im traditionellen Sinne.
Kein 3D Shader / API-Support, keine direkte Display-Ausgabe.
Man wird sicherlich LLVMpipe auf diese Dinger porten können.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Kitsune-Senpai
Colindo schrieb:
[1] CDNA hatte aber nie die Bezeichnung "L0-Cache" oder? Da war doch immer die klassische L1 und L2 Struktur.

[2] Aber interessant, was du über RDNA 4 sagst. Damit konnte ich mich bei Erscheinen nicht im Detail befassen und hatte nicht bemerkt, dass der L1-Cache entfernt wurde. Überrascht mich, ehrlich gesagt.
[1] Richtig, L0 wurde bei CDNA nie als Startpunkt verwendet, weil dort eine Umbenennung nicht "notwendig" war.
Allerdings habe ich an der Stelle bewusst L0 geschrieben, da CDNA5 nun auf RDNA basiert bzw. der physischen WPG-Struktur.
Dort hat AMD L0 als den Startpunkt gewählt bzw. als Bezeichnung für den CU lokalen Daten Cache:
1785132849231.png


AMD hatte damals bei RDNA 1 die Wahl, ob sie den lokalen Cache weiterhin als L1 bezeichnen und den neuen Cluster-Cache als L2-Cache und den vorherigen L2-Cache als L3.
Stattdessen hat man den L1-Cache in L0 umbenannt, der L1-Cache war ein neuer Cluster-Cache und der L2-Cache funktionell und physisch wie gewohnt.

Man hätte den Cluster-Cache auch L1.5 nennen können, was nachträglich gesehen die „eleganteste“ Lösung gewesen wäre.
Dann wären von der physischen Lokalität und mehrheitlich auch Funktionalität her die L1- und L2-Cache-Bezeichnungen über mehrere Architekturen und Generationen hinweg praktisch gleich geblieben.

[2] Die Hit-Rate des L1-Caches war relativ schwach, und jedes zusätzliche Cache-Level erhöht die Latenzen.
Bei RDNA 4 hat man den L1-Cache in einen einfacheren L1-Buffer umgewandelt, welcher Speicherzugriffe zum L2-Cache nach wie vor aggregiert und steuert, aber selber keine Daten mehr cached.
Um die verlorene L1-Cache-Bandbreite auszugleichen, hat RDNA 4 relativ zu RDNA-3-Chips doppelt so viele L2-Cache-Slices, die Bandbreite und Kapazität wurde verdoppelt.
 
  • Gefällt mir
Reaktionen: Kitsune-Senpai, XD-User, Stramma und 2 andere
Dass AMD irgendwas GPU-mäßig geschweigedenn mobile oder inzwischen sogar APU bringt, das wirklich ein echter Fortschritt ist, glaube ich erst wenn ich es sehe.

Konkurrenz ist immer gut, aber was AMD da gerade im Datacenter-Bereich erreicht verlieren sie woanders. Das mag kurzfristig sich auszahlen doch es steht zu hoffen, dass AMD nicht so dumm ist zu vergessen, wo "reales Geld" zu machen ist wenn die Blase platzt. Als der Kleinere steht man nämlich ziemlich schlecht da, wenn der (mit Abstand) größere gleichzeitig auch noch auf dem Alternativmarkt komplett dominiert, es verstanden hat.
 
p-trettin schrieb:
doch es steht zu hoffen, dass AMD nicht so dumm ist zu vergessen, wo "reales Geld" zu machen ist wenn die Blase platzt.
Consumer kaufen seit Jahren keine AMD-GPUs, egal was AMD macht. "Reales Geld" verdient Radeon (als dGPU) schon lange nicht mehr.

High Performance Computing ist keine Blase, sondern seit vielen Jahren etabliert als großer Markt. Durch KI ist dieser Markt explodiert, und nicht jedes KI-Geschäftsmodell wird sich halten, aber der Markt an sich wird niemals wegfallen, sondern immer reales Geld bringen.

Witzigerweise ist es Nvidia, die den "Alternativmarkt" klassischer HPC-Anwendungen ignorieren, während AMD da immer stärker wird.
 
stefan92x schrieb:
Consumer kaufen seit Jahren keine AMD-GPUs, egal was AMD macht. "Reales Geld" verdient Radeon (als dGPU) schon lange nicht mehr.
AMD hat ja auch seit vielen Jahren da bereits falsche Entscheidungen getroffen (mobile) und Desktop dann mit der aktuellen. AMD macht(e) den Rückzug und das kommt nicht gut im Markt an. Davor war AMD durchaus zwar nie führend aber auf einem soliden Weg. Im Prinzp war mit der 6000 mobile der Punkt ab dem es hätte was werden können und AMD tut es eben dann nicht.
Desktop die jüngste Entwicklung Desktop, warum keine Oberklasse, ist genau so dumm, genau so dumm wie das Namensschema an Nvidia anzugleichen, damit die Identität teilweise aufzugeben.

APUs dann RDNA 4 vorzuenthalten ist ebenfalls dumm, denn mit APUs macht AMD aktuell richtig Geld. Intel ist da jetzt technisch vorne.
stefan92x schrieb:
High Performance Computing ist keine Blase, sondern seit vielen Jahren etabliert als großer Markt. Durch KI ist dieser Markt explodiert, und nicht jedes KI-Geschäftsmodell wird sich halten, aber der Markt an sich wird niemals wegfallen, sondern immer reales Geld bringen.
Ganz wegfallen nicht, das ist klar. Aber der Markt wird zusammenbrechen. Musst ja auch bedenken, dass da auch Rechenkapazitäten aufgebaut werden, die vielleicht dann umgenutzt werden müssen (und hoffentlich können), d.h. ein Überangebot an Rechenleistung am Markt ist.
stefan92x schrieb:
Witzigerweise ist es Nvidia, die den "Alternativmarkt" klassischer HPC-Anwendungen ignorieren, während AMD da immer stärker wird.
Vielleicht begreift sich Nvidia ja doch eher im Gaming zu Hause, während AMD sich eher da zu Hause sieht (oder da seine Nische gefunden hat). Ich bin da aber nicht so drin. Keine Ahnung was "klassische HPC-Anwendungen" von dem unterscheidet, was Nvidia mit seiner Produktpalette abdecken kann.

Ist ja gut wenn AMD da ein sicheres Standbein hat. Ich kann mir nur konstant wundern wie AMD sehenden Auges eine Chance nach der nächsten ziehen lässt und so ein Segment nach dem anderen verliert, unnötig, vollkommen unnötig. Und AMD hat gutes Geld mit Consumer-Produkten verdient, und da ist auch weiterhin gutes Geld zu verdienen.
 
p-trettin schrieb:
Keine Ahnung was "klassische HPC-Anwendungen" von dem unterscheidet, was Nvidia mit seiner Produktpalette abdecken kann.
AI braucht vor allem kleine Zahlenformate, HPC liebt große mit hoher Präzision. AMD legt jetzt mit der MI430X ein spezielles Produkt für diesen Markt auf, wären die MI455X genauso auf den AI-Bedarf optimiert ist wie Nvidias GPUs.
p-trettin schrieb:
Ist ja gut wenn AMD da ein sicheres Standbein hat. Ich kann mir nur konstant wundern wie AMD sehenden Auges eine Chance nach der nächsten ziehen lässt und so ein Segment nach dem anderen verliert, unnötig, vollkommen unnötig.
AMD ist zu klein, um sich auf alle Märkte gleichzeitig zu stürzen. Wenn man sich da zu sehr verzettelt, hängt man überall hinterher.
 
stefan92x schrieb:
AMD ist zu klein, um sich auf alle Märkte gleichzeitig zu stürzen. Wenn man sich da zu sehr verzettelt, hängt man überall hinterher.
Das arme, kleine AMD ist gar nicht mehr so klein. Schau dir mal den Umsatz von AMD an und den von Intel.

AMD Q1 2026: 10,2 Mrd
Intel Q1 2026: 13,5 Mrd.

Abgesehen davon ist die Radeon RX 9000-Serie fertig entwickelt. Was hat AMD daran gehindert die Radeon RX 9000-Serie in den mobilen Markt zu schicken? Wo hätte man sich da bitte verzettelt?
Mit der Entscheidung keine mobile dGPU in den Markt zu lassen, hat man weitere Marktanteile verloren. Das ist schlecht, wenn man einen Entwickler dazu bewegen möchte FSR in sein Spiel zu integrieren...

Stattdessen versucht AMD uns mit RDNA 3.X-APUs zu beglücken und auch Valve holt sich eine alte, RDNA 3.0 mobile Grafikkarte für die Steam Machine, weil es keine neuere mobile dGPU von AMD gibt... obwohl die Chips fertig entwickelt im Deskop verkauft werden...
 
Der AMD EPYC 9006 LP ist die Antwort des Unternehmens auf die Vera-CPU von NVIDIA.

Der AMD EPYC™ 9996 mit 512 Threads liefert unglaubliche 330 % mehr Leistung als Vera und im HPC-Bereich (High-Performance-Computing) sogar 600 %.
Ein Prozessor dieser 9006er-Serie mit 144 Threads übertrifft bereits den aktuellen Vera in Sachen Leistung.

eine Speicherbandbreite von 1.6 TB/s – die erste PCIe-Gen-6-Schnittstelle in einer Server-CPU


Der XGU CDNA5 hat mich aus technischer Sicht wirklich sehr beeindruckt.

Es ist unglaublich, wie viele Transistoren er hat.

Die Geschwindigkeit von 23.3 GB.

Die Menge an HBM4-Speicher, über die er pro Einheit verfügt.

Die Möglichkeit, das gesamte Potenzial mit dem Helios-Rack zu bündeln.

Die Entwicklung einer speziellen Hardware innerhalb des XGU, die bestimmte mathematische Funktionen verbessert, ist etwas Neues.

Die Vera-CPUs von Nvidia eignen sich nicht für HPC (wissenschaftliches Hochleistungsrechnen).

Die AMD-x86-CPUs eignen sich gut für den doppelten Einsatzzweck KI/HPC.

Eine ausgereifte Software, da sie auf x86 und nicht auf ARM basiert.

Bei der agentenbasierten KI wird die CPU stärker genutzt als die XPU, und in Zukunft werden wir Server mit bis zu vier CPUs und nur einer XPU sehen.



Wenn es darum geht, Probleme zu lösen oder Lösungen für Probleme zu finden, die nicht in der KI und im Wissen ihres KI-Modells gespeichert sind – so wie es ein Mensch tut.
 
Zuletzt bearbeitet:
p-trettin schrieb:
Desktop die jüngste Entwicklung Desktop, warum keine Oberklasse, ist genau so dumm, ...

...

Vielleicht begreift sich Nvidia ja doch eher im Gaming zu Hause, ...
Ernsthaft? Nvidia weist seit kurzem die Gaming Sparte nicht mehr extra aus, das läuft zusammen mit dem anderen Krümmelkram. Wenn sich jemand von Gaming wegbewegt, dann Nvidia.

Und warum sollte AMD eine Oberklassen Karte abieten? Damit sie trotzdem nicht gekauft wird? Irgendwas ist ja immer, sei es weniger frames/energieffizienz/kein cuda whatever.

Welche Segmente verliert AMD den eins nach dem anderen? Im Serverumfeld sind die gut unterwegs, bei HPC sowieso und langsam werden sie auch im AI Umfeld ein echter Wettbewerber. Und im Gaming sind sie Dank der Konsolen auch noch gut unterwegs.
Der PC Spieler ist kein Wachstumsmarkt, da macht Mobile ja schon fast mehr Umsatz. Wenn ich mir AMDs Börsenkurs so anschaue haben sie alles richtig gemacht die letzten Jahre.
 
Colindo schrieb:
Der L1-Cache scheint sich verdoppelt zu haben, der Instruction Cache aber nicht.
Ich dachte erst du würdest falsch liegen aufgrund von AMDs Folie. Aber CDNA4 teilt den I$ zwischen zwei CU, CDNA5 je WGP.

Auf AMDs Folie sieht es so aus, als wäre es ein I$ pro shader engine.
 
  • Gefällt mir
Reaktionen: Colindo
Mextli schrieb:
Ernsthaft? Nvidia weist seit kurzem die Gaming Sparte nicht mehr extra aus, das läuft zusammen mit dem anderen Krümmelkram. Wenn sich jemand von Gaming wegbewegt, dann Nvidia.
Was Nvidia wie ausweist interessiert doch erstmal keinen Kunden. Am Ende ist es Nvidia, die nach wie vor von der absoluten Einstiegs dGPU bis zur High-End dGPU sowohl Desktop als auch mobile alles (ab)liefert. Da gibt es nichts dran zu drehen. Dass die da bei der 5000er Generation sich jetzt kein Bein ausgerissen haben, ist zwar sehr richtig, aber das wiederum muss ein quasi-Monopolist halt auch nicht. Sollte Nvidia jetzt das Portfolio eindampfen oder keine neue Technik mehr bringen, dann können wir da von einem "Wegbewegen" sprechen. Und genau das machte und macht AMD.
Mextli schrieb:
Und warum sollte AMD eine Oberklassen Karte abieten? Damit sie trotzdem nicht gekauft wird? Irgendwas ist ja immer, sei es weniger frames/energieffizienz/kein cuda whatever.
Die Desktop Oberklasse wurde doch gekauft. Hier haben doch einige eine. Mobile hatten sie in der 7000er Generation ja schon nichts mehr wirklich am Markt (ja ich weiß es gibt sie, ich besitze eine rx7800m). Bei der 6000er Generation gab es sie noch wirklich und sie wurden auch gekauft.
Mextli schrieb:
Welche Segmente verliert AMD den eins nach dem anderen? Im Serverumfeld sind die gut unterwegs, bei HPC sowieso und langsam werden sie auch im AI Umfeld ein echter Wettbewerber. Und im Gaming sind sie Dank der Konsolen auch noch gut unterwegs.
Der PC Spieler ist kein Wachstumsmarkt, da macht Mobile ja schon fast mehr Umsatz. Wenn ich mir AMDs Börsenkurs so anschaue haben sie alles richtig gemacht die letzten Jahre.
Und wo hat AMD gerade erst durch Stillstand das Zepter abgegeben? APUs. Intel B390 lässt die alten RDNA 3(.x)-Gurken stehen. Mehr noch, die APUs sind sogar CPU-seitig heute nominal schlechter als die alten 7000er außer man kauft den 12-Kerner und lässt ihn gegen den 8-Kerner antreten. Im Prinzip sind einzig und allein noch die CPUs ohne nennenswerter iGPU überhaupt konkurrenzfähig im Notebook und bei APUs ist nur noch die Strix Halo Brechstange schneller als ne B390. Und der "neue" Strix Halo (wie der auch immer heißt) kann gar nix neues, wie alle APUs. Stillstand.

Ich finde es ja toll wie aktuell schnell mein 7940HS plus rx7800m eGPU noch ist, aber es zeigt wie AMD im Moment gerade mobile aufgestellt ist. Ich hab ernsthaft das Gefühl die letzten ihrer Art für eine sehr lange Zeit hier zu haben, was mich als langjähriger AMD Fan ein geteiltes Gefühl ist.
 
SaschaHa schrieb:
Naja, in vielen Bereichen ist es ein Quasi-Monopol, da man für bestimmte Anwendungen eben an Nvidia gebunden war. Das wird sich dann hoffentlich ändern, sobald die Unterstützung für ROCm flächendeckend verfügbar ist und ordnungsgemäß funktioniert. Da hat sich zwar enorm viel getan, aber einige Baustellen gibt es halt noch.
Es geht nicht nur um NVIDIA und AMD.
 
  • Gefällt mir
Reaktionen: uberLemu
Colindo schrieb:
Aber interessant, was du über RDNA 4 sagst. Damit konnte ich mich bei Erscheinen nicht im Detail befassen und hatte nicht bemerkt, dass der L1-Cache entfernt wurde. Überrascht mich, ehrlich gesagt.
@Locuza
So ganz stimmt das mit dem L1-Cache nicht, dass der entfernt wurde:

"The AMD RDNA4 devices offer several methods for access to off-chip memory from the processing elements
(PE) within each WGP. On the primary read path, the device consists of multiple channels of L2 cache that
provides data to read-only L1 caches, and finally to L0 caches per WGP. The memory cache is formed by two
levels of cache: the first-level (GL1) for write-combining cache (collect scatter and store operations and
combine them to provide good access patterns to memory); the second (L2) is a read/write cache with atomic
units that lets each processing element complete unordered atomic accesses that return the initial value.
Specific cache-less load instructions can force data to be retrieved from device memory during an execution of
a load clause."

S. 8 der RDNA 4 ISA. Dazu von Seite S.5 die Grafik:
1785320849907.png
 
  • Gefällt mir
Reaktionen: ETI1120
@DevPandi

Das ist ein Copy & Paste-Fehler bei der ISA doc.
Kommt immer mal wieder vor.
Abseits von dem Segment hat AMD alle früheren L1-Referenzen richtigerweise entfernt.

Beim LLVM Memory Model werden die Unterschiede zwischen RDNA4 (GFX12) und früheren Generationen ausführlich beschrieben:
https://rocm.docs.amd.com/projects/...llvm/html/AMDGPUUsage.html#memory-model-gfx12

Bei Latenztests sieht man auch keine klar definierte 128/256 KB L1-Schranke mehr, wie noch zuvor bei RDNA1-3:
1785325093123.png

https://chipsandcheese.com/p/amds-rdna4-gpu-architecture-at-hot
 
  • Gefällt mir
Reaktionen: Colindo und ETI1120
Locuza schrieb:
Abseits von dem Segment hat AMD alle früheren L1-Referenzen richtigerweise entfernt.
Haben Sie das ... Interrsant - nun auch die Commity im LLVM zeigen da ein etwas anderes Bild, was an der Stelle auch komplizierter wird.
The scalar memory operations access a scalar L0 cache shared by all wavefronts on a WGP. The scalar and vector L0 caches are not coherent. However, scalar operations are used in a restricted way so do not impact the memory model. See Memory Spaces.

The vector and scalar memory L0 caches use an L1 buffer shared by all WGPs on the same SA. The L1 buffer acts as a bridge to L2 for clients within a SA.

The L1 buffers have independent quadrants to service disjoint ranges of virtual addresses.

Each L0 cache has a separate request queue per L1 quadrant. Therefore, the vector and scalar memory operations performed by different wavefronts, whether executing in the same or different work-groups (which may be executing on different CUs accessing different L0s), can be reordered relative to each other. Some or all of the wait instructions below are required to ensure synchronization between vector memory operations of different wavefronts. It ensures a previous vector memory operation has completed before executing a subsequent vector memory or LDS operation and so can be used to meet the requirements of acquire, release and sequential consistency.

s_wait_loadcnt 0x0

s_wait_samplecnt 0x0

s_wait_bvhcnt 0x0

s_wait_storecnt 0x0

The L1 buffers use an L2 cache shared by all SAs on the same agent.

The L2 cache has independent channels to service disjoint ranges of virtual addresses.

Each L1 quadrant of a single SA accesses a different L2 channel. Each L1 quadrant has a separate request queue per L2 channel. Therefore, the vector and scalar memory operations performed by wavefronts executing in different work-groups (which may be executing on different SAs) of an agent can be reordered relative to each other. Some or all of the wait instructions below are required to ensure synchronization between vector memory operations of different SAs. It ensures a previous vector memory operation has completed before executing a subsequent vector memory and so can be used to meet the requirements of acquire, release and sequential consistency.

s_wait_loadcnt 0x0

s_wait_samplecnt 0x0

s_wait_bvhcnt 0x0

s_wait_storecnt 0x0
[...]

In WGP wavefront execution mode the wavefronts of a work-group are executed on the SIMDs of both CUs of the WGP. Therefore, explicit management of the per CU L0 caches is required for work-group synchronization. Also accesses to L1 at work-group scope need to be explicitly ordered as the accesses from different CUs are not ordered.

In CU wavefront execution mode the wavefronts of a work-group are executed on the SIMDs of a single CU of the WGP. Therefore, all global memory access by the work-group access the same L0 which in turn ensures L1 accesses are ordered and so do not require explicit management of the caches for work-group synchronization.

Und ja, es kann ein Copy-Paste-Fehler sein, aber mit den LLVM Infos...
1785333587664.png

RDNA 3 - Seite 5
1785333612438.png

RDNA 4,

Nimmt man alles zusammen, ist der L1-Cache an der Stelle nicht einfach verschwunden, sondern wird im ganzen anders in die Kette eingebunden - was auch die Latenzen erklärt.

-- Und um das ganze mal zumindest versöhnlich zu Ende zu bringen: Der L1-Cache in der "klassischen" Form, wie bei RDNA 1 - 3 existiert nicht mehr, richtig. Aber der L1 wird jetzt als Lese-Buffer genutzt. Die Daten werden im L2 angefragt, liegen dann aber im L1 bereit zum Abholen, das erklärt eben auch, warum sich die Latenzmessungen hier geändert haben und der "Spike" geglättet wird - was im Ganzen sich positiv auf die Latenzen und eben den Durchsatz auswirkt, gleichzeitig den L2 allerdings dennoch entlasstet.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ETI1120
@DevPandi

Es gab zuvor noch mehrere Referenzen für die entsprechenden Memory-Befehle und Control-Bits:
RDNA3 ISA:
"8.1.3. S_DCACHE_INV and S_GL1_INV
This instruction invalidates the entire scalar cache or L1 cache. It does not return anything to SDST."
"MUBUF Instructions
BUFFER_GL{0,1}_INV Cache invalidate: either L0 or L1 cache for the CU (L0) and Shader Array (L1) associated with this wave."
"Instruction Fields
DLC 1 Device Level Coherent. Controls behavior of L1 cache (GL1)."

Der entsprechende Scope Abschnitt bei RDNA4 spricht aus meiner Sicht fälschlicherweise von 4 Cache Levels und einem SE Cache:
The ISA SCOPE bits correspond to the 4 cache levels and indicates whether a given cache can do an operation
locally or whether it needs to forward the operation to a next level in the cache hierarchy to complete the operation at the desired scope (coherence domain).
# Name Meaning
0 CU Compute Unit (Work-group) Scope - coherent among all VMEM threads in a CU (work-group, but not a WGP)
1 SE Shader Engine - coherent among all clients (threads) sharing a SE-cache
2 DEV Device - coherent among all threads on the same device
3 SYS System

Weiter unten listet man dann aber nur den L0 v$ (CU$) und L2$ auf:
ScopeCU$L2$
0-CUNOPNOP
1-SEwb/wbinv/invNOP
2-DEVwb/wbinv/invNOP
3-SYSwb/wbinv/invwb/wbinv/inv
"Table 16. VMEM Policies for Writeback and Invalidate Ops"

Ansonsten gibt es auch keine Referenzen zu einem L1 Cache.

Das LLVM Memory Model für RDNA4 hat explizit alle L1 Cache Referenzen zu L1 Buffer umbenannt, weil es an der Stelle kein Cache mehr ist.

RDNA1-3 (GFX10, 10.3, 11) Abschnitt als Vergleichsreferenz:
  • The vector and scalar memory L0 caches use an L1 cache shared by all WGPs onthe same SA. Therefore, no special action is required for coherence between the wavefronts of a single work-group.
    However, a buffer_gl1_inv is required for coherence between wavefronts executing in different work-groups as they may be executing on different SAs that access different L1s.
  • The L1 caches have independent quadrants to service disjoint ranges of virtual addresses.
  • The L1 caches use an L2 cache shared by all SAs on the same agent.

Das hat man auch noch in der RDNA4 ISA Doc geschafft (Seite 7):
1785339434369.png


Vs. RDNA3:
1785339497128.png



Übrigens war der L1 Cache von Anfang an ein Read-Only-Cache (RDNA 1-3).
Beim RDNA4 L1 Buffer werden keine ordinären Programmdaten mehr gecached, bei einem L0 Miss muss danach der L2 Cache gechecked werden, im L1 Buffer gibt es garantiert nichts.
 
Zuletzt bearbeitet:
Sapphire Forum
Zurück
Oben