Kurzfassung. Die moderne medizinische Bildgebung ermo¨glicht immer detailliertere Daten, deren Weiterverarbeitung sich um so zeitaufwendiger gestaltet. Von der Medizin werden jedoch immer schnellere Bildverarbeitungsalgorithmen gefordert. Um diese Forderung zu erfu¨llen, mu¨ssen alle zur Verfu¨gung stehenden Ressourcen genutzt werden. Die Grafikkarte ist eine dieser verfu¨gbaren Ressourcen und kann fu¨r die Parallelisierung von Bildverarbeitungsalgorithmen herangezogen werden. Damit die Bildverarbeitungsprozesse unkompliziert auf die Graphikkarte ausgelagert und parallel berechnet werden ko¨nnen, wird in diesem Beitrag eine Hardware-unabha¨ngige Erweiterung des Medical Imaging Interaction Toolkit vorgestellt. Die Ergebnisse zeigen eine wesentliche Beschleunigung der Algorithmen auf der Grafikkarte.
1 1 GFLOPS = 1 106 floating point operations per second und AMD eigene Programmiersprachen und Kompiler vero¨ffentlicht (NVIDIA CUDA and ATI Stream). Diese jedoch sind nur auf die jeweilige Plattform begrenzt und bieten keine Portabilita¨t. Aktuell steuert die GPU Programmierung in eine Hardware-unabha¨ngige Zukunft. Am 8. Dezember 2008 erschien die erste Spezifikation von Open Common Language (OpenCL) Version 1.0, herausgegeben von der Khronos Group.
Um die GPU Beschleunigungsvorteile auch in der allgemeinen und speziell
der medizinischen Bildverarbeitung auszunutzen, sind in letzter Zeit mehrere
Projekte entstanden, die sich auf Parallelisierung von Algorithmen konzentriert
haben. Die GpuCV Bibliothek [
In diesem Beitrag wird eine Erweiterung fu¨r das Open Source Medical
Imaging Interaction Toolkit (MITK [
Ziel der Erweiterung ist es, die Grafikkarte als allgemeine Recheneinheit fu¨r die Bildverarbeitung zur Verfu¨gung zu stellen ohne dabei eine bestimmte HardwareKonfiguration vorauszusetzen. Aus diesem Grund wurde fu¨r die Realisierung OpenCL gewa¨hlt. Stehen keine von OpenCL ansteuerbare Grafikkarten zur Verfu¨gung, werden die Operationen wie gewohnt auf der CPU ausgefu¨hrt.
Voraussetzung fu¨r die Integration der Erweiterung war ein nahtloses Einfu¨gen in die bestehenden Konzepte. Daher wurde auf ITK2 Konzepten aufgebaut, welche sich in der medizinischen Bildverarbeitung als Standard etabliert haben. ITK ermo¨glicht es komplexe Berechnungen aus einzelnen Filtern in einer Bearbeitungspipeline zusammenzusetzen. Anhand der MITK OpenCL-Erweiterung lassen sich OpenCL-basierte Filter analog zu den ITK-Filtern in eine MITK Bearbeitungspipeline einreihen oder beliebig austauschen. 2.1
Als erstes muss wa¨hrend der Laufzeit von einem Verwaltungsobjekt (contextmanager) untersucht werden, ob eine OpenCL-fa¨hige Grafikkarte zur Verfu¨gung steht und wenn ja, ob der Speicherbedarf des Filters auf der Grafikkarte gedeckt werden kann. Ist dies der Fall, so werden die Daten vom Filter in den Grafikspeicher kopiert. Jetzt ko¨nnen die parallelisierten Einzelberechnungen, die in einer dem Filter zugeordneten Datei definiert sind, mit hoher Datendurchsatzrate bearbeitet werden. Das Ergebnis der Berechnung wird ebenfalls auf der Grafikkarte 2 Insight Toolkit gespeichert. Wenn keine OpenCL-fa¨hige Grafikkarte vorliegt oder nicht genu¨gend Speicher frei ist, wird die Filter-Pipeline nicht unterbrochen, sondern die entsprechende CPU-basierte Version des Filters ausgefu¨hrt. Der context-manager ermo¨glicht weiterhin die filteru¨bergreifende Verwendung eines einzelnen OpenCLKontextes, da ein sta¨ndiger Kontextwechsel unno¨tige Zeit beanspruchen wu¨rde. Zusa¨tzlich ko¨nnen mehrere OpenCL-Filter durch die Verwaltung hintereinander angeordnet werden (Abb. 1). Um das Filterpipeline-Konzept zu realisieren und gleichzeitig die Latenz-Zeiten bei Speicherzugriffen minimal zu halten ist ein besonderer Umgang mit den Daten notwendig. Die zugeho¨rigen Daten liegen entweder im Arbeitsspeicher, im Grafikspeicher oder sogar in beiden. Daher ist es vorteilhaft Daten erst dann aus dem GPU Speicher zu kopieren, wenn sie tatsa¨chlich im Arbeitsspeicher gebraucht werden und vice versa.
Die MITK-OpenCL Erweiterung arbeitet mit eigenen Datenobjekten fu¨r Bild-, Oberfla¨chen- und Punktmengendaten. Diese werden von den entsprechenden MITK Datenklassen abgeleitet und um die notwendigen Membervariablen und Methoden zum Verwalten der Kopiervorga¨nge zwischen RAM und dem Grafikspeicher erweitert. 2.2
Neben u¨blichen Bildverarbeitungsalgorithmen (Konvolutionsfilter) wurde die
Parallelisierung mit der Erweiterung auch fu¨r sequentielle Monte-Carlo Methoden
(SMCM) durchgefu¨hrt. Diese Methoden arbeiten mit unabha¨ngigen
Zufallsproben (Partikeln), wobei die Genauigkeit einer SMCM direkt von der Anzahl der
Partikel abha¨ngt. Ein Einsatzgebiet fu¨r die SMCM ist das Kompensieren von
Rauschen bei Navigationsaufgaben, wie zum Beispiel der navigierten
Bronchoskopie [
Abb. 1. Integration von OpenCL Filter in eine bestehende MITK Filter-Pipeline. Tabelle 1. Laufzeitmessungen fu¨r einen Update-Schritt des Partikelfilters innerhalb der navigierten Bronchoskopie-Anwendung. Fu¨r die GPU Variante ist die Initialisierungszeit nicht inbegriffen, da sie nur einmalig beim ersten Update-Schritt no¨tig ist. Partikel CPU [ms] GPU [ms] Die Evaluation konzentriert sich auf die GPU Plattform. Die Laufzeitmessungen wurden mit folgender Hardwarekonfiguration durchgefu¨hrt – CPU: Intel Core i7 (Quadcore) 2.66 GHz; GPU: NVIDIA GeForce GTX 465. Gemessen wurde zuerst auf neun ku¨nstlichen Daten der Gro¨ße 2k 2l 2m und anschließend auf zehn unterschiedlichen medizinischen Daten (Abb. 2).
Die Tabelle 1 fasst die erzielten Ergebnisse bei der parallelen Implementierung des Partikelfilters in der Beispielanwendung zusammen.
Die Laufzeitmessungen (Abb. 2) zeigen einen Beschleunigungsfaktor bei maximaler Bildgro¨ße von 10 fu¨r den Gaussfilter bzw. 100 fu¨r den Opening-Filter. Die linke Grafik zeigt gleichzeitig ein typisches Pha¨nomen fu¨r kleinere DatenAbb. 2. Laufzeitmessungen fu¨r CPU bzw. GPU Implementierungen auf ku¨nstlichen Testdaten (+ bzw. ) fu¨r Gauss- (links) und Opening-Filter (rechts) auf medizinischen Bilddaten verschiedener Modalita¨ten (CT, MR) und Scanbereiche. sa¨tze. Aufgrund der no¨tigen Initialisierungsschritte inklusive Kompilieren des Quellcodes fu¨r die GPU, muss man mit einer festen minimalen Laufzeit der GPU-basierten Implementierung rechnen. Diese liegt im Bereich von 300-400 ms. Jedoch wird dieser Zusatzbedarf nur bei der ersten Ausfu¨hrung eines Filters beno¨tigt. In der Beispielanwendung (Tab. 1) konnte durch die GPU Beschleunigung die Update-Rate des Partikelfilters deutlich erho¨ht werden, sodass auch fu¨r ho¨here Anzahl von Partikeln eine Anwendung in Echtzeit ermo¨glicht wird. 4
In der vorliegenden Arbeit wurde eine Hardware-unabha¨ngige Erweiterung fu¨r GPGPU Anwendungen innerhalb von MITK vorgestellt. Die Erweiterung bietet eine Unterstu¨tzung fu¨r Entwickler, die nicht im Detail mit der GPU Programmierung vertraut sind und innerhalb ihrer Applikation die Parallelisierung auf der Grafikkarte fu¨r die Bildverarbeitung nutzen wollen. Die Erweiterung u¨bernimmt fu¨r die Entwickler die OpenCL Initialisierung und Datenverwaltung, weiterhin ko¨nnen OpenCL-Filter analog zum Konzept der ITK-Filterpipeline beliebig eingegliedert werden.
Auch wenn ein direkter Laufzeitvergleich von CPU- und
GPU-Implementierungen oft einen positiven Bias fu¨r die GPU besitzt [
Literaturverzeichnis