Terrain Processing on Modern GPU - Computer Graphics Group ...

implicitní proměnné pro zpracovávaná primitiva. Pro vrchol je to například pořadí tohoto
vrcholu. Když známe velikost zobrazované mřížky, můžeme z pořadí vrcholu přesně určit, o jaký
vrchol se jedná, a nepotřebujeme tak jeho souřadnice. Zmíněnou proměnnou (VertexID) jsme
nazvali implicitní, protože není potřeba explicitně ji definovat – obdržíme ji v shaderu
automaticky. Takto nemusíme dodávat vůbec žádná data – stačí specifikovat, kolik vrcholů
chceme zpracovat, a ve vertex shaderu se nám uklizuje pro každý vrchol s jediným vstupem, a
tím bude jeho ID.
4.2.3.2 Využití geometry shaderu
Geometry shader, který jsme napsali pro implementaci subdivision surfaces, je trochu neobvyklý
svou komplexitou. Jeho úloha spočívá v určení, do jaké míry má být vstupní blok rozdělen,
vyzvednutí dat potřebných k takovému dělení a konečně provedení dělení samotného, tzn.
vygenerování velkého množství vrcholů, které budou každý jeden transformovány jako by byly,
kdyby prošly vertex shaderem. Toto obnáší o několik řádů více instrukcí než „běžný“ vertex
shader (to vychází už z toho, že transformace vrcholu tu může být provedena i tisíckrát). Zdálo se
nám tedy velmi důležité optimalizovat jej tak, aby sám nespotřeboval celou vyrovnávací paměť
instrukcí a aby prováděl opakované výpočty co nejméně krát – to je poměrně složitý úkol, neboť
na jeho druhé straně stojí omezené množství registrů a omezená možnost uchovat všechna
spočítaná data. O to více nás však překvapilo, že i přes toto velké množství aritmetických operací
byl výkon geometry shaderu přímo úměrný počtu vygenerovaných vrcholů – ne počtu
vypočítaných vrcholů!
Pokusili jsme se tedy provést více experimentů a nalézt zdroj problému. Ukázalo se, že
problémem je způsob, jakým je výstup z geometry shaderu hardwarově implementovaný. První
experiment byl založený na nahrazení vertex shaderu geometry shaderem. Přesněji řečeno, ve
vertex shaderu jsme pouze předali data dál pro zpracování geometry shaderem, a ten
transformoval všechny vrcholy stejným způsobem, jakým by to udělal vertex shader.
Samozřejmě každý vrchol byl použit pouze v jednom trojúhelníku, takže bylo znemožněno
využití vyrovnávací paměti a znehodnocení výsledků. Výsledky ukázaly, že zpracování vrcholů
geometry shaderem bylo přibližně dvakrát pomalejší pro zvolený kód.
Následoval další experiment, ve kterém jsme měnili velikost výstupu geometry shaderu a
komplexitu prováděného kódu. Zde se ukázalo, že dvakrát větší objem dat generovaných
shaderem znamená téměř dvojnásobné snížení rychlosti. Dodejme, že to není samozřejmé
chování – shader prováděl netriviální výpočty a rozšíření velikosti dat bylo spojeno pouze
s kopírováním již jednou spočítaných dat. Vedle toho jsme se snažili zajistit, aby ani exekuce pixel
shaderu nemohl zásadně ovlivnit výsledky – pixel shader byl triviální a data jsme generovali tak,
aby nebyla vidět, nebo aby se hojně využilo „Early Z“ vyloučení 19. Naopak změny ve složitosti
prováděného kódu se neprojevily konzistentním poklesem výkonu.
Konečně poslední experiment byl odvozen z výsledků předchozích. Transformace vrcholů jsme
prováděli pomocí vertex shaderu, ale tentokrát jsme zapojili i geometry shader, který však pouze
19 Early Z se označuje technika vyloučení pixelu ze zpracování na základě jeho negativního z-testu ještě
před tím, než se spustí kód pixel shaderu. Podrobněji je technika popsána například v (103).
65