Fachgebiet Programmiermethodik Prof. Dr. Claudia Leopold. Seminar Programmierung von Grafikkarten. GPGPU Basiskonzepte. von.

Transkript

1 Fachgebiet Programmiermethodik Prof. Dr. Claudia Leopold Seminar Programmierung von Grafikkarten GPGPU Basiskonzepte von Marc Kirchhoff

2 Inhaltsverzeichnis 1 Einleitung 2 2 Streams, Kernels und Prozessoren Einleitung Das Programmiermodell Streams Prozessoren Datenstrukturen auf der GPU Einfache Datentypen Multidimensionale Arrays Strukturen Dünn besetzte Datenstrukturen Algorithmen Einleitung Bitonic Merge Sort Zusammenfassung 10 Abbildungsverzeichnis 11 Literatur 11 1

3 1 Einleitung Das Grafikkarten gut für die Berechnung von Texturen, Grafiken und Bildern geeignet sind ist klar. Das es aber auch gute Gründe dafür gibt Grafikkarten im Bereich des General Purpose Computings einzusetzen, weiß vielleicht noch nicht jeder. Es gibt hauptsächlich zwei Gründe warum Grafikkarten für die Durchführung von allgemeinen Rechenaufgaben verwendet werden sollten: 1. Performance 2. Lastenverteilung 1. Performance: Wie aus Tabelle 1 leicht ersichtlich ist, sind aktuelle Grafikkarten herkömmlichen CPUs sowohl bei der reinen Rechenleistung als auch bei der Speicherbrandbreite weit überlegen. Fließkommaoperationen Speicherbrandbreite Geforce 6800 Ultra 60 GFlops 35 GB/s Geforce FX 5900 Ultra 20 GFlops 25,3 GB/s Pentium 4 3 GHz 6 GFlops 5,96 GB/s Tabelle 1: Geschwindigkeitsvergleich CPU/GPU 2. Lastenverteilung: Bei modernen Rechnern tritt außerdem oft der Fall ein, dass die GPU auf die CPU warten muss. Es gibt daher keinen Grund warum nicht Rechenaufgaben von der CPU auf den Grafikkartenprozessor (Graphics Processing Unit (GPU)) ausgelagert werden sollten. 2 Streams, Kernels und Prozessoren 2.1 Einleitung Der Grund dafür, dass die CPU nicht komplett durch die GPU ersetzt wird liegt darin, dass die GPU nur auf einer bestimmten Art von Daten besonders schnell Operationen ausführen kann. Die Abarbeitung dieser Daten muss zum einen mit einer hohen Parallelität 2

4 und zum anderen mit einer hohen arithmetischen Intensität möglich sein [1]. Das bedeutet, dass die Daten unabhängig voneinander berechnet werden können müssen und das die Anzahl der zur Abarbeitung der Daten benötigten mathematischen Operationen im Vergleich zu den benötigten Speicherzugriffen wesentlich höher sein sollte. Der Grund dafür, dass Grafikkarten gerade auf dieser Art von Daten besonders schnell Operationen ausführen können, liegt darin, dass die GPU natürlich hauptsächlich zur Bearbeitung von Grafikdaten entwickelt wurde, die naturgemäß diese Eigenschaften aufweißen. Soll z.b. die Helligkeit eines Bildes erhöht werden, so kann natürlich die Helligkeit jedes einzelnen Pixels unabhängig von jedem anderen Pixel erhöht werden. Um eine möglichst effiziente Abarbeitung solcher Daten zu ermöglichen, wurden GPUs als sogenannte Stream-Prozessoren konzipiert. Stream-Prozessoren arbeiten, im Gegensatz zu normalen seriellen Prozessoren, immer auf kompletten Datenströmen (Stream = Array gleicher Daten). Wobei die GPU etwas von diesem Modell abweicht und auch in der Lage ist auf bestimmmte Speicherbereiche wahlfrei zuzugreifen. Der große Unterschied zwischen den seriellen- und den Stream-Prozessoren besteht also darin, dass serielle Prozessoren auf beliebigen Datenelementen arbeiten und daher auf eine geringe Latenz in den Berechnungen optimiert wurden. Stream-Prozessoren hingegen arbeiten auf großen homogenen Datenmengen und sind auf einen hohen Durchsatz optimiert. 2.2 Das Programmiermodell Dadurch das die GPU als Stream- und nicht als serieller-prozessor konzipiert wurde, ergibt sich gegenüber der seriellen CPU ein völlig anderes Programmiermodell [3]. Ein GPU-Programm ist dabei als eine Folge von Operationen auf Datenströmen aufgebaut. Die Abarbeitung erfolgt dann indem die Instruktionen eines Kernels (kleines Programm) auf die Elemente eines Streams angewandt werden. Ein Kernel führt also auf jedem Element eines Streams eine Reihe von Instruktionen aus und erzeugt als Ergebnis einen Output-Stream. Um den Unterschied weiter zu verdeutlichen folgt ein Beispielprogramm. Das linke Quellcodestück in Abbildung 1 zeigt eine normale for-schleife die über ein Array ( data ) läuft und jedes Array-Element an eine Funktion namens loopbody übergibt, wobei die Funktion loopbody irgendwelche be- 3

5 Abbildung 1: Links ein Programm für einen seriellen Prozessor. Rechts das äquivalente Programm für einen Stream-Prozessor. [2] liebigen Operationen auf diesen Array-Elementen ausführen kann. Das rechte Quellcodestück zeigt das äquivalente Programm für einen Stream-Prozessor. Anhand dieses Beispiels kann man sehr eindrucksvoll die Auswirkungen des Stream-Modells auf die konkrete Programmierung erkennen. Als erstes wird der benötigte Datenstrom angegeben, danach wird der Kernel spezifiziert, es wird also festgelegt welche Operationen auf den Stream- Elementen ausgeführt werden sollen (in diesem Fall soll die Funktion loop- Body auf den Stream-Elementen ausgeführt werden) und schließlich wird ein Output-Datenstrom erzeugt indem dieser Kernel auf dem Input-Datenstrom ausgeführt wird. 2.3 Streams Innerhalb einer GPU existieren vier unterschiedliche Arten von Streams [3]: Vertex-Streams Frame-Buffer-Streams Texture-Streams Fragment-Streams Der Textur-Stream nimmt insofern eine Sonderrolle ein, da er der einzige Stream ist der den Fragment-Prozessoren und Vertex Shader 3.0 vorausgesetzt, auch den Vertex-Prozessoren einen wahlfreien Zugriff erlaubt. Fragment-Programme sind daher in der Lage Rechenergebnisse (Output- Streams) in den Textur-Buffer zu schreiben und direkt wieder als Eingabe für neue Berechnungen zu verwenden. Daraus ergibt sich auch gleich ein Vorteil der Fragment-Prozessoren gegenüber den Vertex-Prozessoren für den general purpose -Einsatz, denn wie aus Abbildung 2 ersichtlich können Fragment- Prozessoren mehr oder weniger direkt in den Textur-Stream schreiben, wohingegen Daten vom Vertex-Prozessor erst noch den Rasterizer und dann selber den Fragment-Prozessor durchlaufen müssen bevor sie im Textur-Buffer 4

6 abgespeichert werden können. Die CPU selber kann mit Ausnahme der Fragment-Stream auf alle anderen Streams schreibend und lesen zugreifen. Wobei auch hier Daten vorteilhafterweise direkt in den Textur-Buffer geschrieben werden sollten, damit sie direkt als Eingabedaten für die Fragment-Programme zur Verfügung stehen. Der Fragment-Stream nur innerhalb der GPU verwendet wird und daher für den Programmierer nicht sichtbar ist. Abbildung 2: Übersicht über die Streams innerhalb der GPU. [3] 2.4 Prozessoren Eine Grafikkarte besitzt zwei unterschiedliche programmierbare Prozessoren: Die Vertex- und die Fragment-Prozessoren. [1] Beide Prozessoren sind voll programmierbar (die auszuführenden Instuktionen können also durch den Programmierer angegeben werden und sind nicht durch dir Hardware von vornherein festgelegt) und auf die Bearbeitung von Vektoren mit vier Komponenten spezialisiert. Der Unterschied zwischen beiden Prozessoren besteht darin das Fragment-Prozessoren, im Gegensatz zu Vertex-Prozessoren, in der Lage sind aus beliebigen Speicherbereichen innerhalb des Textur-Buffers zu lesen (Gather), da jedoch die Output- Adresse schon vom Vertex-Prozessor festgelegt wird, sind sie nicht in der Lage in selber bestimmte Speicherbereiche zu schreiben (Scatter). Bei Vertex- Prozessoren verhält es sich genau umgedreht. 5

7 Zwar können auch Vertex-Programme in neueren Grafikkarten mittels Vertex Shader 3.0 lesend und schreibend auf den Textur-Buffer zugreifen, allerdings sind die so geschriebenen Daten nur dazu da die bearbeiteten Vertex-Daten aufzunehmen und können sonst nicht frei verwendet werden. Ein weiterer Unterschied besteht darin, dass Fragment-Prozessoren ausschließlich im SIMD-Modus arbeiten, wohingegen Vertex-Prozessoren auch im MIMD- Modus arbeiten können. Der Fragment-Prozessor muss also auf allen Elementen eines Streams immer die exakt gleichen Instruktionen ausführen. Bei moderneren GPUs wird diese Nachteil aber durch Pixel Shader 3.0 etwas abgeschwächt, wodurch z.b. Schleifen variabler Länge möglich sind. Trotzdem werden für das general purpose computing hauptsächlich die Fragment-Prozessoren verwendet. Das hat mehrere Gründe. Zum einen enthalten moderne Grafikkarten in der Regel mehr Fragment- als Vertex-Prozessoren und zum anderen sind Fragment-Prozessoren, wie in Abschnitt 2.3 schon erwähnt, in der Lage Daten nach der Berechnung innerhalb eines weiteren Renderpass in den Textur- Buffer zu schreiben, was den Vorteil hat das Ausgabedaten direkt wieder als Eingabedaten verwendet werden können. 3 Datenstrukturen auf der GPU 3.1 Einfache Datentypen Bei der CPU-Programmierung ist man wie ganz selbsverständlich daran gewöhnt eine Vielzahl von Datentypen wie z.b. Integers, Floats, Booleans usw. zur Verfügung zu haben. Obwohl einige High-Level GPU-Sprachen auch Datentypen wie Integer und Boolean anbieten, arbeiten aktuelle GPUs intern ausschließlich mit reellen Zahlen in Form von Fest- oder Fließkommazahlen (NVIDIA verwendet aktuell ein 16 und ein 32-Bit Format. ATI verwendet 24-Bit). Werden also Datentypen wie z.b. Integer verwendet, so müssen diese immer in eine Gleitkommzahl abgebildet werden, was durchaus nicht immer problemlos möglich ist [1][2]. So kann z.b. der Wertebereich eines 32-Bit-Integer Wertes nicht komplett in eine 32-Bit Fließkommazahl abgebildet werden, da diese nur über 23 Mantissen-Bits verfügt. (Das standardtisierte 32-Bit-Format besteht aus einem Vorzeichen-, 23-Mantissenund 8-Exponenten-Bits, wobei die Anzahl der Mantissen-Bits die Genauigkeit festlegt mit der eine Zahl dargestellt werden kann.) Hat man nur das 6

8 16-Bit-Format (10 Mantissen-Bits) oder das 24-Bit-Format (16 Mantissen- Bits) zur Verfügung, so ergibt sich aufgrund des sehr beschränkten Integer- Wertebereichs das mit diesen Formaten dargestellt werden kann ein weiteres Problem. Steht z.b. nur das 16-Bit-Format zur Verfügung, so ist es, einfach weil überhaupt nicht so große Integer-Werte dargestellt werden können, nicht möglich vollständig auf ein Array (also auf einen Textur-Stream innerhalb des Textur- Buffers) mit z.b Elementen zuzugreifen. Des Weiteren muss man sich bewusst sein, dass Fließkommazahlen mit dem 16- und dem 24-Bit-Format nicht mit der selben Genauigkeit, wie man es von der normalen CPU-Programmierung her gewöhnt ist, berechnet werden können. 3.2 Multidimensionale Arrays Die GPU stellt sowohl eins-, zwei- als auch dreidimensionale Texturen zu Verfügung. Da es sich bei einem Textur-Stream praktisch um ein Array gleicher Daten handelt, dürfte die Repräsentation von Arrays dieser Dimensionen innerhalb der GPU eigentlich kein Problem darstellen. In Praxis gibt es allerdings zwei Gründe warum ein-, drei- und höherdimensionale Arrays nicht in ein- und dreidimensionale Texturen abgebildet werden sollten [3]. Zum einen stellen zur Zeit aktuelle GPUs nur eine zweidimensionale Rasterisierung und nur zweidimensionale Frame-Buffer zur Verfügung und zum anderen besitzen die Texturen eine festgelegte maximale Größe von Elementen pro Dimension. Sollen also Arrays beliebiger Dimensionen oder andere beliebige Datenstrukturen innerhalb der GPU verwendet werden, so ist es sinnvoll sie in zwei dimensionale Texturen abzubilden. Dadurch ist zum einen eine wesentlich einfachere Verarbeitung der Texturen möglich und zum anderen können im Vergleich zu eindimensionalen Texturen wesentlich mehr Array-Elemente abgespeichert werden. Wird ein eindimensionales Array in einer zweidimensionalen anstatt in einer eindimensionalen Textur abgespeichert kann es anstatt 4096 bis zu Elemente enthalten. 3.3 Strukturen Verwendet man anstatt eines stream of structures (siehe Abbildung 3) ein structure of streams (für jedes Struktur-Element wird ein extra Stream erzeugt, in Abbildung 3 würde also für die beiden Membervariablen a und 7

9 b jeweils ein extra Stream erzeugt werden) so hat das den Vorteil, dass alle Struktur-Mitglieder den gleichen Stream-Index besitzen und daher von einem einzigen Fragment-Programm aktualisiert werden können [3]. Abbildung 3: Links ein stream of strucutures. Rechts ein structure of streams. [3] 3.4 Dünn besetzte Datenstrukturen Einleitung Alle bisher diskutierten Datenstrukturen waren dichtbesetzt. So enthalten Arrays oft nur wenige oder überhaupt keine Felder die ungültige Werte aufweisen. Bei der Programmierung von seriellen CPUs werden aber neben diesen Datenstrukturen oft auch dünn besetzte Datenstrukturen, wie z.b. Listen oder Bäume verwendet, deren Elemente möglicherweise über den Speicher verteilt sind (Elemente eines Arrays werden in der Regel in aufeinanderfolgenden Speicherzellen abgespeichert) und die unter Umständen auch dynamisch wachsen und schrumpfen können. Die Implementierung solcher Datenstrukturen auf der GPU stellt tatsächlich ein nicht unerhebliches Problem dar [3]. Das hat hauptsächlich zwei Gründe. Zum einem ist es zum Aktualisieren solcher Datenstrukturen erforderlich in berechnete Speicheradresse zu schreiben (scattering) und zum anderen muss beim Durchlaufen der Datenstruktur auf eine nicht einheitliche Menge von Pointer zugegriffen werden, was aufgrund der SIMD-Architektur der Fragment-Prozessoren ein Problem darstellt, da ein Fragment-Prozessor auf allen Stream-Elementen die exakt gleichen Operationen ausführen muss. 8

10 Purcell s Sparse Ray-Tracing Data Structure Als ein Beispiel für eine dünnbesetzte Datenstruktur wird hier kurz auf eine Datenstruktur von Purcell zur Speicherung eines dreidimensionalen Grids aus Dreiecken eingegangen [3]. Das Grid besteht aus mehreren Grid-Zellen die wiederum mehrere Dreiecken enthalten. Das Problem besteht nun darin das Dreiecke sich auch in mehreren Grid-Zellen befinden können. Die Besonderheit an Purcell s Implementierung besteht darin, dass die Dreiecke nicht redundant abgespeicher werden. Wie man an dem Bild erkennen kann, besteht die Datenstruktur aus insgesamt drei Texturen. Die erste 3D Grid Textur enthält für jede Grid-Zelle einen Pointer der auf eine Liste innerhalb der zweiten Textur zeigt. Diese Liste enthält für jedes Dreieck innerhalb der entsprechenden Grid-Zelle einen Pointer der auf eine dritte Textur verweist, die dann die eigentlichen Dreiecksdaten enthält. Dieses Beispiel zeigt eine der grundlegenden Ideen bei der Implementierung von dünn besetzten Datenstrukturen auf der GPU. Die Verwendung von indirekter Indizierung. Allerdings hängt die tatsächliche Implementierung der Datenstruktur in der Regel sehr von den tatsächlich vorhandenen Daten ab. Abbildung 4: Purcells s Sparse Ray-Tracing Data Structure [3] 4 Algorithmen 4.1 Einleitung Wie die Implementierung von Datenstrukturen ist die Implementierung von Algorithmen auf der GPU meistens nicht ohne Probleme möglich [4]. In der Regel besitzen die auf der CPU eingesetzten Algorithmen nicht den nötigen 9

11 Parallelitätsgrad um effizient auf der GPU ausgeführt zu werden. Ein Beispiel für einen Sortieralgorithmus der sich gut auf der Grafikkarte implementieren lässt ist der sogenannte Bitonic-Merge-Sort-Algorithmus. 4.2 Bitonic Merge Sort Der Bitonic-Merge-Sort-Algorithmus ist ein paralleler Sortieralgorithmus der auf dem Sortieren und Verschmelzen von bitonischen Zahlenfolgen beruht [4][5]. Das besondere an diesem Algorithmus ist, dass er unabhängig von der konkreten Zahlenfolge immer die gleiche Anzahl an Schritten benötigt. So müssen um eine Zahlenfolge mit n-elementen zu sortieren immer log(n) bitonische Zahlenfolgen erzeugt und verschmolzen werden. Wobei die Operationen innerhalb jedes Schrittes auch von vornherein festgelegt sind, weshalb er für die parallele Ausführung wesentlich besser geeignet ist als die meisten auf der CPU typischerweise eingesetzten Algorithmen wie z.b. Quicksort. 5 Zusammenfassung Ein Grund Grafikkarten für die Ausführung von general purpose -Programmen einzusetzen ist die deutlich höhere Rechenleistung und Speicherbrandbreite gegenüber aktuellen CPUs. Um diese Leistungssteigerung zu erreichen wurde die GPU als sogenannter Stream-Prozessor konzipiert. Stream-Prozessoren arbeiten, im Gegensatz zu seriellen Prozessoren, immer auf kompletten Datenströmen. Dieses Stream-Modell selber wirkt sich aber erheblich auf die Programmierung von Grafikkarten aus und hat zur Folge das die Implementierung von Datenstrukturen und Algorithmen in der Regel nicht so einfach erfolgen kann wie man es von der CPU her gewöhnt ist. So weisen viele der auf der CPU verwendeten Algorithmen typischerweise nicht den nötigen Parallelitätsgrad auf um effizient auf der GPU ausgeführt werden zu können und aufgrund des Stream-Modells müssen alle Datenstrukturen in Streams (typischerweise Textur-Streams) abgebildet werden, was gerade für dünn-besetzte Datenstrukturen die möglicherweise auch dynamisch wachsen und schrumpfen sollen recht kompliziert ist. Die tatsächliche Implementierung solcher dünnbesetzen Datenstrukturen ist dann in der Regel erheblich von den wirklich vorhandenen Daten abhängig. 10

12 Abbildungsverzeichnis 1 Vergleich der Programmiermodelle Stream-Übersicht Strukturen Purcell s Data Strucutre Literatur [1] Matt Pharr, Randima Fernando: GPU Gems 2 Kapitel 31 [2] Matt Pharr, Randima Fernando: GPU Gems 2 Kapitel 32 [3] Matt Pharr, Randima Fernando: GPU Gems 2 Kapitel 33 [4] Matt Pharr, Randima Fernando: GPU Gems 2 Kapitel 46 [5] T. Ottmann, P. Widmayer: Algorithmen und Datenstrukturen 11