Wäre mal interessant sowas als normalen RAM zu haben. Da könnte man viel kleinere Module haben und Platz auf dem Mainboard einsparen
Kommt indirket mit Sapphire Rapids und seinen Ablegern, denn dessen HBM2E-Varianten sollen in einem speziellen Betriebsmodus auch komplett ohne DIMMs betrieben werden können, d. h. man kann hier mit rein dem On-Package-HBM mit seinen X-Hundert GiB/s an Bandbreite arbeiten. Was das aber für konkrete Workloads bringt und ob sich so etwas für einen HEDT-Ableger lohnt, bleibt abzuwarten. Ich würde vermuten insbesondere AVX-lastige Workloads mit hohem Datendurchsatz wie bspw. ML-Workloads werden hier besonders von profitieren. Den Consumer- oder selbst den HEDT-Markt könnte vermutlich schon der Preis "killen". (
Beispielsweise als HEDT wäre eine CPU, bestehend aus nur zwei SRP-Tiles mit 32 GiB HBM2E denkbar ...)
Also der "Normalo" dürfte nur Bahnhof verstehen! [...]
Ignorier das alles und beschränke dich einfach auf die hohe dreistellige Bandbreite pro einzelnem HBM-Chip und behalte im Hinterkopf, dass ein einzelnes DDR4/5-Modul gerade mal um die 25 - 35 GiB/s hinbekommt. Das sind schon immense Unterschiede, wobei die Latenz aber eine andere Frage ist, wobei etwaige Nachteile bein Random-Zugriff jedoch teilweise wieder durch die extrem höhere Bandbreite wettgemacht werden dürften.
Zur Konkretisierung: Ein HBM-BGA-Baustein kann nach aktueller Spec aus bis zu 12 Lagen (stacked chips, verbunden mit TSV's) bestehen und damit bis zu 24 GiB Gesamtspeicherkapazität realisieren.
Die Angabe Gigabits pro Pin pro Sekunde bezieht sich auf die Basis 2 (nicht 10). Ein Chip verfügt zudem über 1024 Pins (ein 1024-Bit-Interface) und entsprechend erreicht ein einzelner 3,2 Gbps-HBM2E-Chip hier rd. 410 GiB/s. (
Also so viel wie eine aktuelle Mittelklasse-GPU mit ihren acht GDDR6-BGAs (256 Bit-SI); bspw. Epyc oder der Threadripper Pro erreichen mit ihren 8 Speicherkanälen gerade mal die Hälfte der Bandbreite eines solchen einzelnen Chips.)
Rambus stellte bereits Mitte August seine HBM3-IP (PHY + Controller) vor, die bis zu 8,4 Gbps an Bandbreite realisieren können soll.
Abschl. Anmerkung zum Namen: Das aktuelle "E" in HBM2E gibt es gemäß Spezifikation gar nicht. Hierbei handelt es sich lediglich um einen Marketingbegriff, der erstmals von Samsung eingesetzt wurde. Konkret sind dies schlicht schnellere BGAs gemäß der offiziellen HBM2-Spezifikation und der nächste Schritt in der Standardisierung ist HBM3.
Weil es gerade passt: Der schnelle GDDR6-Speicher von Micron, den Ampere nutzt, ist ebenso wenig GDDR6X *) sondern schlicht eine proprietäre Eigenentwicklung mit PAM4-Signalisierung, die einen deutlich höheren Pro-Pin-Takt verkraftet. **) Ob die JEDEC das jemals als Standard übernehmen wird, ist unklar. Vereinfachend spricht die Presse jedoch bei Ampere zur Abgrenzung immer von "GDDR6X".
*) Aktuell gibt es von der JEDEC keine GDDR6X-Spezifikation, so wie es bspw. von denen GDDR5X gibt.
**) Hier in konkreten Produkten aktuell bis zu 19,5 Gbps bei 32 (Daten-)Pins pro Micron-OC-GDDR6-BGA. Mainstream-GDDR6 gemäß JEDEC-Spec begnügt sich derzeit mit 14 Gbps, im HighEnd gibt es auch mal 16 Gbps, 18 Gbps stellen bisher das reguläre Limit, werden aktuell aber von keinem GPU-Hersteller in einem Produkt genutzt. (Zur Vereinfachung pro BGA: 14 Gbps ~ 56 GiB/s, 16 Gbps ~ 64 GiB/s, 19 Gbps ~ 76 GiB/s. )
Wird vermutlich nicht sinnvoll funktionieren. Im Artikel sind zwar jetzt keine Taktraten angegeben aber ich denke mal an der Grundlage von HBM wird jetzt nicht so viel anders sein.
Sprich niedrige Taktrate im Vergleich zu DDR-RAM dafür aber vielfach Breiter (mehr Übertragungen gleichzeitig).
Für RAM der an CPUs angeschlossen wird benötigt man aber in den meisten Fällen eine möglichst niedrige Latenz und die ergibt sich aus hohem Takt und scharfen Timings.
Wie oben schon erklärt funktioniert das sehrwohl, da Intel das schon mit Sapphire Rapids SP realisiert hat und auch dem allgemeinen Vernehmen nach AMD mit Genoa angeblich nachziehen soll.
Bei Intel's SPR hat ein CPU-Tile einen HBM2E-Controller um einen HBM2E-BGA anzubinden. Die CPU besteht typischerweise aus vier Tiles und die HBM2E-Modelle können entsprechend 4 BGAs ansteuern, wobei man hier von nur 64 GiB (8 Stacks) und nicht etwa 96 GiB (12 Stacks) Gesamtkapazität ausgeht. Anzunehmenderweise wird man hier den Speicher jedoch mit einer vergleichsweise niedrigen Taktung fahren, also obwohl es HBM2E ist, werden die BGAs möglicherweise mit etwas wie 1,6 - 2,4 Gbps betrieben werden, weil mehr einfach Overkill wäre und dennoch aufs thermische Budget der CPU schlagen würde. Mit 2,4 Gbps würde die CPU eine HBM-Bandbreite von um die 1228 GiB/s oder 1,20 TiB/s aufweisen, was ungefähr derzeit dem vier- bis fünffachen einer typischen Serverspeicherbandbreite entspricht. Intel sieht in dem Design unterschiedliche Betriebsmodi vor. Einerseits kann der HBM2E als transparenter L4$ fungieren, andererseits kann er aber auch als separater Speicherpool direkt angesprochen werden. Eine Server-App könnte somit normal über das DRAM laufen und kritische Bereiche gezielt über den bis zu 64 GiB großen HBM-Speicherpool laufen lassen. Daneben konnte man auch lesen, dass die CPUs gar auch ohne DRAM/DIMMs betrieben können werden sollen, d. h. hier fungiert das HBM2E dann zwangsweise als Hauptspeicher. Ich würde aber vermuten, dass nur wenige Server derart spezifisch ausgerichtet sein werden, sodass man denen DRAM vorenthält (
vielleicht fürs Number Crunshing?, bei bspw. ML benötigt man schon wieder viel Speicher für große Netzte und hier würde man den HBM2E als L4$ nutzen um die mittlere Speicherbandbreite insgesamt deutlich anzuheben).
Auf der anderen Seite beflügelten diese Eckdaten Überlegungen zu einem HEDT-Ableger mit nur bspw. 2 CPU-Tiles, 32 GiB HBM2E und bspw. einer Speicherbandbreite von 600 GiB/s, also gut dem 10-fachen, was aktuell die allerschnellsten Consumer-Plattformen mit DDR5 zustande bringen.
Am Ende aber vermutlich nur Fantasterein. Ein optimierter und größerer Cache wird hier vermutliche das beste P/L-Verhälsnis für Consumer & Enthusiasten bieten, so wie AMDs V-Cache oder die von Intel zu Raptor Lake bereits kolportierten "
Cache-Optimierungen", die in eine ähnliche Kerbe schlagen werden (
aktuell nur noch nicht im Detail konkretisiert wurden).
