Az AMD egy időben a két GPU-t is tartalmazó csúcs-Radeonjairól volt híres. Ezt a vonalat még a Radeon HD 3870 X2-vel indították útjára, majd ezt sorrendben követte a Radeon HD 4870 X2, a Radeon HD 5970, a Radeon HD 6990, a Radeon HD 7990 és a Radeon R9 295X2. Ezt a kategóriát az AMD jellemzően nyerte az NVIDIA-val szemben, ugyanakkor a több GPU-s megoldások támogatása pár évvel korábban elkezdett visszaszorulni, ami miatt a következő csúcsmodellt a vállalat már professzionális szintre szánta. A Radeon Pro Duo tehát megjelent, de a játékosok számára nem feltétlenül volt ajánlható.
Nagyjából ez volt az a pont, amikor az AMD (meg az NVIDIA is) lemondott a játékosoknak szánt több GPU-ról, ugyanis túl komplexszé váltak a videojáték-motorok az AFR eljárás hatékony vezérléséhez. Emellett időközben megjelentek az explicit API-k is. Ezek már a fejlesztők kezébe adták a több GPU kezelését. Bár ennek a hatékonysága igazából nagyon kellemes, akkor is program oldali támogatást igényel, amire az AMD nehezen tud terméktámogatást kínálni. Ezt konkrétan úgy kell érteni, hogy ha az alkalmazás nincs felkészítve erre, akkor a meghajtó oldaláról nem lehet tenni semmit.
Innen a piac gyakorlatilag elkönyvelhette, hogy a több GPU-nak vége, ugyanakkor megtudtuk, hogy az AMD dolgozik egy megoldáson a fenti probléma kiküszöbölésére. Ezzel kapcsolatban minden részlet még nem teljesen tiszta, ugyanakkor nem titok, hogy az aktuális koncepciók problémája a különálló memóriaterület. Konkrétan mindkét GPU saját fedélzeti tárral rendelkezik, és ezek menedzseléséért az alkalmazott API-tól függően a grafikus meghajtó vagy a futtatott alkalmazás felel. A probléma igazából itt keletkezik, mert önmagában a grafikus feladatok feldolgozása rendkívül jól párhuzamosítható, nem csak kettő, hanem akár sokkal több GPU-ra is szétosztható lenne, de ehhez megfelelő leképezőt kell írni, amit nem sok fejlesztő tesz meg. A kérdés, hogy van-e olyan hardveres megoldás, amivel a fejlesztők úgymond kiüthetők a képletből.
A friss adatok szerint van. Nagyon leegyszerűsítve az AMD egy olyan elgondoláson dolgozik, amely kiveszi a fejlesztők kezéből a GPU-k különálló memóriájának menedzselését. A két GPU külön tokozásra kerül a megfelelő mennyiségű HBM memória társaságában, az összeköttetésükről pedig memóriakoherens interfész gondoskodna. Ilyenje ugye van az AMD-nek, hiszen a kétutas EPYC platformon belül a processzorok tokozásai is így vannak összekapcsolva. Gyakorlatilag ez a GPU-k esetében sem jelentene nagy különbséget, elvégre a vállalat már most az Infinity Fabric megoldásra épít az újabb grafikus vezérlőinél, innen már csak ki kell vezetni az interfészt pár IFIS segítségével (Infinity Fabric InterSocket). Utóbbi például már megtalálható a Vega 20 kódnevű GPU-ban.
A fenti megoldás azonban még nem elég, a fejlesztőknek itt még mindig gondoskodniuk kell a fedélzeti tárak menedzseléséről, ugyanakkor HBCC-vel ez is megkerülhető. Két GPU esetében gyakorlatilag a lapkák mellett található memóriák gyorsítótárként funkcionálnának. Mindig azok a 4 kB-os blokkok lennének bennük, amelyekre szükség van, és erről a hardver teljesen önállóan tudna dönteni. Az operációs rendszer felé így egyetlen nagy memóriaterület látszódna, annak ellenére is, hogy több GPU van összekötve. Igazából ez a módszer már most működik a Radeon RX Vega VGA-kon, csak azokon egy GPU van, ugyanis nincs egy megfelelő memóriakoherens interfész összekötni két lapkát.
Úgy tudjuk, hogy a megoldás hátránya, hogy csak Windows 10 mellett képes működni. A korábbi Windows operációs rendszerek nem elég fejlettek ahhoz, hogy a HBCC egyáltalán alkalmazható legyen. Ettől eltekintve az alapötlet egészen érdekes, hiszen így a rendszermemória egy területe lesz a CPU és a GPU-k között megosztott memória, amiből aztán a grafikus vezérlők tudnak gyorsítótárazni. Logikai szinten így beépíthető egy olyan mód a meghajtóba, amely gyakorlatilag egyetlen egy GPU-nak hazudja a két lapkát, és a program is így kezeli azokat, miközben a rendszer a háttérben a működéshez szükséges feladatokat az alkalmazások közvetlen támogatása nélkül is megoldja.
Ez egyébként tekinthető a chipletes elgondolás előfutárának, hiszen ilyen formában az is lehetséges, hogy két GPU ugyanarra a tokozásra kerüljön, csak ugye ezzel az a probléma, hogy a grafikus vezérlők jóval nagyobbak a CPU-knál, és a HBM memóriának is kell a hely, tehát egyelőre számolni kell a fizikai méretkorlátokkal. Erre leginkább a 3D-s tokozás jelentheti a megoldást. Mindenesetre a több GPU-s megoldások visszatérése érdekesség teheti a piacot, hiszen ezeknek a problémái a szoftverben keresendők, de ha ezt hardverben lehet kezelni, akkor érdekes alternatívák lehetnek.
