Pokud bychom mluvili o výhodách, které nám DirectX 12 (samozřejmě také Vulkan a Metal) přinášejí, pak vše se odvíjí od rychlosti vytváření Draw Calls. Díky paralelnímu zpracování jsou Draw Calls vytvářeny mnohem rychleji a také v daleko vyšším počtu. Scény v počítačových hrách tak mohou obsahovat více a realističtěji vypadajících objektů. Také procesor by již neměl být brzdou herní smyčky (CPU Bound) a vývojář by si tak mohl dovolit na CPU provádět i složitější výpočty třeba umělé inteligence, fyziky apod.
Ruku v ruce s výhodami, DirectX 12 s sebou přináší samozřejmě také nějaké ty nevýhody. Naštěstí pro nás, tyto nevýhody se netýkají přímo nás spotřebitelů, ale zejména vývojářů. Pro snížení režie DirectX 12 a zajištění paralelního zpracování byly z jeho původní pipeline vypuštěny některé funkce, které vývojářům podstatným způsobem zjednodušovaly práci a nyní tyto funkcionality musí vykonávat vývojáři sami.
Například správa zdrojů v paměti je nyní zcela v kompetenci vývojářů. Jak už víme, dříve byla u každého příkazu zasílaného do GPU provedena kontrola alokace zdrojů ve VRAM pomocí Kernel Mode Driver. KMD v DirectX 12 prakticky vymizel a nyní za tuto alokaci zdrojů nese odpovědnost sám vývojář. Odešle-li například nějaký vykreslovací příkaz na GPU, který využívá texturu, ale zapomněl tuto texturu v paměti dříve alokovat, bude „odměněn“ pádem aplikace.
Jiným příkladem pak může být paralelní odesílání příkazů na GPU pomocí vícero front. Řekněme, že vývojář chce na GPU spustit nějaký výpočetní shader, který ke své práci využívá texturu. Shader tedy bude odeslán pomocí Compute Queue a příkaz na kopírování textury bude odeslán zase pomocí Copy Queue. Co se ale stane, když výpočetní shader dorazí na GPU a bude spuštěn dříve, nežli bude textura (kterou shader ke své práci nutně vyžaduje) zkopírována do VRAM? Myslím, že snad ani netřeba komentovat. U takovýchto závislostí je při paralelním zpracování příkazů vždy nutná synchronizace. Za takovýto kopírovací příkaz je tedy nutné vložit ještě jakýsi signalizační prvek (Fence), který našemu shaderu signalizuje, že kopírování zdroje bylo dokončeno a může tedy být bez obav spuštěn.
Takovéto hazardy a ještě mnoho dalších nových věcí budou muset vývojáři řešit v případě, pokud budou chtít využívat nové DirectX 12 a nám nezbývá nic jiného, nežli jim k tomu popřát hodně štěstí. Ale to už se odchyluji od dnešního tématu, takže raději dnes budeme končit. Pro jistotu ale znovu zopakuji, že vše, co zde dnes bylo popsáno, je kvůli lepšímu pochopení problematiky notně zjednodušeno. Kdo chce studovat tyto věci hlouběji a do větších detailů, Google bude pro něj asi tím nejlepším nástrojem.
Na samý závěr článku je třeba zdůraznit jednu podstatnou věc. 3D API nové generace nám přinášejí obrovský výkonnostní pokrok při vytváření snímku na straně procesoru a nebývalým způsobem tak mohou "krmit" grafickou kartu daty tak, aby její výkon byl vždy maximálně využit pro dosažení vyšších snímkových frekvencí v počítačových hrách. Pokud však budete disponovat grafickou kartou, která takovéto množství úloh nebude schopna zpracovat, nebo tyto úlohy pro ni budou příliš náročné na rendering, herní smyčka se stane "GPU Bound" a vy se žádného navýšení snímkové frekvence nedočkáte!
Příkazy na vykreslení se tedy z naší herní smyčky přenesly za pomoci DirectX do dopravníku s názvem Command queue (u DirectX 12 také do Compute queue a Copy queue) a my se po mnoha peripetiích konečně dostáváme k samotným grafickým kartám. Příští díl naší mini-série o grafické pipeline bude tedy věnován grafické kartě a popíšeme si, co vše se na hardware grafické karty musí udát, abychom mohli spatřit obraz počítačové hry na našich monitorech. Myslím, že to bude ještě zajímavé :)
Přečtěte si také:
1. Grafická pipeline I: Počítačová hra
3. Grafická pipeline III. Grafická karta
4. Grafická pipeline IV: Monitor