„General Purpose Computation on Graphics Processing Unit“ – Versionsunterschied

General Purpose Computation on Graphics Processing Unit (kurz GPGPU, vom Englischen für Allzweck-Berechnung auf Grafikprozessoreinheit(en)) bezeichnet die Verwendung eines Grafikprozessors für Berechnungen über seinen ursprünglichen Aufgabenbereich hinaus. Dies können beispielsweise Berechnungen zu technischen oder wirtschaftlichen Simulationen sein. Bei parallelen Algorithmen kann so eine enorme Geschwindigkeitssteigerung im Vergleich zum Hauptprozessor erzielt werden.

Überblick

GPGPU ist aus den Shadern der Grafikprozessoren hervorgegangen. Die Stärke liegt im gleichzeitigen Ausführen gleichförmiger Aufgaben, wie dem Einfärben von Pixeln oder der Multiplikation großer Matrizen. Da der Geschwindigkeitszuwachs moderner Prozessoren derzeit nicht mehr (primär) durch die Erhöhung des Taktes zu erreichen ist, ist die Parallelisierung ein wichtiger Faktor zum Erreichen höherer Rechenleistungen moderner Computer. Der Vorteil der Verwendung der GPU gegenüber der CPU liegt in der höheren Rechenleistung und der höheren Speicherbandbreite. Die Geschwindigkeit wird hauptsächlich durch den hohen Grad an Parallelität der Rechenoperationen des Grafikprozessors erreicht.

Modell	Theoretische Rechenleistung		Speicherbus- Datenrate (GByte/s)	Speichertyp	Art
	bei einfacher	bei doppelter
	Genauigkeit (GFlops)
AMD Radeon Pro Duo	16.384	1.024	1.024	HBM	GPU
AMD Radeon R9 Fury X	8.602	538	512
Nvidia Geforce GTX Titan X	6.144	192	336	GDDR5
AMD FirePro W9100	5.350	2.675	320
Nvidia Tesla K20X	3.950	1.310	250
AMD Radeon HD 7970	3.789	947	264
Intel Xeon Phi 7120	2.420	1.210	352		Co-Prozessor
PlayStation 4 SoC (AMD)	1.860	-	167		APU
Nvidia Geforce GTX 580	1.581	198	192,4		GPU
Intel Xeon E7-8890 v3	1.440	720	102,4 (?)	DDR4	CPU
AMD A10-7850k	856	-	34	DDR3	APU
Intel Core i7-3930K	307,2	153,6	51,2		CPU
Intel Pentium 4 mit SSE3, 3,6 GHz	14,4	7,2	6,4	DDR2

Fragment- und Vertex-Shader können gleichzeitig ausgeführt werden. Ein weiterer Vorteil ist der geringe Preis im Vergleich zu ähnlich schnellen anderen Lösungen sowie die Tatsache, dass geeignete Grafikkarten heute in nahezu jedem PC zu finden sind.

Geschichte

Shader waren anfangs nur mit speziellen Funktionen, die eng mit grafischen Berechnungen verknüpft waren, verbunden. Um die Geschwindigkeit der Berechnung einzelner Pixel zu beschleunigen, ging man dazu über, die Berechnung einzelner Pixel gleichzeitig auszuführen, indem man mehrere gleichartige Rechenwerke einsetzte. Später kam man auf den Gedanken, die sehr beschränkten Fähigkeiten der Shader zu erweitern, um sie zu massiv-parallelen Recheneinheiten für beliebige Aufgaben werden zu lassen: Die ersten – mehr oder weniger – frei programmierbaren Shader entstanden. Der Trend, Shader frei programmierbar zu designen, hält bis heute an und wird von den Chipdesignern mit jeder neuen Technologiegeneration stets weiter vorangetrieben. Moderne GPUs haben teilweise über 1000 dieser programmierbaren Shadereinheiten und können somit auch über 1000 Rechenoperationen gleichzeitig ausführen.

Kritik

Durch OpenCL existiert eine einheitliche Schnittstelle zur Umsetzung von GPGPU-Berechnungen. Der Nachteil gegenüber herkömmlichen CPUs ist die massive Parallelität, mit der die Programme ausgeführt werden müssen, um diese Vorteile zu nutzen. Auch sind GPUs im Funktionsumfang beschränkt. Für den wissenschaftlichen Bereich existieren spezielle Grafikmodelle (Nvidia Tesla, AMD FireStream). Der Speicher dieser Grafikkarten verfügt über Fehlerkorrekturverfahren und deren Genauigkeit bei der Berechnung von Gleitkommazahlen ist größer, was sich auch in den Kosten widerspiegelt.

Programmierung

Für die Entwicklung GPGPU-fähiger Programme stehen vor allem OpenCL, CUDA, und seit 2012 C++ AMP zur Verfügung. OpenCL ist ein offener Standard, der auf vielen Plattformen zur Verfügung steht, CUDA dagegen ist ein proprietäres Framework von Nvidia und auch nur auf GPUs dieses Herstellers lauffähig. AMP ist eine von Microsoft initiierte C++-Spracherweiterung in Verbindung mit einer kleinen Template-Bibliothek, die in dem Sinne offen ist, dass sie weder auf Microsoft-Produkte, noch auf bestimmte Accelerator-Hardware-Typen bzw. bestimmte Hardware-Hersteller beschränkt ist (somit nicht nur GPGPUs, sondern auch CPUs und zukünftig weitere Parallelisierungs-Optionen nutzen könnte, wie etwa Cloud Computing). In Microsofts AMP-Implementierung wird von der GPU eine Unterstützung von DirectX Version 11 erwartet, denn erst mit dieser Version wurde dort der Nutzung von GPUs als GPGPUs besonders Rechnung getragen. Findet ein AMP-nutzendes Programm keine hinreichend aktuelle GPU vor, wird der mit Hilfe von AMP programmierte Algorithmus automatisch auf der CPU unter Nutzung derer Parallelisierungsoptionen (Multithreading auf mehreren Prozessorkernen, SIMD-Instruktionen) ausgeführt. AMP soll somit eine vollkommene Abstraktions-Schicht zwischen einem Algorithmus und der Hardware-Ausstattung des ausführenden Computers herstellen. Zudem soll die Beschränkung auf wenige neue C++-Sprachkonstrukte, und wenige neue Bibliotheks-Klassen, die bisherigen Hürden und Aufwände bei der Entwicklung paralleler Algorithmen vermindern. DirectX 11 wird zwar von allen gängigen GPU-Baureihen (jüngeren Datums als die DirectX-11-Einführung) bereits nativ Hardware-unterstützt (einschließlich von Basisleistungs-GPUs wie Intels Chipsatz-integrierte GPUs), jedoch wurde DirectX 11 erst mit Windows 7 eingeführt und nur für Windows Vista nachgeliefert, so dass ältere Windows-Betriebssysteme von einer AMP-Nutzung ausgeschlossen sind. Ob C++ AMP jemals von anderen Plattformen bzw. C++-Entwicklungsumgebungen außerhalb der Windows-Welt adaptiert werden wird, ist derzeit noch völlig offen.

Ein neuerer Ansatz ist OpenACC, das ähnlich wie OpenMP über Compiler-Pragmas gesteuert wird. Damit wird gewöhnlicher Sourcecode, z. B. in C++, automatisch parallelisiert, indem gewisse Compiler-Pragmas wie "#pragma acc parallel" den seriell formulierten For-Schleifen vorangestellt werden. Der Portierungs-Aufwand ist so relativ klein. Allerdings führt eine automatische Parallelisierung nicht immer zu optimalen Lösungen. OpenACC kann also explizite Parallelprogrammierung wie in OpenCL nie ganz ersetzen. Dennoch ist es in vielen Fällen lohnenswert, auf diese einfache Art hohe Beschleunigungs-Faktoren auf GPGPU erreichen zu können. OpenACC wird von kommerziellen Compilern wie PGI und freien Compilern wie der GNU Compiler Collection unterstützt.

Um Programme auf einer GPU auszuführen, benötigt man ein Hostprogramm, das die Steuerung des Informationsflusses übernimmt. Meist wird zur Laufzeit der in einer C-ähnlichen Sprache formulierte GPGPU-Code auf Anweisung des Hostprogrammes kompiliert und an den Grafikprozessor zur Weiterverarbeitung gesandt, der dann die errechneten Daten an das Hostprogramm zurückgibt.

Siehe auch

• Grafikkarte
• Cell (Prozessor)
• Streamprozessor
• Vektorprozessor
• Direct Rendering Manager – Render-Nodes ermöglichen direkten Zugriff
• Heterogeneous System Architecture

Literatur

• Matt Pharr: GPU Gems 2. Addison-Wesley Publishing Company, 2005, ISBN 0-321-33559-7, Part IV - General-Purpose Computation on GPUs: A Primer. 
• David B. Kirk: Programming Massively Parallel Processors: A Hands-on Approach [Paperback]. Morgan Kaufmann, 2010, ISBN 978-0-12-381472-2. 

Weblinks

• GPU Gems 2
• GPGPU.org
• Nvidia working on first GPGPUs for Apple Macs, AppleInsider (January 24, 2008)
• GPU4Vision GPGPU Publications, Videos and Software
• GPGPU Computing - ein Überblick für Anfänger und Fortgeschrittene (planet3dnow.de 26. Mai 2009)
• Tobias Preis, Peter Virnau, Wolfgang Paul, Johannes J. Schneider: GPU accelerated Monte Carlo simulation of the 2D and 3D Ising model. In: Journal of Computational Physics. 228, 2009, S. 4468–4477, doi:10.1016/j.jcp.2009.03.018.