Využití grafického procesoru pro matematické výpočty. Bc. Miloslav Cinibulk

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Diplomová práce Využití grafického procesoru pro matematické výpočty Bc. Miloslav Cinibulk Vedoucí práce: Ing. Ivan Šimeček, Ph.D. Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 14. května 2010

2 iv

3 v Poděkování Na tomto místě bych chtěl poděkovat své rodině za podporu během studií. Za trpělivost a podporu během vypracovávání této práce bych chtěl poděkovat také lidem ve svém blízkém okolí a svému zaměstnavateli.

4 vi

5 vii Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Neratovicích dne 14. května

6 viii

7 Abstract The goal of this thesis is to verify a contribution of a processor utilization of common using graphics cards for general mathematical computation. The verification will be tested on computationally intensive task of computer visualization, ray tracing. This method is based on tracing the rays that pass through 3D scene. The ray tracing belongs to important field of computer graphics. The language Brook was utilised as an instrument of accessing the graphic processor. The Brook is freeware along with translator and run-time library, thanks to the project Brook- GPU that is developed by Standford University. Abstrakt Cílem této práce je ověřit přínos využití procesoru běžně používaných grafických karet pro obecné matematické výpočty. Toto ověření proběhne na výpočetně náročné úloze počítačové vizualizace ray tracing založené na sledování paprsků procházejících 3D scénou, která se řadí mezi významné oblasti počítačové grafiky. Jako nástroj pro zpřístupnění grafického procesoru bude použit jazyk Brook, který je spolu s překladačem a běhovou knihovnou volně přístupný díky projektu BrookGPU vyvíjeném na Stanfordské univerzitě. ix

8 x

9 Obsah 1 Úvod 1 2 Technické pozadí Porovnání architektury CPU a GPU Grafická rozhraní OpenGL DirectX Grafická pipeline Shading jazyky GLSL HLSL Cg Proudový programovací model GPGPU technologie CUDA Architektura Hardwarové požadavky Výhody a nevýhody ATI Stream Architektura Hardwarové požadavky Výhody a nevýhody OpenCL Architektura Hardwarové požadavky Výhody a nevýhody BrookGPU Architektura Hardwarové požadavky Výhody a nevýhody Shrnutí vlastností xi

10 xii OBSAH 4 BrookGPU Překlad překladače a běhové knihovny Překlad zdrojových kódů Instalace a nastavení Překlad Spuštění Jazyk Brook Float2, float3, float Stream Kernel Redukce Standardní funkce Začlenění do projektu Ukázkový příklad Ray tracing Princip metody Osvětlovací model Popis mechanizmu Vlastnosti Možnosti urychlení Urychlení výpočtů průsečíků Optimalizace průsečíkové funkce Snížení počtu výpočtů průsečíků Snížení počtu paprsků Řízení hloubky rekurze Adaptivní antialiasing Sledování více paprsků naráz Analýza a návrh řešení Ray tracing s využitím GPU Akcelerační struktura Konstrukce kd-stromu Výpočet cenové funkce Procházení kd-stromu Návrh řešení Specifikace cíle Volba implementačního prostředí Koncepční návrh CPU část Datové struktuty Engine Akcelerační struktura GPU část Datové struktuty Engine

11 OBSAH xiii Akcelerační struktura Realizace Popis projektu Formát scén Formát NFF Formát VIEW/TRI Popis tříd Třída CRayTracerEngine Třída Object Třída CEngine Třída CBrEngine Třída CKdTree Třída CBrKdTree Seznam kernelů GPU backend Zdrojové kódy třetích stran Problémy během realizace Překladač BRCC Verze Cg Toolkitu Velikost kernelů Vstupní proud zároveň jako výstupní Výpočetní maska Funkce floor Ověřování funkčnosti Testování Způsob testování Testovací sestavy Výsledky Primární paprsky Stínové paprsky Sekundární paprsky Kd-strom Zhodnocení výsledků Faktory ovlivňující výkonnost grafických karet Závěr 69 Literatura 71 A Seznam použitých zkratek 75

12 xiv OBSAH B Instalační a uživatelská příručka 77 B.1 Požadavky B.2 Spuštění aplikace B.3 Popis aplikace B.3.1 Parametry a vlastnosti B.3.2 Hlavní okno B Hlavní nabídka B Panel nástrojů B Seznam údajů B Stavový řádek B.3.3 Renderovací okno B.3.4 Nastavení B Karta General B Karta Rays B Karta Kd-tree B Karta GPU backend B.3.5 Ukládání nastavení B.3.6 Klávesové zkratky B.4 Překlad aplikace B.5 Poznámky k používaní aplikace C Galerie aplikace 87 D Galerie vyrenderovaných obrázků 89 E Obsah přiloženého CD 91

13 Seznam obrázků 2.1 Porovnání architektury CPU a GPU (převzato z [20]) Porovnání výkonnosti CPU a GPU (převzato z [20]) Grafická pipeline (převzato z [8]) Proudový programovací model Architektura CUDA (převzato z [19]) Architektura CUDA z pohledu GPU (převzato z [20]) Architektura ATI Stream (převzato z [5]) Programovací model ATI Stream (převzato z [5]) Platformní model OpenCL (převzato z [17]) Paměťový model OpenCL (převzato z [17]) Architektura BrookGPU Ray tracing Závislost ceny na pozici dělící roviny Zjištění počtu objektů nalevo a napravo od dělící roviny Procházení kd-stromu Návrh aplikace Kd-strom reprezentovaný polem Kd-strom reprezentovaný proudy B.1 Hlavní okno aplikace B.2 Renderovací okno B.3 Nastavení - karta General B.4 Nastavení - karta Rays B.5 Nastavení - karta Kd-tree B.6 Nastavení - karta GPU backend C.1 Aplikace - načítání dat C.2 Aplikace - konfigurace C.3 Aplikace - vyrenderovaný obrázek D.1 Obrázková galerie D.2 Obrázková galerie xv

14 xvi SEZNAM OBRÁZKŮ

15 Seznam tabulek 3.1 Porovnání základních vlastností GPGPU technologií Standardní funkce Seznam kernelů Výsledky testování primárních paprsků Výsledky testování stínových paprsků Výsledky testování sekundárních paprsků Výsledky testování kd-stromu B.1 Význam ikon na panelu nástrojů B.2 Klávesové zkratky xvii

16 xviii SEZNAM TABULEK

17 Kapitola 1 Úvod Herní průmysl je velice perspektivním a výdělečným odvětvím. Začátkem minulého roku některé IT magazíny přišly s informací, že počítačové hry za rok 2008, co se celkových příjmů týče, překonaly jak filmový tak hudební průmysl. Velká poptávka a silné konkurenční prostředí neustále tlačí dopředu nejen vývojářská herní studia, ale ruku v ruce i výrobce grafických procesorů (GPU - Graphics Processing Units). Důsledkem rychlého vývoje a odlišné architektuře je faktem, že výpočetní výkon v pohyblivé desetinné čárce (FLOPS) grafických procesorů je vyšší a roste i rychleji než u klasických procesorů (CPU - Central Processing Units). Tohoto potenciálu si všimla komunita výpočetní techniky a vznikl tak nový obor pojmenovaný GPGPU (General-Purpose computation on Graphics Processing Units). Zabývá se využitím GPU, které jsou primárně určeny pro výpočet a zobrazování vizuálních scén, i pro obecné matematické výpočty, které jsou primárně určeny pro CPU. Vzhledem k vysoké schopnosti paralelismu na GPU to může mnohdy vést k významnému urychlení. Cílem této práce je zmapovat dostupné technologie pro provádění obecných matematických výpočtů na grafických kartách, rozebrat jejich vlastnosti, výhody, nevýhody, možnosti praktického využití, atd. Dále naimplementovat metodu počítačové vizualizace ray tracing, což je výpočetně náročná metoda, založená na sledování paprsků procházejícími 3D scénou. Tato úloha bude provedena ve dvou implementacích, jednou pro CPU a jednou pro GPU. CPU implementace bude na všechny výpočty používat výhradně CPU. GPU implementace bude vycházet z CPU implementace s tím rozdílem, že prostřednictvím jazyka Brook bude na některé stěžejní výpočty, u kterých se to bude jevit jako výhodné, používat GPU. Výsledkem práce bude porovnání rychlosti práce s a bez použití procesoru grafické karty a zhodnocení faktorů ovlivňujících výkonnost grafických karet. 1

18 2 KAPITOLA 1. ÚVOD

19 Kapitola 2 Technické pozadí Tato kapitola by měla sloužit jako teoretický úvod do problematiky obecných matematických výpočtů na grafických kartách, kterým je věnována následující kapitola. Měla by vést k ujasnění některých pojmů, faktů a souvislostí z oboru počítačové grafiky. Mimo jiné budou ozřejmeny potencionální výhody architektury GPU, které nabízí pro výpočty v porovnání s architekturou CPU, a bude popsán proudový programovací model, který je vhodný pro programování algoritmů na GPU. 2.1 Porovnání architektury CPU a GPU CPU a GPU slouží k rozdílným účelům, čili mají podle toho i odlišnou architekturu. Na obrázku 2.1 jsou pro porovnání znázorněna bloková schémata jednotlivých architektur. Obrázek 2.1: Porovnání architektury CPU a GPU (převzato z [20]) CPU jsou navrhovány s ohledem na univerzálnost, na to, aby byly schopny řešit obecné výpočetní problémy nad nejrůznějšími typy dat. Architektura CPU tedy obsahuje několik složitých komplexních aritmetických jednotek (ALU). Velký důraz je kladen na řídící část a velikost cache paměti. Kvůli převládajícímu sekvenčnímu zpracování dat je podpora paralelismu v pozadí. GPU jsou navrhovány s ohledem na provádění specifických, relativně jednoduchých aritmetických operací nad obrovským množství dat stejného typu. Architektura GPU proto obsahuje velké množství jednodušších optimalizovaných aritmetických jednotek 3

20 4 KAPITOLA 2. TECHNICKÉ POZADÍ a velký důraz je kladen na podporu paralelizmu. Je zřejmé, že u CPU je výpočetního výkonu dosahováno zejména vysokou taktovací frekvencí, kdežto u GPU masivním paralelizmem. V praxi se taktovací frekvence CPU pohybuje v řádech několika GHz a GPU v řádech stovek MHz. Na obrázku 2.2 je graficky znázorněn vývoj výkonnosti různých generací CPU a GPU. Obrázek 2.2: Porovnání výkonnosti CPU a GPU (převzato z [20]) 2.2 Grafická rozhraní Grafický hardware je pro vývoj 2D a 3D aplikací zpřístupňován prostřednictvím grafického rozhraní. K dispozici jsou dvě hlavní rozhraní s přímou hardwarovou podporou, OpenGL a DirectX. Jedná se o vysokoúrovňová API (Application Programming Interface), která v základu poskytují obdobné služby. Smyslem je umožnit efektivní programování přenositelných grafických aplikací a oprostit programátora od zbytečných hardwarových detailů OpenGL OpenGL (Open Graphics Library) je standardizované programové rozhraní grafického hardwaru, původně vyvinuté společností Silicon Graphics 1. Obsahuje více jak 250 příkazů pro vývoj 2D a 3D aplikací. Jedná se o rozhraní nezávislé na hardwaru a použitelné na mnoha platformách. Neobsahuje tedy žádnou podporu pro práci s okny a obsluhu uživatelských vstupů. 1 Od roku 1992 OpenGL spravovalo konsorcium ARB (Architecture Review Board), které je od roku 2006 součástí konzorcia Khronos Group.

21 2.3. GRAFICKÁ PIPELINE 5 K tomuto účelu je nutné použít podpůrnou knihovnu. Často bývá využívána knihovna GLUT. Portabilita je jedním z důvodů, proč je OpenGL využíváno v řade profesionálních CAD systémech. Samotné OpenGL nabízí pro popis objektů pouze základní příkazy, jako je bod, úsečka a polygon. Nadstavbové funkce jsou obsaženy v knihovně utilit OpenGL (GLU), která poskytuje podporu pro složité křivky a povrchy. Knihovna GLU je standardní součástí OpenGL. Pro rozšiřování funkcionality používá OpenGL tzv. extenze (extensions). Extenzi může zavést libovolný hardwarový nebo softwarový výrobce. Každá extenze má přiřazeno unikátní číslo a název. Pro definování extenzí a jejich následné připojování do aplikací je navržen jednotný mechanizmus. OpenGL poskytuje programátorovi možnost zjištění podporovaných extenzí pro daný hardware a za běhu aplikace je připojit. Je běžnou praxí, že extenze, které jsou přijaty velkou většinou výrobců, bývají později prosazeny do základní funkcionality OpenGL DirectX DirectX je kolekce aplikačních rozhraní vyvíjená společností Microsoft, pro přímé ovládání moderního hardwaru. DirectX je určeno výhradně pro operační systém Microsoft Windows. Skládá se z řady knihoven pro práci s 2D grafikou (Direct2D), 3D grafikou (Direct3D), fonty (DirectWrite), nebo zvukem (DirectSound, DirectSound3D). V současné době nabízí technologicky vyspělejší funkce než OpenGL, a proto je drtivá většina moderních herních enginů postavena na DirectX. 2.3 Grafická pipeline Mezi základní funkce GPU patří sestavení obrazu z 3D objektů popsaných hraniční reprezentací. Tento proces je rozložen do grafické pipeline, která v GPU představuje funkční bloky, které na sebe navazují, a které mohou pracovat paralelně. Zjednodušený pohled na grafickou pipeline podle [8] je znázorněn na obrázku 2.3. Vedle neprogramovatelných výpočetních jednotek obsahuje moderní grafická pipeline také minimálně dva typy programovatelných procesorů, vertex procesor pro zpracování vrcholů a fragment procesor pro zpracování fragmentů. Vstupem jsou sekvence vrcholů spolu s údaji o jejich propojení, které zasílá 3D aplikace prostřednictvím grafického API. Každý vrchol má definovanou pozici a zpravidla i další atributy, jakými jsou barva, texturovací souřadnice a normálový vektor. Tyto vrcholy jsou nejprve transformovány a následně složeny do geometrických primitiv. Z dalšího zpracování jsou vyřazeny ty části, které leží mimo pohledový objem (clipping). Vyřazeny mohou být také odvrácené plochy (culling). V dalším kroku dochází k rasterizaci a interpolaci, což je převod geometrických a obrazových dat na fragmenty. Každý fragment odpovídá pixelu ve frame bufferu. Reprezentuje jeho potenciální stav, který může být aktualizován. Fragment má přiřazenou pozici pixelu, hloubku a řadu dalších parametrů získaných interpolací, jako je barva, sekundární barva a texturovací souřadnice. Všechny tyto parametry jsou odvozeny od transformovaných vrcholů

22 6 KAPITOLA 2. TECHNICKÉ POZADÍ tvořících danou geometrii. Před obnovením frame bufferu jsou nad jednotlivými fragmenty provedeny rastrové operace, které jsou standardní součástí OpenGL a Direct3D. V této fázi je každý fragment podroben několika testům (barvy, hloubky, atd.) a případně vyřazen. V případě vyřazení fragmentu není příslušný pixel aktualizován. Nová barva pixelu ve frame bufferu je dána míšením barvy fragmentu s původní barvou pixelu. Obrázek 2.3: Grafická pipeline (převzato z [8]) 2.4 Shading jazyky Důsledkem technologického pokroku grafických procesorů se díky novým možnostem stalo programování některých oblastí 3D grafiky poměrně složitou záležitostí. Byla přidána možnost přímo ovlivňovat grafickou pipeline pomocí menších programů označovaných jako shadery. Zpočátku se tyto programy programovaly na nízké úrovni pomocí strojového jazyka procesoru grafické karty. Ačkoli to programátorovi zaručovalo plnou kontrolu nad kódem a flexibilitu, bylo takovéto programování jednak časově náročné a jednak závislé na konkrétní instrukční sadě. Pro odstranění těchto problémů vzniklo několik vyšších programovacích jazyků, které se souhrnně nazývají shading jazyky [4]. Účelem těchto jazyků je zjednodušení programování shaderů a zajištění jejich přenositelnosti. Shader napsaný v takovémto jazyce je později překladačem přeložen přímo do strojového kódu konkrétní grafické karty. Shading jazyků určených pro interaktivní grafiku existuje několik. Všechny vycházejí ze syntaxe jazyka C, který rozšiřují o nové typy a konstrukce. V této části budou stručně představeny.

23 2.5. PROUDOVÝ PROGRAMOVACÍ MODEL GLSL GLSL (OpenGL Shading Language) je vysokoúrovňový programovací jazyk na bázi jazyka C určený pro psaní shaderů, které slouží k řízení zpracování vrcholů a fragmentů pipeline OpenGL. Shader pro zpracování vrcholů je označován jako vertex shader a shader pro zpracování fragmentů jako fragment shader. Programovatelné zpracování vrcholů a fragmentů pomocí shaderů bylo do OpenGL zavedeno od verze 2.0. Více se lze s GLSL seznámit v [27] HLSL HLSL (High Level Shading Language) je shading jazyk navržení společností Microsoft pro použití s rozhraním DirectX. Jedná se o analogii jazyka GLSL určeného pro OpenGL. Pomocí HLSL lze programovat tři typy shaderů, vertex, pixel a geometry shader. Vertex shader slouží pro zpracování vrcholů, generování souřadnic textur a počítání koeficientů osvětlení. Pixel shader slouží k operacím nad pixely. Geometry shader slouží k ovlivňování geometrie přidáváním a odebíráním vrcholů Cg Cg (C for Graphics) je shading jazyk vyvinutý společností NVIDIA v úzké spolupráci se společností Microsoft. Je velice podobný jazyku HLSL. Překladač Cg podporuje shadery jak pro DirectX tak pro OpenGL. 2.5 Proudový programovací model Pro programování algoritmů využívajících výpočetní síly GPU se používá oproti CPU, které odkazují na model sekvenčního programovaní, odlišný programovací model, který je vhodný pro paralelní výpočty. Označuje se jako proudový a je zmiňován v [21, 25]. V tomto programovacím modelu je hlavním používaným datovým typem proud (stream). Proud je tvořen kolekcí dat stejného typu. Data mohou být typu jednoduchého (např. reálné číslo) nebo složeného (např. bod). Ačkoli proudy mohou mít různou délku, je výpočet efektnější, jsou-li delší (stovky a více elementů v proudu). O paralelní výpočty nad proudy se starají funkce, které se nazývají jádra (kernels). Vstupem jádra je jeden či více proudů. Výstupem jádra bývá zpravidla opět jeden či více proudů. Platí, že výstupy jádra jsou funkcí jeho vstupů. Nejtypičtěji se jádro používá k vyhodnocení nějaké funkce aplikováním určité operace na každý element vstupních proudů. Vstupem jádra určeného pro součet dvou proudů mohou být např. proudy (1, 2, 3, 4, 5) a (2, 2, 2, 2, 2). Výstupem by v tomto případě byl proud (3, 4, 5, 6, 7). Dále se může jádro použít pro redukci, kdy je více vstupních elementů kombinováno do jednoho výstupního elementu. Opakem je expanze, kdy je z jednoho vstupního elementu produkováno několik výstupních elementů. Možná je také filtrace, jejíž výstupem je podmnožina vstupních elementů. Při zpracovávání jednotlivých elementů proudu v rámci jádra není mezi těmito elementy žádná závislost.

24 8 KAPITOLA 2. TECHNICKÉ POZADÍ V proudovém programovacím modelu jsou aplikace navrhovány tak, aby pro výpočet využívaly zřetězení více výpočetních jader. Tak, aby výstupní proud jednoho výpočetního jádra mohl být vstupním proudem dalšího výpočetního jádra jak ukazuje obrázek 2.4. Obrázek 2.4: Proudový programovací model

25 Kapitola 3 GPGPU technologie Moderní grafické procesory se vyznačují rozšířenou programovatelností, která je umožňuje použít i k jiným účelům, než je zpracování obrazu. Umožňuje je využít k obecným matematickým výpočtům, které jsou typicky určeny pro CPU. Hlavním smyslem přenesení některých výpočtů z CPU na GPU je zvýšení výpočetního výkonu nejrůznějších úloh z oblasti matematiky, fyziky, nebo medicíny. Konkrétně se může jednat o Fourierovu transformaci, lineární algebru, numerické řešení diferenciálních rovnic, atd. GPU lze pro obecné matematické výpočty zpřístupnit přímo prostřednictvím grafických rozhraní OpenGL nebo DirectX za použití shading jazyků. Tento způsob je z hlediska výkonu optimální, nicméně z pohledu programátora poněkud těžkopádný a zbytečně složitý, neboť vyžaduje pokročilé znalosti grafického API a povědomí o možnostech a omezení grafického hardwaru. Shading jazyky jsou určeny především k programovaní shaderů pro ovlivňování obrazu v grafické pipeline a ne pro obecné úlohy. Z programátorského hlediska je výhodnější používat nástroje, které jsou obecným výpočtům šité na míru. Může se jednat o určitou abstrakci nad rozhraním OpenGL nebo DirectX, zakrývající pro náš účel nadbytečné grafické náležitosti, doplněnou o vysokoúrovňový programovací jazyk na bázi jazyka C, nebo se může jednat o softwarovou vrstvu, která je spolu s grafickým hardwarem pro obecné výpočty speciálně navržena. Takovéto nástroje se obecně označují zkratkou GPGPU (General-Purpose computation on Graphics Processing Units). V současné době existuje několik GPGPU technologií určených pro akceleraci obecných výpočtů prostřednictvím grafických karet. V této kapitole budou zmíněny ty, které patří z hlediska technologického a z hlediska použitelnosti k těm nejzajímavějším. Jedná se o technologii CUDA společnosti NVIDIA, ATI Stream společnosti AMD, OpenCL konsorcia Khronos Group a BrookGPU vyvíjeném na Stanfordské univerzitě. Kapitola je strukturovaná tak, že ke každé technologii je uveden krátký úvod představující danou technologii, dále základní popis architektury vycházející z dostupných materiálů a specifikací, hardwarové požadavky nutné pro použití, výhody a nevýhody dané technologie. Závěr kapitoly je věnován shrnutí vlastností všech zmiňovaných technologií a úvaze o jejich možném praktickém využití. 9

26 10 KAPITOLA 3. GPGPU TECHNOLOGIE 3.1 CUDA CUDA (Compute Unified Device Architecture) je technologie společnosti NVIDIA, která umožňuje používat rozšíření jazyka C pro psaní algoritmů běžících na GPU. Tato technologie je založena na speciálně upravené architektuře grafických karet NVIDIA, která je zaměřena na provádění obecných paralelních výpočtů na GPU. Součástí CUDA Toolkit jsou dvě standardní knihovny pro numerické výpočty BLAS (Basic Linear Algebra Subroutines) a FFT (Fast Fourier Transform) Architektura Architektura CUDA (viz obr. 3.1) zahrnuje jak softwarovou část, která představuje nástroje pro vývoj aplikací, tak hardwarovou část, což je samotný návrh GPU. Programový model CUDA je založen na standardizovaném programovacím jazyku C rozšířeném o nová klíčová slova (C for CUDA). Podporována jsou také výpočetní rozhraní DirectX Compute a OpenCL. Díky nadstavbě C Runtime je možné používat i jazyky, jako je Fortran, Java, Python a další. Z operačních systémů jsou podporovány Windows, Linux a Mac OS. Obrázek 3.1: Architektura CUDA (převzato z [19]) Architektura CUDA z pohledu GPU je zobrazena na obrázku 3.2. Je postavena nad polem proudových multiprocesorů. Každý multiprocesor obsahuje osm skalárních procesorů s registry, multivláknovou instrukční jednotku, sdílenou paměť, pameť pro konstanty a paměť pro textury. Multiprocesor vytváří, spouští a spravuje souběžná vlákna s nulovou režií plánování. Synchronizace vláken je řešena pomocí bariéry, která je realizována jedinou instrukcí syncthreads(). Ke správě velkého množství vláken běžících oddělených programů je použita nová architektura nazvaná SIMT (Single Instruction Multiple Thread). Multiprocesor

27 3.1. CUDA 11 Obrázek 3.2: Architektura CUDA z pohledu GPU (převzato z [20]) mapuje každé vlákno na skalární procesor a každé skalární vlákno spouští nezávisle s jeho vlastní instrukční adresou a stavem registru Hardwarové požadavky Technologii CUDA lze využívat na grafických kartách NVIDIA řady GeForce 8xxx a vyšší, Fermi, Quadro a Tesla Výhody a nevýhody CUDA společnosti NVIDIA je jedna z nejstarších uveřejněných a také nejznámějších technologií pro obecné paralelní výpočty na GPU. V současné době se řadí mezi nejpokročilejší GPGPU technologie. Výhodou je, že se tato technologie neustále vyvíjí a má podporu významného výrobce grafického hardwaru. K dispozici je propracovaná dokumentace s řadou rad a doporučení pro návrh aplikací. Nevýhodou je skutečnost, že CUDA lze využívat pouze s grafickými kartami NVIDIA.

28 12 KAPITOLA 3. GPGPU TECHNOLOGIE 3.2 ATI Stream ATI Stream je technologie společnosti AMD, která představuje řadu pokročilých hardwarových a softwarových technologií, které zpřístupňují grafický procesor ATI jako pomocnou sílu pro CPU k akceleraci výpočtů aplikací. Vychází z CTM (Close To Metal), což je nízkoúrovňové programové rozhraní vyvinuté společností ATI 1 zaměřené na GPGPU výpočty prostřednictvím moderních grafických akcelerátorů ATI. CTM je nyní dále vyvíjeno pod názvem CAL (Compute Abstraction Layer) Architektura Architektura ATI Stream (viz obr. 3.3) je postavena nad moderními stream procesory ATI. O komunikaci na nejnižší úrovni se stará nízkoúrovňové rozhraní Compute Abstraction Layer. To dovoluje vývojářům pracovat s grafickými jádry na nejnižší úrovni a nejlépe tak optimalizovat výkon aplikací. Nadstavba nad tímto rozhraním se nazývá Brook+, která vzešla z open source projektu BrookGPU (viz část 3.4). Brook+ je upraveno na míru rozhraní CAL a na rozdíl od BrookGPU funguje pouze s hardwarem od AMD-ATI. Brook+ je v současné době nahrazován standardizovaným rozhraním OpenCL (viz část 3.3). Obrázek 3.3: Architektura ATI Stream (převzato z [5]) Na obrázku 3.4 je znázorněn zjednodušený programovací model ATI Stream. Programovatelná stream jádra vykonávají různé, programátorem napsané programy, které se nazývají kernely. Stream jádra mohou provádět negrafické funkce použitím virtualizovaného SIMD (Single Instruction Multiple Data) programovacího modelu pracujícímu nad proudy dat. V tomto modelu jsou pole vstupních dat mapovány na řadu SIMD enginů, které spouští 1 Společnost ATI byla v roce 2006 koupena společností AMD.

29 3.2. ATI STREAM 13 Obrázek 3.4: Programovací model ATI Stream (převzato z [5]) kernely ke generování jednoho nebo více výstupů, které jsou zapsány zpět do výstupních polí v paměti. Kernel je rozdělen na vlákna, kde každé běží na thread procesoru. Stream procesor mapuje pole vláken na skupinu thread procesorů, dokud všechna vlákna nejsou zpracována Hardwarové požadavky ATI Stream lze využívat na grafických kartách ATI řady HD 2350 a vyšší, FireGL, FirePro a další Výhody a nevýhody ATI Stream je přímou konkurencí ke CUDA společnosti NVIDIA. Mezi vývojáři není možná tolik v podvědomí, což je dáno jednak pozdějším zpřístupněním široké veřejnosti a jednak méně výrazným marketingem. Výhodou ATI Stream je skutečnost, že za ní stojí společnost, která v současné době disponuje nejvýkonnější ucelenou řadou grafických karet na trhu. Nevýhodou je, že se, podobně jako v případě CUDA, nejedná o obecně přijatý standard.

30 14 KAPITOLA 3. GPGPU TECHNOLOGIE 3.3 OpenCL OpenCL (Open Computing Language) je nový otevřený standard, za kterým stojí konsorcium Khronos Group skládající se ze zástupců nejvýznamnějších firem v IT průmyslu, jako je Apple, Intel, AMD, IBM, NVIDIA a mnoho dalších. Slouží jako podpora pro paralelní programování moderních procesorů v osobních počítačích, serverech, nebo embedded zařízeních. Tedy k programování různorodé kolekce CPU, GPU a jiných diskrétních výpočetních zařízení organizovaných do jednotné platformy Architektura OpenCL zahrnuje programovací jazyk (rozšíření standardu C99), API, knihovny a runtime systém. Poskytuje nízkoúrovňovou hardwarovou abstrakci spolu s frameworkem pro podporu programování. Architekturu OpenCL lze dle [17] rozdělit na hierarchii čtyř modelů, modelu platformního (Platform), prováděcího (Execution), paměťového (Memory) a programovacího (Programming). Platformní model model je znázorněn na obrázku 3.5. Sestává se z hostitelského zařízení (Host) připojeného k jednomu nebo více OpenCL zařízení (Compute Device). OpenCL zařízení je rozděleno na jednu či více výpočetních jednotek (Compute Unit), které jsou dále rozděleny do jednoho či více výkonných prvků (Processing Element - PE). OpenCL aplikace běží na hostitelském zařízení (platformě) podle modelu, který používá. Přijímá příkazy z modelu hostitelské platformy a předává je ke zpracování výkonným prvkům uvnitř OpenCL zařízení. Obrázek 3.5: Platformní model OpenCL (převzato z [17]) Vykonání OpenCL programu nastává ve dvou částech: funkce (kernel), která je vykonána na jednom či více OpenCL zařízeních a host program, který je vykonán na hostitelském zařízení. Host program definuje kontext pro kernely a řídí jejich vykonání. V paměťovém modelu OpenCL (viz obr. 3.6) je paměťový prostor rozdělen na globální paměť, paměť konstant, lokální paměť a privátní paměť. Globální paměť umožňuje přístup ke všem výkonným prvkům ve výpočetních jednotkách. Paměť konstant slouží k ukládání

31 3.3. OPENCL 15 Obrázek 3.6: Paměťový model OpenCL (převzato z [17]) konstant během vykonání kernelu. Lokální paměť může být využita k alokaci proměnných, které jsou sdíleny všemi výkonnými prvky v rámci jedné výpočetní jednotky. Privátní paměť je paměťový prostor vyhrazený výkonným prvkům. Aplikace běžící na hostitelském zařízení využívá OpenCL API k vytváření objektů v globální paměti a k vytváření příkazů, které nad těmito objekty pracují. Paměťové modely hostitelského zařízení a OpenCL zařízení jsou z velké části navzájem nezávislé, neboť hostitelské zařízení je definováno mimo OpenCL. V OpenCL jsou podporovány data parallel a task parallel programovací modely, stejně jako hybridy těchto modelů. Primárně je v návrhu OpenCL používán data parallel model Hardwarové požadavky OpenCL funguje na všech výpočetních zařízeních, ke kterým je k dispozici příslušný OpenCL ovladač Výhody a nevýhody Výhodou standardu OpenCL je, že není navržen jako čistě GPU programovací platforma pro hardware jednoho konkrétního výrobce, ale jako paralelní platforma pro programování napříč řadou různorodých výpočetních zařízení. To OpenCL odlišuje od CUDA nebo ATI Stream, které jsou navrženy pro práci s konkrétním grafickým hardwarem. Komplexnost návrhu OpenCL představuje i určitou nevýhodu, a to složitější API.

32 16 KAPITOLA 3. GPGPU TECHNOLOGIE 3.4 BrookGPU BrookGPU (Brook for GPUs) je open source projekt, za kterým stojí tým vývojářů ze Stanfordské univerzity. Jedná se o překladač a implementaci proudově orientovaného programovacího jazyka Brook, který umožňuje provádění obecných matematických výpočtů na procesorech grafických karet. Kromě překladače lze dále bezplatně stáhnout běhovou knihovnu, která zajišťuje komunikaci s grafickým hardwarem a ukázkové příklady demonstrující možnosti jazyka Architektura BrookGPU se skládá ze dvou hlavních částí. Source to source překladače BRCC a běhové knihovny BRT (Brook Run-Time). Překladač BRCC překládá zdrojové soubory napsané v jazyce Brook (.br) do zdrojových souborů jazyka C++ (.cpp). Za pomoci BRT převádí konstrukce jazyka Brook do syntaxe jazyka C++. BRT je na architektuře nezávislá softwarová vrstva, která implementuje funkční podporu jazyka Brook pro příslušný hardware. Implementace BRT umožňuje běh na GPU nebo CPU. Pro běh na GPU je podporováno rozhraní DirectX 9, OpenGL a CTM (pouze grafické karty AMD-ATI). Obrázek 3.7: Architektura BrookGPU Hardwarové požadavky BrookGPU může pracovat ve 4 režimech. V režimu DirectX, OpenGL, CTM a CPU. Pro DirectX režim je vyžadována grafická karta s podporou DirectX minimálně verze 9. Pro OpenGL režim je vyžadována grafická karta s podporou OpenGL minimálně verze 1.3.

33 3.4. BROOKGPU 17 Karta by dále měla podporovat Shader Model 3.0. Tyto požadavky dnešní grafické karty běžně splňují. Pro CTM režim je vyžadována grafická karta AMD-ATI s podporou Stream SDK (dříve nazýváno Close To Metal). V CPU režimu je využíván pouze hlavní procesor a na grafickou kartu tedy žádný požadavek kladen není Výhody a nevýhody Mezi výhody BrookGPU patří podpora (i starších) grafických karet různých výrobců. Nevýhodou oproti technologiím CUDA a ATI Stream je méně efektivní přístup ke GPU a horší zdokumentování.

34 18 KAPITOLA 3. GPGPU TECHNOLOGIE 3.5 Shrnutí vlastností V této kapitole byly představeny celkem čtyři GPGPU technologie. Jednalo se o technologie CUDA, ATI Stream, OpenCL a BrookGPU, jejichž souhrnné vlastnosti jsou uvedeny v tabulce 3.1. Všechny slouží především k akceleraci obecných výpočtů prostřednictvím procesorů grafických karet. Technologie Podpora GPU různých výrobců Multiplatformní Standard CUDA Ne Ano Ne ATI Stream Ne Ano Ne OpenCL Ano Ano Ano BrookGPU Ano Ano Ne Tabulka 3.1: Porovnání základních vlastností GPGPU technologií CUDA funguje oficiálně pouze s grafickými kartami NVIDIA určitých modelových řad. Podobně ATI Stream funguje zatím pouze s grafickými kartami ATI. To technologie CUDA a ATI Stream předurčuje z důvodu omezené přenositelnosti spíše k využití v akademických projektech nebo tvorbě specifických konvertovacích utilit. Akcelerace přes CUDA využívá např. Badaboom Media Converter nebo Cyberlink MediaShow Espresso. Akcelerace přes ATI Stream dokáže využít např. Avivo Video Converter nebo Cyberlink PowerDirector 7 a vyšší. BrookGPU je open source projekt, jehož hlavní výhodou je podpora grafických karet obou hlavních výrobců NVIDIA a AMD-ATI. Poslední dostupná verze je ve fázi beta, čili se musí počítat, co se stability a kompatibility týče, stále s určitou nedoladěností. Během vypracovávání této práce nebyl tento projekt nijak výrazně aktualizován a není jisté, zdali bude dále vyvíjen, protože vývojáři se v poslední době věnovali spíše vývoji Brook+ pro AMD. AMD ovšem Brook+ ke konci roku 2009 nahradilo OpenCL, takže je otázkou, jak se věci dále vyvinou. OpenCL je otevřený standard zpřístupňující různorodý výpočetní hardware pro paralelní výpočty prostřednictvím vysokoúrovňového API. Vzhledem ke komplexnosti návrhu je programování pod OpenCL v porovnání s CUDA nebo BrookGPU o něco pracnější. Význam OpenCL dokazuje skutečnost, že AMD nahradilo Brook+ u ATI Stream právě tímto standardem a s Brook+ již nepočítá. NVIDIA také stále více prosazuje CUDA spolu s OpenCL. Připravovanou podporu OpenCL pro zpřístupnění síly grafických procesorů v 3D modeláři Lightwave 3D již anoncovala např. společnost NewTek.

35 Kapitola 4 BrookGPU Tato kapitola se podrobněji věnuje projektu BrookGPU [2], jelikož je prakticky používán v implementační části této práce. Bude uveden: Podrobný návod jak přeložit překladač BRCC a statickou knihovnu běhové knihovny BRT jazyka Brook pod operačním systémem Microsoft Windows. Popis překladu zdrojových kódů napsaných v jazyce Brook. Základní popis jazyka Brook. Popis jak využít jazyk Brook v rozsáhlejších projektech psaných v C++. Ukázkový příklad kombinující jazyky Brook a C Překlad překladače a běhové knihovny Následující popis je odzkoušený na verzi 0.5 beta1 a platí pro 32-bitový operační systém Microsoft Windows XP / Vista / 7. K překladu budou vyžadovány následující nástroje: MS Visual Studio 2005 / 2008 Cygwin DirectX 9 SDK Po nainstalování vývojového prostředí MS Visual Studio 2005 / 2008 je další postup následující: 1. Ze stránek stáhnout projekt Brook a rozbalit na disk 1. 1 Nejaktuálnější vývojářskou verzi lze získat přímo z svn: 19

36 20 KAPITOLA 4. BROOKGPU 2. Ze stránek stáhnout instalátor Cygwinu. Při instalaci zvolit Instal from Internet a při výběru balíků změnit pouze u Devel hodnotu Default na Install, jinak stačí ponechat výchozí nastavení. 3. Ze stránek stáhnout DirectX SDK a nainstalovat. 4. V prostředí MS Visual Studio provést následující nastavení: Tools Options Projects and Solutions VC++ Directories: v Executable files přidat: C:\cygwin\bin a posunout pod $(VCInstallDir)bin, aby se předešlo kolizi s link.exe v Include files přidat: C:\Program Files\Microsoft DirectX SDK\Include v Library files přidat: C:\Program Files\Microsoft DirectX SDK\Lib\x86 5. Rozbalený projekt Brook otevřít ve Visual Studiu a přepnout se do režimu Release. Pravým tlačítkem kliknout na projektovou složku brcc a zvolit Build. To samé provést pro projektovou složku runtime. V případě výskytu některých chybových hlášení jsou možná následující řešení: Chybové hlášení: fatal error C1083: Cannot open include file: unistd.h : No such file or directory Možné řešení: V projektové složce brcc dopsat do souborů lexer.l a ps2arb_lexer.l definici #define YY_NO_UNISTD_H. Chybové hlášení: error C3861: isatty : identifier not found Možné řešení: V projektové složce brcc dopsat do souboru ps2arb_lexer.l #include <io.h>. 6. Po úspěšném překladu najdeme v kořenovém adresáři projektu ve složce bin spustitelný soubor brcc.exe překladače a statickou knihovnu brook.lib běhové knihovny. 4.2 Překlad zdrojových kódů Instalace a nastavení 1. Ze stránek stáhnout a nainstalovat Cg Toolkit. 2. Na disku C (nebo jiném) vytvořit složku brook a v ní podsložky bin a lib. 3. Do složky bin zkopírovat spustitelný soubor brcc.exe.

37 4.2. PŘEKLAD ZDROJOVÝCH KÓDŮ Do složky lib zkopírovat statickou knihovnu brook.lib. 5. Do složky brook zkopírovat složku include z kořenového adresáře projektu Brook- GPU. 6. V prostředí MS Visual Studio provést následující nastavení: Tools Options Projects and Solutions VC++ Directories: v Include files přidat: C:\brook\include v Library files přidat: C:\brook\lib Překlad 1. Do složky C:\brook\bin zkopírovat zdrojový soubor nazev_souboru.br. 2. Spustit konzoli (Start Spustit... cmd), pomocí příkazu cd C:\brook\bin se přepnout do adresáře bin a zadat např. příkaz: brcc -p ps20 -p arb -p cpu -f cgc nazev_souboru.br Ve složce bin se tak vytvoří soubor nazev_souboru.cpp. Další možné nastavení přepínačů překladače zjistíme příkazem: brcc. 3. Ve Visual Studiu založit nový prázdný projekt Win32 Console Applications a přidat do něj soubor nazev_souboru.cpp. 4. V nastavení projektu provést následující nastavení: Configurations Properties Linker Input Additional Dependencies: přidat: brook.lib opengl32.lib d3dx9.lib d3d9.lib 5. Klávesou F7 spustit překlad Spuštění Před spuštěním přeloženého souboru nazev_souboru.exe musí být nastavena proměnná prostředí BRT_RUNTIME, podle které je aktivován příslušný režim běhu. Možnosti jsou následující: BRT_RUNTIME=cpu... CPU režim BRT_RUNTIME=dx9... DirectX režim BRT_RUNTIME=ogl... OpenGL režim BRT_RUNTIME=ctm... CTM režim

38 22 KAPITOLA 4. BROOKGPU 4.3 Jazyk Brook Brook je rozšířením standardizovaného jazyka ANSI C. Je navržen tak, aby zahrnul myšlenky paralelního výpočtu dat do známého a efektivního jazyka. Program napsaný v jazyce Brook obsahuje běžný kód jazyka C rozšířený o nové typy a konstrukce. Plnou specifikaci jazyka lze nalézt v [1] Float2, float3, float4 Float2, float3 a float4 jsou základní typy, kterými Brook rozšiřuje jazyk C. Odpovídají následujícím definicím: typedef struct { float x, y; } float2; typedef struct { float x, y, z; } float3; typedef struct { float x, y, z, w; } float4; Inicializovat tyto typy lze pomocí konstruktoru: float4 a = float4(0.2f, 1.0f, 3.2f, 1.0f); // x = 0.2f, y = 1.0f... Inicializace: float4 a(0.2f, 1.0f, 3.2f, 1.0f), která je uvedena v oficiální dokumentaci, však nefunguje Stream Stream (proud) je datový typ, který reprezentuje kolekci dat, která může být zpracována paralelně. Příklad deklarace datového typu stream vypadá následovně: float s<10, 10>; což označuje dvourozměrný proud hodnot typu float. Obsahuje celkem 100 prvků a má tvar matice o rozměrech 10 x 10. Datový typ stream má řádkovou reprezentaci. Pro proudy platí následující omezení: Přímý přístup (např. s[3][2]) je přípustný pouze uvnitř kernelů (uvedeny dále). Není povolena statická inicializace: float s<100> = {1.0f, 2.0f,... Číst a zapisovat lze pouze v rámci kernelu. Mimo kernel lze číst a zapisovat pomocí speciálních operátorů streamread a streamwrite: streamread(s, data_s) // Naplnění proudu s daty z *data_s streamwrite(s, data_s) // Naplnění *data_s daty z proudu s Mohou být deklarovány pouze na zásobníku.

39 4.3. JAZYK BROOK 23 Mohou být typu float, float2, float3, float4, nebo kombinací těchto typů ve formě struktury. Maximální povolená velikost proudu závisí na tom, jak velké textury dokáže daná grafická karta zpracovávat. Většina grafických karet běžně zvládá rozměr 1024 x Nejmodernější grafické karty podporují rozměr 4096 x Kernel Kernely (jádra) jsou speciální funkce, které pracují nad datovými proudy. Kernel je paralelní funkce aplikovaná na každý element proudu. Volání funkce jádra na sadu vstupních proudů provádí implicitní for-cyklus nad všemi elementy proudů, ve kterém se pro každý element vyvolává tělo jádra. Při využití GPU jsou proudy přesunuty do videopaměti a jádro přeloženo do fragment programu. Definice jádra je podobná definici klasické funkce v jazyce C, kde celý zápis předchází klíčové slovo kernel. Návratová hodnota je vždy typu void a jeden z proudových parametrů musí být označen kvalifikátorem out. Statické proměnné a globální paměť nejsou v rámci jádra přístupné. Prototypy a těla jádra jsou omezené na podmnožinu C/C++, kterou podporuje Cg/HLSL. Příklad definice a volání jádra může vypadat takto: kernel void k(float s<>, float3 f, float a[][], out float o<>) {... } k(s, 3.2f, a, o); // Volání jádra k V tomto případě bude tělo jádra k voláno na každý element ze vstupního proudu s. Parametr f je konstantní parametr kernelu, který uchovává stejnou hodnotu pro každou iteraci. Zapisovat do vstupního proudu či měnit konstantní proměnné uvnitř jádra není povoleno. Parametr a je dvourozměrný proud, k jehož elementům lze přistupovat stejně jako v jazyce C, tedy pomocí závorek []. Parametr o je výstupním proudem. Je to proměnná určená pouze pro zápis a slouží k zápisu hodnoty vypočtené v těle jádra. Tělo jádra je implicitně prováděno na každém elementu proudu s a výsledek je zapisován do proudu o Redukce Brook poskytuje podporu pro paralelní redukci nad proudy. Redukce je operace, která z jednoho proudu vytvoří proud menší velikosti nebo jednu hodnotu. Operace může být definována jedním binárním operátorem, který je jak asociativní tak komutativní. Povolené redukční operace jsou např. součet, součin, nebo bitové operace OR, AND a XOR. Nepovolené redukční operace jsou např. odčítání a dělení. Redukční funkce jsou specifikovány podobně jako funkce jádra s několika doplňujícími omezeními. Redukční funkce mohou mít pouze dva proudové argumenty, jeden vstupní a druhý výstupní označený klíčovým slovem reduce. Oba proudy musí být stejného typu. Ostatní

40 24 KAPITOLA 4. BROOKGPU argumenty nesmí být proudy. Redukční parametr může být jak proud tak skalární hodnota. Počáteční hodnota redukce je definována jako první hodnota vstupního proudu. Definice redukční funkce může vypadat např. takto: reduce void sum(float a<>, reduce float result<>) { result = result + a; } Standardní funkce Uvnitř kernelů lze používat některé užitečné standardní funkce. Jejich neúplný výčet je uveden v tabulce 4.1. Funkce Význam indexof(s) Zjištění indexu právě zpracovávaného elementu proudu s. abs(x) Absolutní hodnota x. cross(u, v) Vektorový součinu vektorů u a v. dot(u, v) Skalární součin vektorů u a v. floor(x) x length(u) Délka vektoru u. normalize(u) Normalizace vektoru u. pow(x, y) x y sqrt(x) x Tabulka 4.1: Standardní funkce 4.4 Začlenění do projektu Většina dostupných ukázkových příkladů je koncipována do jednoho br souboru. Tento soubor obyčejně obsahuje definice vlastních typů, definice kernelů, jejich volání a funkci main. Pomocí překladače BRCC tento soubor přeložíme do souboru cpp, který následně přeložíme klasickým C++ překladačem. Takto získáme spustitelný exe soubor. Toto vyhoví v případě, že píšeme krátký jednoduchý program. V případě, že programujeme rozsáhlejší aplikaci, přestane nám dříve nebo později takovýto koncept vyhovovat. Pro rozsáhlejší aplikace psaných v C++ je vhodnější mít v br souboru pouze definice kernelů a po překladu do cpp souboru je volat z jiných cpp souborů. Aby toto bylo možné, je potřeba vyřešit několik otázek: Otázka: Kde správně definovat vlastní typy (např. Triangle), aby byly vidět jak v br souboru, kde jsou bezpodmínečně nutné pro překlad překladačem BRCC, tak i v ostatních místech projektu, kde budou také používány?

41 4.4. ZAČLENĚNÍ DO PROJEKTU 25 Možné řešení: Provést totožné definice jak v br souboru tak v nějakém hlavičkovém souboru (např. Types.h). Otázka: Kde vzít příslušný hlavičkový soubor, pomocí kterého by se br soubor přeložený do cpp souboru vložil do projektu a zpřístupnila se tak možnost volat kernely? Možné řešení: Příslušný hlavičkový soubor vytvořit ručně. Všechny prototypy kernelů a vše potřebné vykopírujeme z přeloženého br souboru. Otázka: Jak deklarovat proudy v C++, které jsou vstupními parametry volaných kernelů? Deklarace uvedená v části platí v rámci br souboru, který překládá překladač BRCC, ale nikoli v rámci cpp souboru, který překládá už klasický překladač. Řešení: Deklarace proudu o velikosti 10 x 10 vypadá v C++ následovně: #include <brook/brook.hpp> ::brook::stream s = brook::stream::create<float>(10, 10); Naplnění proudu pomocí STL kontejneru by mělo fungovat následovně: #include <brook/brook.hpp> #include <vector> ::brook::stream s = brook::stream::create<float>(10, 10); std::vector<float> v;... s.read(&v[0]); Otázka: Nastavování proměnné prostředí BRT_RUNTIME zmíněné v části je nepraktické. Existuje možnost nastavovat režim běhu programově? Řešení: Programově lze režim běhu na začátku programu nastavit v C++ následovně: #include <brook/brook.hpp> ::brook::initialize("dx9", NULL);

42 26 KAPITOLA 4. BROOKGPU 4.5 Ukázkový příklad Následující ukázkový program demonstruje použití jazyka Brook spolu s jazykem C++. Tento jednoduchý program nedělá nic jiného, než že sečte 100 dvojic čísel a výsledné součty vypíše na konzoli. Kernels.br typedef struct struct_pair { float first; float second; } Pair; kernel void ksumpair(pair pair<>, out float result<>) { result = pair.first + pair.second; } Kernels.cpp //////////////////////////////////////////// // Generated by BRCC v0.1 // BRCC Compiled on: Feb :56:34 ////////////////////////////////////////////... Kernels.h (vykopírováno z Kernels.cpp) #include <brook/brook.hpp> void ksumpair(::brook::stream pair, ::brook::stream result); // Důležité pro definovaný typ Pair namespace brook { template<> inline const StreamType* getstreamtype(pair*) { static const StreamType result[] = { BRTFLOAT, BRTFLOAT, BRTNONE}; return result; } } Types.h typedef struct struct_pair { float first; float second; } Pair;

43 4.5. UKÁZKOVÝ PŘÍKLAD 27 Test.cpp #include <iostream> #include "Types.h" #include "Kernels.h" int main(int argc, char* argv[]) { ::brook::initialize("dx9", NULL); // Inicializace GPU módu // Vstupní a výstupní proud ::brook::stream pair_s = ::brook::stream::create<pair>(10, 10); ::brook::stream result_s = ::brook::stream::create<float>(10, 10); Pair pair[100]; float result[100]; for (int i = 0; i < 100; i++) { pair[i].first = 1.f; pair[i].second = (float)i; } streamread(pair_s, pair); // Inicializace proudu pair_s ksumpair(pair_s, result_s); // Volání kernelu streamwrite(result_s, result); // Stažení výsledků do pole result for (int i = 0; i < 100; i++) { std::cout << result[i] << std::endl; } } return 0;

44 28 KAPITOLA 4. BROOKGPU

45 Kapitola 5 Ray tracing Ray tracing neboli metodu sledování paprsku poprvé publikoval v roce 1980 Turner Whitted [30]. Jedná se o výpočetně velice náročnou metodu počítačové vizualizace, pomocí které lze získat realistické zobrazení (obrázek) trojrozměrného modelu scény. Umožňuje zachycení optických jevů, jako je odraz a lom světla. Je používána např. programy Maya, Blender, nebo POV-Ray. Ray tracing se těší širokému zájmu a představuje významnou oblast počítačové grafiky. V této kapitole bude vysvětlen základní princip této metody. Bohužel není možné, vzhledem k rozsahu práce, zmiňovat veškeré detaily a teorii vztahující se k dané problematice, které by vedly ke kompletnímu osvětlení či snad přímočaré implementaci. Více se lze s metodou seznámit v [6]. Tato kapitola čerpá také z [26]. 5.1 Princip metody Ray tracing je založen na určitém zjednodušení fyzikálního principu šíření světla. Uvažuje se, že se fotony ze světelných zdrojů šíří lineárně a se stejnou intenzitou do všech směrů v podobě paprsků. Světelné zdroje, které splňují tuto vlastnost, se nazývají bodové. Metoda v základní podobě s jinými světelnými zdroji, než bodovými, nepočítá. Paprsky se při zásahu objektů mohou podle optických vlastností jednotlivých objektů dále odrážet, lomit a ovlivňovat osvětlení v dalších místech scény. Trajektorii fotonu procházejícího scénou si lze tedy představit jako lomenou čáru. Metoda vrháním a následném vyhodnocováním příspěvků paprsků zkoumá vlastnosti světla šířícího se scénou a umožňuje provést rendering. Zajímavostí je, že k vrhání paprsků nedochází od světelných zdrojů, ale od pozorovatele. Důvodem je to, že větší část světelných paprsků vyzářených světelným zdrojem se po mnoha odrazech k pozorovateli vůbec nedostane. Mnoho výpočtů tak přijde vniveč. Proto je rozumnější trajektorii světla sledovat v opačném směru Osvětlovací model Při zásahu objektu paprskem je nutné v bodě zásahu vypočítat osvětlení. Řečeno jinak, je potřeba určit, jaká je barva povrchu tělesa pro daný bod. V ray tracingu bývá pro tento účel 29

46 30 KAPITOLA 5. RAY TRACING často používán Phongův osvětlovací model. Jedná se o empirický osvětlovací model, který navrhl v roce 1973 Bui-Tuong Phong. Je navržen s ohledem na věrohodnost osvětlení a rychlost výpočtu. Phongův model rozděluje světlo na povrchu tělesa do tří složek. Na složku ambientní (ambient), difúzní (diffuse) a zrcadlovou (specular). Výsledné osvětlení je dáno součtem těchto složek. Vstupem Phongova osvětlovacího modelu, který vypočte barvu na povrchu tělesa v bodě P je: směr paprsku, který těleso zasáhl v bodě P, souřadnice bodu P, normála tělesa v bodě P, pozice a intenzita bodového světla, koeficienty definující materiálové vlastnosti tělesa. Výstupem je vypočtená barva. Podrobněji je tento model rozebrán v [26] Popis mechanizmu Na začátku celého procesu máme popis 3D scény, který zahrnuje geometrické a materiálové definice objektů, definice pozic a intenzit světelných zdrojů a definici pozice a směru pozorovatele (kamery). Úkolem je nyní získat obraz scény z pohledu pozorovatele. Při výpočtu se používají tři typy paprsků, primární, sekundární a stínové. Primární paprsky jsou vysílány z pozice pozorovatele body vypočítávaného obrazu (pixely) směrem do prostoru scény. Sekundární paprsky jsou vysílány z nejbližšího průsečíku, který vznikl dopadem primárního nebo sekundárního paprsku na nejbližší objekt. Reprezentují stav, kdy se příchozí paprsek na základě optických vlastností objektu odrazil nebo lomil. Sekundární paprsky tedy mohou být dvojího typu, odražené (reflected) nebo lomené (refracted). Stínové paprsky jsou vysílány z bodu, kam dopadl primární nebo sekundární paprsek, směrem ke všem světelným zdrojům. Jejich účelem je zjistit, jestli mezi daným bodem a konkrétním světelným zdrojem není překážka (nějaký objekt). V případě zjištění výskytu překážky je konkrétní světelný zdroj vyřazen z výpočtů osvětlovacího modelu v daném bodě. Každým pixelem obrazu je vržen primární paprsek. Některé z nich zasáhnou objekty, kde se podle jejich materiálu povrchu lomí, odrážejí a pro každý pixel vrací vypočtenou barvu. Nezasáhne-li paprsek žádný objekt, je pro daný pixel nastavena barva pozadí. Podrobněji je celý mechanizmus naznačen na obrázku 5.1. Primární paprsek PR prochází pixelem obrazu směrem do scény. Nejblíže zasáhne poloprůhledný objekt A. Z bodu, který je průsečíkem paprsku PR a objektu A, se vyšlou stínové paprsky ke všem světelným zdrojům pro zjištění, zda-li nejsou zakryté nějakým objektem. Následně se pro tento bod vyhodnotí příspěvky osvětlení od všech nezakrytých světelných zdrojů. V tomto případě se jedná pouze o zdroj L1 1. Dále je z tohoto bodu vržen sekun- 1 Zdroj L2 je částečně zakrytý poloprůhledným objektem A. Světelný paprsek ze zdroje L2 tedy vyhodnocovaný bod neovlivňuje přímo, protože se v objektu A lomí. Tuto situaci neumí ray tracing v základní podobě řešit, a proto ji zanedbává.

47 5.1. PRINCIP METODY 31 Obrázek 5.1: Ray tracing dární paprsek SR1 ve směru odrazu paprsku PR a sekundární paprsek SR2 ve směru lomu paprsku PR. Paprsek SR1 nejblíže zasáhne neprůhledný objekt B. V místě dopadu paprsku SR1 se vyhodnotí osvětlení. Odražený sekundární paprsek SR3 již žádný objekt nezasáhne a sledování je ukončeno. Paprsek SR2 projde poloprůhledným objektem A a v místě, kde ho opustí, se vyhodnotí osvětlení. Dále lomený sekundární paprsek SP4 nezasáhne žádný objekt a sledování je také ukončeno. Výsledná barva pixelu je dána součtem jednotlivých příspěvků osvětlení, barvy odraženého paprsku a barvy lomeného paprsku. Výše uvedené lze popsat následujícím pseudokódem: GetColorBuffer() { for j = 0 to resolution_y-1 for i = 0 to resolution_x-1 { primaryray = CreatePrimaryRay(i, j) color = TraceRay(primaryRay, depth) index = (j * resolution_x + i) * 3; } color_buffer[index] = color.r color_buffer[index+1] = color.g color_buffer[index+2] = color.b

48 32 KAPITOLA 5. RAY TRACING } return color_buffer TraceRay(ray, depth) { (object, thit) = GetNearestObject(ray) // Není-li zasáhnut žádný objekt, vrať barvu pozadí if (thit == infinity) return background_color; color = (0.f, 0.f, 0.f) intr = ray.origin + ray.dir * thit normal = object.getnormal(intr) for each light in lights { shadowray = CreateShadowRay(intr, light.position) } // Není-li mezi průsečíkem a světlem překážka, vypočti osvětlovací model if (!IsShadow(shadowRay)) { color += object.computelightingmodel(intr, ray.dir, normal, light) } if (depth > 0) { // Je-li koeficient zrcadlového odrazu větší než 0, sleduj odražený paprsek if (object.krefl > 0) { reflectedray = object.createreflectedray(intr, ray.dir, normal) color += TraceRay(reflectedRay, depth-1) * object.krefl } } // Je-li koeficient průhlednosti vetší než 0, sleduj lomený paprsek if (object.krefr > 0) { refractedray = object.createrefractedray(intr, ray.dir, normal) color += TraceRay(refractedRay, depth-1) * object.krefr } } return color 5.2 Vlastnosti Ray tracing je globální osvětlovací metoda, která sleduje trajektorii světla od pozorovatele. Je pohledově závislá, což znamená, že počítá osvětlení scény pouze pro konkrétní zadaný směr. Při jakékoliv změně ve scéně, např. při změně pozice pozorovatele, změně pozice světla,

49 5.3. MOŽNOSTI URYCHLENÍ 33 přidání či odebrání objektů, se musí vše znovu přepočítat. Metoda dokáže na povrchu těles věrně zobrazit zrcadlové odrazy jiných těles a lom světla procházejícího průhlednými či poloprůhlednými tělesy. V základní podobě počítá pouze s bodovými zdroji světla, což má za následek, že zobrazuje ostré stíny. 5.3 Možnosti urychlení Hlavním výpočetním problémem je pro každý paprsek nalézt objekt, který paprsek zasáhne a který je zároveň od pozice pozorovatele nejblíže. Máme-li scénu skládající se z objektů a chceme-li vyrenderovat obraz s rozlišením 512 x 512 pixelů, musíme krát procházet a testovat objektů, což je časově velmi náročné. V případě uvažování stínových a sekundárních paprsků je časová náročnost samozřejmě ještě mnohem horší. Zkrátka a dobře, ray tracing řešený hrubou silou je pro velké scény příliš pomalý. Z tohoto důvodu je vynakládáno velké úsilí na hledání nejrůznějších urychlovacích technik, které vedou k významnému urychlení ray tracingu. Tyto techniky lze rozdělit do několika základních skupin [26, 3, 14]: Urychlení výpočtů průsečíků Ray tracing tráví nejvíce času ve fázi, kde se počítají průsečíky paprsek-objekt. Jakákoliv optimalizace této fáze se výrazně kladně odrazí na celkové rychlosti. Optimalizovat lze jak na úrovni samotné průsečíkové funkce, kdy dochází ke zrychlení výpočtů průsečíků paprsekobjekt, tak na úrovni prostorového dělení scény, kdy dochází ke snížení počtu výpočtů průsečíků paprsek-objekt Optimalizace průsečíkové funkce Průsečíkové funkce se dají optimalizovat tak, že před samotným plnohodnotným vyhodnocením možného průsečíku s určitou třídou objektů se provede jednoduchý pre-test, ze kterého je zřejmé, zda-li má smysl dále počítat či nikoliv. Toto je výhodné zejména u složitějších objektů Snížení počtu výpočtů průsečíků Snížení počtu výpočtů průsečíků lze docílit tak, že se scéna s objekty rozdělí do vhodné prostorové struktury a podle počátku a směru paprsku se systematicky testuje pouze určitá podmnožina objektů. Mezi nejpoužívanější prostorové struktury pro urychlení sledování paprsku patří uniformní mřížka, BSP strom, kd-strom a oktalový strom (octree). Použití některé z těchto akceleračních struktur patří k nejefektnějším způsobům jak urychlit ray tracing.

50 34 KAPITOLA 5. RAY TRACING Snížení počtu paprsků Řízení hloubky rekurze Ve scénách, ve kterých je převážná většina těles matná, nemá velké opodstatnění vypočítávat příspěvky sekundárních paprsků až do pevně stanovené maximální hloubky, protože by to stejně mělo na výsledný obraz zanedbatelný vliv. Výhodné je pro sekundární paprsky zavést určitý práh, při kterém je sledování předčasně zastaveno. Toto však není výhodné pro scény, které obsahují velké množství průhledných těles nebo těles se zrcadlovým povrchem Adaptivní antialiasing Ray tracing v základním tvaru vrhá každým pixelem pouze jeden primární paprsek. Pro zvýšení kvality výsledného obrazu je možno každým pixelem vrhat více primárních paprsků. Výsledná barva pixelu je pak dána jako průměr z příspěvků jednotlivých paprsků. Daní za to je značné zpomalení celého výpočtu. Proto je výhodné více paprsků vrhat pouze těmi pixely, u kterých to má na kvalitu výsledného obrazu zásadní vliv a náročnost výpočtu tak snížit. Technika, která toto bere v potaz, se nazývá adaptivní antialiasing. Adaptivní antialiasing lze rozdělit do několika fází. V první fázi se klasicky vyrenderuje obrázek vržením jednoho primárního paprsku každým pixelem. V další fázi se pro každý pixel vyrenderovaného obrázku spočítá jeho luminance a také luminance jeho nejbližšího okolí. Pokud se luminance pixelu od průměrné luminance okolí liší nějak výrazně, tak se vrhne tímto pixelem více paprsků a přepočítá jeho barva. Luminanci pixelu, jehož barva je (R, G, B), lze vypočítat podle empirického vztahu: lum = 0.299R G B Sledování více paprsků naráz Ray tracing má tu vlastnost, že barva každého pixelu je vypočítávána nezávisle na ostatních pixelech. Proto ho lze poměrně snadno dekomponovat na paralelní zpracování. Teoreticky můžeme každý pixel renderovaného obrazu nechat vypočítat samostatným procesorem.

51 Kapitola 6 Analýza a návrh řešení Praktickým úkolem této práce je implementace metody ray tracing s využitím CPU a GPU. V této kapitole budou nejprve zmíněny předchozí práce věnující se využití GPU v ray tracingu, dále bude diskutován výběr vhodné akcelerační struktury a nakonec bude uvedena volba implementačního prostředí spolu s popisem návrhu řešení. 6.1 Ray tracing s využitím GPU Zdroje [24, 22, 14] mezi prvními pokusy o využití GPU v ray tracingu uvádí práci Charra a kolektivu z roku 2002, ve kterém představil The Ray Engine [7]. Jedná se o řešení, které GPU využívá pouze k výpočtům průsečíků paprsek-trojúhelník, ostatní je počítáno klasicky na CPU. Slabinou tohoto přístupu je vysoká komunikace mezi CPU a GPU. Snížení CPU/GPU komunikace dosáhl Tim Purcell přenesením většiny výpočtů ray tracingu na GPU [25]. Jedná se o první návrh ray traceru, který je z velké části počítán v GPU. Na fragment procesor GPU je pohlíženo jako na proudový procesor a každá úloha jako je generování paprsků, procházení akcelerační strukturou, výpočet průsečíků paprsků s trojúhelníky, nebo výpočet osvětlení, je implementována jako samostatný kernel (fragment program). Jako akcelerační strukturu Purcell použil trojrozměrnou uniformní mřížku předpočítanou na CPU. Pro urychlení ray tracingu na CPU je kd-strom obecně považován za lepší akcelerační strukturu než uniformní mřížka. Tim Foley se ho proto pokusil použít místo uniformní mřížky [9]. Absenci zásobníku na GPU vyřešil použitím upraveného standardního traverzačního algoritmu, který nepoužívá zásobníkové operace. Algoritmus místo zpracování uzlu umístěného na zásobníku provádí tzv. restart, kdy pokračuje znova od kořene stromu s aktualizovanými parametry. Nevýhoda tohoto přístupu tedy spočívá v navýšení traverzačních kroků oproti standardnímu algoritmu. Stefan Popov představil upravenou verzi kd-stromu, kde každý list stromu obsahuje ukazatele na sousedící listy [24]. Při procházení nevyžaduje tato upravená verze kd-stromu zásobník. Nevýhodou jsou však zvýšené paměťové nároky na uložení stromu. 35

52 36 KAPITOLA 6. ANALÝZA A NÁVRH ŘEŠENÍ 6.2 Akcelerační struktura V předchozí kapitole bylo mimo jiné řečeno, že ray tracing řešený hrubou silou je pro velké scény příliš pomalý. Jedním z návrhových problémů je tedy volba vhodné akcelerační struktury. Odborných článků a prací na toto téma existuje poměrně mnoho a není jednoduché jednoznačně říci, která volba je nejvhodnější. Je nutné si uvědomit, že se jedná o netriviální problematiku, která vyžaduje určitou praxi a že teoretická stránka věci je jedna věc a praktická stránka věci věc druhá. Řečeno jinak, dobrá myšlenka či sebedůmyslnější algoritmus je k ničemu, není-li podložen kvalitní implementací. Můžeme tak zvolením papírově slabšího algoritmu s dobrou implementací docílit lepších výsledků, než použitím papírově lepšího algoritmu s horší implementací, která může pramenit z nedostatečných programátorských zkušeností nebo neúplného pochopení daného algoritmu. Obsáhlým srovnáním akceleračních struktur pro metody na bázi vrhání paprsku se ve své dizertační práci zabýval Vlastimil Havran [13]. Z tohoto srovnání vyšel nejlépe kd-strom. Z předchozí části víme, že kd-strom lze realizovat na GPU, a proto se dále zaměříme právě na tuto akcelerační strukturu Konstrukce kd-stromu Kd-strom je binární strom určený k dělení libovolného k-rozměrného prostoru. K dělení dochází pomocí dělících rovin, které jsou vždy kolmé na některou ze souřadnicových os, přičemž osy, podle kterých se dělí, se zpravidla střídají. Modelově si to můžeme na trojrozměrném prostoru představit tak, že máme kvádr (prostor) a ten rozřízneme na dvě části tak, že získáme dva menší kvádry (levý a pravý podprostor). Tyto dva menší kvádry vezmeme a z jiných stran je opět rozřízneme, čímž získáme čtyři kvádry. Takto bychom mohli pokračovat dále. Vnitřní uzly kd-stromu obsahují souřadnicovou osu, podle které se dělí prostor, pozici dělící roviny a odkazy na levého a pravého potomka. Listy kd-stromu obsahují seznam objektů, které spadají do podprostoru, který daný list reprezentuje. Při konstrukci kd-stromu je potřeba nějakým způsobem určovat, v jakých místech jednotlivé prostory dělit. Naivním řešením je daný prostor vždy rozdělit přesně v polovině. Takto stavěný kd-strom však není příliš efektivní datovou strukturou. Důvodem je, že při rozdělení prostoru dělící rovinou spadají objekty, které dělící rovina protne, jak do levého tak do pravého podprostoru. V případě, že je dělící rovina umístěna nevhodně, je pak při procházení nutné testovat zbytečně více objektů než v případě, že by byla umístěna efektivněji (protla méně objektů). Další příčinou neefektivnosti tohoto neuváženého určování pozice dělící roviny mohou být případy, kdy jeden podprostor obsahuje nepoměrně více objektů než druhý. V extrémním případě jeden podprostor obsahuje všechny objekty a druhý žádné. Rozumnější je pozici dělící roviny určovat na základě vhodně navržené cenové funkce. Podle této funkce se pro několik vytipovaných pozic vypočte cena a vybere se pozice s nejlepší cenou. Cenovou funkci pro efektivnější konstrukci kd-stromu můžeme podle [16] definovat následovně:

53 6.2. AKCELERAČNÍ STRUKTURA 37 kde: cost(x) = C L (x)sa L (v, x)/sa(v) + C R (x)sa R (v, x)/sa(v) SA(v) je povrch děleného prostoru, SA L (v, x) je povrch levého podprostoru v závislosti na pozici dělící roviny, SA R (v, x) je povrch pravého podprostoru v závislosti na pozici dělící roviny, C L (x) je cena levého podprostoru v závislosti na pozici dělící roviny, C R (x) je cena pravého podprostoru v závislosti na pozici dělící roviny. Poměry SA L (v, x)/sa(v) a SA R (v, x)/sa(v) reprezentují pravděpodobnost, s jakou může být levý respektive pravý prostor zasažen paprskem. Ceny C L (x) a C R (x) zohledňují míru výskytu objektů, které protne dělící rovina. Za C L (x) a C R (x) můžeme přímo dosadit počet objektů spadající do levého respektive pravého podprostoru. Charakter průběhu takto navržené cenové funkce je na obrázku 6.1. Nejlepším kandidátem na umístění dělící roviny je pozice, u které vychází nejnižší cena. Obrázek 6.1: Závislost ceny na pozici dělící roviny Výpočet cenové funkce Pro výpočet cenové funkce potřebujeme znát: 1. Kandidáty na umístění dělící roviny, pro které chceme počítat cenu. 2. Kolik objektů spadá do levého podprostoru. 3. Kolik objektů spadá do pravého podprostoru. Stanovení bodů 2 a 3 je drahé. Existují dva základní přístupy pro výpočet cenové funkce. Oba předpokládají, že každý objekt je ohraničený obálkou AABB a že chceme stanovit cenu pro několik vytipovaných pozic dělící roviny. Hlavní rozdíl, v čem se oba přístupy liší, je, že jeden obálky řadí a druhý ne [16, 23].

54 38 KAPITOLA 6. ANALÝZA A NÁVRH ŘEŠENÍ Přístup s řazením V první fázi jsou obálky seřazeny podle dělící osy. V další fázi se cenová funkce vypočte pro požadované pozice pouze jedním průchodem přes seřazené obálky. To lze pro celý kd-strom podle [16] realizovat v čase O(n log 2 n). Dále je odkazováno na [28], kde je díky uchování a znovupoužití výsledků řazení dosaženo času O(n log n). Přístup bez řazení Mějme prostor s k objekty a n různých pozic umístění dělící roviny, pro které chceme vypočítat cenovou funkci. Tyto pozice rovnoměrně rozdělí prostor na n + 1 úseků (viz obr. 6.2). Každému úseku je přiřazena dvojice čítačů C min, C max. Čítač C min Obrázek 6.2: Zjištění počtu objektů nalevo a napravo od dělící roviny počítá počet minim obálek, čítač C max počet maxim obálek, které spadají do daného úseku. Tyto výskyty se napočítají jedním průchodem přes všechny objekty. V další fázi se počty objektů nalevo od dělících rovin vypočítají následujícím systémem: N L1 = C min1, N L2 = N L1 +C min2, N L3 = N L2 +C min3, N Ln = N Ln 1 +C minn a počty objektů napravo od dělících rovin: N R1 = k C min1, N R2 = N R1 C max2, N R3 = N R2 C max3, N Rn = N Rn 1 + C maxn Procházení kd-stromu Pro procházení kd-stromu, který je v ray tracingu použit jako akcelerační struktura, existuje několik základních algoritmů. Souhrnně jsou popsány v [15]. Jejich účelem je podél paprsku procházet minimální počet podprostorů vymezených dělícími rovinami a vrátit nejbližší zasažený objekt. Na obrázku 6.3 je prostor scény rozdělen pomocí kd-stromu na tři

55 6.3. NÁVRH ŘEŠENÍ 39 podprostory, A, B a C. Na na základě počátku a směru paprsku jsou nejprve otestovány Obrázek 6.3: Procházení kd-stromu všechny objekty v podprostoru A. Tam však není zasažen žádný objekt, proto se pokračuje testováním všech objektů v podprostoru B, kde už k zásahu objektu dojde. Objekty v podprostoru C nejsou pro vyznačený paprsek vůbec testovány. V případě, že by v podprostoru A byl zasažen nějaký objekt, došlo by pro tento paprsek k předčasnému ukončení procházení. Vstupem algoritmu pro procházení kd-stromu je: počátek a směr paprsku, parametr scenemin, který představuje vzdálenost mezi počátkem paprsku a místem, kde vchází do prostoru scény, parametr scenemax, který představuje vzdálenost mezi počátkem paprsku a místem, kde opouští prostor scény. Výstupem algoritmu je zasažený objekt a vzdálenost v jaké byl zasažen. V případě, že nebyl zasažen žádný objekt, je vzdálenost zasažení nastavena na nekonečno. 6.3 Návrh řešení Specifikace cíle Nejprve je nutné specifikovat, jak by výsledná aplikace měla vypadat. Jsou dvě hlavní otázky, které je potřeba zodpovědět. První otázka je, jestli aplikaci navrhovat jako konzolovou nebo jako aplikaci s grafickým uživatelským rozhraním (GUI). Návrhem aplikace jako konzolové si ulehčíme práci na úkor toho, že výsledná aplikace bude z uživatelského hlediska méně přívětivá. Znamenalo by to veškeré ovládání a nastavení rozvrhnout do příkazů (přepínačů), které by se zadávaly přes příkazovou řádku. Spouštění s určitou předdefinovanou konfigurací se dá řešit pomocí dávkových souborů (batch files), což by pro náš účel asi postačovalo.

56 40 KAPITOLA 6. ANALÝZA A NÁVRH ŘEŠENÍ Problému s GUI se však úplně nevyhneme, protože potřebujeme nějakým způsobem zobrazovat výstup, což je v našem případě obrázek. Přestože bychom to mohli elegantně řešit např. pomocí knihovny GLUT, bude serioznější aplikaci rovnou navrhovat jako aplikaci s plnohodnotným GUI. Druhá otázka je, jestli navrhovat dvě oddělené aplikace, kde by jedna realizovala ray tracing bez využití GPU a druhá ray tracingu s využitím GPU nebo navrhnout pouze jednu univerzální aplikaci, která by byla schopna pracovat ve dvou režimech. Zde je praktičtější dát přednost jedné univerzální aplikaci. Minimalizujeme tak psaní identického kódu (hlavní okno, dialogová okna,...) a zefektivníme udržování projektu. Dále můžeme více využít výhod objektového programování jako je dědičnost a polymorfizmus. Naším cílem tedy bude aplikace s těmito základními rysy: plnohodnotné grafické uživatelské rozhraní, realizace metody ray tracing bez využití GPU (pouze CPU), realizace metody ray tracing s využitím GPU Volba implementačního prostředí Aplikace z oblasti počítačové grafiky, u kterých je kladen důraz na rychlost, se běžně píší v jazyce C/C++. Jazyk Brook je nadstavbou ANSI C, čili by nic nemělo bránit zvolit C++ jako hlavní programovací jazyk. Pro tvorbu grafického uživatelského rozhraní ve spojení s jazykem C++ se nejvíce používají knihovny Qt a MFC (Microsoft Foundation Classes). Knihovna Qt je jednodušší a intuitivnější na použití než MFC a lze ji použít pod operačním systémem Windows i Linux. MFC lze použít pouze pod operačním systémem Windows. Ve prospěch knihovny MFC však hovoří skutečnost, že za ní stojí společnost Microsoft, která je výrobcem operačního systému Windows a MFC tak doplňuje o nejmodernější prvky tohoto světově nejrozšířenějšího operačního systému. Další, z praktického hlediska mnohem užitečnější, výhodou je, že je tato knihovna integrována do profesionálního vývojového prostředí Microsoft Visual Studio, které nabízí pokročilé debugovací nástroje a zjednodušuje vývoj rozsáhlejších projektů. Při návrhu grafického uživatelského rozhraní proto dáme přednost knihovně MFC. Jako vývojové prostředí zvolíme Microsoft Visual Studio Koncepční návrh Aplikaci budeme koncipovat tak, jak je zjednodušeně znázorněno na obrázku 6.4. Je rozdělena na dvě části, část nevyužívající GPU (CPU část) a část využívající GPU pro výpočty (GPU část). Podle toho, jestli je aplikace nastavena v módu CPU nebo GPU se data popisující trojrozměrnou scénu načítají ze souboru do příslušných datových struktur. V GPU módu bude aplikace při počítání ray tracingu využívat GPU prostřednictvím BRT (Brook Run- Time) a grafického rozhraní DirectX nebo OpenGL. Color buffer, který je výsledkem ray tracigu, obsahuje vypočtené barvy pixelů a je již pouze vykreslen do okna pomocí OpenGL.

57 6.3. NÁVRH ŘEŠENÍ 41 Obrázek 6.4: Návrh aplikace CPU část Datové struktuty Pro CPU (stejně tak i pro GPU) část budeme jako primitiva, ze kterých jsou složeny trojrozměrné scény, uvažovat trojúhelníky a koule. Zde je potřeba přihlédnout k omezení, které nastanou při návrhu GPU části. Pro CPU můžeme např. navrhnout abstraktní třídu Object a z ní odvodit třídy Triangle a Sphere (případně i další), jak ukazuje následující příklad: class Object { public: // materiál Material material; // obálka AABB Box box; virtual Vector3f GetNormal(Vector3f& point) = 0; virtual bool Intersect(Ray& ray) = 0; // Výpočet Phongova osvětlovacího modelu inline Color ComputePhong(Vector3f& intr, Vector3f& dir, Vector3f& normal,

58 42 KAPITOLA 6. ANALÝZA A NÁVRH ŘEŠENÍ { } Light& light)... };... class Triangle : public Object { public: // vrcholy Vector3f v1, v2, v3; };... Pro GPU část však budeme nuceni výše uvedené řešit nějak takto: typedef struct struct_triangle { // vrcholy float3 v1; float3 v2; float3 v3; // materiál float3 c; float3 m1; float2 m2; } Triangle; protože jsme implementací Brooku omezeni pouze na typy float, float2, float3, float4, nebo kombinace těchto typů ve formě struktury (a to ještě dle ANSI C) viz část Nabízí se tedy otázka, jestli omezení GPU nevzít v potaz a pro celou aplikaci nenavrhnout jednotné datové struktury. Z programátorského hlediska by to bylo čistší. Zbytečně by se nepsalo dvakrát totéž, zjednodušil by se zdrojový kód a výsledná aplikace by zabírala méně místa v paměti. Uvědomíme-li si však, pro jaký účel aplikaci navrhujeme, jistě očekáváme, že v případě, že aplikace nevyužívá GPU, co nejlépe využívá CPU. Z toho vyplývá, že by se CPU část měla vyznačovat nekompromisní implementací, a proto pro každou část aplikace navrhneme datové struktury zvlášť a dodržíme koncept z obrázku Engine Při implementaci se budeme držet pseudokódu uvedeného v předchozí kapitole. Všimněme si výpočtu normály v těle metody TraceRay, který je proveden pouze jednou. Můžeme také vzít v úvahu, že trojúhelník je plocha a že směr normály bude v libovolném bodě vždy stejný, čili ji pro každý trojúhelník můžeme předpočítat již během načítání dat. Metoda GetNormal pak bude pro trojúhelník vracet předpočítanou normálu a nebude muset nic počítat. Toto samozřejmě nezle provést pro kouli.

59 6.3. NÁVRH ŘEŠENÍ Akcelerační struktura Jako akcelerační strukturu zvolíme kd-strom. Budovat ho budeme jako spojový seznam. Během stavby nebudeme dále dělit uzly, které obsahují málo objektů (např. méně než 4). Pro určování vhodné pozice dělící roviny použijeme algoritmus pro výpočet cenové funkce bez nutnosti řazení podrobně rozebraný v části Orientace dělících rovin budeme pravidelně střídat. Alternativní řešení je orientaci dělící roviny odvozovat podle rozměrů děleného prostoru - orientaci zvolíme podle nejdelšího rozměru. Pro procházení kd-stromu implementujeme standardní algoritmus s využitím zásobníku a algoritmus Kd-restart, který zásobník nevyužívá [15]. Požadované vstupní parametry scene- Min a scenemax získáme pomocí algoritmu popsaném v [31]. Pro malé scény (zhruba do 100 objektů) nebudeme kd-strom stavět, protože by to nebylo ku prospěchu a necháme pracovat hrubou sílu. Optimální maximální hloubku stromu přibližně stanovíme podle empirického vzorce: k 1 +k 2 log(pocet_objektu), kde k 1 =2 a k 2 = GPU část Datové struktuty Jak už bylo zmíněno, jsme při návrhu datových struktur pro GPU část limitováni. Můžeme používat pouze typy float, float2, float3 a float4, nebo kombinace těchto typů ve formě struktury. Co je možná ještě nepříjemnější, je skutečnost, že by struktury měly být co nejúspornější, protože kernely dokáží pracovat se vstupními parametry pouze do určité velikosti. Dle oficiálního diskuzního fóra by do kernelu mělo vstupovat ve strukturách maximálně 16 floatů bez rozdílu, jestli se jedná o obyčejný float nebo např. float4. V případě, že toto omezení překročíme, překladač BRCC zahlásí chybu typu: error C5102: input semantic attribute "TEXUNIT" has too big of a numeric index (16) Navrhneme-li např. tři struktury, kde se každá bude skládat ze 6 floatů a dále napíšeme kernel, který bude mít tři proudy těchto typů jako vstupní parametry, překladač nám odmítne zdrojový kód přeložit. Řešením je zmenšit některé struktury nebo kernel rozdělit na dva kernely s menším počtem vstupních parametrů. Je zřejmé, že když si navrhneme zbytečně velké struktury, že si zaděláme na problémy. Proto se budeme snažit, aby struktury obsahovaly pouze nezbytné a byly tak co nejúspornější Engine Nové možnosti Jazyk Brook nám nabízí nové možnosti, díky kterým můžeme prostřednictvím GPU zrychlit některé výpočty. K dispozici máme proudy, na které můžeme nahlížet jako na matice, spolu s kernely, které je dokáží paralelně zpracovat. Toho se při návrhu budeme snažit maximálně využít. Operátory streamread a streamwrite, které pro nás znamenají komunikaci CPU/GPU, budeme považovat za drahé a jejich použití se budeme snažit omezit na minimum. Vycházet budeme z algoritmu z předchozí kapitoly, který modifikujeme následovně:

60 44 KAPITOLA 6. ANALÝZA A NÁVRH ŘEŠENÍ GetColorBuffer() { InitTriStream() InitSphStream() ray_s = kcalcprimaryrays(from, p, u, v) color_s = TraceRay(ray_s, depth) streamwrite(color_s, color) for i = 0 to resolution_x*resolution_y-1 { color_buffer[3*i] = color[i].x; color_buffer[3*i+1] = color[i].y; color_buffer[3*i+2] = color[i].z; } } return color_buffer Funkce InitTriStream převede pole s trojúhelníky do dvourozměrného proudu 1 tri_s. Potřebný rozměr proudu získáme tak, že odmocníme původní velikost pole a zaokrouhlíme nahoru. Přebytečné místo vyplníme nulami. Analogický význam má funkce InitSphStream pro koule. Kernel kcalcprimaryrays vypočte pro každý pixel obrazu primární paprsek a všechny je uloží do proudu ray_s, který rozměrově odpovídá renderovanému obrázku. Funkce TraceRay zahájí paralelní sledování všech paprsků a vrátí proud color_s s vypočtenými barvami pixelů. Tyto výsledky jsou staženy do pole color a následně převedeny do formátu vhodného pro vykreslení. TraceRay(ray_s, depth, color_s) { MAKE_MASK(ray_s) hit_s = kinithit() for i = 0 to < trisizesqrt-1 for j = 0 to trisizesqrt-1 { hit_s = kintersecttriangle(ray_s, hit_s, float2(i, j), tri_s) } for i = 0 to sphsizesqrt-1 for j = 0 to sphsizesqrt-1 { hit_s = kintersectsphere(ray_s, hit_s, float2(i, j), sph_s) } info_s = ksetshadinginfo(ray_s, hit_s, tri_s, sph_s) 1 I dále v této části budeme proudem rozumět dvourozměrný proud.

61 6.3. NÁVRH ŘEŠENÍ 45 for k = 0 to lights.size()-1 { c_s = kcomputelightingmodel(ray_s, info_s, lights[k].position, lights[k].intensity, bgcolor) shadowray_s = kcalcshadowrays(ray_s, hit_s, lights[k].position) MAKE_MASK(shadowRay_s) for i = 0 to trisizesqrt-1 for j = 0 to trisizesqrt-1 { c_s = ktrisetshadow(shadowray_s, c_s, float2(i,j), tri_s) } for i = 0 to sphsizesqrt-1 for j = 0 to sphsizesqrt-1 { c_s = ksphsetshadow(shadowray_s, c_s, float2(i,j), sph_s) } MAKE_MASK(ray_s) } color_s = kaddcolor(color_s, c_s) if (depth > 0) { secray_s = kcalcreflectedrays(ray_s, info_s) c_s = TraceRay(secRay_s, depth-1) color_s = kaddcolorrefl(color_s, c_s, info_s) } secray_s = kcalcrefractedrays(ray_s, info_s) c_s = TraceRay(secRay_s, depth-1) color_s = kaddcolorrefr(color_s, c_s, info_s) } return color_s Kernel kintersecttriangle (analogicky kintersectsphere) provádí test na průsečík mezi jedním trojúhelníkem a všemi paprsky. Jeho vstupem je proud s paprsky ray_s, proud se starými zásahy hit_s, index do proudu s trojúhelníky tri_s a samotný proud tri_s. Jeho výstupem je proud hit_s s aktualizovanými zásahy. hit_s potřebuje udržovat informace: co bylo nejblíže zasaženo (trojúhelník, koule nebo nic), index do příslušného proudu tri_s nebo sph_s a vzdálenost zasažení. Při implementaci si tedy vystačíme s proudem o float4 prvcích. Kernel ksetshadinginfo dle hit_s nastaví příslušné informace potřebné pro výpočet osvětlení. Vstupní parametr ray_s je nutný pouze pro výpočet normály koule (v případě, že je zasažena nejblíže). K výpočtu osvětlení slouží kernel kcomputelightingmodel. Kernel ktrisetshadow (analogicky ksphsetshadow) nastaví příslušné barvy na stíny v případě de-

62 46 KAPITOLA 6. ANALÝZA A NÁVRH ŘEŠENÍ tekování překážky. Kernel kaddcolor pak připočítá proud dílčích barev c_s k výslednému proudu barev color_s. V některých případech potřebujeme na začátku kernelu vyhodnotit podmínku, jestli se má pro daný element proudu provést tělo či nikoliv. V případě zjištění, že se tělo provádět nemá, na výstup zapíšeme původní nebo nějakou předem určenou hodnotu. Příkladem můžou být sekundární paprsky. V proudu jsou vygenerovány jen pro některé elementy (odrazí/lomí se pouze od některých zasažených objektů). V kernelu pro zjišťování průsečíku pak přirozeně nemá smysl se nevygenerovanými paprsky zabývat a na výstup můžeme rovnou zapsat, že nedošlo k zásahu. V konečném důsledku, voláme-li kernel pro zjišťování průsečíků opakovaně, dochází k neefektivnímu vytěžování GPU kvůli zbytečným přepisům, které jsou v rámci daného kernelu obdobně drahé, jako plnohodnotné výpočty. Z tohoto důvodu jsme v algoritmu zařadili výpočetní masku. Úkolem výpočetní masky je rozhodnout, které elementy proudu mají být v kernelech počítány a které přeskočeny (nepočítány) Akcelerační struktura Jako akcelerační strukturu zvolíme, stejně jako v CPU části, kd-strom. Základní algoritmus ray tracingu se nám podařilo namapovat na proudový programovací model relativně snadno. V případě kd-stromu to však bude složitější. Obrázek 6.5: Kd-strom reprezentovaný polem

63 6.3. NÁVRH ŘEŠENÍ 47 Konstrukce V CPU části jsme kd-strom budovali jako spojový seznam, což je intuitivní přístup. Zde ho však potřebujeme mít reprezentovaný v proudech, abychom nad ním mohli používat kernely. Proud umíme naplnit pomocí obyčejného pole a operátoru streamread. Kd-strom proto budeme budovat jako pole, ve kterém se vnitřní uzly na potomky a listy na objekty odkazují pomocí indexů. Obrázek 6.5 ukazuje takovýto přístup na kd-stromu o hloubce 1. Všimněme si trojúhelníku s indexem 4, který je obsažen v obou listech. Odpovídá to situaci, kdy je trojúhelník protnut dělící rovinou o tudíž spadá jak do levého tak do pravého podprostoru. Při implementaci můžeme pro kd-strom použít obyčejné dynamické pole, protože máme předem stanovenou maximální hloubku stromu nebo ji dokážeme odvodit z celkového počtu objektů, což nám stačí ke stanovení potřebné velikosti pole. V listech pro pole s indexy budeme muset zvolit nějaký vhodný kontejner, protože jejich maximální velikost nezle předem stanovit. Takto reprezentovaný kd-strom jsme už schopni převést do proudové reprezentace, jak ukazuje obrázek 6.6. Jednorozměrná pole převedeme do dvourozměrných proudů, Obrázek 6.6: Kd-strom reprezentovaný proudy abychom byly schopni pojmout co největší stromy. Uzly kd-stromu obsahují parametry a/ct a sp/cs, které mají dvojí význam podle toho, jestli se jedná o vnitřní uzel nebo list. Ve vnitřním uzlu a/ct vyjadřuje osu, podle které se dělí prostor a sp/cs vyjadřuje pozici umístění dělící roviny. V listu a/ct vyjadřuje počet trojúhelníků v seznamu a sp/cs počet koulí v seznamu. Vnitřní uzly se odkazují na potomky, listy na první pozici odpovídajícího seznamu s indexy trojúhelníků a seznamu s indexy koulí. Jestli se jedná o vnitřní uzel nebo list poznáme podle znaménka parametru a/ct. Záporný a/ct znamená vnitřní uzel, kladný list. Při implementaci nám tedy pro uzel postačí následující struktura: typedef struct struct_kd_node { float2 param; // x - a/ct, y - sp/cs float2 lindex; float2 rindex; } KdNode;

64 48 KAPITOLA 6. ANALÝZA A NÁVRH ŘEŠENÍ Procházeni V [9] je ukázána dekompozice algoritmu Kd-restart nevyužívajícího zásobníkové operace [15], která ho umožňuje namapovat na proudový programovací model. Na základě toho jsme schopni navrhnout pro procházení výše uvedeného kd-stromu následující algoritmus, který reflektuje možnosti jazyka Brook: GetNearestObjects(ray_s) { INIT_MASK INIT_QUERY end = resolution_x * resolution_y (state_s, stmax_s) = kkdinitialize(ray_s, sceneboundsmin, sceneboundsmax) while (1) { while (1) { (state_s, leaf_result_s) = kkdfindleaf(ray_s, state_s, tree_s) } MAKE_MASK(result_s, leaf_result_s) if (query.count() == end) break MAKE_MASK(result_s) order = 0.f init_state_s = kkdtriinitsearchleaf(state_s, tree_s) while (1) { index = float2(order, triindicessize) (hit_s, tri_result_s) = kkdintersecttriangle(init_state_s, ray_s, hit_s, index, triindices_s, triangles_s) MAKE_MASK(result_s, tri_result_s) if (query.count() == end) break } order += 1.f MAKE_MASK(result_s) (state_s, result_s) = kkdcontinue(hit_s, state_s, stmax_s) } MAKE_MASK(result_s) if (query.count() == end) break } return hit_s

65 6.3. NÁVRH ŘEŠENÍ 49 Pro zpřehlednění výkladu nyní uvažujeme jako podporovaná primitiva pouze trojúhelníky. Kernel kkdinitialize slouží k výpočtu parametrů scenemin a scenemax dle [31]. Jeho vstupem je proud paprsků spolu s minimálním a maximálním okrajem obálky, která vymezuje prostor scény. Vypočtené parametry jsou uloženy do proudu state_s, ve kterém má každý element navíc vyčleněny dvě položky pro souřadnice uzlů v kd-stromu (tree_s). Proud state_s tedy deklarujeme jako proud floa4 hodnot. Parametry scenemax jsou navíc uloženy do proudu stmax_s, aby byla jejich hodnota zachována po celou dobu procházení. Mohli bychom je uložit přímo do proudu state_s jako další položku, která se nebude přepisovat, ale znamenalo by to už nadefinování vlastního typu, protože typ float5 není standardně k dispozici. Kernel kkdfindleaf slouží k nalezení listů v kd-stromu. Vnitřně plní následující funkci: if (!node.isleaf()) { a = node.axis tsplit = (node.splitposition - ray.origin[a]) / ray.direction[a] (near, far) = order(ray.direction[a], node.left, node.right) if (tsplit >= tmax tsplit < 0) node = near else if (tsplit <= tmin) node = far else { node = near tmax = tsplit } } result = 0 // list ještě nenalezen, přejdi do další iterace result = 1 // list nalezen Při úplně první iteraci platí tmin = scenemin, tmax = scenemax a také node = root (element [0,0] v tree_s). Kernel kkdtriinitsearchleaf uloží do proudu init_state_s indexy prvních pozic v seznamech indexů trojúhelníků (triindices_s) a také celkové počty trojúhelníků pro dané listy. Kernel kkdintersecttriangle pak na základě init_state_s postupně otestuje všechny trojúhelníky obsažené v seznamech jednotlivých listů. Index [x,y] následující pozice v seznamech indexů lze vypočítat uvnitř kernelu kkdintersecttriangle podle následujícího vztahu: i = floor((sy + order) / size) x = sx + i y = sy + order - i * size kde size je rozměr proudu triindices_s, order pořadí trojúhelníku a sx, sy souřadnice první pozice v seznamu. V kernelu kkdcontinue se rozhoduje, zda-li pokračovat dále v procházení či nikoliv. Vnitřně plní následující funkci: if (hit >= tmax && tmax < scenemax)

66 50 KAPITOLA 6. ANALÝZA A NÁVRH ŘEŠENÍ { tmin = tmax tmax = scenemax node = root result = 0 // pokračuj dále } else { result = 1 // již nepokračuj } Ve výše uvedeném algoritmu nepoužíváme výpočetní masku pouze na určení elementů, které se nemají počítat, ale také pro určení, kdy má dojít k ukončení iterací. Můžeme se totiž dotazovat, kolik elementů výpočetní maska blokuje a v případě, že jsou blokovány všechny elementy, je zřejmé, že nemá smysl pokračovat v další iteraci. Nebo se můžeme naopak dotazovat, kolik daný kernel provedl zápisů a v případě, že neprovedl žádný, opět není důvod dále pokračovat. V případě, že bychom nepoužívaly výpočetní masku, neměly bychom se nač dotazovat, jelikož by kernel prováděl zápis vždy pro každý element proudu. Mohli bychom sice použít paralelní redukci pro zjišťování, kolik elementů proudu je dokončených, ale za cenu výrazného zpomalení celého algoritmu.

67 Kapitola 7 Realizace Tato kapitola se věnuje popisu implementace aplikace, která je výsledkem praktické části této práce. Podrobný popis aplikace z uživatelského hlediska je uveden v příloze B. 7.1 Popis projektu Formát scén Pro načítání scén je podporován zjednodušený formát NFF a formát VIEW/TRI. Formát NFF (Neutral File Format) [11] obsahuje materiálové definice objektů a je vhodný pro testování odražených a lomených paprsků. Formát VIEW/TRI neobsahuje materiálové definice objektů a je vhodný zejména pro testování na velkých datech. Vysvětlivky: tučně - klíčové slovo f - reálné číslo d - přirozené číslo Formát NFF # text řádkový komentář b f f f barva pozadí v definice kamery from f f f pozice kamery at f f f pozice středu obrázku up f f f vektor definující směr nahoru angle f úhel pohledu ve stupních hither f parametr pro vzdálenost roviny promítání od pozice kamery 1 resolution d d rozlišení obrázku v pixelech 2 51

68 52 KAPITOLA 7. REALIZACE l f f f f f f f f f f f f f f f s f f f f definice světla pozice intenzita definice materiálu tělesa barevná složka R barevná složka G barevná složka B difúzní složka K d spekulární složka K s koeficient Shine vyjadřující velikost a ostrost odlesku na povrchu tělesa koeficient T vyjadřující míru příspěvku lomeného paprsku index lomu definice koule střed poloměr p definice polygonu d počet vrcholů, d = {3, 4} f f f souřadnice 1. vrcholu f f f souřadnice 2. vrcholu Formát VIEW/TRI /* VIEW */ -vp f f f -vi f f f -vu f f f -vl f f f pozice kamery pozice středu obrázku vektor definující směr nahoru pozice světla nazev_souboru.tri název souboru s definicemi trojúhelníků 3 /* TRI */ d TRIANGLES počet trojúhelníků 1 Parser tento údaj očekává, ale ignoruje ho a používá implicitně hodnotu 1. 2 Parser tento údaj očekává, ale ignoruje ho a používá výchozí rozlišení nastavené uživatelem. 3 Parser tento údaj očekává na konci souboru.

69 7.1. POPIS PROJEKTU 53 TRIANGLE (f, f, f)(f, f, f)(f, f, f) TRIANGLE (f, f, f)(f, f, f)(f, f, f). souřadnice vrcholů 1. trojúhelníku souřadnice vrcholů 2. trojúhelníku Popis tříd Účelem této části není nahrazovat dokumentaci zdrojového kódu, ale pouze seznámit čtenáře se základní filozofií návrhu implementace. Nebudou proto popisovány veškeré třídy a jejich metody, ale pouze ty nejzákladnější. Popisem tříd a kódu vztahujícího se ke grafickému uživatelskému rozhraní se tato část nebude věnovat vůbec. Třídy s předponou "Br"jsou navrženy s ohledem na využití jazyka Brook pro zpřístupnění GPU pro výpočty. Ostatní třídy s využitím jazyka Brook nepočítají Třída CRayTracerEngine Abstraktní třída CRayTracerEngine je základní třídou. Obsahuje prázdné virtuální metody LoadNffFile, LoadViewFile, GetColorBuffer a BuildTree, které po přepsání mají následující význam. Metody LoadNffFile a LoadViewFile slouží k načítání scén ze souboru. Metoda GetColorBuffer zahajuje generování primárních paprsků. Její návratovou hodnotou je color buffer s vypočtenými barvami pixelů. Color buffer je realizován jako dynamické pole typu float, kde každé tři po sobě jdoucí hodnoty reprezentují jeden pixel (R, G, B). Metoda BuildTree počítá optimální hloubku kd-stromu (v případě, že není pevně stanovena) a zahajuje jeho stavbu Třída Object Abstraktní třída Object obsahuje prázdné virtuální metody GetNormal, Intersect a Calc- Bounds, které po přepsání mají následující význam. Metoda GetNormal vrací normálu v zadaném bodě, metoda Intersect provádí test na průsečík s paprskem a metoda CalcBounds počítá obálku AABB. Třída dále obsahuje definované metody ComputePhong, GetReflectedRay a GetRefractedRay. Metoda ComputePhong počítá Phongův osvětlovací model, metoda GetReflectedRay odražený paprsek a GetRefractedRay lomený paprsek. Tyto metody bychom mohli definovat přímo ve třídě CRayTracerEngine, avšak za cenu toho, že by měly jeden vstupní parametr navíc - zasažený objekt. Od třídy Object jsou dále odvozeny třídy Triangle a Sphere Třída CEngine Třída CEngine je poděděna od třídy CRayTracerEngine. Obsahuje nové metody GetNearestObject, CreateShadowRay a IsShadow. Metoda GetNearestObject vrátí nejbližší zasažený objekt nalezený hrubou silou. Metoda CreateShadowRay vytvoří stínový paprsek mezi zasaženým objektem a odpovídajícím světelným zdrojem. Metoda IsShadow, jejíž vstupem je

70 54 KAPITOLA 7. REALIZACE stínový paprsek, hrubou silou vyhodnotí, zda-li je mezi zasaženým objektem a světelným zdrojem překážka (není zastínen). Třída dále obsahuje metody TraceRay a TrayRayBrute, které realizují rekurzivní sledování paprsku. Metoda TrayRay využívá oproti metodě TrayRayBrute akcelerační strukturu kdstrom. Metody jsou navrženy v několika verzích, které se od sebe liší v podpoře stínových a sekundárních paprsků. Odpovídající metoda je vybrána pomocí ukazatele na funkci dle nastavení aplikace Třída CBrEngine Třída CBrEngine je také poděděna od třídy CRayTracerEngine a obsahuje funkčně ekvivalentní metody jako třída CEngine Třída CKdTree Třída CKdTree obsahuje metody Construct, GetNearestObject a IsShadow. Metoda Construct postaví kd-strom. Pro zlepšení výkonu je při stavbě použit STL zásobník. Metoda GetNearestObject vrátí nejbližší zasažený objekt. Metoda IsShadow vyhodnotí, zda-li je mezi zasaženým objektem a světelným zdrojem překážka Třída CBrKdTree Třída CBrKdTree obsahuje funkčně ekvivalentní metody jako třída CEngine. Navíc obsahuje metodu ConvertToStreams, která postavený strom převede do proudové reprezentace.

71 7.1. POPIS PROJEKTU Seznam kernelů V tabulce 7.1 je uveden neúplný výčet kernelů použitých při implementaci, včetně popisu jejich významu. Název kcalcprimaryrays kcalcshadowrays kcalcreflectedrays kcalcrefractedrays kintersecttriangle kintersectsphere ktrisetshadow ksphsetshadow ksetshadinginfo kcomputephong kaddcolor kinithit kinitindices kkdinitialize kkdfindleaf kkdtriinitsearchleaf kkdsphinitsearchleaf kkdintersecttriangle kkdintersectsphere kkdintersecttriangles kkdintersectspheres kkdcontinue kgenerateraymask Význam Počítá pozice a směry primárních paprsků Počítá pozice a směry stínových paprsků Počítá pozice a směry odražených paprsků Počítá pozice a směry lomených paprsků Vyhodnocuje zasažení trojúhelníku paprsky Vyhodnocuje zasažení koule paprsky Nastavuje barvy na barvu stínu v případě zjištění překážky pro trojúhelníky Nastavuje barvy na barvu stínu v případě zjištění překážky pro koule Nastavuje informace nutné pro výpočet osvětlení Počítá Phongův osvětlovací model K prvním vstupním barvám připočítává druhé vstupní barvy Nastaví zásahy na výchozí hodnoty Inicializuje proud odpovídajícími indexy jeho elementů Počítá parametry scenemin a scenemax nutné pro procházení kd-stromu Hledá listy v kd-stromu Inicializuje prohledání listu pro trojúhelníky Inicializuje prohledání listu pro koule Vyhodnocuje zasažení trojúhelníků paprsky Vyhodnocuje zasažení koulí paprsky Vyhodnocuje zasažení trojúhelníků stínovými paprsky Vyhodnocuje zasažení koulí stínovými paprsky Rozhoduje, zda-li se má pokračovat v procházení kd-stromu Počítá výpočetní masku Tabulka 7.1: Seznam kernelů GPU backend Podle slov tvůrců Brooku je DirectX backend výkonnější a stabilnější než OpenGL backend. Během implementace se to potvrdilo, proto aplikace pro výpočty na GPU používá výhradně DirectX backend Zdrojové kódy třetích stran Při implementaci byly použity následující třídy, metody, nebo funkce třetích stran:

72 56 KAPITOLA 7. REALIZACE Funkce pro výpočet průsečíku mezi trojúhelníkem a paprskem. Autory jsou Tomas Möller a Ben Trumbore [18]. Třída CTimer pro měření času. Autorem je Vlastimil Havran [12]. Metody ReadWindowPlacement, WriteWindowPlacement a přepsané virtuální metody ActivateFrame a OnClose pro zapamatování pozice a velikosti hlavního okna. Autorem je Michael Walz [29]. Třídy C32BitImageProcessor, CEnBitmap, CImageGrayer, CColor, CImageHigh a CToolBar24 pro podporu ikon v 24-bitové barevné hloubce. Autory jsou Daniel Godson a Christian Rodemeyer [10]. 7.2 Problémy během realizace Překladač BRCC Poslední oficiálně uveřejněná verze překladače BRCC (0.5 beta1 svnrev1887) přeložená podle postupu uvedeném v části 4.1 nabízí následující volby překladu: -p shader cpu/ps30/fp40/ctm/glsl/[legacy(ps20/ps2a/ps2b/fp30/arb)] (can specify multiple) -f compiler favor a particular compiler (cgc / fxc / default) Nějaké podrobnější zdokumentování chybí, ale intuitivně se dá usoudit, že volby ps30 a ps20 znamenají DirectX backend a gsls a arb OpenGL backend. Také se dá usuzovat, že volby ps30 a glsl jsou modernější než ps20 a arb. Jako funkční se však na primárně testovaných grafických kartách ATI Radeon HD 5770 a NVIDIA GeForce 7600 GS ukázaly vedle volby cpu pouze volby ps20 a arb v kombinaci s volbou cgc. Tedy: brcc -p ps20 -p arb -p cpu -f cgc nazev_souboru.br Poslední dostupná vývojářská verze svnrev1889 této zjištěné, poněkud matoucí skutečnosti nasvědčuje, protože volby ps30 a glsl už nejsou dostupné: -p shader cpu/ps20/ps2a/ps2b/arb/fp30/fp40 (can specify multiple) Verze Cg Toolkitu Překladač cgc při nainstalovaném Cg Toolkitu verze nekorektně překládá složené podmínky v kernelech (přeložený program nefunguje korektně), např: if ((u < 0.f) (u > det)...) Složené podmínky je nutné dekomponovat na jednoduché, ale i tak nelze implementaci dokončit. Řešením je nainstalovat nejnovější verzi Cg Toolkitu a to i přesto, že se na oficiálním diskusním fóru Brooku můžeme dočíst o možných problémech s kompatibilitou.

73 7.2. PROBLÉMY BĚHEM REALIZACE Velikost kernelů Kernely jsou velikostně omezeny. Při napsání příliš velkého kernelu může překladač BRCC hlásit chyby typu: error C6001: Temporary register limit of 12 exceeded; 14 registers needed error C6003: Arithmetic instruction limit of 64 exceeded; 67 arithmetic in structions needed to compile program Řešením je vymyslet úspornější implementaci těla kernelu nebo kernel rozdělit na dva menší. Dobrým příkladem může být např. kernel kkdintersecttriangle: kkdintersecttriangle(init_state_s, ray_s, hit_s, float2(order, size), tri_indices_s, triangles_s, hit_s, tri_result_s); který v případě problémů můžeme za cenu měřitelného zhoršení výkonu rozdělit takto: kkdgettriindex(init_state_s, float2(order, size), tri_indices_s, tri_index_s, tri_result_s); kkdintersecttriangle(ray_s, hit_s, tri_index_s, triangles_s, hit_s); Vstupní proud zároveň jako výstupní V návrhu se počítá s tím, že v některých kernelech používaných v těle cyklu je vstupní proud, který obsahuje stará data, zároveň i výstupním proudem, do kterého se ukládají aktualizovaná data. Tento způsob je v implementaci běžně používán a ukázal se jako funkční. V jednom případě však došlo k nekorektnímu chování: // Definice kernelu kernel void kkdcontinue(float4 hit<>, float4 istate<>, float stmax<>, out float4 ostate<>, out float result<>) {... } // Volání kkdcontinue(hit_s, state_s, stmax_s, state_s, result_s); /* state_s a result_s obsahují nekorektní výsledky! */ Správné funkčnosti se podařilo docílit následovně: // Deklarace dočasného proudu ::brook::stream tmp_state_s = ::brook::stream::create<float4>(resolution_y, resolution_x); // Volání kkdcontinue(hit_s, state_s, stmax_s, tmp_state_s, result_s); // Překopírování proudu tmp_state_s do state_s

74 58 KAPITOLA 7. REALIZACE kcopyfloat4stream(tmp_state_s, state_s); /* state_s a result_s obsahují korektní výsledky */ Správné funkčnosti kernelu kkdcontinue se tedy podařilo docílit pouze tím, že nezapisuje přímo do proudu state_s, který je zároveň i vstupním proudem, ale do nově deklarovaného proudu tmp_state_s, který se následně překopíruje do proudu state_s. Na oficiálních stránkách Brooku [2] je případ, kdy v kernelu funguje vstupní proud zároveň i jako výstupní, uveden mezi známými problémy. Je více než zřejmé, že zbytečné překopírovávání proudů znamená režii navíc, která se nám nehodí Výpočetní maska Brook nabízí jistou podporu pro výpočetní masku (není zdokumentováno). Dle přiloženého ukázkového příkladu "writequery" by k tomu měly sloužit následující konstrukce: ::brook::write_query q = ::brook::write_query::create(); ::brook::write_mask m = ::brook::write_mask::create(size, size); Bohužel výše uvedené konstrukce odmítá překladač C++ přeložit a hlásí chyby typu: error LNK2001: unresolved external symbol "public: static class brook::write_query cdecl brook::write_query::create(void)" (?create@write_query@brook@@sa?av12@xz) error LNK2001: unresolved external symbol "public: static class brook::write_mask cdecl brook::write_mask::create(int,int)" (?create@write_mask@brook@@sa?av12@hh@z) Což vypadá, jako kdyby nebylo něco korektně nadefinováno v run-time knihovně Brooku. Shodný problém je jak v poslední oficiálně uveřejněné revizi 1887, tak i v poslední vývojářské revizi Této nepříjemnosti předejdeme tak, že před překladem knihovny Brook Run-Time ručně přidáme v projektu Brooku do projektové složky runtime soubory writemask.hpp, writemask.cpp, writequery.hpp a writequery.cpp. Tyto soubory nejsou ve výchozím stavu v projektu korektně přidány a knihovna se proto (bez varování) nepřekládá správně Funkce floor Na grafické kartě ATI Radeon HD 5770 bylo zjištěno podivné chování funkce floor, která vrací celou část desetinného čísla. V níže uvedeném modelovém příkladě byly za jistých, blíže nespecifikovatelných okolností vykazovány nekorektní výsledky. Na grafické kartě NVIDIA GeForce 7600 GS tyto problémy pozorovány nebyly. float f; float x = 0.f; float order = 100.f; float size = 100.f; float result; f = (x + order) / size; result = floor(f); // result = 0.f - chyba!

75 7.2. PROBLÉMY BĚHEM REALIZACE 59 Správné funkčnosti se podařilo docílit následovně: f = (x + order) / size f; result = floor(f); // result = 1.f - správně Ověřování funkčnosti Ray tracing sám o sobě se ladí obtížně. V případě přepracování na paralelní zpracování se situace ještě více komplikuje. Jedním z možných způsobů, jak ověřovat správnost fungování paralelního ray tracingu na GPU, je zapisovat data do souboru a porovnávat je s odpovídajícím souborem zapsaným již odladěným ray tracingem na CPU. Na porovnání obsahů dvou souborů lze použít např. program Total Commander a příkaz cm_comparefilesbycontent. Pro tento účel ověřování funkčnosti slouží v projektu třída CBrDebugLog, která ukládá soubory s daty pro porovnání do adresáře DebugLogs.

76 60 KAPITOLA 7. REALIZACE

77 Kapitola 8 Testování 8.1 Způsob testování Aplikaci otestujeme na čtyřech testovacích sestavách vybavených různými grafickými kartami. Obsažena je jak grafická karta starší generace NVIDIA GeForce 7600 GS tak i nejmodernější grafické karty současnosti ATI Radeon HD 5770 a ATI Radeon HD ATI Radeon HD 5850 lze už považovat za výkonné řešení, které postačuje na většinu současných počítačových her. Poslední sestava je vybavena starší, ale přesto ještě výrobci poměrně osazovanou, mobilní grafikou ATI Mobility Radeon HD Provedeme celkem čtyři série testů. V každé sérii ověříme výkon aplikace při renderování scén jak v CPU módu, kdy využívá pouze CPU tak v GPU módu, kdy vedle CPU z převážné části využívá i GPU. Rozlišení výstupního obrázku bude 512 x 512 a 1024 x První série testů ověří hrubou výpočetní sílu GPU v porovnání s CPU na scénách skládajících se z 30 až 3510 primitiv (trojúhelníků a koulí). Uvažovány budou pouze primární paprsky bez využití akcelerační struktury, což nám podá asi nejméně zkreslenou představu o výpočetním potenciálu jednotlivých procesorů. Druhá série testů naváže na první zapnutím stínových paprsků. Třetí série testů bude sloužit k ověření výkonu při sledování sekundárních paprsků (odražených a lomených) do hloubky 3. Poslední, čtvrtá série testů, bude sloužit k ověření výkonu aplikace pro renderování velkých scén skládajících se z až primitiv při zapnuté akcelerační struktuře kd-strom. Hloubku kd-stromu necháme počítat automaticky, počet testů pro určení vhodné pozice dělící roviny nastavíme na 200 a dolní hranici počtu objektů pro dělení uzlů na 4 (v GPU módu tuto hodnotu zvýšíme na 50). V CPU módu navolíme pro procházení kd-stromu standardní algoritmus, neboť se po zběžném otestování ukázal pro většinu scén jako rychlejší než algoritmus Kd-restart, v GPU módu na výběr nemáme. Měření času se spouští ihned na začátku v těle metody GetColorBuffer a stopuje těsně před vrácením color bufferu. 61

78 62 KAPITOLA 8. TESTOVÁNÍ 8.2 Testovací sestavy Testovací sestava A Kategorie: stolní počítač Procesor: AMD Athlon II X2 3 GHz Grafická karta: ATI Radeon HD 5850, takt jádra 725 MHz, 1024 MB paměti GDDR5 (1000 MHz), 256-bitová sběrnice, bandwidth 128 GB/s, 1440 Pixel Shader Engines, 1440 Vertex Shaders, podpora DirectX 11 a OpenGL 3.2 Operační paměť: 4 GB DDR3 (1333 MHz) Operační systém: Microsoft Windows 7 Testovací sestava B Kategorie: stolní počítač Procesor: AMD Athlon II X2 3 GHz Grafická karta: ATI Radeon HD 5770, takt jádra 850 MHz, 1024 MB paměti GDDR5 (1200 MHz), 128-bitová sběrnice, bandwidth 77 GB/s, 800 Pixel Shader Engines, 800 Vertex Shaders, podpora DirectX 11 a OpenGL 3.1 Operační paměť: 4 GB DDR3 (1333 MHz) Operační systém: Microsoft Windows 7 Testovací sestava C Kategorie: Procesor: Grafická karta: Operační paměť: Operační systém: Testovací sestava D Kategorie: Procesor: Grafická karta: Operační paměť: Operační systém: stolní počítač AMD Athlon XP 2,083 GHz NVIDIA GeForce 7600GS, takt jádra 400 MHz, 256 MB paměti DDR2 (800 MHz), 128-bitová sběrnice, bandwidth 12,7 GB/s, 12 Pixel Shader Engines, 5 Vertex Shaders, podpora DirectX 9 a OpenGL 2 1,75 GB DDR (333 MHz) Microsoft Windows XP SP3 notebook Intel Core 2 Duo 2,26 GHz ATI Mobility Radeon HD 3470, takt jádra 680 MHz 64 MB paměti DDR3 (800 MHz), 64-bitová sběrnice, bandwidth 3,2 GB/s, 40 Pixel Shader Engines, 40 Vertex Shaders, podpora DirectX 10.1 a OpenGL GB DDR3 Microsoft Windows Vista SP1

79 8.2. TESTOVACÍ SESTAVY Výsledky Primární paprsky stínové paprsky: sekundární paprsky: kd-strom: ne ne ne scéna rozlišení TS CPU čas [s] GPU čas [s] zrychlení [-] cornell-blocks.nff A 0,43 0,14 3, x 512 B 0,43 0,07 6,14 C 0,63 0,36 1,75 D 0,42 0,25 1,68 A 1,63 0,1 16, x 1024 B 1,61 0,16 10,06 C 2,53 0,83 3,05 30 primitiv D 1,68 0,71 2,37 teapot2.nff A 10,3 0,31 33, x 512 B 10,31 0,41 25,15 C 18,52 3,6 5,14 D 9,92 2,34 4,24 A 41,14 0,78 52, x 1024 B 41,11 1,18 34,84 C 73,93 14,44 5, primitiv D 39,76 10,84 3,67 wheel.nff A 15,28 0,35 43, x 512 B 15,16 0,56 27,07 C 27,11 5,04 5,38 D 15,8 3,21 4,92 A 60,52 1,04 58, x 1024 B 60,25 1,62 37,19 C 108,41 20,2 5, primitiv D 70,52 12,71 5,55 jacks4.nff A 23,83 0,8 29, x 512 B 23,79 1,25 19,03 C 44,7 10,25 4,36 D 20,81 7,35 2,83 A 94,41 2,5 37, x 1024 B 95,15 3,92 24,27 C 178,69 40,72 4, primitiv D 83,16 28,94 2,87 Tabulka 8.1: Výsledky testování primárních paprsků

80 64 KAPITOLA 8. TESTOVÁNÍ Stínové paprsky stínové paprsky: sekundární paprsky: kd-strom: ano ne ne scéna rozlišení TS CPU čas [s] GPU čas [s] zrychlení [-] cornell-blocks.nff A 0,77 0,09 8, x 512 B 0,76 0,08 9,5 C 1,17 0,52 2,25 D 0,76 0,34 2,24 A 2,98 0,19 15, x 1024 B 2,96 0,24 12,33 C 4,68 1,41 3,32 30 primitiv D 3,02 1,78 1,7 teapot2.nff A 16,97 0,61 27, x 512 B 16,96 0,92 18,43 C 30,53 18,05 1,69 D 16,43 5,26 3,12 A 67,73 2,01 33, x 1024 B 67,59 2,9 23,31 C 119,8 72,28 1, primitiv D 65,84 35,28 1,87 wheel.nff A 18,32 0,62 29, x 512 B 18,25 0,81 22,53 C 32,44 15,34 2,11 D 19,07 4,4 4,33 A 72,89 1,56 46, x 1024 B 73,12 2,52 29,02 C 129,56 61,05 2, primitiv D 75,99 23,56 3,23 jacks4.nff A 29,19 1,18 24, x 512 B 29,09 1,76 16,53 C 54,78 20,55 2,67 D 25,77 10,23 2,52 A 115,31 3,66 31, x 1024 B 115,3 5,6 20,59 C 219,2 76,57 2, primitiv D 102,86 64,22 1,6 Tabulka 8.2: Výsledky testování stínových paprsků

81 8.2. TESTOVACÍ SESTAVY Sekundární paprsky stínové paprsky: ano sekundární paprsky: ano hloubka sledování sekundárních paprsků: 3 kd-strom: ne scéna rozlišení TS CPU čas [s] GPU čas [s] zrychlení [-] cornell-spheres.nff A 0,78 0,21 3, x 512 B 0,78 0,21 3,71 C 1,13 3,06 0,37 D 0,76 1,22 0,62 A 3,03 0,34 8, x 1024 B 3,03 0,54 5,61 C 4, primitiv D 2,99 7,62 0,39 balls1.nff A 1,56 0,28 5, x 512 B 1,56 0,28 5,57 C 2,48 4,9 0,51 D 1,52 1,8 0,84 A 6,18 0,58 10, x 1024 B 6,18 0,85 7,27 C 9, primitiv D 6,06 13,28 0,46 balls2.nff A 46,01 4,04 11, x 512 B 46 5,52 8,33 C 76,92 150,06 0,51 D 41,12 30,15 1,36 A 183,96 11,25 16, x 1024 B 184,03 17,52 10,5 C 308, primitiv D 165,6 230,74 0,72 teapot1.nff A 27,48 3,83 7, x 512 B 27,51 4,22 6,52 C 50,29 256,2 0,2 D 26,87 12,16 2,21 A 109,67 5,81 18, x 1024 B 109,85 7,58 14,49 C 201, primitiv D 107,67 54,71 1,97 Tabulka 8.3: Výsledky testování sekundárních paprsků

82 66 KAPITOLA 8. TESTOVÁNÍ Kd-strom stínové paprsky: sekundární paprsky: kd-strom: ne ne ano scéna rozlišení TS CPU čas [s] GPU čas [s] zrychlení [-] theatre.view A 1,74 2,79 0, x 512 B 1,69 2,99 0,57 C 3,28 43,34 0,08 D 1,81 7,77 0,23 A 5,88 3,71 1, x 1024 B 5,72 4,53 1,26 C 10, primitiv D 6,39 27,18 0,24 ewr10.view A 2,01 1,82 1,1 512 x 512 B 1,94 1,92 1,01 C 4,13 22,8 0,18 D 2,06 4,63 0,44 A 5,53 2,4 2, x 1024 B 5,95 2,89 2,06 C 11, primitiv D 6,8 18,44 0,37 conf.view A 1,6 7,82 0,2 512 x 512 B 1,59 8,12 0,2 C 5,14 120,78 0,04 D 1,58 16,72 0,09 A 3,51 10,98 0, x 1024 B 3,49 13,09 0,27 C 8, primitiv D 3,77 95,96 0,04 sodahall.view A 3,43 6,72 0, x 512 B 3,46 6,94 0,5 C 41, D 3 14,8 0,2 A 5,47 7,78 0, x 1024 B 5,46 8,72 0,63 C 46, primitiv D 5,26 34,97 0,15 Tabulka 8.4: Výsledky testování kd-stromu

83 8.4. ZHODNOCENÍ VÝSLEDKŮ Zhodnocení výsledků První série testů (viz tab. 8.1) byla zaměřena na ověření hrubé výpočetní síly CPU a GPU. Ukazuje se jasná dominance GPU, protože na všech testovacích sestavách bylo při využití GPU dosaženo, dle konkrétní sestavy a scény, 1,68 až 58,19-krát lepšího času než při pouhém využití CPU. Výkonnostní výsledky sestavy B, která představuje počítačovou sestavu nové generace a sestavy C, která přibližně představuje odpovídající počítačovou sestavu starší generace, potvrzují trend z obrázku 2.2, kdy je výkonnostní náskok GPU oproti CPU s novější generací výraznější. Druhá série testů (viz tab. 8.2) ověřovala, jak se změní výkonnost po zapnutí stínových paprsků. Z výsledků je patrné, že je výkonnostní náskok GPU zachován, ale je oproti předchozí sérii testů nižší. Dá se to vysvětlit tím, že zatímco při počítání na CPU je vyhodnocení stínových paprsků rychlejší než vyhodnocení primárních paprsků, při počítání na GPU tomu tak v odpovídající míře není. Při počítání na CPU jsou vysílány stínové paprsky z místa, kde došlo k zasažení objektu primárním (popř. sekundárním) paprskem. V případě, že nedošlo k zasažení, k žádnému vysílání stínových paprsků a následnému zjišťování výskytu překážky mezi místem zásahu objektu a pozicemi světel, vůbec nedochází. Při počítání na GPU však musíme projít všemi fázemi a můžeme pouze vymaskovat elementy proudu, pro něž nebyl vygenerován stínový paprsek, což jsme také udělali. Co však nemáme efektivně vyřešené, je předčasné ukončení testu při první detekci překážky. Přepočítávat výpočetní masku po každém testu se neukázalo jako řešení, které by v tomto případě vedlo k lepšímu výkonu. Třetí série testů (viz tab. 8.3) ověřovala výkonnost při sledování sekundárních paprsků do hloubky 3 (včetně zapnutých stínových paprsků). Vidíme, že stabilního zrychlení dosáhla aplikace pouze sestavách A a B vybavených moderními grafickými kartami ATI řady HD 5xxx. Na sestavě C, která je vybavena starší grafickou kartou NVIDIA GeForce 7600 GS, aplikace vykazovala při využití GPU vždy horší výsledky než při čistém využití CPU. Následnou analýzou se ukázalo, že výpočetní maska na grafické kartě NVIDIA GeForce 7600 GS nefunguje efektivně. Při vyřazení výpočetní masky aplikace podávala obdobné, spíše lepší výsledky (výpočet výpočetní masky znamená také režii), než při jejím zařazení. Tento neúspěch byl korunován nekorektním vykreslením scén cornell-spheres a balls1 v rozlišení 512 x 512. Při snížení hloubky sledování ze 3 na 2 došlo k určitému zlepšení a scény byly vykresleny korektně. V rozlišení 1024 x 1024 nebyla aplikace schopna na této grafické kartě vyrenderovat ani jednu testovanou scénu (docházelo k vypínání). Že není něco v pořádku s výpočetní maskou použitou během výpočtu na grafické kartě NVIDIA GeForce 7600 GS ukazují i předchozí série testů, neboť zatímco v první sérii bylo zrychlení aplikace na sestavě C téměř ve všech případech vyšší než na sestavě D, v druhé sérii (kdy byly maskovány stínové paprsky) se situace v některých případech obrátila, což je neočekávaný výsledek. Poslední série testů (viz tab. 8.4) ověřovala výkonnost aplikace na velkých scénách při zapnuté akcelerační struktuře kd-strom. V těchto testech dokázaly pouze grafické karty ATI Radeon HD 5xxx u scén ew10 a theatre (v rozlišení 1024 x 1024) ještě nabídnout určité zrychlení, v ostatních případech však CPU podávalo lepší výkon. Ukazuje se tak, že proměnit výpočetní potenciál GPU vůči CPU ve zrychlení, není vždy snadné. V našem případě bychom mohli znovu zanalyzovat navržený algoritmus na procházení kd-stromu a pokusit se jinak rozvrhnout funkcionalitu kernelů, dosáhnout nižšího počtu iterací a důmyslnějšího

84 68 KAPITOLA 8. TESTOVÁNÍ maskování. V tomto smyslu určitě prostor na zlepšení existuje. Je však nutné si uvědomit, že jsme také do určité míry limitováni možnostmi BrookGPU Faktory ovlivňující výkonnost grafických karet Podíváme-li se na GPU časy z první série testů, která nejlépe vystihuje výkonnost jednotlivých grafických karet, tak pořadí od nejvýkonnější po nejslabší je následující: 1. ATI Radeon HD ATI Radeon HD ATI Mobility Radeon HD NVIDIA GeForce 7600 GS Ná základě tohoto žebříčku a parametrů uvedených v části 8.2 můžeme usoudit, že důležitým faktorem ovlivňujícím výkonnost grafických karet pro obecné výpočty je zejména počet shader procesorů a velikost grafické paměti spolu s její propustností (bandwidth), která je možná důležitější než samotná šířka sběrnice.

85 Kapitola 9 Závěr Předmětem této práce bylo prostřednictvím jazyka Brook využít procesor grafické karty pro obecné matematické výpočty v softwarové aplikaci. Konkrétně se jednalo o metodu počítačové vizualizace ray tracing, na které se měl prakticky ověřit přínos využití moderních GPU pro výpočty jakožto alternativa k CPU. Výsledkem práce je plnohodnotná přenositelná aplikace realizující metodu ray tracing, která je schopna využívat výpočetní síly GPU, a dosáhnout tak ve srovnání s CPU v řadě případech nezanedbatelného zrychlení. Výsledky testování potvrdily přínos využití GPU jako koprocesoru pro obecné výpočty a také, že přínos GPU se zvyšuje s novějšími generacemi grafických procesorů. BrookGPU je zajímavý projekt, který umožňuje programátorům prostřednictvím jazyka Brook využít výpočetní síly GPU v softwarových aplikacích. Je abstrakcí nad standardizovanými grafickými API DirectX a OpenGL, takže by výsledná aplikace měla teoreticky fungovat s velkou většinou grafických karet. V případě, že bychom místo BrookGPU použili např. technologii CUDA, nespustili bychom výslednou aplikaci na žádné sestavě použité při testování, protože ani jedna není vybavena grafickou kartou, která by technologii CUDA podporovala. Je to však vykoupeno tím, že BrookGPU přistupuje oproti CUDA méně efektivněji ke GPU, takže z principu nemůže nabídnout srovnatelný výkon. Nevýhodou BrookGPU je špatné zdokumentování. Už samotný překlad překladače a běhové knihovny je poměrně komplikovanou procedurou, která může méně zkušeným programátorům činit problémy. Následné používání překladače BRCC může rovněž vyvolat určité rozpaky, jelikož není transparentně řečeno, která nastavení vlastně fungují a za jakých podmínek. Dokumentace vyzdvihuje jazyk Brook, jakožto nadstavbu ANSI C, ale rozšíření Brooku, které je spíše nadstavbou C++, vůbec nezmiňuje a je potřeba to odezřít z několika málo přiložených ukázkových příkladů. Toto může programátora zpočátku zmást a navést ke zbytečně kostrbatému programování, což je škoda, protože BrookGPU je jinak dobře vymyšlený a užitečný projekt, který nabízí možná více, než se na první pohled může zdát. 69

86 70 KAPITOLA 9. ZÁVĚR

87 Literatura [1] Brook Language. stav z [2] BrookGPU - hlavní stránka. stav z [3] Wikipedia - Raytracing. stav z [4] Wikipedia - Shading language. stav z [5] Advanced Micro Devices. ATI Stream Computing User Guide, [6] J. Bikker. Raytracing: Theory & Implementation. stav z [7] N. A. Carr, J. D. Hall, and J. C. Hart. The ray engine. In Proceedings of the ACM SIGGRAPH/EUROGRAPHICS conference on Graphics hardware, page 37 46, [8] R. Fernando and M. J. Kilgard. The Cg Tutorial: The Definitive Guide to Programmable Real-Time Graphics. stav z [9] T. Foley and J. Sugerman. KD-Tree Acceleration Structures for a GPU Raytracer. Stanford University, [10] D. Godson and C. Rodemeyer. Generating inactive/disabled images for toolbar. stav z [11] E. Haines. Neutral File Format. stav z [12] V. Havran. Vlastimil Havran - domovská stránka. stav z

88 72 LITERATURA [13] V. Havran. Heuristic Ray Shooting Algorithms. PhD thesis, Faculty of Electrical Engineering, Czech Technical University in Prague, [14] A. Hildebrand. Raytracing akcelerovaný moderním grafickým hardwarem. Master s thesis, Faculty of Mathematics and Physics of Charles University in Prague, [15] D. R. Horn, J. Sugerman, M. Houston, and P. Hanrahan. Interactive k-d Tree GPU Raytracing. Stanford University, [16] W. Hunt, W. R. Mark, and G. Stoll. Fast kd-tree Construction with an Adaptive Error-Bounded Heuristic, [17] Khronos Group. The OpenCL Specification, [18] T. Möller and B. Trumbore. Fast, minimum storage ray-triangle intersection. journal of graphics, gpu, and game tools, 2(1):21 28, [19] NVIDIA. CUDA Architecture - Introduction & Overview, CUDA_Architecture_Overview.pdf. [20] NVIDIA. CUDA Programming Guide, docs/nvidia_cuda_programming_guide_2.3.pdf. [21] J. Owens. Streaming architectures and technology trends. International Conference on Computer Graphics and Interactive Techniques, [22] S. Popov. Stackless KD-Tree Traversal for Ray Tracing on Graphics Hardware. Master s thesis, Saarland University, [23] S. Popov, J. Günther, H.-P. Seidel, and P. Slusallek. Experiences with Streaming Construction of SAH KD-Trees, [24] S. Popov, J. Günther, H.-P. Seidel, and P. Slusallek. Stackless KD-Tree Traversal for High Performance GPU Ray Tracing, [25] T. J. Purcell. Ray Ttracing on a Stream Processor. PhD thesis, Stanford University, [26] J. Žára, B. Beneš, and P. Felkel. Moderní počítačová grafika. Computer Press s.r.o, Brno, 2st edition, In Czech. [27] D. Shreiner, M. Woo, J. Neider, and T. Davis. OpenGL Průvodce programátora. Computer Press, a.s., Brno, In Czech. [28] I. Wald and V. Havran. On building fast kd-trees for Ray Tracing, and on doing that in O(N log N), [29] M. Walz. Preserving window position in a MFC SDI application. stav z

89 LITERATURA 73 [30] T. Whitted. An improved illumination model for shaded display. Communications of the ACM, 23(6): , [31] A. Williams, S. Barrus, R. K. Morley, and P. Shirley. An Efficient and Robust Ray Box Intersection Algorithm. University of Utah, 2005.

90 74 LITERATURA

91 Příloha A Seznam použitých zkratek ALU Arithmetic Logic Unit API Application Programming Interface CAL Compute Abstraction Layer CPU Central Processing Unit CTM Close To Metal CUDA Compute Unified Device Architecture FLOPS FLoating point Operations Per Second GPGPU General-Purpose computation on Graphics Processing Units GPU Graphics Processing Unit GUI Graphical User Interface HLSL High Level Shading Language MFC Microsoft Foundation Classes 75

92 76 PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

93 Příloha B Instalační a uživatelská příručka B.1 Požadavky Grafická karta s podporou DirectX 9 a Shader Model 3.0 Operační systém Microsoft Windows XP / Vista / 7 B.2 Spuštění aplikace Aplikaci není nutné instalovat. Spustí se pomocí spustitelného souboru RayTracer.exe. Na počítači, kde není nainstalováno DirectX SDK je potřeba, aby vedle spustitelného souboru byla přiložena dynamická knihovna d3dx9_41.dll. B.3 Popis aplikace B.3.1 Parametry a vlastnosti Načítání scén ze souborů ve formátech NFF a VIEW/TRI Renderování obrázků v rozlišeních 512 x 512, 512 x 1024 a 1024 x 1024 Podpora více bodových světelných zdrojů Zachycení stínů, odrazů a lomů Akcelerace pomocí kd-stromu Akcelerace prostřednictvím GPU Ukládání vyrenderovaného obrázku do formátu PNG nebo BMP 77

94 78 PŘÍLOHA B. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA B.3.2 Hlavní okno Hlavní okno aplikace viz obr. B.1 obsahuje hlavní nabídku, panel nástrojů, seznam údajů a stavový řádek. Obrázek B.1: Hlavní okno aplikace B Hlavní nabídka File Open Zobrazí dialogové okno pro načtení scény ze souboru. Podporovány jsou formáty nff a view/tri. Jejich podrobná specifikace je popsána v části File Exit Ukončí aplikaci. Image Render Zahájí renderování obrázku. View Toolbar Zobrazí/skryje panel nástrojů.

95 B.3. POPIS APLIKACE 79 View Status Bar Zobrazí/skryje stavový řádek. Tools Options Zobrazí dialogové okno s možnostmi nastavení. Tools Restore default settings Obnoví výchozí nastavení. Help About Zobrazí informace o verzi programu. B Panel nástrojů Ikona Význam Zobrazí dialogové okno pro načtení scény ze souboru. Zahájí renderování obrázku. Zobrazí dialogové okno s možnostmi nastavení. Tabulka B.1: Význam ikon na panelu nástrojů B Seznam údajů Seznam údajů zobrazuje informace o pozici a směru kamery, pozicích a intenzitách světelných zdrojů a počtu objektů ve scéně. B Stavový řádek Zprava doleva zobrazuje aktuálně nastavené výchozí rozlišení a mód běhu aplikace (CPU / GPU).

96 80 PŘÍLOHA B. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA B.3.3 Renderovací okno Po zahájení renderování se zobrazí renderovací okno (viz obr. B.2). Než je obrázek spočítán a vykreslen, je okno šedivé. V této fázi může být počítač nadměrně vytěžován, a proto se nedoporučuje pracovat s jinými aplikacemi. Obrázek B.2: Renderovací okno Po vyrenderování obrázku je možné pravým tlačítkem myši vyvolat kontextové menu a obrázek uložit na disk. V záhlaví okna jsou uvedeny tři parametry, jejichž význam je následující: kd time - čas postavení kd-stromu, render time - čas od zahájení generování primárních paprsků do naplnění color bufferu vypočtenými barvami pixelů, total time - součet předchozích dvou časů.

97 B.3. POPIS APLIKACE 81 B.3.4 B Nastavení Karta General Obrázek B.3: Nastavení - karta General Default resolution Určuje v jakém rozlišení budou obrázky renderovány. Autosave image Po zavření okna s vyrenderovaným obrázkem automaticky uloží výstupní obrázek do adresáře Images, který je vytvořen vedle spustitelného souboru aplikace. Autosave log Po zavření okna s vyrenderováným obrázkem automaticky uloží do adresáře Logs, který je vytvořen vedle spustitelného souboru aplikace, soubor se základními informacemi o scéně, aktuální konfiguraci a časy, za jaké byla scéna vyrenderována. Název souboru je odvozen od aktuálního systémového data a času, takže nedochází k přepisům.

98 82 PŘÍLOHA B. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA B Karta Rays Obrázek B.4: Nastavení - karta Rays Enable shadow rays Povolí/zakáže stínové paprsky. EPS1 Konstanta, která udává, o jakou vzdálenost mají být počátky stínových paprsků odsazeny směrem ke světelným zdrojům. Důvodem je, aby nebyl zasáhnut ten samý objekt, z jehož povrchu je stínový paprsek vysílán a nedocházelo tak k chybám. Enable reflected and refracted rays Povolí/zakáže odražené a lomené paprsky. EPS2 Má pro sekundární paprsky podobný význam jako EPS1 pro stínové paprsky. Depth Údává, do jaké hloubky mají být sledovány sekundární paprsky. Enable adaptive-antialiasing Povolí/zakáže adaptivní antialiasing pro vyhlazování obrázků. Tato funkce je implementována pouze pro CPU.

99 B.3. POPIS APLIKACE 83 B Karta Kd-tree Obrázek B.5: Nastavení - karta Kd-tree Enable kd-tree Povolí/zakáže akceleraci pomocí kd-stromu. Kd-strom není automaticky použit pro scény s méně než 100 objekty, a není ho proto nutné pro malé scény, ve kterých se jeho stavba nevyplatí, manuálně vypínat. Max. depth Udává maximální povolenou hloubku stromu při jeho konstrukci. Adaptive max. depth Povolí/zakáže určení maximální hloubky stromu na základě počtu objektů ve scéně (doporučeno). Split tests Udává počet zkušebních dělení uzlu. Lower limit of objects for node splitting Udává minimální počet objektů, pri kterém ještě dochází k dělení uzlu. Traversal algorithm Slouží k výběru traverzačního algoritmu. V GPU módu je k dispozici pouze jeden traverzační algoritmus, proto není výběr umožněn.

100 84 PŘÍLOHA B. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA B Karta GPU backend Obrázek B.6: Nastavení - karta GPU backend Enable GPU backend Povolí/zakáže využití GPU pro výpočty. V případě, že je již načtena nějaká scéna, je ji nutné při změně backandu opětovně načíst. B.3.5 Ukládání nastavení Nastavení aplikace se ukládá do souboru Config.ini. Tento soubor se automaticky vytvoří při prvním ukončení aplikace vedle spustitelného souboru. B.3.6 Klávesové zkratky Klávesová zkratka Ctrl+O Alt+F4 Ctrl+R F2 Význam Zobrazí dialogové okno pro načtení scény ze souboru. Ukončí aplikaci. Zahájí renderování obrázku. Zobrazí dialogové okno s možnostmi nastavení. Tabulka B.2: Klávesové zkratky

101 B.4. PŘEKLAD APLIKACE 85 B.4 Překlad aplikace Po rozbalení archivu RayTracer.zip stačí otevřít projekt RayTracer.sln a stisknout klávesu F5. Žádná dodatečná konfigurace by neměla být nutná. B.5 Poznámky k používaní aplikace Během renderování obrázku se může v záhlaví okna objevit výpis "Neodpovídá". S velkou pravděpodobností se nejedená o zatuhnutí aplikace a je pouze nutné počkat na dokončení renderování, které může dle nastavení aplikace a parametrů scény trvat i několik minut. Hloubka sledování sekundárních paprsků by měla pro většinu scén postačit okolo 3. Příliš vysoká hodnota tohoto parametru znatelně zpomaluje renderování a zvyšuje nároky na paměť. Je-li aplikace nastavena v GPU módu a hodnota tohoto parametru je příliš vysoká, může v případě nedostatečné velikosti paměti grafické karty dojít až k vypnutí aplikace. Pro velké scény by se měla zapnout akcelerační struktura kd-strom. V případě, že je vyrenderovaný obrázek posetý černýma tečkama, zkuste nastavit u stínových paprsků parametr EPS1 na 0.1. Při pomalém renderování nebo podivném chování aplikace zkuste v nabídce zvolit příkaz: Tools Restore default settings.

102 86 PŘÍLOHA B. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA

103 Příloha C Galerie aplikace Obrázek C.1: Aplikace - načítání dat 87

104 88 PŘÍLOHA C. GALERIE APLIKACE Obrázek C.2: Aplikace - konfigurace Obrázek C.3: Aplikace - vyrenderovaný obrázek

105 Příloha D Galerie vyrenderovaných obrázků (a) balls1 (b) balls2 (c) jacks (d) spheres Obrázek D.1: Obrázková galerie 1 89

106 90 PŘÍLOHA D. GALERIE VYRENDEROVANÝCH OBRÁZKŮ (a) teapot2 (b) shells (c) ewr10 (d) theatre (e) conference (f) sodahall Obrázek D.2: Obrázková galerie 2