Optimalizációs lehetőségek sugárkövetéses képmegjelenítésben. Diplomamunka

Átírás

1 Miskolci Egyetem Gépészmérnöki és Informatikai Kar Ábrázoló Geometriai Intézeti Tanszék Általános Informatikai Intézeti Tanszék Optimalizációs lehetőségek sugárkövetéses képmegjelenítésben Diplomamunka Mándy Eduárd YUGNGR Mérnök Informatikus MSc Alkalmazásfejlesztő

2 Tartalom 1 Bevezető Sugárkövetés Történet Képszintézis [10] Metszéspont vizsgálat Baricentrikus koordináták [13] Árnyalás Diffúz felületek Árnyalás simítása Spekuláris hatás Árnyék Tükröződés Rekurzió Tükröződés számítása [17] SIMD Történet [18] Intel intrinsic függvények SSE változók [21] m128 és m m128d m128i SSE függvények [20] SSE SSE SSE SSSE

3 3.4.5 SSE4.1 és SSE Feltételes utasítás [20] Adatok betöltése [20] Adatok kiolvasása [20] [21] Adat illesztés Lokális változó illesztése Adatszerkezet illesztése Illesztés a heap memóriaterületen SSE alkalmazása a sugárkövetésben Követelmények a vektorizációhoz SSE alkalmazása az RTVector osztályon AOS struktúra és hátránya SOA struktúra előnye SSE használatakor Sugár-háromszög ütközésvizsgálat vektorizációval Az ütközésvizsgálat vektorizált függvényei Teljesítmény teszt Multithreading Történet Alkalmazás Szinkronizálás Renderelés több szálon Teljesítmény teszt A szoftver Felhasznált eszközök Felület Összefoglalás Summary... 56

4 8 Irodalomjegyzék CD melléklet tartalma... 59

5 1 Bevezető A szoftverfejlesztés irántiérdeklődésemet a számítógépes grafika keltettefel. Mindig is csodáltam és egyben érdekelt is, hogy vajon milyen bonyolult számításokat kell alkalmazni annak érdekében, hogy valósághű ábrázolást vagy éppen ellenkezőleg, a valóságtól elrugaszkodott, művészi szintre emelt képi világot kapjunk. Tanulmányaim során az általános programozási tudásmellett lehetőségem volt arra, hogy bepillantsak a számítógépes grafika rejtelmeibe, valamintmegismerjekkonkrét kódolási módszereket. A számítógépes grafika témakörén belül a figyelmemet a sugárkövetés keltette fel igazán. Bár az algoritmus nem új, mégis napjainkra jutott csak oda az informatika a hardver teljesítmény jelentős növekedésének köszönhetően, hogy látványos eredményeket érjünk el ezen a területen. Az informatika fejlődésének egyik fő húzóereje a számítógépes grafika. A filmipart látványos effektekkel támogatja, az orvostudományt részletes képekkel, háromdimenziós megjelenítéssel látja el az egyes betegségek könnyebb diagnosztizálása érdekében, a számítógépes játékok pedig a szórakozást hivatottak támogatni. Sorolhatnám még az élet különböző területein alkalmazott példákat, de így is jól látható, hogy mennyire szerteágazó a számítógépes grafika használata napjainkban. A számítógépek és az egyéb képi világ megjelenítésére alkalmas eszközök, mint például az okostelefonok vagy a játékkonzolok egyre jobb teljesítménnyel rendelkeznek, ami a számítógépes grafika minőségének javulását is magával hozza. Úgy gondolom, hogy a hardver az, ami korlátokat szab a szoftver számára. A szoftverfejlesztőknek mindig is kihívást jelentett, hogy egy adott eszközből a maximumot hozzák ki, és a számítógépes grafika esetében ez hatványozottan igaz. Kezdetben a számítógépek fő egysége a CPU volt. A szoftverfejlesztők olyan algoritmusokat fejlesztettek ki, amelyek a processzor teljesítményét maximálisan kihasználták, hogy minél szebb és élethűbb képi megjelenítést érjenek el. Látva, hogy milyen algoritmus tudja leginkább kielégíteni a számítógépes grafikával 1

6 szemben támasztott követelményeket, megjelent a hardveres támogatás is. A számítógépek egy új, úgynevezett GPU-val (Graphical Processing Unit) bővültek, ami az inkrementális képszintézist (gyakran raszteres grafikának is nevezik) támogatja, és a mai napig részét képezi, nem csak a számítógépeinknek, de már az okostelefonoknak is. A raszteres technika mellett már régen ismert volt a sugárkövetés módszere is, de sebességbeli hátránya miatt ez utóbbit elvetették a valós idejű grafikai alkalmazásokban. Az előre renderelt grafikáknál azonban előszeretettel alkalmazzák a fotorealisztikusság növelés érdekében. Diplomamunkám célja az, hogy bemutassak egy egyszerűbb sugárkövető algoritmust, majd optimalizáljam a sebességét a processzor adta lehetőségeket kihasználva, amelyek magukba foglalják a több CPU maggal való számítást és az SIMD technológia alkalmazását. A programot C++ nyelven írtam és a felhasználói felületéhez a Qt keretrendszert választottam. 2

7 2 Sugárkövetés 2.1 Történet A sugárkövetés története igen messzire nyúlik vissza. Napjainkban, mint egy számítógépes képalkotási technikaként emlegetik, de valójában nem feltétlenül szükséges számítógép az alkalmazásához. Mielőtt megállapítanánk,hogy ki és mikor valósította meg az első sugárkövetéses digitális képi ábrázolást, érdemes meghatározni tágabb értelemben, hogy mi szükséges ehhez a módszerhez, milyen technikai és számítási előfeltételei vannak. Ahogy a nevében is benne van,,sugarak követése. Akár papíron szerkesztve, mechanikusan vagy automatizálva végezzük, a lényege ugyanaz marad. Adott pontból kiindulva követjük a fénysugár útvonalát és útvonalának módosulását a vele kölcsönhatásba lépő felületek függvényében. A képen megjelenő színeket pedig néhány alapvető fizikai jelenség határozza meg, úgymint (a teljesség igénye nélkül) a testek színe, anyagi tulajdonsága (például csillogó vagy matt felülettel rendelkeznek e), tükröződése,és az, hogy árnyékban van-e. A sugárkövetés nem valósulhatott meg a perspektivikus vetítés és az ehhez szükséges matematikai ismeretek nélkül. A perspektíva ábrázolásához szükséges matematikai módszereket az 1500-as évek elején kezdték alkalmazni. A perspektivikus vetítés első alkalmazása reneszánsz festők és építészek nevéhez köthető, úgymint Leon B. Alberti, Leonardo da Vinci, Bramante és Rafaello. [1] 3

8 2.1 ábra. Rafaello Athéni iskola című festménye. [2] E művészek már képesek voltak vászonra vinni a perspektívát, amit kitűnően példáz Rafaello Athéni iskola című festménye (2.1 ábra). Az alkotáson a térbeli ábrázolás mellett az árnyékok megjelenítését is láthatjuk. A reneszánsz festő és matematikus, Albrecht Dürer nevét is érdemes megemlíteni, aki egy szerkezet megépítésével tette egyszerűbbé a térbeli hatások vásznon való pontos ábrázolását (2.2 ábra). 2.2 ábra. Albert Dürer szerkezete használat közben. [3] Tanulmánya két könyvben is megjelent 1525-ben és 1538-ban (mindkettőt Underweysung der messung címmel publikálták). Dürer a könyveiben többek között írt a perspektivikus vetítés alkalmazásáról, illetve a fények és az árnyékok ábrázolásáról. Felismerte, hogy az árnyék a tér azon részén keletkezik, amely takarásban van a fényforrás elől. [1] 4

9 Arthur Appel 1968-ban megjelent publikációjában [4] leírja, hogy a geometria a testek ábrázolásában nagy segítség lehet, ha a kontúr vonalak helyett a fény által vetett árnyék, illetve a felületek tónusa és színe kerül megjelenítésre. Turner Whitted néhány évvel később ennél tovább megy, és leírja a rekurzív sugárkövetést, amivel már sokkal látványosabb eredményt lehet elérni. [5] A 2.3 ábrán látható egy Whitted algoritmusával készült kép, amelyen már a tükröződés és fénytörés is megvalósul, továbbá a testeken megcsillanó fény is megjelenik. 2.3 ábra. Turner Whitted algoritmusával készült kép. [5] Turner Whitted publikációja után a sugárkövetés nem terjedt el a gyakorlatban a nagy számításigénye miatt. Helyette az inkrementális képszintézis indult fejlődésnek, amit hardveresen is támogatni kezdtek GPU-val. A GPU bár kevésbé jó minőséggel, de sokkal gyorsabban képes a valós idejű grafikus alkalmazások támogatására. Az 1990-es években jelent meg a DirectX és az OpenGL API [6], amelyek támogatást nyújtottak a grafikus hardverekre történő fejlesztéshez. Ekkor a sugárkövetés még mindig háttérbe szorult, sem a GPU, sem a CPU nem rendelkezett kellő számítási kapacitással, hogy támogatni tudja ezt a módszert. 5

10 Ráadásul a GPU még az úgynevezett fix funkciós csővezetékkel rendelkezett, ami korlátozta a fejlesztőket a grafikus hardver lehetőségeinek a teljes kihasználásában. Nagyobb előrelendülést a késői 90-es években megjelent SSE utasítás készlet, illetve a 2000-es években piacra dobott több magos processzorok jelentették ben megjelent az NVIDIA CUDA néven futó GPGPU (General Purpuse GPU) API-ja [7], majd egy évre rá a Khronos Group OpenCL API-ja, [8]amelyek a grafikus hardver általános célú felhasználását tették lehetővé. A CPU és GPU jelentős fejlődésének köszönhetően ismét előtérbe került a sugárkövetés, bár továbbra sem vált alkalmassá a hagyományos számítógépi grafikában alkalmazott technológia lecserélésére. Érdemesnek tartom még megemlíteni a 2005-ös SIGGRAPH konferencián bemutatott RPU (Ray Processing Unit) architektúrát [9], amely egy kifejezetten sugárkövetésre tervezett hardver. Az RPU egy kísérlet volt a processzor és a grafikus hardver előnyeinek ötvözésére, így alkalmassá téve a sugárkövetésen alapuló valós idejű alkalmazás támogatására. Az alapot egy 66 MHz-es FPGA adta, és bár csak 20 FPS-re volt képes, mégis felülmúlta az akkori csúcskategóriás személyi számítógépekkel elérhető sebességet. Jól látható, hogy a sugárkövetés végigkíséri az informatika fejlődését, és folyamatos próbálkozások látnak napvilágot arra törekedve, hogy valós idejű szoftverekben alkalmazható legyen. Az alábbi fejezetekben szeretném bemutatni a főbb különbséget a raszteres grafika és a sugárkövetés között, majd ezt követőenismertetni a konkrét implementációmat a sugárkövetés gyorsítására a CPU lehetőségeit kihasználva. 2.2 Képszintézis [10] Képszintézisről (rendering vagy magyarosítva renderelés) beszélünk, amikor egy virtuális világról egy kétdimenziós kép készül. Akárcsak a valóságban egy fényképezőgéppel, e módszerrel is egy adott nézőpontból fényképezzük le a virtuális világot. Ezt a folyamatot raszterizációnak is nevezzük, hiszen a 6

11 végeredményül kapott kép legkisebb egysége a raszter vagy más néven a pixel. Érdemes még megjegyezni, hogy a pixel színének meghatározására különböző színtér modellek léteznek. Én az egyik legegyszerűbb színtér modellt választottam, az RGB-t. [11] A képszintézis két fő csoportra osztható. Az egyik a fotorealisztikus képszintézis, amelynek során a természet folyamatait szimuláljuk. Ebbe a csoportba tartozik a sugárkövetés, amelynek előnye, hogy általa élethű képeket készíthetünk. Valósidejű programokban azonban nem terjedt el a lassúsága miatt. A másik csoport az inkrementális képszintézis, ami egyszerűbb algoritmussal dolgozik, így valós idejű grafikus szoftverekben való felhasználásra is alkalmas. Bár csak közelíti vagy utánozza a fény tulajdonságait, egyszerűsége nem akadályozza meg a jó minőségű képszintézist. Továbbá hardveres támogatást is kap, ami kifejezetten a grafikus program írását támogatja. Az inkrementális képszintézis és a sugárkövetés is ugyanazt a problémát oldja meg: a háromdimenziós térben elhelyezett objektumokról eldönti, hogy melyik lesz látható a képen (láthatóság vizsgálat), majd ezt követően árnyalja vagyis különböző fényhatásokat, effekteket ad a képhez. A láthatóság vizsgálat kétfélképpen történhet, és itt mutatkozik meg a különbség az inkrementális képszintézis és a sugárkövetés között. Inkrementális képszintézis során először rávetítjük az objektumokat a kétdimenziós képre, majd e kép minden pixelét megvizsgáljuk, hogy fedésben van e valamely, a képre vetített objektummal. Amennyiben fedésben van, kitöltjük az adott pixelt az objektum színével (2.4 ábra). 7

12 2.4 ábra. Háromszög rajzolása inkrementális képszintézissel. Ezzel szemben a sugárkövetés először a kép pixelein halad végig, és azt vizsgálja, hogy mely objektumok láthatóak az adott pixelen keresztül. Ha a kamerából, az adott pixelen át kilőtt sugár ütközik egy objektummal, akkor ebben az ütközési pontban történik az árnyalás (2.5 ábra). Így tehát a láthatóság vizsgálat és az árnyalás az egyes pixeleken egymástól függetlenül történik. 2.5 ábra. Háromszög rajzolása sugárkövetéssel. 2.3 Metszéspont vizsgálat Az algoritmusnak egy fontos része a metszéspont vizsgálat. Ekkor dől el, hogy az adott fénysugár metszi-e valamely, a jelenetben elhelyezett tárgyat, és ezáltal látható-e a tárgy vagy annak egy része a képen. Az objektum anyagtulajdonságától függően a metszéspontban dől el a fénysugár további sorsa. Például egy tükröződő felület esetében a fénysugár visszaverődve a felületről továbbhalad. A metszéspont vizsgálat egyszerűbb objektumok esetén mint például gömb, henger vagy kúp történhet geometriai vagy analitikus módszerrel. Egészen addig, amíg ezeket a primitív formákat szeretnénk megjeleníteni, a vizsgálat nem okoz különösebb nehézséget. Például a kör, kocka, síkfelületek leírása és sugárral való ütközés vizsgálata tehát roppant egyszerű, azonban bonyolultabb, térbeli formák esetében már nehezebb dolgunk van, ráadásul a számítási idő növekedésére is számíthatunk. Erre megoldást jelent a számítógépi grafikában elterjedt megoldás, a poligon alapú ábrázolás. A poligon a legegyszerűbb forma, 8

13 amit egy háromdimenziós térben ábrázolhatunk. Gyakorlatilag egy háromszögről van szó, amit három pont vagy más néven három vertex határoz meg. Fontos tulajdonsága továbbá a normál vektor, ami a poligon síkjára állított irányvektor, tehát merőleges a poligon síkjával. A munkámban a poligon szerepe azért lényeges, mert minden alakzat lebontható véges számú poligonra, így a metszéspont vizsgálat során csupán háromszögek és sugár ütközéspontját kellett kiszámítanom. 2.6 ábra. Sugár háromszög metszése. A háromszög és sugár metszéspont meghatározására a Tomas Möller és Ben Trumbore által1997-ben publikált algoritmust használtam [12]. A hagyományos módszerrel szemben itt nem szükséges a háromszög síkjának egyenletét kiszámolni és eltárolni. Csupán a háromszöget meghatározó három pontra és a sugár (egyenes) egyenletére van szükség. A metszéspont meghatározása egy O kiindulási pont, egy D irányvektorral meghatározott sugár és egy ABC háromszög (2.6. ábra) esetében az alábbi egyenlettel történik: t u v = Q E 2 1 P T P E 1 Q D (2.1) ahol t a sugár kiindulási pontja és a sugár háromszög metszéspont közötti távolság u és v a háromszög baricentrikus koordinátáiban megadott metszéspont 9

14 E 1 és E 2 rendre a háromszög AB és AC élét alkotó vektorok T a sugár O kezdőpontjának és a háromszög A csúcsának különbsége P = D E 2 Q = T E 1 Az algoritmus ebben az állapotában igen egyszerű, csupán azt vizsgálja, hogy a fénysugár ütközik-e az objektummal. A RTTracer::castIntersection függvény végigiterál a jelenet objektumain, és visszatér a kamerához legközelebb elhelyezkedő fénysugarat metsző RTObject példánnyal, majd beállítja az adott pixel színét az objektum színének megfelelően. void RTTracer::castIntersection(RTRay &ray, RTVector &color,const int &depth) { float distance = std::numeric_limits<float>::max(); unsigned int triangleindex = std::numeric_limits<unsigned int>::max(); float u, v; RTObject *object =Trace( ray, distance, u, v, triangleindex ); if ( object ) { color = object->getcolor(); } } Ütközésvizsgálattal az 2.7 ábrán látható eredményt kaptam. Az algoritmus a fény fizikai tulajdonságainak szimulációja hiányában csak az objektum sziluettjét képes megjeleníteni a hozzá beállított színre festve. 10

15 2.7 ábra. Gömb rajzolása ütközésvizsgálattal, árnyalás hiányában Baricentrikus koordináták [13] A háromszög és sugár metszéspontjának meghatározása közben megkapom az ütközéspont baricentrikus koordinátáit is. Egy A, B és C pont által meghatározott háromszögön elhelyezkedő P pont baricentrikus koordinátákkal kifejezve: P = ua + vb + wc (2.2) ahol u, v és w a baricentrikus koordináták, amelyekre az alábbi összefüggés írható fel: 1 = u + v + w (2.3) A baricentrikus koordinátákat később, az árnyalás simítása ( alfejezet) során felhasználom. 2.4 Árnyalás Ahhoz, hogy az objektumoknak ne csak a sziluettjét lássuk, árnyalás alkalmazására van szükség. Ezzel a kiegészítéssel már térhatást adunk a jelenet 11

16 tárgyainak úgy, hogy az árnyalás során a szín mellett a fény intenzitását is meghatározzuk az adott metszéspontban Diffúz felületek A diffúz vagy más néven matt felületek egyenletesen szórják szét a fényt az ütközéspontban. Ezt a hatást a Lambert-törvény [14] alkalmazásával valósítottam meg. A törvény kimondja, hogy egy vizsgált diffúz pontra érkező fény mennyisége arányos a beeső fény iránya és a felület normálvektora által bezárt szög koszinuszával. A bezárt szög koszinusza kifejezhető a két egységvektor skaláris szorzatával (2.8 ábra). 2.8 ábra. Lambert-féle koszinusz törvény. cos α = N L (2.4) Ahol N a metszéspontban a felületre állított normál vektor, L a metszéspontból a fényforrásra mutató irányvektor és α az N és L vektorok által bezárt szög. A 2.9 ábrán három esetet szemléltetek. Első esetben a felület normál vektora és a fénysugár iránya párhuzamos. Ekkor a fény intenzitása maximális. Második esetben a két vektor szöget zár be. Jól látható, hogy a beeső fénysugár nagyobb felületet (L) fed le, mint a vizsgált A felület, tehát ugyanazon mennyiségű foton egy nagyobb felületen oszlik el. Így a második esetben gyengébb intenzitást kapunk. A 12

17 harmadik példában a fénysugár iránya merőleges a felület normálvektorára. Ekkor nem éri fény a felületet, így nem kap megvilágítást. 2.9 ábra. Fény intenzitása a beesési szög függvényében A diffúz árnyalás alkalmazásával a 2.10 ábrán látható eredményt kaptam ábra. Gömb rajzolása diffúz megvilágítással Árnyalás simítása A alfejezetben kapott képen látható, hogy a gömbön az átmenet a jól megvilágított felület és az árnyékos oldal között darabos. Ahhoz, hogy ez az átmenet sima legyen, akár csak egy valóságban megvilágított diffúz felületű gömbön, bevezetem az árnyalás simítását. 13

18 A jelenlegi megoldásban az egyes poligonokra állított normálvektort használtam a fény intenzitásának kiszámításához (2.4 képlet). Mivel a normálvektor (N) és a visszaverődő fény iránya (L) is megegyezik a poligon minden pontjában, ezért a fény intenzitása kapcsán is egyezés tapasztalható az adott poligon teljes felületén. Ezt az angol szakirodalom flat shading-nek nevezi. Annak érdekében, hogy a flat shading-nél jobb eredményt kapjak, növelhetném az objektumokat alkotó poligonok számát, de ezzel jelentősen megnövekedne a felhasznált memória az adatok tárolása során, ugyanakkor az ütközésvizsgálat ideje is megnőne. A fény intenzitásának sima átmenetét tehát úgy kell megoldani, hogy nem növelem a poligonok számát. Ehhez a Gouraud-árnyalást választottam. A módszer lényege, hogy a háromszögek csúcspontjaiban kiszámítom az intentzitást, majd a csúcsponok között, a háromszög egyes pontjaiban interpolálom a csúcspontokban kapott intenzitásokat (2.11 ábra). [15] 2.11 ábra. Intenzitások interpolálása A háromszög csúcspontjaira eső normálvektorokat előre kiszámolom és tárolom, úgy, hogy az adott csúcspontban találkozó háromszögek normálvektorát átlagolom. Az interpoláció viszont renderelés közben történik az ütközéspontban meghatározott baricentrikus koordinátákkal: float dot = 0.f; float dots[3]; for ( unsigned int i = 0; i < 3; i++ ) { dots[i] = RTVector::DotProduct( hitnormals[i], -lightdirection ); } dot = ( 1 - u - v ) * dots[0] + u * dots[1] + v * dots[2]; _color += shadow * object->getcolor() * intensity * std::max( 0.0f, dot ); 14

19 Az interpolált normálvektorokkal a 2.12 ábrán lévő gömböt kaptam, amely láthatóan simább átmenettel rendelkezik az árnyékos és a megvilágított felület között ábra. Gömb rajzolása Gouraud-árnyalással Spekuláris hatás A diffúz hatás mellett egy másik jelenség is látható, ez pedig a csillogó hatás: a fényes felületeken megfigyelhető egy-egy pont, amiben összesűrűsödve visszaverődik a fény. Az árnyalás során így bevezetek egy másik komponenst is, ami a diffúz hatással együtt lesz jelen, amennyiben az adott objektum anyagára jellemző a csillogó felület. A spekuláris hatásról Bui Toung Phong 1975 ben publikált [16]. A csillogó hatás ábrázolásához a megfigyelő nézőpontját és a felületről visszaverődő fény irányát vette alapul. Az objektumon megjelenő csillogó pont ott a legerősebb, ahol a fényforrás tükörképe megjelenne, ha egy tükröződő felületnek vennénk az objektumot. Ettől a ponttól távolodva a csillogás mértéke csökken, és fokozatosan átmegy a matt felület színébe. Phong ezt a hatást úgy számította ki, hogy meghatározta a fényforrás visszaverődésének irányát a metszéspontban, majd ennek és a nézőpont irányának a skaláris szorzatát vette (2.13 ábra és 2.5 képlet). 15

20 2.13 ábra. Spekuláris komponens spekuláriskomponens = (V R) n (2.5) Ahol N a metszéspontban a felületre állított normál vektor, L a beeső fénysugár, R a metszéspontban visszaverődő fénysugár és V a metszéspontból a nézőpontba mutató irányvektor. Ahogy a nézőpont iránya és a fényforrás visszaverődésének iránya között nő a szög, úgy csökken a skaláris szorzat értéke. Az így kapott csillogó pont az objektumon túl nagy területet fed le, ezért Phong n-edik hatványra emelte az egyenletet. Az n növelésével láthatjuk, hogy változik a spekuláris komponens mérete (2.14 ábra). Az n értéke balról jobbra 25, 50 és

21 2.14 ábra. Az n komponens hatása A diffúz és spekuláris komponenseket összegezve kapjuk meg az objektum végleges árnyalását. A 2.6 képlet a 2.4 és 2.5 összegzéséből adódik. C p = C(k d (N L) + k s V R n ) (2.6) Ahol Cp a végleges szín az adott pontban, C az objektum színe. K d és K s a diffúz és spekuláris hatás arányát fejezi ki, és a következő összefüggés igaz rájuk: 1 = k d + k s (2.7) Vegyük figyelembe, hogy Phong modellje tapasztalati, tehát az n, k s és k d változóknak nincs fizikai jelentőségük, nekünk kell beállítani úgy, hogy a kívánt eredményt elérjük. Alacsony n érték esetén a csillogó hatás erőteljes lesz, így érdemes a spekuláris összetevőt csökkentenünk. A 2.15 ábrán látható három esetben az n értéke 10, és balról jobbra haladva a k s értéke 0.7, 0.5 és

22 2.15 ábra Árnyék A raszteres grafikával szemben a sugárkövető algoritmus alkalmazásakor az árnyék megjelenítése sokkal egyszerűbb. Míg az előbbi technológiánál olyan trükk alkalmazásával lehet árnyékot rajzolni, mint például az árnyék térkép (shadow map), addig a sugárkövetés esetében a renderelés folyamata során meghatározhatjuk, hogy az adott pont árnyékban van-e vagy sem. Ehhez csupán egy újabb sugarat kell indítani az adott pont és a fényforrás között. Ha az újonnan indított sugár metszi valamely másik objektumot mielőtt a fényforrást eléri (2.16 ábrán P 1 pont), akkor a vizsgált pont árnyékban van. Amennyiben a fénysugár nem ütközik akadályba,akkor az adott pontra elvégezzük az árnyalást (2.16 ábra P 2 pont). 18

23 2.16 ábra. Árnyék a sugárkövetésben Az árnyék kiszámítása az alábbiakban látható. A példa algoritmus egy fényforrással dolgozik, amelyet a Scene->getLight( 0 ) függvénnyel kérek le. A shadowray az újonnan létrehozott árnyéksugár, amely az ütközéspontból indul, és a light fényforrás felé tart. Ha az árnyéksugár nem ütközött egy objektummal sem, akkor atrace függvény nullptr értékkel tér vissza. Ezt az értéket felhasználva döntöm el, hogy a metszéspont árnyékban van-e. RTVector lightdirection; RTVector intensity; RTLight *light = Scene->getLight( 0 ); light->illuminate( hitpoint, lightdirection, intensity ); float distanceshadow = std::numeric_limits<float>::max(); RTRay shadowray( hitpoint + hitnormal, -lightdirection ); RTObject *shadowobject = Trace( shadowray, distanceshadow ); float shadow = shadowobject == nullptr? 1.f : 0.f; float diffuse = RTVector::DotProduct( hitnormal, -lightdirection ); _color += shadow * object->getcolor() * intensity * std::max( 0.0f, diffuse ); Több irányból történő megvilágítás esetében minden egyes fényforrással kiszámítom az árnyalást az adott metszéspontra, majd összegzem a kapott eredményeket. Két fényforrás használatával a 2.17 ábrán látható képet kaptam. 19

24 Jól látható, hogy a felület azon részén halványabb az árnyék, ahová csak az egyik fényforrás által okozott árnyék vetül, míg a két árnyék kereszteződésében fekete ábra. Árnyék két fényforrás esetén Tükröződés Rekurzió A tükröződés bevezetésével a sugárkövető algoritmus rekurzívvá válik. Mikor az elsődleges sugár (a kamerából indított sugár) egy tükröződő felületet metsz, akkor onnan visszaverődve továbbhalad, és az algoritmus úgymond újraindul. Meg kell vizsgálni, hogy a továbbhaladó fénysugár ütközik-e újabb objektummal, fényforrással vagy a végtelenbe halad tovább. Amennyiben újabb objektummal ütközik, annak anyagtulajdonsága határozza meg a fénysugár további sorsát. Ha a metszéspontban ismét tükröződő a felület, akkor az algoritmus ismét újraindul az újonnan generált sugárral. Ez egészen addig ismétlődik, amíg a fénysugár tükröződő felületet metsz. Ha nagyszámú felület rendelkezik tükröződő tulajdonsággal, akkor jelentősen megnő a számítási idő. Ennek kivédésére egy kilépési feltételt határoztam meg, amivel a rekurzió mélysége korlátozva van. A 20

25 2.18ábrán egy példa látható többszörös tükröződésre. A kamera mögött hat kockát helyeztem el, amik közül a középső kettő fényvisszaverő tulajdonsággal rendelkezik, éppúgy, mint a szemben elhelyezett gömb. Bár kis méretben, de látható, hogy a gömbben tükröződő középső kockákon megjelenik a piros henger objektum ábra. Többszörös tükröződés Tükröződés számítása [17] A tükröződés vagy fényvisszaverődés az egyik legegyszerűbb fénytani jelenség, amit már Euklidesz Kr. e. 300 körül leírt. A fényvisszaverődésre az alábbi két állítás igaz: 1. A beeső fénysugár, a beesési merőleges és a visszavert fénysugár egy síkban van. 2. A visszaverődési szög egyenlő a beesési szöggel. Ahol a beeső fénysugár a felülethez tartó fénysugár visszavert fénysugár a felülettől távolodó fénysugár beesési merőleges a metszéspontban a felületre állított merőleges, vagyis a vizsgált háromszögre állított normál vektor beesési szög a beeső fénysugárnak a beesési merőlegessel bezárt szöge 21

26 visszaverődési szög a visszavert fénysugárnak a beesési merőlegessel bezárt szöge 2.19 ábra. Fényvisszaverődés. A visszaverődés kiszámításához venni kell a beeső fénysugár irányvektorát (I) és a beesési pontban a felületre állított normál vektort (N) (2.19 ábra).ekkor felírhatunk két segéd irányvektort, amelyek szükségesek a további számításokhoz. Ez a két vektor az S és V, amelyekkel kifejezhető az I és O vektor. I = S + V (2.8) O = S V (2.9) A V vektor az I vagy O vektor vetülete az N normálvektoron, és felírható az alábbi egyenlettel: V = cos (α) N (2.10) A 2.8 és 2.9 egyenletekbe behelyettesítve a 2.10-es egyenletet az alábbi összefüggéseket kapjuk: I = S + cos α N (2.11) O = S cos α N (2.12) A 2.11-es egyenletet átrendezve: 22

27 S = I cos α N (2.13) Majd ezt behelyettesítve a 2.12 egyenletbe kifejezhetjük az O vektort. O = I cos α N cos α N (2.14) A 2.14 egyenletet rendezve és az ismert összefüggést felhasználva (vagyis két egység vektor skaláris szorzata a két vektor közötti szög koszinuszával egyenlő) megkapjuk az O vektort kifejező összefüggést: O = I 2 N I N (2.15) A visszaverődés implementációja a saját RTVector osztályokat felhasználva a következőképpen néz ki: RTVector RTTracer::reflect( const RTVector &incident, const RTVector &normal ) { return incident - 2.0f * RTVector::DotProduct( incident, normal ) * normal; } 23

28 3 SIMD 3.1 Történet [18] Az SIMD a Single Instruction Multiple Data rövidítése, amely a Flynn-féle osztályozás [19] egy eleme (3.1 táblázat). Jelentése: egy utasítás több adat. A SIMD olyan számítógépek osztályát írja le, amelyek képesek egy időben ugyanazt a műveletet több adaton elvégezni. Egy utasítás Több utasítás Egy adat SISD MISD Több adat SIMD MIMD 3.1 táblázat. Flynn-féle osztályozás Az első SIMD-t megvalósító számítógép 1966-ban jelent meg ILLIAC IV néven. Az architektúra 256 darab 64 bites FPU-t tartalmazott, és négy CPU-val rendelkezett, amelyek másodpercenként egy milliárd művelet elvégzésére voltak képesek. Igaz a termék végső változatába költségvetési megszorítások miatt csak egy CPU került 64 darab FPU-val.Az 1970-es években megjelent vektor szuperszámítógépeknek továbbra is az SIMD képezte az alapját. Ilyen volt például a Texas Instruments ASC, amelynek processzora egy egydimenziós tömbben tárolt adatokkal való műveletvégzésre volt felkészítve úgy, hogy egy utasítást párhuzamosan több adaton hajtott végre. Az első modern SIMD-t megvalósító számítógépek masszívan párhuzamos rendszerre épülő szuperszámítógépek voltak, mint például a Thinking Machines CM-1 és MC-2, amelyek igen limitált képességű, de párhuzamosan működő processzorokat tartalmaztak. Később a szuperszámítógépek áttértek az MIMD megvalósítására. A mai SIMD technológiát alkalmazó processzorok az asztali számítógépek piacából nőtték ki magukat. Amint elérték azt a teljesítményszintet a számítógépek, hogy támogatni tudják a valós idejű grafikus programok fejlesztését, illetve a hang és képfeldolgozást, megjelent az igény az SIMD megvalósítására ben a Sun Microsystem bemutatta a VIS névre keresztelt 24

29 utasítás készletét, amely az UltraSPARC I nevezetű mikroprocesszorban került megvalósításra. Az SIMD technológiának az első széles körben elterjedt megvalósítása 1996-ban jelent meg az Intel x86 architektúra MMX nevű kiterjesztéseként ben szintén az Intel bemutatta az új SIMD kiterjesztést, az SSE-t (Streaming SIMD Extension), amely napjainkig fejlődik, és már támogatást nyújt mind az x86, mind a 64 bites architektúrákhoz. Az Intel mellett más gyártók sem maradtak el az SIMD technológia megvalósításában. Az AMD 3DNow! néven jelentette meg, az ARM architektúrákban pedig NEON névre lett keresztelve, és ezzel a mobiltelefonokon is elérhetővé vált az SIMD technológia. 3.2 Intel intrinsic függvények C és C++ nyelvhez elérhető egy úgynevezett beépített függvénykészlet (angolul intrinsic functions). Ezzel a függvénykészlettel egyszerűbbé válik a fejlesztés, mert nem kell assembly nyelven megírni az egyes műveleteket. A kiterjesztés használatához be kell illeszteni a megfelelő header fájlt vagy fájlokat, attól függően, hogy egy vagy több verzió funkcióira van szükségünk. Minden egyes verzióhoz külön header fájl tartozik (3.2 táblázat), de az x86intrin.h fájl beillesztésével az összes verzió funkciója elérhetővé válik. A függvények alkalmazásához segítséget nyújt az Intel Intrinsic útmutatója. [20] [21] Verzió SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Header xmmintrin.h emmintrin.h pmmintrin.h tmmintrin.h smmintrin.h nmmintrin.h 3.2 táblázat. SSE verziók és a hozzájuk tartozó header fájlok. 25

30 3.3 SSE változók [21] Az SSE használatához az Intel nyolc darab speciális regisztert biztosít, amiket az xmm0, xmm1, xmm7 nevek jelölnek. Míg a hagyományos regiszterek skalár értékeket tárolnak, és méretük lehet például 32 bit vagy 64 bit, addig az SSE regiszterek lényegesen hosszabb, 128 bit méretűek. Ez utóbbiakat vektor típusként kezeljük, aminek köszönhetően megvalósulhat az, hogy több változón egyszerre, ugyanazt az utasítást hajtsuk végre m128 és m64 Az első verzióban az m128 és m64vektor típusok használhatóak. A típus nevében a szám a bitszélességre utal. Az m128 négy darab 32 bites lebegőpontos számot tud tárolni. Az m64 típus a korábbi, MMX nevű kiterjesztésből maradt fent, és használható továbbra is az MMX függvényekkel együtt. Az m64 típus nyolc darab 8 bites, négy darab 16 bites, két darab 32 bites és egy darab 64 bites egész számot tud tárolni m128d Az m128d vektor az SSE2 verziótól érhető el, és két darab 64 bites lebegőpontos számot tud tárolni m128i Az m128i vektor szintén az SSE2 verziótól érhető el, és hasonlóan az m64vektorhoz, nyolc darab 8 bites, négy darab 16 bites, két darab 32 bites és egy darab 64 bites egész számot tud tárolni. 3.4 SSE függvények [20] Minden egyes SSE utasításhoz, amelyekkel számításokat végezhetünk a vektor adatokon, tartozik egy C függvény implementáció. A függvények elnevezése egy egységes konvenció alapján történik. A név három részre bontható: 26

31 _mm_<utasítás>_<utótag> Az eleje mindig az mm előtaggal kezdődik, amit az utasítás megnevezése követ. A harmadik része az utótag, amely azt jelöli, hogy az adott függvény milyen típusú adatokat vár bemenő paraméterként. Az utótag első betűi lehetnek p (packed), ep (extended packed) vagy s (scalar), amit a típus megnevezése követ. Az egyes típusok a 3.3 táblázatban láthatók. Utótag s d i128 i64 u64 i32 u32 i16 u16 i8 u8 Jelentés lebegőpontos szám duplapontos lebegőpontos szám előjeles 128 bites egész szám előjeles 64 bites egész szám előjel nélküli 64 bites egész szám előjeles 32 bites egész szám előjel nélküli 32 bites egész szám előjeles 16 bites egész szám előjel nélküli 16 bites egész szám előjeles 8 bites egész szám előjel nélküli 8 bites egész szám 3.3 táblázat. Például, ha szeretnénk két darab,float típusú számokat tartalmazó vektort elemenként összeszorozni, akkor arra az alábbi függvény használható. _mm_mul_ps( m128 a, m128b ) A float vektorok összeadása pedig az alábbi módon történik. _mm_add_ps( m128 a, m128b ) SSE Az első verzió tartalmazza azokat a függvényeket, amelyek segítségével betölthetjük az adatokat az SSE regiszterekbe, illetve kiolvashatjuk az adatokat az SSE regiszterekből. Ezen felül aritmetikai, logikai, összehasonlító műveletekhez és a gyorsítótár eredményesebb kihasználásához nyújt támogatást. 27

32 3.4.2 SSE2 Nagyrészt az előző verzióval megegyező függvényeket tartalmaz az újonnan megjelent _m128d és _m128i típusokhoz SSE3 A legfontosabb újítása a harmadik verziónak, hogy nem csak vertikálisan képes műveletvégzésre, hanem horizontálisan is egy adott SSE regiszteren belül. Például az _mm_add_ps( m128 a, m128b ) függvény az a és b regisztert adja össze (vertikálisan) az alábbi módon: a0 + b0; a1 + b1; a2 + b2; a3 + b3; Az _mm_hadd_ps( m128 a, m128b ), ami horizontális összeadást valósít meg, az a és b regiszter szomszédos elemeit összegzi a regisztereken belül az alábbi módon: a0 + a1; a2 + a3; b0 + b1; b2 + b3; SSSE3 Az SSE3 verzió kiegészítése, amelyben további adattípusokon válik lehetővé a horizontális műveletvégzés,ugyanakkor kiegészül két permutáló függvénnyel, amely 8 bites előjel nélküli számokat tud permutálni az m64 és m128i regiszterekben. 28

33 3.4.5 SSE4.1 és SSE4.2 A negyedik verzió két alverzióra bontható. Az SSE4.1forráskód fordításhoz és multimédiás alkalmazásokhoz nyújt támogatást. AzSSE4.2függvényeivel string típusok összehasonlítását végezhetjük, továbbá CRC támogatást nyújt hibafelismeréshez, emellett kiegészül két függvénnyel, amelyek 32 és 64 bites előjel nélküli egész számokban található egy értékű bitek számát adják vissza. 3.5 Feltételes utasítás [20] Vektorizáció során a feltételes vezérlés használata nem ajánlott. Ha a hagyományos if, else if, else utasításokat szeretném használni, akkor előbb ki kell olvasni az SSE vektorban tárolt adatokat, elvégezni a feltételes utasítást, majd visszatölteni az eredményt az SSE vektorokba további műveletvégzéshez. Mivel az adatok be-és kiolvasása költséges művelet, ezért más megoldást választottam. Az SSE kiterjesztés lehetőséget ad adatok összehasonlítására. A teljesség igénye nélkül a leggyakoribb alap összehasonlító függvények az alábbiak m128 vektorokkal való műveletvégzés esetén. m128 _mm_cmpeq_ps( m128 a, m128 b) Az a és b vektor elemei közötti egyenlőséget vizsgálja. m128 _mm_cmpge_ps( m128 a, m128 b) Az a vektor elemei nagyobb vagy egyenlő relációban állnak-e a b vektor elemeivel. m128 _mm_cmpgt_ps( m128 a, m128 b) Az a vektor elemei nagyobb relációban állnak-e a b vektor elemeivel. m128 _mm_cmple_ps( m128 a, m128 b) Az a vektor elemei kisebb vagy egyenlő relációban állnak-e a b vektor elemeivel. m128 _mm_cmplt_ps( m128 a, m128 b) Az a vektor elemei kisebb relációban állnak-e a b vektor elemeivel. 29

34 A visszatérési értéke a függvényeknek egy m128 vektor, amely egy maszk az összehasonlítás eredményéről. 3.6 Adatok betöltése [20] Mielőtt műveleteket végeznék az adatokon, be kell tölteni őket a megfelelő regiszterekbe. Erre két fajta függvény áll rendelkezésre: a set és a load. Diplomamunkámban float típusokkal dolgozok, így a továbbiakban az erre alkalmas m128változóval mutatok példákat. m128 _mm_set_ps( float e3, float e2, float e1, float e0 ) A set függvény szintén négy darab 32 bites float számot tölt be a paraméterként átadott e3, e2, e1 és e0 változókból. Fontos megjegyezni, hogy a set függvény használatakor az SSE regiszterekben lévő adat jobbról balra van reprezentálva. Amennyiben fordított sorrendben szeretnénk betölteni az adatokat, akkor rendelkezésre áll az m128 _mm_setr_ps( float e3, float e2, float e1, float e0 )függvény. A load függvény négy darab 32 bites float számot tölt be a paraméterként átadott memóriacímről. m128 _mm_load_ps( float const* mem_addr ) Visszatérési értéke egy m128 típus, amely a négy darab float számot tárolja. Ebben az esetben az adat sorrendje ugyanúgy van reprezentálva az SSE regiszterben, mint az eredeti memóriaterületen. A load függvénynek is van ellentétes adatsorrendet biztosító változata: m128 _mm_loadr_ps( float const* mem_addr ) 3.7 Adatok kiolvasása [20] [21] Ahogy a esalfejezetben említem, az SSE regiszterben tárolt adatok közvetlen elérése nem lehetséges, és az union struktúra alkalmazása nem ajánlott. Lehetőség van azonban arra, hogy a regiszter alacsony helyi értékén 30

35 elhelyezkedő float elemet kinyerjük az alábbi függvénnyel, amelynek bemenő paramétere egy SEE vektor, visszatérési értéke pedig egy float típusú szám. float _mm_cvtss_f32( m128 a ) Ahhoz, hogy a további három elemet is megkapjuk, egyenként át kell helyezni őket az alacsony helyi érték pozíciójába, majd onnan ismét kiolvasni az _mm_cvtss_f32 függvénnyel. Az SSE regiszteren belül az elemek cseréje a következő függvénnyel valósul meg: m128 _mm_shuffle_ps( m128 a, m128 b, unsigned int imm8 ) A függvény a paraméterként kapott a és b vektorokbólegy maszk segítségével összeállít egy harmadik vektort, amely a függvény visszatérési értéke lesz. A maszkot a harmadik, unsigned int típusú paraméterrel adjuk meg. 3.1 ábra. A maszk paraméter egy 8 bites, úgynevezett közvetlen érték, ami négy darab 2 bites számból áll (3.1 ábra). A négy szám, amelyek 0 és 3 közötti értékeket vehetnek fel, adják meg, hogy mely elemek kerüljenek bele a harmadik SSE vektorba. Jobbról balra haladva az első két index az a vektorból jelöl ki két elemet, a második kettő pedig a b vektorból. A függvény végül visszatér az újonnan létrehozott vektorral. Hogy egyszerűbb legyen a dolgunk, az SSE könyvtár biztosít egy _MM_SHUFFLE( a, b, c, d ) makró függvényt, amivel megadhatjuk a négy darab 0 31

36 és 3 közötti indexet. Az alábbiakban látható példakódban a v vektor négy float elemét olvasom ki, és helyezem el az a tömbben. float eredmeny[4] = { 0.0f }; eredmeny[0] = _mm_cvtss_f32( v ); eredmeny[1] = _mm_cvtss_f32( _mm_shuffle_ps( v, v, _MM_SHUFFLE( 1, 1, 1, 1 ) ) ); eredmeny[2] = _mm_cvtss_f32( _mm_shuffle_ps( v, v, _MM_SHUFFLE( 2, 2, 2, 2 ) ) ); eredmeny[3] = _mm_cvtss_f32( _mm_shuffle_ps( v, v, _MM_SHUFFLE( 3, 3, 3, 3 ) ) ); 3.8 Adat illesztés Amikor SSE vektorokkal dolgozunk, fontos, hogy az adat amit az_mm_set_ps vagy _mm_load_ps függvényekkel betöltünk 16 byte-ra legyen illesztve [21, 174. oldal]. Lehetőség van az m128 _mm_loadu_ps ( float const* mem_addr ) függvénnyel olyan adat betöltésére is, ami nem 16 byte-ra van illesztve, de ennek használata nem ajánlott, ha teljes mértékben ki akarjuk használni a vektorizáció előnyét. Ahhoz, hogy az adatillesztés megvalósuljon, jeleznünk kell a fordítónak az adott változóra vonatkozóan, hogy hány byte-os területre illessze. Mivel az erre alkalmas parancsok fordító specifikusak, és én GNU-t használok a fordításhoz, ezért eltekintek más fordító parancsainak ismertetésétől. Az illesztés elvégezhető önálló változókon, illetve egy osztály vagy struktúra egészén, de nem lehetséges az utóbbi két adatszerkezet egy-egy adattagján úgy, hogy közben más adattagon nem végeztük el az illesztést. Nem lehetséges továbbá a függvény paraméterek illesztése [21, 174. oldal]. A memóriaterületet tekintve mind a stack, mind a heap területen elvégezhető az illesztés Lokális változó illesztése A lokális változók a stack memóriaterületre kerülnek. Az ilyen változók illesztéséhez az attribute ( ( aligned ( n ) ) ) kulcsszót kell használni [23]. Az n paraméter jelöli azon byte-ok számát, amiken az illesztés történik, és amiknek az 32

37 értéke kettő valamely hatványa lehet. Például egy float tömb 16 byte-os illesztése az alábbi módon valósul meg. float a[4] attribute ((aligned(16))); Adatszerkezet illesztése A struktúrák vagy osztályok illesztése hasonlóképpen történik a lokális változók esetéhez. struct vector { float a[4]; float n; } attribute ((aligned(16))); A fenti példakódban az a tömb és az n változó is 16 byte-ra lesz illesztve Illesztés a heap memóriaterületen Ahhoz, hogy a dinamikusan foglalt memóriaterületen is megvalósuljon az illesztés, a new operátor helyett az void * _aligned_malloc( size_t size, size_t alignment ); függvényt [24] használtam, ahol a size paraméter a lefoglalni kívánt memóriaterület mérete byte-okban kifejezve, az alignment paraméter pedig az illesztés mérete szintén byte-okban megadva. Visszatérési értéke egy void típusú mutató. Az illesztett memória felszabadításáról ugyanúgy szükséges gondoskodni, mint a hagyományos, dinamikus memóriakezelés esetében. Ehhez a void free (void *ptr) függvény helyett az void _aligned_free( void *p ); függvényt használom, ahol p a felszabadítani kívánt memóriaterületre mutató változó. 33

38 Ahhoz, hogy egyszerűbb legyen az illesztés a saját osztályok esetében, a new és delete operátorokat túlterheltem, és a fenti _aligned_malloc és _aligned_free függvényeket alkalmaztam, amiknek a megvalósítását az alábbi kódrészlet mutat. void* operator new( std::size_t size ) { return (void*)_aligned_malloc( size, 16 ); } void* operator new[]( std::size_t size ) { return (void*)_aligned_malloc( size, 16 ); } void operator delete( void *p ) { _aligned_free( p ); } void operator delete[]( void *p ) { _aligned_free( p ); } A program tesztelésekor azt tapasztaltam, hogy ez a megoldás nemhogy gyorsította, hanem lassította a vektorműveleteket. 3.9 SSE alkalmazása a sugárkövetésben A vektorizáció megvalósításához számos dolgot figyelembe kell venni, ugyanis vannak bizonyos megkötések. Elsősorban az SIMD technológia helyes használata a mérvadó, másrészt a szoftver célja, vagyis az, hogy milyen problémát old meg. Ez ugyanis szintén meghatározza, hogy az algoritmusban hol és hogyan alkalmazom a vektorizációt. Az általam készített szoftverben úgy döntöttem, hogy a sugár-háromszög ütközést fogom SSE-vel optimalizálni. Mielőtt a végleges verzió elkészült volna, kísérleteztem az SSE egyéb alkalmazásaival a programomban. A további alfejezetekben leírom, hogy milyen megkötésekkel álltam szemben, és hogyan jutottam el a végső megoldáshoz. 34

39 3.9.1 Követelmények a vektorizációhoz Az Intel beépített függvénykészletét használva nem közvetlenül a regiszterekkel dolgozunk, hanem előre definiált adattípusokkal. A típusok használatakor azonban van némi megkötés, ugyanis nem kezelhetjük őket úgy, mint a hagyományos C és C++ típusokat, mint például az int, float, double, char. Egy SSE vektor típus csakis egy intrinsic függvény visszatérési értéke vagy paramétere lehet. Aritmetikai operátorok nem végezhetőek közvetlenül a vektorokkal, a műveletek elvégzése csak az erre kijelölt SSE függvényekkel lehetséges. A hagyományos feltételes utasítás (if, else if, else) szintén nem használható, helyette intrinsic függvényeket alkalmazhatunk. Az SSE regiszter egyes elemeit közvetlenül nem érhetjük el. Bár az Intel hivatalos referenciájában [21, 3. oldal] említik, hogy használhatunk union adatszerkezetet az egyes byte elemek eléréséhez, de az MSDN referenciája [22] már ezzel ellentétben azt tanácsolja, hogy ne olvassuk a vektor elemeket közvetlenül. Én végül a hivatalos megoldást választottam, és a megfelelő intrinsic függvényekkel végeztem el a vektor elemek kinyerését (3.7. Adatok kiolvasása). Mivel az adatok SSE regiszterbe való betöltése és a regiszterből való kiolvasása költséges, ezért érdemes úgy tervezni a programkódot, hogy ez minél kevesebbszer történjen meg. Amíg lehet, az értékeket a regiszterekben kell tartani, és miután az algoritmus végzett, a végeredményt ki lehet olvasni, és az esetleges további, kevésbé költséges számításokat már a hagyományos regiszterekkel végrehajtani SSE alkalmazása az RTVector osztályon Vektorműveletek gyorsítása SIMD alkalmazásával kézenfekvő feladatnak tűnik elsőre. Az interneten kutatva számos fórumposztra, illetve blog bejegyzésre akadtam, ahol a következő megoldást ajánlották: a vektor osztályon elvégzendő műveletekért felelős függvények és túlterhelt operátorok hagyományos megvalósítását kell lecserélni SSE függvényhívásokkal. Mivel ez egyszerűbb, és 35

40 kevesebb módosítással is járt, így az alábbiak szerint alkalmaztam. A példában két vektor összeadását mutatom meg, ezért az osztály csak az ehhez szükséges kódot tartalmazza. class RTVector { public: friend RTVector operator + ( const RTVector &a, const RTVector &b ); private: m128 SIMDVector; }; inline RTVector operator + ( const RTVector &a, const RTVector &b ) { RTVector v; v.simdvector = _mm_add_ps( a.simdvector, b.simdvector ); return v; } AOS struktúra és hátránya Az előző alfejezetben szemléltetett példában az RTVector osztályon alkalmazott megoldás AOS (Array of Structures) magyarul struktúrák tömbje adatstruktúrát valósít meg. Az RTVector három float típusú elemből áll: x, y és z, amelyeket egy vertex leírására alkalmazok. Egy háromdimenziós objektum ilyen vertexek sokaságából áll, amelyeket egy tömbben tárolok (3.2 ábra) ezzel megvalósítva az AOS adatstruktúrát. 3.2 ábra. Vertex adat AOS struktúrában tárolva. Bár az m128 vektor négy float típusú elemet tud tárolni, AOS használatával csak három vektor elem van kihasználva. Ezzel a megoldással az a baj, hogy az SSE regiszter negyedik elemét nem használom ki. Az RTVector három elemből áll, és ezeket rendre a regiszter nulladik, 36

41 első és második helyére töltöm be, így ahelyett, hogy négy darab float típusú adaton végeznék műveleteket, csak három adat kerül felhasználásra SOA struktúra előnye SSE használatakor A SOA (structure of arrays), vagyis tömbök struktúrája az AOS fordítottja. Az egyes vektor elemeket x, y és z külön-külön helyezem el egy-egy tömbben, és ezt a három tömböt egy struktúrába teszem (példakód lent). Ez az adatstruktúra már támogatja a vektorizációt, tehát alkalmas arra, hogy hatékonyan kihasználjuk az SSE regisztereket és a hozzájuk tartozó függvényeket. class RTVector { float x[1024]; float y[1024]; float z[1024]; }; Mivel a vertexeket meghatározó három elem egy-egy külön tömbben kerül elhelyezésre, az SSE vektorok számára készen állnak a négyes adatcsomagok (3.3 ábra). Az SSE regiszternek így mind a négy float eleme felhasználásra kerül, és azonnal végre lehet hajtani rajta az adott műveletet vagy műveleteket. 37

42 3.3 ábra. Vertex adat SOA struktúrában tárolva Sugár-háromszög ütközésvizsgálat vektorizációval SOA adatstruktúrával bizonyos műveletek hatékonyan elvégezhetők. Például egy háromdimenziós modell transzformálása esetén egymástól függetlenül, különkülön elvégezhetjük a transzformációt az x, y majd z komponensen. Mivel a programomban a sugár-háromszög ütközésvizsgálatát gyorsítom, ezért a hagyományos SOA struktúrától egy eltérő megoldást választottam (3.4 ábra). 3.4 ábra. Vertex adatok a végleges struktúrában. Létrehoztam egy RTVectorPack osztályt három m128 típusú adattaggal, amelyek az x, y és z elemeit tárolják a háromszögeket alkotó vertexeknek: RTVectorPack { m128 PackX; m128 PackY; m128 PackZ; }; A 2.3 alfejezetben bemutatott sugár-háromszög metszést vizsgáló függvény deklarációja az alábbi: bool RTMesh::intersectTriangle( const RTRay &ray, const RTVector&v0, const RTVector &v1, const RTVector &v2, float &t, float &u, float &v ); 38

43 A vektorizáció bevezetésével az ütközésvizsgálatot végrehajtó függvény bemenete egy RTRayPack és három RTVectorPack. A pack elnevezés arra utal, hogy az adott osztály valójában négy példányt rejt el a sugárból, illetve a háromszöget leíró m128 vektorokból. bool RTMesh::intersectTriangle( const RTRayPack&ray, const RTVectorPack &v0,const RTVectorPack &v1, const RTVectorPack&v2, float &tpack, float &upack, float &vpack ); Ahol az RTRayPack két RTVectorPack típust tartalmaz: RTVectorPack { RTVectorPack Origin; RTVectorPack Direction; }; Bár elméletileg egy sugarat ütköztetek egyszerre négy háromszöggel, a vektorizáció megkövetelte, hogy az adott sugár is egy SSE regiszterbe legyen betöltve, mégpedig úgy, hogy mind a négy háromszöggel ugyanazt a sugarat ütköztetem Az ütközésvizsgálat vektorizált függvényei Az RTVectorPack osztály a vertex adatok tárolása mellett az ütközésvizsgálathoz szükséges algebrai műveleteket és operátor túlterheléseket valósítja meg. Minden egyes művelet kívülről úgy értelmezendő, mintha két hagyományos vektoron végezném el. Gyakorlatban azonban párhuzamosan négy-négy vektor között történik a műveletvégzés. m128 dotproduct( const RTVectorPack &pack0, const RTVectorPack &pack1 ) Két RTVectorPack skaláris szorzatát számolja ki. Visszatérési értéke négy darab float típusú szám egy m128 vektorban tárolva. m128 dotproduct( const RTVectorPack &pack0, const RTVectorPack &pack1 ) { m128 dotpack = _mm_add_ps( 39

44 } _mm_mul_ps( pack0.packx, pack1.packx ), _mm_add_ps( _mm_mul_ps( pack0.packy, pack1.packy ), _mm_mul_ps( pack0.packz, pack1.packz ))); return dotpack; RTVectorPack crossproduct( const RTVectorPack &v0, const RTVectorPack &v1 ) Két RTVectorPack vektoriális szorzatát számolja ki. Visszatérési értéke egy újabb RTVectorPack. RTVectorPack crossproduct( const RTVectorPack &v0, const RTVectorPack &v1 ) { RTVectorPack cross; cross.packx = _mm_sub_ps( _mm_mul_ps( v0.packy, v1.packz ), _mm_mul_ps( v0.packz, v1.packy )); cross.packy = _mm_sub_ps( _mm_mul_ps( v0.packz, v1.packx ), _mm_mul_ps( v0.packx, v1.packz ) ); cross.packz = _mm_sub_ps( _mm_mul_ps( v0.packx, v1.packy ), _mm_mul_ps( v0.packy, v1.packx ) ); return cross; } RTVectorPack operator * ( const RTVectorPack &v0, const RTVectorPack &v1 ) Két RTVectorPack szorzata. Visszatérési értéke egy új RTVectorPack. RTVectorPack operator * ( const RTVectorPack &v0, const RTVectorPack &v1 ) { RTVectorPack v; v.packx = _mm_mul_ps( v0.packx, v1.packx ); v.packy = _mm_mul_ps( v0.packy, v1.packy ); v.packz = _mm_mul_ps( v0.packz, v1.packz ); return v; } 40

45 Továbbá az összeadás és kivonás függvénye a szorzás mintájára, annyi különbséggel, hogy a műveletet végző függvények rendre _mm_add_ps és _mm_sub_ps Teljesítmény teszt Az SSE teszteléséhez az alábbi jelenetet használtam (3.5 ábra). 3.5 ábra. Jelenet az SSE teszteléséhez. A teljesítmény tesztet egy szálon futtattam,és öt egymást követő renderelésnek az átlagát vettem. Az eredményeket az alábbi 3.4 táblázat tartalmazza. Kategória Renderelés ideje [s] Vektorizáció nélkül 70,01 Vektorizációval 19, táblázat. Vektorizáció teszt eredményei. 41

46 4 Multithreading 4.1 Történet A számítógépek rohamos fejlődésének egyik alappillére a processzorok számítási kapacitásának emelése. A kezdeti korszakban a teljesítmény növelését elsősorban az órajel emelése jelentette. Ez a növekedés azonban azt eredményezte, hogy az áramkör bonyolultsága mellett a processzorok fogyasztása is jelentősen megnőtt. Pollack szabálya szerint romlik a processzorok teljesítményének hatékonysága az áramkörök bonyolultságának növekedésével. [25] Mivel a fejlődés az órajel növelésében megtorpant ami körülbelül 4 GHz-es felső határt jelentette, lépni kellett egy új irányba. A problémára a processzor magok számának növelése jelentette a megoldást. Az első kereskedelmi forgalomban kapható két magos processzor 2001-ben jelent meg POWER4 néven az IBM jóvoltából. [26] A felhasználási területet ekkor még a szerver számítógépek jelentették. Az első személyi számítógéphez kifejlesztett két magos processzor 2005-ben jelent meg Pentium D néven az Intel jóvoltából. [27] Szintén 2005-ben az AMD is forgalomba hozta a két magos processzorát Athlon 64 X2 néven. [28] A többszálú programozás előnyeit nem hagyhattam figyelmen kívül a program megvalósítása során, ezért ebben a fejezetben bemutatom, hogy hogyan alkalmazható ez a gyorsítás egy sugárkövető alkalmazásban. 4.2 Alkalmazás A sugárkövetésen alapuló képalkotás jól párhuzamosítható, ezért ezt az optimalizálás során figyelembe vettem, és úgy alakítottam ki a renderelő algoritmust, hogy kihasználja a több magos processzorokat. Mivel az egyes fénysugarak egymástól függetlenül járják be az objektum teret, így nem kell tudniuk egymás állapotáról, paramétereiről. Kiindulásnak vegyünk egy kétmagos 42

47 processzort. A legegyszerűbb és legkézenfekvőbb implementáció az lehet, ha a képet két részre osztom, egy felső és egy alsó félre. Két szálat hozok létre, amelyek párhuzamosan az egyik és a másik felen dolgoznak. Bár a párhuzamosítás miatt rövidebb lesz a renderelési idő, ezzel a megoldással még nem hozom ki a maximumot a több processzormagból. A jelenet elrendezésétől függően előfordulhat, hogy a kép felső felére alig jut objektum, míg az alsót szinte teljesen elfedi (4.1 ábra). Ebben az esetben a felső területért felelős szál hamarabb fog végezni, és kihasználatlanul fog várni, amíg újabb feladatot nem kap. Az alsó képért felelős szál azonban végig dolgozik. Elmondható tehát, hogy a munkamegosztás így nincs kiegyenlítve. 4.1 ábra. Egyenetlen eloszlású jelent két részre osztva. A processzormagok kihasználtságát azzal javítom, hogy a képet sok, kisebb részre osztom. Így továbbra is két mag dolgozik, de sok, kis képdarabon (4.2 ábra), és amint végez egy darabbal, máris kezdhet egy újat. 43

48 4.2 ábra. Egyenetlen eloszlású jelent sok részre osztva. 4.3 Szinkronizálás Az egyes darabokat egy listából veszik ki a dolgozó szálak. A megvalósításért az RTImageParts osztály felelős. Az osztály része a PART struktúra, amely a kép egy darabját írja le úgy, hogy meghatároz egy téglalapot a képen. struct PART{ int startrow; int startcol; int endrow; int endcol; }; Az RTImageParts osztály egy QList típusú listában tárolja az egyes részeket. Mivel a QList nem thread-safe, ezért gondoskodni kell arról, hogy ne történjen olvasás egy időben több szálról, vagyis szinkronizálni kell az RTImageParts::getPart függvényt. A szinkronizálást mutex-szel valósítottam meg a QMutexLocker segítségével [29]. Az RTImageParts::addPart függvényt viszont nem szinkronizáltam, mert a kép felosztása, így az egyes részek listába való beillesztése még a renderelés előtt, egy szálról történik. 44

49 PART RTImageParts::getPart() { QMutexLocker ml(&mutex); PART retval = List.last(); List.removeLast(); return retval; } A QMutexLocker használatával egyszerűen valósul meg a lock és unlock, ugyanis a mutex-et elegendő a függvényblokk elején példányosítani. Amint kilépünk a popparts függvényblokkból, megsemmisül az ml példány, és megtörténik az unlock is. 4.4 Renderelés több szálon A renderelő magja egy két egymásba ágyazott for ciklus, amely a pixeleken iterál végig soronként és a sorokon belül oszloponként. Hagyományos esetben a ciklusok nulla indextől a kép szélességével, illetve magasságával megegyező pixelszámig iterálnak. for ( int row = 0; row < imageheight; row++ ) { for ( int col = 0; col < imagewidth; col++ ) { // sugár generálása a (row, col) pixelen át // sugárvetés indítása // kalkulált szín beállítása a (row, col) pixelre } } Több szálat használva a renderelés előtt a kép darabok inicializálása fut le a felhasználó által megadott darabszámmal. RTImageParts parts; int partwidth = ImageWidth / 4; int partheight = ImageHeight / 4; for( int row = 0; row < ImageHeight; row += partheight ) { 45

50 } for( int col = 0; col < ImageWidth; col += partwidth ) { } parts.addpart( row, col, row + partheight, col + partwidth ); Az RTImageParts létrehozása és inicializálása után elkészítem a QThread típusú szálakat. A szálak számát az n változó tárolja, aminek az értéke a felhasználó által módosítható a renderelés előtt. Minden egyes szálon beállítom a started és finished signal kezelését, továbbá az RTTracer példányokat inicializálom és átadom a QThread példányoknak. QThread *threads = new QThread[n]; RTTracer *tracers = new RTTracer[n]; for( int i = 0; i < n; i++ ) { connect( &threads[i], SIGNAL( started() ), &tracers[i], SLOT( render() ) ); connect( &tracers[i], SIGNAL( finished() ), &threads[i], SLOT( quit() ), Qt::DirectConnection ); connect( &tracers[i], SIGNAL( updatetimer() ), this, SLOT( refreshlabeltime() ) ); tracers[i].init( &Scene, &CameraRenderer, buffer, &parts, 1.0f, 1.0f, false ); tracers[i].setmaxtracedepth( ui->maxtracedepthspinbox->value() ); tracers[i].movetothread( &threads[i] ); } Végül a képfelosztást alkalmazva a renderelő magja az alábbiak szerint változik. A renderelő algoritmus annyiszor fut le, ahány képdarabot tartalmaz az ImageParts változó. while(!imageparts->isempty() ) { PART p = ImageParts->popPart(); for (int row = p.startrow; row < p.endrow; row++){ for (int col = p.startcol; col < p.endcol; col++){ // sugár generálása a (row, col) pixelen át // sugárvetés indítása // kalkulált szín beállítása a (row, col) pixelre } } } 46

51 4.5 Teljesítmény teszt Referenciának az alábbi,4.3 ábrán látható jelenetet használtam. 4.3 ábra. Jelenet a párhuzamosítás teszteléséhez. Első alkalommal egy szálon rendereltem vektorizálás és képfelosztás nélkül, ami 52 másodpercig tartott. Ezt követően a számítógépemhez igazítva két szálon folytattam, és azzal kísérleteztem, hogy mennyi lehet az optimális darabszám, amire felosztom a képet. Kettőtől elmentem egészen hatvannégyig. Az eredményeket a 4.1 táblázatban tüntettem fel. Szálak száma Kép darabok száma Idő [s] (vízszintesen x függőlegesen) 1 1 x 1 52, x 1 52, x 2 31, x 2 27, x 4 27, x 4 27, x 5 26, x 5 26, x 6 26,21 47

52 2 4 x 8 26, x 8 26, x 6 26, x 8 26, táblázat. Párhuzamosítás teszt eredményei. Látható, hogy4 darabszámtól már nem értem el jelentős javulást a renderelési időben. Ugyanezekkel a darabszámokkal más jelenetet is teszteltem. A 4.3 ábra viszonylag egyenletesen kitölti a jelenetet. Én azonban kíváncsi voltam, hogy változhat-e az eredmény, ha az elhelyezett tárgyak ritkábban helyezkednek el. A jelenet a 4.4 ábrán látható,a hozzá tartozó teszt eredmények pedig a 4.2 táblázatban. 4.4 ábra. Egyenetlen eloszlású jelenet. 48

53 Szálak száma Kép darabok száma Idő [s] (vízszintesen x függőlegesen) 1 1 x 1 263,2 2 1 x 1 263, x 2 139, x 2 134, x 4 136,9 2 4 x 4 133,6 2 4 x 5 134, táblázat. Egyenetlen eloszlású jelenet teszt eredményei. 49

54 5 A szoftver 5.1 Felhasznált eszközök A szoftver felhasználói felületéhez a Qt SDK-t használtam, amely egy C++ nyelven alapuló cross-platform keretrendszer. Segítségével Windows, Linux vagy OS X rendszerekre fejleszthetünk, de akár Android vagy ios alapú mobil platformokra is. A Qt bár C++ nyelven alapul, de kiegészül egy egyedi, úgynevezett signal-slot eseménykezelő rendszerrel. Ezzel a mechanizmussal objektumok között kommunikálhatunk anélkül, hogy szoros kapcsolatot építenénk ki közöttük. A rendszer működését a meta-object system teszi lehetővé, amely makrókat alkalmazva a fordítás előtt kiegészíti a kódot, és ezáltal elérhetővé teszi a signal-slot használatát. A kódoláshoz, felhasználói felület összeállításához és a futtatható program elkészítéséhez a Qt Creator fejlesztőkörnyezetet használtam, amely kifejezetten a Qt SDK-val való fejlesztéshez készült. A kód fordításához MinGW fejlesztői környezetet használtam, amely része a Qt programcsomagnak. Az SSE utasításokhoz szükséges adat illesztési parancsok fordító specifikusak, ezért ebből a szempontból érdemes tisztában lenni a kiválasztott fordítóval. A Qt Creator egyébként lehetőséget biztosít más fordítók használatára is. A jelenet összeállításának megkönnyítésére egy szerkesztőt hoztam létre, amelynek a kirajzolását OpenGl API-val oldottam meg. Ez a grafikus könyvtár szintén része a Qt SDK-nak. A jelenet megjelenítése igen egyszerűen valósul meg, például nem tartalmaz sem fényeket, sem tükröződést. Az ehhez szükséges matematikai számításokat szintén a Qt által biztosított QVector3d és QMatrix4x4 osztályokkal valósítottam meg. 50

55 5.2 Felület 5.1 ábra. A szoftver felhasználói felülete. Az 5.1 ábrán látható a felhasználói felület, amelynek az egyes részeit számokkal jelöltem. Részletes leírás az elemek funkcióiról alább található. 1. Szerkesztő ablak A felhasználói felület legnagyobb részét foglalja el. Itt látható a jelenet az elhelyezett objektumokkal. Lehetőség van az objektumok pozíciójának módosítására, illetve a szín anyagtulajdonság is megjelenítésre kerül. 2. File menü A jelenet elmentése (Save Scene) és egy korábban elmentett jelenet betöltése (Open Scene). A program sc kiterjesztésű fájlokat képes csak megnyitni. A fájl helyességét nem ellenőrzi, feltételezi, hogy a felhasználó a megfelelő fájlt nyitja meg. A Clear Scene a jelenet összes objektumát eltávolítja. 51

56 3. Camera View Ebben a nézetben a kamerát mozgathatjuk az egérrel és a felületen elhelyezett gombokkal (8.).Az egérrel lehetőségünk van a kamera forgatására, a gombokkal pedig a tér három tengelyén pozitív és negatív irányokban tudunk mozogni. A gombok csupán a Camera View módban aktívak. A kamera perspektivikus vetítést alkalmaz. 4. Top, Front és Right View A kamera ezekben a módokban ortogonális vetítést alkalmaz,és az egérrel lehetséges az objektumok áthelyezése. A8. számmal jelölt gombok tiltva vannak, és a kamerát sem mozgathatjuk. 5. Objektum lista A jelenetben elhelyezett objektumok listáját láthatjuk. Egérrel kijelölhetők az egyes listaelemek, és ekkor lehetőség van az objektum törlésére és az anyagtulajdonságainak módosítására. 6. Anyagtulajdonságok A kiválasztott objektumra jellemző anyagtulajdonságokat lehet beállítani. A diffúz és spekuláris (Diff and Spec) beállításnál a komponensek (Diffuse/Specular Coefficient) egymástól függenek, és az összegük nem lehet egynél nagyobb. A spekuláris hatásnál lehetőség van az n kitevő beállítására is (2.5 képlet). A Reflective beállítás az objektum tükröződésének mértékét állítja. Ha Distant Light megvilágítást adunk a jelenethez, akkor a Distant Light Direction beállítással a fény irányát adhatjuk meg. Ekkor nincs jelentősége annak, hogy a jelenetben hol helyezkedik el a fényforrás, az algoritmus csupán az irányát veszi figyelembe. A Set Color gomb az objektum színének beállítására ad lehetőséget. 7. Renderelés A felület ezen részén a sugárkövető algoritmusra vonatkozó beállítások találhatók. A Max trace depth a rekurzió mélységét határozza meg. A tükröződő felületekre vonatkozóan azt határozza meg, hányadik alkalommal számoljon az algoritmus visszaverődést ugyanazon sugárra, ami ismételten egy fényvisszaverő felületet metsz. A Number of thread opció a szálak számát adja meg, amelyek a 52

57 renderelést végzik. Az Image parts mellett látható a kép darabszáma, amelyre felosztjuk a Horizontal és Vertical értékekkel a képet. Végül a Render vagy Render with SSE gombbal indul a képalkotás és alatta látható az az idő (másodpercben), amely szükséges volt a kép elkészítéséhez. 5.2 ábra. Renderelt kép megjelenítése. Az elkészült kép egy új ablakban jelenik meg (5.2 ábra) és PNG formátumban a raytracer.exe mellé automatikusan elmentésre kerül. A fájlnév az image_ + aktuális dátum + idő formátumot kapja. 53