CUDA. Jürgen Pröll. Multi-Core Architectures and Programming. Friedrich-Alexander-Universität Erlangen-Nürnberg Jürgen Pröll 1

Transkript

1 CUDA Jürgen Pröll Multi-Core Architectures and Programming Jürgen Pröll 1

2 Image-Resize: sequentiell resize() mit bilinearer Interpolation leicht zu parallelisieren, da einzelne Punkte voneinander unabhängig sind Jürgen Pröll 2

3 Image-Resize: Parallelisierungsansätze Verschiedene Parallelisierungsansätze: ein Thread pro Pixel - viele Threads (kann Grafikkarte voll ausreizen) - schlecht bei Datenabhängigkeiten ein Thread pro Zeile/Spalte - gut bei entsprechender Datenabhängigkeit ein Thread pro Block Jürgen Pröll 3

4 Hardware: CUDA-GPU aufgeteilt in Multiprozessoren (SM), die aus mehreren Cores (SP) bestehen pro Multiprozessor gibt es einen Shared Memory Jürgen Pröll 4

5 Image-Resize: Aufruf Ein Block in CUDA wird von einem Multiprozessor auf der Grafikkarte ausgeführt, Threads laufen auf den Cores Benutzte Grafikkarte: GeForce GTX Multiprozessoren mit je 8 Cores und maximal 512 Threads pro Block Kernel-Aufruf (ein Thread pro Pixel): Jürgen Pröll 5

6 Image-Resize: Implementierung Jürgen Pröll 6

7 Image-Resize: Ergebnis Die Größe des zu skalierenden Bildes beeinflusst die Geschwindigkeit nur gering, deswegen wird es bei diesem Test immer auf 1000x1000 gesetzt Größe CPU Thread pro Zeile Thread pro Pixel 10x10 0,01ms 0,047ms 0,018ms 50x50 0,051ms 0,115ms 0,028ms 100x100 0,219ms 0,191ms 0,033ms 1000x1000 9,667ms 1,295ms 0,183ms 5000x ,70ms 42,019ms 6,83ms 10000x ,92ms 157,377ms 34,787ms 15000x ,98ms 333,557ms 89,539ms Obwohl extrem viele Threads erzeugt werden (bei 15000x15000 insgesamt 225 Millionen Threads), geht eher der auf 1GB beschränkte Global Memory zu Neige, als dass zu viele Threads erzeugt werden Jürgen Pröll 7

8 Integralbild: sequentiell sequentieller Code (ohne zusätzliche Zeile/Spalte mit 0en) Sequentiell guter Algorithmus, aber aufgrund der Datenabhängigkeit parallel nicht gut nutzbar anderer Algorithmus benötigt Jürgen Pröll 8

9 Integralbild: parallel Neuer Algorithmus: Zuerst spaltenweise, dann zeilenweise aufsummieren besser parallelsierbar Jürgen Pröll 9

10 Integralbild: erste Implementierung integralcuda_x() ist äquivalent Jürgen Pröll 10

11 Integralbild: Speicherzugriff Bild liegt im globalen Speicher (für Kommunikation nötig) langsame Zugriffszeiten wie auf der CPU ist zeilenweises Lesen/Schreiben wesentlich schneller als spaltenweises da CUDA eine SIMT-Architektur ist, sind die Threads gleich schnell spaltenweises Lesen der Threads ist OK, zeilenweises nicht! Jürgen Pröll 11

12 Integralbild: Speicherzugriff Lösung: man kopiert einen Block spaltenweise vom langsamen Global Memory auf den schnellen Shared Memory liest zeilenweise vom Shared Memory und speichert Ergebnisse ebenfalls im Shared Memory und schreibt die Ergebnisse spaltenweise zurück ins Global Memory Jürgen Pröll 12

13 Integralbild: Speicherzugriff Jürgen Pröll 13

14 Integralbild: Shared Memory Der Shared Memory ist in 32 Bänke mit je 4 Byte aufgeteilt Nur ein Zugriff auf dieselbe Bank pro Taktzyklus möglich Konflikt, wenn mehrere Threads auf Daten derselben Bank zugreifen (beim Aufsummieren dauernd!) Jürgen Pröll 14

15 Integralbild: Shared Memory Ein simpler Trick löst das Problem: keine Zugriffskonflikte mehr Jürgen Pröll 15

16 Integralbild: Ergebnis Jürgen Pröll 16

17 Integralbild: Ergebnis Sprünge der CPU-Kurve an den Stellen k1024+1: Caching-Effekte? Spitzen bei der CUDA-Kurve: durch Alignmenteffekte entstehen die schnelleren Zeitwerte bei Vielfachen von 512 Stufen bei den speicheroptimierten Varianten: Shared Memory ist auf 16KB begrenzt es können keine 2 Blöcke gleichzeitig von einem Multiprozessor bearbeitet werden, da diese mehr Speicher benötigen würden als vorhanden ist Sequentialisierung: sobald alle Multiprozessoren arbeiten, muss ein zusätzlicher Block warten, bis ein Anderer fertig wird (bei Vielfachen von 960 arbeitenden Threads) Jürgen Pröll 17

18 Vergleich unterschiedlicher Hardware codesigns30: Capability Version 1.1 (GeForce 8800 GTS 512 ) schlechtes Alignment-Verhalten codesigns43: Capability Version 1.3 (GeForce GTX 285) codesigns46: Capability Version 2.0 (3 Grafikkarten) da hier mehrere Karten initialisiert werden müssen, ist die Startzeit extrem hoch und daher für Viola-Jones unrentabel Bestes Alignmentverhalten Zusätzlich Caches für den Global Memory (bei Viola-Jones nicht gut nutzbar) Jürgen Pröll 18

19 19

20 Facedetect Die einzelnen Rechtecke, über die die Kaskaden laufen, lassen sich gut parallel ausführen aber: die Datenstruktur MAPClassifierCascade muss komplett auf die Grafikkarte kopiert werden, damit sie dort verfügbar ist (Pointer darin werden ungültig!) Da Vektoren nicht auf CUDA laufen, müssen die Ergebnisse anders an die CPU zurückgegeben werden - Über Booleanarray gelöst, in das CUDA Treffer schreibt; die Position im Bild kann aus der Position im Array berechnet werden Jürgen Pröll 20

21 Endergebnis Endergebnis stimmt in etwa, nur einzelne Ausreißer und Absturz bei anderen Bilddateien noch Fehler im Code (z.b. Threads schreiben in falsche Zellen) Jürgen Pröll 21

22 Endergebnis Zeit im Vergleich zur Referenzimplementierung: Referenzimplementierung: ca. 300ms CUDA-Implementierung: ca. 400ms Kein Speed-Up, aber: Speed-Up bei größeren Dateien größer weitere Optimierungen möglich (Code an sich oder speziell für gegebene Hardware) Jürgen Pröll 22

23 Noch Fragen? Jürgen Pröll 23