Miután az AMD közzétette a nagy UALink javítócsomag-sorozatát Linuxra, az Intel mérnökei ma egy DRM Fabric nevű javaslatot jelentettek be.

A UALinkhez vagy az AMD xGMI-hez hasonló megoldásokat kiegészítve a DRM Fabric célja egy gyártófüggetlen, protokollfüggetlen DRM topológiai infrastruktúra kialakítása, amely skálázható összeköttetést biztosít GPU-k és AI gyorsítók között.

„Ez az RFC a DRM Fabricet javasolja: gyártófüggetlen, protokollfüggetlen DRM topológiai infrastruktúrát skálázható összeköttetésekhez, a következő modell alapján:

fabric -> endpoint -> port -> peer

A fabric egy szolgáltató által meghatározott interconnect-egy példányának végpontjait fogja össze. Az endpoint egy gyorsító csatolása, amely a fizikai portjait tartalmazza. A port jelenti a sávképességet, az aktuális állapotot és opcionálisan számlálókat. A peer egy típusos érték, amely a közvetlenül szomszédos gyorsítót vagy switch portot nevezi meg, nem pedig egy élő kernel objektumra mutató hivatkozás; azonosíthat olyan gyorsítót is, amelyet egy másik operációs rendszer kezel, vagy egy átlátszatlan switchet egy másik bizalmi tartományban.

A core csak a közvetlen szomszédosságot tartja nyilván, nem az end-to-end elérhetőséget vagy a switch forwardingot; ezek továbbra is a fabric vezérlőjének feladatai. A gyártói driverek megtartják a hardverfelismerést, a firmware-rel való együttműködést, a memóriaszemantikát és a hardver által hordozott adatút kezelését. A DRM Fabric a DRM által kezelt gyorsítók topológiáját és vezérlési állapotát írja le; nem hoz létre hálózati eszközt, és nem veszi át az útvonal-számítás, a switch forwarding, a transport vagy a torlódásvezérlés feladatait.

A Generic Netlink jobban illeszkedik ehhez a többobjektumos, eseményvezérelt modellhez, mint a sysfs, amely rosszul kezeli a teljes dump-alapú felsorolást és az aszinkron értesítéseket, viszont biztosítja a YAML-leírású uAPI fegyelmet, amelyet a DRM RAS vezetett be a DRM-be. A Devlink is szóba került, de az eszközöket és alárendelt objektumaikat modellezi, nem pedig egy, több DRM eszközt átfogó fabricet.

Az 1–6. javítócsomag egy teljes, külön tesztelt, csak olvasható mérföldkövet alkot, amelyet önállóan is be lehet olvasztani, miközben a provisioning még felülvizsgálat alatt áll. A szolgáltatók egy kis, a kernel-n belüli API-n keresztül teszik közzé az objektumokat, a szomszédossági információkat, az aktuális állapotot és az opcionális portstatisztikákat; a userspace a futó gráfot tudja lekérdezni, de nem módosíthatja.

A 7–12. javítócsomag privilégizált provisioninget ad a szoftveresen definiált fabricekhez. A userspace létrehozhat és törölhet üres fabriceket, hozzárendelheti a fabric nélküliként regisztrált árva endpointokat, kérheti az adminisztratív állapotot és kezelheti a peer szomszédosságot, miközben a szolgáltató végzi a hardverprogramozást. Az adminisztratív állapot a vezérlősík szándékát rögzíti, az aktuális állapot továbbra is a szolgáltató által jelentett érték marad, és minden portot vagy a szolgáltató, vagy a userspace kezel. A módosító műveletek: fabric-new, fabric-del, endpoint-set, port-set, port-peer-new és port-peer-del.”

A DRM Fabric célja, hogy gyártófüggetlen legyen, bár a mostani, első RFC-állapotban egyelőre csak Intel mérnökök dolgoztak rajta. A tesztelés és a 2026-ra tervezett DRM Fabric-fejlesztés iránti érdeklődésük feltehetően az érkező Crescent Island AI gyorsítókhoz kapcsolódik. Érdekesség, hogy az Intel mérnökei a nyilvános AMDGPU xGMI megvalósítást használták fel a DRM Fabric provider API-jának kialakításához.

A DRM Fabric jelenlegi formájában nem határoz meg semmit az adatátvitelről, a kapcsolási (switch) szabályokról, a live migrációról, az MMU programozásáról vagy más funkciókról. A kezdeti javítócsomagokhoz nem tartozik éles, gyártásra szánt provider megvalósítás sem.

Akik többet szeretnének megtudni erről a korai, scale-up interconnectekhez szánt DRM Fabric javaslatról, további részleteket találnak a dri-devel levelezőlistán.