Abschied vom Multicore-Ansatz
Bildverarbeitung mit Kombination von CPU und GPU
Die Bildverarbeitung ist rechenintensiv und beansprucht immense Prozessor- und Speicherressourcen. Eine Parallelisierung mittels mehrerer CPU-Kerne hilft zwar, doch selbst mit heutigen Zweikern-, Vierkern- oder Mehrkern-Prozessoren benötigen Multimedia-Anwendungen entweder sehr viel Energie oder erfordern den Einsatz zusätzlicher Bildverarbeitungs-Hardware. Setzt man aber zusätzlich zur CPU parallele Recheneinheiten als programmierbare Beschleuniger ein, bietet dies eine gute Balance aus universeller Rechenleistung, hoher Performance und geringem Energieverbrauch. Beispiele verdeutlichen, wie sich mit einer Kombination von CPU und GPU die Performance und das Leistung-pro-Watt-Verhältnis auf das Zwei- bis Dreifache verbessern lassen.
Bis vor Kurzem hat man Multicore vornehmlich unter dem Gesichtspunkt homogener CPU-Architekturen betrachtet. Ein typischer Ansatz war, zwei, vier oder mehr Kerne zu einem symmetrischen Multicore-Prozessor (SMP) zu gruppieren oder in einer cache-kohärenten nicht-uniformen Speicher-Anordnung (ccNUMA) zu integrieren. Manchmal verfügen diese Architekturen über zusätzliche Hardware-Beschleuniger, um besonders anspruchsvolle Aufgaben an diese zu übergeben, wie etwa CAVLC oder noch rechenintensivere CABAC Entropiekodier-Funktionen, wie sie zur H.264 Video-Verarbeitung genutzt werden. Viele Prozessorhersteller bieten ihre Plattformen nun mit integrierter Grafik an, meist um Platz auf dem Board und Materialkosten einzusparen. Dabei bietet eine integrierte Graphics Processing Unit (GPU) noch einen weiteren Vorteil: Sie stellt einen weiteren Lösungsweg dar, mit dem anspruchsvolle Rechenaufgaben gemeistert werden können. Ein gutes Beispiel hierfür sind AMDs R-Series Prozessoren, welche die ‚Bulldozer‘ CPU-Architektur mit einer AMD Radeon GPU auf dem Leistungsniveau einer dedizierten Grafikkarte kombinieren. Diese Kombination bildet eine neue Prozessorklasse, genannt Accelerated Processing Unit oder kurz APU (Bild 1). Die GPU besteht aus mehreren Single Instruction Multiple Data (SIMD) Processing Elementen. Beide, SIMD-Engines und x86er Kerne werden über einen gemeinsamen Speicher-Controller angesprochen. Diese Architektur repräsentiert einen ersten Schritt in der Entwicklung hin zu AMDs Heterogener System Architektur (HSA), die sich signifikant vom traditionellen Multicore-Ansatz unterscheidet: HSA nutzt die integrierte Grafikeinheit als weitere Ressource zur Datenverarbeitung, da die Grafikeinheit auch für die Verarbeitung von ’normalen‘ nicht-grafischen Daten genutzt werden kann. Das Prinzip funktioniert ähnlich wie zusätzliche Hardwarebeschleuniger, jedoch mit dem Vorteil, dass es sich um eine große Anzahl programmierbarer Einheiten handelt – bis zu 384 Kerne in der Maximalauslegung – mit einem Rechendurchsatz in der Größenordnung von mehreren hundert Gflops.
Datenparallele Anwendungen für höheren Datendurchsatz
Tabelle 1 beschreibt die grundlegenden Daten einer AMD Desktop-Plattform. Diese weist dieselbe Architektur auf, wie die AMD R-Series APU. Die Bulldozer-basierte CPU bietet mit 121,6Gflops eine gute Fließkomma-Performance, wird jedoch von der GPU klar in den Schatten gestellt: Die GPU bietet entsprechenden Applikationen bis zu 614Gflops Rechenleistung. Um die Recheneinheiten der GPU für die Bildverarbeitung einsetzen zu können, ist eines von besonderer Bedeutung: Man muss die Zeit berücksichtigen, welche nötig ist, um einen Datenblock an die GPU zu übergeben, dort zu bearbeiten und anschließend wieder an die Hauptprogrammroutine auf der CPU zurückzuführen. Obwohl bei der aktuellen Generation der AMD R-Series APUs der Datentransfer zwischen GPU und CPU zwar noch auf einen Zwischenspeicher angewiesen ist, können datenparallele Anwendungen dennoch deutliche Verbesserungen bei Datendurchsatz und Energieeffizienz erzielen, die den Aufwand für den Datentransfer deutlich überwiegen. Ein Beispiel für eine solche datenparallele Anwendung ist Handbrake, ein weitverbreitetes Programm zur Videokonvertierung, das unter einer Vielzahl von Betriebssystemen und auf unterschiedlichen Hardware-Plattformen läuft. Das Programm zeichnet sich durch einen gut integrierten Multicore-Support aus. Das macht das Tool zu einer guten Plattform, um die Effektivität von Multicore-Strategien zu überprüfen. Handbrake nutzt X264, einen vollausgestatteten H.264-Encoder, der eine gute Multicore-Unterstützung bietet. In dieser und der folgenden Anwendung wurde OpenCL eingesetzt, um die in der APU verfügbare Rechenkapazität der GPU nutzbar zu machen. In X264 wurde die Qualitätsoptimierung mit der dazugehörigen Lookahead-Funktion komplett in OpenCL umgesetzt und auf die GPU ausgelagert. Diese Funktionen werden in Applikationen für die Videokonvertierung eingesetzt, um die Ausgabe-Qualität eines Videos zu verbessern. Normalerweise beanspruchen sie bis zu 20% CPU-Zeit. Handbrake nutzt X264 als Video Encoder. Außerdem nutzt es OpenCL für die Videoskalierung und um den Farbraum von RGB auf YUV zu konvertieren. Unter Handbrake übernimmt AMDs Hardware Video Decoder (UVD) auch einige Aufgaben der Videodekodierung. Die Daten wurden auf einem AMD Trinity A10-Desktop-System ermittelt. Die zugrundeliegende Prozessorarchitektur der genutzten APU ist aber identisch zu der in den Embedded-Produkten eingesetzten.
Fünf mal besserer Fließkomma-Durchsatz
Da die APU eine komplexe Power Management-Architektur aufweist und um die Analysen zu vereinfachen, wird nur die maximale Thermal Design Power (TDP) betrachtet, anstatt den Energieverbrauch jedes einzelnen Subsystems herauszuarbeiten. Die Daten zeigen: Wird die Berechnung nur über die CPU ausgeführt, wird eine Bildrate von 14,8fps erzielt. Die Berechnung ist in 62s abgeschlossen. Nimmt man die GPU und die UVD Blocks zur Berechnung hinzu, steigt die Framerate auf 18,3fps. Die Rechendauer und damit auch der Energieverbrauch, sinken auf 48s (22%). Die in Tabelle 2 aufgeführte Gesamtzahl der Fließkomma-Operationen resultiert aus dem Fließkomma-Durchsatz, wie in Tabelle 1 dargestellt, und der Rechenzeit. Daraus lässt sich wiederum eine Kennzahl ableiten: die Operationen-pro-Watt. Betrachtet man die Gesamtzahl der Fließkomma-Operationen und die normalisierten Operationen-pro-Watt, wird schnell deutlich, dass die verfügbaren Ressourcen nicht voll ausgeschöpft werden. Mit der CPU allein lässt sich ein Durchsatz von 75 Operationen-pro-Watt erzielen. Wird die GPU zur Berechnung hinzugezogen, erhöht sich die Zahl auf 353 Operationen-pro-Watt; der theoretische Fließkomma-Durchsatz verbessert sich dabei auf fast das Fünffache (4,7). Die zuvor aufgeführten 22% Ersparnis sind beachtlich. Aber während diese Generation von APUs signifikante Fortschritte in Richtung HSA macht, sind die Speicherzugriffe hinsichtlich Latenz und Durchsatz nicht einheitlich. Der Kernel greift direkt auf den Speicher zu. Solche Operationen werden mit einer theoretischen Rate von 22GB/s durchgeführt, bzw. mit 16 bis 18GB/s in gewöhnlichen Applikationen. Wenn aber ein Zwischenspeicher im Hostspeicher eingefügt wird, um auf die Daten der GPU zuzugreifen, werden die Daten über einen anderen Pfad geleitet, bei dem die effektive Bandbreite eher im Bereich von 8GB/s liegt, d.h. die Bandbreite bei einem lokalen Speicherzugriff des Kernels im Vergleich zur Speicherbandbreite über einen Zwischenspeicher auf den GPU-Speicher ist rund dreimal schneller. Dabei ist dieses Verhältnis symmetrisch: Benötigt die GPU Daten aus dem CPU-Speicher, würde das gleiche Verhältnis gelten. Zukünftige Plattformen, die vollständig der HSA-Architektur entsprechen, werden über ein einheitliches Speichermodell verfügen und müssen dann Daten nicht mehr zwischen den CPU- und GPU-Speicherbereichen kopieren. Algorithmen, wie die Lookahead-Funktionen von X264, werden dann über die nahezu gleiche Speicherbandbreite verfügen, auch wenn sie auf der GPU ausgeführt werden. Ein zweites Beispiel einer datenparallelen Anwendung ist Luxmark, ein grafikorientiertes Benchmarking-Tool. Es nutzt OpenCL und zeigt, was sich erreichen lässt, wenn keine Unterschiede mehr in der Speicherzugriffszeit bestehen. Der standardmäßig integrierte Benchmark wurde auf einer AMD Embedded R-464L-APU ausgeführt. Die GPU bietet für diesen Aufgabenbereich eine um 25% bessere Leistung als die CPU. Bei einer vollständigen HSA-Implementierung würde man erwarten, dass die Kombination aus CPU und GPU einen Wert erzielt, der in etwa der Summe der Einzelwerte von CPU+GPU entspricht, nämlich 344. In der Praxis jedoch zeigt sich ein Ergebnis von 230. Das ist zwar eine beachtliche Steigerung von 63%, spiegelt allerdings nicht das mögliche volle Potenzial wider. Die Differenz erklärt sich hauptsächlich durch den Overhead, der entsteht, wenn die CPU Daten umwandelt und diese an die GPU übergibt und sie dann wieder zurückgeschrieben werden – und das mit der zuvor beschriebenen geringeren Geschwindigkeit. Volle HAS-Konformität wird es ermöglichen, die CPU und die GPU mit minimalem Overhead zu nutzen und so von einer deutlich verbesserten kombinierten Performance von CPU und GPU zu profitieren, als es beide Einheiten jeweils alleine bieten könnten.
