Själv-optimerande dynamisk adaptiv struktur för WebGL-applikationer

Teknik och samhälle Datavetenskap

Examensarbete

15 högskolepoäng, grundnivå

Själv-optimerande dynamisk adaptiv struktur för

WebGL-applikationer.

Self-optimizing dynamically adaptive structure for WebGL-applications.

Hektor Wallin

Examen: Kandidatexamen 180 hp Huvudområde: Datavetenskap Program: Spelutveckling

Datum för slutseminarium: 2013-05-30

Handledare: Johan Gustavsson Andrabedömare: Jonas Forsberg

Sammanfattning

Utvecklingen av datorer och deras förmåga ökar klyftan mellan datorer och skapar en stor mångfald av hårdvarutillgänglighet. Kapaciteten som datorer besitter varierar kraftigt och därmed även förmågan att hantera komplexa applikationer. Moderna applikationer erbju-der inställningar som användare kan anpassa för datorn, något som kräver att användaren har tillräcklig kunskap för att förstå inställningarnas eekt. Att välja ut de optimala in-ställningarna för datorn är en process som är både svår och tidskrävande. Detta arbete granskar hur ett dynamiskt adaptivt system automatiskt kan anpassa inställningarna för applikationen medan den kör, utan manuell extern inverkan. Systemet mäter kontinuerligt applikationen och individuella teknikers prestanda. Baserat på mätresultat anpassar det adaptiva systemet applikationens inställningar. Genom att abstrahera funktionaliteten att justera applikationen kan datorns kapacitet utnyttjas, utan varken användarens kunskap eller påverkan. Arbetet undersöker hur olika tekniker kan inuera applikationens prestanda och genomför tester av ett dynamiskt anpassande systems förmåga att skräddarsy appli-kationen för exekveringsmiljön.

Abstract

The development of computers and their ability increases the gap between computers and create a wide variety of hardware availability. The capacity that computers possess vary considerably and thus the ability to handle complex applications. Modern applications provides settings that users can customize for the computer, which requires the user to have sucient knowledge to understand the attitude of the eect. To select the optimal settings for your PC is a process that is both dicult and time consuming. This thesis examines how a dynamically adaptive system can automatically adjust the settings for the application while it is running, without manual external impact. The system continuously monitors the application and individual technologies performance. Based on measurements the adaptive system can customize applications settings. By abstracting the functionality to adjust the application the computer's capacity is utlizied, without neither the user's knowledge or inuence. The thesis examines how various technologies can inuence ap-plication performance and conducts tests of a dynamically adaptive system's ability to customize the application for execution environment.

Innehåll

1 Inledning 1 1.1 Problemdiskussion . . . 1 1.2 Bakgrund . . . 2 1.3 Syfte . . . 4 1.4 Frågeställning . . . 4 1.5 Avgränsning . . . 4 2 Metod 6 2.1 Teknik-metoder . . . 6 2.1.1 Shader-teknik . . . 7 2.1.2 Boll-teknik . . . 7 2.1.3 Level of Detail-teknik . . . 8 3 Implementation 9 3.1 Applikation . . . 9 3.1.1 Applikationens syfte . . . 9 3.1.2 Design . . . 9 3.2 API . . . 10 3.2.1 WebGL . . . 10 3.3 Bibliotek . . . 13 3.3.1 Cannon . . . 13 3.3.2 Klass . . . 14 3.3.3 GlMatrix . . . 14 3.4 Mätningar . . . 15 3.4.1 Mätvariabler . . . 15 3.4.2 Update . . . 16 3.4.3 Draw . . . 16 3.4.4 Wait . . . 17

3.4.5 Dynamisk adaptiv logik . . . 17

3.4.6 Implementation av tekniker . . . 20

3.5 Tester . . . 21

3.5.1 Syfte med testerna . . . 21

3.5.2 Design av test . . . 21 3.5.3 Testfall . . . 22 3.5.4 Boll-tekniker . . . 22 3.5.5 Shader-tekniker . . . 23 3.5.6 LoD-tekniker . . . 23 3.5.7 Dynamiskt adaptiv . . . 23 3.5.8 Testmiljö . . . 23

4 Resultat 25

4.1 Boll-tekniker . . . 25

4.2 Shader-tekniker . . . 25

4.3 LoD-tekniker . . . 27

4.4 Dynamiskt adaptivt system . . . 27

5 Analys 29 5.1 Resultat . . . 29 5.1.1 Boll-teknik . . . 29 5.1.2 Shader-teknik . . . 29 5.1.3 LoD-teknik . . . 30 5.1.4 Summering av teknikanalys . . . 30

5.2 Dynamiskt adaptivt system . . . 30

6 Diskussion 32 6.1 Prestanda . . . 32

7 Slutsats och vidare forskning 34

Referenser 35

A Ordlista 36

1 INLEDNING

1 Inledning

1.1 Problemdiskussion

Datorer nns med en enorm variation av kapacitet och är utvecklade för ett stort omfång av syften vilket resulterar i växlande kompetens mellan datorerna. Applikationers krav på datorns kapacitet måste anpassas för att kunna rikta sig mot en stor mängd användare i applikationens målgrupp. Applikationer som ska vara tillgängliga för en bred massa behöver ha en låg tröskel vad gäller krav på datorns potens för att möjliggöra att sämre datorer kan köra applikationen. Ett problem som uppstår med att utveckla applikationer speciellt designade för den minsta gemensamma nämnaren mellan datorer är att applikationen blir begränsad i mån av vilken logik och genre applikationen tillåts implementera. Den visuella presentationen måste även vara tillräckligt enkel för lågpresterande hårdvara att hantera. Applikationens graska presentation kan inte utnyttja moderna avancerade tekniker och inte heller använda högt detaljerade objekt med stort antal polygoner. Applikationens prestandakrav riskerar bli för tungt och exkludera mindre kapabla datorer.

Ett alternativ till att skala ner applikationer är att inte ta hänsyn till datorers kapacitet och implementera moderna krävande tekniker för de som uppnår kraven. Applikationer kan ha ett enhetligt, visuellt tilltalande, framförande men med nackdelen att färre datorer kan behandla applikationen och blir tillgänglig för färre användare. Användare med kraftfullare datorer kan fortfarande köra applikationen och erbjuds en rik upplevelse, men en påtaglig del av den potentiella användarbasen går förlorad. Ingen av situationerna är optimal varken för användare eller utvecklare. För att tillgodose båda behoven hos applikationen, att vara tillgänglig för datorer i ett brett spektrum av kapacitet och samtidigt erbjuda avancerade tekniker, innehåller applikationer ofta inställningar som användaren kan anpassa för att förändra nivån hos applikationen.

Applikationer förses vanligen med en meny där användaren kan påverka inställningarna för applikationen. Ofta innehåller menyn antingen en mängd variabler så användaren kan kontrollera direkt vilka tekniker som används, eller består menyn av ett bestämt antal steg för applikationens totala nivå, där varje nivå påverkar era tekniker.

Inställningsmenyer med många variabler att förändra kräver viss kunskap och förståelse hos användaren för vilken eekt teknikerna har och vad de olika variablerna påverkar. För optimalt resultat behöver användare även veta vilka inställningar som passar den egna datorn bäst. Användare kan alternativt testa sig fram mellan olika inställningar, en process som är svår att förstå och få rätt, samt blir lätt tidskrävande. Den enklare varianten av inställningar består av ett bestämt antal steg där varje steg representerar en samling av variabler. När nivån skiftas från ett steg till ett annat förändras alla variabler som steget påverkar. På detta sätt klumpas inställningar ihop så de tillhör en större grupp och när en nivå förändras skiftas alla variabler i gruppen. En enklare inställningsmeny som består av få variabler är enklare för mindre erfarna användare att anpassa men erbjuder inte samma exibilitet. När färre variabler kan ställas in tappar applikationen i förmåga att anpassas på bästa sätt för datorn. En dator med styrka på ett område och svagheter på ett annat måste anpassas till minsta gemensamma nämnaren i en nivågrupp av inställningar och därmed går kapaciteten inom datorns styrkeområden förlorad. Med en mer avancerad inställningsmeny

1.2 Bakgrund 1 INLEDNING nns möjlighet att eektivare anpassa inställningarna efter datorn men svårighetsgraden för användaren ökar. Optimalt bör mängden variabler att ställa in vara proportionellt mot antalet tekniker som applikationen stödjer och att processen för användaren att ställa in variablerna för systemet elimineras.

För att nyttja fördelarna med många inställningsvariabler och enkel användning behövs ett nytt angreppssätt som automatiserar funktionaliteten som kontrollorerar applikations-nivån. Applikationer kan implementera ett dynamiskt anpassande system som abstraherar processen att manuellt anpassa inställningar. Ett dynamiskt adapterande system kan in-tegreras i en applikations iterationscykel och kontinuerligt uppdatera inställningar under exekveringen. Systemet mäter fortlöpande applikationens prestanda och anpassar däref-ter med lämpliga inställningar för datorn. Med ett dynamiskt anpassande system behöver antalet variabler att ställa in inte begränsas på grund av någon simplicitetsfaktor för an-vändaren.

Ett system som dynamiskt anpassas kontinuerligt under körning för med sig ännu en fördel över statiska inställningar. Komplexiteten hos en applikation, speciellt realtidspro-gram med 3D-grak, varierar kraftigt under olika segment av applikationen. Det förekom-mer tillfällen i applikationen då prestandakraven ökas eller sänks på grund av variationer i scenen. Statiska inställningar som användare väljer behöver, för att vara eektiva, utses så de håller en jämn nivå under uktuerande komplexitet av applikationsscenen. Variabler som sätts på en hög nivå kan sköta sig bra under större delen av applikationen men bli en askhals under tyngre delar. Användaren får antingen acceptera visst fall av prestanda under tyngre segment eller välja en lägre nivå över hela exekveringen. Ett adaptivt system kan istället välja ut de tekniker som presterar bäst för tillfället genom hela utförandet av applikationen. Under de mer krävande segmenten kan systemet automatiskt dra ner nivån på de tekniker som påverkas av komplexiteten i scenen. I ett senare skede när applikatio-nens prestandakrav minskar kan det dynamiska systemet återigen öka nivån på teknikerna som används. I det optimala dynamiska anpassande systemet sjunker prestandan för ap-plikationen aldrig under en vald acceptansnivå och systemet använder alltid de tekniker som presterar bäst för tillfället.

1.2 Bakgrund

Autonomic Computing presenterades som ett nytt tankesätt inom mjukvaruutveckling i början av 2000-talet av IBM's Paul Horn[8]. Idén med Autonomic Computing är att auto-matisera funktionalitet som nns i stora mjukvarusystem och bygga ett självständigt un-derliggande lager som utför många av de uppgifter som tidigare krävt manuell interaktion från kunniga människor. Syftet bakom Autonomic Computing var att lösa problem som uppstod med den hastigt ökande komplexiteten det innefattar att underhålla och vidare-utveckla mjukvaruprogram. Inspiration för Autonomic Computing tas från den mänskliga kroppen och dess autonoma nervsystem. Det autonoma nervsystemet i människokroppen hanterar många vitala funktioner för en människas fortlevnad utan medveten påverkan från mänskliga individen. På samma sätt som det autonoma nervsystemet sköter sig själv i ett större system är tanken bakom Autonomic Computing att mjukvaruprogram ska fungera på de lägre nivåerna. Autonomic Computing bygger på att automatisera uppgifter som

1.2 Bakgrund 1 INLEDNING annars utförs manuellt av utbildad personal och användare av systemet. Ett autonomt system är istället självstyrande i de lägre nivåerna och kontrolleras genom högnivå-regler som utvecklare förser.

Kephart m..[?] plockar ut och listar de fyra karaktärsdragen som ett fullständigt au-tonomt system implementerar. Ett auau-tonomt system är själv-kongurerande vilket innebär att systemet kan anpassa sig själv till miljön den existerar i. Detta inkluderar att installera och kongurera nya moduler till det existerande systemet med minimal manuell inverkan samt att anpassa redan installerade komponenter mot förändringar i systemets omgivning. Det autonoma systemet har själv-helande egenskaper både förebyggande och agerande. Systemet kan på komponentnivå detektera problem som uppstår och hantera dessa utan påverkan hos resten av systemet. Helande aktioner som krävs i ett vanligt system tar pro-grammerare en stor del av den arbetande tiden för att identiera och laga. Själv-helande egenskaper gör hela systemet mer stabilt. Autonoma system besitter även verktyg för själv-optimering.Själv-optimering handlar konceptuellt likt själv-konguration om att anpassa sig mot omgivningen men med ändamålet att maximera resurshanteringen hos systemet. Själv-optimeringens uppgift är att hela tiden sträva efter att öka prestandan. Optimeringen innebär också att systemet lär sig från egna erfarenheter för att hantera motsvarande situ-ationer eektivare vid nästa incident. Det fjärde och sista karaktärsdragen man nner hos ett autonomt system är förmågan för själv-beskydd. Den beskyddande egenskapen har att göra med systemets säkerhet. Den hanterar att användare har tillgång till rätt information och skyddar mot utomstående attacker. Systemet kan förutse och förebygga externa så väl som interna attacker och skydda sig korrekt mot dem.

En mer ingående mall för de autonoma komponenterna i ett system introduceras av IBM[7] där design och tankemönster för implementation av autonoma komponenter ges. Ritningen delar upp intelligensen i tre delar med vars ett ansvarsområde. Den övergripande kontrollen sköts av en komponent benämnd som Autonomic Manager. Komponenten ab-straherar och automatiserar någon funktionalitet som i traditionella system kräver manuell interaktion. Autonomic Manager-enheten är det analyserande och beslutande organet för den tilldelade funktionaliteten. Komponenten observerar en del i systemet och avgör om förändring är nödvändig för att bättre tillfredsställa de krav den har. Den andra komponen-ten är Knowledge Source vilken är nära integrerad med Autonomic Manager. Knowledge Source-komponenten fungerar som en log till Autonomic Manager och håller väsentlig in-formation. Logen består av värden för hur komponenten presterar för tillfället men också historia om hur den förändrats under sin livstid och vilka implikationer det fått. Den sista delen är Touchpoint vilken är gränssnittet mot den faktiska funktionaliteten som kompo-nenten ansvarar över. Touchpoint agerar på order från Autonomic Manager och verkställer de förändringar som krävs.

Dynamic Voltage Frequency Scaling, DVFS, är en struktur för tekniker som arbetar med att optimera energiförbrukningen hos batteridrivna maskiner[2].

Filoson bakom DVFS är att prestandan och antalet beräkningar växlar under exekve-ring av ett program. Syftet med DVFS är att förse hårvaran med enbart den energimängd som minst krävs för datorn att hinna de beräkningar som ska utföras. Systemet arbetar ständigt med att förutse hur mycket energi det behöver för att utföra sina uppgifter och mäter därför konstant med en specik metod hur den tror arbetsbördan kommer

föränd-1.3 Syfte 1 INLEDNING ras. DVFS-system är från början främst anpassade för video-dekodning, men Gu m..[4] visade att även spel var lämpade för liknande implementationer. Gu m.. menar att spels belastning för datorn varierar mellan olika segment under exekvering och kan därmed vinna mycket på att energitillgången anpassas löpande. Gu m..[5] byggde vidare inom området med mer avancerade metoder för att beräkna arbetsbördan och den nödvändiga energitill-gången. Även Mochocki m..[15] utvecklade metoder för att mäta komplexiteten hos en scen för att förutspå hur mycket energi hårdvaran behöver för att arbeta. Gemensamt för dessa arbeten är att mätningarna de utför sker på en låg hårdvarunära nivå av datorn. Som exempel modierar Mochocki i sitt arbete ödet i pipelinen för grakkortet genom att implementera ett extra steg efter transformation av objekten där systemet beräknar hur mycket som är synligt.

Tankarna inom DVFS att analysera applikationers prestanda och förändra väsentli-ga parametrar har inspirerat (ingångspunkten) forskningen i detta arbetet. Målet mellan DVFS och optimeringsarbetet som utförs i ett autonomt system skiljer sig åt då DVFS strävar efter att dra ner tillgång medan optimeringen pressar prestandan för maximal ut-vinning. Tillvägagångssättet att analysera systemets prestation och förändra där det nns utrymme är en gemensam punkt.

1.3 Syfte

Detta arbete ämnar undersöka möjligheterna i att använda sig av ett dynamiskt anpassande system i en applikation. Arbetet granskar vilken påverkan olika tekniker har på prestandan hos en applikation och hur prestandan kan förändras genom att dynamiskt variera tekniker för att passa datorn.

Undersökningen innefattar granskning av betydelsen tekniker har för applikationens prestanda. Arbetet undersöker även hur olika datorer av varierande kapacitet påverkas av teknikerna och vilken skillnad ett dynamiskt adaptivt system kan göra för applikationens prestanda. Undersökningen mäter prestandan för datorer vid användande av olika tekniker och analyserar vilken förmåga det dynamiskt anpassande systemet har för att bibehålla en hög prestanda och samtidigt välja lämpliga tekniker för den individuella datorn. Arbetet testar det adaptiva systemets kompetens att sträva efter avancerade tekniker utan att belasta datorn på ett sätt så applikationen prestanda sjunker.

1.4 Frågeställning

• Är det möjligt för ett dynamiskt adaptivt system att påverka prestandan hos en applikation genom att variera vilka tekniker som används?

• På vilket sätt kan olika tekniker påverka prestandan hos en applikation?

1.5 Avgränsning

Syftet med arbetet är undersöka möjligheten till ett dynamiskt anpassade system för appli-kationer inom speldomän. För att undersöka möjligheten till dynamisk anpassning behöver arbetet först visa på skillnad mellan olika parameters påverkan på prestandan.

1.5 Avgränsning 1 INLEDNING Undersökningen kommer använda sig av WebGL och JavaScript. Applikationen tar endast hänsyn att fungera tillsammans med en Chrome-webbläsare. Applikationen som utvecklas för undersökningen implementeras med WebGL och JavaScript vilket begränsar vilka funktioner systemet kan använda för att mäta och reagera på prestandaförändringar. Detta arbete ämnar inte förändra i det naturliga ödet för en grask pipeline eller andra hårdvarunära rutiner, utan alla mätningar utförs på applikationssidan med JavaScript.

Detta arbete granskar inte hur ett dynamiskt anpassande system byggs på eektivast sätt. Arbetets syfte är att undersöka hur tekniker påverkar den övergripande prestandan av applikationen och därmed kommer arbetet inte analysera vilka tekniker som bäst anpassas, och heller inte någon fördjupning i hur systemet detekterar att en teknik bör bytas ut.

Enbart undersökning angående prestandaförändringar och inte andra faktorer, så som batteritid, minnesanvändning eller någon form av optimering för teknikerna kommer beak-tas. Undersökningen granskar enbart hur mätvärdet för prestandan förändras under kör-ning.

2 METOD

2 Metod

Undersökning är en kvantitativ deduktiv mätning där värdet som används för att avgöra prestandan är det FPS-värde programmet har. För att undersöka hur tekniker påverkar programmets prestanda och hur ett dynamiskt anpassande system kan automatisera konti-nuerlig förändring av tekniker utvecklas en applikationen att använda vid tester. Testerna resulterar i kvantitativ data vilken analyseras för att avgöra hur användande av olika tek-niker förändrar FPS-värdet. Den insamlade datan baseras på tester med fast satta tektek-niker och tester där systemet dynamiskt varierar tekniker.

värdet för applikationen är det värde mätningar av prestandan baseras på. FPS-värdet är ett mått på hur många iterationer av programmets uppdateringsloop som datorn hinner utföra under loppet av en sekund. Med FPS-värdet kan tiden för en iteration be-räknas. Ett högt FPS-värde är bättre än lägre, då det innebär att datorn hinner med er iterationer under en sekund och därmed er beräkningar vilket kan resultera i mer avan-cerade tekniker och bättre fysiksimulation. Applikationen för undersökningen använder samma FPS-värde för både uppdatering och rendering av applikationen. Det är inte nöd-vändigt för applikationen att renderas oftare än datorns skärm uppdateras, vilket i många fall är med en hastighet på 60 Hz. All rendering som sker oftare än skärmens uppdaterings-frekvens kommer inte synas och är därför meningslös. Uppdateringslogiken i applikationen kan beräknas så ofta som möjligt för så exakt fysiksimulering och responsivitet som möjligt. Applikationen som används i undersökningen delar inte uppdateringslogik och rendering i separat iterationer utan utför dem efter varandra. Att uppdateringslogiken inte sker i en separat iterationscykel begränsar teknikerna som påverkar processorn, men inte deras logik. Resultatet av att inte separera är att högst nivån sänks, men förhållandet mellan tekniker är oförändrat.

Prestanda för mjukvaruprogram mäts ofta i två resurser, tid och minne. Tid omfattar hur snabbt ett program exekverar, hur många uträkningar det hinner utföra under en given tid. Mätning av minne beaktar hur stor plats applikationen kräver eller tar för sig under körning. Den prestanda som undersökningen mäter är i form av tid. Prestandan baseras på FPS-värdet för applikationen vilket är ett mått på hur snabb applikationen är. Att mäta minnesanvändning hos ett dynamiskt anpassande system är också en del av optimering inom Autonomic Computing, men inte inom omfattningen för denna undersökning. Tek-nikerna som används i applikationen varierar inte minnesanvändningen betydande under körningen och oavsett om de används eller inte laddas alla tekniker in av applikationen. Därför är tidsaspekten den enda som tas hänsyn till i undersökningen och den parameter som det dynamiska systemet baserar sina val på.

2.1 Teknik-metoder

För undersökningen behövs tekniker som systemet kan alterera. Att implementera avance-rade tekniker är svårt och tidskrävande. För undersökningen använder applikationen därför förenklade tekniker som simulerar tyngre. Att använda mer verklighetsförankrade tekni-ker kan möjligt ge en tydligare bild av hur eektivt ett dynamisk anpassande system kan tillverkas, men för undersökningen i arbetet är det inte sakfrågan. En approximation av

2.1 Teknik-metoder 2 METOD avancerade tekniker, som applikationen använder, påverkar samma delar i pipelinen som reella tekniker men ger ingen grask feedback för användare och är därmed inte lämpliga i en produktionsapplikation.

Applikationen har tre typer av tekniker som påverkar olika steg i pipelinen. De tre stegen är uppdateringssekvensen, vertex-shadersteget och fragment-shadersteget. Dessa segment är tre delar av pipelinen som kan påverkas genom att byta ut tekniker som berör dem. Det nns andra potentiella segment i en pipeline, till exempel kommunikation mellan processorn och grakkortet, som också kan påverkas av tekniker, men för arbetets undersökningen är applikationen avgränsad till dessa tre då undersökningen inte ämnar värdera vilka tekniker som främst kan påverkas. Därför är applikationen avgränsad till tre delar som har en klar roll i pipelinen.

De använda teknikerna benämns nedan med en förklaring om dess roll och eekt. 2.1.1 Shader-teknik

Shader-teknikerna är den parameter i systemet som bestämmer vilket shader-program applikationen använder för att renderas. Shader-programmen mellan olika shader-tekniker som applikationen använder varierar enbart i arbetsbördan för fragment-shadern. Shader-tekniker påverkar därmed mängden arbete grakkortet utför i fragment-shadersteget av grakkortspipelinen. Fragment-shaders arbetsbörda varierar beroende på de dimensioner buern har till vilken fragment-shadern skriver data. Om applikationen använder höga dimensioner för skärmen det renderas i blir kraven högre på grakkortets möjlighet att hantera fragment-shadersteget. Shader-teknikerna som används av applikationen kommer därmed påverka prestandan beroende på skärmstorleken och kapaciteten hos grakkortet. I moderna grakapplikationer förekommer många av de mest avancerade uträkningarna för den slutgiltiga bilden på skärmens i fragment-shadern. Shader-teknikerna som används i undersökningen ger ingen grask variation mellan de olika nivåerna. Shader-teknikerna simulerar avancerade och därmed uträkningskrävande tekniker genom att utföra tomma uträkningar. Anledningen är att fördröja exekveringen och öka prestandakraven för appli-kationen. De olika nivåerna av shader-tekniker varierar fördröjningen i fragment-shadern. 2.1.2 Boll-teknik

Teknikerna som berör uppdateringscykeln på JavaScript-delen av applikationen är boll-teknikerna. Teknikernas belastning påverkar processorn hos datorn genom att öka antalet beräkningar under uppdateringssekvensen på applikationssidan. Boll-teknikerna kontrolle-rar mängden fysiska objekt som får existera i applikationen samtidigt och på så sätt berörs tiden det tar för fysikmotorn att simulera en iteration.

Boll-teknikerna påverkar även grakkortet eftersom de fysiska objekten i applikationen även är graska och därmed renderas. Högre nivåer av boll-tekniken tillåter er fysiska ob-jekt och er instanser av obob-jekten skickas från applikationen till grakkortet för utritning. Påverkan av boll-teknikerna på grakkortets arbetsbörda är dock försumbar i förhållande till de andra teknikerna som främst påverkar graska komponenter.

2.1 Teknik-metoder 2 METOD 2.1.3 Level of Detail-teknik

Level of Detail är en teknik som ofta används i moderna applikationer i olika syften. Level of Detail innebär att den graska modellen som representerar objekt byts mellan modeller med växlande grader av detaljrikedom och polygonantal. Modellerna alterneras i vanligt bruk antingen beroende på vilken inställningsnivå som är inställd eller beroende på objektets avstånd till kameran i scenen.

Level of Detail-teknikerna i undersökningen, framöver benämnd som LoD-tekniker, in-verkar på grakkortets belastning. LoD-teknikerna modierar inte shader-programmet eller ödet på grakkortet utan mängden data som grakkortet bearbetar. LoD-teknikerna be-stämmer vilken detaljrikedom de graska objekten ritas ut med, där högre detaljrikedom innebär er vertex-punkter som shader-programmet behöver hantera. LoD-teknikerna är verkande i en annan del va den graska pipelinen gentemot shader-teknikerna. Shader-teknikernas belastning är i fragment-shadern och bestäms därmed till stor del av dimen-sionerna på buerten den skriver till medan LoD-tekniken skiftar arbetsbördan för vertex-shadern vars påfrestning beror av antal objekt i scenen och deras polygonantal.

3 IMPLEMENTATION

3 Implementation

3.1 Applikation

3.1.1 Applikationens syfte

För undersökningen utvecklas en applikation som används för testning av forskningsfrå-gan. Syftet med applikationen är att mäta hur dess prestanda förändras när tekniker i applikationen växlas. Applikationen behöver därför byggas upp med ett system där tekni-ker kan skiftas utan att resterande logik i applikationen påverkas. Applikationen ska även implementera ett dynamiskt adaptivt system för teknikerna. Applikationen består av en underliggande struktur som kontinuerligt mäter prestandan och anpassar applikationens konguration.

Den dynamiskt adaptiva komponenten i applikationen har under exekvering ett mål den konstant strävar efter. Ett dynamiskt anpassande optimeringssystem nöjer sig aldrig med de inställningar det har och stadgar sig utan arbetar hela tiden att förbättras. Det adaptiva systemet i undersökningen strävar att använda mer avancerade tekniker i alla led som är möjliga. Systemet måste dock rätta sig efter uppsatta regler och samtidigt hålla en balanserad prestanda.

Applikationen innehåller de grundläggande elementen i ett spel för att ge testerna ett samband till en verklig spelapplikation.

3.1.2 Design

Designen av applikationen är baserad på den mall som IBM[7] presenterar. IBM ger ett generellt designmönster för att bygga autonoma datorsystem, vilka generellt sätt är större och mer komplicerade applikationen som utvecklas för undersökningen. Applikationen im-plementerar de mest grundläggande delar som IBM presenterar. Undersökningen fokuserar på den del som innefattar själv-optimering[?] och tillämpar ingen av resterande delar.

Maggio m.[14] ger två exempel på hur autonoma systems konceptuella kontroll kan byggas upp; Monitor, Analyze, Plan and Execute (MAPE) och Observe, Decide, Act (ODA). Den förstnämnda av de två, MAPE, är inriktat på att systemet kan förutse föränd-ringar och agera innan problem uppstår, medan ODA-modellen observerar hur systemet presterar och agerar därefter. Applikationen realiserar ODA-modellen då den passar sig bäst för systemet. I applikationer där användaren har kontroll över ödet har systemet inte samma möjlighet att förutse vad som kommer ske. Att observera hur programmet presterar och har presterat den närmsta tiden bakåt, ta beslut om värdena är tillfredsstäl-lande eller inte och därefter agera, lämpar sig då förutsägbarhet saknas i programmet.

Applikationen bygger upp en 3D-värld för användare att interagera med. I 3D-världen styrs objekt av simulerade fysiska lagar likt moderna spelapplikationer. Världen, som an-vändaren existerar och rör sig i, är begränsad av fyra väggar längs med sidorna. Anan-vändaren styr en karaktär i världen, visualiserad i form av en kub, som kan röra sig i alla tre axlar med användarens input. I världen nns statiska fysiska objekt som kuben kan kollidera och interagera med. Användaren kan avfyra bollar från kubens position i den riktning som ka-meran siktar mot. Bollarna är fysiska objekt och kolliderar med alla andra objekt i världen,

3.2 API 3 IMPLEMENTATION

Figur 1: Överblick över världen i applikationen. inklusive användarens kub.

I världen nns även ett område med icke-fysiska objekt utan enbart graska modeller. Modellerna föreställer kaniner och kan varieras att renderas med växlande detaljrikedom. Då kanin-modellerna inte är några fysiska objekt påverkar de inte arbetsbördan för fysik-motorn. Deras syfte är att öka den graska komplexiteten i scenen och har en stor eekt på prestandan vid skiftande av detaljrikedom.

3.2 API

3.2.1 WebGL

Applikationen använder sig av WebGL[11] för all renderingslogik. WebGL är ett standar-diserat JavaScript-API för hårdvaruaccelerad grak direkt i webbläsaren, utan användning av insticksprogram. WebGL är baserat på OpenGL ES 2.0[13], en variant av OpenGL[12] specikt utvecklat för inbyggda system. OpenGL ES, och därmed WebGL, innehåller en delmängd av OpenGL med vissa plattformsspecika tillägg. WebGL är aningen mer kom-plicerat än de esta andra webbteknologier därför det är designat att arbeta direkt mot grakkortet. Som en konsekvens är gränssnittet nära lågnivåspråk, vilket möjliggör snabba uträkningar för komplexa 3D-scener.

För att en applikation ska kunna använda sig av WebGL behöver den hämta ett WebGL-kontext. Kontexten hämtas ut en canvas, ett HTML5-element, i vilken WebGL även kommer rendera all grak. Det faktum att WebGL renderas i canvasen innebär direkt integration i HTML-dokumentet, DOM-objektet, för canvasen. WebGL blir alltså en del av HTML-sidan och hanteras precis som andra noder i dokumentet.

3.2 API 3 IMPLEMENTATION 1 var canvas = document . getElementById ('canvas ') ;

2 var g l = canvas . getContext ('webgl ') ; 3

4 // ...

5

6 g l . c l e a r ( g l .COLOR_BUFFER_BIT | g l .COLOR_DEPTH_BIT) ; 7 g l . bindBuffer ( g l .ARRAY_BUFFER, v e r t e x B u f f e r ) ;

8 g l . v e r t e x A t t r i b P o i n t e r ( vertexPointer , 3 , g l .FLOAT, false, 0 , 0) ; 9

10 g l . drawArrays ( g l .TRIANGLE_STRIP, startVertex , vertexCount ) ;

Figur 2: Programmet hämtar WebGL-kontext från ett canvas-element. Den nedre delen av koden visar hur WebGL kan användas för att rendera ett objekt, förutsatt att variabler är initierade och har korrekta värden. Exemplet visar WebGL:s lågnivå-natur.

Applikationssidan använder JavaScript för all WebGL-interaktion, men på grakkor-tet kör WebGL små program som kallas shaders. Shader-programmen behandlar geome-trin som applikationen sänder till grakkortet och bestämmer hur de ska visas i WebGL-fönstret. Shader-programmen är helt bestämmande i vilken position alla vertex-punkter har samt vilken färg pixlarna får som vertex-punkternas trianglar täcker. Shader-programmen har total slutgiltig makt över applikationens graska presentation och därför är det ut-vecklares ansvar att förse WebGL med de shader-program som ska användas. En kom-plett WebGL-applikation innehåller alltid minst ett shader-program, annars kan WebGL inte rendera någonting. Ett shader-program består i sin tur av en vertex-shader och en fragment-shader som båda utför en specik uppgift.

Vertex-shadern är det program på grakkortet som bestämmer den geometriska formen och position för alla objekt. Vertex-shadern arbetar med de vertex-punkter som förses av applikationen. Resultatet från en korrekt vertex-shader är alltid minst den position en vertex-punkt har i förhållande till skärmens koordinatsystem, men har också möjlighet att returnera mer data som sedan kan användas i fragment-shadern. Till vertex-shadern förser JavaScript-sidan representationsmatriser att använda under beräkningarna.

Efter vertex-shadersteget utför grakkortet en del beräkningssteg som applikationsut-vecklare inte har någon möjlighet att modiera. Det huvudsakliga arbetet som utförs är rasteriseringsdelen där grakkortet beräknar hur de bearbetade vertex-punkterna triangu-leras och vilket utrymme, om något, de täcker på skärmen. Rasteriseringen räknar ut vilka pixlar trianglarna ska färga och anropar fragment-shadern för dem.

shadern körs för varje pixel av fönstret som täcks av en triangel. Fragment-shaderns uppgift är att färglägga varje pixel den anropas för. Resultatet från en fragment-shader är därför den färg som beräknats och ingenting mer. Eftersom fragment-fragment-shadern ar-betar på per-pixel basis och shadern med punkter måste värdena som vertex-shadern returnerar till fragment-vertex-shadern interpoleras över triangeln med värdena från de andra vertex-punkterna. I moderna applikationer används fragment-shadern bland annat för att beräkna ljussättning av objektet beroende på ljuskällorna i scenen. Ljusberäkning-arna kan variera i komplexitet och exekveringstid det tar att utföra.

ap-3.2 API 3 IMPLEMENTATION 1 // VERTEX 2 a t t r i b u t e vec4 a_position ; 3 a t t r i b u t e vec2 a_texcoord ; 4 a t t r i b u t e vec3 a_normal ; 5

6 uniform mat4 u_wvp ; 7 uniform mat4 u_world ; 8

9 varying vec2 v_texcoord ; 10 varying vec3 v_normal ; 11

12 void main ( ) {

13 gl_Position = u_wvp ∗ a_position ; 14 v_texcoord = a_texcoord ;

15 v_normal = u_world ∗ vec4 ( a_normal , 0 . 0 ) ; 16 }

17

18 //

---19

20 // FRAGMENT

21 uniform sampler2D u_texture ; 22 uniform vec3 g _ l i g h t D i r e c t i o n ; 23 uniform vec4 g _ d i f f u s e L i g h t ; 24

25 varying vec2 v_texcoord ; 26 varying vec3 v_normal ; 27

28 void main ( ) {

29 vec4 sampled = texture2D ( u_texture , v_texcoord ) ;

30 f l o a t l i g h t = s a t u r a t e ( dot(− g _lig htD i re ct io n , normalize ( v_normal ) ) ) ; 31 gl_FragColor = sampled ∗ l i g h t ∗ g _ d i f f u s e L i g h t ;

32 }

Figur 3: Ett enkelt shader-program med både vertex- och fragment-shader. Vertex-shadern räknar ut positionen och normalen med de matriser som applikationssidan försett. Fragment-shadern samplar färgen från texturen ljussätter med en simpel dius ljusfaktor. Ljusets riktning och färg förses av applikationssidan vid varje iterationscykel.

3.3 Bibliotek 3 IMPLEMENTATION 1 var world = new CANNON. World ( ) ;

2

3 var sphere = new CANNON. RigidBody ( 4 /* mass */ 5 . 0 ,

5 /* shape */ new Cannon . Sphere (/* radius */ 2) ) ; 6

7 world . add ( sphere ) ; 8

9 (function loop ( time ) { 10 world . step ( time ) ; 11

12 // Render scene

13

14 window . requestAnimationFrame ( loop ) ; 15 }) ( ) ;

Figur 4: Enkelt exempel på användande av cannon.js

plikationen har och är bidragande faktor till applikationens identitet. En applikation kan använda sig av era shader-program för rendering, antingen inom en iterationscykel el-ler mellan olika iterationer. För undersökningen varierar applikationen shader-program för att skifta komplexitet och exekveringstid. Applikationen behöver inte förändra logiködet i programmet för att byta shader-program. Då shader-programmen enbart påverkar den graska presentationen förblir logiken oförändrad.

3.3 Bibliotek

3.3.1 Cannon

Cannon.js[6] är ett bibliotek som används för att simulera fysik i JavaScript-applikationer. Till skillnad från många av de tillgängliga fysikbiblioteken för JavaScript, vilka är portade från ett annat språk med hjälp av verktyg, är Cannon helt utvecklad i JavaScript. Can-nons interna struktur och användande är designat för JavaScript och därmed optimerad för språket. För att vara ett fysikbibliotek är Cannon lättviktigt, funktionsmässigt. Cannon stödjer de mest vitala funktionerna för ett fysikbibliotek men inte mer avancerade tekni-ker, så som ragdolls. Cannons funktionalitet är tillräcklig undersökningen i arbetet. För mätningarnas skull används fysik då det återspeglar en reell applikations behov.

Cannon är enkelt och snabbt att använda under utvecklingen. Grunden för all fysik är ett World-objekt. Till den sätts inställningar så som gravitationsstyrka och riktning. Alla fysiska objekt i applikationen läggs till i world-objektet. För varje iteration av spelloopen anropas world-objektets stepmetod. Cannon simulerar då all fysik och kollisioner i värl-den. När applikationen ska rendera tillstånden i världen hämtar den position, rotation och skalningsdata för varje objekt.

Koden i Figure 4 är ett exempel på hur man kan skapa en värld med Cannon. I världen läggs det till en rigidbody som har formen av en sfär. Alla fysiska objekt i Cannon är av typen rigidbody. En rigidbody håller information om objektet så som tillstånd och rörelse.

3.3 Bibliotek 3 IMPLEMENTATION 1 var GameObject = k l a s s (function( ) {

2 this. a c t i v e = true; 3 }) . methods ({

4 update : function( ) {} 5 }) ;

6

7 var DrawableGameObject = GameObject . extend (function( ) { 8 this. v i s i b l e = true;

9 }) . methods ({

10 draw : function( ) {} 11 }) ;

12

13 var myobj = new DrawableGameObject ( ) ; 14 myobj . update ( ) ;

Figur 5: Exempel på användande av klass.js. DrawableGameObject ärver i det här fallet från GameObject och får då alla medlemmar från GameObject

3.3.2 Klass

Språket JavaScript erbjuder i många fall era metoder för att lösa ett problem vilket kan leda till sämre kvalitet på koden. JavaScript har inget standardiserat system för objekt-orienterad kodstruktur, utan erbjuder olika tillvägagångssätt för utvecklaren. Klass[3] är ett JavaScript-bibliotek som underlättar objektorienterad utveckling. Klass abstraherar arvsfunktionaliteten och ger ett enklare gränssnitt för att utveckla med arvshierarkier.

Exemplet i gur 5 skapar en simpel arvshierarki där DrawableGameObject ärver från GameObject. DrawableGameObject får då tillgång till medlemsvariabler och metoder från GameObject. Exemplet visar hur superklassen initieras med hjälp av klass-objektet. Där-efter har alla objekt i arvskedjan tillgång till hjälpfunktionerna från klass, som till exempel extend.

3.3.3 GlMatrix

Vid arbetande med en 3D-scen krävs mycket geometri och matematiska uträkningar för att beskriva hur scenen ser ut. Många av uträkningarna involverar matris- och vektorope-rationer som behöver vara snabba och eektiva. Varken WebGL eller webbläsare erbjuder stöd för matriser och vektorer i det inbyggda Matematikbiblioteket, därför måste utveck-lare förse applikationen med det. Applikationen som utvecklas använder GlMatrix[9], ett bibliotek specikt utvecklat för syftet att användas till WebGL-applikationer. GlMatrix är helt utvecklat och optimerat för JavaScript. GlMatrix är inte det snabbaste[17] matrisbib-liotek tillgängligt enligt mätningar men är tillräckligt för applikationen. Då alla tekniker använder sig av samma bibliotek nns ingen påverkar av biblioteket på mätningarna mellan teknikerna.

3.4 Mätningar 3 IMPLEMENTATION 1 var p o s i t i o n = vec3 . fromValues ( cannon . rigidbody . pos ) ;

2 var r o t a t i o n = quat . fromValues ( cannon . rigidbo dy . quaternion ) ; 3

4 var world = mat4 . c r e a t e ( ) ;

5 mat4 . fromRotationTranslation ( world , r o t a t i o n , p o s i t i o n ) ; 6 mat4 . s c a l e ( world , world , cannon . rigidbody . s c a l e ) ;

7

8 // Draw object using world -matrix

Figur 6: Exemplet visar en förenkling av hur man kan använda GlMatrix tillsammans med Cannon. I exemplet hämtas data från Cannon-objekt och skapar världsmatris som representerar objektets position, rotation och skalning.

3.4 Mätningar

Mätningar i applikationen tjänar två syften. Mätning av programmets prestanda är datan som används för undersökningens analys och underlag för det dynamiskt adaptiva systemet. Mätningar utförs kontinuerligt av applikationen som en integrerad del av iterationscykeln. Mätvärdet som används är tiden det tar att utföra olika segment under en iteration. Appli-kationen samplar tiden vid viktiga milstolpar under uppdateringsloopen för att fastställa mätvärdena. För att ta reda på nuvarande tiden i JavaScipt används funktionen perfor-mance.now[16]. Funktionen returnerar ett högupplöst tidsvärde på antal millisekunder det gått sedan applikationen startade.

Det första som sker i början av en iteration är att applikationen beräknar värden från föregående iterationen. Applikationen beräknar två varianter av FPS-värde. Det ena värdet är en uppskattning av FPS baserad på den kompletta tiden föregående iteration tog. Med tiden t kan en approximation av FPS-värdet beräknas med formeln:

F P S = 1 t

Detta uppskattade FPS-värde som beräknas för varje iteration kan ge hoppiga resultat som inte överensstämmer med det antal iterationer som faktiskt hinns med under en sekund. Detta beror på att komplexiteten i scenen som uppdateras varierar och även andelen re-surser operativsystemet fördelar till applikationen. Det andra värdet som beräknas är det faktiska FPS-värdet, alltså antal iterationer applikationen utförde den senaste hela sekun-den. Nackdelen med detta värde är att det uppdateras endast en gång per sekund vilket inte är tillräckligt responsivt för det dynamiskt anpassande systemet. Komponenterna i den adaptiva strukturen av applikationen använder sig av FPS-approximationen men med en viss tröskel för förändring och medelvärdesberäkning.

3.4.1 Mätvariabler

Mätningarna i applikationen bygger på tre mätvariabler som alla representerar ett segment av logik i applikationen, Update, Draw och Wait. Dessa variabler är sammanslagna värdet för FPS-approximationen över en iteration. Variablerna utgör grundvärden för de enskilda delarna i det dynamiskt adaptiva systemet.

3.4 Mätningar 3 IMPLEMENTATION

Figur 7: Flödet för en iteration i applikationen. 3.4.2 Update

Före en iteration av uppdateringslogiken påbörjas samplar applikationen datorsystemets högupplösta tid med performance.now. Tiden samplas återigen efter all uppdateringslogik utförts och den förutna tiden beräknas genom skillnaden av de två tiderna.

elapsed = secondsample − f irstsample

Formeln för beräkning av föruten tid är samma för alla tre mätvariabler.

Det arbete som utförs under spannet av update-tiden är främst användarinput och fy-sikberäkningar. Update-variabelns värde påverkas främst av att fysikmotorns arbetsbörda blir tyngre.

3.4.3 Draw

Draw-tiden är ett mått på den förutna tiden då applikationen gör matrisoperationer och anropar WebGL för rendering. Draw-tiden beräknas direkt efter uppdateringslogiken är klar och efter att det sista anropet gjorts till WebGL. Draw-tiden är det värde som varierar minst i applikationen och är sällan askhalsen. Draw-värdet påverkas av mängden synliga objekt som nns i scenen och därmed måste skickas till grakkortet för att renderas.

3.4 Mätningar 3 IMPLEMENTATION

Figur 8: Strukturen för mätningen. Controller har en array med Technique-group, vilka i sig har en array med Technique-instance. En Technique-instance måste alltid vara aktiv inom en Technique-group.

3.4.4 Wait

Wait-variabeln mäter den tid det tar för grakkortet att utföra all rendering som applika-tionssidan begärt. Wait-tiden mäts efter det sista draw-anropet av applikationen och till dess att applikationen är redo för en ny iteration. Tiden däremellan arbetar grakkortet med att rita ut scenen. En ny iteration av applikationen påbörjas inte förrän grakkortet är klar med förra, vilket gör wait-variabeln till en bra mätning för grakkortets arbetsbör-da. Wait-variabeln påverkas av de tekniker som har hand om eekter på grakkortet och antalet vertex-punkter som skickas från applikationssidan.

3.4.5 Dynamisk adaptiv logik

Den dynamiskt anpassande strukturen har i uppgift att balansera en acceptabel prestanda för applikationen samtidigt som den försöker öka nivån på de tekniker som används. Sy-stemet nöjer sig aldrig med nuvarande konguration utan försöker hela tiden avancera i nivå. Systemet är uppbyggt av tre komponenter vilka är Controller, Technique-group och Technique-instance. Dessa komponenter implementerar gemensamt den mall som beskrivs av IBM[7].

Controller är den enda av komponenterna som det bara nns en instans av. Control-ler har den högsta makten i det adaptiva systemet och är den som anropar resterande delar. Controller har ett antal instanser av Technique-group i en array. Controller har tre framstående uppgifter i systemet vilka är att beräkna värden för mätvariablerna vid varje uppdatering, anropa de underliggande komponenterna och se till att det allmänna FPS-värdet inte sjunker under acceptabel nivå.

3.4 Mätningar 3 IMPLEMENTATION de aktiva teknikerna presterar. Technique-group håller en array av Technique-instance där en av instanserna i arrayen alltid är markerad som aktiv. Den aktiva instansen kontrollerar vilken teknik applikationen använder och är den som uppdaterar sina prestandavärden. En Technique-group anropar sin aktiva Technique-instance under varje iteration och evaluerar även dess prestation. Technique-group är ansvarig för att byta aktiv Technique-instance om värdena antyder det.

Technique-instance är den yttersta komponenten i det adaptiva systemet och är den del som beräknar sina egna prestationsvärden och är gränssnittet ut mot tekniken den håller koll på. När en Technique-instance är aktiv uppdaterar den sina egna värden baserat på de värden som Controller beräknat från förra iterationen. Technique-instance är grundklassen för alla varianter av tekniker som applikationen implementerar. De specika teknikerna som används har vars en Technique-instancetyp representerad, med rutiner för att variera just den typen av teknik.

Technique-group samlar alla objekt av samma Technique-instancetyp. På så sätt har varje Technique-group ansvar för endast en typ av teknik och alla nivåer av den tek-niktypen. Technique-group har en eller era fokusvariabler baserat på vilken del av pro-gramödet som tekniktypen påverkar prestandamässigt. Fokusvariabeln är den mätva-riabel en Technique-group baserar evaluering av den aktiva Technique-instancen. Alla Technique-instancer i samma Technique-group evalueras på samma villkor men varierar mellan Technique-groupinstanser. Technique-group har värde för acceptanstid, acceptans-nivå och toleransacceptans-nivå som den använder för att bedöma den Technique-instance som är aktiv. Acceptanstiden är så lång tid Technique-instancen får vara aktiv utan att den kon-trollerande Technique-groupen byter ut den, oavsett hur dess mätvärden presterar. Detta är för att när en teknik byts ut mot en ny kan det ta viss tid innan applikationen stabi-liseras och eekten från den gamla tekniken inte spelar in längre. Acceptansnivån är det värde den aktiva Technique-instancen måste nå över för att den ska anses accepterad och ansvarig Technique-group byter upp den mot nästa nivå av samma Technique-instancetyp. Toleransnivån är motsatt värde som den aktiva Technique-instancen inte får sjunka under för att fortfarande vara aktiv.

Metoden som används för att hantera förändringar är främst baserad på den heuristiska lösningen konceptuellt presenterad av Maggio m.[14] och använd av Chase m..[1]. Meto-den är en enkel lösning för att reagera på systemets nuvarande tillstånd under en iteration. Denna heuristiska metod kan ge uktuerande resultat och kräver att tröskelvärdet för att göra en förändring i systemet inte är för generöst satt. Gu m.[5] utvecklar en metod som tar historien i beaktande före systemet gör en förändring, vilket planar ut uktuationen och ger ett jämnare resultat. Det dynamiskt adaptiva systemet i undersökningen använder sig av ett snarlikt kontrollschema anpassat till miljön i vilken applikationen verkar. Före systemet gör en förändring, analyserar det nästkommande tekniks tidigare prestation om tekniken i ett annat skede varit aktiv. Beslutet om att avancera till en mer avancerad teknik baseras på den nuvarande teknikens prestanda och nästkommande teknikens historia.

När en Technique-group utvärderar sin aktiva Technique-instance jämför den värdet som Technique-instancen har för den fokusvariabel Technique-groupen bedömer med ac-ceptansnivån. Om prestationsvärdet inte överskrider acceptansnivån jämförs det mot to-leransnivån. Om den aktiva instansens prestationsvärde benner sig mellan acceptansnivå

3.4 Mätningar 3 IMPLEMENTATION

Figur 9: Det logiska ödet för en teknik.

och toleransnivå märks den som ok i systemet till dess att nya mätningar ger annorlunda värden.

När en Technique-instance uppdaterar använder den sig av det uppskattade FPS-värdet som Controller beräknat. Trots att resultatet från uppskattningen kan variera kraftigt ger det ändå ett fullgott resultat då Technique-instancen använder sig av ett medelvärde baserat på alla uppskattningar under sin aktiva tid. Technique-instancen uppdaterar även ett medelvärde baserat på de tjugo senaste uppskattningarna för att hålla koll på hur den presterat den närmsta tiden och inte enbart över sin totala tid.

Utöver den kontinuerliga evalueringen sker en översikt av Controller varje sekund när ett nytt faktiskt FPS-värde nns tillgängligt. Controller tar beslut om det nya FPS-värdet ligger inom accepterad nivå för hela applikationen eller om det kan behövas en föränd-ring. Om FPS-värdet visar sig ligga under den accepterade nivån anropas alla objekt i arrayen med Technique-group för att utvärdera sina aktiva Technique-instancer. De aktiva instanserna evalueras under denna process med hårdare nivåvärden än under den vanliga evalueringssekvensen. Den första gruppen som anser att sin aktiva instans är på gränsen och växlar ner returnerar detta som resultat till Controller, vilken i sin tur nöjer sig och utelämnar bedömning av resterande grupper. Prioriteringen av vilken grupp som i första hand ska skifta ner beror därmed på vilken ordning de har i arrayen hos Controller. Grup-per med ett lägre indexvärde kommer oftare reagera på globalt påtvingade förändringar. Om ingen av grupperna självmant växlar ner sin aktiva Technique-instance väljer Control-ler ut den Technique-group med högst värde på sin fokusvariabel och tvingar den att skifta ner.

Acceptabel nivå för applikationens FPS-värde är i omfånget 45 < F P S < 60. Appli-kationen är byggd för att maximalt uppdateras 60 gånger på sekund och blir därmed den högsta möjliga FPS applikationen kan nå. 45 FPS är vald som gräns i undersökningen för att det dynamiskt adaptiva systemet ska ha nivåer att arbeta efter. Det adaptiva

syste-3.4 Mätningar 3 IMPLEMENTATION mets resultat är inte tillfredsställande då FPS-värdet är 60 och det nns mer avancerade att välja. Ett lyckat FPS-värde bör därför ligga på en lagom nivå mellan 45 och 60 FPS. 3.4.6 Implementation av tekniker

Applikationen innehåller tre kategorier av tekniker som det dynamiskt adaptiva systemet kan variera.

Shader-teknikerna varierar komplexiteten för fragment-shadern i applikationen. De förs-ta tre nivåerna av Shader-teknik är tekniker som påverkar den visuella presenförs-tationen. Första tekniken som heter Lightning ljussätter scenen med algoritmer för ambient, dius och spekulär ljussättning. Den andra tekniken, Normal, använder samma ljussättningsmo-dell men adderar en extra textur till fragment-shadern som innehåller data om objektets yta som används vid ljussättningen. Parallax-tekniken bygger vidare från andra tekniken men ännu en textur som innehåller data om höjdskillnader på objektets yta.

Shader-teknik (1-3) Nivå 1 Nivå 2 Nivå 3 Lightning Normal Parallax

De övriga fem varianterna av Shader-teknik påverkar inte den graska presentatio-nen utan simulerar mer avancerade tekniker genom att fördröja exekveringen. Fragment-shadern för teknikerna ljussätter scenen multipla gånger. Antal iterationer som fragment-shadern utför är detsamma som tekniken har i sitt namn.

Shader-teknik (4-8)

Nivå 4 Nivå 5 Nivå 6 Nivå 7 Nivå 8 Delay 50 Delay 100 Delay 500 Delay 1000 Delay 5000

Teknikkategorin som inuerar processorns arbetsbörda är Boll-teknik. Tekniken be-stämmer hur många fysiska dynamiska objekt som får existera i applikationsvärlden samti-digt. Applikationen hanterar de fysiska objekten med en kö som data-struktur. När ett nytt objekt tillkommer och antal objekt redan är på den maximala gränsen tas det objekt som existerat längst bort från världen. Nivåerna som nns av Boll-teknik bestämmer antalet aktiva simultana objekt.

Boll-teknik

Nivå 1 Nivå 2 Nivå 3 Nivå 4 Nivå 5 Nivå 6 Nivå 7 Nivå 8 Nivå 9 Nivå 10

10 20 40 50 75 100 150 200 300 500

Den sista teknikgruppen är LoD-teknik som kontroller vilken detaljnivå objekt renderas med. Alla objekt i scenen som inte har rätblocks-form, består av minst tre modeller med varierande detalj. Högsta detaljnivån implementeras av bollarna vilka har 6 nivåer. Objekt som renderas använder sig av den minsta detaljnivån mellan modellens egna maxnivå och systemets inställda detaljnivå. Antalet polygoner som skiftar mellan de olika detaljnivåerna varierar mellan olika modeller och objekt.

3.5 Tester 3 IMPLEMENTATION

Figur 10: Högt detaljerade kaniner i scenen för att öka polygonantalet och större påverkan av LoD-tekniker. Kaninerna är inga fysiska objekt och ingen kollision med dem förekommer.

3.5 Tester

3.5.1 Syfte med testerna

Testerna utförs för att ge underlag att diskutera frågeställningen. Testerna ska visa vilken eekt tekniker av skiftande komplexitet har på applikationens prestanda. De ska visa hur tekniker kan påverka prestandan mellan olika datorer. Testerna ska även pröva hur det dynamiskt adaptiva systemet kan automatiskt välja de mer avancerade teknikerna för da-torer som kan hantera dem och samtidigt behålla prestandan acceptabel. Testernas resultat ska granska om tekniker som påverkar olika delar av applikationens prestanda bör mätas separat.

För ett lyckat resultat från testerna ska det nns skillnader mellan tester och resul-terande prestanda. Ett tillfredsställande testresultat ska också visa att teknikanvändande påverkar datorerna olika. Testresultaten för det adaptiva systemet bör resultera i ett FPS-värde mellan den acceptabla nivån för alla datorer. Det adaptiva systemets tester bör också visa på skillnad mellan vilka tekniker som används för olika datorer.

3.5.2 Design av test

Testfallen som används i undersökningen är automatiserade. Karaktären i applikationsvärl-den som normalt styrs av användaren har i testfallen att förkongurerat rörelsemönster och kan inte påverkas utifrån. Mönstret som karaktären rör sig efter är att den på ett simpelt sätt roterar runt sin position så den under testfallet får en överblick över hela scenen. Det

3.5 Tester 3 IMPLEMENTATION är viktigt för undersökningen att hela scenen är delaktig och påverkar testresultatet då scenens komplexitet varierar per område. Samtidigt som karaktären roterar avfyrar den upprepande bollar i sin riktning. Bollarna är den främsta prestandafaktorn för uppdate-ringslogiken och har en viktigt del i testresultatet.

Det redovisade testresultatet baseras på FPS-värdet som applikationen har under kör-ning av ett testfall. Ett medelvärde av FPS-värdet från hela testfallskörkör-ningen används för att ta hela testet i beaktande.

Alla givna testfall körs automatisk löpande efter varandra. Varje testfall körs under en minut. Under ett givet testfall som inte testar det adaptiva systemets förmåga förändras inga tekniker. Testfallen använder fast satta inställningar för att undersöka vilken skillnad teknikerna gör för applikationens prestanda. Ett testfall påbörjar inte mätningen förrän applikationen är initierad och redo. Det innebär att hela applikationen hämtas av webblä-saren och laddas in först. Applikationen får även exekvera under två extra sekunder för att stabiliseras efter inladdningen. Detta för att varken nätverksuppkopplingen eller datorns inladdningsförmåga ska påverka testresultatet. För varje nytt testfall som körs hämtas he-la sidan på nytt och initieras med nya värden för testfallet. Testerna har därmed ingen påverkan på varandra genom kvarliggande resurser.

När ett testfall avslutats samlar applikationen all data som är relevant för resultatet. Datan skickas synkront till en server med hjälp av AJAX. På serversidan hanteras datan av ett PHP-script som sparar den till l grupperad efter testdatorns ip-adress. Om len sparas korrekt skickar servern ett svar till applikationen som indikerar att nästa test kan utföras. Om det uppstår fel i kommunikationen mellan server och applikationen eller skrivning av data till l misslyckas blir testfallet inte godkänt och måste utföras på nytt.

3.5.3 Testfall

Testerna är uppdelade i fyra kategorier för att testa olika dela av applikationen med olika tekniker. De testfall som är grupperade gemensamt ska alla påverka samma del av appli-kationens prestanda. Vid testning av en tekniktyp förändras inga av de andra teknikerna för att på ett så korrekt sätt som möjligt visa påverkan från de tekniker som testas. 3.5.4 Boll-tekniker

De tre första testfallen ska visa vilken påverkan boll-teknikerna i applikationen har på prestandan. Testfallen skiljer sig åt endast genom vilken boll-teknik de har aktiv. Boll-teknikerna påverkar främst uppdateringslogiken och processorns arbetsbelastning och kan visa vilken skillnad mängden beräkningar under uppdateringen gör för prestandan. Under testfall 13 används samma Shader-teknik och samma LoD-teknik medan Boll-tekniken skiftar mellan testerna. Datorer med snabb processor bör hantera testfallen bättre än datorer med en sämre processor.

Test 1 Test 2 Test 3 Shader Lightning Lightning Lightning

Bollar 10 50 200

3.5 Tester 3 IMPLEMENTATION 3.5.5 Shader-tekniker

Shader-teknikerna varierar arbetsbelastningen för fragment-shadersteget på grakkortet. Testfall 48 varierar vilken Shader-teknik applikationen använder sig av medan Boll-teknik och LoD-teknik förblir samma. Testfallen ska visa vilken kapacitet datorerna har för beräk-ningar i fragment-shadern och vilken skillnad Shader-tekniker av olika nivåer gör. Datorer med kraftigare grakkort förväntas prestera bättre än datorer med sämre grakkort. Även skärmstorleken bör spela in för resultat i testfall 48.

Test 4 Test 5 Test 6 Test 7 Test 8 Shader Lightning Parallax Delay 50 Delay 500 Delay 1000

Bollar 50 50 50 50 50

LoD 3 3 3 3 3

3.5.6 LoD-tekniker

De sista testfallen med fast satta tekniker varierar vilken LoD-teknik som används. Shader-teknik och Boll-Shader-teknik är samma för testfall 911. LoD-Shader-teknikerna skiftar vilken detaljrike-dom objekt renderas med och därmed mängden arbete vertex-shadern utför. LoD-teknikens påverkan bestäms till stor del även av vilken teknik som är aktiv eftersom högre Boll-teknik betyder er objekt att rendera. Boll-Boll-tekniken är satt på en nivå så de esta datorer kan hantera antalet vid lägsta LoD-nivå och bollantalet samtidigt är tillräckligt högt att LoD-teknikerna får en tydlig påverkan. Datorer med kraftigare grakkort förväntas prestera bättre med högre LoD-teknik.

Test 9 Test 10 Test 11 Shader Parallax Parallax Parallax

Bollar 50 50 50

LoD 1 4 6

3.5.7 Dynamiskt adaptiv

Det sista testfallet skiljer sig från resterande testfall då det inte använder fast satta tekniker. Testfallet undersöker istället hur väl det dynamiskt adaptiva systemet fungerar. Testet börjar med alla tekniker inställda på lägsta nivån. Det är sedan det adaptiva systemets mål att avancera tekniknivån till en grad och kvalitet som passar datorn. Testfallets evaluering baseras dels på medelvärdet av FPS likt andra testfall men tar också i beaktande vilka slutgiltiga tekniker systemet valt för datorn. Syftet med testet av det dynamiskt adaptiva systemet är att undersöka hur väl ett adaptivt system kan variera tekniker anpassade för datorn och balansera prestandan på en acceptabel nivå.

3.5.8 Testmiljö

Datorerna som används i testerna är utvalda för att representera ett brett spektrum av prestandakapacitet. Datorerna skiljer sig i vilket syfte de normalt används och vilken hård-varukapacitet de besitter. För testernas simplicitet har miljön testerna körs i begränsats så

3.5 Tester 3 IMPLEMENTATION alla datorer använder snarlik miljö. Operativsystemet som används av samtliga datorer är Windows, med varierande version. Alla testfall har körts i webbläsaren Chrome v26. Val av enhetlig testmiljö ska inte påverka undersökningens teori men är vald av kompatibilitetsskäl för applikationen.

Grakkort Processor RAM Moderkort OS

Dator 1 Intel Q45

Ex-press Chipset Inte Core 2Duo E7500 @ 2.93 Ghz

4 GB Hewlett

Pac-kard 3048h Windows 7 En-terprise Dator 2 NVIDIA

Quadro 600 IntelW3565 Xeon@ 3.2GHz 12 GB Hewlett Pac-kard 0B4Ch Windows XP Dator 3 GeForce GT 520M Intel Core i5- 2430M @ 2.4Ghz 8 GB ASUSTek

P5Q-E WindowsProfessional 7 Dator 4 ATI Radeon

HD 5700 Series IntelE5506 Xeon@ 2.13Ghz

6 GB HP NC326i Windows 7 En-terprise

Dator 5 ATI Radeon

HD 4800 Series Intel Core 2Duo - E8400 @ 3.0Ghz

8 GB ASUSTek

P5Q-E WindowsProfessional 7 Dator 6 AMD Radeon

4 RESULTAT

Figur 11: Datorernas färgkodning i testtabellerna

Figur 12: Resultat för testfall 13.

4 Resultat

I detta kapitel redovisas resultat från respektive dator och testfall. Resultaten från testfallen presenteras i forma av tabeller inom räckvidden 060 FPS. De datorer vars värden skiljer sig främst från resten ges i den löpande texten. Datorernas resultat är presenterade i tabellerna med samma ordning som de är numrerade. Datorernas färgkodning kan ses i Figure 11 tillsammans med deras namn. Samtliga testresultat tillsammans med större tabeller kan ses i appendix B.

4.1 Boll-tekniker

De tre första testerna varierar Boll-teknik, som bestämmer hur många fysiska objekt det får nnas i scenen samtidigt. Boll-teknikerna belastar datorns processor främst. Det första testfallet använder minsta nivån av Boll-teknik som är implementerad i applikationen. Då de andra teknikerna även är på lägsta nivån är Test 1 den lägsta nivån applikationen kan köras på.

Dator 1 presterar sämst i Test 1 och får medelvärdet 53.41 FPS för testet. Resultatet är över accepterad nivå och visar att alla datorer klarar köra applikationen med lägsta inställningarna. I Test 2 presterar återigen Dator 1 sämst resultat med försumlig skillnad från Test 1. Resultatet för Dator 1 i Test 2 är 52.59 FPS en knapp ökning med 1 FPS från Test 1. Test 3 ökar markant nivån av Boll-teknik vilket återspeglas i testresultaten. Datorn med högst resultat är Dator 6 med 55.73 FPS. Dator 1 får sämst resultat med 37.18 FPS tätt följd av Dator 4 på 37.26 FPS.

4.2 Shader-tekniker

Testfall 48 växlar vilken Shader-teknik applikationen använder. Redan i första testet för Shader-tekniker Test 4 har några av datorerna lägre FPS än första testet av Boll-teknik.

4.2 Shader-tekniker 4 RESULTAT

Figur 13: Resultat för testfall 48.

Det beror på den högre nivån av LoD-teknik och Boll-teknik som används av testfall 48. Över alla testfallen för Shader-teknik kan man ändå se påverkan av prestandan mellan testerna.

Test 4 klarar majoriteten av datorerna med en bra nivå. Dator 1 får direkt svårt att hantera testet och slutar med 25.72 FPS. Dator 2 är näst sämst med 50.60 FPS vilket är godtagbart värde och resten av resultaten är i ungefär samma nivå över 57 FPS.

I Test 5 används en försiktigt mer avancerad Shader-teknik vilket påverkar de understa tre datorers resultat. Dator 1 får resultatet 24.29 FPS, Dator 2 47.59 FPS och Dator 3 56.03 FPS. Resterande tre datorer resultat förändras inte och stannar på över 59 FPS.

Resultaten fortsätter sjunka för Dator 13 i Test 6 då en snäppet mer avancerad Shader-teknik används. Resultatet för Dator 1 ungefär halveras med 12.72 FPS. Dator 2 som i Testfall 5 låg drygt över den acceptabla gränsen resulterar 30.46 FPS i Test 6 och hamnar därmed under. Dator 3 sjunker till 45.92 vilket är precis på gränsen för att vara accepterad. Övriga datorer presterar bra resultat i Test 6 med över 59 FPS.

Shader-tekniken som används i Test 7 slår helt ut Dator 13 och börjar även påverka Dator 4 och Dator 5. Dator 1 har 2.08 FPS, Dator 2 4.92 FPS och Dator 3 11.23 FPS, alla testvärden markant sänkta från Test 6. Dator 4 och Dator 5 får något lägre resultatvärden med 53.36 för Dator 4 och 57.91 för Dator 5, men bägge datorerna presterar fortfarande godkänt.

Test 8 är det sista testfallet för Shader-tekniker och använder en teknik som pressar testdatorerna rejält. Datorerna 13 som redan i Test 7 ck dåliga resultat följer samma mönster som tidigare och sänker resultaten. Skillnaden i resultat från Test 7 på den låga nivån som datorerna ligger är försumbar då de redan är långt under godtagbar nivå. Dator 4 och Dator 5 sjunker under den acceptabla nivån med Shader-tekniken i Test 8. Dator 4 resulterar i 32.42 FPS och Dator 5 41.97 FPS. Dator 6 som tidigare inte påverkats får resultatet 54.95 FPS.

4.3 LoD-tekniker 4 RESULTAT

Figur 14: Resultat för testfall 911.

4.3 LoD-tekniker

De sista testerna med statiska tekniker är testfall 911. Testerna varierar vilken LoD-teknik applikationen använder medan Shader-teknik och Boll-teknik är samma. Resultaten från tester med LoD-teknik varierar kraftigare beroende på vilken Boll-teknik som används. För testfall 911 används en Boll-teknik som ska vara enkel att hantera i lägre LoD-nivå och ge eekt för de högre LoD-nivåerna.

Det första testet med LoD-teknik, Test 9, använder lägsta LoD-nivån och är enkelt för datorerna att hantera. Dator 9 har lägst resultat med 49.59 FPS vilket beror på nivåerna av Shader-teknik och Boll-teknik som applikationen använder. Dator 26 har samtliga resultat över 58 FPS för testfallet.

Test 10 använder LoD-nivå 4 vilket visar sig svårt för Dator 1 och Dator 2 att behandla. Dator 1 får resultatet 22.95 FPS och Dator 2 39.39 FPS. Dator 3 sjunker en aning i sitt resultat med 52.74 men klarar testet med godkänd nivå. Dator 46 slutar med resultat över 58 FPS.

Test 11 är det sista testet med statiska tekniker. Resultaten för Dator 1 sjunker till 10.17 FPS och för Dator 2 till 24.06 FPS. Dator 3 som klarade Test 10 med godkänt presterar 33.53 FPS och sjunker under tillräcklig nivå. De kraftigare datorerna 46 klarar även Test 11 med över 58 FPS.

4.4 Dynamiskt adaptivt system

Det slutgiltiga testets resultat kan ses i Figure 15. Testet som utförs är av det dynamiskt adaptiva systemets förmåga att anpassa sig efter datorn. Resultatet som ges från testet är dels vilket FPS-värde datorn har som medelvärde men också vilka teknikerna systemet valt för datorn när testet avslutas.

Resultaten från testet med det dynamiskt adaptiva systemet kan ses i Table 1. Samtliga datorer får ett resultat inom godkänd nivå med 45 < F P S < 60. Resultaten i Table 1 visar också att de kraftigare datorerna använder mer avancerade tekniker för applikationen.

4.4 Dynamiskt adaptivt system 4 RESULTAT

Figur 15: FPS-resultat för det dynamiskt adaptiva systemet.

Tabell 1: Resultat från test av dynamiskt adaptivt system

Dator 1 Dator 2 Dator 3 Dator 4 Dator 5 Dator 6

FPS 48.84 49.03 50.13 57.68 54.25 58.09

Shader-teknik Lightning Delay 500 Lightning Parallax Delay 100 Delay 100

Boll-teknik 100 75 100 150 75 150

5 ANALYS

5 Analys

5.1 Resultat

Testerna utfördes för att undersöka hur tekniker påverkar applikationens prestanda och det dynamiskt adaptiva systemets förmåga att anpassa teknikerna mot datorn.

5.1.1 Boll-teknik

Testfall 13 varierar aktiv Boll-teknik som applikationen använder. Boll-tekniker påverkar arbetsbelastning för processorn genom att öka antalet fysiska objekt som existerar sam-tidigt i applikationen. Testerna utfördes med tre olika nivåer för Boll-teknik som varierar hur stort antal fysiska objekt som existerar samtidigt i applikationsvärlden.

Från testresultaten kan utläsas att Boll-teknikerna har stor påverkan för applikationens prestanda. Samtliga datorer hanterar Test 1 och Test 2 med, för undersökningen, godkänd prestanda. I Test 3 där Boll-teknikens nivå höjs markant sjunker testresultaten för Dator 15 under 45 FPS. Dator 6 påverkas inte lika kraftigt av den höjda nivån för processorns arbetsbörda och hamnar som ensam testdator ovanför den godkända nivån. Resultaten visar tydligt att val av Boll-teknik påverkar applikationens prestanda. Testresultaten för datorerna 15, trots att de inte anses godtagbara för undersökningen, är inte katastrofala och fungerar för lättare applikationers prestandabehov. Resultaten visar ändå att appli-kationens prestanda kan skiftas beroende på vilken teknik som används. Resultatet för Dator 6 visar också det skiljer sig mellan datorerna vilken Boll-teknik de kan hantera. Da-tor 6 har kapacitet att arbeta med mer avancerad Boll-teknik än övriga testdaDa-torer vilket applikationen kan utnyttja.

5.1.2 Shader-teknik

Redan i första testet av Shader-teknik har Dator 1 lågt testresultat. Då Shader-tekniken i Test 4 är den lägsta nivån, som även användes i Test 13, beror det på den ökade nivån av Boll-teknik och LoD-teknik som används i testfall 48. Resultaten för Dator 1 sjunker procentuellt ganska kraftigt för varje testfall med Shader-teknik, något som tyder på låg kapacitet hos grakkortet. Resultaten visar att Dator 1 bör använda lägsta nivån av Shader-teknik för att hålla applikationens prestanda uppe.

Dator 2 som presterar bra i tester med Boll-teknik har svårare när mer avancerade Shader-tekniker används. Resultaten antyder att Dator 2 har relativt övriga datorer högre kapacitet för processorn än grakkortet. Vid jämförelse mellan Dator 2 och Dator 3 visar resultaten att det är lämpligt att separera mätningar mellan olika tekniker. I samtliga test-fall 13 har Dator 2 högre testresultat än Dator 3 när Boll-teknik och därmed processorns belastning varieras. Under testfall 48 där istället Shader-teknik skiftas är rollerna helt omvända och Dator 3 presterar över Dator 2 med klar marginal för alla tester. Resultaten pekar på att Dator 2 har kraftiga processor än Dator 3 medan Dator 3 har större kapacitet för beräkningar på grakkortet.

Resultaten visar också att det är stor skillnad mellan datorernas prestanda, särskilt vid högre nivåer. Datorerna 46 presterar påtagligt bättre än de sämre datorerna.