Az Electronic Arts újonnan létrehozott részlege, a DICE-ból kivált Frostbite Team a jövőben csak arra koncentrál, hogy a kiadó számára biztosítsa a Frostbite videojáték-motor fejlesztését a házon belül készülő játékok számára. Ennek köszönhetően a csapatnak jelentősen megnőtt a mozgástere, hiszen nem kell direkten egy játék megjelenésére koncentrálniuk, vagyis saját ütemben fejleszthetik a technológiát.
Az idei GDC-n kiderült, hogy az egyik legfontosabb kutatási terület a Frostbite körül a multi-GPU-s megoldások teljes reformja. Az AFR ugyanis a jövőben túlságosan is korlátozhatja majd a grafikai lehetőségeket. Még ha az adott API-n belül lehetőség is van teljes kontrollra, akkor is kerülni kell az egymás után következő képkockák közötti kommunikációt, és ezzel a szinkronizálási pontokat. Az AFR cseréjére többféle koncepció adódik, de a leghatékonyabb ötletnek az úgynevezett munkamegosztás tűnik, noha ennek kivitelezése a legnehezebb is. Ugyanakkor lényegében csak egyszer kell elérni, hogy működjön, és onnantól kezdve a multi-GPU-s rendszerek nem okoznak többet fejfájást.
A Frostbite Team koncepciója teljes egészében az új generációs API-khoz illeszkedik (Mantle, várhatóan a DirectX 12, illetve esetlegesen az OpenGL specifikus kiterjesztésekkel), az aktuálisan elterjedt szabványos API-kon viszont nem fog működni, mert a rendszer nem biztosítja a megfelelő kontrollt a hardverek vezérlése szempontjából.
A munkamegosztás ötlete lényegében a rendelkezésre álló erőforrások képességeinek feltérképezésére alapul, és ezután már a motornak rálátása van, hogy mit tud az adott konfiguráció, ami alapján kiválasztja a legerősebb GPU-t, mely innentől kezdve a vezér szerepét látja el. A gépben található termékek elméleti specifikációjából kiindulva célszerű erre kötni a kijelzőt, vagy kijelzőket is, de természetesen nem kötelező. A vezér GPU mellett számtalan szolga GPU fogható munkára, amelyek csak a leképzéshez szükséges adatok egy részét kapják meg, és a feladatuk, hogy ezt kiszámolják, majd az eredményt beírják a vezér GPU memóriájába. A feladatok elosztása teljesen kontrollálható, így számtalan módon vezérelhető, hogy melyik hardver mit számoljon. A végső képkockát a vezér GPU rakja össze, és küldi ki a megjelenítésért felelős rendszerre.
A fenti ötlet előnye, hogy lényegében nincs olyan leképzési technológia, amit ne tudna hatékonyan megoldani, hiszen a fejlesztő egy nagy logikai GPU-ra dolgozik, ami a valóságban persze több fizikai GPU, de összességében a konfiguráció, megfelelő feladatelosztás mellett úgy viselkedik, mintha egyetlen grafikus processzor dolgozna mindenen. Szintén előnyös, hogy nem kell két hasonló teljesítményű hardvert vásárolni. Lényegében a vezér GPU mellé akármelyen és akármennyi szolga GPU tehető és a teljesítmény folyamatosan skálázódni fog. Persze az alaplapok méretszabványai ettől nem változnak meg, de nyolc GPU-ra bőven van lehetőség. Ráadásul a teljes késleltetés nem lesz nagyobb, mintha fizikailag is egy GPU dolgozna a leképzésen. Ez az AFR egy másik nagy problémája, hiszen minél több GPU van összekötve annál nagyobb lesz a késleltetés, főleg akkor, ha a rendszer még ki is egyenlíti a képkockák megjelenítésének idejét.
Vélhetőleg a munkamegosztás koncepcióját több fejlesztő is mérlegeli, hiszen az új generációs API-kkal végre megkapják a hőn áhított kontrollt a hardverek felett, amit érdemes is használni. A működő rendszer kifejlesztése persze nem lesz egyszerű, de annyira sok előnyt kínál az aktuális modellhez képest, hogy nehéz figyelmen kívül hagyni ezt a lehetőséget. Főleg annak tudatában, hogy a jövőben rengeteg számítógépben lesz egy IGP a VGA mellett, amit ezzel a módszerrel munkára lehet fogni, amennyiben persze nem dolgozik valamilyen más feladaton, de ezt úgyis a fejlesztő dönti el.
