Automatisches Multi-GPU Scheduling in OpenCL

Transkript

1 Automatisches Multi-GPU Scheduling in OpenCL vorgelegt von Dipl.-Math. Wolfgang Welz Diplomarbeit am Fachgebiet Kommunikations- und Betriebssysteme Prof. Dr. Hans-Ulrich Heiß Institut für Telekommunikationssysteme Fakultät IV Elektrotechnik und Informatik Technische Universität Berlin

2

3 Die selbständige und eigenhändige Anfertigung versichere ich an Eides statt. Berlin, 2. September 20 III

4

5 Zusammenfassung Bis vor wenigen Jahren wurde die Leistungsfähigkeit von Computerprozessoren im Wesentlichen durch eine Erhöhung der Taktfrequenz gesteigert. Da dies aber aus fertigungstechnischen Gründen auf Grenzen stößt, sind die Prozessorhersteller inzwischen dazu übergegangen, eine immer größer werdende Anzahl von weitgehend autonomen Prozessorkernen zu kombinieren. Diese Entwicklung hin zu stärkerer Parallelität ist besonders bei modernen Grafikkarten schon recht stark ausgeprägt. Sie bestehen bereits heute aus hunderten kleinerer Recheneinheiten. Aber nur Programme, die ebenfalls massiv parallelisierbar sind, können hiervon überhaupt profitieren. Aus diesem Grund wurden Schnittstellen wie OpenCL entwickelt, die es ermöglichen, bestimmte komplexe Berechnungen so in tausende Teilberechnungen aufzuteilen, dass möglichst viele dieser kleinen Berechnungen gleichzeitig ausgeführt werden können. In der folgenden Untersuchung wird ein Modell vorgestellt, das Konzept von OpenCL so zu erweitern, dass sich auch ein System mit mehreren Grafikkarten effizient und völlig automatisch nutzen lässt. Hierzu wird das Konzept der MetaQueue eingeführt. Komplizierte Berechnungen, für die eine Beschleunigung besonders wichtig ist, sind im Allgemeinen aus vielen kleineren Teilberechnungen und Funktionen aufgebaut, die untereinander von den Ergebnissen vorher ausgeführter Berechnungen abhängen. Die MetaQueue koordiniert nun die Ausführung dieser Funktionen und verteilt sie auf die unterschiedlichen Grafikkarten. Hierzu ist es von zentraler Bedeutung, dass Übertragungen von Teilergebnissen zwischen zwei Grafikkarten nur dann durchgeführt werden dürfen, wenn dies eine parallele Abarbeitung zulässt, die anderenfalls nicht möglich gewesen wäre. Für dieses Problem wird ein heuristischer Algorithmus entwickelt, der diese Zuweisungen anhand von einigen einfachen Kriterien vornimmt, ohne dass die Dauer der einzelnen Berechnungen im Voraus bekannt ist. Das Verhalten dieses heuristischen Algorithmus wird für idealtypische Testproblemstellungen durch einen Vergleich mit der bestmöglichen Zuteilung überprüft. V

6 Zusammenfassung Durch die MetaQueue steht also erstmals eine Schnittstelle zur Verfügung, durch die OpenCL-Programme ohne Änderung des Konzeptes und ohne jegliche Anpassung des Quelltextes automatisch von der Leistungssteigerung durch die Nutzung mehrerer Grafikkarten profitieren können. VI

7 Inhaltsverzeichnis Abbildungsverzeichnis Codebeispiele IX XI Die Forderung nach Parallelisierung. Die Koordination von mehreren GPUs als aktuelle Herausforderung Aufbau der Untersuchung Grafikkarten-Programmierung 5 2. Programmierbare GPUs Berechnungen auf Grafikprozessoren Ein Vergleich zwischen GPU und CPU Programmierschnittstellen für GPGPU CUDA OpenCL DirectCompute OpenCL 3 3. Architektur Speichermodell OpenCL C Implementierungen Bündelung mehrerer GPUs Die MetaQueue 2 4. Strukturelle Voraussetzungen für die MetaQueue Theoretischer Hintergrund Beschreibung des Konzeptes Wrapper für OpenCL-Objekte OpenCL-Ereignisse VII

8 Inhaltsverzeichnis 4.4 Vorüberlegungen zur Zuteilung auf die GPUs Einfachste Möglichkeit: First-Come First-Served Vermeidung von Kopieroperationen zwischen Grafikkarten Implizite Abhängigkeiten Berücksichtigung der Zusammenhangskomponenten Internes Scheduling Implementations-Details Evaluierung der MetaQueue Generierung von Testinstanzen Auswertung Bestimmung einer optimalen Lösung Optimale versus heuristische Zuteilung Tabellarischer Vergleich Perspektiven und Erweiterungsmöglichkeiten Kopieren und Verschieben von Speicherobjekten Nur eine MetaQueue-Instanz auf dem Host Eine MetaQueue für Geräte in unterschiedlichen Computern Abschätzen der Ausführungsdauer eines Befehls Fazit 65 Literaturverzeichnis 67 Appendices 73 A OpenCL-Kerne für die Testinstanzen 73 B Testinstanzen 75 VIII

9 Abbildungsverzeichnis. Darstellung eines typischen Problems Schematischer Vergleich von CPU und GPU Hierarchische Darstellung einer Plattform Das OpenCL-Speichermodell Diagramm der OpenCL-Klassen Präzedenzgraph für Ereignisse Beispiel für FCFS-Scheduling Beispiel für Scheduling unter der Berücksichtigung von Speicher Graph, der das Addieren von zwei Vektoren repräsentiert Präzedenzgraph für parallel Präzedenzgraph für parallel_unbalanced Präzedenzgraph für components Präzedenzgraph für com_test Präzedenzgraph für components2_host Präzedenzgraph für commutative_add Ein Beispiel, bei dem sich das Kopieren von Speicherobjekten lohnt.. 59 IX

10

11 Codebeispiele 3. Beispielcode zur Ausführung von OpenCL-Kernen Einfaches Beispiel für ein OpenCL Programm Typisches Beispiel für einen OpenCL-Wrapper: cl_program Einfaches Beispiel für das TGF-Format XI

12

13 Kapitel Die Forderung nach Parallelisierung Nach dem Mooreschen Gesetz verdoppelt sich die Komplexität integrierter Schaltkreise mit minimalen Komponentenkosten etwa alle 24 Monate. Diese steigende Komplexität und die daraus resultierenden zusätzlichen Transistoren ermöglichen es immer aufwändiger werdende erweiterte Funktionen oder zusätzliche Kerne zu integrieren. Da eine reine Erhöhung des Prozessortaktes aus technischen Gründen ohne Weiteres nicht mehr möglich ist, sind die Prozessorhersteller inzwischen dazu übergegangen, den Durchsatz der Central Processing Units (CPUs) durch das Hinzufügen von mehreren Prozessorkernen zu erhöhen. Von daher wird die Anzahl der Kerne auch in den nächsten Jahren immer weiter zunehmen, so dass diese Parallelität eine immer größere Rolle bei der Entwicklung von Hard- und Software spielt. Aber auch bei anderen Prozessortypen besteht die Tendenz zu immer stärkerer Parallelität. So haben sich die Graphics Processing Units (GPUs) im Laufe der letzten Jahre von fest vorprogrammierten Geräten zur Bildsynthese zu frei programmierbaren und hoch parallelen Prozessoren entwickelt. Diese zunehmende Parallelisierung der CPUs und GPUs stellt neue Anforderungen an die Konzepte und Hilfsmittel des Programmierens: Es muss einerseits möglich sein, die Vorteile solcher mächtigen Plattformen voll auszunutzen. Auf der anderen Seite muss dieses aber für den Programmierer auch so einfach und transparent wie möglich gehalten werden, so dass z. B. keine oder nur minimale Änderungen notwendig sind, um Programme auf anderen parallelen Prozessortypen ausführen zu können.

14 Kapitel Die Forderung nach Parallelisierung All diese Aspekte werden besonders am Beispiel der Programmierung für moderne Grafikkarten deutlich: GPUs liefern heutzutage im Vergleich zu CPUs eine enorm hohe parallele Rechenleistung, sind aber aufgrund der unterschiedlichen Anforderungen komplett anders aufgebaut. Dadurch ist es im Allgemeinen nicht möglich, ein und dasselbe CPU- Programm auf der Grafikkarte auszuführen und dadurch automatisch eine hundertfache Geschwindigkeitssteigerung zu erreichen. Außerdem gibt es unterschiedliche Grafikkartenmodelle von verschiedenen Herstellern, die untereinander nicht voll kompatibel sind. Aber selbst unter diesen schwierigen Voraussetzungen stehen inzwischen sehr gute Programmierschnittstellen zur Verfügung, mit denen sich auch die Rechenleistung von GPUs effizient ausnutzen lässt. Im nächsten Abschnitt. wird daher zuerst darauf eingegangen, welche Probleme und Möglichkeiten sich bei der gleichzeitigen Nutzung von mehreren Grafikkarten in einem Computer ergeben. Außerdem wird in Abschnitt.2 die Gliederung der vorliegenden Arbeit erläutert.. Die Koordination von mehreren GPUs als aktuelle Herausforderung Um gut parallelisierbare Probleme noch schneller berechnen zu können, bietet es sich an mehr als eine Grafikkarte in einem Computer zu verbauen. Da Grafikkarten aufgrund ihrer hohen Serienproduktion im Verhältnis zu ihrer Rechenleistung sehr kostengünstig sind, ist es so möglich einen enorm leistungsfähigen Computer auch für Privatpersonen finanzierbar zusammenzustellen. Dieses Kombinieren von mehreren Geräten in einem Computer stellt weitere Anforderungen an die benutzte Programmierschnittstelle. Die eleganteste Möglichkeit wäre es, wenn in diesem Fall alle Grafikkarten in einem virtuellen Gerät zusammengefasst werden. Die Schnittstelle müsste dann dafür sorgen, dass große Probleme entsprechend für jede GPU unterteilt werden und im Anschluss auf diesen parallel ausgeführt werden. Kleinere Probleme, bei denen sich so eine Aufteilung nicht lohnt, müssten ebenso erkannt und dann der bestgeeigneten Grafikkarte zugeteilt werden. Diese Entscheidungen werden für mehrere Prozessoren einer Grafikkarte schon so getroffen. Das 2

15 . Die Koordination von mehreren GPUs als aktuelle Herausforderung Zusammenfassen aller Grafikkarten ist damit der logisch nächste Schritt auf einer höheren Komplexitätsebene. Leider bieten die aktuellen Versionen der entsprechenden Schnittstellen zur GPU-Programmierung diese Möglichkeiten nicht. Der Entwickler muss also selber entscheiden, wie er seine Berechnungen aufteilt und auf welche Grafikkarten er dann die einzelnen Teile überträgt. Dieses Vorgehen stellt wiederum hohe Voraussetzungen an die Fähigkeiten des Programmierers in Bezug auf die Hardware und ist damit im Sinne eines möglichst transparenten Konzeptes schlecht geeignet. Diese Arbeit wird sich im folgenden mit einem ersten Ansatz zur Lösung des Problems beschäftigen. Hierzu wird ein Konzept vorgestellt, das innerhalb einer OpenCLkonformen Schnittstelle eine mehrere Geräte umfassende Meta-Warteschlange zur Verfügung stellt. Befehle in dieser Warteschlange werden dann völlig transparent auf die einzelnen Grafikkarten aufgeteilt. Abbildung.: Darstellung eines typischen Problems, das auf mehrere Grafikkarten aufgeteilt werden soll: Die Rechtecke stellen die Programmteile und die Kanten die Abhängigkeiten unter diesen dar. Besonders bietet sich dies für Probleme wie in Abbildung. an. Diese Probleme bestehen dabei aus einer verhältnismäßig großen Anzahl von Befehlen und Programmen, die untereinander auch stark abhängig sind. In solchen Fällen ist es nicht mehr ohne 3

16 Kapitel Die Forderung nach Parallelisierung Weiteres ersichtlich, wie die Menge von Befehlen am Besten auf die Geräte aufzuteilen ist. Zusätzlich hängt eine sinnvolle Aufteilung auch davon ab, wie schnell ein Befehl auf einem bestimmten Gerät ausgeführt werden kann. Genau an dieser Stelle setzt die MetaQueue-Implementation ein, mit der unter diesen Voraussetzungen das Einplanen auf verschiedene Geräte automatisch und problemunabhängig erfolgt. Neben der Zurverfügungstellung von OpenCL-konformen Schnittstellen ist es ein Hauptproblem der MetaQueue-Implementation einen Algorithmus zu entwickeln, der anhand bisheriger Informationen entscheidet, welcher Befehl auf welcher Grafikkarte ausgeführt werden kann, um so eine möglichst effiziente parallele Abarbeitung des Problems zu ermöglichen. Dieses Problem stellt damit ein sogenanntes Scheduling- Problem dar..2 Aufbau der Untersuchung Um die Ideen hinter so einer effizienten MetaQueue-Implementation darstellen zu können, werden in Kapitel 2 die Möglichkeiten einer programmierbaren GPU vorgestellt und die Unterschiede erläutert, die bei der Nutzung der GPU im Vergleich zur CPU auftreten. In Kapitel 3 wird dann ausführlicher auf die Funktionsweise der Open Computing Language (OpenCL) eingegangen. Dies ist in diesem Zusammenhang besonders wichtig, da OpenCL die Schnittstellen zur Verfügung stellt, in die sich die MetaQueue integriert, die aber auch von der MetaQueue-Implementierung selber genutzt werden, um die Aufgaben an die Grafikkarten weiterzuleiten. Nach diesen beiden einführenden Kapiteln wird dann in Kapitel 4 die eigentliche MetaQueue-Implementation sowie der verwendete Scheduling-Algorithmus erläutert. Im nächsten Kapitel wird dann das Verhalten dieses Scheduling-Algorithmus für einige Testfälle überprüft und mit dem idealen Scheduling verglichen. In Kapitel 6 wird dann ein Ausblick gegeben, wie sich die dargestellte Implementation auf andere Aufgabenszenarien anpassen ließe und durch welche weiterführenden Ideen sich das resultierende Scheduling noch weiter verbessern lässt. 4

17 Kapitel 2 Grafikkarten-Programmierung In diesem Kapitel wird die Entwicklung der Grafikkarte dargestellt, die sich von einem einfachen Gerät für die Bildsynthese zu einem vielfältig nutzbaren Prozessor gewandelt hat. Hierzu wird im ersten Abschnitt die heutige Funktionsweise und Aufgabe einer GPU erläutert. In Abschnitt 2.2 wird dann kurz eine Übersicht über die existierenden Schnittstellen für die Grafikkarten-Programmierung gegeben. 2. Programmierbare GPUs Die eigentliche Aufgabe des Grafikprozessors liegt in der Aufbereitung von 3D- und aufwändiger 2D-Grafik. Dazu werden für die Bildsynthese Geometrieinformationen in Form von Polygonen und die dazugehörigen Texturinformation an die Grafikkarte geschickt und dort verarbeitet. Ursprünglich besaßen die Grafikkarten dazu fest einprogrammierte Algorithmen, die zur Erstellung des Bildes genutzt werden konnten. Dies wird als sogenannte Fixed Function Pipeline (FFP) bezeichnet. Hierbei konnte der Programmierer nur einige Parameter dieser Algorithmen anpassen, aber keine weitergehenden Änderungen vornehmen. Um eine individuellere und realistischere Darstellung von Oberflächen- und Materialeigenschaften erzielen zu können, existieren daher in aktuellen Grafikchips (ab dem Jahr 2000 mit DirectX 8 [27]) kleine programmierbare Recheneinheiten, die sogenannten Shader. Diese Hardware-Shader können programmiert werden, um bestimmte 3D- Effekte zu erzielen, ohne dass durch ihre Berechnung die CPU belastet werden muss. Im Allgemeinen wird hier zwischen zwei Arten unterschieden: 5

18 Kapitel 2 Grafikkarten-Programmierung Vertex-Shader dienen dazu, die Geometrie von Objekten zu manipulieren. Dazu werden die Daten, die einen Eckpunkt oder Vertex eines übergebenen Polygons definieren, verändert. Hiermit lassen sich z. B. Effekte wie vertexbasierte Beleuchtung (Veränderung der Farbwerte des Eckpunktes) oder Wasserwellen (Veränderung der Koordinaten) erzielen. Pixel-Shader ermöglichen es, mit Programmen in die Schattierung und Texturdarstellung der einzelnen Pixel einzugreifen. Beispiele für die Anwendung von Pixel- Shadern sind pixelbasierte Beleuchtung (Phong Shading) oder Spiegelungen. 2.. Berechnungen auf Grafikprozessoren Shader waren anfangs nur für spezielle Funktionen konzipiert, die eng mit grafischen Berechnungen verknüpft waren. Um die Geschwindigkeit der Berechnung einzelner Pixel zu beschleunigen, ging man dazu über, die Berechnungen für viele Pixel gleichzeitig auszuführen, indem mehrere gleichartige Rechenwerke eingesetzt wurden. Die Shader wurden mit der Zeit so weit weiterentwickelt, dass sie nicht länger nur für ihr beschränktes Aufgabengebiet bei der Bildsynthese einsetzbar sind, sondern auch als massiv-parallele Recheneinheiten für beliebige Berechnungen zur Verfügung stehen. Eine zweite unverzichtbare Voraussetzung für die Durchführung von Berechnungen auf Grafikkarten ist, dass es Möglichkeiten gibt, Daten nicht nur zur Grafikkarte zu übertragen, sondern auch Ergebnisse von dieser zu empfangen und in den lokalen Arbeitsspeicher zu kopieren. Das Auslesen des auf der Karte befindlichen Bildspeichers, also der digitalen Kopie des Monitorbildes, wird bereits von den ersten 3D- Grafikkartengenerationen beispielsweise zur Erstellung von Screenshots unterstützt. Aus diesem Grund existierte schon sehr lange ein Rückkanal von den Grafikkarten, der auch zur Übermittlung der Ergebnisse genutzt werden kann. Das Besondere bei einer parallelen Ausführung von Shadern ist, dass hier dasselbe relativ einfache Programm auf sehr vielen unterschiedlichen Datensätzen (beim Pixel- Shader für jedes Pixel) ausgeführt wird. Aus diesem Grund wurden auch die Shader- Einheiten genau für solche Fälle konzipiert. Nach der Flynnschen Klassifikation entspricht so eine Architektur dem sogenannten Single Instruction, Multiple Data (SIMD) Model. Lässt man diese Recheneinheiten nun allgemeine Berechnungen durchführen, so stellen sie auch hierfür eine SIMD-Architektur zur Verfügung. 6

19 2. Programmierbare GPUs Im Allgemeinen wird die Verwendung des Grafikprozessors für Berechnungen außerhalb der eigentlichen Bildsynthese als General Purpose Computation on Graphics Processing Unit (GPGPU) bezeichnet. Im November 2006 brachte NVIDIA mit der GeForce 8800 die erste Grafikkarte auf den Markt, die für GPGPU genutzt werden konnte. Eine praktikable Nutzung, auch für allgemeine Berechnungen auf der GPU, wurde durch die Einführung folgender grundlegender Konzepte ermöglicht (vergleiche dazu das Fermi Whitepaper [6]): Unterstützung der Programmiersprache C, so dass die GPU ohne das Erlernen einer neuen Sprache programmiert und genutzt werden kann. Zusammenführung der getrennten Vertex- und Pixel-Shader in einem einheitlichen Prozessor, der zusätzlich auch allgemeine Berechnungen durchführen kann. Durch diese Zusammenführung entsteht eine einheitliche SIMD-Architektur. Von NVIDIA wird dies als Single Instruction, Multible Thread (SIMT) Modell bezeichnet, da mehrere unabhängige Threads gleichzeitig eine Anweisung ausführen können. Shared Memory und Barrier Synchronization, die eine Kommunikation und Koordination zwischen den einzelnen Threads erlauben. Hierdurch wurde es ermöglicht, dass auch Berechnungen für praxisrelevante Berechnungen deutlich schneller durchgeführt werden konnten als bei einer Ausführung auf der CPU. Eines der ersten Beispiele hierzu ist die in Hussein u. a. [4] vorgestellte Version eines parallelen push-relabel Algorithmus zur Berechnung von minimalen Schnitten in Graphen. Dieser Algorithmus kann die parallele Rechenleistung der Grafikkarte ausnutzen, und war so schneller als das serielle Gegenstück auf der CPU. Andere wissenschaftliche Anwendungen, die sich gut parallelisieren lassen und von daher auch von einer Ausführung auf der GPU deutlich profitieren, werden z. B. in Nyland und Harris [2] am Beispiel einer Mehrkörpersimulation oder in Stone u. a. [25] vorgestellt Ein Vergleich zwischen GPU und CPU Aufgrund ihrer verschiedenen primären Anwendungsgebiete sind GPUs nach grundlegend anderen Prinzipien konstruiert als CPUs. Eine klassische CPU versucht möglichst schnell ein einzelnes allgemeines Programm auszuführen, während eine GPU ein 7

20 Kapitel 2 Grafikkarten-Programmierung verhältnismäßig einfacheres Programm auf sehr vielen unterschiedlichen Daten laufen lässt. Wie man gut an den beiden schematischen Darstellungen in Abbildung 2. erkennen kann, besitzt die GPU deutlich mehr Recheneinheiten, auf der anderen Seite fehlt ihnen aber ein Cache. Aktuelle GPU besitzen zwar lokalen Shared Memory, auf den mehrere Recheneinheiten Zugriff haben, ein Cache im eigentlichen Sinn wird aber erst durch Karten ab der NVIDIA Fermi-Generation eingeführt [6]. Abbildung 2.: Schematischer Vergleich von CPU und GPU aus [7]. Speicher ist rot markiert und Recheneinheiten sind grün Für die GPU verwenden die Grafikkartenhersteller in diesem Zusammenhang sehr oft den Begriff von mehreren gleichzeitig ausgeführten Threads. Diese sind aber anders zu verstehen als CPU-Threads. GPU-Threads sind im Gegensatz zu ihren CPU-Pendants im Allgemeinen nicht unabhängig und können nur zusammen ausgeführt werden. Dadurch haben sie aber auch viel weniger eigene Daten, so dass Kontextwechsel wesentlich effizienter durchgeführt werden können. Mehrere Threads werden dazu in einer Gruppe zusammengefasst, die sich dann gemeinsam eine Menge von Hardware-Ressourcen teilen. Unter anderem teilen sie sich dabei auch einen einzigen Instruction Pointer. Sie können von daher alle immer nur an genau derselben Stelle im Programm sein. Dies hat zur Folge, dass bei Verzweigungen, die von unterschiedlichen Threads derselben Gruppe verschieden ausgewertet werden, alle möglichen Wege nacheinander durchlaufen werden müssen und jeder Thread dabei nur die Anweisungen seines Weges ausführt. Die Größe dieser Gruppen ist durch die Hardware festgelegt und entspricht der Mindestmenge an Daten, die gleichzeitig bearbeitet werden können. 8

21 2.2 Programmierschnittstellen für GPGPU NVIDIA bezeichnet eine Gruppe von Threads, die alle dieselbe Anweisung gleichzeitig ausführen als warp [3], bei AMD heißt sie wavefront. Ein Thread greift nicht auf den globalen Speicher der Grafikkarte zurück, sondern nur auf den lokalen Speicher. Da dieser Speicher mehreren Threads gleichzeitig zur Verfügung steht, können so Speicherzugriffe auf den globalen Speicher zusammengefasst werden. Der Zugriff auf den lokalen Speicher durch die Threads kann allerdings nicht vollständig beliebig erfolgen, sondern muss bestimmte Anforderungen einhalten: Speicher kann immer nur in Blöcken von 6 bzw. 32 Datensätzen geladen werden. Solch ein Block wird dann einer Gruppe von ebenso vielen Threads zur Verfügung gestellt. Diese Menge an Threads wird auch mit half warp bezeichnet. Wollen nun innerhalb eines half warps Threads auf unterschiedliche Blöcke zugreifen, so können diese nicht mehr in einer Operation übertragen werden, sondern es werden mehrere benötigt und auch alle anderen Threads dieses half warps müssen warten. Da Speicherzugriffe, selbst auf den lokalen Speicher, verhältnismäßig viel Zeit benötigen, sollte bei dem Entwerfen von Programmen für die GPU immer darauf geachtet werden, dass die Blockgröße bei Speicherzugriffen eingehalten wird. 2.2 Programmierschnittstellen für GPGPU Im vorherigen Abschnitt wurde erläutert, dass GPUs einen vollkommen anderen internen Aufbau besitzen als CPUs. Demzufolge muss sich natürlich auch die Programmierschnittstelle und damit auch die Herangehensweise bei der Programmierung ändern. Programme für herkömmliche CPUs bestehen aus Algorithmen, die zu jedem Zeitpunkt jeweils nur mit einem einzelnen Datenelement rechnen. Gute Compiler können jetzt automatisch innerhalb dieses Algorithmus bestimmte Teile identifizieren, die sich doch parallel ausführen lassen. Dazu verfügen CPUs seit etlichen Jahren über die sogenannten Streaming SIMD Extensions (SSE). Mittels dieser Befehle können Rechenoperationen gleichzeitig auf einem Vektor von zwei bis 6 Zahlen durchgeführt werden. Ein Vektorisieren ist dann z. B. bei Schleifen innerhalb des Programms möglich, wenn hier in jedem Durchlauf identische Berechnungen nur auf unterschiedlichen Datensätzen durchgeführt werden. Diese automatische Erkennung von Parallelität innerhalb des Algorithmus funktioniert aber nur in speziellen, sehr einfachen Fällen, so dass auch so ein Großteil des Programms seriell bleibt. Bei der Programmierung auf CPUs stellt dies kein großes 9

22 Kapitel 2 Grafikkarten-Programmierung Problem dar, da diese Prozessoren auch für serielle Programme optimiert sind. Auf einer GPU würde dies aber zu fundamentalen Problemen führen, da hier die Parallelität unbedingt ausgenutzt werden muss. Die GPU-Programmierung verfolgt daher ein grundlegend anderes Konzept. Dazu wird der Algorithmus, ähnlich wie bei der CPU, für ein einzelnes Datenelement entwickelt. Bei der Ausführung wird dann aber nicht ein einzelner Wert übergeben, auf dem gerechnet werden soll, sondern ein ganzes Array mit Daten. Durch dieses Verfahren haben wir implizit angegeben, dass sich das Programm, das die neuen Werte für das Array berechnet, für jedes einzelne Datenelement parallelisieren lässt. Hierbei ist es natürlich notwendig, dass die Berechnungen keine Abhängigkeiten untereinander aufweisen. Für die Entwicklung solcher Programme stehen vor allem OpenCL [8] und CUDA [5] zur Verfügung. Während OpenCL eine durch die Khronos Group standardisierte offene Programmierplattform ist, die für alle Grafikkarten anwendbar ist und auf mehreren Plattformen zur Verfügung steht, ist CUDA ein proprietäres Framework von NVIDA, das nur auf Karten dieses Herstellers lauffähig ist. Neben diesen beiden existierte auch noch ATI Stream als Gegenstück zu CUDA für ATI bzw. AMD Karten. Dieses basierte auf der Sprache Brook+, die eine hardwareoptimierte Version der an der Stanford University entwickelten C-ähnlichen Sprache Brook darstellt. Seit der Version 2.0 des ATI Stream SDK setzt AMD voll und ganz auf OpenCL, während Brook+ nicht mehr weiterentwickelt wird. All diese Varianten haben gemeinsam, dass ein in einer C-ähnlichen Sprache geschriebenes Programm speziell für die GPU kompiliert und an die Grafikhardware übermittelt wird. Diese Aufgabe sowie die Koordination der Grafikkarten und die Übertragung von Daten übernimmt dabei ein Host-Programm, das regulär auf der CPU ausgeführt wird. Neben den eben genannten Schnittstellen gibt es auch im Rahmen von Microsoft DirectX das sogenannte DirectCompute. DirectCompute orientiert sich dabei sehr stark an Direct3D, so dass hier auch die High Level Shading Language (HLSL) als Programmiersprache für die GPU Verwendung findet CUDA Die Compute Unified Device Architecture, kurz CUDA genannt, wurde von NVIDIA am 5. Feburar 2007 durch den ersten CUDA SDK veröffentlicht. Sie wird von allen 0

23 2.2 Programmierschnittstellen für GPGPU NVIDIA GPUs ab G80 Grafikserie unterstützt und ist damit jetzt in GeForce, Ion, Quadro und Tesla Grafikprozessoren verfügbar. Weitere Informationen zu CUDA können z. B. auf der CUDA-Homepage [5] oder im Programming Guide [8] gefunden werden OpenCL Im Gegensatz zu CUDA ist OpenCL eine Programmierplattform, die einen Standard zur allgemeinen parallelen Programmierung darstellt. OpenCL ist daher nicht nur auf die GPU beschränkt, sondern bezieht sich explizit auch auf CPUs und andere Prozessoren wie Digitale Signalprozessoren (DSPs) und dem IBM Cell-Prozessor. Die Spezifikation für OpenCL.0 wurde am 8. Dezember 2008 veröffentlicht. Am 5. Juni 200 folgte die Spezifikation. mit weitreichenden Verbesserungen, die aber zu der Version.0 vollständig abwärts kompatibel ist. OpenCL ist im Gegensatz zu CUDA für die Benutzung von diversen Prozessorarten ausgelegt. Dadurch ist das Konzept etwas allgemeiner gehalten und nicht speziell für die Nutzung von GPUs optimiert. Dies macht sich auch in der Geschwindigkeit bemerkbar, wenn man die Ausführung von OpenCL-Programmen mit der Ausführung in CUDA auf identischer Grafikhardware vergleicht. Von Karimi u. a. [7] konnte so für ein spezielles praxisrelevantes Problem ermittelt werden, dass OpenCL hier ca. 0 % bis 60 % langsamer ist DirectCompute Im Rahmen der Einführung von DirectX am 22. Oktober 2009 stellte auch Microsoft zum ersten Mal die Möglichkeit zur Verfügung mit DirectX Berechnungen auf der GPU auszuführen. Auch wenn DirectCompute ein Feature von DirectX ist, so wird es doch auch von Karten mit DX0-Hardware unterstützt und kann auf entsprechenden Karten sowohl von NVIDIA als auch AMD genutzt werde. Allerdings sind bisher DirectCompute-Anwendungen deutlich weniger verbreitet als Eine Liste von GPUs die CUDA unterstützen kann unter gpus.html gefunden werden.

24 Kapitel 2 Grafikkarten-Programmierung Anwendungen in CUDA oder OpenCL. Dies ist wahrscheinlich darauf zurückzuführen, dass für DirectCompute-Programmierung HLSL verwendet werden muss, was im Vergleich zu den sehr C-ähnlichen Programmen der Konkurrenten eine höhere Einstiegshürde darstellt. 2

25 Kapitel 3 OpenCL OpenCL (Open Computing Language) is an open royalty-free standard for general purpose parallel programming across CPUs, GPUs and other processors, giving software developers portable and efficient access to the power of these heterogeneous processing platforms. Erster Absatz der OpenCL Spezifikation [9] Da es, wie bereits in Kapitel geschildert, das Ziel dieser Untersuchung ist eine OpenCL-konforme transparente Multi-GPU Unterstützung zu ermöglichen, werden wir in diesem Kapitel ausführlicher speziell auf OpenCL eingehen. Aus diesem Grund orientiert sich dieses Kapitel sehr stark an der OpenCL Spezifikation [9]. Weiterführende Informationen können auch dort nachgelesen werden. Hierzu werden in den ersten Abschnitten 3. und 3.2 die grundlegenden OpenCL- Begriffe sowie die entscheidenden Design-Entscheidungen erläutert. Im nächsten Abschnitt 3.3 wird dann kurz auf die wesentlichen Besonderheiten der OpenCL Programmiersprache eingegangen, bevor in Abschnitt 3.4 die zur Zeit verfügbaren OpenCL- Implementierungen aufgelistet werden. 3. Architektur Ein OpenCL-System besteht immer aus einem Host und einem oder mehreren OpenCL- Geräten. Ein Gerät besteht aus einer oder mehreren unabhängigen Recheneinheiten oder Compute Units (CU), welche wiederum in Processing Elements (PEs) aufgeteilt werden, die die eigentlichen Berechnungen durchführen. 3

26 Kapitel 3 OpenCL OpenCL-Gerät Compute Unit OpenCL-Gerät Processing Processing Compute Unit Processing Element Element Element Processing Processing Compute Compute Unit Processing Unit Element Element Element OpenCL-Gerät Processing Processing Processing Processing Compute Processing Unit Processing Element Element Element Element Element Element Processing Processing Compute Compute Unit Processing Unit Element Element Element Processing Processing Processing Processing Compute Processing Unit Processing Element Element Element Element Element Element Processing Processing Compute Unit Processing Element Processing Element Element Processing Element Element Processing Element Host Abbildung 3.: Hierarchische Darstellung einer OpenCL-Plattform und ihrer Komponenten All diese Einheiten zusammen werden in der OpenCL-Spezifikation als eine Plattform bezeichnet. Hierbei ist es ausdrücklich erlaubt und erwünscht, dass unterschiedliche Gerätetypen (wie z. B. CPUs und GPUs) und Geräte mit unterschiedlichen OpenCL- Versionen in einer Plattform aufgeführt werden. Die Ausführung eines OpenCL Programmes kann in zwei unterschiedliche Teile gegliedert werden:. Sogenannte Kerne (Kernels), dies sind die eigentlichen Programme, die dann auf einem OpenCL-Gerät ausgeführt werden. 2. Ein Host-Programm, das die Initialisierung durchführt und die Ausführung der Kerne koordiniert. Eine der wichtigen OpenCL-Design-Entscheidungen wird deutlich, wenn wir uns anschauen, wie die Kerne auf den Geräten ausgeführt werden: Wenn ein Kern vom Host an ein Gerät zur Ausführung übergeben wird, dann wird er immer zusammen mit einer Indexmenge übergeben. Auf dem Gerät wird dann genau eine Instanz des Kerns für jedes Element aus dieser Indexmenge aufgerufen. In OpenCL werden diese Instanzen als work-items und ihr entsprechender Index als global ID bezeichnet. Diese work-items führen dann alle denselben Code aus; lediglich die Daten, auf denen 4

27 3. Architektur gerechnet wird, können von der ID abhängen und damit für die Instanzen unterschiedlich sein. In einer etwas gröberen Unterteilung der zu bearbeitenden Indexmenge werden mehrere work-items in einer work-group zusammengefasst. Alle work-items einer work-group werden dabei von den PEs einer CU quasi-gleichzeitig ausgeführt. Aus diesem Grund existieren auch Methoden um die items einer work-group zu koordinieren. Die Anzahl der work-items innerhalb einer work-group, die tatsächlich vollständig parallel ausgeführt werden, entspricht genau der Größe der in Kapitel 2 eingeführten Warps bzw. Wavefronts. Bevor tatsächlich Berechnungen durchgeführt werden können, muss vorher von dem Host durch entsprechende Funktionen der OpenCL-API ein sogenannter Kontext erstellt werden. Dieser Kontext enthält alle Ressourcen, die für das Ausführen von Kernen benötigt werden. Er umfasst dabei insbesondere: die Geräte, die benutzt werden, die auszuführenden Kerne, die Speicherobjekte, die die Daten enthalten, auf denen die Kerne arbeiten. Es ist möglich mehrere unterschiedliche Kontexte zu erstellen; es kann jedoch ein Kern jeweils nur auf den Geräten und mit den Speicherobjekten ausgeführt werden, die auch mit ihm im Kontext liegen. Zur eigentlichen Ausführung werden die Kerne dann an die Befehlswarteschlange (command queue) eines Gerätes übergeben. Ab diesem Zeitpunkt übernimmt dann die OpenCL Implementation die Koordination der Ausführung. Da jede Warteschlange nur mit genau einem Gerät verbunden ist, wird durch die Nutzung einer bestimmten Befehlswarteschlange auch das zu nutzende Gerät festgelegt. Diese Auswahl muss also vom Host-Programm und damit vom Programmierer getroffen werden. Standardmäßig werden die OpenCL-Befehle in genau der Reihenfolge ausgeführt, in der sie an die Warteschlange übergeben werden. Es steht aber auch die Möglichkeit zur Verfügung dieses Verhalten für eine Befehlswarteschlange durch das Setzen der Eigenschaft CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE zu deaktivieren. In diesem Zustand ist es der Implementation überlassen, in welcher Reihenfolge die übergebenen Befehle ausgeführt werden. In Listing 3. wird ein einfaches Host-Programm dargestellt, das einen OpenCL-Kern ausführt. Dazu müssen, wie gerade beschrieben, erst Plattform, Kontext und Warteschlange festgelegt werden. Nach Abschluss des Kerns werden die erzeugten Daten in den Arbeitsspeicher des Hosts kopiert. 5

28 Kapitel 3 OpenCL // g e t the f i r s t p l a t f o r m clgetplatformids (, &platform, NULL) ; // g e t a GPU d e v i c e in the p l a t f o rm clgetdeviceids ( platform, CL_DEVICE_TYPE_GPU,, &device, NULL) ; // c r e a t e a c o n t e x t c o n t a i n i n g t h i s d e v i c e context = clcreatecontext (NULL,, &device, NULL, NULL, NULL) ; // a l s o c r e a t e a command queue f o r the d e v i c e queue = clcreatecommandqueue ( context, NULL, device, NULL) ; // c r e a t e a memory o b j e c t and f i l l i t with data from the h o s t memobj = c l C r e a t e B u f f e r ( context, CL_MEM_READ_WRITE CL_MEM_COPY_HOST_PTR, sizeof ( float ) num_entries, src, NULL) ; // c r e a t e the compute program and b u i l d i t program = clcreateprogramwithsource ( context,, &kernel_src, NULL, NULL) ; clbuildprogram ( program, 0, NULL, NULL, NULL, NULL) ; // c r e a t e the k e r n e l and s e t i t s argument k e r n e l = c l C r e a t e K e r n e l ( program, "foo_bar", NULL) ; clsetkernelarg ( kernel, 0, sizeof (cl_mem ), ( void )&memobj ) ; // e x e c u t e the k e r n e l and then wait f o r i t s completion global_work_size [ 0 ] = num_entries ; local_work_size [ 0 ] = 3 2 ; clenqueuendrangekernel ( queue, kernel,, NULL, global_work_size, local_work_size, 0, NULL, NULL) ; c l F i n i s h ( queue ) ; // read the data from the d e v i c e and s a f e i t on the h o s t clenqueuereadbuffer ( queue, memobj, true, 0, sizeof ( float ) num_entries, dest, 0, NULL, NULL) ; Listing 3.: Beispielcode, der den Aufruf eines Kernels in OpenCL ohne Fehlerbehandlung darstellt Obwohl es möglich ist, mehrere Warteschlangen in einem Kontext zu haben, führt OpenCL selbst keine implizite Synchronisation zwischen ihnen durch. Zu diesem Zweck gibt es aber spezielle OpenCL-Ereignisse. Diese Ereignisse können an einen bestimmten Kern gekoppelt werden, so dass der Status des Ereignisses genau den Stand der Ausführung dieses Kerns widerspiegelt. 6

29 3.2 Speichermodell Bei der Übergabe eines Kerns an eine Warteschlange kann zusätzlich auch noch eine Liste von diesen Ereignissen mitgegeben werden. Der neue Kern darf dann nur starten, wenn alle Ereignisse eingetreten und damit alle ihre Kerne beendet sind. Hiermit können so auch beliebige Abhängigkeiten der Kerne untereinander modelliert werden. Bei der Nutzung einer Warteschlange ist dies nur relevant, wenn Out-of-order Execution aktiviert ist. Im anderen Fall ist die Ausführungsreihenfolge schon durch das Übergeben an die Befehlswarteschlange eindeutig definiert. Zusätzlich dazu kann der Status der Ereignisse auch im Host-Programm abgefragt werden, womit es auch hier möglich wird, auf das Ende von bestimmten Kernen zu warten. Diese eben beschriebene Architektur muss auch bei einer OpenCL-konformen Implementation der MetaQueue eingehalten werden. Hierzu bietet es sich an, eine eigene Plattform für die MetaQueue zu nutzen. Diese Plattform enthält für jeden Gerätetyp ein virtuelles Gerät, das sich auf alle Geräte der Herstellerimplementation bezieht. Existieren zu einem Typ keine Herstellergeräte, so ist auch das entsprechende virtuelle Gerät nicht vorhanden. Die Befehlswarteschlange zu einem dieser Geräte entspricht in diesem Falle genau der eigentlichen MetaQueue. Damit durch diese Warteschlange auch implizit mehrere reale Geräte genutzt werden können, muss Out-of-order Execution erlaubt sein. Ist dies verboten, so kann die MetaQueue nicht mehr als ein Gerät gleichzeitig nutzen. 3.2 Speichermodell In OpenCL werden folgende Arten von Speicher unterschieden: Host-Speicher (host memory): Beim Host-Speicher handelt es sich um den regulären Arbeitsspeicher des Hosts; Gerätspeicher: Speicher, der auf dem OpenCL-Gerät liegt. Er wird weiter wie folgt unterteilt: globaler Speicher (global memory): Auf diesen Speicher können alle workitems in allen work-groups sowohl lesend als auch schreibend zugreifen; konstanter Speicher (constant memory): Ein Bereich des globalen Speichers, der während der Ausführung eines Kerns nicht verändert werden kann. Der Host kann dazu Objekte in dem konstanten Speicher platzieren; 7

30 Kapitel 3 OpenCL lokaler Speicher (local memory): Ein lokaler Speicherbereich für eine workgroup. Dieser Speicherbereich kann für Variablen genutzt werden, die von allen work-items in dieser work-group geteilt werden; privater Speicher (private memory): Dieser Speicher ist nur einem workitem vorbehalten. Andere work-items und der Host können auf den Inhalt dieses Speichers nicht zugreifen. Host-Speicher Host Kontext globaler und konstanter Speicher work-group lokaler Speicher work-group lokaler Speicher work-item work-item work-item work-item privater Speicher privater Speicher privater Speicher privater Speicher Abbildung 3.2: Das OpenCL-Speichermodell In dem OpenCL-Speichermodell sind der Hostspeicher und der Gerätespeicher weitestgehend unabhängig voneinander. Sie interagieren nur miteinander, wenn Daten von dem einen in den anderen kopiert werden. Der Gerätespeicher wird daher durch ein OpenCL-Speicherobjekt repräsentiert, welches dann als Argument an einen Kern übergeben wird. Es stehen außerdem explizite Befehle zur Verfügung, um Daten zwischen Host und Speicherobjekt zu transferieren. Da dieser Vorgang von dem Gerät abhängt, müssen diese Befehle genau wie Kerne an eine bestimmte Warteschlange übergeben werden. 3.3 OpenCL C Die OpenCL C Programmiersprache basiert auf der Syntax von C99 und damit dem ISO-Standard ISO/IEC 9899:999. 8

31 3.3 OpenCL C Die Sprache wurde darüber hinaus um Vektordatentypen mit 2, 3 (seit OpenCL.), 4, 8 und 6 Elementen erweitert. Die Operatoren (+,,, /,... ) wurden dabei so angepasst, dass sie sowohl auf skalare Datentypen als auch auf den Vektordatentypen definiert sind. Es existieren auch einfache mathematische Funktionen wie sin, acos oder floor, die ebenfalls komponentenweise auf Vektoren angewendet werden können. Es ist außerdem sichergestellt, dass auch Möglichkeiten zur Synchronisation, Funktionen zum Umgang mit work-items/groups sowie Flags für die unterschiedlichen Speicherbereiche vorhanden sind. Ein einfaches Beispiel für einen Kern, der einige von den erweiterten Möglichkeiten von OpenCL C nutzt, ist im Listing 3.2 dargestellt. Dieses Beispiel stammt aus dem NVIDIA GPU Computing SDK [4]. kernel void t r a n s p o s e ( global float odata, global float idata, int o f f s e t, int width, int height, local float l o c a l ) { unsigned int xindex = get_global_id ( 0 ) ; unsigned int yindex = get_global_id ( ) ; } // read the matrix t i l e i n t o shared memory i f ( ( xindex + o f f s e t < width ) && ( yindex < h e ight ) ) { unsigned int index_ in = yindex width + xindex + o f f s e t ; l o c a l [ get_local_id ( ) (BLOCK_DIM+)+get_local_id (0)]= i d a t a [ index_in ] ; } // wait u n t i l a l l work items are done b a r r i e r (CLK_LOCAL_MEM_FENCE) ; // w r i t e the transposed matrix t i l e to g l o b a l memory xindex = get_group_id ( ) BLOCK_DIM + get_local_id ( 0 ) ; yindex = get_group_id ( 0 ) BLOCK_DIM + get_local_id ( ) ; i f ( ( xindex < h e i g h t ) && ( yindex + o f f s e t < width ) ) { unsigned int index_ out=yindex h e i g h t + xindex ; odata [ index_out ]= l o c a l [ get_local_id ( 0 ) (BLOCK_DIM+)+get_local_id ( ) ] ; } Listing 3.2: Beispiel für ein OpenCL Programm: Matrixtransposition durch Verwendung von lokalem Speicher und Synchronisation zur Vermeidung von Bankkonflikten 9

32 Kapitel 3 OpenCL 3.4 Implementierungen Genau wie z. B. auch bei OpenGL wird für OpenCL von der Khronos Group lediglich die Spezifikation der Programmschnittstelle standardisiert. Diese API muss dann noch implementiert werden, so dass sie auf Hardware tatsächlich lauffähig wird. Seit Einführung des Standards ist OpenCL inzwischen auf immer mehr Hardware implementiert : NVIDIA bietet seit 2009 eine OpenCL-Implementierung für ihre GPGPU-Schnittstelle CUDA unter Linux, Windows und Mac OS X an [20]. Die ebenfalls seit 2009 existierende OpenCL-Implementierung von AMD ermöglicht neben der Nutzung von GPUs zusätzlich auch die Nutzung von CPUs mit SSE 3 für Linux und Windows. Seit 200 bietet auch IBM eine Implementierung für ihre Prozessoren und damit unter anderem auch den Cell-Prozessor an. Inzwischen stellt auch Intel eine Implementierung der OpenCL-Spezifikation. für ihre Core- und Xeon-Prozessoren zur Verfügung [6]. Diese Implementierung unterstützt allerdings bis jetzt nur die CPU, nicht aber die integrierten Grafikeinheiten. Bisher existiert allerdings noch keine Implementierung im Rahmen der OpenSource Linux Grafikkartentreiber. In 2009 wurde das Projekt Clover von Zack Rusion [22] öffentlich, das OpenCL-Unterstützung für die freie Grafikbibliothek Mesa liefern sollte. Allerdings ist dieser Code selbst nach zwei Jahren noch in einem unvollständigen Zustand und noch weit von einer funktionierenden Implementierung entfernt. Im Rahmen des Google Summer of Code 20 existiert auch ein neues Projekt von Denis Steckelmacher, das es als Ziel hat, Clover weiter auszubauen und gemäß der OpenCL-Spezifikation zu vervollständigen [24]. Zum jetzigen Zeitpunkt besitzt Clover bereits eine im Wesentlichen vollständige Unterstützung zur Nutzung der CPU unter OpenCL. Die vollständige Liste der OpenCL-konformen Produkte, kann unter adopters/conformant-products/#topencl gefunden werden 20

33 Kapitel 4 Bündelung mehrerer GPUs Die MetaQueue In diesem Kapitel wird auf die theoretischen und praktischen Überlegungen eingegangen, die für eine mehrere Geräte umfassende MetaQueue erforderlich sind. Hierzu wird in den Abschnitten 4. und 4.2 vorgestellt, für welche primären Konstellationen das Verfahren entwickelt wurde, wie sich diese formalisieren lassen und welche anderen theoretischen Resultate es zu verwandten Problemen gibt. Der Abschnitt 4.3 widmet sich dann einem Konzept, mit dem sich die MetaQueue in die OpenCL-Spezifikation einbauen und wie sich eine bestehenden OpenCL-Implementation effizient um die zusätzlichen Funktionen erweitern lässt. Anschließend (Abschnitt 4.4) wird dann eine Heuristik eingeführt, die unter den gegebenen Voraussetzungen eine vernünftige Zuteilung vornehmen kann. Dazu werden eine Reihe von Aspekten beschrieben, die wichtig für eine gute Zuteilung sind, und wie sie effektiv umgesetzt werden können. Schließlich wird dann im letzten Abschnitt untersucht, welche zusätzlichen Datenstrukturen und Algorithmen, die so nicht durch die OpenCL-Spezifikation zur Verfügung gestellt werden, erforderlich sind um diese Heuristik umzusetzen. 4. Strukturelle Voraussetzungen für die MetaQueue Wie bereits in Abschnitt. geschildert, ist die Aufgabe der MetaQueue eine virtuelle Warteschlange zur Verfügung zu stellen, deren Befehle dann intern möglichst effizient 2

34 Kapitel 4 Bündelung mehrerer GPUs Die MetaQueue auf die eigentlichen Grafikkarten aufgeteilt und weitergereicht werden. Hierbei beschäftigen wir uns speziell mit dem Fall, dass eine verhältnismäßig hohe Anzahl von untereinander abhängenden Befehlen ausgeführt werden soll. Formal definiert sind also folgende Aspekte gegeben: eine Menge C von Befehlen, die auf den Grafikkarten ausgeführt werden sollen; eine Menge M von OpenCL-Speicherobjekten, wobei jedem Befehl c C eine Teilmenge M c M von Speicherobjekten zugeordnet ist; ein azyklischer und gerichteter Präzedenzgraph P := (A, C); hierbei bedeutet die Kante (u, v) A mit u, v C, dass der Befehl u beendet sein muss, bevor v gestartet werden kann. Ein Befehl c C darf dabei nur auf Speicherobjekte aus M c zugreifen. Die Abhängigkeiten in P bestimmen sich aus den Abhängigkeiten, die beim Einreihen in die Warteschlange in Form von OpenCL-Ereignissen übergeben wurden. Der Begriff Befehl soll sich hierzu im Folgenden immer sowohl auf OpenCL-Kerne als auch Lese- und Schreiboperationen auf den OpenCL-Speicherobjekten beziehen. Zusätzlich bestehen folgende natürlichen Bedingungen:. Ein Befehl benutzt auch tatsächlich alle ihm zugeordneten Speicherobjekte, indem er entweder Daten in ihnen verändert oder seine Ausführung von diesen Daten abhängt. 2. Es dürfen nur Speicherobjekte gelesen werden, die in irgendeiner Form bereits initialisiert wurden. 3. Die Abhängigkeiten sind so gegeben, dass durch unterschiedliche Ausführungsreihenfolgen, die aber alle P erfüllen, die Ergebnisse nicht verändert werden. Ist die erste Bedingung nicht erfüllt, so führt dies zwar trotzdem zu korrekten Ergebnissen, allerdings werden Speicherabhängigkeiten vorausgesetzt, die eigentlich nicht erforderlich sind. Hierdurch könnte das Ergebnis der automatischen Zuteilung deutlich schlechter ausfallen. Ist die letzte Voraussetzung 3 nicht erfüllt, so widerspricht dies den Voraussetzungen der Out-of-order Execution in der OpenCL-Spezifikation. Ein entsprechendes Vorgehen und Ergebnis ist daher nicht mehr definiert. Etwas formaler können wir also davon ausgehen, dass folgende Bedingungen erfüllt sein müssen: 22

35 4.2 Theoretischer Hintergrund Greifen zwei Befehle c, c 2 C auf dasselbe Speicherobjekt m M zu, wobei mindestens einer der beiden Zugriffe schreibend ist, so besteht zwischen c und c 2 eine Abhängigkeit, d.h. es muss in P entweder ein Pfad von c nach c 2 oder von c 2 nach c existieren. Greift ein Befehl c r lesend auf das Speicherobjekt m M zu, so hängt er auch von einem Befehl c w ab, der auf m schreibt. Durch diese Bedingungen ist sichergestellt, dass wir an P auch die Zugehörigkeiten zu den Speicherobjekten ablesen können: Dazu betrachten wir die ungerichtete Version P UD von P. P UD enthält hierbei die ungerichtete Kante {v, w} genau dann, wenn (v, w) oder (w, v) in P enthalten ist. Sind unter diesen Voraussetzungen zwei Befehle c und c 2 in P UD nicht verbunden, so wissen wir dadurch auch, dass diese Befehle nicht auf ein gemeinsames Speicherobjekt zugreifen können. Die Ausführungszeit eines Befehls hängt nicht nur von der Grafikkarte d ab, auf der der Befehl gestartet werden soll. Zusätzlich dazu benötigt ein Befehl auch noch Zeit, um von ihm benutzte Speicherobjekte, die zum Zeitpunkt der Ausführung noch nicht auf d liegen, von einer anderen Grafikkarte dorthin zu kopieren oder zu verschieben. Unter diesen Voraussetzungen suchen wir also einen zulässigen Plan, der festlegt, wann ein Befehl auf welcher Grafikkarte ausgeführt wird und bei dem möglichst früh alle Befehle fertig ausgeführt sind. Eine formalisierte Form dieser Aussage werden wir im nächsten Abschnitt an einer etwas vereinfachten Problemstellung betrachten. 4.2 Theoretischer Hintergrund Für den folgenden Abschnitt gehen wir von folgenden vereinfachenden Annahmen aus: Die Befehle sind unabhängig voneinander, d.h. es sind keine Präzendenzbedingungen vorhanden. Alle Befehle sowie deren Ausführungszeiten sind a priori bekannt. Der Kommunikationsaufwand zum Verschieben von Speicherinhalten zwischen unterschiedlichen Geräten entfällt komplett. 23

36 Kapitel 4 Bündelung mehrerer GPUs Die MetaQueue Unter diesen vereinfachten Bedingungen erhalten wir dann ein Multiprocessor Scheduling Problem: Definition 4. (Multiprocessor Scheduling Problem) Gegeben sei eine Anzahl m Z + von Prozessoren sowie eine Menge T von Prozessen, wobei jeder Prozess t T die Rechenzeit l t Z + hat. Frage: Was ist unter diesen Voraussetzungen die kürzest mögliche Zeit D, die benötigt wird um die Prozesse ohne Überlappungen einzuplanen? Wir suchen also das kleinste D Z + für das es eine Funktion σ : T Z + 0 gibt, die die folgenden Eigenschaften erfüllt: (a) Für alle u 0 ist die Anzahl von Prozessen t T mit σ(t) u < σ(t) + l t nicht größer als m. (b) Für alle t T gilt σ(t) + l t D. In unserem Fall entsprechen dabei die m Prozessoren den vorhandenen Grafikkarten und die Prozesse entsprechen den einzuplanenden OpenCL-Kernen mit bekannter Ausführungszeit. Leider ist selbst schon diese vereinfachte Variante schwer: Satz 4.2 Das aus dem Multiprocessor Scheduling Problem resultierende Entscheidungsproblem ist N P-vollständig. Beweis: Beweis durch Reduktion von PARTITION. (Für den Beweis der N P-Vollständigkeit des Partitionsproblem siehe z. B. Garey und Johnson [2, Abschnitt 3..5]) Satz 4.3 Das aus dem Multiprocessor Scheduling Problem resultierende Entscheidungsproblem mit m > 2 ist stark N P-vollständig. Beweis: Beweis durch Reduktion von 3-PARTITION. (Für eine ausführliche Erläuterung siehe Garey und Johnson [2]) Unser Problem wird dann im Vergleich zum Multiprocessor Scheduling Problem um den Präzendenzgraphen und prozessor- und vorgängerabhängige startup times erweitert. Da das Multiprocessor Scheduling Problem an sich ein Spezialfall davon ist, ist es ebenfalls N P-schwer. 24