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

Größe: px

Ab Seite anzeigen:

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

Julius Brahms
vor 7 Jahren
Abrufe

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

2 Warum Tesla? Traditionelle Graphikkarten Getrennte Prozessoren für Vertex- / Pixelberechnungen - Nachteil: es werden mehr Pixel- als Vertexberechnungen benötigt Keine gute Lastbalance Unterstützen Pipelining Tesla-Architektur Graphikkarten Allgemeine Prozessoren (frei programmierbar mit CUDA) SIMT (Single Instruction Multiple Thread)-Architektur Hohe Skalierbarkeit Axel Jena, Jürgen Pröll 2

3 Geschichte und Leistungsdaten Erste Tesla-Graphikkarte im November 2006 (GeForce 8800) mit 128 Streaming-Prozessoren Nächste Generation der Tesla-Architektur: Fermi Leistungsdatenvergleich: Intel Core i7 980 Nvidia Tesla C2050 Flops 107,55 G 515 G Taktrate 3,3 GHz 600 MHz Leistung 130 W 238 W Kerne Axel Jena, Jürgen Pröll 3

4 Befehlsabarbeitung Skalierbar -128 Streaming Prozessoren - Organisiert in 16 Streaming Multiprozessoren - Aufgeteilt in 8 unabhängige Textur/Prozessor Clusters Axel Jena, Jürgen Pröll 4

5 Texture/Processor Cluster Die TPC rechnen unabhängig voneinander. Der Geometry Controller bildet die Berechnungen auf die SMs (Streaming Multiprocessors) ab. SMC Verbindung der SMs mit der Textur-Unit zur Textur Erzeugung und Filterung (z.b. Anisotropie Filterung) Steuert Lastbalance Axel Jena, Jürgen Pröll 5

6 Streaming Multiprocessor Besteht aus: 8 Streaming Prozessoren (SP) 2 Special Function Units (SFU) Multithreaded Instruction Fetch and Issue Unit (MT issue) Instruction Cache (I cache) Read only Cache 16KB read/write Shared Memory (evtl. DP-Prozessoren (Double Precision) ) Die SMs unterstützen massives Multithreading (bis zu 768 Threads pro SM, ohne scheduling Overhead, SIMT- Architektur) Das Shared Memory hält die Daten für die parallelen Berechnungen. Die SFUs werden für komplexe Berechnungen verwendet Die SPs werden für die fundamentalen Berechnungen verwendet (Add, Mult ) Axel Jena, Jürgen Pröll 6

7 Streaming Multiprocessor: SIMT Die Streaming Multiprozessoren bilden Thread-Gruppen von 32 Threads pro Gruppe (= 1 Warp) Jeder SM kann 24 Warps behandeln. Die SM arbeiten mit der SIMT-Architektur (Single Instruktion Multiple Thread) ähnlich SIMD. Jeder Befehl wird mit Hilfe von Pipelining berarbeitet. Jede konditionelle Abzweigung (Pfade) im Code (IF s) werden getrennt parallel ausgewertet. Sobald klar ist, welcher Pfad die Richtige ist werden die anderen verworfen. Die SMs arbeiten ansonsten mit einem Register basierendem Befehlssatz. (floating-point, integer, bit, flow control, memory load/store, texture operations) Axel Jena, Jürgen Pröll 7

8 Raster Operations Processor Können direkt auf dem Speicher arbeiten. Zu jedem Speicherbaustein gehört ein eigenes ROP. Können Daten von den TPCs erhalten. Kümmern sich u. A. um: Farbüberblendungen. Antialiasing. Interpolation. Können nicht mit CUDA verwendet werden. Axel Jena, Jürgen Pröll 8

9 Speicher und Kommunikation Der Datenbus für die Kommunikation ( Interconenction Network ) ist 384 Pins breit und in 6 Partitionen a 64 Pins gegliedert. Jede Partition verwaltet 1/6 des gesamten physikalischen Adressraums. Das Interconenction Network basiert auf einer Hub-Unit die die die Anfragen zwischen den verschiedenen Komponenten (PCIe-Bus, TPCs, DRAM) routet. Die ROPs sind direkt an den Speicher angebunden und belasten damit nicht das Interconnection Network. Eine Memory Management Unit setzt virtuelle zu physikalischen Adressen um und kümmert sich um Paging. Als Speicher fungieren GDDR3 Module die mit ca. 1GHz getaktet sind. Axel Jena, Jürgen Pröll 9

10 CUDA Programming Model Serieller Code in einem Thread des Hosts (CPU) Paralleler Code verteilt auf viele Threads im Device (GPU) Kernel: vom Host aufgerufene Funktion, die auf dem Device von vielen Threads ausgeführt wird Axel Jena, Jürgen Pröll 10

11 Thread Hierarchy Ein Kernel wird von einem Grid ausgeführt Ein Grid besteht aus in Blöcken gruppierten Threads Alle Threads des Grids: Führen den selben Code aus Sind durch Thread ID und Block ID unterscheidbar Jeder Block wird, in SIMT Warps geteilt, von einem Streaming Multiprozessor (SM) ausgeführt Axel Jena, Jürgen Pröll 11

12 Memory Hierarchy Local Memory: jeder Thread hat Register, um temporäre Variablen zu speichern sind diese nicht ausreichend, hat er zusätzlich noch einen Local Memory für größere Dateien Shared Memory: gemeinsamer Speicher für Threads desselben Blockes Global Memory: zur Kommunikation unter sequentiell ablaufenden Grids Axel Jena, Jürgen Pröll 12

13 Transparente Skalierbarkeit Thread Blöcke sind voneinander unabhängig, weshalb sie auch in beliebiger Reihenfolge ausgeführt werden können Programmierer müssen nicht auf Hardware achten, da sich ein Grid beliebig auf vorhandene Ressourcen verteilt Axel Jena, Jürgen Pröll 13

14 Kompilierung NVCC teilt Code in seriellen und parallelen Teil PTX Code (Parallel Thread Execution): Pseudoassembler für Grafikkarten Host und Device Code werden anschließend zu einer ausführbaren Datei zusammen gelinkt Axel Jena, Jürgen Pröll 14

15 CUDA API: Extended C Minimale Erweiterungen zu C/C++ Durch Wrapper auch andere Programmiersprachen nutzbar Language Extensions Function Type Qualifiers Variable Type Qualifiers Built-in Variablen Runtime Library Common Component Device Component Host Component Axel Jena, Jürgen Pröll 15

16 Function Type Qualifiers global void KernelFunc(): wird vom Host aufgerufen und auf dem Device ausgeführt muss void sein device float DeviceFunc(): wird vom Device aufgerufen und ausgeführt host float HostFunc(): wird auf dem Host aufgerufen und ausgeführt (optional) Funktionen auf dem Device: keine Rekursion keine statischen Variablen keine variable Argumentenliste KernelFunc<<<grid,block>>>(args); grid: Dimension des Grids (1D oder 2D) block: Dimension eines Blocks (1D, 2D oder 3D) Axel Jena, Jürgen Pröll 16

17 Variable Type Qualifiers device int GlobalVar; im Global Memory bleibt über die gesamte Programmausführung bestehen sichtbar für alle Threads und für den Host über die Runtime Library constant int ConstantVar; im Constant Memory Lebensdauer und Verfügbarkeit wie bei device shared int SharedVar; im Shared Memory eines Thread Blocks an Lebensdauer des Thread Blocks gebunden ist nur für Threads innerhalb des Blocks sichtbar int LocalVar; (innerhalb einer Device-Funktion) in einem Register oder bei großen Daten im Local Memory Axel Jena, Jürgen Pröll 17

18 Built-in Variablen Verfügbar in Device-Funktionen dim3 threadidx; Thread-ID innerhalb des Blocks threadidx.x, threadidx.y, threadidx.z dim3 blockidx; Block-ID innerhalb des Grids dim3 blockdim; Größe des Blocks in Threads dim3 griddim; Größe des Grids in Blöcken int warpsize; Größe eines Warps in Threads Axel Jena, Jürgen Pröll 18

19 Runtime Library Common Runtime Component Vektor Typen (dim3), Texture Typen Teile der C Runtime Library Host Runtime Component Device Management Memory Management cudamalloc(), cudafree(), cudamemcpy() Texture Management Kompatibilität mit OpenGL und Direct3D Event Management Error Handling Device Runtime Component Mathematische Funktionen Atomic Funktionen Funktionen zur Synchronisation - syncthreads() wartet, bis alle Threads eines Blocks die Barriere erreichen Axel Jena, Jürgen Pröll 19

20 Libraries & Development Tools CUDA Libraries: Thrust: Standard Template Library (STL) für CUDA CUBLAS: CUDA Basic Linear Algebra Subprograms CUFFT: CUDA Fast Fourier Transformation Development Tools: CUDA-gdb (Debugger) CUDA Visual Profiler (Performance Profiling Tool) CUDA-MemCheck Axel Jena, Jürgen Pröll 20

21 Beispiel - CPU Axel Jena, Jürgen Pröll 21

22 Beispiel GPU Axel Jena, Jürgen Pröll 22

23 Noch Fragen? Axel Jena, Jürgen Pröll 23

Ähnliche Dokumente

CUDA. Moritz Wild, Jan-Hugo Lupp. Seminar Multi-Core Architectures and Programming. Friedrich-Alexander-Universität Erlangen-Nürnberg

CUDA. Moritz Wild, Jan-Hugo Lupp. Seminar Multi-Core Architectures and Programming. Friedrich-Alexander-Universität Erlangen-Nürnberg CUDA Seminar Multi-Core Architectures and Programming 1 Übersicht Einleitung Architektur Programmierung 2 Einleitung Computations on GPU 2003 Probleme Hohe Kenntnisse der Grafikprogrammierung nötig Unterschiedliche