Vergleich der Frameworks OpenCL und CUDA zur GPGPU- gestützten Datenverarbeitung Leonid Kostrykin Matr.Nr.: Lehrstuhl für Medizintechnik Helmholtz-Institut für Biomedizinische Technik der RWTH Aachen Pauwelsstraße Aachen Fakultätsinterner Betreuer: Prof. Dr. rer. nat. W. Hillen, FH Aachen Betreuender wissenschaftlicher Mitarbeiter: Dr.-Ing. M. de la Fuente

Überblick  Einleitung  Technischer Hintergrund oGrafikprozessor-Besonderheiten oGPGPU-Grundlagen  CUDA und OpenCL oKonzeptionelle Ebene oProgrammiermodelle  Fazit und Ausblick

Einleitung  GPGPU – “general purpose computing on graphics processing units” – Möglichkeiten und Grenzen  Dazu: populäre Frameworks CUDA und OpenCL Leistungsfähigkeit von Haupt- und Grafikprozessoren im zeitlichen Verlauf [NVIDIA, 2012b] Intel Core i7: 4 Kerne NVIDIA GeForce GTX 280 : 240 Kerne

Beckenmodell – CT-Aufnahme Normalen der CT-Aufnahme, farbkodiertCT-Aufnahme mit Lichtsimulation Einleitung

Grafikprozessor-Besonderheiten  Grundlegendes Problem digitaler Rechner: von-Neumann-Flaschenhals Herangehensweisen:  CPU: Pipelining und Cachespeicher  GPU: Hohe Speicherbandbreite verdeckt Latenz  Mehr Chipfläche ausgewiesen für… oFlusskontrolle und Cachespeicher (CPU) oRechenlogik (GPU)

Problem-Eignung zur GPGPU-Beschleunigung

Typischer CUDA-fähiger Grafikprozessor: G80 mit „Tesla“-Architektur GPGPU-Grundlagen NVIDIA G80 GPU Architektur [Ruetsch und Oster, 2008]  128 SP  16 MP mit je 8 SP

Konzeptionelle Ebene: CUDA  CUDA – “compute unified device architecture” oSprache CUDA C/C++ oCUDA-Architektur (GPGPU-Hardware, Treiber, …)  Compute Capability: 1.x (Tesla) 2.x (Kepler) 3.x (Fermi)  Programmteile unterschieden nach Domänen: oHost: CPU + Hauptspeicher oDevice: GPU + Grafikspeicher oWerden gemischt kodiert  Programmteil auf Device: Kernel

Konzeptionelle Ebene: OpenCL  OpenCL – “open computing language”  Plattform-Modell  SPMD – “single program multiple data” o1 Datenstrom  1 Befehlszähler  unterschiedliche Instruktionen je Datenstrom / Taktzyklus  Hierarchische Aufteilung wie „Tesla“-Architektur  Kernel: Einstiegspunkt in Device-Programmteil OpenCL Plattform-Modell als UML-Klassendiagramm Device - globaler Speicher - konst. Speicher Host steuert Recheneinheit - geteilter Speicher Abarbeitungs- element - dedizierter Speicher SIMDSPMD 1 * 1 *

Konzeptionelle Ebene: Ausführungsmodelle Abbildung auf Hardware CUDAKonzeptOpenCL Abbildung auf Plattform-Modell Streaming- Prozessor Thread Kernel-Abarbei- tungsstrang Work-Item Abarbeitungs- element Grid Gesamtmenge aller Abarbeitungs- stränge: 1-, 2- oder 3-dimensional organisiert NDRange bzw. Index-Raum Streaming- Multiprozessor Block Verbund aus benachbarten Abarbeitungs- strängen Work-Group Recheneinheit

CUDAOpenCL Host- Device- Kommuni kation Globaler / Konst. Speicher  globaler / konst. Speicher Koop. im Block Geteilter Speicher  geteilter MP- Speicher Lokaler Speicher  geteilter Recheneinheit- Speicher Lokale Variablen Privater Speicher  SP- Register (nicht abzählbar) Lokaler Speicher  globaler Device- Speicher Privater Speicher  dedizierter Abarbeitungselem ent-Speicher Konzeptionelle Ebene: Speichermodelle CUDA-Speichermodell [Kirk und Hwu, 2010]

Konzeptionelle Ebene: Speichermodelle Besonderheiten des CUDA-Speichermodells:  Zusätzliche Speicherklassen Textur-Speicher (CC 1.0) – nur lesbar Surface-Speicher (CC 2.0) – les- und schreibbar omit Caches für örtliche 2D-Lokalität optimiert oextra-Recheneinheiten beschleunigen Adressberechnungen  Unified Virtual Addressing (CC 2.0, nur 64bit)  Zeiger-Domäne implizit bekannt  vereinfachte Schnittstellen HauptspeicherGlobaler SpeicherKonstanter Speicher 0 … Adressräume ohne UVA: 0 … Adressraum mit UVA:

Programmiermodelle: Überblick CUDA:  Host- und Device-Programmierung in CUDA C/C++ OpenCL:  Device-Programmierung in OpenCL C (C99-Teilmenge) Typische Aspekte:  Initialisierung?  Fehlerbehandlung?  Debugging? Weiterführende Fragen:  Kernel-Steuerung?  Synchronisation?  Zugriff auf OpenGL-Objekte?

Initialisierung, Fehlerbehandlung und Debugging  OpenCL muss explizit initialisiert werden  OpenCL-Kontext Fehlerbehandlung  CUDA: Rückgabewert jedes API-Aufrufs  OpenCL: nicht einheitlich Debugging  CUDA: „Nsight“ – integriert sich in bestehende IDE  OpenCL: implementierungsspezifisch oAMD: „gDEBugger“ – integriert sich ebenfalls in IDE ogibt keinen für NVIDIA-Hardware  OpenCL-Kernels auf NVIDIA-Hardware debuggen nicht möglich

Kernel-Steuerung und Synchronisation Kernel-Aufruf:  CUDA: Spracherweiterungen  OpenCL: Aufrufe der Host-API  konventionell, aufwendiger Synchronisation:  CUDA wie OpenCL: bzgl. Threads eines Blocks oder Host-Device  Nur OpenCL: bzgl. Befehlen in Befehlswarteschlange

CUDAOpenCL 1.Initialisierung „cudaGLSetGLDevice“Zwei zusätzliche Parameter bei der OpenCL-Initialisierung: 1.„CL_GL_CONTEXT_KHR“ 2.Plattform-spezifisch 2.Objekt- Vorbereitung 1.Bekanntmachung des OpenGL-Objekts in CUDA/OpenCL 2.Sperrung für Exklusivzugriff 3.Objekt-Nutzung 4.Objekt- Freigabe 1.Freigabe des Exklusivzugriffs 2.Aufheben der Bekanntmachung Einschränkungen Nur Texturen mit 1, 2 oder 4 Farbkanälen 3D-Texturen nur lesen; Texturen mit 3 Farbkanälen nur mit Pixeltiefe von 16bit Zugriff auf OpenGL-Objekte

Fazit  Normalenberechnung gutes Beispiel  CUDA und OpenCL konzeptionell sehr ähnlich  Entscheidungsfindung: Weitere Kriterien: o Templates zur Kernel- Programmierung:  CUDA  OpenCL o Unabhängigkeit von bestimmter Plattform zur Laufzeit:   CUDA OpenCL OpenCL oder CUDA – Entscheidungsfindung bezüglich des Entwicklungssystems

Ausblick Röntgenbild-Rekonstruktion eines Herzens aus einem CT- Datensatz (Digitally Reconstructed Radiograph) Volumenrendering eines CT-Datensatzes, das ein Herz zeigt

Literaturverzeichnis  ALT, A.: Mixing Graphics and Compute with Multiple GPUs  AMD: Heterogeneous Computing: OpenCL™ and the ATI Radeon™ HD 5870 (“Evergreen”) Architecture  HOMBERG, W.: OpenCL A Programming Model for eQPACE?  KIRK, David ; HWU, Wen-mei: Programming Massively Parallel Processors: A Hands-on Approach. Burlington: Morgan Kaufmann Publishers, – ISBN  KÜPPERS, Bastian ; KRAFT, B. ; SCZIMAROWSKY, Martin ; VOSS, Alexander: Vorlesungsfolien IT-Systeme SS  MICIKEVICIUS, P.: Local Memory and Register Spilling  MUNSHI, A.: The OpenCL Extension Specification: Version  MUNSHI, A.: The OpenCL Specification: Version  NVIDIA: Introduction to GPU Computing with OpenCL  NVIDIA: NVIDIA’s Next Generation CUDA™ Compute Architecture: Fermi™  NVIDIA: NVIDIA CUDA C Programming Guide  NVIDIA: OpenCL™ Programming Guide for the CUDA™ Architecture  RIBBROCK, D.: Entwurf einer Softwarebibliothek zur Entwicklung portabler, hardwareorientierter HPC Anwendungen am Beispiel von Strömungssimulationen mit der Lattice Boltzmann Methode. Dortmund, Technische Universität Dortmund, Dissertation, 2009  RUETSCH, G. ; OSTER, B.: Getting Started with CUDA  SCHROEDER, Tim C.: Peer-to-Peer & Unified Virtual Addressing  SEIDLER, R.: CUDA und OpenCL  TARIQ, S.: An Introduction to GPU Computing and CUDA Architecture

Vergleich der Frameworks OpenCL und CUDA zur GPGPU- gestützten Datenverarbeitung Leonid Kostrykin Lehrstuhl für Medizintechnik Helmholtz-Institut für Biomedizinische Technik der RWTH Aachen Vielen Dank !