Mall skapad av Henrik
E FFEKTIVITET HOS
ACCELERATIONSSTRUKTURER FÖR
S TRÅLFÖLJNING
En jämförelse av konstruktionstid för BVH och KD- träd
E FFIENCY OF ACCELEREATION STRUCTURES IN RAY TRACING
A comparison of construction time on BVH and KD- Tree
Examensarbete inom huvudområdet Informationsteknologi Grundnivå 30 högskolepoäng
Vårtermin 2020
Anton Blomdell & Tim Cook
Handledare: Peter Sjöberg
Examinator: Henrik Gustavsson
Sammanfattning
Strålföljning är en rendering teknik som använts för icke realtid rendering men har med hjälp av accelerationsstrukturer och GPUer lyckats uppnå rendering i realtid. För att använda strålföljning i spel eller dynamiska scener behövs accelerationsstrukturerna byggas om i realtid på grund av detta har denna undersökning valt att utföra en komparativstudie där accelerationsstrukturerna Boundary Volume Hierachy (BVH) och K-dimensional tree (KD-träd) undersöks angående konstruktionstider på GPUn. Undersökning gjordes via skapandet av olika scener som med hjälp av en brusfunktion, även en BVH och en KD-träd lösning implementerades baserat på Lauterbach et al (2009) och Li et al (2017) respektive. För att testa strukturerna implementerades en strålföljnings algoritm baserad på Whitted (1980). Resultaten visar att BVH konstruerar upp sin struktur snabbare än KD-träd i alla scener. Som framtida arbeten vore det intressant att ytterligare undersöka andra algoritmer samt att jämföra algoritmerna i spel scener.
Nyckelord: strålföljning, grafik, BVH, KD-träd
Innehållsförteckning
1 Introduktion 1
2 Bakgrund 2
2.1 Om strålföljning 2
2.1.1 Realtid 3
2.2 Accelerationsstrukturer 3
2.2.1 Volymer 4
2.2.2 Morton kod 5
2.2.3 CPU eller GPU 6
2.3 Boundary Volume Hierarchy 6
2.3.1 Realtid 7
2.4 KD-Träd 8
2.4.1 Realtid 9
2.5 BVH och KD-träd jämförelser 9
3 Problemformulering 11
3.1 Metodbeskrivning 11
4 Implementation 13
4.1 Brusfunktionen 13
4.2 Axis Algined Bouding Box 14
4.3 Morton kod 15
4.4 Radix sort 16
4.5 Boundary Volume Hierarchy 17
4.6 KD-träd 18
4.7 Strålföljning 20
4.8 Datainsamling 21
4.9 Förstudie 21
5 Utvärdering 25
5.1 Presentation 25
5.2 Analys 27
5.3 Slutsatser 29
6 Avslutande diskussion 30
6.1 Sammanfattning 30
6.2 Diskussion 30
6.2.1 Metod 30
6.2.2 Implementation 30
6.2.3 Parallellism 31
6.2.4 Samhällelig nytta 31
6.3 Framtida arbeten 32
Referenser 33
1
1 Introduktion
Strålföljning är en renderingsteknik som skickar ut ljusstrålar för att beräkna belysning, reflektioner och skuggor. Strålföljning har länge varit för tidskrävande för realtidsapplikationer som spel. Utvecklingen av hårdvara och accelerationsstrukturer har realtidsrendering blivit möjligt men endast i statiska scener, för att kunna använda strålföljning i dynamiska scener behövs accelerationsstrukturer konstrueras i realtid. Boundary Volume Hierachy (BVH) är en accelerationsstrukur som används i dynmaiska scener på grund av att strukturen inte behöver konstrueras om varje bilduppdatering utan kan istället uppdatera (eng.refitting) strukturen (Wald et al 2009), Omkonstruktioner behövs när scenens utformning skiljer sig för från scenens utformning då accelerationsstrukturen konstuerades. KD-träd är en accelerationsstrukur som har mer effektiv söktid än BVH men har istället mindre effektiv konstruktionsstid och används främst i statiska scener (Wald et al 2009). I detta arbete undersöktes BVH och KD-träd med avseende på konstruktionsstid i olika scen miljöer.
Skapandet av olika scener skedde via ett tredimensionellt brus som implementerades med hjälp av perlin brus. Brus funktionen kan skapa scener av varierande storlekar, triangleantal och täthet.
BVH och KD-träd implementeras på GPUn med hjälp av tidigare arbeten av Lauterbach et al (2009) och Li et al (2017) respektive. Valet av tidigare arbeten är motiverat av att båda använder sig av liknande steg vid konstruktionen vilket gör alla scener mer rättvisa eftersom båda accelerationsstrukturer exekverar samma steg. För att garantera att accelerationsstrukturerna konstureras korrekt implmenterades en strålföjlnings algoritm baserat på Whitted (1980) som även implementerar en bredd-först-sökning för sökning genom accelerationsstrukturerna. Bruset används för att generera olika scener som sedan anting BVH eller KD-träd konstrueras runt där strålföjlning används för att undersöka om konstruktionen skedde korrekt. Den data som samlats är parametrarna som används för bruset, antal trianglar och konstruktionenstiden för den valda accelerationsstrukturen anting BVH eller KD-träd. All data som samlades in sammanställdes och utvärderades.
2
2 Bakgrund
2.1 Om strålföljning
Strålföljning är ett sätt att lösa renderingsekvationen för datorgrafik. Den skapar skuggor, reflektioner och hur ljus bryts på olika material (Cook, Porter, Carpenter 1984). Huvudkonceptet bakom tekniken är hur strålföljning (eng.ray tracing) beräknas och simulerar dess fördelning i en virtuell miljö (Marmitt, Friedrich, Slusallek, 2008). Första benämningen av en implementation av strålföljning görs i en vetenskaplig artikel av Appel (1968). Appel (1968) presenterar en teknik där en ljusstråle skickas ut för varje pixel som träffar första närmsta objekt och med hjälp av en belysningseffekt ger denna pixel en färg (Appel 1968). Nästa årtionde kommer Whitted (1980) med sin metod för strålföljning, som innebär att efter att ljusstrålar har kolliderat med närmsta objektet genereras nya ljusstrålar vilket ger mer information som kan användas till belysningen av pixeln. I flera årtionden har strålföljning använts huvudsakligen till att skapa bilder av hög kvalitet och fotorealism (Liang, Yang, Zhang, Yin & Cao 2016).
Figur 1
Ett trestegs träd för en pixel.
I Figur 1 skickas först en primär ljusstråle ut från pixeln som träffar en träffpunkt som i figuren visas med en cirkel i trädet. Detta leder till att nya ljusstrålar kallade för sekundära ljusstrålar genereras. Reflektioner, ljus, och skuggeffekter beräknas för varje ny generation av ljusstrålar som skapas. Varje steg nedåt i trädet ses som en ny generation i denna beskrivning. Vilket görs rekursivt i valfritt djup. Sista generationen i trädet används till global belysning.
3
Ett traditionellt tillvägagångssätt för strålföljning har varit att gå igenom en datorgrafisk scen för varje pixel. Innan alla pixlar är beräknade kan inte scenen renderas. Hög komplexitet i geometrin hos en scen kan leda till tidskrävande rendering. Som leder till långsam rendering. (Yagel &
Meeker 1999). Enligt Liang (2016) Tidskomplexiteten för traditionell strålföljning är O (ljusstrålar x primitiver).
Figur 2
Pseudokod på traditionell strålföljning.
Utifrån Figur 2 kan slutsatsen dras att högre antal ljusstrålar som skickas och högre komplexitet för geometrin i scener kan i värsta fall leda till kvadratisk tidskomplexitet.
2.1.1 Realtid
Genom att datorkomponenter som GPU och CPU har blivit effektivare och utveckling av strålföljningstekniken skett har förbättringar kunnat göra strålföljning interaktiv istället för att endast kunna användas till skapandet av enstaka bilder. För tillfället görs mestadels av realtidsrendering med hjälp av rastreringstekniken och dess kraftfulla accelerationsstruktur i hårdvaran (Günther, Fredrich, Wald, Seidel & Slusallek 2006). För att strålföljning ska kunna användas inom realtid krävs att algoritmerna kan hantera förändringar i geometrin som sker i varje bild per sekund och hårdvaran utvecklas.
Företaget EA har genom sin spelmotor “Frostbite” skapat en belysningsteknik som heter Flux som skapar ljuskartor (eng.light maps) till sina spel. Tekniken bygger på att stimulera ljusstrålar från olika källor och köra rekursiv strålföljning från ljuskällorna. Vilket renderas i förväg innan spelet spelas. Flux beräknades i början på CPU vilket gjorde att det tog upp till en dag att rendera datorgrafiska scener innehållandes komplex geometri (O’Donnell 2018). År 2018 gick utvecklingen över till att beräkna på GPU istället för att förbättra renderingstiderna för Flux.
Utvecklare i Flux upplever att tiderna för att förändra och rendera tar upp en betydande del av deras arbete, 30 till 60 minuter krävs för att beräkna en geometrisk komplex datorgrafisk scen.
För varje ändring som görs i scenen behövs allting beräknas om (Nvidia Gameworks 2018).
2.2 Accelerationsstrukturer
Strålföljning är betydligt dyrare att rendera jämfört med rastrering med samma geometri, vilket främst beror på beräkning av alla strålar som måste jämföras med alla trianglar i scenen. För att reducera antalet jämförelser testas en ljusstråle först mot en volym som omslutar en eller flera
4
trianglar innan den testas mot trianglarna (Fujimoto et al. 1986). Det finns många olika accelerationsstrukturer som vanligen används till strålföljning (Wald et al. 2007). Arbetet kommer fokusera på Boundary Volume Hierachy (BVH) och K-Dimensional-Tree (sv.KD-Träd) då båda algoritmerna har försökts anpassas till realtid (Wald et al. 2009).
2.2.1 Volymer
Det finns olika sätt att definiera omslutningsvolymer i accelerationsstrukturerna (Kay & Kajiya 1986). Axis-Aligned Bounding box (AABB) där volymens kanter är parallella mot scenens världskoordinater är den vanligaste metoden som används (se Figur 3). AABB erbjuder många fördelar som snabb beräkning för träffar emot strålar och mindre konfigurationer för hur scenen kan konstrueras (Wald et al. 2007) vilket diskuteras mer i nästa kapitel. Utöver användandet av AABB finns inte tillräckligt med forskning om hur omslutna volymer kan användas i samband med strålföljning. En fördel med andra omslutna volymer än AABB är att de mer effektivt kan omsluta geometri (Wald et al. 2009; Kay & Kajiya 1986).
Figur 3
Exempel på AABB strukturer runt trianglar.
Volymerna i accelerationsstrukturerna kan konstrueras på olika sätt. Gällande heuristiska accelerationsstrukturer finns flera olika sätt att välja vart delningen för varje omsluten volym ska ske. Ett bra uppdelat träd där uppdelning har skett på ett sätt där kostnaden för genomsökning av trädet är minimal brukar kallas för ett träd av hög kvalitet och motsatsen kallas för låg kvalitet.
Surface Area Heuristic (SAH) är en algoritm som används för att räkna ut den potentiella kostnaden för genomsökning av ett träd och används för att skapa träd av hög kvalitet genom att jämföra potentiella uppdelningar för att välja den uppdelningen med bäst resultat, algoritmen är dock beräkningstung och leder till längre konstruktionstider (Bittner, Hapala & Havran 2015;
Wald et al. 2009). Om konstruktionstid är viktigt kan medianen användas för att dela upp scenen
5
istället för SAH. Något som leder till låg kvalitet men mer effektiv konstruktionstid (Wald et al.
2009).
2.2.2 Morton kod
Lauterbach et al (2009) menar att enklaste sättet att parallellisera konstruktionen av accelerationsstrukturer är att reducera den till ett sorteringsproblem, vilket görs möjligt med morton kod genom att ordna alla trianglar i scenen i en lista. Morton kod är ett värde tilldelas varje triangle i scenen och är baserad på triangelns koordinater och slår samman dessa (se Figur 4).
Figur 4
exempel på två dimensionell morton kod där Y-axeln representeras med röda siffror och X-axeln som blåa siffror. Varje låda representeras av ett nummer
som fås av scenens X- och Y-axlar.
Genom att sortera alla trianglar med de tilldelade morton koderna kan scenen lätt delas upp som en trädstruktur eftersom morton kod har egenskapen där varje bit beskriver vart i scenen triangeln befinner sig, det vill säga att alla trianglar som har en morton kod som börjar på noll är i den övre delen av scenen medans de som börjar på ett är på den nedre (se Figur 4). För att kunna sortera morton koderna med hög parallelism på GPUn använder Lauterbach et al (2009) radix sort. Radix implementeras i flera passeringar där varje passering sorterar en eller fler bitar (Satish, Harris &
Garland, 2009). Varje passering i radix sort räknar först ut histogram för varje unikt element (Satish, Harris & Garland 2009). För att behålla ordning på elementen. Sedan räknas förskjutning
6
för vart varje element ska börja ut med hjälp av summan av alla föregående histogram (Satish, Harris & Garland 2009) med dessa två uträkningar fås de nya positionerna.
2.2.3 CPU eller GPU
När strålföljnings tekniken ska implementeras finns två alternativ på vilken arkitektur som ska användas, båda har sina för- och nackdelar. CPU är uppgifts driven i sin parallellism. Uppgifter kör olika instruktioner och varje tråd som körs schemaläggs i en bestämd ordning. GPU är datadriven i sin parallellism vilket innebär att den kör samma instruktioner på olika typer av data.
Den bygger på tekniken SIMD vilket betyder (en.single instruction multiple data). Trådar hanteras och schemaläggs efter hårdvaran. Programmering på GPU är gjord i partier av trådar som hanterar en pixel shader för en grupp av pixlar eller ett draw call (Rege 2008). GPU är bättre än CPU på att hantera stora datavolymer på ett effektivt sätt. För att uppnå högre prestanda krävs att koden är parallellt implementerad, mellan 1 000 till 10 000 trådar används parallellt för uppnå optimal effektivitet (Liang et al. 2016).
2.3 Boundary Volume Hierarchy
BVH är en trädstruktur vars noder representerar rymden i en scen. BVH börjar med en volym som omsluter hela scenen som representeras av rotnoden som rekursivt delas upp till två (eller fler) barnnoder, se Figur 5, som är subvolymer till rotnoden, se Figur 6. Denna process fortsätter tills barnnoderna innehåller en förutbestämd mängd geometri eller trianglar (Clark 1976). BVH introducerades först av Clark (1976) för att gallra ut vilka objekt som inte syntes i kameran samt för att bestämma detaljer på objekt beroende på distans från kameran. BVH använder sig av objektpartitionering vilket innebär att scenen delas upp via objekt vilket innebär att varje unik geometri blir refereras till en gång i trädet men volymerna i trädet kan överlappa vilket leder till mindre effektiva söktider (Wald et al 2009).
Den första implementationen av BVH som användes till strålföljning använde sig av handgjorda volymer. Implementationen visade på mer effektiva söktider i statiska scener (Rubin & Whitted 1980). För att automatisera skapandet av BVH-träd används geometrins medianvärde (Kay &
Kajiya 1986). Rubin och Whitted (1980) samt Kay och Kajiya (1986) konstruerade BVH-träd av låg kvalitet anger Wald et al (2009) som även menar att högkvalitativa träd konstrueras med SAH- algoritmen. BVH använder sig oftast av AABB och är oftast binära träd (Wald et al. 2009; Geimer
& Müller, 2003; Wächter & Keller 2006). BVH varianter som var icke binära gjordes men dessa presterade sämre vid utskickning av primära strålar men gav likvärdig prestanda för sekundära strålar jämfört med ett binärt BVH-träd (Wald, Benthin & Boulos 2008).
7
Figur 5
En scen med tre trianglar med BVH
Figur 6
Motsvarande trädstruktur för Figur 5
2.3.1 RealtidBVH har visat söktider som är effektiva nog för realtidsrendering, därav har forskning fokuserat på att tillämpa BVH till dynamiska scener där trädet av hög kvalitet måste kunna byggas i realtid.
En uppoffring av BVH-trädets kvalitet i utbyte mot konstruktionsprestanda gjordes (Wächter &
Keller. 2006). BVH-träd går att uppdatera istället för att göra en fullständig omkonstruktion och denna teknik kallas uppdatering (eng.refitting), men det har visats att enbart uppdatering inte räcker då trädets kvalitet kommer minska med tiden i samband med dynamiska scener (Wald et
8
al. 2007). För att försöka behålla en del av kvaliteten i trädet har Yoon, Crutis och Manocha (2007) föreslagit en lösning som omkonstruerar andelar av trädet och uppdaterar resten. Lauterbach, Galrand, Sengupta, Luebke och Manocha (2009) implementerade en parallell lösning för att konstruera BVH-träd på GPU, genom att reducera konstruktionen till ett sorteringsproblem med hjälp av morton kod. Lauterbach et al.(2009) implementation vidareutvecklades där flera av algoritmens svagheter eliminerades genom användandet av alternativa metoder. Vilket resulterade i mer effektiva konstruktionstider (Pantaleoni & Luebke 2010). På senare år har forskning fokuserat mer på utvecklingen av specialiserad hårdvara för att få ner konstruktionstiden. Doyle, Fowler och Manzke (2013) utvecklade en specialiserad hårdvara för att snabbt konstruera upp BVH-träd av högkvalitet. En specialiserad hårdvarulösning baserad på Pantaleoni och Luebke (2010) gjordes, med fokus på att effektivt konstruera upp träd på bekostnad av lägre kvalitet (Viitanen, Koskela, Jääskeläinen & Kultala 2017).
2.4 KD-Träd
KD-träd är en datastruktur som bygger på rymdpartitionering som organiserar punkter i en k- dimensionell rymd. Som accerationsstruktur har denna används i flera användningsområden, strålföljning till partikelsimulering av vätskor (Zhou, Hou, Wang & Gou 2008). KD-träd bygger på att en datorgrafisk scen S som är konstruerad med N antal trianglar. KD-träd som går genom S och rekursivt delar upp områden i S. Roten i trädet korresponderar till AABB av S. Inre noder representerar plan inom S som rekursivt delar upp området vinkelrätt till koordinaterna för rotnoden. Alla yttre noder har referenser till alla trianglar som överlappar till korresponderande rymden i scenen. Uppbyggnaden kan ses i Figur 5 som är scenen och Figur 6 som är KD-trädet (Wald & Havran 2006).
Figur 7
En scen med tre trianglar.
9
Figur 8
Motsvarande KD-träd för Figur 7.
2.4.1 Realtid
KD-träd används huvudsakligen till rendering i statiska scener eller skapandet av enstaka bilder, då prestandan är mest tidseffektiv. Problemet uppstår när trädstrukturen måste uppdateras eller konstrueras om när rörelser och förflyttningar av objekt sker och noderna i trädet behöver ändras.
KD-träd konstrueras upp med metoden SAH vilket gör att trädstrukturen är beroende av den direkta delningen av scenen med denna metod (Yang, Yang, Wang, Xu 2016). Att implementera KD-träd på GPU innebär ett arkitekturrelaterat problem. KD-träd är ett binärt träd i sin struktur vilket gör att bara ett fåtal noder i början av konstruktionen behandlas. Vilket leder till att inte alla kärnor på GPU utnyttjas. En lösning på problemet är att ändra delningspolicy på SAH och reducera kraven på delningen. Vilket kommer resultera i ett träd med lägre kvalitet. En annan lösning är att ändra om algoritmen så att den konstrueras på bredden och skapar flera träd vilket gör att parallellismen i GPU kommer att utnyttjas (Yang et al. 2016). En jämförelse mellan CPU och GPU implementation visar att GPU lösningen har effektivitet som är 6 till 15 gånger bättre än den CPU lösning. Lösningen visade att konstruktionen kunde köras parallellt på GPU arkitekturen (Zhou et al. 2008).
2.5 BVH och KD-träd jämförelser
Inom strålföljning har flera komparativa studier gjorts där accelerationsstrukturer betraktats för att komma fram till vilken som är mest effektiv. Havran (2000) jämförde tolv stycken olika accelerationsstrukturer i flera olika scener på CPU där både konstruktionstid och söktid var faktorer, resultaten visade att KD-träd presterade mest effektivt. Havran (2000) konstaterade att
10
BVH hade för långa konstruktionstider vid tillfället (2000) för att tävla mot andra accelerationsstrukturer. Zlatšuka och Havran (2010) undersökte söktider på GPU för BVH och KD-träd där båda använde sig av SAH algoritmen i statiska scener, resultaten visade att BVH presterade effektivare än KD-träd vid primära strålar men inte vid sekundära strålar. Vinkler, Havran & Bittner (2014 2016) undersökte söktider på GPU och kom fram till att BVH presterade mest effektivt i mindre scener medan KD-träd var mer effektiva i större scener.
11
3 Problemformulering
Ett problem som funnits med strålföljning sedan algoritmen introducerades (Whitted 1980) är att algoritmen har varit för beräkningstung för realtidsapplikationer. Utveckling av hårdvara har lett till att antalet beräkningar har kunnat göras på kortare tid som lett till förbättrade renderingstiden. För dynamiska scener räcker inte hårdvaran enbart utan accelererationsstrukturen måste kunna konstrueras effektivt för uppnå realtidsrendering (Wald et al 2009). Syftet är att genomföra en experimentell studie angående konstruktionstid mellan de två accelerationsstrukturerna KD-träd och BVH i dynamiska scener.
De spel som idag använder strålföljning använder sig av BVH implementationer även fast KD-träd har visat mer effektiva söktider i större statiska scener (Vinkler, Havran & Bittner 2014,2016). Den största bidragande faktorn för användandet av BVH i dynamiska scener över KD-träd är dess fördelar kring omkonstruktion när förändring sker i geometrin. Implementationen av accelerationsstruktur-algoritmerna gjordes på CPU fram till år 2006 då första implementationen som exekveras endast av GPU gjordes (Günther et al 2006) vilket möjliggjorde strålföljning i realtidsapplikationer men begränsat till statiska scener där accelerationsstrukturen inte behövde konstrueras om.
Zlatuška och Havran (2010) visade att algoritmen grid som delar upp scenen i ett rutnät utan hänsyn till geometri inte presterade effektivt gällande söktid. I samband med att Vinkler, Havran och Bittner (2014, 2016) angav att BVH och KD-träd är de mest relevanta algoritmerna för realtids-strålföljning argumenterar för användandet av BVH och KD-träd. KD-träd är den accelerationsstruktur som presterade mest effektivt i statiska scener på CPU baserade lösningar (Havran 2000) men har visat blandade resultat på GPU (Zlatšuka & Havran 2010; Havran &
Bittner 2014,2016). På grund av att BVH går att uppdatera samt konstruera snabbare än KD- träd har huvudsakligen forskning på BVH gjorts för dynamiska scener (Lauterbach et al 2009;
Pantaleoni & Luebke 2010), vilket dock inte hindrat forskningen från att utveckla KD-träd- algoritmer som fungerar i dynamiska scener i realtid (Zhou et al 2008). Det finns inte mycket forskning om att jämföra konstruktionstider på GPU även fast flera artiklar fokuserar på att effektivisera konstruktionen (Doyle, Fowler & Manzke 2013, Lauterbach et al 2009, Pantaleoni &
Luebke 2010, Zhou et al 2008).
Båda algoritmerna som har valts att implementeras (Lauterbach et al 2009; Li, Deng & Gu 2017) visar hög parallellism och redogör för hur deras algoritmer är implementeras, de implementerar även liknande steg vilket kommer göra testerna mer rättvisa då båda algoritmer kan implementeras med samma algoritmer i flera steg.
3.1 Metodbeskrivning
En brusfunktion baserad på perlin brus kommer att användas för att skapa geometriska objekt som accelerationsstrukturerna kommer dela upp i respektive trädstrukturer. Brusfunktionen används för att med hjälp av parametrar går att ändra en scens geometri. Frekvens parametern används för att ändra antalet trianglar. Minimumvärde och maximumvärdet hos brusfunktion kommer göra så värden kontrolleras vilket möjliggör skapandet av en scen med lägre geometrisk komplexitet respektive med högre komplexitet. Dessa parametrar hjälper till att variera scenens geometriska struktur och hjälper till att ge mer intressanta data för studien.
12
Enligt Wald et al (2009) är BVH objektpartitionering medan KD-träd använder sig av rymdpartitionering vilket kan leda till att vissa scener blir mer orättvisa. Wald et al (2009) menar att rymdpartitonering kan göra uppdelningar av högre kvalitet än objektpartitionering eftersom objektpartitonering inte har möjligheten att skapa volymer mindre än objekten. Enligt Vinkler (2016) presterar KD-träd effektivare på scener med högre geometrisk komplexitet medan BVH är bättre på lägre komplexitet. Sambandet kommer att undersökas i studien med hjälp av brusfunktionen och skapa en rättvis prövning då parametrarna i funktionen kan justeras.
Data som samlas in om konstruktionstid sammanställs i ett diagram. Konstruktionstiderna fås genom att ta skillnaden i tid från att konstruktionen börja till att den är slut. Implementation som görs på GPU använder en BVH (Lauterbach et al 2009) lösning och en KD-träd (Li et al 2017) lösning. Artiklar visar på hur parallellism kan utnyttjas hos GPU arkitekturen och hur effektivitet den är i jämförelse med CPU implementation, där kan en förbättring på upp till 15 gånger gällande beräkningstid förväntas.
Centralt inom utveckling är att skapa mer parallellism hos algoritmerna i konstruktionsfasen.
Valet av källor som ska användas är utvalda utifrån deras visade resultat i skapandet av effektiv parallellism på GPUn. Multi split KD-träd är algoritm som kunde har använts till arbetet som visar goda resultat för konstruktionstiden (Yang et al. 2016) eller BVH algoritmen HLBVH (Pantaleoni
& Luebke 2010). Information om algoritmen och deras detaljer beskrivs i mer detaljerad form i källorna som har valts än andra källor som kunde använts för implementationen.
Andra algoritmer som kunde användas för BVH lösningen är till exempel Wald (2007) men en observation om relevans har gjorts som kom fram till att Lauterbach et al (2009)
implementation har bidragit med mer än Wald (2007) i nuläget. Ytterligare lösningar som kan argumentera att vara bättre för spel är en uppdatering lösning (Yoon, Crutis & Manocha 2007) för BVH då trädet bara behöver konstrueras om trädets kvalité hamnar under ett förbestämt värde och kan istället uppdatera volymerna. Anledning till att en sådan algoritm inte valdes är svårigheten att hitta något som efterliknar uppdatering gällande KD-träd. Något som inte kommer implementeras från Lauterbach et al (2009) och Li et al (2017) är hur sökning genom träden görs utan istället kommer en enkel bredd-först-sökning implementeras på grund av att fokus ligger på konstruktionstid.
Istället för att använda en annan lösning för algoritmerna skulle en hypotesprövande
undersökning där resultat från annan forskning används för att bevisa en hypotes användas som forskningsmetod. Genom undersökning och analys utifrån forskning gjord på konstruktionstider för BVH och KD-träd kunna dra slutsatser angående deras effektivitet. Implementationerna av algoritmerna använder sig huvudsakligen av olika scener samt varierande hårdvara vilket leder till att en generell slutsats om algoritmerna inte kan göras och en orättvis jämförelse.
Valet av forskningsmetod landade på en experimentell studie. Innebörden av en experimentell studie är att beskriva arbetet med en liten del som består i ett större sammanhang. Användning av denna metod görs när forskaren inte har tid eller resurser att bedriva större forskning på området så används istället specifika fall för att representera sin frågeställning och världen (Ejvegård 2009). Vår studie kommer undersöka specifika fall och specifikt konstruktionstiden hos algoritmerna som kommer att representera algoritmernas för och nackdelar. Svagheter med att användas sig av en experimentell studie som metod är att enskilda fall och slutsatser inte kan representera fullt verkligheten men ge en vägledning och kan jämföras med annan forskning på området för kunna ge en fullständig bild av verkligheten.
13
4 Implementation
4.1 Brusfunktionen
Brusfunktionen som används skapas med hjälp av Unitys mathf.PerlinNoise funktion som är ett tvådimensionellt perlin brus, för att skapa tredimensionellt brus kombineras fleras exemplar från funktionen. Värdena från brusfunktionen sparas i en matris som sedan skapar en mesh. Från början skapade brusfunktionen kuber på varje plats om värdet från brusfunktionen översteg ett bestämt värde där varje kub består av 12 trianglar. För att minska antalet trianglar undersöktes varje positions grannar för att gallra ut kuberna som hade alla grannar. För att ytterligare reducera antalet trianglar användes sidor som bestod av två trianglar istället för kuber. Sökning av grannarna används även för att bestämma vilka sidor som ska konstrueras.
Brusfunktionen går att styra genom att ändra upplösningen vilket bestämmer hur stor matrisen blir och gör att skalan på bruset kan ändras. Även frekvensen på bruset kan ändras. Tröskelvärdet ändrar hur högt värdet måste vara för att konstruera bruset.
Figur 9
Exempel på mesh skapat från brusfunktionen
14
4.2 Axis Algined Bouding Box
Implementationen av AABB gjordes som en struktur på grund av att compute shaders inte tillåter klasser. AABB innehåller två vektorer med tre element var som håller data om lådans kanter.
AABB strukturen håller också en integer som lagrar ett index som används i samband med en lista av trianglar för att få ut vilken triangel som tillhör AABB strukturen.
Trianglarnas AABB räknas ut parallellt på GPU i trådgrupper om fyra och antal grupper är lika med antalet trianglar dividerat med fyra. Kanterna för lådan räknas ut från triangelns vertices där minsta värdet för x, y och z samt högsta värdet för x, y och z axlarna räknas ut. Efter trianglarnas AABB räknats ut synkas alla trådar för att kunna räkna ut kanterna för AABB strukturen som omsluter alla trianglar, denna AABB räknas ut med tre trådar där varje tråd räknar ut varsin axels minimum och maximum position för kanterna. Både BVH och KD-träd använder sig av denna AABB implementation.
function AABBGeneration(uint threadID)
set float3 triangle0 to vertices[triangles[threadID * 3]]
set float3 triangle1 to vertices[triangles[threadID * 3 + 1]]
set float3 triangle2 to vertices[triangles[threadID * 3 + 2]]
set minValue to triangle0 set maxValue to triangle0
set minValue.x to min(minvalue.x, triangle1.x) set minValue.y to min(minvalue.y, triangle1.y) set minValue.z to min(minvalue.z, triangle1.z) set minValue.x to min(minvalue.x, triangle2.x) set minValue.y to min(minvalue.y, triangle2.y) set minValue.z to min(minvalue.z, triangle2.z) set maxValue.x to max(maxvalue.x, triangle1.x) set maxValue.y to max(maxvalue.y, triangle1.y) set maxValue.z to max(maxvalue.z, triangle1.z) set maxValue.x to max(maxvalue.x, triangle2.x) set maxValue.y to max(maxvalue.y, triangle2.y) set maxValue.z to max(maxvalue.z, triangle2.z) set AABBBuffer[threadID].minPoint to minValue set AABBBuffer[threadID].maxPoint to maxValue set AABBBuffer[threadID].triangleIndex to threadID * 3 if (threadID < 3) do
set split to threadID mod 3
set minFloat to AABBBuffer[0].minPoint[split]
set maxFloat to AABBBuffer[0].maxPoint[split]
for int i = 0 to triangleCount set minFloat to
min(AABBBuffer[i].minPoint[split],minFloat)
15 set maxFloat to
max(AABBBuffer[i].maxPoint[split],maxFloat) set rootNode.minPoint[split] to minFloat
set rootNode.maxPoint[split] to maxFloat
Figur 10
Pseudokod för AABB konstruktion
Figur 11
AABB för trianglarna
4.3 Morton kod
Morton kod används för att i senare steg kunna sortera trianglarna. På grund av att morton kod kombinerar alla tre koordinataxlar till en 32-bit integer får datan inte vara för stor. Detta görs genom att kartlägga varje triangels axel till ett värde mellan noll och ett beroende på vart den befinner sig i den stora AABB som täcker alla trianglar. Om värdet är 1 innebär det att triangeln ligger vid maxgränsen för den stora AABB och om värdet är noll ligger den vid minimumgränsen.
Värdet som kartlagts multipliceras med 1 024 eftersom att hela tal ska användas och inte decimaltal. 1 024 används för att det går att representera med 10 bitar vilket gör att alla tre axlar får plats i en 32 bit integer. Värdet kodas med hjälp av morton kod enligt Figur 12. Morton koden används för både BVH och KD-träd.
function EncodeMorton(float3 p, NodeAABB root) uint3 code;
//gör om kordinaterna till ett värde mellan 0 - 1 beroende på position inom rooten set p to InverseLerpVector(root.minPoint, root.maxPoint,p)
for int i = 0 to 3
16 multiply p[i] by 1024
clamp p[i] between 0,1023 set code[i] to bitSeperation(p[i]) return code[2] << 2 | code[1] << 1 | code[0]
function bitSeperation(uint var)
//maskerar ut värden mellan 0 - 1023 var &= 0x000003ff
//separerar värden så att 123 -> 1--2--3 var = (var ^ (var << 16)) & 0xff0000ff;
var = (var ^ (var << 8)) & 0x0300f00f;
var = (var ^ (var << 4)) & 0x030c30c3;
var = (var ^ (var << 2)) & 0x09249249;
return var
Figur 12
Pseudokod för morton kod
4.4 Radix sort
Radix sorten sorterar elementen bitvis och börjar med den minst värda biten och rör sig uppåt till den största satta biten. Varje elements bitar undersöks om de är satta eller inte för att bilda ett histogram. Histogrammet används för att veta hur många bitar som är satta och inte satta för att avgöra vart de satta bitarna ska börja i en lista vid sortering. Implementationen utför även en beräkning av summan av alla föregående element i histogrammet vilket i denna implementationen är onödigt då endast två unika element finns i histogrammet på grund av att endast en bit undersöks per passering. Vilket leder till att denna uträkning är nödvändig när flera bitar ska undersökas som i Lauterbach et al (2009) implementation där två bitars undersöks per gång. För att behålla ordningen på elementen i listan efter sorteringen beräknas nollorna och ettorna i den ordning de förekommer, denna uträkning liknar uträkning för histogrammet se Figur 13. Med ordning på de satta bitarna, ordning på de icke satta bitarna och förskjutningen för vart de satta bitarna ska börja i listan kan en sorterad lista skapas. Upplägget för radix sorten är baserat på Satish, Harris och Garland (2009).
Implementationen av radix sorten gjordes på CPUn. Tester gjordes på att beräkna histogrammet på GPUn men konstruktionstiden ökade troligtvis på grund av att en flaskhals uppstod när data skulle skickas till och från GPUn.
function SortOneBit(mortonCode codes,uint bit) for int i = 0 to triangleCount
if(codes[i] & bit) equals bit do set value to 1
else do
set value to 0 increment histogram[value]
for i = 1 to histogram.length
set histogramPrefix[i] to histogram[i - 1]
int onePointer, zeroPointer for i = 0 to triangleCount
if(codes[i] & bit) equals bit do
set output[onePoiner + hisogramPrefix[1]] to codes[i]
increment onePointer
17 else do
set output[zeroPointer + hisogramPrefix[0]] to codes[i]
increment zeroPointer' for i = 0 to triangleCount
set codes[i] to output[i]
Figur 13
Pseudokod för radix sorten
4.5 Boundary Volume Hierarchy
BVH nod strukturen innehåller fyra integer. Den första integern håller sitt eget index, andra indexet på vänstra barnet, tredje indexet på högra barnet och den fjärde föräldrar indexet.
Strukturen innehåller även en unsigned integer på 32-bitar som håller morton koden. Strukturen har även en AABB struktur. BVH konstruktionen består av uträkning av morton kod för AABB strukturerna som omsluter trianglarna, sortering av morton koderna med radix sort, konstruktion av hierarkin och konstruktion av AABB strukturen för de inre noderna.
För att skapa ett BVH träd så behövs AABB strukturerna för alla trianglar samt en AABB som täcker alla trianglar. Listan för BVH noderna är N * 2 - 1 lång där N är antalet trianglar som även är antalet löv och N -1 är antalet inre noder. Alla löv lagras mellan 0 och N - 1 i listan och alla inre noder lagras mellan N och N * 2 - 1, där rotnoden för trädet hamnar på index N.
Efter morton koderna har skapats och sorterats konstrueras träd hierarkin parallellt genom att starta en tråd för varje inre nod som väljer ut både vänstra och högra barnnoder utifrån sin egen morton kod. Vilket fungerar eftersom morton koden är sorterade och att det lätt går att se vart medianen för alla element ligger genom att undersöka vart den största satta biten skiljer sig och sedan den näst största och så vidare tills alla löv noder har en förälder nod. Implementationen är baserad på Karras (2012). Denna implementation skiljer sig från Lauterbach et al (2009) som istället bygger hierarkin i samband med beräkningar görs när delningen räknas ut.
Implementationen skiljer sig eftersom Pantaleoni och Luebke (2010) samt Luterbach et al (2009) anger att hierarki konstruktionen för LBVH har nackdelen att trädet måste undersökas efter konstruktionen. Efter hierarkin är skapad behövs bara AABB strukturen för de inre noderna vilket görs via en botten upp implementation som räknar ut AABB strukturen beroende på barn nodernas AABB strukturer.
18
Figur 14
BVH trädets AABBer
4.6 KD-träd
KD-träd noden är uppbyggd på samma sätt som BVH noden med fyra integers som håller index för barn, föräldrar och sig själv. Den innehåller också ett integer för split som görs på AABB boxarna. Trädet har alla AABB boxar och en box som omsluter hela objektet som sin rot. Morton koden körs för att sedan kunna sortera trianglarna inom den stora boxen. Radix
sorteringsalgoritm körs för att sortera boxarna till rätt plats efter sitt morton kod värde. Efter dessa tre steg har körts körs uppdelningssteget i algoritmen på boxarna. Steget går till på
följande sätt där algoritmen utgår ifrån rot noden och delar upp denna box i ett antal iterationer på varje djup. Delningen görs på den längsta axeln hos varje AABB.
19
Figur 15
KD-Träd Uppdelning av objektet.
Efter uppdelningen har gjorts körs sista steget i algoritmen vilket skapar boxar för
föräldranoderna i trädet. Steget skapar en AABB box som omsluter de barnnoder den innehåller.
En relation mellan delningen och trädstrukturen skapas.
Figur 16
Strukturen för KD-träd algoritmen.
Grunden för algoritmen utgår från Li et al (2017) forskning angående parallellism och hur morton koden kan användas för att bygga upp en trädstruktur för kd-träd. Skillnaden mellan
20
den lösning som presenteras i Li et al (2017) forskning och den implementation som använts i arbetet är hur konstruktion av delningssteget för algoritmen. Där delning av morton kodens värde bestämmer vart delning ska ske har en delning valts som ska ske utifrån rotnoden och iterativt gå neråt och dela AABB boxarna. När steget skapa föräldrar körs i algoritmen kommer den skapa korresponderande AABB boxar som omsluter delningen som gjorts på boxarna. Vilket kan ses i Figur 13 hur föräldrar noderna omsluter delningen som gjorts.
Calculate Split() KDtree <- RWBuffer
while(depth < maxDepth) for each aabb in KDtree
split the aabb along the longest axis
depth++;
Figur 17
Pseudokod för delningsteget
Utifrån Figur 17 som beskriver psuedokoden går det att se koden körs i ett antal iterationer vilket kan bestämmas. Ett för högt värde medför en högre beräkningstid för algoritmen och ett för lågt värde ger försämrad kvalitet för trädet. Ett alltför högt värde ger inte bättre kvalitet på
trädstrukturen utan genom prövning har ett värde som passar prövats , värdet har varit mellan 50-100. I pseudokoden korresponderar värdet med variabeln maxdepth vilket är djupet för delning som ska köras.
4.7 Strålföljning
Strålföljningen som implementeras är baserad på Whitted (1980). Strålföljning shadern implementerar skuggor och reflektioner. Strålföljning shadern har en bakgrund, ett plan och antingen BVH-trädet eller KD-trädet. Shadern består av två delar. Strålföljning delen som identifierar träffar och skuggning delen som bestämmer beroende på data från träffen utseendet.
Strålföljning shadern används för att söka igenom träden för både BVH och KD-träd. Sökning implementeras med en bredd-först-sökning på båda strukturerna där rotnoden undersöks först.
Om någon stråle är innanför AABB strukturen för rotnoden hämtas båda barnnoderna och jämförs mot strålen, vilket fortsätter tills lövnoderna nås då nodens triangel jämförs mot strålen. Om en träff identifierades skickas data om träffen vidare till skuggnings delen.
Styrning av strålföljning shadern går till genom att stänga av och sätta på den, byta acceleration struktur som används samt att ändra antalet studsar som ska göras för reflektionerna.
21
Figur 18
Sökning genom ett BVH träd med hjälp av strålföljning.
4.8 Datainsamling
Den data som samlas in är upplösningen, frekvensen, skalan, tröskelvärdet, antalet trianglar och beräkningstiden för accelererationsstrukturen. Beräkningstiden skaffas genom att mäta tiden med hjälp av unitys Time.realtimesincestartup funktion innan accelerationsstrukturen byggs om. För att minska overhead görs konstruktionstid testen utan strålföljning. Varje scenario testas fem gånger för att minska risken för felaktiga värden. Värdena samlas in i en xml fil.
4.9 Förstudie
Alla tester genomfördes på samma hårdvara där en i5 9600k användes som CPU och GTX 1080 som GPU.
22
Figur 19
Alla test scener som användes från höger vänster till höger. Standard, Utspridd, Kub med hål, Terräng slice, Varannan kub och Öar.
Tabell 1 Värdena som användes för att skapa test scenerna Standard Utspridd Kub med
hål Terräng
Slice Varannan
kub Öar
Upplösning 12 12 12 24 24 32
Brus skala 1 1 1 2 1 1
Frekvens 0.05 0.6 0.5 0.02 0.5 0.05
Tröskelvärde 0.609 0.85 0.3 0.855 0.855 0.95
Antal trianglar 984 680 3 992 5 904 22 436 880
Värden på brusfunktionen har justerats för att få en rättvis jämförelse mellan algoritmerna och olika fall har testas. Vilket har möjliggjort det att utvärdera vilka scener som är effektiva för algoritmerna alternativ ineffektiva på.
Figur 20
Resultat av medelvärdet för testerna
Resultaten visar att BVH konstrueras mer effektivt än KD-träd i alla testfall. Hur mycket mer effektivt BVH konstrueras skiljer sig dock mellan testerna vilket går att se i Tabell 2 där den
23
största skillnaden på KD-träd och BVH är 140 % vilket säga att KD-trädet tog 140 % längre tid att konstruera, den minsta skillnaden var en ökning på 34 %.
Tabell 2 Tabell över resultaten Standard
(984 Trianglar)
Utspridd (680 Trianglar)
Kub med hål (3 992 Trianglar)
Terräng slice (5 904 Trianglar)
Varannan kub (22 436 Trianglar)
Öar (880 Trianglar)
KD-Träd 13.9ms 8.4ms 32.1ms 47.1ms 91.2ms 7.7ms
BVH 5.8ms 5ms 17.9ms 25.9ms 68.2ms 4ms
Procent
ökning 140 % 68 % 79 % 82 % 34 % 93 %
Ytterligare testningar gjordes för att undersöka hur tiden växer med antalet trianglar för vilket användes parametrarna i Tabell 3, alla tester konstruera en kub med varierande storlekar och triangel antal.
Tabell 3 Tabell över värden som används för att konstruera kuberna
Kub 8 Kub 16 Kub 24 Kub 32 Kub 40
Upplösning 8 16 24 32 40
Brus skala 1 1 1 1 1
Frekvens 1 1 1 1 1
Tröskelvärde 0 0 0 0 0
Antal
trianglar 768 3 072 6 912 12 288 19 200
24
Figur 21
Ändring av konstruktionstid beroende på antal trianglar
25
5 Utvärdering
Syftet med denna undersökning var att jämföra konstruktionstiden för två olika accelerationsstrukturer, BVH och KD-träd. I detta kapitel kommer den data som samlats redovisas för att sedan utvärderas och diskuteras.
5.1 Presentation
Utifrån förstudien gjordes iakttagelsen att skillnaden mellan BVH och KD-träd minskade med antalet trianglar, därav genomfördes fler tester där antalet trianglar var stort för att vidare undersöka. Tester gjordes även där antal trianglar var runt samma men scenens utformning skilde sig. Parametrarna för alla tester ses i Tabell 4, Testerna är sorterade efter antal trianglar i Tabell 4, Tabell 5 och Figur 23.
Figur 22
Brus motsvarande Tabell 4
Tabell 4 Parametrarna som används för bruset
Upplösning Brus skala Frekvens Tröskelvärde Antal Trianglar
Utspridd 12 1 0.6 0.85 680
Öar 32 1 0.05 0.95 880
Standard 12 1 0.05 0.609 984
Kub med hål 12 1 0.5 0.3 3 392
Terräng slice 24 2 0.02 0.855 5 904
Sammanhän
gande 42 1 0.03 0.8 12 496
Varannan
Kub 24 1 0.5 0.855 22 436
Standard 36 36 1 0.05 0.55 22 720
26 Sammanhän
gande 2 64 1 0.02 0.8 28 208
Figur 23
Resultat från test scenerna för BVH och KD-träd
Olika fall av scener har testas som ses i Figur 23 och i Figur 22 med bilder. Slutsatsen av dessa fall är utformning av scenen inte påverkar konstruktionstiderna för antingen BVH eller KD-träd.
Tabell 5 Resultat för testerna i millisekunder och procent skillnad
KD-träd BVH BVH/KD-träd
Utspridd 8.4 ms 5 ms 60 %
Öar 7.7 ms 4 ms 52 %
Standard 13.9 ms 5.8 ms 42 %
Kub med hål 32.1 ms 17.9 ms 56 %
Terräng slice 47.1 ms 25.9 ms 55 %
Sammanhängande 79.4 ms 43.4 ms 55 %
Varannan kub 91.2 ms 68.6 ms 75 %
Standard 36 91.7 ms 70.9 ms 77 %
Sammanhängande 2 112.2 ms 83.2 ms 74 %
27
Figur 24
Kurva på hur konstruktionstiden ökar med antalet trianglar
Tabell 6 Tabell för punkterna som användes i Figur 24KD-träd BVH Trianglar
Kub 8 4.4 ms 3 ms 768
Kub 16 18.6 ms 13.2 ms 3 072
Kub 24 52.9 ms 29.8 ms 6 912
Kub 32 76.2 ms 42.8 ms 12 288
Kub 40 83.8 ms 52.6 ms 19 200
Kub 46 102.2 ms 78.4 ms 25 392
Kub 52 125.6 ms 97.8 ms 32 448
5.2 Analys
Under implementationen iakttogs en flaskhals i samband med att data skickas till GPUn därav gjordes tester på att jämföra histogram uträkning för radix sort genom att jämföra två
28
implementationer en på CPUn och en på GPUn som ses i Figur 25.
Figur 25
Beräkning av histogrammet på GPU och CPU för BVH
I Figur 25 utläses att GPU implementationen för uträkningen av histogram presterar sämre, vilket verkar bero på att det tar lång tid att skicka data från och till GPU då radix sort steget behöver göra upp till 30 passeringar för att garantera en korrekt sorterad lista. Stora mängder data skickas fram och tillbaka, vilket utgör anledningen till skillnaden mellan implementationerna. Som förmodligen även är en av anledningarna till att Lauterbach et al (2009) sorterar två bitar per passering vilket minskar antal passeringar och därav mängden data som skickas till och från GPUn.
Kurvorna i Figur 24 visar konstruktionstiden och antalet trianglar, desto fler trianglar som används desto mer planar kurvorna på diagrammet ut. Kurvan liknar för båda algoritmerna en linjär kurva i sin utveckling. Att utvecklingen är linjär innebär att algoritmerna som används kan skalas upp till högre antal trianglar med en resonabel utveckling.
Scenens utformning och uppbyggnad har en minimal inverkan på konstruktionstiderna hos algoritmerna. Vilket har undersökts genom att köra olika tester och resultatet från dessa tester visar att aspekten på scenens utformning inte påverkar tiden som krävs för konstruktionen.
Utifrån resultatet från testerna syns att skillnaden mellan KD-träd och BVH skiljer sig mindre desto fler trianglar som används. Vilket betyder att skillnaden mellan KD-träd och BVH planar ut desto fler trianglar som används i en scen. Enligt Vinkler et al (2014) blir KD-träd algoritmen effektivare vid högre komplexitet än BVH. Triangelantalet är över 100 000 trianglar och uppåt.
Vilket överensstämmer med den tolkning som gjordes på triangelantalets utveckling och att skillnaden mellan algoritmerna minskade med ökat triangelantal. KD-träd algoritmens tidskompensation spenderas huvudsakligen i konstruktionsfasen där resultat från tester gjorda visar att ju högre komplexitet med triangelantal i scenen som används ju mer procentandel spenderas i konstruktionen. 80 - 95 % av hela tiden används för algoritmen att köra konstruktionsfasen (Liu, Deng, Ni, Li, 2015). Vilket är en intressant aspekt på KD-träd som för
29
tillfället inte används i spelutveckling då den anses vara ineffektiv för datorspel. Företaget Nvidia har utvecklat en hårdvarulösning utifrån BVH algoritmen (Viitanen, 2019).
5.3 Slutsatser
Resultaten från Figur 23 visar att BVH algoritmen har en effektivare konstruktionstid i alla olika scener som skapades. Som överensstämmer med andra resultat från forskning på strålföljning och konstruktionstiderna hos algoritmerna som används (Zhou et al. 2008). Från analysen dras slutsatsen att KD-träd bör prestera bättre än BVH i större scener. Vilket kan ses genom iakttagelsen att ett högre triangelantal minskar skillnaden mellan BVH och KD-träd, vilket även stämmer överens med forskning från Vinkler et al (2014). Utifrån resultatet i Figur 23 utvärderas att utformning av scenen inte påverkar konstruktionstiderna för algoritmerna som används. Som påverkar tiderna för algoritmerna är storleken av triangelantalet som används och inte utformningen. Testerna “varannan kub” och “standard 36” i Figur 23 har liknande triangelantal men annan utformning. Resultatet visar på liknande konstruktionstider för både BVH och KD- träd.
I resultatet går att se att data som skickades mellan CPU och GPU utgjorde en flaskhals som påverkade uppdateringstiden för algoritmerna och strålföljning. Tester på histogrammet som användes för algoritmerna visade ineffektiviteten i att beräkna denna del på GPU istället för CPU.
30
6 Avslutande diskussion
6.1 Sammanfattning
I arbetet undersöktes konstruktionstiderna för två olika accelerationsstrukturer. BVH och KD- träd användes för att undersöka vad för påverkan scenens uppbyggnad har på strukturerna.
Tidigare forskning visar att de två mest relevanta strukturerna är BVH och KD-träd (Vinkler et al 2014,2016). På grund av att accelerationsstrukturer möjliggör realtidssökning har forskning på senare år främst fokuserat på BVH då denna struktur är bättre anpassad. För dynamiska scener där trianglar ändrar positioner och antalet förändrats. Forskning finns av Zhou et al (2008) som visar att KD-träd även fungerar för dynamiska scener, vilket är anledning varför denna undersökning kommer fokusera på konstruktionstiderna för dessa två strukturer och om scenens uppbyggnad kan ge fördelar för någon av strukturerna. Undersökningen gjordes för att undersöka om KD-träd presterade bättre än BVH gällande konstruktionstid då BVH historiskt sett har varit bättre men KD-träd har haft bättre genomsökning av sin trädstruktur. Implementationen baserades på forskning av Lauterbach et al (2009) och Li et al (2017) för BHV respektive KD-träd, dessa två valdes för att många av stegen i konstruktionen av strukturerna är samma i båda samt att båda är GPU baserade. Resultaten visar att scenens konstruktion inte har någon märkbar påverkan på konstruktionstiden samt att BVH konstrueras upp snabbare än KD-träd i alla testscener, ytterligare slutsatser som drogs var att med ökande antal trianglar så blev procent skillnaden mellan KD-träd och BVH mindre avseende konstruktionstiden.
6.2 Diskussion
I kapitlet diskuteras forskningsmetoden som använts, implementation, påverkan denna undersökning kan ha på samhället samt även förslag för framtida arbeten.
6.2.1 Metod
Implementationen gjordes i spelmotorn Unity. Skillnaden är att andra forskningsartiklar oftast använder sig av programmeringsspråket CUDA och testerna huvudsakligen görs på standardiserade bildobjekt från Stanford university (Li et al 2017, Zlatšuka et al 2010). Istället har programmeringsspråket HLSL valts och egna scener gjorts som testas i spelmotorn Unity.
Begränsningar finns i versionen av programmeringsspråket HLSL som används av Unity och överflödiga overheadkostnader som kan påverka beräkningstiden negativt. Resultatet från våra tester är inte aktuella att använda för forskningssyfte utan är till för att se hur olika varianter av datastrukturer kan användas för att accelerera strålföljning inom spelutveckling. Vilket är anledningen till beslutet om att implementera datastrukturernas lösningar i spelmotorn Unity för att med overheadkostnaderna se hur resultat av strålföljning skulle fungera i en spelmotor.
Språket HLSL har begränsats i Unity så att data inte kan lagras på globala buffrar på grafikkortet utan att istället behövs skickas fram och tillbaka mellan CPU och GPU varje gång ett nytt steg ska köras i algoritmen. HLSL ska ha globala buffrar implementerade i sitt språk som inte fungerar i Unity vilket ledde till en flaskhals för data skickandet mellan komponenter.
6.2.2 Implementation
Brusfunktionen som användes i arbetet har en nackdel. Alla trianglar som skapas har samma storlek. Vilket gjorde att alla AABB strukturer som skapades hade minimal överlappning förutom
31
om trianglar tillhörde samma sida då de istället överlappade helt. Att BVH och KD-träd hanterar överlappning på olika sätt (Wald et al, 2009) kan ha påverkat resultaten.
Resultaten av konstruktionstiderna från Figur 23 visar på konstruktionstider som inte mäter sig med Lauterbach et al (2009) och Li et al (2017) som har en konstruktionstid på 9.8 millisekunder med 49000 trianglar respektive 4.3 millisekunder med 69000 trianglar. Den primära anledningen till skillnaden i konstruktionstid beror på flaskhalsen som uppstår vid skickandet av data mellan CPU och GPU vilket går att se i Figur 25.
En aspekt som har påverkat resultatet har varit länken mellan CPU och GPU, där data har behövt skickas över i flera steg på algoritmerna, vilket kan ses i Figur 25 och tas upp i analysdelen i arbetet.
Resultatet har därför påverkats negativt för varje steg i algoritmen då data behövts skickas fram och tillbaka mellan dessa enheter vilket har lett till försämrad konstruktionstid för båda algoritmer. Vilket kommer påverka prestanda i datorspel och skulle leda till försämrad uppdateringstid för bildsekvenser i spelet.
I Figur 24 ses utveckling av triangelantalet med konstruktionstid genom att studera antalet trianglar, därför är det inte aktuellt att köra implementation som används direkt på datorspel.
Konstruktionstiderna är inte aktuella med triangelantalets utveckling vilket leder till hög beräkningstid som inte är önskvärt i ett spel.
Om 30 bilder per sekund ska uppnås måste det maximalt ta 30 millisekunder vilket vår BVH implementation gör med runt 7 000 trianglar vilket är ett lågt antal trianglar. Flera olika system som finns i spel måste också uppdateras med samma frekvens så att den realistiska tiden som konstruktionen tar bör vara betydligt lägre. Gruen et al (2019) anger att i spelet Shadow of the Tomb Raider (2018) tar BVH konstruktionen cirka 10 000 000 trianglar per sekund vilket jämfört med vår implementation som tar cirka 250 000 trianglar per sekund ger en bättre bild på hur lång tid det realistiskt får ta att konstruera upp accelerationsstrukturer.
6.2.3 Parallellism
Implementation kör trådarna på GPU i små grupper av en till fyra trådar för konstruktionen av BVH och KD-träd. Tester gjordes med grupper på 32-trådar, dock slutade hierarki steget på konstruktionen att fungera korrekt med grupper på 32-trådar och de delar som fungerade korrekt med en större trådgrupp gav ingen märkbar prestandaökning. Implementationen har även begränsad parallellism när det kommer till skapandet av AABB strukturen som innehåller hela scenen där den för närvarande bara kör tre trådar. En för varje axel som går igenom listan av AABB strukturer var för sig. En mer parallell lösning vore att dela upp listan i ett antal delar och sedan lägga ihop alla delar för att skapa den AABB strukturen. Nackdelen vore att alla delar skulle behöva synkas vilket även skulle innebära större buffertar. Större buffertar skulle leda till mer data som skickas mellan CPU och GPU och därav skulle flaskhalsen kännas av mer vilket är anledningen till att den föreslagna lösningen inte används.
6.2.4 Samhällelig nytta
En aspekt på en samhällelig nytta är att spelföretag som använder strålföljning i sina produkter har efterfrågat effektivare beräkningstider. Genom att undersöka algoritmerna och analysera deras resultat kan förståelsen för accelerationsstrukturer öka. Vilket kan leda till att ge bättre kunskap om vilka användningsområden olika algoritmer är effektiva för inom spelutveckling.
Minskning av beräkningstid som en algoritm tar leder till bättre effektivitet hos användaren av
32
programmet som i sin tur kan leda till bättre ekonomiskt vinning för företag som implementera strålföljning i sina produkter.
Nackdelen ifall strålföljning blir den teknik som huvudsakligen används inom datorgrafik är att vissa jobb kan försvinna. Strålföljning skapar realistiska effekter för miljöer och scener som kan hota vissa grafiska jobb, men troligtvis kommer andra jobb skapas där kunskap om strålföljning kommer uppskattas. Om denna teknik blir världsledande inom datorgrafik om tio år är det viktigt ur en miljöaspekt att se på effektivitet hos algoritmer som kan användas. En liten förbättring hos en algoritm som används av ett stort antal användare kan leda till minskad energiförbrukning för program som implementerar strålföljning.
Undersökningen visar tecken på att KD-träd kan vara mer effektivt än BVH i större scener vilket förhoppningsvis kan visa att KD-träd fortfarande kan vara relevant när det kommer till realtids strålföljning. Vilket även går att se i Vinkler et al (2014) undersökning att KD-träd presterar bättre än BVH i större scener. I samband med att realtids strålföljning blir mer vanligt går det att tänka sig att större och större scener kommer användas på grund av att ny teknik utvecklas för att effektivisera strålföljning, vilket kan innebära att KD-träd kommer kunna användas i framtiden istället för BVH.
Ur ett energiperspektiv är strålföljning en krävande teknik att använda sig av. Spelutveckling har istället valt att använda sig av hybridlösningar mellan strålföljning och rastrering tekniken. Vilket för rastrering ger lika effektiva resultat på vissa effekter inom datorgrafik medans strålföljning ger mer realistiska effekter på områden som reflektioner inom datorgrafik. Genom att använda sig av hybridlösning skulle det gå att minska energianvändandet av programmet som körs.
6.3 Framtida arbeten
Ett kortsiktigt perspektiv på arbetet är att vidare undersöka flaskhalsen som bildas mellan CPU och GPU då denna flaskhals haft en stor påverkan på algoritmernas prestanda. Om denna flaskhals motverkas antingen helt eller delvis så vore det intressant att undersöka hur resultaten blir för att eventuellt kunna dra fler eller nya slutsatser och för att se hur uppdateringstiden för algoritmerna påverkas. Vilket är viktigt för att kunna dra slutsatser för framtida arbetens resultat för att kunna få strålföljning att effektivt köras i realtid.
För att kunna vidareutveckla arbetet ur ett långsiktigt perspektiv skulle algoritmerna kunna testas i spelmiljöer. Vilket skulle vara intressant eftersom inte allt i ett spel renderas med strålföljning utan görs med hjälp av rastreringsteknik som används för att skapa hybrid scener. Resultaten skulle bättre återspegla hur algoritmerna kommer användas vilket vore intressant (Nvidia Gameworks 2018). Fler algoritmer vore även intressant att prova då Zellman et al (2019) utvecklade en BVH lösning som är specialiserad på glesa scener. Även jämnförningar av olika BVH lösningar vore intressant. Där uppdatering används för att undersöka hur dessa mäter sig mot konstruktionstider samt hur ofta en omkonstruktion måste ske för att behålla kvaliteten på träden.
Ett annat långsiktigt perspektiv skulle vara ifall CUDA kunde implementeras i programspråket i spelmotorn Unity. För att se resultaten av en implementation med CUDA språket. Unity som spelmotor är CPU centrerad och en lösning baserad på CUDA skulle kunna göra att grafikkortets fulla potential går att utnyttja. Anledningen till att det inte går att få till så effektiva resultat i Unity är att det finns hinder och problem med HLSL vilket skulle kunna lösas med CUDA.
33
Referenser
Appel, A. (1968). Some techniques for shading machine renderings of solids. In Proceedings of the April 30--May 2, 1968, spring joint computer conference (AFIPS ’68). Association for Computing Machinery, New York, NY, USA, 37–45. doi:10.1145/1468075.1468082.
Bittner, J., Hapala, M. & Havran, V. (2015). Incremental BVH construction for ray tracing.
Comput. Graph. 47(C), ss. 135–144. doi: 10.1016/j.cag.2014.12.001.
Clark, J. (1976). Hierarchical geometric models for visible surface algorithms. Commun. ACM, 19(10), ss. 547–554. doi:10.1145/360349.360354.
Cook, R., Porter, T. & Carpenter, L. (1984). Distributed ray tracing. Comput. Graph. 18(3), ss 137–
145. doi:10.1145/964965.808590.
Doyle, M., Fowler, C. & Manzke, M. (2013). A hardware unit for fast SAH-optimised BVH construction. ACM Trans. Graph. 32(4), Artikel 13, 10 sidor. doi:10.1145/2461912.2462025.
Ejvegård, R. (2009). Vetenskaplig metod. 4.uppl., Lund: Studentlitteratur.
Fujimoto, A., Tanaka, T. & Iwata, K. (1986). ARTS: Accelerated Ray-Tracing System. IEEE Computer and Applications, 6(4). ss. 16 - 17. doi: 10.1109/MCG.1986.276715.
Geimer, M. & Müller, S. (2003) A cross‐platform framework for interactive ray tracing.
Tagungsband Graphiktag der Gesellschaft für Informatik. Frankfurt am main, Tyskland. ss.
25– 34.
Gruen, H., Roze, M. & Story, J. (2019). “Shadows” of the Tomb Raider: Ray Tracing Deep Dive [video]. https://www.gdcvault.com/play/1026163/-Shadows-of-the-Tomb [2020-05-08].
Günther, J., Fredrich, H., Seidel, HP. & Slusallek, P. (2006). The Visual Computer. 22(9-11). ss.
785-792. doi:10.1007/s0037-006-0063-x.
Havran, V. (2000) Heuristic Ray Shooting Algorithms. Department of Computer Science and Engineering, Faculty of Electrical Engineering, Czech Technical University in Prague.
Karras, Tero. (2012). Maximizing parallelism in the construction of BVHs, octrees, and k-d trees.
Proceedings of the Fourth ACM SIGGRAPH / Eurographics conference on High-Performance Graphics. Goslar, Tyskland.
Kay, T. & Kajiya, J. (1986). Ray tracing complex scenes. Proceedings of the 13th annual conference on Computer graphics and interactive techniques. Association for Computing Machinery, New York, NY, USA, ss. 269–278. doi: 10.1145/15922.15916.
Lauterbach, C., Garland, M., Sengupta, S., Luebke, D. & Manocha,D. (2009). Fast BVH Construction on GPUs. Computer Graphics Forum. 28(2), ss. 375-384. doi: 10.1111/j.1467- 8659.2009.01377.x.
Li, Z., Deng, Y. & Gu, M. (2017). Path Compression Kd-trees with Multi-layer Parallel Construction. A Case Study on Ray Tracing. Proccedings of the 21st ACM SIGGRAPh on interactive 3D Graphics and Games. 16(1-8). doi: 10.1145/3023368.3023382.
34
Liang, X., Yang, H., Zhang, Y., Yin, J. & Cao, Y. (2016). Efficent kd-tree construction for ray tracing using ray distribution sampling. Multimedia Tools and Applications. 75(23). ss 15881–15899.
doi:10.1007/s11042-015-2896-7.
Liu, X., Deng, Y., Ni, Y., Li, Z. (2015). FastTree: A Hardware KD-Tree Construction Acceleration Engine for Real-Time Ray Tracing. Proceedings of the 2015 Design, Automation & Test in Europe Conference & Exhibition. ss 1595-1598.
Marmitt, G., Friedrich, H. & Slusallek, P. (2008), Efficient CPU‐based Volume Ray Tracing Techniques. Computer Graphics Forum. 27(6). ss. 1687-1709. doi:10.1111/j.1467- 8659.2008.01179.x.
O’Donnell, Y. (2018) Precomputed Global Illumination in Frostbite. Game Developers Conference. San Francisco, USA 21 - 23 mars 2018.
Pantaleoni, J. & Luebke, D. (2010). HLBVH: hierarchical LBVH construction for real-time ray tracing of dynamic geometry. Proceedings of the Conference on High Performance Graphics.
Eurographics Association, Goslar, DEU, ss. 87–95.
Rubin, S. & Whitted,T. (1980). A 3-dimensional representation for fast rendering of complex scenes. Proceedings of the 7th annual conference on Computer graphics and interactive techniques. Association for Computing Machinery, New York, NY, USA, ss. 110–116. doi:
10.1145/800250.807479.
Real-Time Raytracing for Interactive Global Illumination Workflows in Frostbite (2018) [video].
San Francisco: Nvidia GameWorks
https://www.youtube.com/watch?v=rhlGBCSv02M&t=202s [2018 - 06-08].
Rege,A. (2008). An Introduction to Modern GPU Arhitecture [PowerPoint-presentation].
Hämtade från Januari 18 - 2020.
http://download.nvidia.com/developer/cuda/seminar/TDCI_Arch.pdf
Satish,N., Harris, M. & Garland, M. (2009) Designning effeicient sorting algorithms for manycore GPUs. IEEE International Symposium on Parallel & Distributed Processing. ss. 1-10. doi :10.1109/IPDPS.2009.5161005.
Shadows of the Tomb Raider (2018). Square Enix. Tillgänglig på Internet:
https://tombraider.square-enix-games.com/en-gb.
Viitanen, T. Koskela, M. Jääskeläinen, P. & Kultala, H. (2017). MergeTree: A Fast Hardware HLBVH Constructor for Animated Ray tracing. ACM Transactions on Graphics. 36(5), artikel 169. 14 sidor. doi: 10.1145/3132702.
Viitanen, T. (2019). Acceleration Data Structure Hardware (And Software). Siggraph 2019. LA, USA.
Vinkler, M., Havran, V. & Bittner,J. (2014). Bounding volume hierarchies versus kd-trees on contemporary many-core architectures. Proceedings of the 30th Spring Conference on Computer Graphics. Association for Computing Machinery, New York, NY, USA, ss. 29–36.
doi:10.1145/2643188.2643196.
