Egyre több játékfejlesztő veszi figyelembe a 4K-s kijelzők érkezését, amit egyébként a piac is bőszen reklámoz, tehát a terjedése mögött komoly gazdasági érdekek is állnak. Azt nehéz megjósolni, hogy ennek lesz-e eredménye, de a játékfejlesztők biztosan örülnek az újításnak, ugyanakkor eléggé világos mindenki számára, hogy a modern videojáték-motorokban a 4K-s felbontás olyan mértékű terhelés, amelyet egyetlen grafikus vezérlővel nem igazán lehet kiszolgálni. Elvben nincs gond, hiszen erre valók a több GPU-s konfigurációk, ráadásul a 4K-s kijelzők árait látva az újdonság iránt érdeklődő játékosok valószínűleg a VGA-kat is képesek majd megfizetni.
A 4K közeledtével a PC-ben érdekelt stúdiók is több kutatást szentelnek a több GPU-s konfigurációk hatékonyabb kihasználására, de ennek ma vannak igen komoly akadályai is, amelyeket meg kell oldani. Az érintettek két nagy gondot jeleztek a gyártóknak és a grafikus API-k fejlesztőinek. Ebből kitalálható, hogy az egyik leginkább hardveres, míg a másik szoftveres probléma, de ahhoz, hogy jobban támogathassák a 4K-hoz amúgy is szükséges több GPU-s feldolgozást, mindkettőt meg kell oldani.
Az elmúlt hónapokban elvégzett tesztek során kiderült, hogy a 4K-s felbontás a modern leképzőkkel olyan mértékű kommunikációs terhelést jelent az AFR elven működő SLI és CrossFire konfigurációk számára, amelyet az ezekhez alkalmazott dedikált hidak egyszerűen nem viselnek el. Ez nem újdonság, hiszen korábban az AMD és az NVIDIA is felvetette ezt a potenciális problémát. Alapjaiban arról van szó, hogy a CrossFire és az SLI konfigurációkhoz használt adatkapcsolatok nagyjából egy évtizede nem fejlődtek, miközben a szoftverek általi terhelés folyamatosan nőtt. Most jutottunk el egyértelműen arra a pontra, hogy az alkalmazott hidak adatátviteli teljesítménye egyszerűen kevés. Ezt a limitációt az AMD és az NVIDIA is úgy korrigálja, hogy 4K-s felbontás mellett már nem a dedikált hidakat, hanem a PCI Express összeköttetést használják. Ehhez azonban meg kell várni a játék elkészültét, és az adott videojáték-motort kielemezve kell a grafikus meghajtóba írni egy specifikus AFR rutint.
Ennek a megoldásnak a hátránya, hogy rengetek kommunikációra van szükség a gyártók és a fejlesztők között, ugyanis általános AFR módban a Radeon R9 290-es termékcsalád az egyetlen megoldás, amelyre valamilyen mértékben lehet fejleszteni 4K-s felbontáshoz igazított több GPU-s támogatást. Ez annak köszönhető, hogy a CrossFire XDMA blokk eleve a PCI Express összeköttetést használja az AFR működéséhez, ugyanakkor a fejlesztők számára gondot jelent, hogy ha ehhez hozzáigazítják a videojáték-motor működését, akkor sem garantálja semmi, hogy a többi hardveren hibátlan lesz az eredmény, amint az AMD és az NVIDIA megírta a specifikus AFR rutinokat a régebbi elven működő CrossFire és SLI konfigurációkhoz. Szintén gondot okoznak az adott játékhoz készülő javítások, amelyek kiadása után esetlegesen újra kell paraméterezni a meghajtókba épített specifikus AFR rutinokat.
Általánosan megfogalmazva elmondható, hogy a rengeteg hardver és szoftverkörnyezet mellett sem a gyártó, sem pedig a játék fejlesztője nem tud garanciát vállalni arra, hogy 4K-s felbontásban működni fog-e a CrossFire, illetve az SLI. Ez borzasztóan káros a piacra nézve, hiszen a 4K-s korszakra vonatkozóan a felhasználó a kellemes és nem a kellemetlen élményekért fizet.
CrossFire és SLI. Lejárt a hidak ideje.
A fejlesztők szerint elsődlegesen meg kell szabadulni a régi, gyenge teljesítményű hidaktól, és a PCI Express felület temérdek kihasználatlan sávszélességét kell befogni. Ehhez még egy olyan hardveres blokk is kell a lapkákba, amely az egész folyamatot képes általános AFR rutinokon keresztül vezérelni. A szoftverre vonatkozó igény azonban bonyolultabb. Jelenleg egyetlen szabványos grafikus API, vagy szabványosan elfogadott kiterjesztés sem kínál kontrollt a több GPU-s konfigurációk működtetésére. Az egész egy grafikus meghajtón belül működő kikényszerített üzemmód, aminek a használata nem befolyásolható, így a skálázódás biztosításához kell igazítani a videojáték-motor leképzőjét. A problémát az jelenti, hogy a fejlesztők irányt akarnak mutatni, nem pedig egy megadott irányba haladni, azaz nem akarnak semmilyen korlátozásokat eredményező, elavult módon működő rendszerhez igazodni, hanem azt szeretnék, ha maguk irányíthatnák a több GPU-s konfigurációkat.
Ennek az előnye a felhasználói élményben azonnal tetten érhető lenne, hiszen ami eddig a grafikus meghajtóban volt az átkerülne a programba, azaz minden fejlesztő a saját alkalmazott technológiájához igazíthatná a több GPU-s konfigurációk működését a lehető legjobb sebesség és kompatibilitás érdekében. Ez persze nem jelentené azt, hogy minden játék megjelenésekor azonnal befogható lenne több GPU egy PC-n belül, ahogy az látszik a Mantle API-t használó játékoknál is. Ugyanakkor olyan biztos nem lenne, hogy egy játékhoz még hónapok múlva se érkezzen több GPU-s támogatás.
A 4K-s átállást egyébként segíteni szeretnék az érintettek. Ez egyszerűen mindenki számára fontos. Senkinek sem teszik kötelezővé, de ez egy olyan üzleti szempont, amit érdemes kihasználni. Az AMD gyakorlatilag a CrossFire XDMA blokkal, illetve a Mantle API-val megoldotta azt, amit a fejlesztők kérnek. Ugyanakkor ez a piac egészére nézve már nem megoldás, hiszen kell a többi hardvernél is a gyorsabb összeköttetés, illetve a Microsoft számára világossá kell tenni, hogy a DirectX 12 API-t érdemes kiegészíteni olyan funkciókkal, amelyek lehetővé teszik a fejlesztők számára a több GPU-s rendszerek programból való kontrollálását. Utóbbit úgy tudjuk, hogy a Microsoft eredetileg nem tervezte, de az igényt látva tesznek majd azért, hogy ezt a gondot is felszámolják. Ne feledjük, hogy a redmondi óriáscég számára ugyan fontosak a játékosok, de arányaiban túl kevesen vannak a 4K-s kijelzőket használó, több GPU-s PC-vel rendelkező felhasználók ahhoz, hogy az igényeik magas prioritást élvezzenek egy grafikus API fejlesztése során.