Kacha schrieb:
Das war denke ich eher die erste Stufe. Also fixe Cluster zu definieren die unter sich ihre L1 Caches sharen koennen.
Deswegen schrieb ich ja auch, dass man es in einer vereinfachten Form umgesetzt hat.
Das Paper geht natürlich noch mal ein Stück weiter mit der dynamischen Aufteilung. Nur sieht man durchaus Anleihen aus dem Patent als auch eben dem Paper bereits in RDNA, besser man sieht eine entsprechende Reorganistation der CUs zu den WGP und dass man für die WGPs nun einen gemeinsamen L1-Cache verwendet.
Kacha schrieb:
Das hat es in RDNA1 eben noch nicht gehabt. Natuerlich bringt das ganze etwas Overhead mit, allerdings ist es die naetuerliche Weiterentwicklung der fixen Einteilung.
Stimme ich dir vollkommen zu, ich denke das wird bei AMD auch der nächste Schritt sein, bei RDNA2 sehe ich den Schritt aber noch nicht, eher dann bei RDNA3 eventuell sogar erst bei RDNA4.
Wobei hier auch die Frage ist: Kommt das Patent auf CU/WGP-Basis, dass dort die L0-Caches verbunden werden, oder dynamisiert man dann den L1-Cache auf Shader-Arrray-Ebene, sodass dann die 2 SA pro SE erst mal dynamisch ihren L1-Cache verbinden.
Man kann hier jetzt echt viel spekulieren und überlegen, was kommt und wie es kommt.
Kacha schrieb:
Zu Cache allgemein: Ich bin immer wieder ueberrascht wie sehr Caches unterschaetzt werden.
Ich denke, dass Problem ist, dass die möglichen »Fallstricke« wenn es denn mal wirklich zu einem vollständigen »Miss« kommt, sprich vom L1 - L3 (bei RDNA L0 - L3) für viele in der Regel sich sehr katastrophal anhören.
Nur das ist ein so katastrophaler Worstcase, dass in dem Fall nicht mal mehr die höchste Bandbreite hilft, um hier wirklich noch Geschwindigkeit zu retten und selbst die Latenz zum RAM kann hier nicht mehr soviel retten.
Dazu halt die Sache, dass man durchaus auch unterscheiden muss zwischen OoO-Designs mit spekulativer Ausführung bei CPUs und eben GPUs, die in der Regel ein IO-Design nutzen und wesentlich strikter arbeiten.
Im Endeffekt ist das durchaus ein interessantes und komplexes Thema und man muss je nach den Designs auch die Caches unterschiedlich designen und organisieren.
Kacha schrieb:
Ich denke auch wir werden mehr Cache sehen bei MCM oder Chiplet Designs. Das bietet sich zu sehr an.
Ich denke nicht nur, dass du recht hast in dem Fall, sondern sicher, dass du da recht hast. Sehe ich mir alle Entscheidungen von AMD bei den GPUs sowie eben auch bei den CPUs der letzten Jahre an, dann arbeitet AMD seit Vega auf ein MCM/Chiplet-System auch bei den Grafikkarten hin: Vega führte »HBCC« ein, auch wenn es bei RDNA und RDNA2 nicht als Feature dabei ist als ganzes, denke ich schon, dass man einige »Techniken« für den VRAM übernommen hat, vor allem jetzt mit dem Infiniti-Cache. Vega führte DSBR (Tiled-Based-Render) ein, sucht man sich da Informationen zusammen, scheint AMD hier in letzter Zeit auch darauf hingearbeitet zu haben, dass dieser feinere Tiles benutzt. Die Umstellung von Wave64 auf Wave32 beim Treiber, was die Datenmenge pro Befehl durchaus verringert.
Bei Zen arbeitet man beim Infinit Fabric darauf hin, dass auch hier die Latenzen möglichst geringer werden, man arbeitet an der Bandbreite usw.
Nehm ich mein theoretisches Wissen hinzu, was man ggf. an Daten puffern muss, wie man Daten/Tiles effizient verteilt usw. Mich würde es nicht wundern, wenn wir einen Main/Controller-DIE bei der GPU bekommen, der die Tiles dann an "GPU-Chiplets" verteilt und die GPU-Chiplets entsprechend den großen L2-Cache haben und der Main/Controller-DIE eigentlich nur ein riesiger Infintie-Cache-DIE wird, der die die Abfrage der GPU-Chiplets puffert.