Az AMD még a 2020-as esztendő októberében jelentette be, hogy felvásárolják a Xilinxet. Az akvizíciót azonban nem sikerült lezárni az előző év végére, de mostanra a Kínai Népköztársaság versenyhatóságának számító State Administration for Market Regulation (SAMR) engedélye is megérkezett. Ezzel minden akadály elhárult az akvizíció elől, amire az érintetek a következő héten pontot tesznek.
Az eredeti megállapodás nem változott meg, így a Xilinx részvényesei fix, 1,7234-es aránnyal jutnak AMD részvényekhez. Az aktuális részvényárfolyammal kalkulálva az akvizíció értéke végül elérheti az 50 milliárd dollárt is.
A legfőbb kérdés valószínűleg az, hogy mi fog változni. A jelenlegi állás szerint rövidebb távon semmi. Minden AMD és Xilinx termék elérhető marad, bár a cég neve AMD lesz, így a Xilinx amolyan márkajelzéssé válhat. A készülő Xilinx hardverek sem lesznek majd törölve, ami a szerverpiacon azért fontos, mert sok nagyobb megrendelő eleve egy útiterv alapján választ magának beszállítót, és ezeket a rendeléseket célszerű kiszolgálni.
Az első nagyobb változás az összeolvadás után szoftveres szempontból várható. 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, és a két cég már a felvásárlás bejelentésekor elkezdett közösen dolgozni a fejlesztőeszközök tekintetében.
A ROCm és Vitis környezetek [+]
Ha a jelenleg elérhető környezeteket vesszük figyelembe, akkor az AMD-féle 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 nagyon 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 ROCm XRT interoperációval [+]
A felvásárlással záros határidőn belül megszűnik a két különálló rendszer, és a Xilinx gyorsítók támogatása beolvad a ROCm szoftvercsomagba. Információink szerint ez a fejlesztés akkor is végbement volna, ha végül az akvizíció nem történik meg. A mögöttes koncepció a HIP C++ interoperáció alkalmazása, így a ROCm futtatási környezet képes lesz é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. Ezt a szoftvercsomag már hónapok óta tesztelhetik a szóban forgó cégek partnerei, és várhatóan az idei évben ténylegesen elérhető is lesz.
A Xilinx az egésszel nem kockáztatott nagyot, mert ha nem is jött volna létre az üzlet, akkor is hasznos, ha az FPGA-ik közvetlenül kezelhetők annak a cégnek a szoftverkörnyezetével, amely nagy teljesítményű CPU-kat és GPU-kat kínál a szerverpiac számára. Ezzel szimplán növelte volna a cég annak az esélyét, hogy az AMD EPYC, illetve Instinct rendelések mellé a vásárló Xilinx gyorsítót kér a konkurens megoldások helyett. Nyilván az akvizíció elmaradása esetén a Vitis környezetet erőteljesen fejlesztették volna tovább.
A felvásárlás ugyanakkor megtörtént, így a szoftveres szintű összeolvadás a következő szakaszba lép, és eltűnik majd az eszközspecifikus, HLS C vagy AIE C 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.
[+]
Ez az a lépcső, amiért kellett a felvásárlás. A mögöttes koncepció annyi, hogy a CPU-k, a GPU-k és az FPGA-k másféle helyzetekben erősek, és ezeket az előnyöket a ROCm úgy tenné elérhetővé, 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, továbbá mindezt rendkívül egyszerű legyen leprogramozni, a manapság általánosnak tekinthető buktatók nélkül.
A szoftveroldali jelentős integráció előrevetíti a hardveres változásokat is. A ROCm 5.0-s verziója az Infinity Fabric 3.0-val összekötött EPYC és Instinct párosításra van írva, amelyet a Trento platform biztosít, ez a kombináció akár trióvá bővíthető a Xilinx akármelyik gyorsítójával, csak bele kell tervezni az Infinity Fabric linket, és meg is van oldva az egységes memóriakezelés. Hosszabb távon tehát jelentős változások várhatók a termékskálát tekintve is, a Xilinx megoldások erőteljesen az AMD rendszereire lesznek tervezve a működés szempontjából, ahogy az például látható az új Instinct gyorsítónál, de ettől még a szabványos interfészek támogatása megmarad, csak azon nem érhető el összes képesség.
