Teknik och samhälle

Datavetenskap

Examensarbete15 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 hpHuvudområde: DatavetenskapProgram: SpelutvecklingDatum för slutseminarium: 2013-05-30

Handledare: Johan GustavssonAndrabedömare: Jonas Forsberg

Sammanfattning

Utvecklingen av datorer och deras förmåga ökar klyftan mellan datorer och skapar en stormångfald av hårdvarutillgänglighet. Kapaciteten som datorer besitter varierar kraftigt ochdä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ändarenhar tillräcklig kunskap för att förstå inställningarnas e�ekt. 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 arbetegranskar hur ett dynamiskt adaptivt system automatiskt kan anpassa inställningarna förapplikationen medan den kör, utan manuell extern inverkan. Systemet mäter kontinuerligtapplikationen och individuella teknikers prestanda. Baserat på mätresultat anpassar detadaptiva systemet applikationens inställningar. Genom att abstrahera funktionaliteten attjustera applikationen kan datorns kapacitet utnyttjas, utan varken användarens kunskapeller påverkan. Arbetet undersöker hur olika tekniker kan in�uera applikationens prestandaoch 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 andcreate a wide variety of hardware availability. The capacity that computers possess varyconsiderably and thus the ability to handle complex applications. Modern applicationsprovides settings that users can customize for the computer, which requires the user tohave su�cient knowledge to understand the attitude of the e�ect. To select the optimalsettings for your PC is a process that is both di�cult and time consuming. This thesisexamines how a dynamically adaptive system can automatically adjust the settings for theapplication while it is running, without manual external impact. The system continuouslymonitors the application and individual technologies performance. Based on measurementsthe adaptive system can customize applications settings. By abstracting the functionalityto adjust the application the computer's capacity is utlizied, without neither the user'sknowledge or in�uence. The thesis examines how various technologies can in�uence ap-plication performance and conducts tests of a dynamically adaptive system's ability tocustomize the application for execution environment.

Innehåll

1 Inledning 1

1.1 Problemdiskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Avgränsning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Metod 6

2.1 Teknik-metoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.1 Shader-teknik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Boll-teknik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 Level of Detail-teknik . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Implementation 9

3.1 Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.1 Applikationens syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.1 WebGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Bibliotek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.1 Cannon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.2 Klass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3.3 GlMatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4 Mätningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4.1 Mätvariabler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4.2 Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.3 Draw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.4 Wait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4.5 Dynamisk adaptiv logik . . . . . . . . . . . . . . . . . . . . . . . . . 173.4.6 Implementation av tekniker . . . . . . . . . . . . . . . . . . . . . . . 20

3.5 Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5.1 Syfte med testerna . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5.2 Design av test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5.3 Testfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.5.4 Boll-tekniker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.5.5 Shader-tekniker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5.6 LoD-tekniker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5.7 Dynamiskt adaptiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5.8 Testmiljö . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Resultat 25

4.1 Boll-tekniker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Shader-tekniker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 LoD-tekniker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4 Dynamiskt adaptivt system . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Analys 29

5.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.1.1 Boll-teknik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.1.2 Shader-teknik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.1.3 LoD-teknik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.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

B Bilder 37

1 INLEDNING

1 Inledning

1.1 Problemdiskussion

Datorer �nns med en enorm variation av kapacitet och är utvecklade för ett stort omfångav 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 iapplikationens målgrupp. Applikationer som ska vara tillgängliga för en bred massa behöverha en låg tröskel vad gäller krav på datorns potens för att möjliggöra att sämre datorerkan köra applikationen. Ett problem som uppstår med att utveckla applikationer specielltdesignade för den minsta gemensamma nämnaren mellan datorer är att applikationen blirbegränsad i mån av vilken logik och genre applikationen tillåts implementera. Den visuellapresentationen måste även vara tillräckligt enkel för lågpresterande hårdvara att hantera.Applikationens gra�ska presentation kan inte utnyttja moderna avancerade tekniker ochinte heller använda högt detaljerade objekt med stort antal polygoner. Applikationensprestandakrav 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 kapacitetoch implementera moderna krävande tekniker för de som uppnår kraven. Applikationer kanha ett enhetligt, visuellt tilltalande, framförande men med nackdelen att färre datorer kanbehandla applikationen och blir tillgänglig för färre användare. Användare med kraftfullaredatorer kan fortfarande köra applikationen och erbjuds en rik upplevelse, men en påtagligdel av den potentiella användarbasen går förlorad. Ingen av situationerna är optimal varkenför användare eller utvecklare. För att tillgodose båda behoven hos applikationen, att varatillgänglig för datorer i ett brett spektrum av kapacitet och samtidigt erbjuda avanceradetekniker, innehåller applikationer ofta inställningar som användaren kan anpassa för attförändra nivån hos applikationen.

Applikationer förses vanligen med en meny där användaren kan påverka inställningarnaför applikationen. Ofta innehåller menyn antingen en mängd variabler så användaren kankontrollera direkt vilka tekniker som används, eller består menyn av ett bestämt antal stegfö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åelsehos användaren för vilken e�ekt teknikerna har och vad de olika variablerna påverkar. Föroptimalt resultat behöver användare även veta vilka inställningar som passar den egnadatorn bäst. Användare kan alternativt testa sig fram mellan olika inställningar, en processsom är svår att förstå och få rätt, samt blir lätt tidskrävande. Den enklare varianten avinställningar består av ett bestämt antal steg där varje steg representerar en samling avvariabler. När nivån skiftas från ett steg till ett annat förändras alla variabler som stegetpåverkar. På detta sätt klumpas inställningar ihop så de tillhör en större grupp och när ennivå förändras skiftas alla variabler i gruppen. En enklare inställningsmeny som består avfå 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åsteanpassas till minsta gemensamma nämnaren i en nivågrupp av inställningar och därmed gårkapaciteten inom datorns styrkeområden förlorad. Med en mer avancerad inställningsmeny

1

1.2 Bakgrund 1 INLEDNING

�nns möjlighet att e�ektivare anpassa inställningarna efter datorn men svårighetsgradenför användaren ökar. Optimalt bör mängden variabler att ställa in vara proportionellt motantalet tekniker som applikationen stödjer och att processen för användaren att ställa invariablerna för systemet elimineras.

För att nyttja fördelarna med många inställningsvariabler och enkel användning behövsett nytt angreppssätt som automatiserar funktionaliteten som kontrollorerar applikations-nivån. Applikationer kan implementera ett dynamiskt anpassande system som abstraherarprocessen att manuellt anpassa inställningar. Ett dynamiskt adapterande system kan in-tegreras i en applikations iterationscykel och kontinuerligt uppdatera inställningar underexekveringen. 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överantalet 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 enfördel över statiska inställningar. Komplexiteten hos en applikation, speciellt realtidspro-gram med 3D-gra�k, varierar kraftigt under olika segment av applikationen. Det förekom-mer tillfällen i applikationen då prestandakraven ökas eller sänks på grund av variationeri scenen. Statiska inställningar som användare väljer behöver, för att vara e�ektiva, utsesså de håller en jämn nivå under �uktuerande komplexitet av applikationsscenen. Variablersom sätts på en hög nivå kan sköta sig bra under större delen av applikationen men blien �askhals under tyngre delar. Användaren får antingen acceptera visst fall av prestandaunder tyngre segment eller välja en lägre nivå över hela exekveringen. Ett adaptivt systemkan istället välja ut de tekniker som presterar bäst för tillfället genom hela utförandet avapplikationen. Under de mer krävande segmenten kan systemet automatiskt dra ner nivånpå 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å teknikernasom 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 teknikersom presterar bäst för tillfället.

1.2 Bakgrund

Autonomic Computing presenterades som ett nytt tankesätt inom mjukvaruutveckling ibö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 interaktionfrån kunniga människor. Syftet bakom Autonomic Computing var att lösa problem somuppstod med den hastigt ökande komplexiteten det innefattar att underhålla och vidare-utveckla mjukvaruprogram. Inspiration för Autonomic Computing tas från den mänskligakroppen och dess autonoma nervsystem. Det autonoma nervsystemet i människokroppenhanterar många vitala funktioner för en människas fortlevnad utan medveten påverkan frånmänskliga individen. På samma sätt som det autonoma nervsystemet sköter sig själv i ettstörre system är tanken bakom Autonomic Computing att mjukvaruprogram ska fungerapå de lägre nivåerna. Autonomic Computing bygger på att automatisera uppgifter som

2

1.2 Bakgrund 1 INLEDNING

annars utförs manuellt av utbildad personal och användare av systemet. Ett autonomtsystem är istället självstyrande i de lägre nivåerna och kontrolleras genom högnivå-reglersom utvecklare förser.

Kephart m.�.[?] plockar ut och listar de fyra karaktärsdragen som ett fullständigt au-tonomt system implementerar. Ett autonomt system är själv-kon�gurerande vilket innebäratt systemet kan anpassa sig själv till miljön den existerar i. Detta inkluderar att installeraoch kon�gurera nya moduler till det existerande systemet med minimal manuell inverkansamt 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 utanpå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 identi�era och laga. Själv-helandeegenskaper gör hela systemet mer stabilt. Autonoma system besitter även verktyg för själv-optimering.Själv-optimering handlar konceptuellt likt själv-kon�guration om att anpassasig 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. Optimeringeninnebär också att systemet lär sig från egna erfarenheter för att hantera motsvarande situ-ationer e�ektivare vid nästa incident. Det fjärde och sista karaktärsdragen man �nner hosett autonomt system är förmågan för själv-beskydd. Den beskyddande egenskapen har attgöra med systemets säkerhet. Den hanterar att användare har tillgång till rätt informationoch skyddar mot utomstående attacker. Systemet kan förutse och förebygga externa så välsom interna attacker och skydda sig korrekt mot dem.

En mer ingående mall för de autonoma komponenterna i ett system introduceras avIBM[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 övergripandekontrollen sköts av en komponent benämnd som Autonomic Manager. Komponenten ab-straherar och automatiserar någon funktionalitet som i traditionella system kräver manuellinteraktion. Autonomic Manager-enheten är det analyserande och beslutande organet förden tilldelade funktionaliteten. Komponenten observerar en del i systemet och avgör omfö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. KnowledgeSource-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 sistadelen ä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ällerde förändringar som krävs.

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

Filoso�n 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ängdsom minst krävs för datorn att hinna de beräkningar som ska utföras. Systemet arbetarständigt med att förutse hur mycket energi det behöver för att utföra sina uppgifter ochmäter därför konstant med en speci�k metod hur den tror arbetsbördan kommer föränd-

3

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 spelsbelastning för datorn varierar mellan olika segment under exekvering och kan därmed vinnamycket på att energitillgången anpassas löpande. Gu m.�.[5] byggde vidare inom områdetmed 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 enscen för att förutspå hur mycket energi hårdvaran behöver för att arbeta. Gemensamt fördessa arbeten är att mätningarna de utför sker på en låg hårdvarunära nivå av datorn.Som exempel modi�erar Mochocki i sitt arbete �ödet i pipelinen för gra�kkortet genomatt implementera ett extra steg efter transformation av objekten där systemet beräknarhur 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 mellanDVFS och optimeringsarbetet som utförs i ett autonomt system skiljer sig åt då DVFSsträ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 �nnsutrymme är en gemensam punkt.

1.3 Syfte

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

Undersökningen innefattar granskning av betydelsen tekniker har för applikationensprestanda. Arbetet undersöker även hur olika datorer av varierande kapacitet påverkas avteknikerna och vilken skillnad ett dynamiskt adaptivt system kan göra för applikationensprestanda. Undersökningen mäter prestandan för datorer vid användande av olika teknikeroch analyserar vilken förmåga det dynamiskt anpassande systemet har för att bibehålla enhög prestanda och samtidigt välja lämpliga tekniker för den individuella datorn. Arbetettestar det adaptiva systemets kompetens att sträva efter avancerade tekniker utan attbelasta 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 enapplikation 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överarbetet först visa på skillnad mellan olika parameters påverkan på prestandan.

4

1.5 Avgränsning 1 INLEDNING

Undersökningen kommer använda sig av WebGL och JavaScript. Applikationen tarendast hänsyn att fungera tillsammans med en Chrome-webbläsare. Applikationen somutvecklas för undersökningen implementeras med WebGL och JavaScript vilket begränsarvilka 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 gra�sk pipeline eller andrahårdvarunära rutiner, utan alla mätningar utförs på applikationssidan med JavaScript.

Detta arbete granskar inte hur ett dynamiskt anpassande system byggs på e�ektivastsätt. Arbetets syfte är att undersöka hur tekniker påverkar den övergripande prestandan avapplikationen 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å sombatteritid, 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.

5

2 METOD

2 Metod

Undersökning är en kvantitativ deduktiv mätning där värdet som används för att avgöraprestandan är det FPS-värde programmet har. För att undersöka hur tekniker påverkarprogrammets prestanda och hur ett dynamiskt anpassande system kan automatisera konti-nuerlig förändring av tekniker utvecklas en applikationen att använda vid tester. Testernaresulterar 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 teknikeroch tester där systemet dynamiskt varierar tekniker.

FPS-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 datornhinner 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 �eriterationer 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ändersamma 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ångafall ä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 applikationenkan 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 renderingi separat iterationer utan utför dem efter varandra. Att uppdateringslogiken inte sker ien separat iterationscykel begränsar teknikerna som påverkar processorn, men inte deraslogik. Resultatet av att inte separera är att högst nivån sänks, men förhållandet mellantekniker är oförändrat.

Prestanda för mjukvaruprogram mäts ofta i två resurser, tid och minne. Tid omfattarhur snabbt ett program exekverar, hur många uträkningar det hinner utföra under en giventid. Mätning av minne beaktar hur stor plats applikationen kräver eller tar för sig underkö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ätaminnesanvändning hos ett dynamiskt anpassande system är också en del av optimeringinom Autonomic Computing, men inte inom omfattningen för denna undersökning. Tek-nikerna som används i applikationen varierar inte minnesanvändningen betydande underkö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 parametersom 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örförenklade tekniker som simulerar tyngre. Att använda mer verklighetsförankrade tekni-ker kan möjligt ge en tydligare bild av hur e�ektivt ett dynamisk anpassande system kantillverkas, men för undersökningen i arbetet är det inte sakfrågan. En approximation av

6

2.1 Teknik-metoder 2 METOD

avancerade tekniker, som applikationen använder, påverkar samma delar i pipelinen somreella tekniker men ger ingen gra�sk feedback för användare och är därmed inte lämpligai 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 processornoch gra�kkortet, som också kan påverkas av tekniker, men för arbetets undersökningen ärapplikationen avgränsad till dessa tre då undersökningen inte ämnar värdera vilka teknikersom främst kan påverkas. Därför är applikationen avgränsad till tre delar som har en klarroll i pipelinen.

De använda teknikerna benämns nedan med en förklaring om dess roll och e�ekt.

2.1.1 Shader-teknik

Shader-teknikerna är den parameter i systemet som bestämmer vilket shader-programapplikationen använder för att renderas. Shader-programmen mellan olika shader-teknikersom applikationen använder varierar enbart i arbetsbördan för fragment-shadern. Shader-tekniker påverkar därmed mängden arbete gra�kkortet utför i fragment-shadersteget avgra�kkortspipelinen. Fragment-shaders arbetsbörda varierar beroende på de dimensionerbu�ern har till vilken fragment-shadern skriver data. Om applikationen använder högadimensioner för skärmen det renderas i blir kraven högre på gra�kkortets möjlighet atthantera fragment-shadersteget. Shader-teknikerna som används av applikationen kommerdärmed påverka prestandan beroende på skärmstorleken och kapaciteten hos gra�kkortet.

I moderna gra�kapplikationer förekommer många av de mest avancerade uträkningarnaför den slutgiltiga bilden på skärmens i fragment-shadern. Shader-teknikerna som användsi undersökningen ger ingen gra�sk variation mellan de olika nivåerna. Shader-teknikernasimulerar avancerade och därmed uträkningskrävande tekniker genom att utföra tommauträ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 antaletberä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örstiden det tar för fysikmotorn att simulera en iteration.

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

7

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 gra�ska modellen som representerar objekt byts mellanmodeller med växlande grader av detaljrikedom och polygonantal. Modellerna alternerasi vanligt bruk antingen beroende på vilken inställningsnivå som är inställd eller beroendepå objektets avstånd till kameran i scenen.

Level of Detail-teknikerna i undersökningen, framöver benämnd som LoD-tekniker, in-verkar på gra�kkortets belastning. LoD-teknikerna modi�erar inte shader-programmet eller�ödet på gra�kkortet utan mängden data som gra�kkortet bearbetar. LoD-teknikerna be-stämmer vilken detaljrikedom de gra�ska objekten ritas ut med, där högre detaljrikedominnebär �er vertex-punkter som shader-programmet behöver hantera. LoD-teknikerna ärverkande i en annan del va den gra�ska pipelinen gentemot shader-teknikerna. Shader-teknikernas belastning är i fragment-shadern och bestäms därmed till stor del av dimen-sionerna på bu�erten 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.

8

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 iapplikationen 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 ävenimplementera ett dynamiskt adaptivt system för teknikerna. Applikationen består av enunderliggande struktur som kontinuerligt mäter prestandan och anpassar applikationenskon�guration.

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

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

3.1.2 Design

Designen av applikationen är baserad på den mall som IBM[7] presenterar. IBM ger ettgenerellt designmönster för att bygga autonoma datorsystem, vilka generellt sätt är störreoch mer komplicerade applikationen som utvecklas för undersökningen. Applikationen im-plementerar de mest grundläggande delar som IBM presenterar. Undersökningen fokuserarpå 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 kanbyggas 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 systemetpresterar och agerar därefter. Applikationen realiserar ODA-modellen då den passar sigbäst för systemet. I applikationer där användaren har kontroll över �ödet har systemetinte samma möjlighet att förutse vad som kommer ske. Att observera hur programmetpresterar 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ärldenstyrs 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. Användarenstyr en karaktär i världen, visualiserad i form av en kub, som kan röra sig i alla tre axlarmed användarens input. I världen �nns statiska fysiska objekt som kuben kan kollidera ochinteragera 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,

9

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 gra�ska 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 gra�ska komplexiteten i scenen och har en stor e�ektpå 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 gra�k direkt i webbläsaren, utan användningav insticksprogram. WebGL är baserat på OpenGL ES 2.0[13], en variant av OpenGL[12]speci�kt utvecklat för inbyggda system. OpenGL ES, och därmed WebGL, innehåller endelmängd av OpenGL med vissa plattformsspeci�ka tillägg. WebGL är aningen mer kom-plicerat än de �esta andra webbteknologier därför det är designat att arbeta direkt motgra�kkortet. Som en konsekvens är gränssnittet nära lågnivåspråk, vilket möjliggör snabbauträkningar för komplexa 3D-scener.

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

10

3.2 API 3 IMPLEMENTATION

1 var canvas = document . getElementById ( 'canvas' ) ;2 var g l = canvas . getContext ( 'webgl' ) ;34 // ...

56 g l . c l e a r ( g l .COLOR_BUFFER_BIT | g l .COLOR_DEPTH_BIT) ;7 g l . b indBuf fe r ( g l .ARRAY_BUFFER, ve r t exBu f f e r ) ;8 g l . v e r t exAt t r ibPo in t e r ( ver texPo inter , 3 , g l .FLOAT, false , 0 , 0) ;910 g l . drawArrays ( g l .TRIANGLE_STRIP, s tar tVertex , vertexCount ) ;

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

Applikationssidan använder JavaScript för all WebGL-interaktion, men på gra�kkor-tet kör WebGL små program som kallas shaders. Shader-programmen behandlar geome-trin som applikationen sänder till gra�kkortet och bestämmer hur de ska visas i WebGL-fönstret. Shader-programmen är helt bestämmande i vilken position alla vertex-punkter harsamt vilken färg pixlarna får som vertex-punkternas trianglar täcker. Shader-programmenhar total slutgiltig makt över applikationens gra�ska 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 WebGLinte rendera någonting. Ett shader-program består i sin tur av en vertex-shader och enfragment-shader som båda utför en speci�k uppgift.

Vertex-shadern är det program på gra�kkortet som bestämmer den geometriska formenoch position för alla objekt. Vertex-shadern arbetar med de vertex-punkter som förses avapplikationen. Resultatet från en korrekt vertex-shader är alltid minst den position envertex-punkt har i förhållande till skärmens koordinatsystem, men har också möjlighet attreturnera mer data som sedan kan användas i fragment-shadern. Till vertex-shadern förserJavaScript-sidan representationsmatriser att använda under beräkningarna.

Efter vertex-shadersteget utför gra�kkortet en del beräkningssteg som applikationsut-vecklare inte har någon möjlighet att modi�era. Det huvudsakliga arbetet som utförs ärrasteriseringsdelen där gra�kkortet 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 vilkapixlar trianglarna ska färga och anropar fragment-shadern för dem.

Fragment-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-shadern ar-betar på per-pixel basis och vertex-shadern med vertex-punkter måste värdena som vertex-shadern returnerar till fragment-shadern interpoleras över triangeln med värdena från deandra vertex-punkterna. I moderna applikationer används fragment-shadern bland annatfö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.

Shader-programmen i en applikation bidrar till stor del vilket gra�skt utseende ap-

11

3.2 API 3 IMPLEMENTATION

1 // VERTEX

2 a t t r i b u t e vec4 a_pos i t ion ;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 ;56 uniform mat4 u_wvp ;7 uniform mat4 u_world ;89 vary ing vec2 v_texcoord ;10 vary ing vec3 v_normal ;1112 void main ( ) {13 g l_Pos i t ion = u_wvp ∗ a_pos i t ion ;14 v_texcoord = a_texcoord ;15 v_normal = u_world ∗ vec4 ( a_normal , 0 . 0 ) ;16 }1718 // ----------------

1920 // FRAGMENT

21 uniform sampler2D u_texture ;22 uniform vec3 g_l i gh tD i r e c t i on ;23 uniform vec4 g_di f fu seL ight ;2425 varying vec2 v_texcoord ;26 vary ing vec3 v_normal ;2728 void main ( ) {29 vec4 sampled = texture2D ( u_texture , v_texcoord ) ;30 f l o a t l i g h t = sa tu ra t e ( dot(−g_l ightDi rec t ion , normal ize ( v_normal ) ) ) ;31 gl_FragColor = sampled ∗ l i g h t ∗ g_di f fu seL ight ;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 di�us ljusfaktor.Ljusets riktning och färg förses av applikationssidan vid varje iterationscykel.

12

3.3 Bibliotek 3 IMPLEMENTATION

1 var world = new CANNON.World ( ) ;23 var sphere = new CANNON. RigidBody (4 /* mass */ 5 . 0 ,5 /* shape */ new Cannon . Sphere ( /* radius */ 2) ) ;67 world . add ( sphere ) ;89 ( function loop ( time ) {10 world . s tep ( time ) ;1112 // Render scene

1314 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 kananvä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öratt skifta komplexitet och exekveringstid. Applikationen behöver inte förändra logik�ödeti programmet för att byta shader-program. Då shader-programmen enbart påverkar dengra�ska 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 portadefrå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örspråket. För att vara ett fysikbibliotek är Cannon lättviktigt, funktionsmässigt. Cannonstö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örmä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 ärett World-objekt. Till den sätts inställningar så som gravitationsstyrka och riktning. Allafysiska objekt i applikationen läggs till i world-objektet. För varje iteration av spelloopenanropas 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 ochskalningsdata för varje objekt.

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

13

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 }) ;67 var DrawableGameObject = GameObject . extend ( function ( ) {8 this . v i s i b l e = true ;9 }) . methods ({10 draw : function ( ) {}11 }) ;1213 var myobj = new DrawableGameObject ( ) ;14 myobj . update ( ) ;

Figur 5: Exempel på användande av klass.js. DrawableGameObject ärver i det här falletfrå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 kanleda 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] ärett JavaScript-bibliotek som underlättar objektorienterad utveckling. Klass abstraherararvsfunktionaliteten 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ånGameObject. DrawableGameObject får då tillgång till medlemsvariabler och metoder frånGameObject. 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 exempelextend.

3.3.3 GlMatrix

Vid arbetande med en 3D-scen krävs mycket geometri och matematiska uträkningar föratt beskriva hur scenen ser ut. Många av uträkningarna involverar matris- och vektorope-rationer som behöver vara snabba och e�ektiva. Varken WebGL eller webbläsare erbjuderstö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], ettbibliotek speci�kt utvecklat för syftet att användas till WebGL-applikationer. GlMatrix ärhelt 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 teknikeranvänder sig av samma bibliotek �nns ingen påverkar av biblioteket på mätningarna mellanteknikerna.

14

3.4 Mätningar 3 IMPLEMENTATION

1 var po s i t i o n = vec3 . fromValues ( cannon . r ig idbody . pos ) ;2 var r o t a t i on = quat . fromValues ( cannon . r i g idbody . quatern ion ) ;34 var world = mat4 . c r e a t e ( ) ;5 mat4 . f romRotat ionTrans lat ion ( world , ro ta t i on , p o s i t i o n ) ;6 mat4 . s c a l e ( world , world , cannon . r ig idbody . s c a l e ) ;78 // Draw object using world -matrix

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

3.4 Mätningar

Mätningar i applikationen tjänar två syften. Mätning av programmets prestanda är datansom 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ällamä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 detgått sedan applikationen startade.

Det första som sker i början av en iteration är att applikationen beräknar värden frånfö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. Medtiden t kan en approximation av FPS-värdet beräknas med formeln:

FPS =1

t

Detta uppskattade FPS-värde som beräknas för varje iteration kan ge hoppiga resultat sominte ö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 detfaktiska 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 vilketinte är tillräckligt responsivt för det dynamiskt anpassande systemet. Komponenterna iden adaptiva strukturen av applikationen använder sig av FPS-approximationen men meden 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 segmentav logik i applikationen, Update, Draw och Wait. Dessa variabler är sammanslagna värdetför FPS-approximationen över en iteration. Variablerna utgör grundvärden för de enskildadelarna i det dynamiskt adaptiva systemet.

15

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 datorsystemetshögupplösta tid med performance.now. Tiden samplas återigen efter all uppdateringslogikutförts och den för�utna tiden beräknas genom skillnaden av de två tiderna.

elapsed = secondsample− firstsample

Formeln för beräkning av för�uten 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ördablir tyngre.

3.4.3 Draw

Draw-tiden är ett mått på den för�utna tiden då applikationen gör matrisoperationer ochanropar WebGL för rendering. Draw-tiden beräknas direkt efter uppdateringslogiken ärklar och efter att det sista anropet gjorts till WebGL. Draw-tiden är det värde som varierarminst i applikationen och är sällan �askhalsen. Draw-värdet påverkas av mängden synligaobjekt som �nns i scenen och därmed måste skickas till gra�kkortet för att renderas.

16

3.4 Mätningar 3 IMPLEMENTATION

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

3.4.4 Wait

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

3.4.5 Dynamisk adaptiv logik

Den dynamiskt anpassande strukturen har i uppgift att balansera en acceptabel prestandafö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 kon�guration utan försöker hela tiden avancera inivå. Systemet är uppbyggt av tre komponenter vilka är Controller, Technique-group ochTechnique-instance. Dessa komponenter implementerar gemensamt den mall som beskrivsav 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 resterandedelar. Controller har ett antal instanser av Technique-group i en array. Controller hartre framstående uppgifter i systemet vilka är att beräkna värden för mätvariablerna vidvarje uppdatering, anropa de underliggande komponenterna och se till att det allmännaFPS-värdet inte sjunker under acceptabel nivå.

Technique-group är den komponent som sköter den kontinuerliga evalueringen av hur

17

3.4 Mätningar 3 IMPLEMENTATION

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

Technique-instance är den yttersta komponenten i det adaptiva systemet och är den delsom beräknar sina egna prestationsvärden och är gränssnittet ut mot tekniken den hållerkoll på. När en Technique-instance är aktiv uppdaterar den sina egna värden baserat på devärden som Controller beräknat från förra iterationen. Technique-instance är grundklassenför alla varianter av tekniker som applikationen implementerar. De speci�ka teknikernasom används har vars en Technique-instancetyp representerad, med rutiner för att varierajust den typen av teknik.

Technique-group samlar alla objekt av samma Technique-instancetyp. På så sätt harvarje 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. AllaTechnique-instancer i samma Technique-group evalueras på samma villkor men varierarmellan Technique-groupinstanser. Technique-group har värde för acceptanstid, acceptans-nivå och toleransnivå som den använder för att bedöma den Technique-instance som äraktiv. 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 e�ekten från den gamla tekniken inte spelar in längre. Acceptansnivån är detvärde den aktiva Technique-instancen måste nå över för att den ska anses accepterad ochansvarig 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 underför att fortfarande vara aktiv.

Metoden som används för att hantera förändringar är främst baserad på den heuristiskalö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 attgöra en förändring i systemet inte är för generöst satt. Gu m.�[5] utvecklar en metod somtar historien i beaktande före systemet gör en förändring, vilket planar ut �uktuationenoch ger ett jämnare resultat. Det dynamiskt adaptiva systemet i undersökningen användersig av ett snarlikt kontrollschema anpassat till miljön i vilken applikationen verkar. Föresystemet gör en förändring, analyserar det nästkommande tekniks tidigare prestation omtekniken i ett annat skede varit aktiv. Beslutet om att avancera till en mer avancerad teknikbaseras 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ärdetsom 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 be�nner sig mellan acceptansnivå

18

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 annorlundavärden.

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

Utöver den kontinuerliga evalueringen sker en översikt av Controller varje sekund närett nytt faktiskt FPS-värde �nns tillgängligt. Controller tar beslut om det nya FPS-värdetligger 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 iarrayen med Technique-group för att utvärdera sina aktiva Technique-instancer. De aktivainstanserna evalueras under denna process med hårdare nivåvärden än under den vanligaevalueringssekvensen. Den första gruppen som anser att sin aktiva instans är på gränsenoch växlar ner returnerar detta som resultat till Controller, vilken i sin tur nöjer sig ochutelämnar bedömning av resterande grupper. Prioriteringen av vilken grupp som i förstahand 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 skiftaner.

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

19

3.4 Mätningar 3 IMPLEMENTATION

mets resultat är inte tillfredsställande då FPS-värdet är 60 och det �nns mer avanceradeatt 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 systemetkan 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 presentationen.Första tekniken som heter Lightning ljussätter scenen med algoritmer för ambient, di�usoch 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 objektetsyta som används vid ljussättningen. Parallax -tekniken bygger vidare från andra teknikenmen ännu en textur som innehåller data om höjdskillnader på objektets yta.

Shader-teknik (1-3)

Nivå 1 Nivå 2 Nivå 3Lightning Normal Parallax

De övriga fem varianterna av Shader-teknik påverkar inte den gra�ska 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å 8Delay 50 Delay 100 Delay 500 Delay 1000 Delay 5000

Teknikkategorin som in�uerar 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 nyttobjekt tillkommer och antal objekt redan är på den maximala gränsen tas det objekt somexisterat längst bort från världen. Nivåerna som �nns av Boll-teknik bestämmer antaletaktiva simultana objekt.

Boll-teknik

Nivå 1 Nivå 2 Nivå 3 Nivå 4 Nivå 5 Nivå 6 Nivå 7 Nivå 8 Nivå 9 Nivå 1010 20 40 50 75 100 150 200 300 500

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

20

3.5 Tester 3 IMPLEMENTATION

Figur 10: Högt detaljerade kaniner i scenen för att öka polygonantalet och större påverkanav 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 vilkene�ekt tekniker av skiftande komplexitet har på applikationens prestanda. De ska visa hurtekniker kan påverka prestandan mellan olika datorer. Testerna ska även pröva hur detdynamiskt 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 resultatska granska om tekniker som påverkar olika delar av applikationens prestanda bör mätasseparat.

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ändandepå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örkon�gurerat rörelsemönster ochkan inte påverkas utifrån. Mönstret som karaktären rör sig efter är att den på ett simpeltsätt roterar runt sin position så den under testfallet får en överblick över hela scenen. Det

21

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 denupprepande 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örningen används föratt ta hela testet i beaktande.

Alla givna testfall körs automatisk löpande efter varandra. Varje testfall körs under enminut. Under ett givet testfall som inte testar det adaptiva systemets förmåga förändrasinga tekniker. Testfallen använder fast satta inställningar för att undersöka vilken skillnadteknikerna gör för applikationens prestanda. Ett testfall påbörjar inte mätningen förränapplikationen ä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 attstabiliseras efter inladdningen. Detta för att varken nätverksuppkopplingen eller datornsinladdningsfö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 ingenpå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 avett PHP-script som sparar den till �l grupperad efter testdatorns ip-adress. Om �len sparaskorrekt 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 avdata 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 olikatekniker. 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 teknikernafö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 kanvisa vilken skillnad mängden beräkningar under uppdateringen gör för prestandan. Undertestfall 1�3 används samma Shader-teknik och samma LoD-teknik medan Boll-teknikenskiftar mellan testerna. Datorer med snabb processor bör hantera testfallen bättre ändatorer med en sämre processor.

Test 1 Test 2 Test 3Shader Lightning Lightning LightningBollar 10 50 200LoD 1 1 1

22

3.5 Tester 3 IMPLEMENTATION

3.5.5 Shader-tekniker

Shader-teknikerna varierar arbetsbelastningen för fragment-shadersteget på gra�kkortet.Testfall 4�8 varierar vilken Shader-teknik applikationen använder sig av medan Boll-teknikoch 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. Datorermed kraftigare gra�kkort förväntas prestera bättre än datorer med sämre gra�kkort. Ävenskärmstorleken bör spela in för resultat i testfall 4�8.

Test 4 Test 5 Test 6 Test 7 Test 8Shader Lightning Parallax Delay 50 Delay 500 Delay 1000Bollar 50 50 50 50 50LoD 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-teknik är samma för testfall 9�11. LoD-teknikerna skiftar vilken detaljrike-dom objekt renderas med och därmed mängden arbete vertex-shadern utför. LoD-teknikenspåverkan bestäms till stor del även av vilken Boll-teknik som är aktiv eftersom högre Boll-teknik betyder �er objekt att rendera. Boll-tekniken är satt på en nivå så de �esta datorerkan hantera antalet vid lägsta LoD-nivå och bollantalet samtidigt är tillräckligt högt attLoD-teknikerna får en tydlig påverkan. Datorer med kraftigare gra�kkort förväntas presterabättre med högre LoD-teknik.

Test 9 Test 10 Test 11Shader Parallax Parallax ParallaxBollar 50 50 50LoD 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. Testetbörjar med alla tekniker inställda på lägsta nivån. Det är sedan det adaptiva systemets målatt avancera tekniknivån till en grad och kvalitet som passar datorn. Testfallets evalueringbaseras dels på medelvärdet av FPS likt andra testfall men tar också i beaktande vilkaslutgiltiga tekniker systemet valt för datorn. Syftet med testet av det dynamiskt adaptivasystemet är att undersöka hur väl ett adaptivt system kan variera tekniker anpassade fördatorn 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 avprestandakapacitet. 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å

23

3.5 Tester 3 IMPLEMENTATION

alla datorer använder snarlik miljö. Operativsystemet som används av samtliga datorer ärWindows, med varierande version. Alla testfall har körts i webbläsaren Chrome v26. Val avenhetlig testmiljö ska inte påverka undersökningens teori men är vald av kompatibilitetsskälför applikationen.

Gra�kkort 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 NVIDIAQuadro 600

Intel XeonW3565 @3.2GHz

12 GB Hewlett Pac-kard 0B4Ch

Windows XP

Dator 3 GeForce GT520M

Intel Core i5- 2430M @2.4Ghz

8 GB ASUSTekP5Q-E

Windows 7Professional

Dator 4 ATI RadeonHD 5700 Series

Intel XeonE5506 @2.13Ghz

6 GB HP NC326i Windows 7 En-terprise

Dator 5 ATI RadeonHD 4800 Series

Intel Core 2Duo - E8400 @3.0Ghz

8 GB ASUSTekP5Q-E

Windows 7Professional

Dator 6 AMD RadeonHD 78000

Intel Core i7 -2600 @ 3.4Ghz

8 GB Hewlett-Packard 1494

Windows 7Professional

24

4 RESULTAT

Figur 11: Datorernas färgkodning i testtabellerna

Figur 12: Resultat för testfall 1�3.

4 Resultat

I detta kapitel redovisas resultat från respektive dator och testfall. Resultaten från testfallenpresenteras i forma av tabeller inom räckvidden 0�60 FPS. De datorer vars värden skiljersig främst från resten ges i den löpande texten. Datorernas resultat är presenterade itabellerna med samma ordning som de är numrerade. Datorernas färgkodning kan sesi Figure 11 tillsammans med deras namn. Samtliga testresultat tillsammans med störretabeller 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 detfår �nnas i scenen samtidigt. Boll-teknikerna belastar datorns processor främst. Det förstatestfallet 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 kankö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ägstainställningarna. I Test 2 presterar återigen Dator 1 sämst resultat med försumlig skillnadfrån Test 1. Resultatet för Dator 1 i Test 2 är 52.59 FPS en knapp ökning med 1 FPS frånTest 1. Test 3 ökar markant nivån av Boll-teknik vilket återspeglas i testresultaten. Datornmed högst resultat är Dator 6 med 55.73 FPS. Dator 1 får sämst resultat med 37.18 FPStätt följd av Dator 4 på 37.26 FPS.

4.2 Shader-tekniker

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

25

4.2 Shader-tekniker 4 RESULTAT

Figur 13: Resultat för testfall 4�8.

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

Test 4 klarar majoriteten av datorerna med en bra nivå. Dator 1 får direkt svårt atthantera testet och slutar med 25.72 FPS. Dator 2 är näst sämst med 50.60 FPS vilket ärgodtagbart 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 understatre datorers resultat. Dator 1 får resultatet 24.29 FPS, Dator 2 47.59 FPS och Dator 356.03 FPS. Resterande tre datorer resultat förändras inte och stannar på över 59 FPS.

Resultaten fortsätter sjunka för Dator 1�3 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 iTestfall 5 låg drygt över den acceptabla gränsen resulterar 30.46 FPS i Test 6 och hamnardä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 1�3 och börjar även påverkaDator 4 och Dator 5. Dator 1 har 2.08 FPS, Dator 2 4.92 FPS och Dator 3 11.23 FPS, allatestvärden markant sänkta från Test 6. Dator 4 och Dator 5 får något lägre resultatvärdenmed 53.36 för Dator 4 och 57.91 för Dator 5, men bägge datorerna presterar fortfarandegodkänt.

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

26

4.3 LoD-tekniker 4 RESULTAT

Figur 14: Resultat för testfall 9�11.

4.3 LoD-tekniker

De sista testerna med statiska tekniker är testfall 9�11. Testerna varierar vilken LoD-teknikapplikationen använder medan Shader-teknik och Boll-teknik är samma. Resultaten fråntester med LoD-teknik varierar kraftigare beroende på vilken Boll-teknik som används. Förtestfall 9�11 används en Boll-teknik som ska vara enkel att hantera i lägre LoD-nivå ochge e�ekt 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ördatorerna att hantera. Dator 9 har lägst resultat med 49.59 FPS vilket beror på nivåerna avShader-teknik och Boll-teknik som applikationen använder. Dator 2�6 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 sittresultat med 52.74 men klarar testet med godkänd nivå. Dator 4�6 slutar med resultat över58 FPS.

Test 11 är det sista testet med statiska tekniker. Resultaten för Dator 1 sjunker till10.17 FPS och för Dator 2 till 24.06 FPS. Dator 3 som klarade Test 10 med godkäntpresterar 33.53 FPS och sjunker under tillräcklig nivå. De kraftigare datorerna 4�6 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 dynamisktadaptiva 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 systemetvalt för datorn när testet avslutas.

Resultaten från testet med det dynamiskt adaptiva systemet kan ses i Table 1. Samtligadatorer får ett resultat inom godkänd nivå med 45 < FPS < 60. Resultaten i Table 1 visarockså att de kraftigare datorerna använder mer avancerade tekniker för applikationen.

27

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.09Shader-teknik Lightning Delay 500 Lightning Parallax Delay 100 Delay 100Boll-teknik 100 75 100 150 75 150LoD-teknik 4 6 1 2 6 6

28

5 ANALYS

5 Analys

5.1 Resultat

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

5.1.1 Boll-teknik

Testfall 1�3 varierar aktiv Boll-teknik som applikationen använder. Boll-tekniker påverkararbetsbelastning 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 varierarhur 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 applikationensprestanda. Samtliga datorer hanterar Test 1 och Test 2 med, för undersökningen, godkändprestanda. I Test 3 där Boll-teknikens nivå höjs markant sjunker testresultaten för Dator1�5 under 45 FPS. Dator 6 påverkas inte lika kraftigt av den höjda nivån för processornsarbetsbörda och hamnar som ensam testdator ovanför den godkända nivån. Resultatenvisar tydligt att val av Boll-teknik påverkar applikationens prestanda. Testresultaten fördatorerna 1�5, trots att de inte anses godtagbara för undersökningen, är inte katastrofalaoch 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örDator 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 testdatorer vilketapplikationen kan utnyttja.

5.1.2 Shader-teknik

Redan i första testet av Shader-teknik har Dator 1 lågt testresultat. Då Shader-teknikeni Test 4 är den lägsta nivån, som även användes i Test 1�3, beror det på den ökade nivånav Boll-teknik och LoD-teknik som används i testfall 4�8. Resultaten för Dator 1 sjunkerprocentuellt ganska kraftigt för varje testfall med Shader-teknik, något som tyder på lågkapacitet hos gra�kkortet. 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 avanceradeShader-tekniker används. Resultaten antyder att Dator 2 har relativt övriga datorer högrekapacitet för processorn än gra�kkortet. Vid jämförelse mellan Dator 2 och Dator 3 visarresultaten att det är lämpligt att separera mätningar mellan olika tekniker. I samtliga test-fall 1�3 har Dator 2 högre testresultat än Dator 3 när Boll-teknik och därmed processornsbelastning varieras. Under testfall 4�8 där istället Shader-teknik skiftas är rollerna heltomvända och Dator 3 presterar över Dator 2 med klar marginal för alla tester. Resultatenpekar på att Dator 2 har kraftiga processor än Dator 3 medan Dator 3 har större kapacitetför beräkningar på gra�kkortet.

Resultaten visar också att det är stor skillnad mellan datorernas prestanda, särskiltvid högre nivåer. Datorerna 4�6 presterar påtagligt bättre än de sämre datorerna. Dato-

29

5.2 Dynamiskt adaptivt system 5 ANALYS

rerna med större kapacitet har möjlighet till en gra�skt mer avancerad presentation avapplikationen med hög prestanda.

5.1.3 LoD-teknik

Resultaten från testerna som varierar LoD-teknik, Test 9�11, visar liknande mönster somtestfallen 4�8. LoD-teknik och Shader-teknik har liknande e�ekt för prestandan genom attpåverka gra�kkortet. Trots att Shader-teknik och LoD-teknik inverkar på separata delarav gra�krenderingens pipeline påminner testresultaten om varandra. Dator 1 och Dator 2når över godkänd prestandanivå endast i första testet av LoD-teknik. Dator 3 har snäppetkraftigare gra�kkort och klarar även Test 10. Resultaten tyder på att datorerna 1�3 harsämre gra�kkortskapacitet än datorerna 4�6 och bör därför presentera applikationen medenklare gra�ska tekniker. LoD-tekniken är den teknik med tydligast verklighetsförankringdå det är en vedertagen teknik för moderna spel.

5.1.4 Summering av teknikanalys

Utifrån testerna kan uttydas att de tekniker applikationen använder har stor betydelseför dess prestanda. Framförallt vid användande av tyngre Shader-tekniker syns en klarskillnad och många av testdatorerna får svårt att prestera. Testerna visar att de mindrekraftiga datorerna inte lyckas prestera då teknikerna är för tunga, medan datorer medbättre prestanda hanterar teknikerna betydligt bättre. Undersökningen visar att de tyngredatorerna har kapacitet att använda tyngre tekniker med en bibehållen uppdateringsfre-kvens och möjliggör en visuellt mer imponerande applikation. Om datorerna med lägrekapacitet använder samma tekniker, presterar applikationen inte på en acceptabel nivå.Den visuella presentationen för datorerna som använder lägre tekniker sjunker i kvalitet,men kan applikationen kan bibehålla en högre prestanda.

I en jämförelse mellan Dator 3 och Dator 2 kan man se att det �nns syfte i att mätateknikerna var för sig och inte enbart applikationens totala prestanda. Dator 2 presterarbättre än Dator 3 under tester med högre Boll-teknik, medan Dator 3 presterar bättre i detester med shader och LoD-teknikerna. Testresultaten visar att det �nns ingen relationenmellan hur applikationen presterar för processorn och gra�kkortet. Därför kan Dator 2 fåbättre testresultat för teknikerna som påverkar processorn medan Dator 3 presterar bättrepå gra�kkortet.

5.2 Dynamiskt adaptivt system

Underlag för analys är det sista testfallet då applikationen använder det dynamiskt ad-aptiva systemet. Det adaptiva systemet strävar ständigt efter att använda mer de meravancerade teknikerna och samtidigt hålla FPS-värdet på en stabil nivå. Slutresultatetfrån testerna visar att alla testdatorer avancerade från grundinställningarna som appli-kationen startar med. Testerna bevisar att det dynamiskt adaptiva systemet har varieratvilka tekniker applikationen använder sig av. Resultaten visar också att de kraftigare dato-rerna med större kapacitet använder mer avancerade tekniker än de datorerna med sämrekapacitet. Slutligen visar resultaten att samtliga datorers prestandaresultat hamnar inom

30

5.2 Dynamiskt adaptivt system 5 ANALYS

den accepterade nivån med 45 < FPS < 60. Testresultaten för det dynamiskt adaptivasystemet visar att systemet med ett tillfredsställande resultat anpassar sig efter datornapplikationen körs på. Undersökningen bevisar att det är möjligt för applikationen att an-passa sig efter exekveringsmiljön. För de kraftigare testdatorerna valde applikationen meravancerade tekniker. För de svagare datorerna behöll applikationen enklare tekniker för attupprätthålla prestandanivån.

31

6 DISKUSSION

6 Diskussion

Applikationen som utvecklats är en implementation av själv-optimeringskomponenten inomAutonomic Computing. Systemet som sköter den dynamiska anpassningen är utformad en-ligt konceptmallen för att autonomiskt system presenterad av IBM[7]. I sin forskning visarGu m.�.[4] att spel kan variera i komplexitet och är lämpliga för DVFS-implementationer.Testerna utförda i detta arbete bygger vidare på antagandet att spels komplexitet är kva-li�cerad att mätas och visar att en spelapplikationen implementerad med ett autonomisktsjälv-optimerande systemet har möjlighet att mäta sin prestanda och anpassa applikatio-nens inställningar efter resultaten.

6.1 Prestanda

Med ett system som automatiskt anpassar sig efter datorns behov och kapacitet kan ap-plikationer underlätta för användaren och erbjuda en bättre upplevelse mer lättillgängligt.Det dynamiskt adaptiva systemet kan själv lägga sig på en nivå där datorns kapacitet kom-mer till rätt användning. Testerna veri�erar möjligheten att tillverka applikationer med ettadaptivt systemet i grunden. Testfallen som undersökts kan däremot inte bevisa stabilite-ten och kontinuiteten för systemet. En möjlig konsekvens av det adaptiva system är attteknikerna skiftas ofta och skapar stor variation av upplevelsen. Det dynamiska systemetsom hanterar förändringarna måste byggas på ett sådant sätt att tekniker inte byts ut framoch tillbaka vilket skapar hopp i uppdateringsfrekvensen.

Exempel: Då en teknik presterar bra, beslutar det adaptiva systemet att avancera tillnästa steg av samma tekniktyp. Den nya tekniken är betydligt tyngre för datorn och ap-plikationens uppdateringsfrekvens sjunker. Systemet byter ut den tyngre tekniken mot denförra aktiva tekniken och uppdateringsfrekvensen återställs. Efter en tid med den enklaretekniken anser systemet att tekniken presterar bra och avancerar till nästa teknik igen, dåsamma e�ekt upprepas.

I en tidig version av det utvecklade systemet uppstod den beskrivna situationen medjämna mellanrum. Genom att implementera en modell av metoden som Gu m.�[5] presen-terar stabiliseras upprepat skiftande av tekniker och ger bättre resultat för det dynamisktadaptiva systemet.

Det utvecklade dynamiskt adaptiva systemet veri�erar med testresultaten möjlighetenatt implementera en anpassande struktur för applikationer. Det utvecklade systemet ärdock inte optimalt implementerat och har en del aspekter vilka kan förbättras med vida-re utveckling för att frambringa bättre resultat. De olika typerna av tekniker har ingenkommunikation sinsemellan. Två tekniktyper som mäter samma fokusvariabel kan påverkavarandras mätresultat på sätt som systemet inte designat. Ena tekniktypens aktiva teknikkan ha blivit accepterad för att stanna kvar och fungerar väl när den andra tekniktypensaktiva teknik, med samma fokusvariabel, byter upp sig till en högre nivå. Detta kan påverkaFPS-värdet så det sjunker under acceptabel nivå. Då den teknik som nyss avancerat är un-der sin prövotid, tiden en teknik får vara aktiv före den evalueras, har den svårare att bytasut av systemet än de andra teknikerna. Risken är i detta fall stor att den teknik som avsystemet ansågs accepterad får sämre prestanda på grund av den nya teknikens påverkan

32

6.1 Prestanda 6 DISKUSSION

och blir nedskiftad. Det dynamiska systemet kan istället implementeras med ett centralthanteringssystem med bättre kommunikation mellan tekniktyper. Tekniker som påverkarsamma delar av applikationens prestanda blir införstådda i att en ny teknik är under sinprövotid och har möjlighet att vara med liberal med sina egna värden för en period. Detdynamiska systemet kan mer noggrant mäta vilken teknik som påverkar prestandan.

Applikations adaptiva system tar inte heller hänsyn till hur tekniktyper med olikafokusvariabler påverkar varandra. Som exempel har Boll-teknik och LoD-teknik en starkrelationen mellan sig. Boll-teknik påverkar prestandan för LoD-tekniken med �er synligaobjekt som ska renderas. Det dynamiskt adaptiva systemet följer inga regler för vilken avteknikerna som prioriteras att avancera till en högre nivå. Systemet kan förbättras meden hierarki över teknikernas prioritet, vilken tekniktyp som har företräde. Kontrollen attvälja vilka tekniker som har förtur i systemet kan ges antingen utvecklare eller användareav applikationen.

Lagspikes

En realtidapplikations belastning kan variera kraftigt under exekvering. Olika partier avapplikationen innehåller varierande komplexitet och skapar �uktuationer i FPS. Applika-tioner med ett väldesignat adaptivt system kan teoretiskt sett förebygga, eller minska,e�ekten av sådana förändringar. När systemet exekverat under en period har den hafttid att ska�a kunskap om hur olika tekniker presterar för datorn den körs på. Genom attimplementera ett systematiskt poängsystem över teknikerna kan det dynamiska systemethålla koll på vilka tekniker som är enklare kontra svårare för datorn att använda. Ett re-sponsivt system kan med sådan information snabbt reagera på tyngre partier genom attbyta till en teknik den förutser bättre hanterar det tunga partiet. Denna förmåga hos ettdynamiskt systemet är inte passande för alla typer av tekniker. En del tekniker tar ett tagefter de byts ut innan dess e�ekt slutar påverka prestandan. Detta beror på att datorn kanbehöva byta ut �yktigt minne och resurser som tillhört den gamla tekniken.

E�ektiva reaktioner implementerade i det adaptiva systemet kan lämpligtvis kombine-ras med inläsning av nya resurser. Applikationen kan noti�era det adaptiva systemet närny data läses in, vilket i sin tur aktiverar enklare tekniker för applikationen att använda.Systemet kan undvika tillfälliga dippar av prestanda genom att reagera i förväg.

Applikationen som utvecklats för undersökningen tar ingen hänsyn till snabba utbytenav tekniker och är därmed inte testat inom detta arbete. Däremot visar testerna att för-ändringar av tekniker påverkar prestandan och att det dynamiskt adaptiva systemet harmöjlighet att utvärdera teknikernas förmåga. Att skapa ett system med snabbare reaktiongentemot förändringar är ett område för vidare forskning. Hypotetiskt sätt kan applikatio-nen genom hela exekvering ligga på en stadig FPS trots stora förändringar i scenen.

33

7 SLUTSATS OCH VIDARE FORSKNING

7 Slutsats och vidare forskning

Detta arbete har undersökt vilken påverkan olika tekniker har på en applikations prestandaoch hur ett dynamiskt adaptivt system automatiskt kan anpassa vilka tekniker applika-tionen använder efter datorns kapacitet. Genom tester med olika statiska tekniker bevisarundersökningen att de tekniker applikationen använder påverkar prestandan i stor utsträck-ning. Testerna visar att för datorer med låg kapacitet kan mer avancerade tekniker dra nerprestandan till nivåer då applikationen inte är användbar medan de kraftigaste datorernamed lätthet hanterar samma tekniker. Vid testande av det dynamiskt anpassande syste-met visar resultaten att det är möjligt att utveckla ett dynamiskt system som balanserarapplikationens prestanda med anpassad tekniknivå för datorn. Testresultaten för den dyna-miska strukturen visar att systemet valt tekniker som den exekverande datorn kan hanterapå en nivå som undersökningen de�nierat som acceptabel. Det implementerade adaptivasystemet visas med testerna vara kapabelt att mäta sig fram till vilka tekniker som passardatorn kan hantera. Det dynamiskt adaptiva systemet kan med vidare forskning förbättraförmågan att välja de mest e�ektiva teknikerna och stabilare förändringar.

Genom att utföra en initial testsekvens direkt när applikationen laddas in kan syste-met få ett riktvärde för datorns kapacitet. Systemet kan då välja en lämplig startnivå fördatorn istället för att börja på lägsta nivån och arbeta sig uppåt. Även resursinladdningenkan optimeras i applikationen genom att först ladda in startteknikerna. Under exekveringfortsätter applikationen ladda in resterande resurser och det adaptiva systemets mätningarfortföljer normalt. En sådan förändring kan innebära snabbare stabilisering av systemetsinställningar. Vilka tekniker som först laddas in kan skräddarsys enligt �er parametrar.Applikationen kan starta med att ladda in de lågupplösta modellerna och texturerna förstoch börja använda när grunden är inladdad. Mer detaljerade modeller och texturer lad-das in under applikationens exekvering eller inte alls beroende på datorns kapacitet. Detadaptiva systemet kan avgöra om datorn presterar tillräckligt för att kunna hantera hög-re upplösta resurser. Applikationen kan spara in på nätverkstra�k genom att bara laddain de resurser den kommer använda. Användaren gynnas också genom snabbare starttidav applikationen. Applikationen bör sträva efter att så tidigt som möjligt vara körbar föranvändaren. Resursinladdning och starttider är ett eget forskningsområde som med fördelkan kombineras med det dynamiska systemet.

Vidare forskning bör undersöka en dynamiskt adaptiv struktur implementerad i enapplikation med mer verklighetsförankring och med vettiga tekniker. Forskning kan under-söka hur ett dynamiskt adaptivt system sköter sig i en produktionsmiljö. Applikationen somutvecklats i detta arbete använder simulerade tekniker och implementerar ingen särskildoptimering. Den naturliga progressionen från den utvecklade applikationen är att utvecklateknikerna eller ersätta med reella exempel. Applikationen som används i undersökningenimplementerar främst tekniker som påverkar gra�kkortets belastning. Vidare undersökningkan granska tekniker för processorns belastning som inte påverkar spellogiken eller använ-darinteraktionen. Tänkbara tekniker är CPU-uppdaterade partikele�ekter eller karaktärsa-nimationer av variabel komplexitet. Partikele�ekter i WebGL-applikationer implementerasofta på gra�kkortet, men för en dator med kraftigare processor kan gra�kkortets belastninglättas eller alternativt lämna utrymme för mer avancerade gra�ska tekniker.

34

REFERENSER REFERENSER

Referenser

[1] J. S. Chase, D. C. Anderson, P. N. Thakar, A. M. Vahdat, R. P. Doyle, Managingenergy and server resources in hosting centers, In Proceedings of the eighteenth ACMsymposium on Operating systems principles, pages 103�116, 2001

[2] K. Choi, R. Soma, M. Pedram, Dynamic voltage and frequency scaling based onworkload decomposition, In Proceedings of the 2004 international symposium on Lowpower electronics and design, pages 174�179, 2004

[3] D. Diaz, Klass.js, https://github.com/ded/klass, 2013-04-10

[4] Y. Gu, S. Chakraborty, W. T. Ooi, Games are up for DVFS, In Proceedings of the43rd annual Design Automation Conference, pages 598�603, 2006.

[5] Y. Gu, S. Chakraborty, Control theory-based DVS for interactive 3D games, In Pro-ceedings of the 45th annual Design Automation Conference, pages 740�745, 2008.

[6] S. Hedman, Cannon.js, https://github.com/schteppe/cannon.js, 2013-04-10

[7] IBM, An architectural blueprint for autonomic computing, 2005

[8] IBM, Autonomic Computing: IBM?s Perspective on the State of Information Tech-nology, 2001

[9] B. Jones, Gl Matrix, http://glmatrix.net/ , 2013-04-10

[10] J. O. Kephart, Autonomic computing: the �rst decade, In Proceedings of the 8thACM international conference on Autonomic computing , pages 1�2, 2011

[11] Khronos Group, WebGL Speci�cation, http://www.khronos.org/registry/webgl/specs/latest/ ,2013-03-21

[12] Khronos Group, OpenGL, http://www.opengl.org/, 2013-04-03

[13] Khronos Group, OpenGL ES 2.0, http://www.khronos.org/opengles/, 2013-04-03

[14] M. Maggio, H. Ho�man, M. D. Santambrogio, A. Agarwal, A. Leva, Decision ma-king in autonomic computing systems: comparison of approaches and techniques,In Proceedings of the 8th ACM international conference on Autonomic computing ,pages 201�204, 2011

[15] B. C. Mochocki, K. Lahiri, S. Cadambi, X. S. Hu, Signature-based workload estima-tion for mobile 3D graphics, In Proceedings of the 43rd annual Design AutomationConference, pages 592�597, 2006

[16] W3C, High Resolution Timer, http://www.w3.org/TR/2012/REC-hr-time-20121217/ , 2013-05-08

[17] WebGL Matrix Library Benchmark,http://stepheneb.github.io/webgl-matrix-benchmarks/matrix_benchmark.html , 2013-04-10

35

A ORDLISTA

A Ordlista

Applikation - I uppsatsen syftar applikation för det mesta till applikationer inom domä-nen realtidsrenderade applikationer, e.g. Spel eller andra 3D-miljöer.

DVFS - Dynamic Voltage Frequency Scaling, struktur som optimerar energitillgången förbatteridrivna maskiner.

Prestanda - Begrepp för hur väl applikationen presterar.

Lågnivå - Logik som är lik de uppgifter hårdvaran utför.

Pipeline - Sekvens av rutiner som utförs efter varandra. Gra�kkortet har en pipeline föratt rendera.

Teknik - Inställning av applikationen som påverkar den visuella presentationen, applika-tionens beräknande intelligens eller kapacitet.

FPS - Uppdateringar per sekund. Mått för applikations prestanda.

LoD - Level of Detail. Detaljrikedom, där högre är önskvärt men tyngre för systemet.

Shader - Program som körs på gra�kkortet. Bestämmer position och färg för objekt somrenderas.

Pixel - Pixel är den minsta beståndsdelen som bygger upp gra�ken för en datorskärm.

Vertex - Representation av en punkt i den gra�ska världen. Alla objekt är uppbyggda avvertex-punkter som kombinerade bildar geometriska �gurer.

Vertex-shader - Delen av ett shader-program som hanterar vertex-punkter och minstberäknar dess position på skärmen.

Fragment-shader - Delen av shader-program som exekveras för varje pixel av skärmen.Bestämmer vilken slutgiltig färg varje pixel får.

36

B BILDER

B Bilder

Testresultat (FPS)

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

Test 1 53.41 59.09 58.9 59.05 59.18 59.11Test 2 52.59 59.11 58.81 58.9 59.14 59.14Test 3 37.18 44.23 40.62 37.26 40.97 55.73Test 4 25.72 50.6 57.55 58.78 59.16 59.16Test 5 24.29 47.59 56.03 59.0 59.15 59.13Test 6 12.72 30.46 45.92 59.01 59.15 59.18Test 7 2.08 4.92 11.23 53.36 57.91 59.05Test 8 1.47 2.12 5.97 32.42 41.97 54.95Test 9 49.59 58.09 58.26 58.96 58.87 59.1Test 10 22.95 39.39 52.74 58.99 58.82 59.1Test 11 10.17 24.06 33.64 58.97 58.95 59.12

37