Implementierung eines GPU-beschleunigten Kalman-Filters mittels OpenCL

Transkript

1 Implementierung eines GPU-beschleunigten Kalman-Filters Track Fitting für das ATLAS-Experiment am CERN Masterarbeit vorgelegt von: Maik Dankel, B.Sc. Matrikelnummer: Erstgutachter: Zweitgutachter: Prof. Dr. rer. nat. Nikolaus Wulff Dr. Sebastian Fleischmann Datum: c 2013

2 Dieses Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwertung ausserhalb der engen Grenzen des Urheberrechtgesetzes ist ohne Zustimmung des Autors unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen sowie die Einspeicherung und Verarbeitung in elektronischen Systemen. c Maik Dankel

3 Zusammenfassung Diese Masterarbeit befasst sich mit der Frage, ob die Portierung eines Algorithmus zur Spurrekonstruktion auf GPUs einen Performancegewinn gegenüber konventionellen CPU-Algorithmen erzielen kann. Es werden verschiedene Konzepte und der technologische Hintergrund erörtert, der nötig ist, um das Programmiermodell von GPGPU Anwendungen zu verstehen. Anschließend wird ein Kalman-Filter mittels der, von der Khronos Group entwickelten, OpenCL API implementiert. Es werden Zeitmessungen vorgenommen, die die Laufzeit des Algorithmus mit denen einer CPU-Implementierung vergleicht. Die Ergebnisse zeigen, dass der Algorithmus, der sich der GPGPU Technologie bedient, lediglich 37% der ursprünglichen Ausführungszeit benötigt. Abstract This Master s thesis deals with the question if porting a track-fitting algorithm to GPUs can obtain a better performance than running a conventional CPU algorithm. First various concepts and the technological background necessary to understand the programming model are discussed in detail. Then a Kalman-Filter is implemented using the OpenCL API introduced by Khronos Group. The execution time of the algorithm is measured and compared with the execution time of a CPU algorithm. The results show that the GPGPU algorithm only takes 37% of the original calculation time. c Maik Dankel

4 Danksagung An dieser Stelle möchte ich mich herzlich bei all denen bedanken, die mich bei der Anfertigung dieser Masterarbeit unterstützt haben. Der größte Dank gilt Herrn Prof. Dr. rer. nat. Nikolaus Wulff, der es mir ermöglicht hat diese Arbeit anzufertigen und der den Kontakt zu der Wuppertaler Gruppe des ATLAS-Experiments hergestellt hat. Weiter bin ich Herrn Dr. Sebastian Fleischmann für die durchgehend freundliche und geduldige Beratung und Betreuung während des Projektes zu großem Dank verpflichtet. An dieser Stelle sei auch der restlichen ATLAS-Forschungsgruppe aus Wuppertal, insbesondere Herrn Prof. Dr. Peter Mättig, für die freundliche Zusammenarbeit gedankt. Auch meinem Projektpartner Rene Böing danke ich für die konstruktive Zusammenarbeit und auch das Korrekturlesen meiner Arbeit. An dieser Stelle sei auch dem Masterprojekt-Team, bestehend aus Philipp Schoppe und Matthias Töppe, für ihre Unterstützung gedankt. Auch meinen weiteren Korrekturlesern bin ich für ihre Hilfe sehr dankbar. Außerdem allen Weiteren, die direkt oder indirekt bei der Erstellung dieser Arbeit beteiligt waren. c Maik Dankel

5 Inhaltsverzeichnis Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Verzeichnis der Listings III IV V 1. Einleitung Motivation Ziel der Arbeit GPGPU Graphic Processing Units Architektur SMX OpenCL Host-Code Device-Code / Kernel Speichermodell Asynchrone Verarbeitung und Synchronisation Kalman-Filter Definition Startwerte Smoothing Implementierung Data-IO und Datenstrukturen Host-Code Device-Code Kalman-Filter Smoothing c Maik Dankel I

6 Inhaltsverzeichnis 4.4. Optimierungen Track-Parallelisierung Asynchrone Verarbeitung Host-Parallelisierung Numerische Stabilität und Symmetrie Matrixinvertierung Performance-Vergleich Optimierungsstufen OpenCL / CUDA / CPU Fazit Ausblick 66 Literaturverzeichnis 67 Eidesstattliche Erklärung 69 A. Anhang i c Maik Dankel II

7 Abkürzungsverzeichnis Abbildungsverzeichnis 1.1. Schematische Darstellung des ATLAS Detektors Komplettes Blockdiagramm des GK Blockdiagramm einer SMX-Einheit eines GK110-Chips Arbeitsweise des Warp Schedulers Aufbau einer OpenCL Plattform Veranschaulichung von Global- und Local-ID Veranschaulichung von Work-Groups, Work-Items und Dimensionen OpenCL Speichermodell Synchronisierung von Work-Items Der rekursive Ablauf des Kalman-Filters. Der time update Schritt bildet den aktuellen Zustand auf einen geschätzten zukünftigen Wert ab. Der measurement update Schritt korrigiert den geschätzten Wert mittels einer aktuellen Messung Schematische Darstellung von Teilchenspur und verfälschter Messung innerhalb eines Detektors Schematische Darstellung der durch den Kalman-Filter korrigierten Spur Arbeitsweise der Implementation Speicheraufteilung Track Parallelisierung Speicheraufteilung c Maik Dankel III

8 Tabellenverzeichnis Tabellenverzeichnis 4.1. Hilfsfunktionen Matrix-/Vektor-Multiplikation Spezifikationen des Testsystems Eigenschaften des verwendeten Testdatensatzes Performancevergleich Optimierungsstufen Ausführungszeiten der Implementierungen Performancevergleich der Implementierungen mit Benchmarks Performancevergleich der Implementierungen mit Benchmark c Maik Dankel IV

9 Verzeichnis der Listings Verzeichnis der Listings 2.1. oclgetplatformid() Signatur clgetdeviceids() Signatur clcreatecontext() Signatur clcreatecommandqueue() Signatur clcreatebuffer() Signatur clenqueuewritebuffer() Signatur clcreateprogramwithsource() Signatur clbuildprogram() Signatur clcreatekernel() Signatur clsetkernelarg() Signatur clenqueuendrangekernel() Signatur clenqueuereadbuffer() Signatur OpenCL clean-up Methoden OpenCL Synchronisationspunkt barrier() clwaitforevents() Signatur clfinish() Signatur Definition eines Events Definition eines Tracks Definition eines Tracks Pseudocode Filtering-Prozess Überprüfung der Dimensionalität Invertierung der Kovarianzmatrizen Pseudo-Code Filtering-Kernel Funktionskopf des dofiltering Kernels Start des Vorwärts-Fits Time-Update Hilfsfunktion Hilfsfunktion zur Matrix-Vektor-Multiplikation Erster Teil der Berechnung von C k k Zweiter Teil der Berechnung von C k k c Maik Dankel V

10 Verzeichnis der Listings Berechnung von K k im eindimensionalen Fall Kalman-Gain: Invertierung 2D Kalman-Gain: Matrixmultiplikation 2D Berechnung p k k 1D Berechnung p k k 2D Berechnung C k k 1D Berechnung C k k 1D Smoothing Kernel Verwendung von Work-Groups Datenstruktur für die Nutzung des OpenCL Eventmodells Pseudocode asynchrone Verarbeitung A.1. Minimalbeispiel einer OpenCL Implementierung i c Maik Dankel VI

11 1. Einleitung 1. Einleitung Das europäische Kernforschungszentrum CERN (Conseil Européen pour la Recherche Nucléaire) mit Sitz in Meyrin (Kanton Genf) ist eine Großforschungseinrichtung, die sich mit physikalischer Grundlagenforschung beschäftigt. Insbesondere werden mit Hilfe des "Großen Hadronen-Speicherrings" (engl.: Large Hadron Collider, kurz: LHC), dem weltgrößten Teilchenbeschleuniger, die grundlegenden Bestandteile der Materie erforscht. Dort werden Teilchen mit annähernd Lichtgeschwindigkeit zur Kollision gebracht, was den Physikern Aufschluss darüber gibt, wie diese Teilchen miteinander wechselwirken. Außerdem erhofft man sich neue Erkenntnisse über die fundamentalen Naturgesetze[CERN]. Dem LHC angeschlossen sind sieben Experimente, die Teilchendetektoren betreiben, um die unzähligen, bei der Kollision erzeugten Teilchen, zu messen und zu analysieren. Diese werden von Kollaborationen von Wissenschaftlern weltweit betrieben. Die beiden größten Experimente sind ATLAS und CMS, die unabhängig voneinander konzipiert wurden, was unverzichtbar ist, um neue Entdeckungen validieren zu können Motivation ATLAS ist eines der großen Experimente am LHC des CERN. Der Detektor ist mit einer Länge von etwa 45 Metern und einem Durchmesser von 25 Metern der größte Detektor am LHC (siehe Abbildung 1.1). Ziel des Experiments ist die Suche nach unentdeckten Teilchen, wie zum Beispiel dem Higgs-Boson, sowie die Untersuchung einer womöglich vorhandenen Substruktur von Leptonen und Quarks, beides Klassen von Elementarteilchen aus dem Standardmodell der Teilchenphysik. Um diese Teilchen zu finden und zu analysieren werden Protonen oder Blei- Ionen zu Strahlen gebündelt und bei nahezu Lichtgeschwindigkeit zur Kollision gebracht, um die Wechselwirkung dieser Teilchen bei sehr hohen Energien c Maik Dankel 1

12 1. Einleitung Abbildung 1.1.: Schematische Darstellung des ATLAS Detektors. Quelle: [ATLAS] (nach dem Anfang 2013 eingeleiteten, etwa 2-jährigen technischen Stopp (LS1), bis zu 14TeV Schwerpunktenergie) zu untersuchen. Bei der Kollision entsteht eine Wechselwirkung zwischen den kollidierten Teilchen und diese zerfallen in weitere Subteilchen. Die einzelnen Sekundärteilchen zerfallen ihrerseits wieder in weitere Teilchen. Die so entstehenden Teilchenschauer erzeugen Myriaden von Messpunkten, die es auszuwerten gilt. Das ATLAS-Experiment erzeugt mit den Messungen dieser Teilchenschauer gewaltige Datenmengen von über 300 MB pro Sekunde [ATLAS], die auszuwerten aktuell sehr viel Zeit in Anspruch nimmt. Aus diesem Grund wird momentan viel in die Forschung und Entwicklung neuer, effizienterer Wege investiert diese Daten zu analysieren. Ein Ansatz ist es, die Berechnungen (zumindest teilweise) zu parallelisieren und, statt wie bisher auf CPUs, auf GPUs auszuführen. Diese sind in der Lage mehrere tausend Berechnungen zeitgleich (echt parallel) durchzuführen, was bei bestimmten Aufgaben einen erheblichen Geschwindigkeitsgewinn bewirken kann Ziel der Arbeit Ziel dieser Masterarbeit ist es, einen Algorithmus zur Spurrekonstruktion (in diesem Fall ein Kalman-Filter), wie er in Teilen der ATLAS Software eingesetzt c Maik Dankel 2

13 1. Einleitung wird, so zu implementieren, dass er auf GPUs ausgeführt werden kann. Es gilt herauszufinden, ob dieses spezielle Problem effizient auf GPUs berechnet werden kann. Die Software wird unter Benutzung der freien OpenCL Programmierschnittstelle implementiert und kontinuierlich hinsichtlich Geschwindigkeit optimiert. Um den Geschwindigkeitszuwachs feststellen zu können, werden wiederholt Zeitmessungen der Berechnungsdauer durchgeführt. Parallel dazu wird eine CPU-Anwendung entwickelt, die die selben Daten auswertet 1 um einen Referenzwert für die Berechnungsdauer zu erhalten und die Ergebnisse evaluieren zu können. 1 Die Implementierung des CPU-Codes war Teil eines Masterprojektes und nicht Bestandteil dieser Masterarbeit c Maik Dankel 3

14 2. GPGPU 2. GPGPU Im Oktober 2010 fand im High-Performance Computing eine Revolution statt. China stellte seinen neuen Supercomputer Tianhe-1A vor, der als erster Computer seiner Klasse GPUs als Koprozessoren verwendete. Mit einer Rechenleistung von 2,566 PFLOPS (10 15 floating-point operations per second) ist er fast 50% schneller als der bis dahin schnellste Supercomputer Jaguar (1,759 PFLOPS). Eine weitere Besonderheit ist, dass er zwar fast doppelt so rechenstark ist, jedoch nur knapp 58% der elektrischen Leistung von Jaguar benötigt und damit bedeutend energieeffizienter arbeitet (Vgl. [Scarpino 2012], S. 3f). Der Einsatz von GPUs als Koprozessoren für nicht-graphische Berechnungen wird als general purpose GPU computing oder GPGPU computing bezeichnet und ist im Bereich High-Performance Computing momentan immer mehr im Vormarsch Graphic Processing Units Grafikprozessoren können in speziellen Bereichen erheblich mehr Leistung bringen als herkömmliche CPUs. Dies gilt jedoch nur unter bestimmten Voraussetzungen. Um nachzuvollziehen unter welchen Umständen sie leistungsfähiger sein können, muss zunächst die Architektur einer GPU genauer betrachtet werden. Eine der aktuell am weitesten fortgeschrittenen GPUs wurde 2012 von NVIDIA unter dem Namen GK110 vorgestellt. Dieser Chip wurde hauptsächlich für die NVIDIA Tesla Koprozessoren entwickelt und basiert auf der neuen Kepler Architektur. Ziel der Entwicklung dieses Chips ist es die höchste Parallel-Computing Performance der Welt zu erreichen [NVIDIA]. Eine komplette Kepler GK110 Implementierung besteht aus 15 Streaming Multiprozessoren (SMX) und sechs 64-Bit Memory Controllern. Inzwischen wird dieser Chip teilweise in NVIDIA s Consumer-Modellen, der GeForce Reihe, verbaut. Sowohl bei den GeForce Modellen, als auch den anderen Baureihen, sind jedoch oftmals einige der Komponenten deaktiviert (es steht beispielsweise eine c Maik Dankel 4

15 2. GPGPU Abbildung 2.1.: Komplettes Blockdiagramm des GK110. Quelle: [NVIDIA] S.6 geringere Anzahl an SMX zur Verfügung) Architektur Das in Abbildung 2.1 abgebildete Blockdiagramm zeigt den schematischen Aufbau eines GK110 Chips. Nachfolgend werden die einzelnen Elemente zur Begriffsklärung und zum besseren Verständnis kurz erläutert. Gigathread Engine Die Gigathread Engine ist dafür zuständig, die zu berechnenden Daten in Threadblöcke aufzuteilen und an die SMX Einheiten weiterzuleiten. Des Weiteren ist sie verantwortlich für Kontextwechsel zwischen den einzelnen Blöcken. Streaming Multiprozessor (SMX) Die Next Generation Streaming Multiprocessors sind das Herzstück der Kepler GPUs. Ein SMX ist vom Prinzip her vergleichbar mit einer CPU c Maik Dankel 5

16 2. GPGPU und ist für die Aufteilung der Blöcke auf mehrere Threads verantwortlich, die auf die einzelnen Kerne verteilt werden. Die einzelnen Komponenten eines solchen Multiprozessesors werden in Unterabschnitt genauer behandelt. PCI Express 3.0 Host Interface Über die PCIe Schnittstelle ist die Grafikkarte mit dem Hostsystem verbunden. PCIe 3.0 x16 erlaubt Datenübertragungsraten von bis zu 16GB pro Sekunde. L2 Cache Der Level 2 Cache dient dazu, Daten zwischen den einzelnen Prozessoren (hier den SMX) auszutauschen. Er dient demnach der Verwaltung des globalen Speichers, der unter den SMX geteilt wird. Memory Controller Der GK110 Chip verfügt über insgesamt sechs 64-Bit Memory Controller, die die Speicherverwaltung übernehmen. Die größten Karten, die den GK110 Chip einsetzen, verfügen über 6GB GDDR5 Speicher SMX Abbildung 2.2 zeigt den schematischen Aufbau eines SMX des GK110-Grafikchips. Auch hier werden die einzelnen Komponenten nachfolgend erläutert und beschrieben. Kerne Der große mittlere Teil in Abbildung 2.2 stellt die Rechenkerne des Multiprozessors dar. Jede SMX-Einheit besteht aus 192 Single-Precision- und 64 Double-Precision Kernen, die für mathematische Berechnungen genutzt werden können. Außerdem existieren je 32 Load/Store Einheiten und sogenannte Special Function Units, die der Berechnung spezieller mathematischer Funktionen wie Sinus, Cosinus, Wurzeln, etc. dienen. Warp Scheduler Ein SMX teilt Threads in Gruppen von 32 Threads ein, die Warps genannt werden. Jede der SMX-Einheiten besitzt vier Warp Scheduler, die es erlauben vier Warps gleichzeitig zu starten und auszuführen. Außerdem sind pro Warp Scheduler zwei Dispatch Einheiten vorhanden, die c Maik Dankel 6

17 2. GPGPU Abbildung 2.2.: Blockdiagramm einer SMX-Einheit eines GK110-Chips. Quelle: [NVIDIA] S.8 es ermöglichen zwei unabhängige Befehle pro Takt an einen Warp zu schicken. Abbildung 2.3 veranschaulicht dieses Verhalten. Instruction Cache Der Instruction Cache ist ein spezieller Speicher zum Zwischenspeichern von Befehlen, bevor diese an die einzelnen Warps verteilt werden. Shared Memory / L1-Cache Jede SMX-Einheit verfügt über 64 KB lokalen Speicher, der sowohl als shared Memory innerhalb des SMX dienen kann, als auch als Level 1- Cache. Dieser Speicher kann entweder als 16 KB L1-Cache und 48 KB c Maik Dankel 7

18 2. GPGPU Abbildung 2.3.: Arbeitsweise des Warp Schedulers Quelle: [NVIDIA] S.10 Shared Memory, 48 KB L1-Cache und 16 KB Shared Memory, oder gleichmäßig auf je 32 KB aufgeteilt werden. Read-Only Data Cache Der Read-Only Data Cache ist ein spezieller Speicher für Daten, auf die nur lesend zugegriffen werden darf. Die Speichergröße beträgt 48 KB OpenCL OpenCL ist eine Programmierschnittstelle (API) zum Schreiben von Software, die plattformunabhängig ausgeführt werden kann. Der OpenCL-Code kann laut Spezifikation auf CPUs, GPUs, DSPs und anderen Prozessoren ausgeführt werden. OpenCL wurde zunächst von Apple in Kooperation mit führenden Firmen aus der Industrie 2 entwickelt und Mitte 2008 zur Standardisierung bei der Khronos Group eingereicht. Ende 2008 wurde dann die OpenCL 1.0 Spezifikation veröffentlicht [KHRONOS]. OpenCL stellt eine Top-Level-Abstraktion für Low-Level Hardware Routinen dar, um hochparallele Anwendungen zu implementieren. Dabei kann sowohl 2 z.b. 3DLABS, Activision Blizzard, AMD, ARM, Electronic Arts, Ericsson, IBM, Intel Corporation, Motorola, Nokia, NVIDIA, Samsung, Texas Instruments c Maik Dankel 8

19 2. GPGPU Abbildung 2.4.: Aufbau einer OpenCL Plattform Quelle: [KHRONOS 2008] S.13 Datenparallelität, als auch Task-Parallelität erreicht werden. Der eigentliche OpenCL-Code wird in OpenCL C implementiert, eine auf ISO C99 basierende Sprache, die um einige Datentypen und Funktionen zur parallelen Verarbeitung erweitert wurde. Allerdings ist OpenCL C an einigen Stellen eingeschränkt gegenüber dem C99-Standard. So existieren beispielsweise keine Funktionszeiger, Arrays müssen eine feste Größe besitzen und Rekursion ist nicht möglich. OpenCL Software ist in zwei Komponenten aufgeteilt, zum einen der Host- Code und auf der anderen Seite der Device-Code. Als Host wird im Folgenden ein System bezeichnet, das ein oder mehrere OpenCL-fähige Geräte (Devices) enthält und von dem/denen aus die Software ausgeführt wird. Ein Device wiederum ist eine Grafikkarte oder ein Koprozessor, auf dem der eigentliche OpenCL-Code ausgeführt wird. Im grundsätzlichen Aufbau einer OpenCL Plattform verfügt ein Host über ein oder mehrere Devices und steuert diese an (siehe Abbildung 2.4). Jedes Device verfügt über mehrere Recheneinheiten (siehe Unterabschnitt 2.1.1, SMX), welche wiederum über mehrere Rechenkerne verfügen (siehe Unterabschnitt 2.1.2, Kerne). In den folgenden Abschnitten wird erläutert, welche Schritte nötig sind um lauffähigen OpenCL-Code zu erzeugen und einige Besonderheiten dabei werden hervorgehoben. c Maik Dankel 9

20 2. GPGPU Host-Code Hostseitig werden sämtliche, für die OpenCL-Laufzeitumgebung wichtigen, Komponenten implementiert und angesteuert. Der Hostcode als solches kann in regulärem C oder C++ geschrieben werden, allerdings gibt es einige OpenCLspezifische Datenstrukturen und Funktionsaufrufe, auf die nachfolgend genauer eingegangen wird. Erstellen der grundlegenden OpenCL-Umgebung Dazu zählt als Erstes die sogenannte Plattform, welche durch eine cl_platform _id repräsentiert wird. Eine Plattform ist ein Host mit 1-n Devices (siehe Abbildung 2.4). Mit folgendem Aufruf wird ein cl_platform Objekt erzeugt: 1 // Returns an error code 2 cl_int oclgetplatformid (cl_platform_id platform) // Pointer to the platform object Listing 2.1: oclgetplatformid() Signatur Es wird ein Zeiger auf eine cl_platform_id übergeben, welcher durch den Aufruf gesetzt wird und damit die Referenz zur Plattform herstellt. Als Rückgabewert wird ein OpenCL-weit eindeutiger numerischer Wert zurückgegeben, der einen Fehlercode darstellt. Sobald Zugriff auf die Plattform besteht, kann auf alle Devices zugegriffen werden, die mit dieser Plattform assoziiert sind. Dazu muss die Referenz zu einem oder mehreren Devices hergestellt werden, was über den folgenden Aufruf geschieht: 1 cl_int clgetdeviceids ( 2 cl_platform_id platform, 3 cl_device_type device_type, // bitfield for choosing the device type 4 cl_uint num_entries, // The number of cl_device entries that can be added to \emph{devices} 5 cl_device_id devices, // Pointer to the device object 6 cl_uint num_devices) // number of devices matching the device_type Listing 2.2: clgetdeviceids() Signatur c Maik Dankel 10

21 2. GPGPU Hier wird festgelegt wie viele und was für Devices für die angegebene Plattform angesprochen werden. Mögliche Typen für device_type sind: CL_DEVICE_TYPE_GPU CL_DEVICE_TYPE_CPU (Host-Prozessor, Single- oder Multicore) CL_DEVICE_TYPE_ACCELERATOR (dedizierter OpenCL Koprozessor) CL_DEVICE_TYPE_DEFAULT CL_DEVICE_TYPE_ALL Nach einem erfolgreichen Aufruf sind die Devices eindeutig über deren cl_device _id definiert und können darüber angesprochen werden. Ebenso ist dann die Anzahl der Komponenten, die dem angegebenen Typ entsprechen, in num _devices gespeichert. Nach Definition einer Plattform und ein oder mehrerer Devices, wird ein Context erzeugt. Dieser definiert die gesamte OpenCL Umgebung inklusive der OpenCL-Devices, Kernel, Command-Queues, etc. und dient dazu OpenCL- Code auf den jeweiligen Devices auszuführen. Ein Context wird über den nachfolgenden Funktionsaufruf erzeugt: 1 cl_context clcreatecontext ( 2 const cl_context_properties properties, // properties bitfield (see specification ) 3 cl_uint num_devices, // Number of devices 4 const cl_device_id devices, // Pointer to the devices object 5 void ( pfn_notify)(const char errinfo, const void private_info, size_t cb, void user_data), // callback function to retrieve errors 6 void user_data, // Passed as user_data argument when pfn_notify is called 7 cl_int errcode_ret) // error code result Listing 2.3: clcreatecontext() Signatur Die wichtigen Parameter dieses Funktionsaufrufs sind num_devices (wie viele Devices werden mit diesem Context assoziiert) und *devices, ein Zeiger, der die genauen Devices angibt und durch den vorherigen Aufruf von cldetdeviceids() gesetzt wird. Zusätzlich kann eine callback-funktion angegeben werden, die von der OpenCL-Implementierung genutzt wird, um Informationen c Maik Dankel 11

22 2. GPGPU über Fehler zu liefern, die in diesem Context auftreten. Soll diese Funktionalität nicht genutzt werden, können die Argumente (*pfn_notify)(...) und *user_data NULL gesetzt werden 3. Abschließend wird eine Command-Queue erzeugt. In dieser Warteschlange werden Anweisungen, die auf dem jeweiligen Device ausgeführt werden sollen, abgelegt und von diesem letztendlich abgearbeitet. Erzeugt wird eine Command-Queue mit dem Aufruf von clcreatecommandqueue(): 1 cl_command_queue clcreatecommandqueue ( 2 cl_context context, 3 cl_device_id device, 4 cl_command_queue_properties properties, // bitfiled for properties 5 cl_int errcode_ret) // error code result Listing 2.4: clcreatecommandqueue() Signatur Zwischen Devices und Command-Queues besteht eine 1:n Beziehung. Einer Warteschlange ist über das Argument device immer genau ein OpenCL-Device zugeordnet, jedoch kann ein Device mehrere Queues haben, was unter Umständen einen höheren Grad an Parallelisierung ermöglichen kann (Vgl. dazu Unterabschnitt 2.2.4). Die Anweisungen, die in der Queue abgelegt werden, können entweder inorder oder out-of-order ausgeführt werden. Dies wird über das properties Argument festgelegt. Standardmäßig werden die Befehle in der Reihenfolge abgearbeitet, in der sie dort abgelegt werden (first in, first out). Soll dieses Verhalten geändert werden, kann für properties CL_QUEUE_OUT_OF_ORDER _EXEC_MODE_ENABLE gesetzt werden. Ist das in-order Verhalten gewünscht, kann hierfür 0 eingesetzt werden. Speicher allozieren Mit den vorherigen Aufrufen ist der Host grundlegend konfiguriert. Es können Devices angesprochen und Anweisungen an die Command-Queue(s) weitergegeben werden. Als Nächstes wird Speicherplatz auf dem Device zur Verfügung gestellt. Das erfolgt mit folgendem Funktionsaufruf: 3 selbiges gilt auch für *properties c Maik Dankel 12

23 2. GPGPU 1 cl_mem clcreatebuffer ( 2 cl_context context, // The context where the memory will be allocated 3 cl_mem_flags flags, 4 size_t size, // The size in bytes 5 void host_ptr, 6 cl_int errcode_ret) Listing 2.5: clcreatebuffer() Signatur Dieser Aufruf erzeugt ein cl_mem Objekt, das einen Speicherbereich repräsentiert. Dieser kann verschiedene Eigenschaften haben, je nachdem welche Werte für das Argument flags gesetzt werden. Mögliche Flags sind CL_MEM_READ_WRITE CL_MEM_WRITE_ONLY CL_MEM_READ_ONLY CL_MEM_COPY_HOST_PTR CL_MEM_ALLOC_HOST_PTR CL_MEM_USE_HOST_PTR Mit den ersten drei Flags können Zugriffsrechte für den Speicher angegeben werden. Nur lesender, nur schreibender Zugriff, oder beides. Wird keines gesetzt, so kann standardmäßig sowohl lesend, als auch schreibend zugegriffen werden. Die letzten drei Flags geben an, ob und wie Daten (beim Erstellen des Speichers) zwischen Host und Device übertragen werden. Den einfachsten Fall stellt CL_MEM_COPY_ HOST_PTR dar, da hier Speicher auf dem Device alloziert und gleichzeitig mit den Daten, die durch host_pointer adressiert sind, initialisiert wird. Mit CL_MEM_USE_HOST_PTR wird Speicher in einem Bereich alloziert, der sowohl vom Host, als auch vom Device erreichbar ist. Hierbei ist Vorsicht geboten, da der Speicher hostseitig manipuliert wird, sobald der Kernel gestartet wird. Das Flag CL_MEM_ ALLOC_HOST_PTR bewirkt, dass hostseitig sogenannter Pinned-Memory erzeugt wird. Dies ist ein Speicherbereich, der nicht auf Sekundärspeicher (z.b. die Festplatte) ausgelagert wird. Das kann erheblich höhere Datentransferraten ermöglichen. Wird keines der letzten drei Flags angegeben, so wird lediglich Speicher auf dem Device reserviert. Jeweils eines von den ersten und letzten drei Flags kann bitweise verodert werden. c Maik Dankel 13

24 2. GPGPU Sofern nicht das Flag CL_MEM_USE_HOST_PTR (bei dem Hostspeicher genutzt wird), bzw. CL_MEM_COPY_HOST_PTR (wobei implizit Daten auf das Device kopiert werden) gesetzt wird, muss, sofern Daten zum Device transferiert werden sollen, ein expliziter Kopiervorgang angestoßen werden. Das geschieht mit clenqueuewritebuffer(): 1 cl_int clenqueuewritebuffer ( 2 cl_command_queue command_queue, 3 cl_mem buffer, // to which buffer 4 cl_bool blocking_write, // determines if this call is blocking or not 5 size_t offset, // offset from the beginning 6 size_t cb, // size to be written (in bytes) 7 const void ptr, // pointer to host memory 8 cl_uint num_events_in_wait_list, 9 const cl_event event_wait_list, 10 cl_event event) Listing 2.6: clenqueuewritebuffer() Signatur Hierbei wird angegeben welcher Speicherbereich (bestimmt durch *ptr und cb) an welche Stelle auf dem Device (angegeben durch das vorher erzeugte cl_mem Objekt, hier buffer) kopiert wird. Wie der Name der Funktion bereits impliziert, wird das Kommando in die Command-Queue gehängt und kann über das boolsche Argument blocking_write blockierend oder nicht blockierend ausgeführt werden. Sofern blocking_write auf FALSE gesetzt ist, muss mittels des letzten Arguments event sichergestellt werden, dass der Aufruf beendet ist, bevor auf diesen Daten gearbeitet werden kann. Sowohl clenqueuewritebuffer, als auch alle noch folgenden clenqueue* Befehle arbeiten nach diesem Prinzip. 4 Programm und Kernel Sowohl Programm und Kernel enthalten ausführbaren Code. Ein Kernel (siehe dazu Unterabschnitt 2.2.2) ist allerdings eine einzelne Funktion, die auf einem Device ausgeführt wird. Im Gegensatz dazu ist ein Programm eine Sammlung von mehreren Kerneln. 4 mehr zum Thema Events in Unterabschnitt c Maik Dankel 14

25 2. GPGPU Ein Programm wird in OpenCL durch eine cl_program Datenstruktur repräsentiert, die mit folgendem Funktionsaufruf erzeugt wird: 1 cl_program clcreateprogramwithsource ( 2 cl_context context, 3 cl_uint count, // number of files 4 const char strings, // array of strings, each one is a file 5 const size_t lengths, // array specifying the file lengths 6 cl_int errcode_ret) // error code to be returned Listing 2.7: clcreateprogramwithsource() Signatur Dieser Aufruf erzeugt ein Programm aus einer oder mehreren Dateien (angegeben durch das Argument count) und erwartet ein Array von Strings, das den Inhalt dieser Dateien enthält. Das heißt, eine Datei muss zunächst ausgelesen und zwischengespeichert werden. Diese Datei enthält den eigentlichen Kernel- Code. Ist dies erfolgt, wird das Programm kompiliert. Das erfolgt mit dem Aufruf von clbuildprogram(). Die Signatur sieht folgendermaßen aus: 1 cl_int clbuildprogram ( 2 cl_program program, 3 cl_uint num_devices, 4 const cl_device_id device_list, 5 const char options, // Compiler options, see the specifications for more details 6 void ( pfn_notify)(cl_program, void user_data), 7 void user_data) Listing 2.8: clbuildprogram() Signatur Diese Funktion benötigt sowohl das zuvor erzeugte cl_program, als auch die Anzahl der Devices und die Referenz zu diesen. Mit dem Argument options können Compileroptionen angegeben werden. Ähnlich wie beim Aufruf von clcreatecontext() existiert auch hier eine Callback-Funktion. Sofern diese angegeben wird, wird sie gerufen, sobald der Build-Vorgang abgeschlossen ist. Außerdem blockiert der Aufruf von clbuildprogram() in diesem Fall nicht und es wird mit der Ausführung des Codes direkt fortgefahren. Ist dies nicht gewünscht, kann für die beiden letzten Argumente NULL eingesetzt werden. c Maik Dankel 15

26 2. GPGPU Abschließend wird mittels clcreatekernel() ein Kernel erzeugt, der später als Einstiegspunkt zu dem auf der GPU ausführbaren Code dient. 1 cl_kernel clcreatekernel ( 2 cl_program program, // The program where the kernel is 3 const char kernel_name, // The name of the kernel 4 cl_int errcode_ret) Listing 2.9: clcreatekernel() Signatur Dieser Aufruf benötigt das vorher erzeugte und kompilierte Programm sowie den Namen des Kernels, der geladen werden soll. Hiermit ist nicht der Dateiname, sondern der tatsächliche Name der Kernelfunktion gemeint, die im Code aufgerufen wird. Da ein Kernel gewissermaßen eine Funktion darstellt, benötigt dieser üblicherweise Argumente, die ihm übergeben werden. Dazu ist ein weiterer Aufruf nötig, der wie folgt aussieht: 1 cl_int clsetkernelarg ( 2 cl_kernel kernel, // a valid kernel 3 cl_uint arg_index, // index of the argument, goes from 0 to n 1 4 size_t arg_size, // size of the argument value 5 const void arg_value) // pointer to data that should be used as the argument Listing 2.10: clsetkernelarg() Signatur Dieser muss für n Argumente n-mal aufgerufen werden. Es wird der Kernel angegeben, für den diese Argumente bestimmt sind, sowie ein Index, der das jeweilige Argument angibt. Bei beispielsweise n=3 Argumenten muss diese Funktion drei mal aufgerufen werden, mit arg_index {0, 1, 2}. Die Argumente arg_size und arg_value geben die Größe und das zu übergebene Argument an. Üblicherweise sind das ein cl_mem Objekt, das zuvor mit clcreatebuffer() erstellt wurde und dessen Größe (sizeof(cl_mem)). Um die Ausführung des Kernels zu starten ist der nachfolgende Aufruf von clenqueuendrangekernel() nötig. 1 2 cl_int clenqueuendrangekernel ( 3 cl_command_queue command_queue, // A valid command queue 4 cl_kernel kernel, // A valid kernel c Maik Dankel 16

27 2. GPGPU 5 cl_uint work_dim, // Choose if using 1D, 2D or 3D Work Items and Work Groups 6 const size_t global_work_offset, // Mmust be NULL, not supported by OpenCL yet 7 const size_t global_work_size, // The total number of Work Items (must have work_dim dimensions) 8 const size_t local_work_size, // The number of Work Items per Work Group (must have work_dim dimensions) 9 cl_uint num_events_in_wait_list, 10 const cl_event event_wait_list, 11 cl_event event) Listing 2.11: clenqueuendrangekernel() Signatur Es wird eine Command-Queue sowie der auszuführende Kernel übergeben. Außerdem muss die Dimension angegeben werden, in der die Work-Items arrangiert sind (zur Erläuterung siehe Unterabschnitt 2.2.2). global_work_size gibt die Gesamtanzahl der Work-Items an, local_work_size gibt die Anzahl an Work-Items pro Work-Group an und muss ein Teiler von global_work_size sein. Wird für local_work_size NULL eingesetzt berechnet die OpenCL Implementierung selbsständig eine geeignete Aufteilung in Work-Groups. Nach Aufruf von clenqueuendrangekernel() wird der Befehl zur Ausführung des Kernels in die Command-Queue eingehängt und anschließend gestartet. Speicher auslesen Nach Ausführen des Kernels werden die Daten vom Devicespeicher ausgelesen. Dazu existiert eine weitere Funktion mit Namen clenqueuereadbuffer(): 1 cl_int clenqueuereadbuffer ( 2 cl_command_queue command_queue, 3 cl_mem buffer, // from which buffer 4 cl_bool blocking_read, // determines if this call is blocking or not 5 size_t offset, // offset from the beginning 6 size_t cb, // size to be read (in bytes) 7 void ptr, // pointer to the host memory 8 cl_uint num_events_in_wait_list, 9 const cl_event event_wait_list, 10 cl_event event) Listing 2.12: clenqueuereadbuffer() Signatur c Maik Dankel 17

28 2. GPGPU Dieser Aufruf erfolgt analog zu clenqueuewritebuffer(). In diesem Fall gibt buffer an aus welchem Speicher gelesen wird und *ptr ist eine hostseitige Speicheradresse, an der die Daten abgelegt werden. Clean up Abschließend werden jegliche zuvor erzeugten Objekte freigegeben. Dies muss explizit geschehen, da die OpenCL Implementierung sonst dauerhaft Ressourcen belegt. 1 cl_int clreleasememobject ( cl_mem memobj) 2 cl_int clreleaseprogram (cl_program program) 3 cl_int clreleasekernel (cl_kernel kernel) 4 cl_int clreleasecommandqueue(cl_command_queue command_queue) 5 cl_int clreleasecontext (cl_context context) Listing 2.13: OpenCL clean-up Methoden Damit sind alle wichtigen Aufrufe erläutert. Ein komplettes Minimalbeispiel mit allen erwähnten Funktionsaufrufen ist in Anhang A zu finden Device-Code / Kernel Der Code, der auf den OpenCL-Devices ausgeführt wird, wird Kernel genannt. Ein Kernel ähnelt einer, zum Beispiel in C oder C++ üblichen Funktion, die vom Host aufgerufen wird. Ein Kernel stellt den Einstiegspunkt für die Ausführung von Code auf dem Device dar. Ein kurzes Beispiel soll genauer erläutern, was einen Kernel von einer üblichen C-Routine unterscheidet und wie damit die extrem hohe Parallelität erreicht wird, für die OpenCL ausgelegt ist. Bei großen Datensätzen ist es üblich, diese mittels Schleifen zu durchlaufen. Müssen zum Beispiel mehrdimensionale Daten bearbeitet werden, erfolgt dies üblicherweise mit verschachtelten Schleifen: c Maik Dankel 18

29 2. GPGPU for (i=0; i<z; i++) { for (j=0; j<y; j++) { for (k=0; k<x; k++) { process(point[i][j][k]); } } } Solche Schleifen sind zwar üblich, allerdings sehr ineffizient, da jede Iteration neben der eigentlichen Berechnung einen Vergleich und eine Addition erfordert. Vergleiche sind allerdings teuer, sogar auf den besten CPUs, insbesondere aber auf GPUs. Diese sind darauf ausgelegt die selben Operationen immer wieder auszuführen, aber nicht Vergleiche anzustellen und darauf basierend Entscheidungen zu treffen. Muss eine GPU eine Bedingung überprüfen, kann es Hunderte von Taktzyklen dauern, bevor sie wieder mit voller Geschwindigkeit mit der Berechnung fortfahren kann [Scarpino 2012]. Abbildung 2.5.: Veranschaulichung von Global- und Local-ID Quelle: [Römhild 2011] Der Vorteil von OpenCL ist, dass solche Schleifen wegfallen können. Ein Kernel führt gewissermaßen nur den Code aus, der innerhalb der Schleifen liegt. In OpenCL werden die einzelnen Instanzen (Threads), die diesen Code ausführen als Work-Items bezeichnet. Diese sind die kleinste ausführbare Einheit in OpenCL Programmen. Bei jedem Kernelaufruf wird die durch den Aufruf von clenqueuendrangekernel mit dem Argument global_work_size festgelegte Anzahl Work-Items gestartet, die alle den selben Kernelcode ausführen. Dieses Prinzip nennt sich SIMT (Single Instruction Multiple Threads). Die Möglichkeit Code nach diesem Schema ausführen zu können erlaubt OpenCL die extrem hohe Parallelität zu erreichen. Es ist wichtig, zwischen Kernel und Work-Item zu differenzieren. Ein Kernel ist eine Sammlung von Anweisungen, die ausgeführt werden. Ein Work-Item c Maik Dankel 19

30 2. GPGPU dagegen ist eine spezielle Instanz des Kernels, die einen bestimmten Datensatz bearbeitet. Angelehnt an das vorherige Beispiel entspricht ein Kernel der Funktion process(point[i][j][k]). Ein einzelnes Work-Item entspricht zum Beispiel process(point[1][2][3]). Jedes Work-Item besitzt eine eindeutige ID, die Global-ID genannt wird. Die Global-ID der Kernelinstanz process(point[1][2][3]) ist das Array {1, 2, 3}. Die Anzahl an Elementen, aus der eine Global-ID besteht, steht in direktem Bezug zur Dimension der Daten, die bearbeitet werden. Die Dimension wird beim Aufruf von clenqueuendrangekernel mit dem Argument work-dim angegeben. Bei dem vorherigen Beispiel ist work-dim gleich drei gesetzt. Daraus ergibt sich folgender Kernel-Code: int i = get_global_id(0); int j = get_global_id(1); int k = get_global_id(2); process(point[i][j][k]); Der Aufruf von get_global_id(n) liefert die eindeutige ID, der n-ten Dimension. Das nächste Konzept, das in diesem Zusammenhang zu erwähnen ist, ist was NVIDIA in seiner Architektur als CUDA Thread Blocks bezeichnet und in OpenCL Work-Group genannt wird. Eine Work-Group ist ein Zusammenschluss mehrerer Work-Items, die gemeinsam auf den extrem schnellen lokalen Speicher zugreifen (siehe dazu Unterabschnitt 2.2.3) und untereinander synchronisiert werden können (siehe Unterabschnitt 2.2.4). Zusätzlich zur Global-ID besitzt ein Work-Item eine Local-ID, die es eindeutig innerhalb einer Work-Group identifiziert und mit get_local_id(n) abgefragt werden kann (siehe Abbildung 2.5). Work-Groups bieten den Vorteil, dass nur eine gewisse Anzahl an Work-Items die selben Daten bearbeiten und nicht alle. Sollen beispielsweise viele 8x8-Matrizen gleichzeitig berechnet werden, so wird beim Aufruf von clenqueuendrangekernel für local_work_size {8, 8} angeben. Dies bewirkt, dass eine Work-Group aus 8*8 Work-Items besteht. In Abbildung 2.6 ist dargestellt, wie die vorhergehenden Prinzipien an einem zweidimensionalen Beispiel aussehen. Die einzelnen Quadrate stellen die Work- Items dar, die zu Work-Groups zusammengefasst sind. Global Size(0) bezeichnet die Gesamtanzahl Work-Items in der ersten und Global Size(1) in der c Maik Dankel 20

31 2. GPGPU Abbildung 2.6.: Veranschaulichung von Work-Groups, Work-Items und Dimensionen Quelle: [J. Tompson 2012] zweiten Dimension. Äquivalent dazu steht Local Size(n) für die Elemente innerhalb der Work-Groups Speichermodell Wie bereits in Abschnitt 2.1 erläutert, verfügt eine GPU über verschiedene Speicherarten, die unterschiedlich schnelle Zugriffszeiten haben. Dies spiegelt sich durch verschiedene Speichertypen in OpenCL wieder. Die Speicherhierarchie (siehe Abbildung 2.7) in OpenCL ähnelt der physikalischen Speicherkonfiguration von NVIDIA und ATI Hardware, auch wenn das Mapping nicht eins zu eins ist, da die beiden Hersteller ihre Speicherhirarchie unterschiedlich definieren [J. Tompson 2012]. c Maik Dankel 21

32 2. GPGPU Abbildung 2.7.: OpenCL Speichermodell Quelle: [KHRONOS 2008] Wie in Abbildung 2.7 zu sehen, verfügt eine OpenCL Umgebung über folgende Speicherbereiche: Host Memory Als Hostspeicher wird im Allgemeinen der Hauptspeicher, oder Massenspeicher wie Festplatten, des Hosts bezeichnet. Global Memory Jede Work-Group und damit auch alle Work-Items haben sowohl lesenden, als auch schreibenden Zugriff auf den globalen Speicher (siehe L2- Cache aus Unterabschnitt 2.1.1). Die OpenCL Spezifikation trifft hierbei keine Aussagen, ob die Zugriffe gecached werden. Dies hängt von der jeweiligen Hardware ab [M. Müller 2009]. Constant Memory Ein Teil des globalen Speichers wird für konstante Werte genutzt, die zur Laufzeit unverändert bleiben. Dieser Bereich wird nur hostseitig beschrieben. c Maik Dankel 22

33 2. GPGPU Local Memory Die einzelnen Work-Groups verfügen über lokalen Speicher, der innerhalb dieser erreichbar ist (siehe Shared Memory / L1-Cache aus Unterabschnitt 2.1.2). Alle Work-Items einer Work-Group können auf diesen Speicher zugreifen. Private Memory Jedes Work-Item verfügt zusätzlich über einen kleinen privaten Speicher, in dem private Variablen gespeichert werden. Der Global Memory entspricht dem in Unterabschnitt angegebenen L2- Cache der GPU. Der Local Memory und der Private Memory entsprechen dem Shared Memory, bzw. L1-Cache eines SMX, wie in Unterabschnitt beschrieben. Der Transfer von Daten muss immer explizit folgende Schritte durchlaufen: Zunächst werden Daten beim Kernelaufruf vom Hostspeicher in den globalen Devicespeicher geladen. Auf diesem kann direkt gearbeitet werden. Da dieser Speicher allerdings langsamer ist als der lokale Speicher, sollten die Daten, die bearbeitet werden, zunächst in den lokalen Speicher kopiert werden. Nach der Bearbeitung werden diese zurück in den globalen Speicher geschrieben und können vom Host ausgelesen werden. Die oben angegebene Reihenfolge entspricht demnach gleichzeitig der Speicherhierarchie, von Host Memory (langsam) bis hin zu Private Memory (sehr schnell). Was beim Transfer von Daten ebenfalls zu beachten ist, ist dass oftmals die PCIe Schnittstelle der Flaschenhals bei der Performance einer OpenCL Anwendung ist. Aus diesem Grund sollten Kopiervorgänge zum und vom Device möglichst immer große Datenmengen beinhalten. Viele kleine Datentransfers bremsen die Anwendung aus Asynchrone Verarbeitung und Synchronisation OpenCL ist auf hohe Parallelität ausgelegt. Beim Aufruf von clenqueuen- DRangeKernel werden beliebig viele Kernelinstanzen gestartet, die parallel Daten bearbeiten. Das bewirkt bereits eine asynchrone Verarbeitung, die als Data Parallelism bezeichnet wird und die Kernkompetenz von OpenCL- Anwendungen darstellt. Viele Kernelinstanzen führen parallel den selben Code auf verschiedenen Daten aus. Arbeiten viele tausend Threads auf den Daten c Maik Dankel 23

34 2. GPGPU wird es spätestens bei etwas komplexeren Anwendungen von Nöten sein, dass diese sich untereinander synchronisieren, da es vorkommen kann, dass zur Bearbeitung eines Datums eine vorherige Berechnung abgeschlossen sein muss. Um dies zu bewerkstelligen, sind in OpenCL sogenannten Barriers, also zu Deutsch Barrieren, implementiert, an denen die Work-Items warten müssen, bis alle an dieser Stelle im Code angelangt sind. Abbildung 2.8.: Synchronisierung von Work-Items Quelle: [J. Tompson 2012] Solch eine Synchronisation ist (wie in Abbildung 2.8 dargestellt) nur innerhalb einer Work-Group möglich. Das heißt Work-Items können nicht Work-Groupübergreifend synchronisiert werden. Ein Synchronisationspunkt wird in OpenCL mit dem in Listing 2.14 gezeigten Aufruf von barrier() erzeugt. Jedes Work-Item einer Work-Group muss diese Funktion ausführen, bevor mit der weiteren Ausführung fortgefahren werden darf. Zusätzlich werden mit diesem Aufruf Speicheroperationen synchronisiert. Über den Parameter flags kann angegeben werden, welche Speicherbereiche davon betroffen sind. Als möglicher Parameter existiert CLK_LOCAL_MEM _FENCE oder CLK_GLOBAL_MEM_FENCE. Diese geben ab ob Operationen auf dem lokalen, oder globalen Speicher synchronisiert werden 5. 1 void barrier ( cl_mem_fence_flags flags) Listing 2.14: OpenCL Synchronisationspunkt barrier() 5 die Parameter können durch ein logische ODER kombiniert werden, wodurch auf Speicheroperationen auf beiden Speicherarten reagiert wird c Maik Dankel 24

35 2. GPGPU Zu beachten ist, dass diese Synchronisationspunkte im Code immer von allen Work-Items erreichbar sein müssen. Ein barrier() Aufruf sollte nicht in einem If-Statement stehen, falls dies bewirkt, dass nicht alle Instanzen diesen Code ausführen. Dies könnte zu Fehlern oder Deadlocks führen, da die blockierten Threads nicht weiterlaufen, bis alle den Synchronisationspunkt erreicht haben, einige diesen aber nicht erreichen können. Selbiges gilt für Schleifen. Zusätzlich zum Data Parallelism unterstützt OpenCL das Konzept des Task Parallelism. Es können verschiedene Aufgaben (Kernel) gleichzeitig ausgeführt werden. Dies kann zum Beispiel gewünscht sein, wenn die selben Daten auf unterschiedliche Art und Weise verarbeitet werden müssen. Hierzu werden mehrere verschiedene Kernel aufgerufen und gestartet. Ebenfalls lässt sich dieses Prinzip einsetzen, um eine GPU möglichst effizient auszulasten. Wenn ein Kernel den Grafikprozessor nicht genug beansprucht und ein Großteil der Zeit auf die Kopiervorgänge von und zu diesem gewartet wird, kann der selbe Kernel mehrfach mit unterschiedlichen Daten aufgerufen werden. Dadurch wird höhere Auslastung und damit höhere Parallelität erreicht. Soll dieses Prinzip angewandt werden, muss wie in Unterabschnitt Speicher allozieren erwähnt, mit den von OpenCL zur Verfügung gestellten Events gearbeitet werden. Werden diese nicht verwendet, sind sämtliche clenqueue* Aufrufe blockierend und es können nicht mehrere Kernel gleichzeitig gestartet und ausgeführt werden. 1 cl_int clwaitforevents ( 2 cl_uint num_events, 3 const cl_event event_list) Listing 2.15: clwaitforevents() Signatur Der Einsatz dieser Technik stellt den Programmierer vor ein erneutes Synchronisationsproblem. Hierfür sind die OpenCL-Events zuständig. Wird beim Aufruf einer clenqueue* Routine eine Referenz auf ein cl_event übergeben, so enthält dieses Informationen über die Ausführung dieser speziellen Kernelinstanz. Mit dem Aufruf von clwaitforevents (siehe Listing 2.16) kann hostseitig eine Synchronisation vorgenommen werden, da dieser Aufruf blockiert, bis die Ausführung der Kernelinstanz beendet ist. Das ist zum Beispiel dann wichtig, wenn der Host mit Werten rechnet, die vom Device vorverarbeitet werden. c Maik Dankel 25

36 2. GPGPU Wird an solch einer Stelle keine Synchronisation vorgenommen, ist die Datenintegrität gefährdet. Mit clwaitforevents wird auf ein oder mehrere spezielle Events gewartet. Das Argument num_events gibt die Anzahl an Events an, auf die gewartet wird und *event_list eine Referenz auf die entsprechenden Events. Soll nicht auf spezielle Events gewartet werden, sondern auf die Beendigung aller bislang in einer Command-Queue abgesetzten Befehle kann alternativ clfinish gerufen werden. 1 cl_int clfinish (cl_command_queue command_queue) Listing 2.16: clfinish() Signatur Hier wird die entsprechende Command-Queue übergeben und die weitere Ausführung des Host-Codes solange blockiert, bis die Warteschlange deviceseitig abgearbeitet ist. c Maik Dankel 26

37 3. Kalman-Filter 3. Kalman-Filter Der Kalman-Filter ist eine nach seinem Entdecker Rudolf Emil Kálmán benannte Sammlung von mathematischen Gleichungen. Dieser veröffentlichte erstmals 1960 in seinem berühmten Paper A New Approach to Linear Filtering and Prediction Problems [R. E. Kalman 1960] eine rekursive Lösung zur linearen Filterung von diskreten Daten. Vereinfacht gesagt erlaubt der Kalman- Filter bei Vorliegen von fehlerbehafteten Beobachtungen (zum Beispiel Messungen) Rückschlüsse auf das System zu ziehen und damit Fehler zu minimieren. Mathematisch gesehen entspricht der Kalman-Filter einem Bayes schen Minimum-Varianz-Schätzer für lineare stochastische Systeme. Der Kalman-Filter ist ein Satz von mathematischen Gleichungen 6, deren Besonderheit ist, dass sie besonders effizient in Echtzeitsystemen einsetzbar sind, um den Zustand eines Prozesses zu schätzen. Aus diesem Grund findet er seit jeher rege Beachtung in der Wissenschaft und Wirtschaft. Dazu zählen unter anderem Anwendungen zur autonomen Navigation, Auswertung von Radarsignalen oder die Positionsverfolgung sich bewegender Objekte (Tracking)[G. Welch 2006]. In dieser Arbeit wird ein Kalman-Filter eingesetzt, um die Genauigkeit der Messungen aus dem Atlas-Teilchendetektor zu erhöhen und damit dem tatsächlichen Punkt, den dieses Teilchen passiert, näher zu kommen. Das Prinzip dieses Algorithmus wird nachfolgend am Beispiel einer Spurrekonstruktion genauer erläutert Definition Die rekursive Form des Kalman-Filters kommt dadurch zustande, dass er einen kontinuierlichen Prozess darstellt, der sich laufend wiederholt, solange neue 6 Die genaue Herleitung der Formeln ist nicht Teil dieser Arbeit und kann z.b. in [R. E. Kalman 1960] oder [G. Welch 2006] eingesehen werden c Maik Dankel 27

38 3. Kalman-Filter Messwerte vorhanden sind. Dieser Algorithmus hat einen erheblichen Vorteil gegenüber vergleichbaren Ansätzen, da er zur Berechnung eines Schrittes lediglich die vorherige Berechnung benötigt, nicht aber alle vorangegangenen Daten (wie es zum Beispiel beim Wiener-Filter der Fall ist)[g. Welch 2006]. Daher ist der Kalman-Filter sehr effizient, sowohl was Geschwindigkeit, als auch Speicherbedarf angeht, ohne dass Informationen verloren gehen, da ein berechneter Wert immer die Information aller vorhergehender Werte beinhaltet. Abbildung 3.1.: Der rekursive Ablauf des Kalman-Filters. Der time update Schritt bildet den aktuellen Zustand auf einen geschätzten zukünftigen Wert ab. Der measurement update Schritt korrigiert den geschätzten Wert mittels einer aktuellen Messung. Quelle: [G. Welch 2006] Abbildung 3.2 veranschaulicht schematisch, wie ein Teilchen verschiedene Detektorlagen durchdringt und dabei Messpunkte erzeugt. Allerdings entsprechen diese Messungen nicht immer genau der Realität. Sie werden durch verschiedene Faktoren beeinflusst, wie beispielsweise der Auflösung der jeweiligen Detektorlage, Magnetfelder innerhalb des Detektors und anderer Störungen. Aus diesem Grund wird der Kalman-Filter eingesetzt, um mittels Minimierung der Fehlerkovarianz die fehlerbehaftete Messung zu korrigieren und somit näher an die tatsächlichen Durchschlagpunkte eines Teilchens zu gelangen. Der Kalman-Filter kann, wie in Abbildung 3.1 dargestellt, in zwei Schritte unterteilt werden: der Time Update Schritt und der Measurement Uptdate Schritt. Ersterer stellt eine Vorhersage (Schätzung) eines Zustandes dar, welcher im zweiten Schritt mittels einer konkreten Messung korrigiert wird. Im Time Update Schritt erfolgt zunächst eine Projektion von Lage k-1 zu Lage k. Hierzu wird der vorherige Status-Vektor p k 1 k 1 mit der zugehörigen c Maik Dankel 28

39 3. Kalman-Filter Abbildung 3.2.: Schematische Darstellung von Teilchenspur und verfälschter Messung innerhalb eines Detektors Jacobi-Matrix F k multipliziert und somit eine a-priori-schätzung des nächsten Schritts berechnet. Daraus ergibt sich nachfolgende Gleichung 3.1 p k k 1 = F k p k 1 k 1 (3.1) Neben dem Status (welcher im Beispiel Spurrekonstruktion einen Punkt im Detektor darstellt) wird auch für die zugehörige Fehlerkovarianzmatrix C k k 1 eine a-priori-schätzung berechnet. Diese besteht aus der Summe von zwei Termen, die in Gleichung 3.2 angegeben sind. Der erste beschreibt die lineare Fehlerfortpflanzung, der vorherigen Fehlerkovarianzen, der zweite einen Rauschterm. C k k 1 = F k C k 1 k 1 F T k + P kq k P T k (3.2) Nach Berechnung von Gleichung 3.1 und Gleichung 3.2 ist die Time Update Phase abgeschlossen und es folgt die sogenannte Measurement Update Phase. Hier werden die zuvor geschätzten Ergebnisse von p k k 1 und C k k 1 unter Berücksichtigung eines neuen Messwertes korrigiert und aktualisiert und somit ein a-posteriori-wert berechnet. Dazu wird der sogenannte Kalman-Gain K k (siehe Gleichung 3.3) berechnet, der angibt, wie stark diese Korrektur in den neuen Wert einfließt. Die Matrix H k ist hierbei und im Folgenden eine Transformationsmatrix, die dafür c Maik Dankel 29

40 3. Kalman-Filter sorgt, dass die einzelnen Parameter die korrekte Dimensionalität haben, V k beschreibt einen Rauschterm. K k = C k k 1 H T k (V k + H k C k k 1 H T k ) 1 (3.3) Gleichung 3.4 stellt die Korrektur des zuvor geschätzten Wertes von p k k 1 unter Berücksichtigung eines aktuellen Messwertes m k dar. Es wird folglich eine a posteriori Abschätzung des Statusvektors berechnet. p k k = p k k 1 + K k (m k H k p k k 1 ) (3.4) Abschließend wird mittels Gleichung 3.5 die korrigierte Fehlerkovarianzmatrix C k k berechnet. C k k = (I K k H k )C k k 1 (3.5) Gleichung 3.1 und Gleichung 3.2 stellen den Time Update Schritt dar, Gleichung 3.3 bis Gleichung 3.5 entsprechen dem Measurement Update Teil des Kalman-Filters 7. Nach Beendigung beider Schritte werden die aktuellen a posteriori Schätzungen von p k k und C k k als Input für den nächsten Time Update Schritt verwendet und der in Abbildung 3.1 dargestellte Zyklus startet von vorn. Abbildung 3.3 veranschaulicht schematisch die durch den Filter optimierte Spur, die näher an den tatsächlichen Werten liegt Startwerte Eine gewisse Herausforderung stellt das Finden von geeigneten Startwerten für den Filter dar. Im ersten Schritt existiert kein Vorgänger mit Index k-1 auf den zugegriffen werden kann. Werden schlechte Startwerte gewählt, können diverse Probleme auftreten. Die lineare Approximation des Spurmodells könnte falsch sein, falls der Startwert zu weit vom tatsächlichen Wert entfernt liegt. Außerdem könnte die Vorhersage gänzlich fehlschlagen, weil der berechnete Pfad die nächste Detektorlage nicht schneidet. Ein Ansatz zur Lösung dieser Problematik ist eine Referenzspur zu verwenden, die zuvor durch 7 Die angegebenen Gleichungen variieren in verschiedenen Publikationen leicht. Die hier verwendete Notation stammt aus [R. Frühwirth 2000], S. 246 f. c Maik Dankel 30

41 3. Kalman-Filter Abbildung 3.3.: Schematische Darstellung der durch den Kalman-Filter korrigierten Spur Mustererkennungsverfahren ermittelt wird. Es werden zunächst für die Referenzspur sämtliche Schnittpunkte mit den Detektorlagen berechnet und als Referenzwerte p k,r verwendet. Der Filterprozess findet nicht mehr auf den reinen Messwerten statt, sondern auf der Differenz zu dieser zur Referenzspur. Daraus ergibt sich, dass nicht m k, sondern m k = m k H k p k,r verwendet wird. Dieses Prinzip verbessert die Qualität des Filter-Outputs und erleichtert das Finden geeigneter Startwerte ([R. Frühwirth 2000], S. 252). Da eine Differenz hier im Optimalfall null beträgt, kann ohne weiteres Vorwissen dies als Startwert genutzt werden. Wird keine Referenzspur genutzt und null als Startwert gewählt, kann die Abweichung zum eigentlichen Messpunkt beliebig groß werden. Daher wird empfohlen, wann immer möglich eine Referenzspur zu verwenden. Dieses Prinzip auf der Differenz zu einer Referenzspur zu arbeiten wird ebenfalls in dieser Arbeit verwendet (siehe Unterabschnitt 4.3.1) Smoothing Der Kalman-Filter liefert sehr gute Ergebnisse. Die in Abschnitt 3.1 beschriebenen Arbeitsweise des Filters, bei der ein Wert immer nur von seinem Vorgänger abhängt, hat jedoch einen nicht zu verachtenden Nachteil. Jeder neu berechnete Wert enthält immer sämtliche Informationen der bis dahin errechneten Werte, da diese aufeinander aufbauen. Das bedeutet folglich, dass, je weiter c Maik Dankel 31

42 3. Kalman-Filter der Prozess fortgeschritten ist, der Informationsgehalt und damit die Wahrscheinlichkeit genauere Werte zu erhalten steigt. Im Umkehrschluss bedeutet dies aber, dass am Anfang der Reihe sehr wenig Information vorhanden ist und die Wahrscheinlichkeit, dass die errechneten Werte ungenau sind, relativ hoch ist. Um diesem Phänomen entgegenzuwirken, kann eine Technik namens Smoothing (zu deutsch: Glättung) eingesetzt werden. Ziel ist hierbei diesem Ungleichgewicht des Informationsgehaltes entgegenzuwirken. Dazu kann der Kalman-Filter noch einmal auf den selben Daten, jedoch in entgegensetzter Richtung ausgeführt werden. Das bewirkt, dass die Informationsgehalte der einzelnen Zwischenergebnisse in entgegengesetzter Richtung zunehmen. Werden die entsprechenden Werte p f und p b (das hochgestellte f steht für forward, also den Hinweg, das b entsprechend für backward, also den Rückweg) zusammengeführt und gewichtet, wird dadurch ein konsistent hoher Informationsgehalt über die gesamte Messreihe erreicht. Gleichung 3.6 gibt an, wie die Gewichtung der einzelnen Messwerte berechnet wird. Hierzu werden die Fehlerkovarianzmatrizen aus Hin- und Rückweg verwendet. K k = Cf k k (Cf k k + Cb k k ) 1 (3.6) Gleichung 3.7 stellt die Berechnung des geglätteten Wertes dar. Zu beachten ist, dass aus dem Rückwärts-Fit der a-priori-wert p b k k 1 und aus dem Vorwärts-Fit der a-posteriori-wert p f k k verwendet wird, da sonst die jeweilige Messung im Smoothing effektiv doppelt gewichtet würde. p k = pf k k + K k (pb k k 1 pf k k ) (3.7) Letztendlich kann zu dem neuen, geglätteten state-vektor eine zugehörige Fehlerkovarianzmatrix C k berechnet werden. Die Berechnung ist in Gleichung 3.8 dargestellt. C k = (I K k )Cf k k (3.8) c Maik Dankel 32

43 4. Implementierung 4. Implementierung Wie eingangs erwähnt, ist Ziel dieser Arbeit die Implementierung eines, wie in Kapitel 3 beschriebenen, Kalman-Filters zur Rekonstruktion der Spur, die ein Teilchen zurücklegt, wenn es sich durch die einzelnen Detektorlagen bewegt. Da extrem große Datenmengen entstehen, wenn zwei Teilchenströme im Bereich eines Detektors aufeinandergelenkt und zur Kollision gebracht werden, ist das Ziel die Auswertung dieser Daten möglichst mit einem hohen Grad an Parallelität vorzunehmen. Um dies zu erreichen wird das in Abschnitt 2.2 erläuterte OpenCL-Framwork genutzt. Nachfolgend wird das Zusammenspiel und speziell die Umsetzung der zuvor erläuterten Technologien und Algorithmen genauer beschrieben Data-IO und Datenstrukturen Die auszuwertenden Testdaten liegen in diesem Fall in Form eines ROOT-Files vor. ROOT ist eine 1995 vom CERN entwickelte, objektorientierte Software, die insbesondere mit großen Datenmengen umgehen und diese analysieren kann. Es ermöglicht einem (sowohl Endanwender, als auch Entwickler, der dieses Framwork nutzt) Daten effizient und ohne diese verändern zu müssen, zu kombinieren und zu visualisieren. So stehen einem Funktionalitäten wie Histogrammierung, Curve Fitting, Auswertung von Funktionen, sowie weitere Graphik- und Visulisierungsklassen zur Verfügung. Der hier verwendete Datensatz liegt in Form einer Baumstruktur (TTree) vor, die in einer Klasse EventReader ausgelesen und in Events (Kollisionen von Teilchen) und zugehörige Tracks (Spuren der Teilchen) gespeichert werden. 8 Listing 4.1 zeigt solch ein Event, welches der EventReader ausliest. Dieses besteht wiederum aus mehreren Tracks, weshalb es als Vektor von Tracks modelliert ist. 8 Anm.: Die Implementierung der Klasse EventReader war Teil eines Masterprojektes und nicht Bestandteil dieser Arbeit c Maik Dankel 33

44 4. Implementierung 1 typedef std :: vector<track_t> KF_Event_t; Listing 4.1: Definition eines Events Die Track_t-Struktur wird in diesem Fall so modelliert, dass sie aus mehreren Informationen besteht. Zum einen dem eigentlichen Track, der wiederum aus mehreren Hits (also Messpunkten im Detektor) besteht und hier mit track betitelt ist. Zum anderen aus dem Startpunkt der Referenzspur (info) und dem tatsächlichen Startpunkt der Simulation (truthtrackinfo). 1 typedef std :: vector<trackhit_t> TrackData_t; 2 3 struct TrackStruct { 4 TrackData_t track; 5 TrackInfo_t info; 6 TrackInfo_t truthtrackinfo; 7 }; 8 typedef TrackStruct Track_t; Listing 4.2: Definition eines Tracks Die Daten, die ein Track beinhaltet (TrackData_t) sind, wie in Listing 4.2 gezeigt, als Vektor von Trackhits (TrackHit_t) modelliert. Der Aufbau eines Trackhits ist in Listing 4.3 abgebildet. 1 struct TrackHitStruct { 2 scalar_t normal[order]; 3 scalar_t ref [ ORDER]; 4 scalar_t err_locx; 5 scalar_t err_locy; 6 scalar_t cov_locxy; 7 scalar_t jacobi [ ORDER ORDER]; 8 scalar_t jacobiinverse [ ORDER ORDER]; 9 char is2dim; 10 int dettype; 11 int bec; 12 }; 13 typedef struct TrackHitStruct TrackHit_t; Listing 4.3: Definition eines Tracks c Maik Dankel 34

45 4. Implementierung Wie in Listing 4.3 zu sehen, beinhaltet ein einzelner Hit sehr viele Informationen. So existiert zu jedem Hit ein Array ref in der Dimension ORDER (ORDER ist ein Projektweites #define und ist in diesem speziellen Fall auf 5 festgelegt), das einen Vektor darstellt, der den Punkt der Refernzspur im Detektor repräsentiert. Der Datentyp dieser Werte ist scalar_t, welcher über ein #define auf float oder double (oder sonstige benötigte Datentypen) festgelegt werden kann. Der Vektor sieht folgendermaßen aus: ref = ref LocX ref LocY refp hi reft heta ref QoverP reflocx und reflocy geben die Position des Hits in X/Y-Koordinaten an, ref- Phi und reftheta beschreiben Winkel der Flugbahn und refqoverp beschreibt die Krümmung der Flugbahn. Entsprechend dazu existiert ein Vektor der simulierten Hits, bei dem allerdings die Werte Phi, Theta und QoverP gleich null sind, da ein Messwert nur über einen Punkt im Koordinatensystem verfügt, nicht aber über die Eigenschaften eines sich bewegenden Teilchens. normal = locx locy Des Weiteren existiert zu einem Hit eine Matrix, die die Propagation von Detektorlage i-1 nach Lage i beschreiben. Das ist die sogenannte Jacobi-Matrix F k, die in Gleichung 3.1 und Gleichung 3.2 auftaucht und hier mit jacobi[order*order] bezeichnet ist. Der Einfachheit halber wird in dieser Datenstruktur zusätzlich die Inverse dieser Matrix unter jacobiinverse abgelegt, da diese beim Rückwärtsfit benötigt wird. Außerdem existiert zu jedem Hit eine Information über den Detektortyp (det- Type), der angibt, in welchem Bereich des Detektors sich der Hit befindet. Zusätzlich ist ein Wert is2dim vorhanden, welcher ein Flag darstellt, das angibt, ob die Messung eindimensional, oder zweidimensional berücksichtigt werden soll. Dies stellt einen Spezialfall dar, welcher in Abschnitt 4.2 genauer erc Maik Dankel 35

46 4. Implementierung läutert wird. Die Werte err_locx, err_locy und cov_locxy werden für die Matrix V k aus Gleichung 3.3 benötigt Host-Code Abbildung 4.1.: Arbeitsweise der Implementation Der Ablauf der implementierten Software kann, wie in Abbildung 4.1 dargestellt, grob in sechs Stufen eingeteilt werden. Vier davon sind Aufgaben, die auf dem Host-System ausgeführt werden (blau hinterlegt) und zwei Schritte erfolgen auf dem Device (rot hinterlegt). Nachfolgend wird die hostseitige Implementierung erläutert und in Abschnitt 4.3 der entsprechende Device-Code. Im ersten Schritt werden, unter Verwendung des EventReaders, Daten aus dem ROOT-File ausgelesen und in den in Listing 4.1 und Listing 4.2 angegeben Datenstrukturen gespeichert. Anschließend werden die für die Ausführung des OpenCL-Codes erforderlichen Elemente, wie program und kernel, erstellt und initialisiert. Im Anschluss startet der Hauptteil der Software in Form einer Schleife, die alle Events und alle darin enthaltenen Tracks bearbeitet. Wie im Pseudocode in Listing 4.4 zu sehen ist, erfolgt die Bearbeitung der Daten auf Seiten des Hosts seriell. Es werden sowohl die Events, als auch die darin enthaltenen Tracks nacheinander abgearbeitet. Es folgt zunächst eine Intitalisierungsphase, bei der die zur Verfügung stehenden Daten vorverarbeitet werden und Speicherplatz reserviert wird. Abbildung 4.2 stellt schematisch dar, wie die Aufteilung des Speichers erfolgt, in dem die zu bearbeitenden Daten gespeichert werden. Es werden für die Werte, die vom Kalman-Filter berechnet werden (fits[]), (ORDER*hitcount)*3 c Maik Dankel 36