Coordonator științific CONF. DR. ING GIANINA GABOR UNIVERSITATEA DIN ORADEA FACULTATEA DE INGINERIE ELECTRICĂ ȘI TEHNOLOGIA INFORMAȚIEI DOMENIUL /… [606632]

UNIVERSITATEA DIN ORADEA FACULTATEA DE INGINERIE ELECTRICA și TEHNOLOGIA INFORMAȚIEI DEPARTAMENTUL TEHNOLOGIA INFORMAȚIEI TEMA – PROIECTAREA ȘI REALIZAREA UNEI APLICAȚII ANDROID NATIVE Lucrare de Finalizare a studiilor a student: [anonimizat] 1). Tema lucrării de finalizare a studiilor: PROIECTAREA ȘI REALIZAREA UNEI APLICAȚII ANDROID NATIVE 2). Termenul pentru predarea lucrării 27.06.2014 3). Elemente inițiale pentru elaborarea lucrării de finalizare a studiilor Cunoștințe de programare Java, Android Software Development Kit, XML, lucru cu baza de date SQLite. 4). Conținutul lucrării de finalizare a studiilor Descrierea tehnologiilor și aplicațiilor folosite pentru dezvoltarea aplicației și modul în care acestea au fost utilizate. Descrierea arhitecturii aplicației. Prezentarea modului de utilizare al aplicației. Concluzii și dezvoltări ulterioare. 5). Material grafic: Capturi de ecran din aplicație, schema de navigare în aplicație. 6). Locul de documentare pentru elaborarea lucrării: Internet, laborator Calculatoare, biblioteca universității. 7). Data emiterii temei 30.10.2013
Coordonator științific CONF. DR. ING GIANINA GABOR

UNIVERSITATEA DIN ORADEA FACULTATEA DE INGINERIE ELECTRICĂ ȘI TEHNOLOGIA INFORMAȚIEI DOMENIUL / PROGRAMUL DE STUDIU: TEHNOLOGIA INFORMAȚIEI FORMA DE ÎNVĂȚĂMÂNT ZI PROIECT DE DIPLOMĂ COORDONATOR ȘTIINȚIFIC: CONF. DR. ING GIANINA GABOR ABSOLVENT: [anonimizat] 2014

UNIVERSITATEA DIN ORADEA FACULTATEA DE INGINERIE ELECTRICĂ ȘI TEHNOLOGIA INFORMAȚIEI DOMENIUL / PROGRAMUL DE STUDIU: TEHNOLOGIA INFORMAȚIEI FORMA DE ÎNVĂȚĂMÂNT ZI PROIECTAREA ȘI REALIZAREA UNEI APLICAȚII ANDROID NATIVE COORDONATOR ȘTIINȚIFIC: CONF. DR. ING GIANINA GABOR ABSOLVENT: [anonimizat] 2014

Cuprins CAPITOLUL I. Introducere 5 …………………………………………………………………CAPITOLUL II. TEHNOLOGII UTILIZATE 6 …………………………………………………….2.1 Sistemul de operare iOS 6 …………………………………………………………….2.1.1 Arhitectura iOS 6 ……………………………………………………………………2.1.2 Aplicații iOS 7 ……………………………………………………………………….2.2 Swift 9 …………………………………………………………………………………2.4 Metal 12 ……………………………………………………………………………….CAPITOLUL III. Dinamica Fluidelor 14 ……………………………………………………….3. Dinamica computerizată a fluidelor 14 ………………………………………………..3.1 Ecuația Navier-Stokes pentru fluide incompresibile 14 ……………………………..4.1 Aplicațiile intensive CPU 16 …………………………………………………………..4.1.1 Algoritm 16 ………………………………………………………………………….4.1.2 Aplicația OpenGL 17 ………………………………………………………………..4.1.3 Aplicația Metal 17 …………………………………………………………………..4.2 Aplicațiile intensive GPU 18 ………………………………………………………….4.2.1 Algoritm 18 ………………………………………………………………………….4.2.2 Aplicația OpenGL 23 ………………………………………………………………..4.2.3 Aplicația Metal 25 …………………………………………………………………..4.4 OpenGL vs Metal 25 …………………………………………………………………..CAPITOLUL vI. cONCLUZII 31 ………………………………………………………………..Bibliografie 32………………………………………………………………………………
4

CAPITOLUL I. INTRODUCERE Tema aleasă pentru lucrarea de diplomă reprezintă o comparație între două API-uri grafice pe dispozitive iOS (iPhone, iPad, iPod). Pentru a realiza comparația am creat câte două aplicații pentru fiecare API disponibil pe dispozitivele iOS: OpenGL și Metal. Aplicațiile prezintă o simulare de lichid/fum bazându-se pe formula Navier-Stokes. Am ales această tema datorită familiarității mele cu platforma mobilă iOS, o platformă care permite dezvoltarea unor aplicații complexe, oferind de asemenea fiabilitate și securitate, cât și datorită interesului meu față de dezvoltarea aplicațiilor grafice. În dezvoltarea aplicațiilor am decis să folosesc limbajul de programare Swift, un limbaj relativ nou, în curs de maturizare, ce oferă funcționalități și sintaxă moderne. Despre fiecare tehnologie în parte voi vorbi de-a lungul acestei lucrări, pentru a oferi informațiile de bază astfel încât să poată fi înțelese aplicațiile prezentate. Capitolul II prezintă pe scurt tehnologiile ce stau la baza proiectării aplicațiilor iOS. Acest capitol poate avea atât rolul de a familiariza cititorul cu tehnologiile utilizate cât și de a fi o sursă rapidă de documentație, prin exemplele prezentate. Capitolul III detaliază ecuația Navier-Stokes pentru lichide incompresibile utilizată în dezvoltarea simulărilor. Capitolul VI prezintă realizarea efectivă a aplicațiilor, cât și compararea de performanță a celor doua API-uri utilizate.

5

CAPITOLUL II. TEHNOLOGII UTILIZATE 2.1 SISTEMUL DE OPERARE IOS Sistemul de operare iOS este unul din cele mai populare sisteme de operare pentru dispozitive mobile, primul loc fiind ocupat de către Android. iOS a fost lansat în anul 2007 de către Apple odată cu apariția primului iPhone, un produs revoluționar care a schimbat sensul cuvântului smartphone. La scurt timp după apariție, Apple a oferit publicului SDK-ul (Software Development Kit) pentru dezvoltarea aplicațiilor pe platforma lor, creând astfel o industrie nouă, cea a dezvoltării aplicațiilor mobile. Cea mai semnificativă funcționalitate prin care iOS s-a distins față de competiție a fost posibilitatea de a interacționa cu interfața prin intermediul gesturilor. [5] 2.1.1 ARHITECTURA IOS Arhitectura sistemului de operare iOS este similară cu cea a diferitelor sisteme de operare existente pe alte platforme mobile sau pe PC-uri. Aceasta este împărțită pe diferite
6
Figura 2.1.1 – Straturile sistemului de operare iOS [1]

straturi, asemănător unei stive, fiecare strat oferind anumite funcționalități cât și un nivel de abstractizare asupra straturilor mai joase. [1] Figura 2.1.1 ilustrează la un nivel înalt principalele straturi ale sistemului de operare. Straturile superioare oferă diferite abstractizări pentru funcționalitățile de baza cum ar fi interceptarea de gesturi pe ecranul dispozitivului sau funcționalitate de redare a unui video, pe când straturile inferioare oferă acces direct la funcționalitățile hardware cum ar fi geolocație, comunicare cu dispozitive Bluetooth, sau acces la primitivele sistemului de operare cum ar fi semafoarele sau funcții de sistem pentru redare audio folosind PCM (Pulse Code Modulation). [2] De asemenea straturile inferioare oferă toate funcționalitățile de la nivelurile superioare, dar fără abstractizarea acestora. Un exemplu de abstractizare în cazul funcționalităților pentru procesare grafică îl putem întâlni la framework-urile SpriteKit și Metal. SpriteKit oferă un API simplu de utilizat specializat pentru dezvoltarea jocurilor care se bazează pe funcționalitatea oferită de Metal, în schimb Metal este un API la nivel mai jos care permite atât dezvoltarea de jocuri cât și a altor aplicații ce utilizează procesorul grafic. 2.1.2 APLICAȚII IOS Aplicațiile iOS sunt programe complexe care utilizează funcțiile de sistem în moduri creative pentru a oferi noi capabilități utilizatorilor. Majoritatea aplicațiilor se bazează pe recomandările și limitările propuse de către Apple, astfel o aplicație standard folosește șablonul Model-View-Controller. [3] Aplicațiile rulează într-un proces propriu limitat astfel încât o aplicație sa nu aibă acces la memoria altei aplicații. Componenta esențială în cadrul unei aplicații iOS îl reprezintă ViewController-ul, acesta fiind responsabil de interceptarea gesturilor și reîmprospătarea interfeței grafice conform logicii aplicației. [4] Atât aplicațiile cât și fiecare ViewController au un ciclu de viață previzibil, trecând prin diferite stări de la inițializare la deinițializare, în funcție de acțiunile utilizatorului și de logica aplicației. Aceste stări pot fi observate în figura 2.1.2.1 și figura 2.1.2.2. Programatorul trebuie să utilizeze aceste tranziții pentru a încărca sau salva starea aplicației astfel încât să 7

ofere o experientă fluidă pentru utilizatori. În cazul aplicațiilor grafice este important să fie tratat cazul în care aplicația este pusă în fundal pentru a opri execuția codului grafic, sau cazul în care aceasta devine activă pentru a reporni activitatea grafică.
8
Figura 2.1.2.1 – Ciclul de viață al unei aplicații [3]
Figura 2.1.2.2 – Ciclul de viață al unui ViewController [4]

2.2 SWIFT Swift este noul limbaj open-source oferit de Apple pentru dezvoltarea aplicațiilor și framework-urilor iOS și OSX. Apple promovează Swift ca fiind un limbaj puternic, intuitiv și ușor de învățat. Swift îmbină paradigmele programării funcționale cu cele ale programării orientate pe obiecte oferind o sumedenie de funcționalități și caracteristici care permite dezvoltarea de programe eficiente și rapide cu un efort minimal. Deși este considerat succesorul limbajului Objective-C, Swift este un limbaj de sine stătător dezvoltat de la zero cu scopul de a oferi o alternativă modernă pentru dezvoltarea aplicațiilor mobile. Principalele diferențe față de Objective-C sunt: deducția tipurilor de date, tipizarea statică, siguranța, îmbunătățirea managementului de memorie, lizibilitatea îmbunătățită, reducerea coliziunilor de nume cât și performanța ridicată. [6] Unul din problemele principale ale limbajului Objective-C îl constituie tipizarea dinamică a variabilelor, unde tipul variabilelor este verificat în momentul rulării aplicațiilor. În Swift această problemă a fost eliminată și verificarea tipurilor se face la timpul compilării, de asemenea a fost eliminată posibilitatea de a executa o metodă a unui obiect nul, aceasta rezultând într-o excepție la momentul rulării aplicației. Aceste schimbări oferă o siguranță ridicată aplicațiilor scrise în Swift prin ajutarea programatorilor să evite aceste probleme. Deoarece Objective-C este bazat direct pe C, evoluția acestuia este direct legată de evoluția limbajului C, dar Swift fiind un limbaj independent poate să evolueze în continuu fără astfel de limitări, oferind performanță din ce în ce mai bună și capabilități moderne cum ar fi definirea de operatori. Din punct de vedere al performanței Swift este comparabil cu C++, cel din urmă având un foarte mic avantaj din punct de vedere al vitezei. [7] Ca și popularitate, Swift a reușit să ajungă în anul 2017 pe locul 11 în lista celor mai utilizate limbaje de programare conform RedMonk. [8] 9

2.3 OPENGL ES Unul dintre cele mai răspândite API-uri grafice, OpenGL (Open Graphic Language) a fost lansat în 1992 ca un standard pentru dezvoltarea portabilă a aplicațiilor 2D și 3D. [9] OpenGL este un strat de abstractizare al hardware-ului (Hardware Abstraction Layer) ce expune un număr de funcții care permit trimiterea de instrucțiuni către driverul grafic astfel făcând posibilă desenarea de imagini pe orice tip de hardware care implementează standardul. [10] 10
Figura 2.2.1 – Topul limbajelor de programare utilizate în 2017 [8]

Operația de transmitere a instrucțiunilor de la CPU (Central Processing Unit) la GPU (Graphical processing unit) se întâmplă în mod asincron. OpenGL se bazează pe un mod de operare numit double buffering, care presupune existența a două tampoane de memorie, unul fiind folosit pentru afișarea imaginii curente și celălalt pentru scrierea următoarei imagini. După terminarea operației de scriere, cele două tampoane sunt interschimbate în momentul reîmprospătării ecranului pentru a oferi o imagine clară utilizatorului fără artefacte vizibile din cauza scrierii într-un tampon care este în același timp citit. [10]
OpenGL ES este un subset al OpenGL specializat pentru funcționarea pe dispozitive mobile, excluzând anumite funcționalități care cereau putere multă de procesare. Începând cu OpenGL 2.0, programatorii au primit mai mult control asupra acțiunilor grafice prin pipeline-ul programabil și limbajul GLSL (OpenGL Shading Language), care permit scrierea de programe numite shadere care sunt executate în diferite momente ale pipeline-ului după cum se poate observa în figura 2.3.1. De obicei într-un pipeline grafic există două tipuri 11
Figura 2.3.1 – Pipeline-ul OpenGL [11]

de shadere: Vertex Shader și Fragment Shader, fiecare având un anumit rol. Un Vertex Shader trebuie să returneze o poziție pentru fiecare vertex, care mai apoi trec prin procesul de asamblare a primitivelor, de exemplu triunghiuri, apoi prin procesul de rasterizare care transformă primitivele în pixeli. Rolul unui Fragment Shader este de a returna o culoare pentru fiecare pixel. Această flexibilitate permite crearea de efecte limitate în teorie doar de imaginația și cunoștințele matematice ale programatorilor. Datorită acestor trăsături am ales OpenGL ca o opțiune pentru dezvoltarea aplicațiilor. 2.4 METAL Cel de-al doilea API grafic ales pentru implementarea aplicațiilor este Metal. Deși OpenGL oferă acces la nivel relativ jos pentru operații grafice, Metal reușește să meargă un pas mai departe eliminând anumite neajunsuri de care dă dovadă OpenGL prin îmbinarea funcționalităților OpenGL și OpenCL (Open Computing Language), cât și prin eliminarea anumitor validări de stare. [12][13] Metal oferă toate funcționalitățile pe care le oferă OpenGL, pipeline-ul grafic fiind asemănător după cum se poate observa în figura 2.4.1.
Metal oferă mai mult control asupra modului în care comenzile sunt grupate și transmise către procesorul grafic prin utilizarea unui așa numit CommandQueue. Acest CommandQueue permite crearea obiectelor de tip CommandBuffer. Un command buffer permite gruparea tuturor comenzilor de desenare ce trebuie executate într-un pas prin utilizarea unuia sau mai multor obiecte de tip RenderCommandEncoder, după cum se poate 12
Figura 2.4.1 – Pipeline-ul Metal [14]

observa în figura 2.4.2. Numărul de astfel de obiecte utilizate cât și gruparea lor și timpul de executare pot afecta drastic performanța aplicației, acestea putând fi configurate din fire de execuție diferite pentru o performanță sporită. [15] Utilizarea mai multor obiecte de tip CommandBuffer este utilă pentru aplicații ce execută mai mulți pași independenți, însă Metal oferă modalități de execuție asincronă și pentru aplicații care vor să grupeze mai multe comenzi pentru un singur pas printr-un obiect numit ParallelRenderCommandEncoder.
Metal oferă toate aceste unelte dar în cele din urmă este responsabilitatea programatorului să le folosească într-un mod eficient pentru a asigura o performanță ridicată a aplicației.
 13
Figura 2.4.2 – Command Buffer [15]

CAPITOLUL III. DINAMICA FLUIDELOR Capitolul III prezintă conceptul de dinamica a fluidelor și ecuația esențială utilizată în simulări de lichide și gaze. 3. DINAMICA COMPUTERIZATĂ A FLUIDELOR Dinamica computerizată a fluidelor este o ramură a mecanicii fluidelor care utilizează algoritmi și metode numerice în cadrul unui program pe calculator pentru a modela și rezolva probleme în care apar fluide. [16] Modelarea acestor probleme se bazează pe rezolvarea unui set de ecuații diferențiale prin diferite metode de discretizare. [16] 3.1 ECUAȚIA NA VIER-STOKES PENTRU FLUIDE INCOMPRESIBILE La baza majorității problemelor de dinamică computerizată a fluidelor stă ecuația Navier-Stokes. [17] În rezolvarea unor probleme fizice, de multe ori se fac anumite presupuneri pentru a simplifica problema. În cazul simulărilor din această lucrare se presupune că fluidele sunt omogene și incompresibile, aceasta presupune ca densitatea fluidului este constantă în spațiu și volumul oricărei subregiune este constant în timp. [18] Astfel obținem următoarea ecuație: ) După cum se poate observa ecuația este alcătuită din 4 termeni diferiți: •Primul termen reprezintă mișcarea cantităților din câmpului de viteză, acesta se transportă pe sine însuși cât și alte cantități aflate în fluid, de exemplu cerneală. •Cel de-al doilea termen reprezintă gradientul presiunii, propagarea presiunii dinspre valori mari spre valori mici. ∂u∂t=−(u⋅∇)u−1ρ∇p+ν∇2u+F∇⋅u=0
14

•Al treilea termen reprezintă viscozitatea fluidului, rezistența acestuia la mișcare. •Ultimul termen reprezintă forțele externe care acționează asupra fluidului. [18] Ecuația Navier-Stokes poate fi calculată analitic doar pentru anumite configurări, dar poate fi rezolvată incremental prin tehnici de integrare numerică. Această metodă de calculare este benefică pentru simulări unde se dorește vizualizarea incrementală a evoluției lichidului. [18]
15

CAPITOLUL VI. STUDIU COMPARATIV În acest capitol voi prezenta pe scurt părțile esențiale ale dezvoltării aplicațiilor cât și comparația din punct de vedere al performanței acestora. Am creat câte două aplicații pentru fiecare API: una care sa utilizeze mai mult procesorul și una care își execută majoritatea funcționalității pe unitatea grafică. 4.1 APLICAȚIILE INTENSIVE CPU Primul set de aplicații, numite MultipleCubes, utilizează în principal procesorul. Acestea au ca scop desenarea unui număr mare de obiecte simple pe ecran și aplicarea unor rotații pentru fiecare obiect desenat, astfel încât obiectele să se rotească în jurul axei Y proprii. 4.1.1 ALGORITM Algoritmul în cazul ambelor aplicații este foarte simplu. La inițializarea aplicațiilor se creează un număr de obiecte 3D, în cazul acesta cuburi, și se asignează o poziție în coordonatele spațiului cât și o culoare pentru a putea distinge diferitele obiecte.
16
Figura 4.1.1.1 – 1600 de cuburi desenate pe ecran

În momentul în care obiectele urmează să fie desenate pe ecran, se generează o matrice de rotație cât și o matrice de proiecție care sunt apoi trimise către unitatea grafică. În cadrul programelor grafice se execută înmulțirea matricelor pentru determinarea poziției și rotației finale ale obiectului cât și aplicarea culorii. Toate valorile pentru poziția, rotația și culoarea obiectelor sunt generate aleatoriu. Un exemplu al acestor aplicații poate fi văzut în figura 4.1.1.1. 4.1.2 APLICAȚIA OPENGL Pentru realizarea aplicației s-au utilizat Vertex Array Objects și Vertex Buffer Objects pentru memorarea structurilor de date și a stării pipeline-ului grafic. La pornirea aplicației se încarcă un obiect dintr-un fișier OBJ, care conține toate informațiile pentru fiecare vertex și apoi se duplică pentru a crea numărul de obiecte dorite. Această duplicare se realizează pentru a asigura o încărcare rapidă a datelor în cazul numerelor mari de obiecte. Aplicația OpenGL utilizează comenzile standard pentru crearea instrucțiunilor de desenare. Toate instrucțiunile sunt executate în stil secvențial, creându-se un număr de desene egal cu numărul de obiecte, folosind același shader cu valori de poziție și culoare diferite. 4.1.3 APLICAȚIA METAL Aplicația Metal folosește în mare parte aceeași logică ca și aplicația OpenGL pentru încărcarea obiectelor la pornirea aplicației și setarea pozițiilor inițiale Shader-ul utilizat este identic cu cel din OpenGL doar adaptat pentru limbajul Metal Shading Language, logica de funcționare al acestuia poate fi văzută în figura 4.1.3.1. Vertex Shader-ul manipulează pozițiile primite prin înmulțiri cu matrici și returnează poziția finală, iar Fragment Shader-ul colorează obiectul uniform cu aceeași culoare. Spre deosebire de aplicația OpenGL, aplicația Metal nu transmite instrucțiunile de desenare secvențial către procesorul grafic ci utilizează capabilitățile Metal pentru codificare paralelă. Instrucțiunile sunt codificate pe fire de execuție diferite pe procesor și in momentul în care toate firele de execuție și-au terminat operațiile, comenzile sunt trimise la procesorul grafic. Aceasta este o optimizare față de aplicația OpenGL unde suntem forțați de către limitările API-ului să codificam instrucțiunile secvențial pe un singur fir de execuție. 17

Altă optimizare utilizată în aplicație este technica tripple-buffering, prin care codificarea pentru următoarele două cadre ce urmează să fie afișate se realizează în timpul afișării cadrului curent. 4.2 APLICAȚIILE INTENSIVE GPU Cel de-al doilea set de aplicații, numite FluidDynamics, au ca scop utilizarea intensă a unității grafice, minimizând drastic nevoia de a executa instrucțiuni pe procesor. Ambele aplicații folosesc același algoritm pentru a produce efectul grafic dorit. Printre cele mai intense operații grafice se numără simulările, astfel pentru acest set de aplicații am ales să creez o simulare de lichid și fum. 4.2.1 ALGORITM Pornind de la ecuația Navier-Stokes pentru fluide incompresibile, putem crea o serie de metode care să genereze o simulare cât mai realistă din punct de vedere fizic. 18
Figura 4.1.3.1 – Shaderele pentru aplicația Metal

Deoarece operațiile sunt executate pe procesorul grafic, toată funcționalitatea va fi implementată folosind limbajul de programare al procesorului grafic specific fiecărui API, GLSL pentru OpenGL și Metal Shading Language pentru Metal. În cadrul programelor ce rulează pe procesorul grafic nu există spații de stocare a informației între execuții, cum ar fi: variabile globale, vectori sau obiecte, dar pentru persistarea informațiilor pot fi utilizate texturile. Toate texturile utilizate sunt bidimensionale și folosesc formatul RG, iar fiecare texel din textură este de tipul Float16. Această configurare permite stocarea de informație în intervalul [-1, 1] pentru fiecare texel din textura. Astfel se poate salva informația cu referire la direcția în care se deplasează o particulă în canalele RG sub forma unui vector. Din motive de performanță, nu au fost utilizate texturi în formatul RGBA deoarece canalele BA ar fi rămas neutilizate în majoritatea programelor, ar fi mărit cantitatea de memorie rezervată și ar fi avut un impact negativ asupra vitezei de scriere în textură. O altă problemă întâmpinată este faptul ca nu se pot executa operații de citire și scriere în același timp pe aceeași textură. Asta înseamnă că pentru fiecare suprafață utilizată vor exista câte două texturi, care după fiecare operație de scriere vor fi interschimbate. Pentru realizarea simulării se folosesc atât câmpuri scalare, pentru care se utilizează doar componenta R a texturilor, cum ar fi în cazul presiunii sau a densității, cât și câmpuri vectoriale pentru care se folosesc componentele RG a texturilor, ca de exemplu viteza. Primul pas cât și cel mai simplu este aplicarea de forțe externe. Dacă eliminam toate celelalte shadere, shaderul de aplicare a forțelor externe ar acționa ca un program de desenare. Acesta pas de fapt setează valorile de direcție în textura de viteză, iar pentru textura de densitate, acest pas setează culoarea, “cerneala” care urmează sa fie afectată de câmpul de viteză. Modul de funcționare al acestui pas poate fi vizualizat în figura 4.2.1.1. Următorul pas este cel de mișcare al cantităților, cum ar fi câmpul de viteză sau densitatea. Pentru a realiza acest pas trebuie ținut cont de limitările procesorului grafic. Un procesor grafic efectuează multe instrucțiuni simple simultan, astfel nu putem merge pe varianta intuitivă de a muta o particulă din poziția curentă în altă poziție determinată, deoarece poziția în care o mutăm e posibil să fie citită de o altă instanță a programului în 19

același timp. Această implementare ar produce efecte neașteptate și nedorite. Modul de rezolvare al problemei este de fapt să calculăm poziția precedentă pentru texelul curent și să copiem valoarea interpolată. [18] Cel mai costisitor pas este cel de calculare a presiunii. Acest pas a fost separat în trei programe diferite: calcularea divergenței, scăderea gradientului și calcularea difuziunii. Primele doua programe sunt executate o singură dată fără să utilizeze multe resurse. Programul pentru calcularea difuziunii în schimb, se bazează pe o metodă iterativă de relaxare pentru aproximarea unor ecuații Poisson, numită tehnica iterativă Jacobi, ceea ce 20
Figura 4.2.1.1 – Campul de densitate și de viteză pentru pasul de aplicare a forțelor.

înseamnă că acest program trebuie executat de un număr de ori pană converge la o soluție. Un număr ideal de iterații este intre 20 și 80. [18] După toți acești pași simularea de lichid este completă și poate fi vizualizată. Figura 4.2.1.2
ilustrează câmpul de densitate cât și cel de viteză în cadrul unor simulări. Un lucru important de observat în figură sunt vorticele, acele efecte de rotație, care se obțin datorită iterațiilor Jacobi. Acest efect este bun pentru un lichid însă în cazul unei simulări de fum efectul ar trebui să fie mai pronunțat. 21
Figura 4.2.1.2 – Campul de densitate și viteză pentru o simulare completă.

Pentru a obține efectul dorit am adăugat un pas în plus, alcătuit din două metode. Prima metodă calculează câmpul de vorticitate pe baza câmpului de viteză existent, iar cea de-a doua metodă aplică efectul asupra câmpului de viteză. Figurile 4.2.1.3 și 4.2.1.4 ilustrează texturile pentru densitate, presiune, viteză cât și cea pentru vorticitate după aplicarea acestui pas adițional.

22
Figura 4.2.1.3 – Campul de densitate și presiune după aplicarea pasului de vorticitate.

4.2.2 APLICAȚIA OPENGL Aplicația OpenGL compilează toate shaderele la momentul pornirii aplicației și le păstrează în memorie pentru o utilizare eficientă. Majoritatea funcțiilor folosite au fost încapsulate în clase și structuri ajutătoare. Un astfel de exemplu este clasa “Surface” care încapsulează funcționalitatea de creare a unor texturi pe baza dimensiunilor specificate cât și o metodă de a goli conținutul unor texturi. Această funcționalitate este prezentată în figura 4.2.2.1. 23
Figura 4.2.1.4 – Campul de vorticitate și viteză după aplicarea pasului de vorticitate.

Pentru fiecare shader am creat câte o metodă care este responsabilă de configurarea variabilelor necesare rulării shader-ului cât și pentru stabilirea destinației de desenare conform tehnicii prezentate în subcapitolul anterior. La fel ca și în cazul aplicației OpenGL anterioare, toate instrucțiunile sunt executate în mod secvențial.
24
Figura 4.2.2.1 – Funcționalitatea clasei Surface în OpenGL

4.2.3 APLICAȚIA METAL Aplicația Metal folosește aceeași logică prezentă în aplicația OpenGL. Suprafețele si referințele către shadere sunt create în momentul pornirii aplicației, iar pentru fiecare ciclu de reîmprospătare a ecarnului se execută codificarea comenzilor de desenare. Față de aplicația anterioară, unde instrucțiunile grafice erau identice pentru toate obiectele, în cadrul acestei aplicații, logica de funcționare nu permite codificarea paralelă a instrucțiunilor, deoarece la fiecare pas rezultatul trebuie scris într-o altă textură. Prin urmare, aplicația Metal din punct de vedere al logicii cât și din punct de vedere al metodei de codificare a instrucțiunilor grafice este identică cu cea OpenGL, diferențele fiind datorate particularităților fiecărui API, de exemplu limbajele de shading diferite. 4.4 OPENGL VS METAL Din punct de vedere al performanței, scopul unor aplicații grafice este sa ruleze la cel puțin 30 de cadre pe secundă, numărul ideal fiind 60. În continuare performanța unor aplicații va fi măsurată în funcție de numărul de cadre care aceasta le afișează pe secundă, în funcție de diferiți parametri. În cazul aplicațiilor ce necesită procesare intensă pe CPU parametrul este numărul de cuburi, iar în cazul simulărilor de fluid, parametrul este numărul de iterații Jacobi. Pentru determinarea performanței aplicațiilor am folosit debugger-ul standard din IDE-ul XCode, cât și utilitatea Instruments. Toate testele au fost efectuate pe urmatoarele dispozitive: •iPhone 5S – procesor Apple A7 1.3Ghz dual-core, procesor grafic PowerVR G6430 (quad-core graphics), 1GB RAM, rezoluție 640×1136 pixels, iOS 10.3.1 •iPhone 7 – procesor Apple A10 Fusion 2.34 GHz quad-core, procesor grafic PowerVR Series7XT Plus (six-core graphics), 2GB RAM, rezoluție 750×1334 pixeli, iOS 10.3.1 •iPad Air 2 – procesor Apple A8X 1.5Ghz triple-core, procesor grafic PowerVR GXA6850 (octa-core graphics), 1GB RAM, rezoluție 1536×2048 pixels, iOS 10.3.1 25

Primul test va compara performanța aplicațiilor MultipleCubes care necesită mai multă procesare pe CPU, prin ilustrarea numărului de cadre care acestea pot afișa pe secundă pentru diferite cantități de obiecte.
26Cadre pe secundă0FPS40FPS80FPS
Cuburi5001000150020002500
60FPS
OpenGL – iPhone 5S
Metal – iPhone 5S
OpenGL – iPhone 7
Metal – iPhone 7
OpenGL – iPad Air 2
Metal – iPad Air 2Figura 4.4.1 – Comparație de performanță pentru aplicațiile MultipleCubes.

27Timp de initializareSecunde0,0s0,1s0,3s0,4s
iPhone5iPhone7iPad Air 2
0,008s
0,006s
0,012s
0,243s
0,237s
0,277sOpenGLMetal
Figura 4.4.2 – Comparație a timpului de inițializare al aplicațiilor FluidDunamics

28Cadre pe secundă0FPS40FPS80FPS
Iterații Jacobi204080120
60FPS
OpenGL – iPhone 5S
Metal – iPhone 5S
OpenGL – iPhone 7
Metal – iPhone 7
OpenGL – iPad Air 2
Metal – iPad Air 2Figura 4.4.3 – Comparație de performanță pentru aplicațiile FluidDynamics.

29
Figura 4.4.4 – Ordonarea și gruparea operațiilor în aplicația OpenGL

30
Figura 4.4.5 – Ordonarea și gruparea operațiilor în aplicația Metal

CAPITOLUL VI. CONCLUZII Pe parcursul lucrării au fost prezentate cele mai importante elemente necesare dezvoltării unei simulări de lichid sau fum pe platforma iOS folosind OpenGL și Metal. De asemenea a fost prezentată și o comparație a celor doua implementări aratând avantajele cât și dezavantajele acestora. În majoritatea situațiilor Metal a avut o performanță mai bună, însă această performanță a necesitat multă optimizare din partea programatorului. Diferența de performanță pentru operații pur grafice este neglijabilă față de OpenGL. În cazul prezentat, OpenGL a avut o performanță aproape egală cu Metal, fară ca programatorul sa petreacă mult timp la optimizarea codului. Pe viitor, aplicațiile pot fi îmbunătățite prin ajustarea dimensiunilor texturilor astfel încât texturile să aibe dimensiunile egale cu jumatate din dimensiunile ecranului. Rezultatul ar fi o performanță mai bună însă această mișcare ar afecta calitatea imaginii finale. Pentru a rezolva problema calității s-ar putea adăuga un pas care să execute un blur gaussian pe imagine pentru a asigura o tranziție mai bună între pixeli. De asemenea poate fi implementată logica pentru a adauga obiecte fixe sau mobile care să interacționeze cu lichidul, sau s-ar putea trece de la 2D la 3D.
31

BIBLIOGRAFIE [1] About the iOS Technologies, https://developer.apple.com/library/content/documentation/Miscellaneous/Conceptual/iPhoneOSTechOverview/Introduction/Introduction.html, Consultat la 10.07.2017 [2]What is Core Audio, https://developer.apple.com/library/content/documentation/MusicAudio/Conceptual/CoreAudioOverview/WhatisCoreAudio/WhatisCoreAudio.html, Consultat la 10.07.2017 [3]The app life cycle, https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html#//apple_ref/doc/uid/TP40007072-CH2-SW9, Consultat la 10.07.2017 [4]Understanding the ViewController Lifecycle, https://developer.apple.com/library/content/referencelibrary/GettingStarted/DevelopiOSAppsSwift/WorkWithViewControllers.html#//apple_ref/doc/uid/TP40015214-CH6-SW1, Consultat la 10.07.2017 [5]iOS, https://en.wikipedia.org/wiki/IOS, Consultat la 10.07.2017 [6]Swift vs. Objective-C: 10 reasons the future favours Swift, https://www.infoworld.com/article/2920333/mobile-development/swift-vs-objective-c-10-reasons-the-future-favors-swift.html, Consultat la 10.07.2107 [7]Swift vs. Objective-C: 5 Reasons for using Swift, https://theappsolutions.com/blog/development/swift-vs-objective-c/, Consultat la 10.07.2017 [8]The RedMonk Programming Language Rankings: June 2017, http://redmonk.com/sogrady/2017/06/08/language-rankings-6-17/, Consultat la 10.07.2017 [9]OpenGL Overview, https://www.opengl.org/about/, Consultat la 10.07.2017 [10] Lengyel E., (2012): Mathematics for 3D Game Programming and Computer Graphics Third Eddition, Cengage Learning, Boston, pp. 1-9. [11]Introduction to OpenGL ES 3.0, http://www.informit.com/articles/article.aspx?p=2181697, Consultat la 10.07.2017 32

[12]Metal (API), https://en.wikipedia.org/wiki/Metal_(API), Consultat la 10.08.2017 [13]Fundamental Metal Concepts, https://developer.apple.com/library/content/documentation/Miscellaneous/Conceptual/MetalProgrammingGuide/Device/Device.html#//apple_ref/doc/uid/TP40014221-CH2-SW1, Consultat la 10.08.2017 [14]Graphics Rendering: Render Command Encoder, https://developer.apple.com/library/content/documentation/Miscellaneous/Conceptual/MetalProgrammingGuide/Render-Ctx/Render-Ctx.html, Consultat la 10.08.2017 [15]Command Organization and Execution Model, https://developer.apple.com/library/content/documentation/Miscellaneous/Conceptual/MetalProgrammingGuide/Cmd-Submiss/Cmd-Submiss.html#//apple_ref/doc/uid/TP40014221-CH3-SW1, Consultat la 10.08.2017 [16]Mecanica fluidelor numerică, https://ro.wikipedia.org/wiki/Mecanica_fluidelor_numerică, Consultat la 10.08.2017 [17] Navier-Stokes equations, https://en.wikipedia.org/wiki/Navier–Stokes_equations, Consultat la 10.08.2017 [18] Fast fluid dynamics simulation on the GPU, http://developer.download.nvidia.com/books/HTML/gpugems/gpugems_ch38.html, Consultat la 10.07.2017
33

DECLARAȚIE DE AUTENTICITATE A LUCRĂRII DE FINALIZARE A STUDIILOR Titlul lucrării: PROIECTAREA ȘI REALIZAREA UNEI APLICAȚII ANDROID NATIVE. Autorul lucrării: PIȚIȘ ANDREI-SERGIU Lucrarea de finalizare a studiilor este elaborată în vederea susținerii examenului de finalizare a studiilor organizat de către Facultatea de Inginerie Electrica și Tehnologia Informației din cadrul Universității din Oradea, sesiunea iulie 2014 a anului universitar 2013/2014. Prin prezenta, subsemnatul PIȚIȘ ANDREI-SERGIU, 1910623055081, declar pe proprie răspundere că această lucrare a fost scrisă de către mine, fără nici un ajutor neautorizat și că nici o parte a lucrării nu conține aplicații sau studii de caz publicate de alți autori. Declar, de asemenea, că în lucrare nu există idei, tabele, grafice, hârți sau alte surse folosite fără respectarea legii române și a convențiilor internaționale privind drepturile de autor. Oradea, Data Semnătura 34