Az új generációs grafikus API-k nem csak az aktuális hardverek jobb kihasználását segíthetik, hanem változtathatnak a processzortervezési filozófiákon is. Manapság a PC-ben az AMD és az Intel is nagyjából hasonló koncepciót követ, így alapvetően terveznek egy erős, illetve egy gyenge magot. Előbbit a magas órajelre élezik ki, míg utóbbinál főleg az alacsony fogyasztás dominál, és ezeket felhasználva fedhető le a teljes piac. A mobil szegmensben egyértelműen az energiahatékonyság dominál, így itt tulajdonképpen az úgymond kisebb magok uralkodnak, de ugyanakkor vannak olyan feladatok a munkaállomásokban, vagy a szerverek területén is, ahol erős magra van szükség, tehát ilyenkor úgymond a nagy mag a jobb választás.
A fentiek a jövőben sem fognak változni, de a két véglet között is vannak piacok, és itt már érdekes kérdés lehet, hogy a kicsi vagy a nagyobb maggal érdemes számolni. Többek között a DirectX 12 érkezése felboríthatja az eddig megszokott tervezési normákat, hiszen a Pollack szabály ma nagyon is él, azaz egy adott fogyasztási kereten belül több kisebb mag nagyobb összesített teljesítményre lesz képes, cserébe viszont csökken az egy magra levetített teljesítmény.
A Build konferencián egy érdekes kérdés merült fel a magok számát illetően. Régóta ismert tény, hogy a mai játékok esetében a több mag kihasználását az aktuális DirectX működése korlátozza, hiszen ugyanaz a kód a konzolokon gyakorlatilag lineárisan skálázódik, míg PC-n ezt nagyon nehéz elérni. A probléma eredete szoftveres alapokon nyugszik, és pont erre reflektál a DirectX 12. Logikus, hogy pár fejlesztő felveti, hogy a korlátokat kiütve jobban járna-e a PC-piac apró magokból felépített, 16 vagy akár 24 szálat kezelő processzorokkal.
A Microsoft szerint egyelőre erre még nincsenek teljes tanulmányok, de nincs okuk feltételezni azt, hogy a skálázódás ne lehetne lineáris. Többek között felmerült a StarSwarm nevű tesztprogram is, mely ugyan a DirectX 12-t még nem használja (legalábbis hivatalosan), de a hasonló működést megvalósító Mantle alatt 30 processzorszálig lineárisan skálázódik, és ez egy gyakorlati tesztre épülő mérés. Elméletben 32 szálig is skálázódhat, és utána sem kizárt a további extra sebesség, de a Nitrous motor alapján képző SWARM technológia jelenleg „csak” ennyi szálra van felkészítve. Jó hír viszont, hogy az új generációs grafikus API-k a rendszert egyetlen ponton sem kényszerítik soros feldolgozásra, azaz a leképzés tulajdonképpen akármennyi szálra párhuzamosítható, és ezek között nem szükséges szinkronizáció.
A grafikus alrendszer működése: az aktuális és az új API-k [+]
A fenti kép a régi és az új modell között nagyon jól reprezentálja a különbséget. A régi API-k esetében látható, hogy az alkalmazás hiába fut több szálon a leképzés akkor is egy szálra kényszeríti a munkamenetet egy bizonyos ponton, ami Amdahl törvényét figyelembe véve nem szerencsés. Az új API-k (DirectX 12 és Mantle) esetében viszont a Gustafson-Barsis-törvény él, azaz kellően nagy adathalmazok feldolgozása hatékonyan párhuzamosítható.
A fentiek értelmében nagyon is érdekes kérdés az Intel és az AMD számára is, hogy mégis merre menjenek tovább. Az új grafikus API-k terjedésével egyértelműen a sok, apró maggal rendelkező processzorok fogják gyorsabban futtatni a manapság amúgy is job (munka) rendszert alkalmazó videojáték-motorokat. Példaként említve 16-24 darab AMD Jaguar vagy Intel Silvermont mag, illetve ezek leszármazottai lényegesen gyorsabbak lesznek az új játékokban, mint a mai elvek szerint fejlesztett négy-, hatmagos processzorok.
A jövő egyértelműnek látszik, de problémát jelent úgymond a váltópont belövése. A sok apró mag ugyanis a DirectX 12 és Mantle API-t nem használó játékokban már lassabb lesz. Ez a szituáció nagyon kellemetlené teszi a hardverek fejlesztését, hiszen az irányt érezni lehet, a piac egyértelműen a párhuzamosítás felé menetel már az API-k szempontjából is, de azt az időpontot nehéz belőni, amikor lesz annyi elérhető program, hogy a felhasználók előnyként fogják fel a változást.
Érdekes adalék még, hogy felmerült egy olyan kérdés is, mely azt firtatja, hogy a rajzolási parancsokkal a processzormagoknak kell-e törődni, vagy esetlegesen más feldolgozó is megoldhatná ezeket. Egyelőre ez még nagyon megbeszélés tárgyát képzi, így a tényleges fejlesztések még nem kezdődtek meg, de az előzetes kutatások szerint gyorsítható a grafikus API az integrált grafikus processzor segítségével. Ez is megkeverheti majd a kártyákat, hiszen tovább bonyolítja a hardverek fejlesztését már a tervezési fázisban is. A gyártók manapság kezdik el tervezni a 2019 körül érkező rendszereket, de annyi lehetséges irány van, hogy nehéz egyértelműen ideális dizájnt kialakítani a jövőre nézve. Mindemellett bevehetjük a képletbe az ARM-os versenyzőket is, hiszen az efféle koncepcióváltás sok céget támadásra késztet, ráadásul a Microsoft sem ragaszkodik specifikusan egy utasításarchitektúrához, így támogatják az ARM térhódítását.
