Numerik und Rechnen. Inhaltsverzeichnis. Seminar Programmierung von Grafikkarten

Transkript

1 Numerik und Rechnen Seminar Programmierung von Grafikkarten Martin Heide & Dominik Holler Betreuer: Björn Knafla, Prof. Dr. Claudia Leopold Inhaltsverzeichnis 1 Einführung Rechnen auf der GPU mit einer Bibliothek Darstellung der Daten Operationen auf den Daten Beispiel Fazit Projekt GPGPU Raumklimabeurteilung Verwendung der High Level Sprache Sh für das numerische Rechnen Rechnen mit Sh Fazit... 6

2 1 Einführung Moderne GPUs eignen sich aufgrund ihrer engen Spezialisierung auf Verarbeitung massiv paralleler Datenströme sehr gut nicht nur für 3D Berechnungen, sondern auch für nicht grafische Rechenaufgaben mit gleich bleibenden Datenströmen. Sollen die Ergebnisse der Berechnung visualisiert werden, kommt hinzu, dass sie schon in der Grafikkarte sind; dadurch ist die Visualisierung sehr effizient. Die GPU kann auf verschiedenen Abstraktionsebenen programmiert werden. Eine wenig abstrakter Ansatz ist es, in das Applikationsprogramm Shader einzubetten, um Probleme hoher arithmetischer Intensität auf der GPU zu berechnen. Die Applikation lässt sich vereinfachen, indem GPGPU in einer Bibliothek gekapselt wird. Zum Beispiel ist es mit der Bibliothek Havok FX 1 möglich, physikalische Effekte von der GPU berechnen zu lassen. Im Bereich der Computer Vision (computerunterstütztes Sehen) klingt die Bibliothek OpenVIDIA 2 viel versprechend, weil sie aufwendige Algorithmen, die zum Beispiel zur Objekterkennung auf Videobildern nötig sind, auf die GPU verlagert. An der TU-München wurde eine Bibliothek entwickelt, die Berechnungen der Linearen Algebra auf die GPU verlagert. Diese Bibliothek wird im ersten Teil der Arbeit vorgestellt. Einen ganz anderen Ansatz geht das Stream-Processing Paradigma. Mit Programmiersprachen wie Sh sich Metaprogramme erstellen, die erst zur Laufzeit das auszuführende Programm generieren. 2 Rechnen auf der GPU mit einer Bibliothek Hier wird am Beispiel der Bibliothek für Lineare Algebra von Jens Krüger gezeigt, wie Matrizen und Vektoren auf einer GPU gespeichert und verarbeitet werden können. Anschließend werden die vorgestellten Konzepte benutzt, um ein Beispielproblem zu lösen. Der gesamte Abschnitt orientiert sich am Kapitel A GPU Framework for Solving Systems of Linear Equations von Jens Krüger und Rüdiger Westermann im Buch GPU Gems 2 von Addison-Wesley und Nvidia. 2.1 Darstellung der Daten Skalare (Fließkommazahlen) werden als 1 1 Textur dargestellt, weil der Texturspeicher effizient an die GPU angebunden ist, und weil diese Darstellung zu den folgenden Datentypen passt. Vektoren werden als Texturen, und nicht als Vertices gespeichert, weil die GPU Texel schneller als Vertices verarbeitet, weil der Texturspeicher schneller angebunden ist, und weil in den Texturspeicher auch geschrieben werden kann. Da Grafikhardware für die Verarbeitung zweidimensionaler Texturen optimiert ist, sind zweidimensionale Texturen zur Repräsentation von Vektoren am besten geeignet, siehe Schritt 1 in Abbildung 1. In jedem Pixel der Textur lassen sich 4 Fließkommazahlen speichern, siehe Schritt 2 in Abbildung 1. Auf diese Art lassen sich auch hardwareseitige Größenbeschränkungen eindimensionaler Texturen umgehen. Voll, diagonal und zufällig besetzte Matrizen werden verschiedene Art gespeichert. Volle Matrizen werden in ihre Spaltenvektoren zerlegt gespeichert. Sind nur die Diagonalen einer Matrix besetzt, ist es ausreichend nur diese Diagonalenvektoren als Spaltenvektoren zu speichern, siehe Matrix M in Abbildung

3 1. Ein Pixel 2. Abbildung 1: Darstellung von eindimensionalen Vektoren auf der GPU 2.2 Operationen auf den Daten Die hier vorgestellten Operationen berechnen aus Texturen, die, wie oben erklärt, Matrizen und Vektoren repräsentieren, neue Texturen, die das Ergebnis einer Rechenoperation repräsentieren. Elementweise Operationen, wie die Addition oder die elementweise Multiplikation von Vektoren, berechnen aus einem Pixelpaar der beiden Eingabetexturen ein Pixel der Ausgabetextur. Die Berechnung wird vom Fragmentshader durchgeführt. Die Summe über alle Elemente eines einer Matrix n n kann in log n Rendering-Durchgängen gefunden werden. In jedem Rendering-Druchgang wird die Eingabematrix auf eine Textur der viertelsten Größe reduziert. Dabei addiert das Fragment-Programm je vier Pixel der Eingabematrix zu einem Pixel der Ausgabematrix. Eine diagonal-besetzte Matrix M wird mit einem Vektor v multipliziert, indem die Diagonalen- Vektoren elementweise mit bestimmten Elementen des Vektors v multipliziert werden, siehe Abbildung 2. Der Vektor der Elemente, mit ein Diagonalen-Vektor multipliziert werden soll, ergibt sich aus dem Vektor v durch verschieben der Indices um den Abstand des Diagonalen-Vektors zur Hauptdiagonale der Matrix. In Abbildung 2 wird die Hauptdiagonale (Rot, Gelb, Mangenta, Orange) mit v elementweise Multipliziert. Die zweite besetzte Diagnonale in M (Hellgrün, Blau) wird nur mit den beiden letzten Elementen von v elementweise Multipliziert. Der Ergebnissvektor der Matrix-Vektor-Multiplikation ergibt sich aus der Summe Ergebnisse der elementweisen Vektor-Multiplikationen. M v x x x Abbildung 2: Multiplikation einer diagonal besetzten Matrix mit einem Vektor 3

4 Abbildung 3: Einfluß eines Elementes in einem 3 3 Gitter 2.3 Beispiel Die Autoren Kürger und Westermann zeigen [KrüWest05], wie sich eine Welle an der Wasseroberfläche auf der GPU simulieren lässt. Dazu wird ein Gitter, siehe Abbildung 3, über die simulierte Wasserfläche gelegt. Die roten Pfeile in Abbildung 3 beschreiben den Einfluß der Höhe y der Welle an den benachbarten Punkten des Gitterneztes auf den mittleren Punkt, die blauen Pfeile beschreiben den Einfluss der Welle des mittleren Punktes auf seine Nachbarn. Mathematisch lässt sich die Auslenkung y der Welle in der x z -Ebene in Abhängigkeit der Geschwindigkeit c der Welle mit der partiellen Differentialgleichung in Formel 1 beschrieben. 2 y c2 2 y 2 y t 2 x 2 z 2 Formel 1: Beschreibung der Welle Formel 2: Explizite Darstellung der Welle Aus der Diskretisierung von Formel 1 ergibt sich durch Umformungen Formel 2. Formel 2 beschreibt die Welle in einer für Computer geeigneter Schreibweise aus Matrizen und Vektoren. Die Matrix M beschreibt den Einfluss der Welle an jedem Punkt im Gitter auf jeden Punkt im Gitter. Der Vektor t y beschreibt die Welle zum Zeitpunkt t an jedem Punkt im Gitter. Diese Berechnung lässt sich mit der Bibliothek der TU-München in eine Zeile C-Quelltext kapseln: M->MatrixVectorOp(CL_SUB, y_now, y_last, y_next); Zur Berechnung wird eine Matrix-Vektor-Multiplikation für die fünf besetzten Diagonalen der Matrix M durchgeführt. Vom Ergebnis-Vektor der Multiplikation wird anschließend y t 1 elementweise abgezogen. Beide Rechenschritte werden auf die oben beschriebene Weise durchgeführt. 2.4 Fazit Berechnungen der Linearen Algebra lassen sich auf der GPU durchführen. Auf der Grafikkarte werden Matrizen und Vektoren von Texturen repräsentiert. Berechnungen werden vom Fragmentshader durchgeführt. Bibliotheken, wie die hier vorgestellte Bibliothek der TU-München, können die Details der Implementierung kapseln. 3 Projekt GPGPU Raumklimabeurteilung y t 1 M y t y t 1 Die Motivation für den zweiten Teil diese Ausarbeitung resultiert aus dem Studienprojekt GPGPU Raumklimabeurteilung, bei dem es um eine thermische Behaglichkeitssimulation von Wohn- und Arbeitsräumen geht. 4

5 Das ursprüngliche Simulationsprogramm entstand am Ingenieurbüro Prof. Hauser und wurde von Dipl.-Ing. Christoph Kempkes in Fortran entwickelt. Ziel des Projektes ist es, die Simulation auf einer High-End GPU zu rechnen, mit dem Ziel der Performance-Steigerung zugunsten höherer Genauigkeit. Unter Behaglichkeit wird hier das thermische Temperaturempfinden eines Menschen verstanden in der Art: Mir ist kalt, mir ist zu warm oder es ist gerade angenehm. Die Grundidee des Simulationsalgorithmus ist in der Abb. 1 schematisch dargestellt. Das Ergebnis ist als blau-rote Ebene dargestellt. Diese symbolisiert die Verteilung der PMV-Werte, die das thermische Empfinden einer Person angeben (PMV nach DIN EN ISO 7730). Der Ermittlung der PMV- Werte liegen die Strahlungstemperaturen zugrunde (DIN EN 1946 Teil 2). Die Ebene ist in Zellen aufgeteilt, für die je ein Strahlungstemperatur-Wert zu ermitteln ist. Dazu müssen ebenfalls die Bauelemente (Wände, Decke, Fußboden) in Zellen zerlegt werden, in denen je Oberflächentemperatur, Entfernung und Winkel zur jeder Zelle der PMV-Ebene kodiert sind. Die Simulation liefert um so genauere Ergebnisse, je feiner die Gitterauflösung ist. Abbildung 3: PMV- Verteilung in einer Ebene 4 Verwendung der High Level Sprache Sh für das numerische Rechnen Für die Simulation der thermischen Behaglichkeit wird die High-Level Sprache Sh, das an der University of Waterloo Kanada entwickelt wird, verwendet. Der Vorteil der High-Level Sprachen gegenüber der Low-Level Methode und den Bibliotheken liegt in der höheren Abstraktionsebene und Einfachheit. So muss der Programmierer kein OpenGL oder DirectX Spezialist mehr sein, d. h. er muss das Stream-Processing Paradigma nicht mit Texturen und Shadern umsetzen. Ein weiterer Vorteil ist die bessere Plattformunabhängigkeit. Diese Vorzüge und die Möglichkeit, ein Shader zu programmieren, machen Sh zum geeigneten Kandidaten als bevorzugte Sprache für das Projekt. 5

6 4.1 Rechnen mit Sh Dieser Kapitel erklärt nicht Sh, sondern Beschreibt das Verfahren der Matrixreduktion mit Sh. Es wird vorausgesetzt, dass der Leser mit dem Vortrag von Jens Breitbart Streamprocessing und Hich-Level GPGPU-Sprachen vom vertraut ist. Weil ein Bauelement (typischerweise eine Wand) in der Simulation auf eine Matrix abgebildet wird (vgl. Kapitel 3), ist die wesentliche Anwendung der GPU im Projekt das Aufaddieren der Zellen einer großen Matrix (die Reduktion der Matrix). Sie kann dazu zeilenweise in Streams aufgeteilt werden. Diese können nun in die GPU geladen und dort verarbeitet werden. Allerdings ist der Programmierer an dieser Stelle mit einer Einschränkung der Streamparadigmas konfrontiert. Die Aufaddierten Matrix-Zeilen ergeben einen Vektor, dessen Elemente wieder aufaddiert werden müssen, doch ist dies ohne die Neuordnung der Streams nicht möglich, denn die GPU lässt keinen Umtausch der Streamelemente zu (Abb. 2). Der Ausgabe-Stream muss nun in die CPU geladen und dort neu sortiert werden. Dieser Prozess führt zu einer Steigerung der Busauslastung, die die GPU Performance erheblich schmälert. Eine Lösung wäre, die zu verarbeitenden Matrizen bezüglich der Rechenvorgänge zu sortieren. D. h. erst werden die Zeilen jeder Matrix zusammenaddiert, dann werden die Ergebnisse in die CPU geladen und zu einer neuen Matrix zusammengefasst, nun wir die Matrix wieder in die GPU geladen und die Zeilen addiert. So bekommen wir die Reduktionen jeder Matrix mit nur zwei Buszugriffen. Streams Streams Matri x Vektor GPU CPU GPU CPU Skalar Abbildung 4: Matrixreduktion 5 Fazit Das Streamingparadigma erlaubt durch die höhere Abstraktion einfachere Herangehensweise an ein numerisches Problem. Jedoch gibt es momentan einige Einschränkungen. Z. B. können die Streams nicht in der GPU neu geordnet werden, ferner gibt es keine Datenstruktur in der Art eines Arrays, die wahlfreien Zugriffe für jeden Streamelement zulässt, ohne dass sich der Programmierer mit Texturen beschäftigen muss. 6

7 Die High-Level Sprachen bergen einige Nachteile. So lassen die gegenwärtigen GPU Architekturen keine Neuordnung der definierten Streams zu. Diese können nur auf der CPU-Ebene neu geordnet werden, was zu einer höheren Busauslastung und somit Latenz führt, denn die Daten müssen in den Arbeitsspeicher des Rechner transferiert werden. Daher ist es wichtig, zusätzlich zu dem Streamkonzept, die Möglichkeit zu haben, GPU-Direktiven im demselben Programm einzubetten. So können Features entwickelt werden, die das Streamparadigma nicht zulässt. Z. B. wahlfreies Lesen einer Textur, um jedem Streamelement dieselben Werte verfügbar zu machen. Für die Entwicklung des Simulationsprogramms im Rahmen des Projekts GPGPU Raumklimabeurteilung ist die Wahl trotz bekannter Einschränkungen auf Sh gefallen. Der Grund dafür ist, die einfache Handhabung der Streams und die Möglichkeit GPU-Programme so zu gestalten, dass ein wahlfreies Lesen doch noch möglich ist. Ferner ist Sh die zur Zeit einzige verfügbare GPU Programmiersprache, die weiterentwickelt wird. 6 Zusammenfassung Es hat sich gezeigt, dass sich Berechnungen auf der GPU in einer High-Level-Sprache wie Sh oder mit Bibliotheken, wie die der TU-München, sich mit Einschränkungen programmieren lassen. Bibliotheken haben sich als sehr auf ein Problem spezialisiert herausgestellt, während die High- Level-Sprache Sh durch das Stream-Programming-Paradigma eingeschränkt wird. 7

8 Literaturverzeichnis [KrüWest05] KRÜGER, Jens; WESTERMANN, Rüdiger: A GPU Framework for Solving Systems of Liniear Equations in GPU Gems 2 Addison-Weslesy, 2005 ISBN Seiten [DIN7730] DIN EN ISO 7730: Analytische Bestimmung und Interpretation der thermischen Behaglichkeit durch Berechnung des PMV- und PPD-Indexes und der lokalen thermischen Behaglichkeit. [DIN1946] DIN EN ISO 1946, Raumlufttechnik Gesundheitstechnische Anforderungen. 8