Az AMD még az előző év októberében jelentette be, hogy egy 35 milliárd dolláros akvizíció keretében gyakorlatilag egyesülnek a Xilinxszel, de akkor még nem volt sok információ a lehetséges hatásokról. Rövidebb távon nyilván futnak tovább a két cég projektjei, de hosszabb távon egy szoros integráció jön létre, aminek az első felvonása a szoftveres háttér összeolvasztása. Ez elkerülhetetlen ahhoz, hogy az üzletnek értelme legyen, így nem véletlen, hogy a két fél már dolgozik is rajta.
Mint ismeretes az AMD a saját hardvereire a HSA kiterjesztett implementációját használó ROCm szoftvercsomagot kínálja, míg a Xilinx a Vitis környezetre alapoz. Koncepció szintjén a kettő olyan sokban nem különbözik egymástól, a lényeg ezeknél a különböző hardverekre való fejlesztések megkönnyítése.
A ROCm alapja a ROCm futtatási környezet, ami célozható a HIP C++-ban írt kódokkal, és persze számos függvénykönyvtár is támogatott. Ezzel egységes kód írható magára a platformra, amit a CPU vagy a GPU is képes futtatni, esetlegesen akár egyszerre is. A Vitis elvi szinten hasonló, ott az alap egy XRT futtatási környezet, ami az XRT API-n keresztül érhető el, viszont lényeges tényező a megfelelő eszközszintű kód megírása, amit külön kell végezni. Utóbbi szükséges hozzá, hogy a futtatott program ne csak a CPU-kon, hanem az FPGA-kon is működjön.
A két cég annyiban változtat, és a Xilinx gyorsítók támogatása beolvad a ROCm szoftvercsomagba. Ez két részletben lesz kivitelezve. Első körben HIP C++ interoperáció kerül alkalmazásra, így a ROCm futtatási környezet kiegészül annyival, hogy tudja értelmezni a Xilinx eszközökhöz írt, HLS C vagy AIE C kódot. Ezzel a Vitis környezet többi része eltűnik, hiszen azokat tudja helyettesíteni a ROCm, sőt, többet kínál náluk.
Ezzel az új implementációval a Xilinx gyorsítók programozhatók lesznek a ROCm csomagon keresztül, de nem érhető el hozzájuk az egységes virtuális memória, illetve a különböző egyéb egységesítésre vonatkozó képességek, így a programfejlesztés oldalán mindenképpen szükség lesz HIP C++ kódra, ami futhat a CPU-n és a GPU-n, és egy alternatív HLS C vagy AIE C kódbázisra is a Xilinx hardvereihez. Ez a szoftvercsomag egyébként már javában készül, a nagyobb megrendelők akár tesztelhetik is.
A következő lépés lesz a teljes egységesítés. Ezzel eltűnik az eszközspecifikus kód szükségessége a Xilinx gyorsítók tekintetében, vagyis ezek is HIP C++ nyelven keresztül lesznek programozhatók, ahogy a CPU-k és a GPU-k. Ezzel párhuzamosan megjelenik az egységes virtuális memória támogatása, vagyis az összes komponens látja, illetve koherensen kezeli majd az elérhető memóriaterületeket, illetve mindegyik hardverelemhez ugyanazok a függvénykönyvtárak és keretrendszerek lesznek használhatók.
A mögöttes koncepció az, hogy a CPU-k, a GPU-k és az FPGA-k másféle helyzetekben erősek. A CPU-k leginkább a komplex feladatokban működnek jól, szemben a GPU-kkal, amelyek az adatpárhuzamos végrehajtás tekintetében acélosak. Az FPGA-k viszont finom szemcsézettségű adatfolyamok alacsony késleltetésű feldolgozásában kimagaslóan erősek, és erre sem a CPU-k, sem a GPU-n nem optimálisak. A ROCm iránya lényegében az, hogy egy közös nyelven, közösen támogatott függvénykönyvtárakkal és keretrendszerekkel, illetve egységes memóriakezeléssel mindegyik részegység a neki megfelelő feladatokat futtassa, és mindezt rendkívül egyszerű legyen leprogramozni, a manapság általánosnak tekinthető buktatók nélkül.
Arról még nincs információnk, hogy a teljes egységesítést biztosító ROCm mikor érkezik. Úgy tudjuk, hogy erre leghamarabb jövőre van esély, ugyanis az AMD egy nagyobb hardveres átalakítással készül a Genoa kódnevű szerverplatformhoz. A lényeg itt az, hogy a gyorsítók egyszerűen beköthetők lesznek Infinity Fabric kapcsolaton keresztül, ennek is a 3.0-s verziójával. Ezzel a CPU és a GPU már nem PCI Express, hanem egy jóval gyorsabb memóriakoherens interfészt használhat a kommunikációra, és ez nyilván könnyen kiterjeszthető az FPGA-kra, hiszen azokba is építhető Infinity Fabric link.
A probléma már látszik a fenti iránnyal kapcsolatban, mármint a piac nézőpontjából, hiszen magának a kommunikációnak memóriakoherensnek kell lennie, vagyis egy egyszerűen programozható, továbbá nagymértékben skálázható konfiguráció kialakításához muszáj AMD-től származó részegységet vásárolni. Ha tehát valaki Xilinx FPGA-kra épített a múltban, és nem szeretne váltani, akkor térhet át AMD CPU-kra és GPU-kra, de ez fordítva is igaz. Itt hosszabb távon megoldást jelenthetne egy szabványos memóriakoherens interfész, viszont jelenleg a Xilinx szállítja a piacnak a legpotensebb FPGA-kat, miközben az AMD biztosítja a legjobb szerverprocesszorokat. A két, éppen egyesülő cégnek rövidebb távon egyáltalán nem érdeke szabványos interfészekben gondolkodni, mert az Infinity Fabric kapcsolatra való kényszerítéssel egymás eladásit húzzák majd felfelé.
