A szerverprocesszorok piacáról – az elmúlt években – több olyan pletyka is érkezett, miszerint az AMD és az Intel is a HBM-mel próbálná kezelni a memória-sávszélesség problémáját. Gyakorlatilag mindkét cég azzal néz szembe, hogy a processzorok teljesítménye a több mag és a nagyobb órajel miatt csak nő, de ezt viszonylag lassan követi a rendszermemória sebességnövelése. Nyilván több memóriacsatornát mindig be lehet vetni, de ennek az iránynak is vannak hátrányai, illetve valami olyan megoldás kellene, ami a tokozásra vonatkozó költségeket nem emeli meg igen jelentősen.
Az egyik logikus iránynak az tűnt, hogy a processzor mellé, a tokozásra kerülhetne HBM szabványú memória. Nem mondható ez akkora újdonságnak, mert vannak már ilyen szerverprocesszorok az ARM-os vonalon, és maga a koncepció sem akkora innováció, hiszen pár korábbi fejlesztés hasonló módon alkalmazta a memóriát.
Logikus lépésnek tűnt tehát, hogy idővel az x86/AMD64-es szerverprocesszorokon is megjelenik a HBM, és tulajdonképpen az Intel tekintetében a pletykák nem lőttek mellé, mivel a Sapphire Rapids kódnevű fejlesztés HBM-es kiépítésben is érkezik.
Az AMD-s vonalon azonban egyelőre a 3D V-Cache tűnik befutónak, és a Milan-X platform ezt be is veti, de HBM-mel kapcsolatos pletyka a vörös oldalon is volt bőven. A gyártóktól megtudtuk, hogy nem is alaptalanul, mert jó ideig létezett HBM-es verzió a tervekben az új EPYC fejlesztésekre, ezek azonban nagyjából háromnegyed éve eltűntek. Információink szerint ennek a fő oka az volt, hogy az AMD kipróbálta a 3D V-Cache és a HBM dizájnt is, és utóbbit bizonytalan ideig elvetették.
Úgy tudjuk, hogy a HBM nem működött jól gyorsítótárként, egyrészt túl magas volt a késleltetése ahhoz viszonyítva, amire elméletben szükség lenne, másrészt pedig semmilyen olyan memórialeképezési mód nem volt ideális hozzá, ami a processzornak kedvezett.
A gondra két opcióval próbált reagálni az AMD. Az elméleti teljesítmény tekintetében gyorsabbik megoldás a nagyon nagy, lényegében HBM-hez illeszkedő gyorsítótársor alkalmazása, de ennek az volt a hátránya, hogy ha a program nem volt direkten erre optimalizálva, akkor rengeteg memóriát pazaroltak vele. Mivel az AMD kritikusnak tekintette, hogy a meglévő alkalmazásokat ne kelljen átírni az új dizájnhoz, így egy másik irányt is kipróbáltak, amiben úgynevezett közvetlen leképzésű gyorsítótárként működött a HBM, és ehhez – a processzor optimális működése érdekében – 64 bájtos gyorsítótársort alkalmaztak. Az efféle memórialeképezés egyik sajátossága az alacsony találati arány, de a HBM előnye, hogy nagy kapacitást kínál, amivel ezt a problémát valamennyire kezelni lehet. Valószínű ugyanakkor, hogy ez a működési mód sem hozta a 3D V-Cache mutatóit.
Azt sajnos nem tudni, hogy mikor lehet HBM-es EPYC, egyelőre – a potenciális buktatók miatt – parkolópályára tette ezt az irányt az AMD. Nagy kérdés még, hogy az Intel miképpen oldja meg a HBM implementálását, ez ugye működhet a Sapphire Rapids processzoron gyorsítótárként, de a szaftos részletekbe nem ment bele a Santa Clara-i óriáscég, és nyilván nem csak az a két működési mód van, amit fentebb leírtunk.
