GPU Lab. 15. fejezet. Nehezen párhuzamosítható szimulációk. Grafikus Processzorok Tudományos Célú Programozása. Berényi Dániel Nagy-Egri Máté Ferenc

Méret: px

Mutatás kezdődik a ... oldaltól:

Download "GPU Lab. 15. fejezet. Nehezen párhuzamosítható szimulációk. Grafikus Processzorok Tudományos Célú Programozása. Berényi Dániel Nagy-Egri Máté Ferenc"

Lili Barta
6 évvel ezelőtt
Látták:

1 15. fejezet Nehezen párhuzamosítható szimulációk Grafikus Processzorok Tudományos Célú Programozása

2 Jól párhuzamosítható szimulációk Ha megnézzük az eddigi példákat (valamint a beadandókat) akkor a következőt látjuk: A feladatok vagy triviálisan párhuzamosak: Semmi kölcsönhatás az elemek között Előre tudható az indítandó szálak száma Előre tudható a bemenet, kimenet mérete, azaz Minden memóriát előre le tudunk foglalni Ez lefedi kb. a következő feladatokat: Lineáris algebra Fix méretű rácsos szimulációk (életjáték, Ising jellegű szim., PDE-k) ODE rendszerek, ha csak a végeredményre vagyunk kíváncsiak

3 Rosszul párhuzamosítható szimulációk Mi történik, ha nem tudjuk előre, hány szál lesz, illetve időnként nagyon kevés van belőlük? Tipikus példa: reduce: Pl.: Hosszú adatsor felösszegzése Háromszög jellegű Mátrix manipulációk pl.: Gauss elim, LU-dekomp. Amikor fogy az adathalmaz mérete, egyre kevesebb szál indítható, és egy pont után a GPU jó része nem kap feladatot, a kevés szál egyre kevésbé hatékonyan tud dolgozni Amit lehet tenni, hogy amikor már relatíve kevés az adat, akkor CPU-n végezni a reduce végét. for(int i=0; i<n; i++) { for(int j=0; j<i; j++) { A[i][j] =... } }

4 Rosszul párhuzamosítható szimulációk Mi történik, ha a kódunk egészen változatos lefutású lehet különböző paraméterek esetén? Tipikus eset: Hosszú program sok if-el és/vagy switch-el Példa: Adaptív Runge-Kutta A szálak közötti divergencia jelentősen rontja a teljesítményt Mit lehet tenni? Ha legalább workgroup szinten csoportosítani tudjuk a szálakat (pl. közösen számolják a hibát

5 Rosszul párhuzamosítható szimulációk Mi történik, ha nagyon sok a kölcsönhatás? Tipikus példa: nem-determinisztikus reduce (futás idejű értéktől függő döntést kell hozni) Adatsor hisztogramozása Monte-Carlo beütések regisztrálása Sok szál akar viszonylag kevés változót, de random access! Az eredmény: rengeteg írás ütközés és/vagy várakozások Ha sokat kell szinkronizálni, akkor az a teljesítmény rovására megy.

transzformáció A rendezetlen (nem-koaleszkált)

6 Rosszul párhuzamosítható szimulációk Mi történik, ha nem rendezett az írás-olvasás: Tipikus példa: Fourier transzformáció A rendezetlen (nem-koaleszkált) írások-olvasások drasztikusan csökkentik a memória elérés sebességét

7 Rosszul párhuzamosítható szimulációk Mi történik, ha nem tudjuk előre az adatok méretét?! Ez a legjobban fájó pont! Nincs dinamikus memória allokálás (kiv. CUDA) De semmiképpen nem hatékony (geometry shadert sem használja senki ) Kicsit részletesebben megnézünk két példát: Raytrace és Particle Transport

8 Raytrace Számolnivaló: A render egyenlet megoldása Monte-Carlo integrálással Teljes megvilágítottság Emisszió Félgömb irányintegrál a bejövő sugarakra Kétirányú visszaverést leíró függvény (BRDF) Bejövő megvilágítottság A beesési szög miatti gyengülés

Végrehajtani a programot Eldönteni, hogy milyen irányba hány új sugarat

9 Raytrace Számolnivaló: A kamerából sugarakat indítani Megkeresni a legközelebbi metszett felületet Betölteni a shadert + textúrákat Végrehajtani a programot Eldönteni, hogy milyen irányba hány új sugarat kell indítani Mindezt ismételni, amíg a Kép elég jó nem lesz (Monte-Carlo zaj csökkentése)

10 Raytrace Mi a baj? -minden! A sugarak divergensek, nem igazán lehet tudni, mibe fognak ütközni, sőt, egyre több lesz belőlük, de nem lehet tudni mennyi A textúrák nem férnek bele a memóriába, állandóan ki-be kell töltögetni őket A shadereket vagy egy nagy kezelhetetlenül bonyolult shaderbe írják elágazásokkal switchekkel stb-vel vagy Rengeteg apró shadert használnak, amiket megint ki-be kell töltögetni

11 Raytrace Mi a baj? Az egész logikai örökség eleve CPU terhelt. A legtöbb filmet még mindig CPU-s renderfarmokon számolják ( és a szomszéd lakótelepet és az irodákat fűtik a hőjével )

12 Raytrace Mit lehet tenni? Csoportosítás! Ha össze lehetne szedni elég sok részecskét, amiknek ugyan az a shader és textúra kell, akkor lehet növelni a hatékonyságot Ray-packeting: Akár azonos irányba tartás, Akár Material access alapján lehet őket csoportokba gyűjteni

13 Raytrace Mit lehet tenni? Gyorsító struktúrák a metszéspont megtalálás hatékonyabbá tételére. Valamilyen fastruktúra célszerű Általában az iparban a Bounding Volume Hierarchy használt.

14 Particle transport Az alapprobléma: A nagyenergiás fizikában, orvostudományokban sokszor szükség van az elemi részecskék anyaggal való kölcsönhatásának modellezésére, főleg azért, hogy a detektorok viselkedését, szisztematikus hibáit előre meg lehessen határozni Példák: LHC és más gyorsítók kísérleteiben a különböző fizikai elveken működő detektorok megértése, és a bennük mért adatokból az elemi részecskék pályáinak rekonstruálása Sugárterápiás, Tomográfiás rendszerek tervezése, a mérésekből a rendellenes területek meghatározása

15 Particle transport

16 Pozitron Emissziós Tomográfia

17 Particle transport Mi a gond? Szinte minden, mint a raytrace-nél! Nem lehet tudni előre, hány részecske keletkezik, mert bomlanak, vagy keltődnek Nem lehet tudni merre mennek, mert kanyarodnak a mágneses térben, szóródnak az anyagon, bomlásnál szétrepülnek. Mindezek bonyolultan függnek a részecskék paramétereitől A detektorok helyenként μm-es felbontással vannak modellezve hatalmas méretű geometria A fizikai kölcsönhatásokból rengeteg van, ezeknek a valószínűségei sokszor csak táblázatosan érhetőek el, ez is hatalmas adathalmaz!

18 Particle transport Geant4 fizikai modellek: Elektromágneses (ionizáció, fékezési sug., fotoelektromos eff., párkeltés, szórás, annihiláció, Hadronikus (reakciós hatáskeresztmetszetek, abszorpció, befogás, rugalmasrugalmatlan szórások, hasadás) Bomlások (mindenr észecske lényegében minden bomlási csatornájára) Fotolepton-Hadron (gamma, lepton, neutrínó indukált folyamatok) Optikai (hullámjelenségek, Cherenkov, különböző felületekkel való kölcsönhatás, hullámhossz eltolódás, szintilláció)

19 Particle transport Megoldások: hasonlóak, mint a raytrace-nél: Csoportosítás: azonos, vagy ugyanarra menő részecskék: basketekbe tétele Nagyon okos scheduler, aki váltogat a basketek között, hogy melyik hozzátartozó adatok érhetőek éppen el, melyik szálak számoljanak Néha 1-1 részecskénél a csoportosított változat lassabb az overhead miatt, ekkor single particle transport. A leghatékonyabban mintavételezhető tárolása a fizikai folyamatoknak (tabuláció+interpoláció vs parametrizáció/fit). Hierarchikus geometriai modell

20 Tanulság Ezek a problémák lehetetlenül bonyolultnak és párhuzamosíthatatlannak tűnnek Mégis rengetegen dolgoznak azon, hogy megírják hatékonyan GPU-kra őket Az alap trükk a tarsolyban a hierarchikus probléma feldarabolás és tárolás (oszd meg és uralkodj) illetve a megfelelő csoportosítása az erőforrásoknak, illetve az erőforrásokat használó részeknek

Hasonló dokumentumok

A Geant4 használatának alapjai

A Geant4 használatának alapjai Bíró Gábor A tommag és N e h é z i o n fi z i k a i T éli I skola 2016. február 2-3. Tartalom Bevezetés Részecsketranszport szimulációk Geant4 alapok Történet Működési alapok