3DMark: testujeme výkon DirectX 12

Vývojáři se ale ve svých hrách nepotýkají pouze s obrazovou informací, oni musejí řešit i věci jako zvukové stopy, umělou inteligenci nebo herní fyziku. To vše dohromady konzumuje spoustu procesorového času a výkonu, který poslední dobou nijak závratně neroste. Je tedy nutné (a pokud to vůbec je možné) tyto úlohy rozkládat na více procesorových jader a co jen trochu jde, přehodit raději na bedra grafické karty. Rozložení jednotlivých úloh na více vláken či jader procesoru dnes pro většinu vývojářů není zdaleka takovým problémem, jako byl dříve, ale jak jim v tom pomáhají současná a dřívější 3D API? Stručně řečeno prakticky nijak, spíše naopak!

Pojďme se nyní podívat na to, co dnes DirectX nabízí vývojářům počítačových her. A že to nebude pohled veselý, naznačuje následující obrázek.

Obrázek ukazuje typické herní vytížení procesoru při přípravě snímku pod DirextX 11. Logika aplikace je vzorně rozložena do několika procesorových vláken, kde její nejpozději dokončené vlákno (číslo 1) je zpracováno v nějakém čase kolem 3 milisekund. To v řeči snímkové frekvence představuje nějakých 333 snímků za sekundu.

Bohužel dalším voláním 3D API na hlavním renderovacím vláknu si v tomto případě D3D ukrojí dalších více než 5 milisekund času potřebného k vytváření a odesílání Command Bufferů. Celkový čas potřebný na vytvoření snímku je nyní navýšen na zhruba 8 milisekund. Opět volně přeloženo do snímkové frekvence, toto navýšení času samotným API představuje propad na cca 125 snímků za sekundu.

S přimhouřením obou očí lze tedy říci, že si v tomto konkrétním případě samotné DirectX ukrojilo cca 50 % z celkového času na tvorbu snímku. A právě této režii 3D API při vytváření snímku se říká API Overhead, což je právě to, co 3DMark měří a co budeme dnes měřit také my.

Kromě doby potřebné na vytvoření vykreslovacích příkazů na straně procesoru je ještě potřeba další doby, kterou grafická karta potřebuje k samotnému zpracování zaslaných příkazů a finálnímu vykreslení snímku na monitor počítače. Pokud je doba tvorby snímku na straně procesoru delší než doba, kterou trvá GPU snímek vykreslit, je jasné, že grafická karta není dostatečně vytěžována a hra se stává závislou na CPU (cpu-bound). V opačném případě, kdy grafická karta nestíhá vykreslovat snímky tak rychle, jak jsou jí zasílány procesorem, je zase nevytížen procesor (musí stát a čekat na GPU) a hra se stává závislou na GPU (gpu-bound).

Samozřejmě, že druhá varianta (gpu-bound) je vždy tou lepší variantou, protože vývojáři mohou ušetřeného procesorového výkonu a času využít k dalším vylepšením hry (více objektů, inteligence, efekty atd..).

Pokud se na výše uvedený obrázek podíváme ještě jednou, člověk nemusí být nutně genius, aby viděl prakticky okamžitě zdroj problému. Kdyby D3D neprovádělo veškerou svou činnost pouze v prvním procesorovém vlákně (hlavní renderovací vlákno), ale rozložilo svou práci i do vláken ostatních, výsledný čas tvorby snímku by byl významně kratší.

Microsoft proto v DirectX 11 zavedl takzvaný Muti-Thread Rendering, který skutečně práci na vytváření Command Bufferů rozkládá do více vláken. Bylo v tom ale jedno velké ALE.

Práce při vytváření snímku procesorem je zde rozdělena do „Deffered Context“ a „Immediate Context“, kde procesorová vlákna sice mohou vytvářet vykreslovací příkazy paralelně do vlastních Command Listů (Deffered Context), ale takto vytvořené příkazy nemohou být okamžitě zasílány k exekuci na grafickou kartu. Tyto Command Listy se musí vrátit zpět do hlavního renderovacího vlákna a dále jsou zpracovávány podobně sériově jako u předchozích verzí (Immediate Context). Další nevýhodou tohoto řešení bylo to, že si MTR vyhradil celé jedno procesorové jádro, takže nějaké výkonnostní zisky se projevily až u procesorů s více než dvěma jádry.

Napříč tomu, že tvorba (příprava) Command Bufferů byla prováděna paralelně na několika vláknech, spoustu navazující práce API bylo tedy prováděno opět pouze sériově. Jednalo se tak o polovičaté řešení, které sice režii DirectX částečně snížilo, ale jak uvidíte z našich testů, nic co by mohlo vývojáře počítačových her nějak do budoucna uspokojit, se však nekonalo.

V každém případě Microsoft zřejmě pokládal MTR za dostatečně silný nástroj pro uspokojení vývojářů, OpenGL si šlo svou vlastní cestou Zero Api Overhead pomocí různých rozšíření a nic tak nenasvědčovalo tomu, že by se stojaté vody kolem 3D API a jeho vysoké režii měly nějak rozvířit.

Pak se však stalo něco, co mnoho lidí naprosto nečekalo. AMD ohlásilo nové 3D API s názvem Mantle a ze dne na den se začaly dít opravdu velké věci. Pojďme se tedy podívat, co že to Mantle vůbec je a jak vlastně funguje.