Az IBM és az NVIDIA egy friss, több egyetem bevonásával készült tanulmányban bemutatott egy olyan koncepciót, ami javíthatja az adatintenzív feladatok különféle gyorsítókon történő végrehajtását. A Big accelerator Memory, rövidebben BaM célja egy olyan szoftveres háttér biztosítása, ami lehetővé teszi a gyorsítók számára, hogy közvetlenül az NVMe adattárolóból férjenek hozzá a tárolt adatokhoz, és ezeket úgy dolgozzák fel, hogy a host CPU segítségét semmilyen formában nem igénylik hozzá.

Maga a BaM nagyon leegyszerűsítve egy szerverekbe szánt szoftverkönyvtárnak tekinthető, ami azt biztosítja, hogy a GPU-n futó szálak közvetlenül az NVMe SSD-kről olvassanak be adatokat, illetve írják ki rá ezeket a feldolgozás után. Az adatmozgást ebben a rendszerben teljes egészében a GPU végzi a PCI Express interfészen keresztül, a GPUDirect RDMA segítségével. Ahhoz, hogy ez hatékonyan működjön a GPU saját fedélzeti memóriája részben egy szoftveresen menedzselt gyorsítótár lesz, és ha ebben a memóriaterületben megtalálhatók a szükséges adatok, akkor nyilván azok feldolgozása egyszerű lesz, ellenkező esetben viszont már bonyolódik a helyzet, mivel a szükséges információ valahol az NVMe adattárolókon van – ilyenkor a GPU fedélzeti memóriájának szabad része arra használható majd, hogy az adott SSD beírja a kért információt. Ahhoz, hogy ez megtörténjen, szükség van egy módosított Linux kernel-illesztőprogramra, ami menedzseli a GPU-n futó szálakat, és a kapcsolódó parancsok megfelelő sorrendben végrehajtásra kerülnek, amikor is a célzott SSD ellátja a feladatát.

A prototípus rendszer alapján úgy látják a fejlesztők, hogy az SSD-k felé irányuló hozzáférések kedvezően párhuzamosíthatók, illetve az I/O kapacitás is hatékonyabban használható ki. Ennél is fontosabb, hogy a szinkronizációs többletterhelés eltűnik a CPU és a GPU között, ami persze a működést figyelembe véve logikus, hiszen a BaM teljesen mellőzi a virtuális memóriacímek fordítását, így nem fordulhat elő olyan esemény, ami soros feldolgozást követel meg. Persze ennek a megoldásnak is megvannak a maga nehézségei, többek között a futtatott szoftverkönyvtárnak van némi többletterhelése, ami valószínűleg bőven vállalható határon belül van.

Felmerülhet az a kérdés, hogy mi történik akkor, ha a host CPU éppen hozzányúl a GPU által a BaM rendszeren keresztül párhuzamosan feldolgozott adatokhoz. Nos, valószínűleg semmi jó, mivel egymástól teljesen elkülönülő rendszeren történne a munkavégzés, viszont erre azért lehet figyelni a futtatott feladat tekintetében, így ezeket az eshetőségeket manuálisan el lehet kerülni.

A BaM fejlesztését végző érintettek a későbbiekben nyílt forráskódú formában elérhetővé teszik a hasonló rendszer megépítéséhez szükséges hardveres és szoftveres optimalizálásokat.