Leteszteltük a DirectX 12-t és újításait!

A DirectX 12 és az Ashes of the Singularity

Az Ashes of the Singularity egy valós idejű stratégiai (RTS) játék, mely jelen pillanatban még csak béta formájában érhető el, és március 31-én jelenik meg. Egyike az első olyan címeknek, amelyik független fejlesztőstúdió munkája, és az explicit API-k közül képes a Microsoft DirectX 12-t kihasználni. Ezért ezt a játékot fogtuk be, hogy megvizsgáljuk a gyakorlatban is az új DirectX által ígért előrelépést. Beérik végre a Windows 10 ilyen irányú tudása is, hiszen jelenleg az egyetlen operációs rendszer, ahol a DirectX 12-t használhatjuk. A technikai fejlődés oda vezetett, hogy időszerű volt a DirectX 11 leváltása, ami sokkal finomabban, fokozatosabban megy végbe, mint az eddigi ilyen cserék.

Tesztünk több szempontból is rendhagyó. Soha nem volt még lehetőség például konkurens gyártók videokártyáit együtt dolgoztatni, és sosem kínált még egyetlen API ekkora teljesítménynövekedést. GeForce-ot és Radeont párosítottunk tehát, és ezt úgy is lemértük, amire még külföldi oldalakon sem nagyon akadt példa. Korábban egy alkalommal volt hasonló mérésünk a Mantle API és a DirectX 11 kapcsán, de akkor a kisebb teljesítménynövekedésen kívül mást nem kaptunk. Végül pedig ezúttal egy átfogóbb elemzést is be kellett iktatnunk, hogy a jelentős újításokat ismertethessük.

A DirectX 12

A Microsoft DirectX 12 egy alacsonyszintű hardveres elérésű, úgynevezett explicit grafikus API, mely az előd DirectX 11-hez képest gyökeres változtatásokon ment keresztül. Sokkal közelebbi rokonságot mutat a Mantle és a Vulkan API-val, valamint a konzolok közvetlen hozzáférésű programozási módjával. A kulcsfontosságú kérdés az, hogyan hasznosítjuk az egyre több és több magot kínáló processzorokat? Az idők folyamán a CPU-k és a GPU-k újításai mögött lemaradt a grafikus API-k fejlődése, és egyre inkább problémát okozott a nagymértékű párhuzamosítás optimális kihasználása, amit az alábbi kép kiválóan szemléltet.

Hiába a sok párhuzamos erőforrás, ha nem használjuk ki [+]

Ugyan már az elődnek számító DirectX 11 is lehetővé tett némi többszálú feldolgozást, de a parancslistákat nehéz jól kezelni. A probléma ott kezdődik, hogy nem lehet meghatározni, hogy ezek mikor lesznek elküldve a grafikus vezérlőnek. A működés biztosításához azonban szükséges a megfelelő GPU-címek folyamatos beírása annak érdekében, hogy a parancsok betölthetők legyenek. A DirectX 11 alatt a vezérlést mindenképpen csak egy mag végzi, és ez vagy azonnali kontextust küld a grafikus vezérlőnek, vagy a késleltetett kontextusokhoz tölti fel a GPU-címeket. Emiatt a többszálú parancslisták alkalmazása egyszerre előny és hátrány.

Feltöltött GPU-címek mellett a munka jól skálázható, de amint új parancslisták jönnek, és új GPU-címek kellenek hozzájuk, rögtön jön a hátrány, vagyis a munkavégzés ideiglenes leállása a címek feltöltéséig. Emiatt az első pár percben a parancslisták többszálú kezelése előnyt biztosít, majd a GPU-címek feltöltésének szakaszában a feldolgozás lelassul, és gyakorlatilag ez a körforgás folytatódik a program futtatása alatt. Fentebb linkelt tudástár bejegyzésünk is kitér arra, hogy az NVIDIA ezt alkalmazza, míg az AMD nem engedélyezi. A DirectX 11-es teszteredményeket ennek fényében kell majd értelmezni, a 3 perc hosszú benchmark miatt a fentiek a zöld VGA-k számára kedvezőbbek.

Hirdetés

Végezetül pedig nagyon fontos a vörösek és a zöldek most tesztelt hardverei közt fennálló különbségek közül kiemelni az eltérő bekötési modellt. A HBM-es Radeon, az R9 Fury a TIER_3-as, míg a GTX 980 Ti csak a TIER_2-es bekötési modellt tudja kezelni, ez utóbbi valamivel több CPU-időt emészt fel az UAV/SRV/CBV kreálás során, így a Radeon előnyhöz juthat. A DirectX 12 specifikációinak véglegesítéséről is született írásunk, ahol mindez alaposabban körüljárásra került.

Miért különleges a Nitrous?

A teszt előtt érdemes beiktatni egy apróbb, mondhatni rendhagyó elemzést, ugyanis az Ashes of the Singularity című játék egy tényező miatt rendkívül különlegesnek tekinthető. Ez nem más, mint a Nitrous videojáték-motor, amelyről nagyon sokat lehetett hallani az elmúlt években, és természetesen a felé irányuló figyelem nem véletlen.

Az Oxide Games új stúdióként alakult meg 2013-ban, akiket nagyrészt a Stardock pénzel, illetve olyan iparági nagyágyúk alapították, mint Dan Baker, Tim Kipp, Marc Meyer, Brian Wade és Brad Wardell. Az úriemberek neve egyenként is elképesztően erős, aligha van náluk jobb szakember az iparágban az adott területeken belül, így igen nagy szó, hogy összefogtak egy közös cél érdekében, ami a stratégiai játékok reformja volt.

Nem túl ismert tény, hogy manapság jó minőségű, valós idejű stratégiai játékot a legnehezebb fejleszteni, nincs is túl nagy tolongás e téren. A gondokra jó példa a Starcraft 2, amely különböző technológiai problémák miatt egységlimittel rendelkezik, ami azt jelenti, hogy egy adott pályán egy bizonyos számú egységnél több nem építhető. Szerencsére ez a szám elég nagy, hogy csak ritkán okozzon problémát. Ennél sűrűbben bele lehet futni a 255 darabos kijelölési limitbe, amely szintén egy technikai gond, nem beszélve arról a jelenségről, amikor nagyszámú egység esik egymásnak, amitől teljesen lelassulhat az adott PC.

Gyógyír a gondokra

Az Oxide Games pont azért kezdett a nulláról, hogy a mára általánossá vált limiteket ki lehessen ütni egy jobban felépített alappal. A Nitrous videojáték-motor egyik különlegessége a SWARM rendszer, amely a Simultaneous Work And Rendering Model rövidítése. Ez egy olyan feladatalapú, alapjaiban a nagy és komplex szimulációkhoz tervezett alkalmazásmodell, amelyet évek tapasztalata alapján épített fel Dan Baker és Tim Kipp. A SWARM teszi lehetővé, hogy a Nitrous extrém mértékben skálázódjon a többmagos processzorokon. A határokat még nem lehet tudni, de a jelenlegi tesztek alapján a közel lineáris skálázódás 16 magig nem akadály, persze csak akkor, ha van mögötte elég gyors grafikus hardver.

Az extrém skálázódás azonban amellett, hogy jó, rengeteg problémát felvet. Például azt, hogy mennyi a valóban szabad, program számára ténylegesen hozzáférhető processzoridő. Utóbbit ugyanis nem csak a futó és egyben megterhelő alkalmazás, hanem az operációs rendszer és más komponensek is használják. A Nitrous esetében például rendkívüli limitációkat jelentettek anno a grafikus kernel meghajtók szerver szálai, ugyanis elvették a processzoridő egy jelentős részét, valamint sokszor soros munkavégzésre kényszerítették a rendszert, amitől hozzáférhetetlenné vált a hardverben létező erőforrások nagy része.

A DirectX 11 sok processzoridőt hagyott kihasználatlanul [+]

A fenti képen látható, hogy a DirectX 11 mellett gyakorlatilag csak a processzoridő egy kis részét használta a Nitrous kezdeti kódja, és a maradék rész egyszerűen hozzáférhetetlen. Dan Baker, a Nitrous vezető programozója korábban erről azt mondta, hogy a grafikus driverek működési modellje a rossz, mert kiszámíthatatlanul cselekednek, így képtelenség hatékony többszálú optimalizálást bevezetni. Ezért a Nitrous már a kezdetektől fogva az explicit API-kra készült. Az elején az AMD Mantle-re, míg ma már a DirectX 12 és a Vulkan API-ra is.

A végeredményben mindegy, hogy milyen explicit API-n fut a program, a skálázhatóságot a grafikus kernel meghajtó megszűnése biztosítja, így kikerül a képből az a kiszámíthatatlan tényező, amely megakadályozta a hatékony többszálú optimalizálást.

Ha már lépünk, lépjünk nagyot

Már az előző oldal alapján látható, hogy A Nitrous működése a mai videojáték-motorokhoz képest igencsak eltérőnek tekinthető, ugyanakkor az olló még jobban kinyílik, ha számításba vesszük a leképezőt is. Utóbbira ma két vezető irány létezik: forward és deferred. Ezeknek persze vannak különböző variánsai, amelyeket a változó igények formáltak; az előbbi linken az általánosan elterjedt alternatívákról részletesebb beszámoló is olvasható. A nagy kérdés mindig is az volt, hogy van-e más lehetőség, és erre a válasz jellemzően igen lesz, ugyanakkor az iparágon belül a főbb fejlesztéseket végző stúdiók akkora pénzt raktak az aktuális technológiáikba, hogy nem szívesen döntenek úgy, hogy a nulláról újrakezdik. Még ha ez át is fut a vezető szakemberek fején, a megfelelő anyagi támogatást már nem kapják meg rá. Utóbbi elsődleges oka, hogy a kiadók többsége egy komplett újraírást rendkívül kockázatosnak találna, így inkább apróbb lépéseket finanszíroznak.

A Nitrous azonban eleve a nulláról készült, tehát logikusnak tűnt olyan területekbe invesztálni, amire már számtalan tanulmány épült az elmúlt évekből, de nagyobb támogatás hiányában a tényleges megvalósításig nem jutottak el. A Nitrous egy úgynevezett objektumtér-alapú leképezőt használ, amely alapjaiban különbözik attól, amit eddig láthattunk a játékokban. A fő cél az, hogy az árnyalási számítások ne az objektumtér magasabb szintjén, ezen belül is a fragmenteken történjenek meg, hanem magában az objektumtérben. Ennek számos előnye van, kiemelve azt, hogy olyan technikák is megvalósíthatóvá vállnak, amelyeket eddig csak előreszámolt számítógépes animációkban lehetett látni. Többek között a Nitrous szempontjából a láthatósági teszt előtti árnyalás volt fontos, ugyanis ilyen formában az árnyalás eredménye akárhányszor újrahasznosítható.

Komplex árnyalási számítások segítségével... [+]

A Nitrous objektumtér-alapú leképezője egyébként leginkább a Pixar RenderMan motorjának Reyes implementációjához hasonlítható, de a Nitrous valós időben számol, így különböző módosításokra és trükkökre volt szükség, hogy ez megvalósítható legyen. Többek között ki kellett ütni azt az igényt, hogy tesszellált mikropoligonokból, azaz egy pixelnél kisebb háromszögekből történjen a számítás, ugyanis ez a mai hardvereken drámai mértékben megnövelné a láthatósági teszt terhelését. A hogyanról az Oxide Games nem szívesen beszél, mivel ez elég nagy üzleti titoknak számít, hiszen manapság nagyrészt ez a probléma akadályozza meg a valós idejű Reyes implementációk megszületését. Az viszont látható, hogy a probléma megoldható, tehát lehet, hogy az Ashes of the Singularity megjelenése beindítja a többi stúdió kutatását is a jobb leképezők felé.

...minden fényforrás külön árnyékot vet [+]

Az Oxide Games egyik nagy fegyvere, hogy az új leképező miatt gyakorlatilag olyan korlátokat törhettek át, amelyek minden mai játékban akadályt jelentenek. Például az árnyékot vető fények száma általában nyolcra van limitálva, mivel nagyjából ennyire elég a rendelkezésre álló hardverek ereje, de a legtöbb játék egyszerűen kettőt használ és kész. Az egyik jellemzően az égbolt, míg a másik például lehet a főhős karakterében egy zseblámpa. A stratégiai játékoknál a helyzet ennél is egyszerűbb, hiszen az égbolt fénye elég.

A jövőt jelentheti a használt objektumtér-alapú leképező [+]

A Nitrous azonban az új leképezővel elég komplex szituációkat is játszva kezel. Gyakorlatilag minden egyes jelenetben lévő fényforrás árnyékot vet, legyen az az égbolt vagy akár fegyverekből kilőtt sok száz lézernyaláb, illetve a különböző robbanások. Ez az a pont, ahol az objektumtér-alapú leképező igazán erősnek tekinthető, és előrevetíti, hogy mennyi lehetőség rejlik a leképezők modernizálásában, amit sok stúdió és kiadó egyszerűen nem hajlandó radikális mértékben fejleszteni. Bár anyagilag érhető az álláspontjuk, hiszen kétséges, hogy egy erőteljes átállás megtérül-e, így amíg van elfogadható szinten működő alap, addig a teljes újraírás nem jöhet szóba.

Az Oxide Games felfogása tehát radikálisan különbözik attól, amit eddig megszoktunk. Ez természetesen nem baj, mert ideje volt már bebizonyítani, hogy az előreszámolt számítógépes animációkhoz használt leképezők bizonyos módosításokkal működőképesek lehetnek valós időben, és remélhetőleg az eredményeket látva más is követi a Nitroust, nem feltétlenül technológiai, hanem innovációra való törekvés szempontjából.

Tesztkonfiguráció, metodika

Méréseink során törekedtünk arra, hogy a lehető legpontosabb képet kapjuk, amit olvasóink is könnyen reprodukálhatnak, így a játék beépített benchmarkját használtuk. A tesztek egyik és legfontosabb alappillére jól bevált, X99-es tesztkonfigurációnk, mely sokaknak már bizonyára ismerős lehet. Az alaplap egy Asus X99-PRO modell, míg a processzor feladatát egy fixen 4 GHz-re tuningolt Intel Core i7-5960X tölti be, hogy minél többet ki tudjunk passzírozni a tesztelt alkalmazásból. A rendszermemória mérete továbbra is 32 GB. A HyperX Fury típusú DDR4 modulból összesen négy található az alaplapban, így azok négycsatornás üzemmódban, 2666 MHz-en hasítanak.

Az egyre csak hízó játékok okán SSD-ből már kénytelenek voltunk egy 500 GB-os modellt választani, egészen konkrétan egy Samsung 850 EVO-t, bár jelen tesztünkben csak az Ashes of the Singularity és az operációs rendszer futtatása volt a feladata. Ez a negyedik alkalom, hogy a 64 bites Windows 10 Próra frissített tesztrendszerünk bevetésre kerül, aminek mostanra érett be a frissítése, hiszen a DirectX 12-es mód kizárólag ezzel érhető el. A tesztrendszer komponenseit az alábbi táblázat ismerteti.

Tesztkonfigurációnkban békésen megfér az NVIDIA és az AMD videokártya [+]

Ahol az Intel Core i7-5960X processzor órajelét és beállításait külön nem jeleztük, ott a korábbi tesztekben is megszokott 4 GHz-en, minden magjával és HT-vel együtt, túlhajtva üzemelt. A videokártyák meghajtóprogramjaiból a teszt mérései során elérhető legfrissebb verziót használtuk. Itt nem volt opció a régebbi, de biztosan stabil kiadás telepítése, aminek több oka is van. Mindkét gyártónál folyamatosan optimalizálják a kódot, és erősen fókuszálnak a DirectX 12-re. A 16.1-es Crimson és a 358.91-es NVIDIA driver kombinációjával ráadásul villogó fekete árnyékokat tapasztaltunk multiadapter módban az eltérő gyártók házasításakor. Egy-egy kisebb villanás a driverek frissítése után is maradt (szemfülesebbek a képernyőképeken is kiszúrhatják), de ez már nem volt zavaró, és csak ritkán fordult elő.

Hogyan mértünk?

Ezúttal kapunk jól konfigurálható beépített benchmarkot, így könnyű dolgunk lehetett volna, de mégsem volt. Sajnos a minimum FPS-t a játék saját teljesítménytesztje nem írja és nem is menti a logfájlba. Frametime ugyan szerepel, de a többszáz kilobájt méretű TXT fájlból hosszadalmas és körülményes volna a kinyerése. A FRAPS DirectX 12 üzemmódban sajnos nem működött, így azt sem használhattuk. Az első oldalon is említett rendhagyóságot tehát fokozzuk, mert ezúttal nem fognak a minimum FPS értékek szerepelni, csak az átlagok. Egyik szemünk sír, a másik viszont nevet: kétféle átlagot kapunk ugyanis a másodpercenkénti képkockaszámra! Rendelkezésünkre áll a sima számtani közép, és egy súlyozott átlag, aminél a hosszabb idő alatt kirajzolt frame-eket erőteljesebben veszi figyelembe a program. A grafikonok készítésekor ezt használtuk, így a tulajdonképpeni minimumérték beépítve kap helyet.

A kíváncsibbak és elemző érdeklődésűek az összes logfájlt ömlesztve, ZIP formátumba tömörítve letölthetik innen: FPS log [15,6 MB]. A DirectX 12-es futtatások a CPU képkockaszámot, driver-overheadet, processzorlimites részek arányát, batchekre szétválasztott értékeket, jelenetenkénti bontást és minden frametime-ot külön is tartalmaznak.

DirectX 12 a DirectX 11 ellen

Végigpörgettük WQHD-ben a beállítható preseteket, DirectX 12 és DirectX 11 módban, előbbit engedélyezett és letiltott aszinkron compute mellett is. Mint már a bevezetőben is jeleztük, itt a felszínre kerülnek az eltérő hardveres megvalósítás miatt mérhető különbségek. Az Ashes of the Singularity által korábban használt aszinkron compute kódút eltérő volt a két hardveren, de ezt egységesítették. Ez egy kicsit jobban megterheli a GeForce-okat, ezért csökken egy minimálisat az FPS. A DirectX 11-es jelentős eltérés az AMD kártyájához képest a parancslistás megközelítés miatt van, amit a zöld gyártó alkalmaz, a vörös viszont mellőz. Hosszabb idejű játék során a GeForce DirectX 11-es eredményei is alacsonyabbak lennének, mert nem érvényesülhetne a parancslista előnye.

A kisebb felbontások sem szolgáltak nagyobb meglepetéssel, hiszen még itt is a videokártya volt a gyengébb láncszem, a CPU-limitet szándékosan elkerültük. Mivel a DirectX 12 csak félszemű óriás lenne az aszinkron compute nélkül, így azt végig bekapcsolva hagytuk a kisebb felbontású tesztek alatt, így jött ki a kissé fura végeredmény. Ebből messzemenő következtetést levonni még nem lehet, hiszen az aszinkron compute a játék INI fájlját szerkesztve kikapcsolható. Összességében elégedettek vagyunk a látottakkal, a DirectX 12 hozta a jobb eredményeket, vagy így, vagy úgy. Megjegyeznénk, hogy a Mantle API-t bemutató tesztünkhöz hasonlóan nem vettünk észre jelentős képminőségbeli eltérést a DirectX 12 és DirectX 11 között.

A helyzet CPU-limit esetén

Aki az előző oldalon bosszúsan legyintett, hogy "ezért kellett ez a nagy felhajtás?", az most reméljük, ugyanannyira pislog, mint mi! Az AMD gyengébb (a kisebb Intel Core i3-asok szintjén elhelyezkedő) APU-ját használva az 50%-ot is meghaladja a DirectX 12-vel elért gyorsulás a Fury videokártyával. Nem szégyenkezhet a 4 magosra, Hyper-Threadinget is letiltva 2 GHz-re butított izomgépünk sem. A GeForce DirectX 11-es eredményeit a parancslistás feldolgozás torzítja (pozitív irányba), azt gondolatban lecsippentve nála is tekintélyes a gyorsulás mértéke. Külön öröm, hogy a gyengébb(re vett) konfigurációk és a tuningolt, teljes erőbedobással versenyző i7-es gép értékei között nem jelentős az eltérés, persze DirectX 12-ben. Itt még igazi processzorlimitről nem is beszélhetünk...

...hiszen az csak a következő grafikonon, visszább csavart beállításokkal (High preset) teljesedik ki igazán. Az AMD processzoros konfigon már a CPU számítási kapacitása korlátoz, de az Intellel még így is megugrik a framerate, ha a beállításokat csökkentve ennek teret engedünk. A Mantle API tesztelésekor találkoztunk hasonlóval, de közel sem ilyen szembetűnő mértékben.

Az utolsó grafikon az előző kettő összefésülése, más csoportosításban, ugyanis így jobban megfigyelhető, hol alakult ki a tényleges CPU-limit, és hol nyerhetünk még némi kraftot a kisebb részletességű beállítással. Az AMD konfiguráción a DirectX 12 valóságos csodát művel: mehet a maximális beállítás, kihajtja a lelkét a hardvernek így is. Felesleges visszavenni bármit is, hiszen mindenképp a processzor lesz a korlát. Az Intel még 2 GHz-en is nagyon erős, de itt már a 100%-os FPS-növekményt is megkörnyékezhetjük egy Radeonnal, ha DirectX 11 helyett DirectX 12-t használunk.

Csak a teljes, tuningolt órajelen futtatott i7-es gépezet esetén találkozunk az eredeti felállással. Ott szépen látható, hogy az eredmények csak a DirectX 12 fejlettsége miatt magasabbak a DirectX 11-eseknél, processzorlimit már nincs. Ezek az eredmények csak a viszonyítás megkönnyítése érdekében szerepelnek az összevetésben. Az NVIDIA parancslistás preferenciája itt is beleszól az eredménybe, ezt figyelembe kell venni.

Multiadapter: AMD és nV együtt

A Windows 10 egyik, kétségtelenül igen érdekes újítása a DirectX 12 által indukált változásokon kívül a WDDM2.0 felület. Ez a GPUMMU támogatáson felül azt is lehetővé teszi, hogy az operációs rendszer teljesen különállóként kezeljen két vagy több grafikus adaptert. Természetesen ez akkor is igaz, ha egy GeForce és egy Radeon van a gépben, persze a meghajtóprogramjaikat külön telepíteni kell. Ez a szaknyelvben explicit multiadapter néven szerepel, és a valóságban is működik. Eddig konkrét számok csak korlátozottan voltak elérhetők, így mi is leteszteltük ezt – értelemszerűen már csak DirectX 12-ben.

Nagy eltérés nem mutatkozik a már megtárgyalt aszinkron compute beállítását változtatva, de az egy GPU-s üzemhez képest majd' kétszeres gyorsulás bizony impozáns. Két sorrendben is letesztelésre került a páros, ugyanis a specifikáció szerepelteti, hogy az erősebb parancsprocesszorral rendelkező VGA-t célszerű elsődleges szerepbe fogni (erre kell a megjelenítőt csatlakoztatni). Fejlettebb architektúrája révén itt a Radeon érezte jobban magát az első pozícióban, ráadásul korántsem marginális többletet felmutatva, amin magunk is meglepődtünk.

Végül megnéztük a kisebb játszópajtásokat is. A Dual Graphics a DirectX 12-vel eleve nem működik, de szándékosan nem is az R7 250-t alkalmaztuk (amivel párosítva tudná ezt a funkciót DirectX 11-ben). A jelentősen erősebb R7 260X-et magában szerencsésebb üzemeltetni, az APU IGP-je csak visszafogta. A GT 740-nel már érdekesebb a helyzet. Természetesen itt sem volt mindegy, melyik az elsődleges adapter. A Godavari APU IGP-jét ebbe a szerepbe fogva még gyorsulást is kimértünk, de a kép iszonyatosan villódzott. A kisebb videokártyák mezőnyében tehát ez egyelőre csak érdekesség, de a nagyoknál működik. Idővel a technológia fejlesztései remélhetőleg az alsóházba is elhozzák a hibamentes változatot.

Értékelés, végszó

Összességében a DirectX 12 egyelőre egy alternatíva, amely választható. Grafika tekintetében a képminőség a korábbi technológiákhoz hasonlatos: nem szebb, de nem is rosszabb a renderelt végeredmény a DirectX 11-hez képest – jelenleg. A fény-árnyék hatások, tükröződések azonban már nem az API, hanem a grafikus motor korlátozásai miatt állnak fenn, ezek a jövőben valószínűleg komoly fejlődésen mennek majd keresztül. Üdvözlendő, hogy azonos hardverből pusztán programozástechnológiai váltással milyen mértékű szunnyadó tartalékot sikerült előcsalogatni, illetve az eddig kihasználatlan részegységeket végre megdolgoztatni. Jó, hogy alkalmazásával lejjebb tolhatjuk a játszhatóság alsó határát.

Tesztünkből is látszik, hogy a technológiában számos további, még kiaknázatlan lehetőség rejlik. Noha ez még csak az első szárnypróbálgatások időszaka, egy-egy momentum bizony szájtátósra sikerült. Nagyon érdekes a multiadapter funkció, hiszen GeForce és Radeon dolgozhat így együtt, hivatalosan. Erre még sosem volt korábban példa, sőt eddig jellemzően inkább lépéseket tettek ellene.

A játékból kiragadott képkocka megállapítása, tehát hogy anomáliák adódhatnak sajnos még egy-egy esetben (pl. multiadapter az alsó szegmensben) megállja a helyét. Jó hír, hogy ez már nem az átlagfelhasználás berkein belül van. Így a DirectX 12 nekünk hihetetlenül tetszett újításai és az általa elérhető teljesítménynövekedés miatt; érdemes haladni a korral, és lehetőség szerint kihasználni a benne rejlő adottságokat.

DirectX 12 grafikus API

Abu85 és 04ahgy

Az ASUS Radeon R9 Fury Strix videokártyát a Ramiris Europe Kft. biztosította.