GPU Architektur CUDA - OpenCL

Transkript

1 GPU Architektur und Programmiermöglichkeiten für GPGPU-Anwendungen kernel void matsq( global const float *mat, global float *out ) { int dim = get_global_size(0); //Matrix dimension int i = get_global_id(0); //index 1 int k = get_global_id(1); //index 2 float val = 0; for( int l = 0; l < dim; l++ ) val += mat[dim*i+l] * mat[dim*l+k]; } out[dim*i+k] = val; GPU Architektur CUDA - OpenCL 1

2 Inhalt Motivation GPU Architektur CUDA und OpenCL Grundlegendes Prozessmodell Parallelisierung Speicherhierarchie (Inter-Thread) Synchronisation und Kommunikation Einschub: Inline PTX Assembler bei CUDA Vergleich zwischen CUDA und OpenCL (Codebeispiele) 3

3 Motivation CPU vs. GPU Anzahl Cores Core i7-3930k: 6 HD 7970: 2048 GTX 680: 1536 FLOPS (single-precision) Core i7-3930k: 307 GFLOPS HD 7970: 3789 GFLOPS GTX 680: 3090 GFLOPS Pentium 4 3,2 GHz: 6,4 GFLOPS Speicherbandbreite DDR3-2133: 17 GB/s HD 7970: 264 GB/s 4

4 Wenn GPUs so schnell sind Warum ersetzen wir nicht unsere CPU durch eine GPU? Fundamental andere Aufgabenfelder GPUs sind gut im Number Crunching aber nicht so flexibel wie CPUs GPUs sind immer noch aufgabenspezifische Hardware Algorithmen müssen sich parallelisieren lassen Bei sequentiellen Alg. ist die CPU (viel) besser CPUs implementieren Virtualisierung, Virtuellen Speicher, Branch-Prediction usw. GPUs kommen mit Branches nicht gut klar 5

5 GPU Architektur Eine GPU ist ein massiver Parallelrechner Aktuelle Modelle: Über 2000 Kerne Aber: Kerne im Gegensatz zur CPU nicht vollwertig Teilen sich viele Einheiten, wie z.b. Caches Ist auf Stream-Verarbeitung ausgelegt Ideal: großer Datenstrom auf dem einfache, lineare Berechnungen parallel ausgeführt werden 8

6 Gliederung einer GPU Die Hardware lässt sich grob in 4 Bereiche einteilen: Hauptspeicher Rechenkerne Auch Shadereinheiten genannt Caches Aufgabenspezifische Hardware 9

7 Hauptspeicher Rechenkerne Caches Aufgabenspez. Hardware Gliederung einer GPU - Hauptspeicher Aufbewahrungsort für die zur Berechnung benötigten Daten Große Kapazität (mehrere Gigabyte) Große Bandbreite (z.b. HD 7970: 264 GB/s) Aber: Große Zugriffslatenz (teils mehrere 100 Zyklen) Nicht geeignet als temporärer Zwischenspeicher 10

8 Hauptspeicher Rechenkerne Caches Aufgabenspez. Hardware Gliederung einer GPU - Rechenkerne Aus dem Kontext der Computergrafik auch Shadereinheiten genannt Einfache, skalare Gleitkommaprozessoren Werden zu Gruppen zusammengefasst Teilen sich innerhalb einer Gruppe z.b. Integer, Branching oder Textureinheiten, häufig auch Register Im Gegensatz zu CPU keinesfalls ein vollwertiger Kern 11

9 Hauptspeicher Rechenkerne Caches Aufgabenspez. Hardware Gliederung einer GPU - Caches Im Gegensatz zur CPU extrem klein (im Kilobyte-Bereich) Anzahl viel kleiner als bei einer CPU Häufig kein L3- sondern nur ein geteilter L2-Cache, Kerne innerhalb einer Gruppe teilen sich einen L1- Cache 12

10 Hauptspeicher Rechenkerne Caches Aufgabenspez. Hardware Gliederung einer GPU Aufgabenspezifische Hardware Nicht programmierbar Übernehmen allgemeine Managementaufgaben oder vorgeschriebene Schritte der Grafikpipeline Cache-Controller, Bus-Interfaces, Texturfilter, Rasterisierung, etc. Besonderheit: (Thread-) Scheduling ebenfalls in Hardware implementiert Sehr schnell 13

11 Wie kann eine GPU Programmiert werden? Vorstellung zweier Technologien 14

12 NVIDIA CUDA (Compute Unified Device Architecture) Proprietärer Standard von NVIDIA Speziell für GPUs entwickelt Läuft nur auf NVIDIA Hardware CUDA SDK für Windows, Linux, Mac OS X Sprache: C for CUDA C mit speziellen Erweiterungen (neue Schlüsselwörter und Datentypen) Ist häufig minimal schneller als der OpenCL-Gegenpart da spezialisiert auf NVIDIA Hardware GPU-Unterstützung: ab der G8x-Serie, inklusive der Linien GeForce, Quadro und Tesla 15

13 Ursprünglich von Apple entwickelt OpenCL (Open Computing Language) Offener Standard, wird heute von der Khronos Group verwaltet (die auch den OpenGL Standard verwaltet) OpenCL ist nur ein Standard In der Regel erstellen die Hardware-Hersteller die konkrete Implementierung für ihre Geräte Ist nicht beschränkt auf GPUs, läuft auf allem sofern eine standardkonforme Implementierung existiert Implementierungen von AMD, NVIDIA, Sony(Cell), Intel (x86) etc. AMD und NVIDIA liefern ihre Implementierung mit dem Grafikkartentreiber aus (Windows: OpenCL.dll) Sprache: OpenCL C C mit speziellen Erweiterungen (neue Schlüsselwörter und Datentypen) GPU-Unterstützung: AMD: ab DirectX 11 Grafikkarten (HD 5xxx, ATI FirePro Vx800) NVIDIA: Nvidia Tesla C/D/S, Nvidia GeForce GTS/GT/GTX, Nvidia Ion, Nvidia Quadro FX/NVX/Plex 16

14 Prozessmodell Das einfachste Prozessmodell umfasst vier Schritte: 1. Daten vom Hauptspeicher des Host-Rechners in den Hauptspeicher der Grafikkarte kopiert 2. Die CPU beauftragt GPU mit der Berechnung 3. Die GPU führt das Programm parallel in CUDA Threads / Work Items aus 4. Das Resultat wird zur Weiterverarbeitung bzw. Auswertung aus dem Hauptspeicher der Grafikkarte zurück in den Hauptspeicher des Host-Rechners übertragen 17

15 Parallelisierung unter OpenCL und CUDA Problem wird in Teilprobleme aufgeteilt (Work Item, CUDA Thread) Aufteilung kann in 1, 2 oder 3 Dimensionen erfolgen Für jedes Teilproblem wird das selbe Programm bzw. der selbe Code bzw. der selbe Kernel ausgeführt Jeder Kernel wird in einem eigenen Thread ausgeführt Threads (bzw. Kernel) werden auf die (Shader-)Cores der GPU aufgeteilt Teilprobleme werden zu Gruppen zusammengefasst (Work Group, CUDA Thread Block) Jede Kernel-Instanz (Thread) kann hat Zugriff auf die Problemgröße, Gruppengröße und ihre Position innerhalb des Problems und innerhalb der Gruppe Thread-Instanz weis so auf welchen Daten sie operieren soll 18

16 Aufteilung in Teilprobleme und Teilproblemgruppen 1-Dimensionale Aufteilung: Problem Größe: Gruppe mit der ID 0 Größe: 4 Thread/Kernel mit der ID 11 Bei CUDA ist die ID relativ zur Gruppe und nicht zum globalen Problem, ID wäre dann 3* *Bei CUDA kann die globale ID ausgerechnet werden: blockidx.x*blockdim.x + threadidx.x 19

17 Aufteilung in Teilprobleme und Teilproblemgruppen 2-Dimensionale Aufteilung: Problemgröße: 8x8 Gruppengröße: 4x4 0,0 1,0 2,0 3,0 4,0 5,0 6,0 7,0 0,1 1,1 2,1 3,1 4,1 5,1 6,1 7,1 0,2 1,2 2,2 3,2 4,2 5,2 6,2 7,2 0,3 1,3 2,3 3,3 4,3 5,3 6,3 7,3 0,4 1,4 2,4 3,4 4,4 5,4 6,4 7,4 0,5 1,5 2,5 3,5 4,5 5,5 6,5 7,5 Thread/Kernel mit der ID 7,2 (CUDA: 3,2) Gruppen-Ids: 0,0 1,0 0,1 1,1 0,6 1,6 2,6 3,6 4,6 5,6 6,6 7,6 0,7 1,7 2,7 3,7 4,7 5,7 6,7 7,7 3-Dimensionale Aufteilung analog 20

18 Speicherhierarchie OpenCL CUDA Beschreibung Zugriff Typ. Größe host global constant local private host global constant shared registers Speicher des Host- Programms, also der normale Arbeitsspeicher des PCs Hauptspeicher der Grafikkarte Kann nur von Host-Programm geschrieben werden, für Kernel read-only Kleiner, schneller Speicher welcher für jede Thread- Gruppe existiert Noch kleinerer, noch schnellerer Speicher welcher für jeden Thread existiert Nur Host- Programm Jede Kernel- Instanz/ jeder Thread Jede Kernel- Instanz/jeder Thread Nur jeweils eine Thread-Gruppe Nur einzelner Thread Zugriffszeiten: global: ca Zyklen, local/shared: ~5 Zyklen 2-16 GB 1-8 GB 64 kb kb 16 kb Geschwindigkeit Größe 21

19 Speicherhierarchie (2) Host host Device (Grafikkarte) PCIe: 8-16 GB/s (global: bis 260 GB/s) global und constant Work-Group / CUDA Thread Block local / shared Work-Group / CUDA Thread Block local / shared Work-item / CUDA-Thread Work-item / CUDA-Thread Work-item / CUDA-Thread Work-item / CUDA-Thread Work-item / CUDA-Thread Work-item / CUDA-Thread private / registers private / registers private / registers private / registers private / registers private / registers 22

20 Warum diese Unterteilung in Threadgruppen und warum diese komplizierte Speicherhierarchie? (Geometrisch) nah beieinander liegende Threads sollen auf Daten mit nah beieinanderliegenden Speicheradressen operieren So wird Nutzen aus den kleinen Caches gezogen Speicherhierarchie minimiert den Einfluss der großen Latenz des Hauptspeichers Kommunikation zwischen Threads ist (innerhalb einer Gruppe) ohne Umwege über den Hauptspeicher möglich 23

21 Synchronisation und Kommunikation zwischen Threads Kommunikation Synchronisation Threads der selben Gruppe local/shared Speicher oder (viel langsamer) globaler Speicher CUDA: synchthreads() threadfence() OpenCL: barrier(clk_local_mem_fence) barrier(clk_global_mem_fence) Threads unterschiedlicher Gruppen Ausschließlich über globalen Speicher Nur über Host-Programm Kommunikation zwischen Threads schwierig Synchronisation fast nur innerhalb einer Threadgruppe möglich nur memory-barriers, keine critical sections, mutexes o. Ä.! Falls möglich vermeiden! 24

22 Wie können GPUs Millionen Threads handhaben? Threads sind nicht vollwertig Eingeschränkte Synchronisation und Kommunikation Keine Critical Sections usw. Thread Verwaltung und Scheduling ist in dedizierter Hardware implementiert Kontextwechsel sind Hardware-Implementiert und daher sehr schnell Häufig Kontextwechsel bei (GPU-)Speicher-Anfragen: Thread wird schlafen gelegt bis die Daten da sind Ein anderer Thread kann in der Zeit den Prozessor nutzen 25

23 Einschub: Inline PTX Assembler bei CUDA PTX (Parallel Thread Execution) Assembly ist CUDA s interne Assemblersprache Compiler (nvcc) erstellt PTX-Assembly Lässt sich durch Inline PTX-Assembly auch in CUDA C nutzen Syntax: asm("template-string" : "constraint"(output) : "constraint"(input)); Template-String enthält PTX-Befehl und Platzhalter für die Ein- bzw. Ausgabeparameter Constraints enthalten (im wesentlichen Größen-) Beschränkungen der Ein- bzw. Ausgabeparameter Gleichheitszeichen vor dem Constraint kennzeichnet geschriebene Parameter Durch Kommas abgetrennt können mehrere Ein- bzw. Ausgaben definiert werden Platzhalter für Ein- und Ausgaben können mehrfach verwendet werden Beispiel: int i; int j = 5; int k = 5; asm("add.s32 %0, %1, %2;" : "=r"(i) : "r"(j), "r"(k)); //i is now 10 26

24 CUDA: Inline PTX-Assembler (Forts.) Längeres Beispiel mit mehrfacher Nutzung der Platzhalter device int cube(int x) //calculate x^3 { int y; asm(".reg.u32 t1;" // temporal register t1 "mul.lo.u32 t1, %1, %1;" // t1 = x * x "mul.lo.u32 %0, t1, %1;" // y = t1 * x : "=r"(y) : "r"(x) ); // output : y, input : x return y; } Anweisungszeilen werden mittels der normalen C/C++ String-Syntax aneinander gereiht Demonstratives Beispiel return x*x*x; währe einfacher gewesen und erzeugt vermutlich besseren Code 27

25 Vergleich zwischen OpenCL und CUDA CUDA ist beschränkt auf GPGPU-Anwendungen auf Hardware von NVIDIA + Dokumentation, Tools und Framework greifen nahtlos ineinander + Gute Optimierungsmöglichkeiten, da Hardwarenah (z.b. Inline PTX) + Neue Möglichkeiten der Hardware zeitnah verwendbar (häufig neue CUDA-Version vor Veröffentlichung der zugehörigen Hardware) Abhängigkeit OpenCL ist ein offener und viel universeller einsetzbarer Standard für Berechnungen auf Parallelrechnern + Universalität + Unabhängigkeit ± Abstraktion der Hardware Performance geringer Lange Versionsintervalle Herstellereigene Erweiterungen sind zwar zeitnah verfügbar, aber Unabhängigkeit geht verloren 28

26 Vergleich der Performance zw. OpenCL und CUDA Messergebnisse basierend auf dem Paper A Performance Comparison of CUDA and OpenCL von K. Karimi, N. Dickson und F. Hamze Autoren nutzen eine wissenschaftliche Applikation (AQUA), welche ein Quanten-Spin-System simuliert Die existierende CUDA-Implementierung wurde nach OpenCL portiert Kernel: semi-automatische Generierung Host-Code: größtenteils neu geschrieben Unterschiedliche Laufzeiten resultieren im Wesentlichen aus dem zugrunde liegenden Framework Gemessen wurden: Laufzeit der Kernel (d.h. rein zur Berechnung benötigte Zeit) Zeit für Speichertransfers Laufzeit der GPU-Anwendung (d.h. im Wesentlichen die Summe der gerade genannten Punkte) Gesamtlaufzeit inklusive Setup, Erkennung der GPU, Kompilierung der Kernel, etc. 29

27 Vergleich der Performance zw. OpenCL und CUDA Von OpenCL zusätzlich benötigte Zeit in Prozent Zeit OpenCL Zeit CUDA 1 Qubits (Problemgröße) Kernellaufzeit Datentransfer GPU-Laufzeit Gesamtlaufzeit 8 13,8 22,2 13,7 45, ,9 53,3 22,7 38, , ,4 26, , ,7 50, ,6 37,7 62,5 67, ,8 36,7 17,9 21, ,7 36,3 12,7 15,7 Durchschnitt 27,5 40,5 27,4 37,9 30

28 Vergleich der Performance zw. OpenCL und CUDA Messungen nur bedingt aussagekräftig Nur eine spezielle Anwendung Veraltete CUDA-Version (2.3, Juli 2009) Veraltete Hardware (NVIDIA GTX 260) Heutiger Unterschied könnte anders Ausfallen (in beide Richtungen) Trotzdem: Eindeutiger Trend erkennbar OpenCL wird vermutlich immer etwas langsamer sein als CUDA 31

29 Danke für Ihre Aufmerksamkeit! Fragen? 33

30 Beispielprogramm: Matrix-Quadrierung einer quadratischen Matrix Normaler C-Code nach Schulmethode (mit 1-Dimensionalem Array implementiert): void matsq( int dim, const float *mat, float *out ) { for(int i = 0; i < dim; i++) { for(int k = 0; k < dim; k++) { float val = 0; for(int l = 0; l < dim; l++) val += mat[dim*i+l] * mat[dim*l+k]; out[dim*i+k] = val; } } } 2-Dimensionales Problem Äußere Schleifen iterieren über alle Einträge der Ergebnis-Matrix und berechnen das Element der Stelle i,k Berechnung des Eintrags i,k ist unabhängig von anderen Elementen der Zielmatrix Berechnung der Einträge kann massiv parallel erfolgen Kernel schreiben der genau einen Eintrag der Zielmatrix berechnet, und für alle Einträge der Zielmatrix einmal ausgeführt wird 34

31 Aufteilung der Matrix-Quadrierung Jeder Thread berechnet genau einen Eintrag der Ergebnis-Matrix 2-Dimensionales Problem Problemgröße: n, n bei einer n n Matrix Threads werden zu 2-Dimensionalen Gruppen hinzugefügt Aufteilung prinzipiell willkürlich, keine Anforderungen an lokalen Speicher, Synchronisation usw. Aber: Gruppen können nicht beliebig groß sein, es gibt eine Maximalausdehnung auf jeder Achse und eine maximale Gesamtanzahl an Threads Beispiel: 8x8 = 64 Threads pro Gruppe 35

32 Wie sieht der Kernel aus? OpenCL C: C for CUDA: kernel void matsq( global const float *mat, global float *out ) { int dim = get_global_size(0); //Matrix dimension int i = get_global_id(0); //index 1 int k = get_global_id(1); //index 2 float val = 0; for( int l = 0; l < dim; l++ ) val += mat[dim*i+l] * mat[dim*l+k]; global void matsq( const float *mat, float *out ) { int dim = griddim.x * blockdim.x; int i = blockidx.x * blockdim.x + threadidx.x; int k = blockidx.y * blockdim.x + threadidx.y; float val = 0; for( int l = 0; l < dim; l++ ) val += mat[dim*i+l] * mat[dim*l+k]; } out[dim*i+k] = val; } out[dim*i+k] = val; Keine äußeren for-schleifen mehr, da der Kernel von OpenCL bzw. CUDA für jeden Eintrag der Matrix ausgeführt wird. Vor der Ausführung muss im Host-Programm die Dimension und die Größe des Problems bzw. der Matrix festgelegt werden. 36

33 Wie sieht das Host-Programm aus? (C/C++, OpenCL) Initialisierung: 37

34 Wie sieht das Host-Programm aus? Initialisierung (2): (C/C++, OpenCL) 38

35 Wie sieht das Host-Programm aus? (C/C++, OpenCL) Ausführung und Aufräumen 39

36 Matrix-Quadrierung Vorführung Sourcecode: redpuma.funpic.de/opencl-helloworld.zip 40

37 Weitere Optimierungen Bisheriger Kernel ist naiv Mögliche Optimierungen: Benutzung des local/shared Speichers Benutzung von float8, float16 usw. Benutzung der Texture-Caches Beispielhaft optimierter Kernel ist ca. 6 mal schneller als naive Lösung Optimierter Kernel ist im Sourcecode enthalten, siehe matsq.cl 41

38 GPU-Aufbau (Beispiel: HD 7970) Compute Unit (CU) Raster-Back-Ends bestehend aus mehreren ROPs (Raster Operation Processor) 16 kb Instruction Cache 32 kb Scalar Data Cache (768 kb) Bild: Advanced Micro Devices, Inc. (AMD) 3 GB Main Memory 42

39 GPU-Aufbau (Beispiel: HD7970) Bilder: Advanced Micro Devices, Inc. (AMD) 43