Vergleich der Frameworks OpenCL und CUDA zur GPGPU- gestützten Datenverarbeitung Leonid Kostrykin Matr.Nr.: 846728 Lehrstuhl.

Präsentation zum Thema: "Vergleich der Frameworks OpenCL und CUDA zur GPGPU- gestützten Datenverarbeitung Leonid Kostrykin Matr.Nr.: 846728 Lehrstuhl."—  Präsentation transkript:

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

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

3 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

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

5 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)

6 Problem-Eignung zur GPGPU-Beschleunigung

7 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

8 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

9 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 *

10 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

11 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]

12 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 … 2 32 -1 Adressräume ohne UVA: 0 … 2 64 -1 Adressraum mit UVA:

13 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?

14 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

15 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

16 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

17 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

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

19 Literaturverzeichnis  ALT, A.: Mixing Graphics and Compute with Multiple GPUs. 15.05.2012.  AMD: Heterogeneous Computing: OpenCL™ and the ATI Radeon™ HD 5870 (“Evergreen”) Architecture. 03.2010.  HOMBERG, W.: OpenCL A Programming Model for eQPACE? 04.02.2009.  KIRK, David ; HWU, Wen-mei: Programming Massively Parallel Processors: A Hands-on Approach. Burlington: Morgan Kaufmann Publishers, 2010. – ISBN 978-0-12-381472-2  KÜPPERS, Bastian ; KRAFT, B. ; SCZIMAROWSKY, Martin ; VOSS, Alexander: Vorlesungsfolien IT-Systeme SS 12. 2012.  MICIKEVICIUS, P.: Local Memory and Register Spilling. 2011.  MUNSHI, A.: The OpenCL Extension Specification: Version 1.2. 2011.  MUNSHI, A.: The OpenCL Specification: Version 1.2. 2011.  NVIDIA: Introduction to GPU Computing with OpenCL. 2009.  NVIDIA: NVIDIA’s Next Generation CUDA™ Compute Architecture: Fermi™. 2009.  NVIDIA: NVIDIA CUDA C Programming Guide. 2012.  NVIDIA: OpenCL™ Programming Guide for the CUDA™ Architecture. 2012.  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. 2008.  SCHROEDER, Tim C.: Peer-to-Peer & Unified Virtual Addressing. 2011.  SEIDLER, R.: CUDA und OpenCL. 24.04.2012.  TARIQ, S.: An Introduction to GPU Computing and CUDA Architecture. 2011.

20 Vergleich der Frameworks OpenCL und CUDA zur GPGPU- gestützten Datenverarbeitung Leonid Kostrykin (kostrykin@hia.rwth-aachen.de) Lehrstuhl für Medizintechnik Helmholtz-Institut für Biomedizinische Technik der RWTH Aachen http://www.meditec.hia.rwth-aachen.de Vielen Dank !