Brook for GPUs: Stream Computing on Graphics Hardware

Transkript

1 Ausarbeitung zum Thema Brook for GPUs: Stream Computing on Graphics Hardware Ian Buck, Tim Foley, Daniel Horn, Jeremy Sugerman, Kayvon Fatahalian, Mike Houston and Pat Hanrahan von Aldo Mühlhause Hauptseminar Graphische Datenverarbeitung Betreuung PD Dr. S. Gumhold

2 Inhaltsverzeichnis 1 EINLEITUNG ALLGEMEINES ARITHMETISCHE INTENSITÄT ZIELE STREAM-PROZESSOR-MODELL ENTWICKLUNG DER GAFIKHARDWARE-PROGRAMMIERUNG FEATURES STREAMS KERNELS REDUCTIONS IMPLEMENTIERUNG ARCHITEKTUR STREAMS KERNELS REDUCTIONS EVALUATION TESTUMGEBUNG TESTPROGRAMME ERGEBNISSE SCHLUSSFOLGERUNGEN AUSBLICK

3 1 Einleitung 1.1 Allgemeines Im Mittelpunkt der kommenden Betrachtungen steht die Auseinandersetzung GPU vs. CPU im Vordergrund. Aktuelle GPUs sind deutlich schneller als CPUs. Mit einer GeForce FX 5900 Ultra erreicht man z.b. eine Leistung von 20 GFLOPS. Für die gleiche Leistung bräuchte ein Pentium 4 eine Taktrate von 10 GHz. Jedoch sind GPUs schwer und umständlich zu programmieren. Aus diesem Grunde wurde BrookGPU von der Universität Stanford entwickelt. Brook beinhaltet einen Compiler, eine Sprache und ein Runtime-System für aktuelle GPUs. Die CPU soll jedoch immer noch universell nutzbar bleiben und ist sogar notwendig um die GPU-Programmierung zu organisieren. Bisher grundlegende Konzepte der GPU-Programmierung sind der Vertex-Shader und der Fragment-Shader. OpenGL und NVIDIA Cg sind die wichtigsten Programmierumgebungen für GPUs. Schwierig wird bei ihnen jedoch die Zuweisung des Textur-Speichers, die Konstruktion grafischer primitiven und das Laden von Shader-programmen. Für eine intensive GPU-Programmierung ist breites Wissen über Grafik-API notwendig und man unterliegt Einschränkungen durch die Grafikhardware. Die Brook-Programmierumgebung soll dem entgegen wirken. Die Sprache ist C- ähnlich und kann für aktuelle GPUs genutzt werden. Die GPU soll als Streaming- Coprozessor arbeiten und somit parallele Datenoperationen ermöglichen. Parallele Datenoperationen werden im Wesentlichen durch Streams ermöglicht. Zudem steht die Erhöhung arithmetischer Intensität im Vordergrund. 1.2 Arithmetische Intensität Die arithmetische Intensität beschreibt das Verhältnis arithmetischer Operationen zur Speicher-Bandbreite. Durch die Erhöhung der arithmetischen Intensität wird also versucht ein besonderes Augenmerk auf die Berechungszeit der arithmetischen Operationen zu legen. Eine höhere Gewichtung der Berechnungszeit ist von Vorteil, da man nicht abhängig von der Bandbreitenbeschränkung ist und die eigentliche Geschwindigkeit der Recheneinheit in den Vordergrund rückt. Dies macht die eigentliche Stärke der GPU aus, welche mehr auf der eigentlichen Berechungszeit liegen als auf der Bandbreite. Die Erhöhung der arithmetischen Intensität wird im Wesentlichen durch die Verwendung von Kernels realisiert. 1.3 Ziele Wie bereits erwähnt soll die GPU als allgemeiner Streaming-Coprozessor betrachtet werden. Des Weiteren sollen GPU basierte Berechnungen für die breite Masse zugänglich gemacht werden. Für den Programmierer sollen somit keine - 3 -

4 zusätzlichen Erfahrungen über die Computergrafik notwendig sein. Außerdem wird versucht störende GPU-Begrenzungen zu umgehen. Dennoch wird Wert auf die Performance gelegt. Hierbei soll der Vorteil in der Berechnungszeit gegenüber der CPU immer noch möglichst voll ausgeschöpft werden. Brook stellt sich zu dem als plattformunabhängig dar. Es werden Grafikkarten von ATI und NVIDIA unterstützt. DirectX- und OpenGL-Versionen sind möglich. Die Betriebssysteme Windows und Linux werden unterstützt. 1.4 Stream-Prozessor-Modell Das Model für eine Grafikhardware entspricht zum Größten Teil dem eines Vektorprozessors: Ein Shader-Programm arbeit mit einzelnen Elementen aus dem Inputregister und schreibt die Ergebnisse in das Outputregister. Es werden temporäre Register genutzt. Dies ist der wesentliche Unterschied zu Streamprozessoren. Hierbei wird auf einzelnen Elementen einer Menge von Eingabeströmen gearbeitet und als Ergebnis ein oder mehrere Ausgabeströme erzeugt. Während Vektorprozessoren nur eine einzelnen Operationen auf den Daten ausführen können, sind Stream-Prozessoren in der Lage mehre Operationen auf den Eingabestrom auszuführen. Modell einer Grafikhardware Stream-Prozessor-Modell - 4 -

5 1.5 Entwicklung der Gafikhardware-Programmierung NVidia und ATI Extensions waren nur für spezielle Grafikkarten geeignet. Die Programmierung der Grafikkarten geschah auf der Low-Level-Ebene. Breites Wissen über die Grafikkarten-API und über die Hardwareprogrammierung an sich war notwendig. Zudem konnten nur wenige Funktionen programmiert werden. Die folgenden OpenGL - ARB Extensions entstanden aus einem Zusammenschluss mehrerer Firmen. OpenGL sollte abstrakter werden. Man wollte auch unabhängiger von spezieller Hardware werden. Die Programmierung an sich blieb jedoch Assembler ähnlich. NVidias Cg zeigt einen Versuch (von mehreren) die Grafikhardware-Programmierung auf einer höheren Ebene zu praktizieren. Nvidia Cg ist eine C-basierte, High-Level-Programmiersprache. Eine hohe Kompatibilität zu anderen Sprachen ist gegeben. So können zum Beispiel Ergebnisse in DirectX Shader oder OpenGL Extension übersetzt werden. Brook setzt nun auf diesem Ansatz auf. Die Grafikhardware-Programmierung soll noch universeller und weiter abstrahiert werden. Losgelöst von der Hardwareschicht soll die Programmierung auf andere bereiche ausgedehnt werden. Cg Programmierer sind z.b. noch immer selber auf spezifische API Aufrufe angewiesen. In Brook wurde das Stream-Management weiter abstrahiert, um unabhängiger von der API zu werden

6 2 Features 2.1 Streams Streams sind definiert über eine Menge von Daten auf denen parallele Operationen ausgeführt werden können. Sie bestehen aus Elementen und haben eine Form. Die Form ist definiert über die Dimension des Streams. Streams sind mit gewöhnlichen Arrays zu vergleichen. Jedoch erlauben sie keine Indizierung. Somit besteht keine Abhängigkeit zwischen den einzelnen Elementen und parallele Operationen sind gewährleistet. Der Ausdruck float s<10,5> beschreibt z.b. einen 2-dimensionalen Stream vom Typ Float. Er enthält 50 Elemente und hat die Form 10 zu 5. Es werden die Typen float, sowie float2, float3 und float4(vektor-typen von NVIDIA Cg) unterstützt. Auch ist es möglich sich Strukturen als Kombination dieser Typen zu definieren. typedef struct ray_t { float3 o; float3 d; float tmax; } Ray; Ray r<100>; Durch die Verwendung dieser Strukturen wird zusätzlich noch einmal von der Grafikhardwareebene abstrahiert. Der Programmierer ist nicht direkt an Datentypen aus der Hardwareprogrammierung gebunden und kann sich selbst eigene Datentypen generieren. Eine gewisse Unabhängigkeit ist somit gegeben. Die Befehle StreamRead und StreamWrite transferieren Daten zwischen den Streams und dem Speicher. Vor einer Sequenz von Kernels werden somit die Daten aus dem Speicher geholt (StreamRead), die Kernels ausgeführt und danach das Ergebnis wieder in den Speicher zurück geschrieben (StreamWrite). Ein wesentlicher Nachteil entsteht hierbei für die GPU, weil bei CPU-Berechnungen die Befehle entfallen. 2.2 Kernels Kernels sind spezielle Funktionen die auf Streams ausgeführt werden können. Kernels verstärken den Focus auf die Zeit, in der eine Operation ausgeführt wird. Dadurch sind sie wesentlicher Bestandteil für die arithmetische Intensität. Der Aufruf eines Kernels auf einen Stream erzeugt implizit eine Schleife die über alle Elemente des Streams läuft. Akzeptiert werden verschiedene Typen als Argument: Input-Streams(read-only) enthalten Daten für Kernel-Prozess Output-Streams(writeonly) sind gekennzeichnet durch Schlüsselwort out und enthalten das Ergebnis der Berechnung, Gather-Streams(read-only) sind definiert über C-array-Syntax und können beliebig indiziert werden Konstanten(read-only) bezeichnen alle Elemente die keine Streams sind

7 Ein Kernel kann beliebig viele Output-Streams haben. Durch die Verwendung von Gather-Streams hat der Programmierer die Wahl zwischen Arrays und Streams. Der Gather-Stream erlaubt es auf beliebige Elemente zuzugreifen. Bei einem Stream werden pro Kernelaufruf alle Elemente durchlaufen. Somit zwingt Brook den Programmierer zwischen Daten, auf die von der Kernel über Gather-Operationen zugegriffen wird und Daten, die via Input Streams zu den Kernels transferiert werden, zu unterscheiden. Somit kann das System die Streams unterschiedlich behandeln. Auf Input-Streams wird in einem regelmäßigen Muster zugegriffen. Die Elemente werden in einem Kernelaufruf nicht wiederverwendet. Auf Gather-Streams erfolgt ein zufälliger Zugriff und hier können Elemente wiederverwendet werden. Die Verwendung von Kernels macht einen wesentlichen Unterschied zwischen Stream-Programmierung und Vektor-Programmierung aus. Kernels können beliebige, Funktionsauswertungen behandeln, während Vektor-Operationen aus einfachen mathematischen Berechungen bestehen. Vektor-Operationen erfordern, dass temporäre Daten, in großen Vektor-Register- Dateien gespeichert werden. Bei Kernels werden diese Daten in lokalen Registern gespeichert. Somit wird die Bandbreitennutzung reduziert und die arithmetische Intensität dadurch erhöht. kernel void foo (float a<>, float b<>, float t, float array[], out float result<>) { result = array[t] + a + b; } float a<100>; float b<100>; float c<100>; float array<25> foo(a,b,3.2f,array,c); In diesem Beispiel ist foo ein Kernelaufruf. Die Variablen a und b sind Input-Streams. Als Output-Stream wurde c definiert. Array beschreibt hier ein Gather-Stream und t (3.2f) wird als Konstante behandelt. Der Ablauf in der Kernel sieht wie folgt aus: for (i=0; i<100; i++) c[i] = array[t]+a[i]+b[i]; Hierbei werden a und b komplett durchlaufen. Hingegen wird array nur an einer konstanten Stelle aufgerufen

8 2.3 Reductions Reductions berechnen aus einer Menge von Daten (Streams) einzelne Werte. Aus einem einzelnen Input-Stream werden ein kleinerer Output-Stream oder einzelne Werte berechnet. Das Schlüsselwort für den Output ist reduce. Reductions werden z.b. für die Berechnung der arithmetische Summe oder des Maximums verwendet. Da es sich hierbei um eine assoziative Operation handelt, ist es möglich Reductions in einer beliebigen Reihenfolge auszuführen. Die Form von Input- und Output-Stream entscheidet welche Elemente reduziert werden. kernel void mul (float a<>, float b<>, out float c<>) { c = a * b; } reduce void sum (float a<>, reduce float r<>) { r += a; } float A<50,50>; float x<1,50>; float T<50,50>; float y<50,1>;... mul(a,x,t); sum(t,y); In diesem Beispiel wird mit Hilfe einer Reduction eine Vektor-Matrix-Multiplikation der Form y=ax ausgeführt. X und y sind Vektoren und A (und T) eine Matrix. X enthält den Eingabevektor und y ist das Ergebnis. A beschreibt die Eingabematrix und T wird zur Zwischenspeicherung genutzt. Der Stream x besteht somit aus einer Zeile und 50 spalten. Aufgrund der folgenden Berechung wurde dieser Vektor praktisch um 90 Grad gedreht. Y besteht aus 50 Zeilen und einer Spalte. A und T haben jeweils 50x50 Elemente. Zunächst wird über einen Kernelaufruf x mit A elementenweise multipliziert. Das Ergebnis wird in T zwischen gespeichert. Für eine vollständige Vektor-Matrix

9 Multiplikation müssen nun alle Werte einer Zeile aus T aufsummiert werden. Dies übernimmt die Reduction. Anhand der Form von y und T entscheidet die Reduction das jeweils ein Wert in y (zeilenweise) alle aufsummierten Werte der entsprechende Zeile aus T enthält. reduce void sum (float a<>, reduce float r<>) { r += a; } float a<20>; float r<5>; sum(a,r); In diesem Beispiel sind a und r eindimensionale Streams. Durch die Verwendung der arithmetischen Summe wird a zu r reduziert. Folgender Code wird in der Reduction ausgeführt: for (int i=0; i<5; i++) r[i] = a[i*4]; for (int j=1; j<4; j++) r[i] += a[i*4 + j]; Aus a werden also immer vier Werte zu einem Wert in r reduziert

10 3 Implementierung 3.1 Architektur Die oberste Ebene beschreibt die Brook source files. Darunter befindet sich der source to source compiler. Dieser basiert auf ctool (einen open source C-Parser). Er bildet Kernels auf Cg-Shader ab. Diese werden später von herstellerspezifischen Compilern in Assemblercode übersetzt. Die Brook run-time library ruft über c++ die Kernels auf. Sie bildet die Schnittstelle zur GPU API. OpenGL- DirectX- und CPU-Implementierungen sind möglich. Der Programmierer hat also die Möglichkeit sich sein backend auszusuchen und kann somit die Ergebnisse besser verglichen. Zudem ist die Plattformenabhängigkeit gegeben. Im Folgenden werden die zuvor beschriebenen Features von Brook noch einmal unter dem Aspekt der Implementierung beleuchtet. 3.2 Streams Streams werden repräsentiert als Floating-Point-Textur. StreamRead und streamwrite, sowie Gather-Operationen werden als Texturzugriffe realisiert. Wiederholungs- und Sprung-Operationen werden mit texturesampling erreicht C++ stellt Streams als gewöhnliche Grafik-API-Texturen dar. Somit werden die Berechnungen für den Programmierer visualisiert. Die Texturen können dann von einer gewöhnlichen Grafik-Applikation gerendert werden. Dafür müssen aber Streams in einem festgelegten Texturlayout verfügbar sein. Als Default-Einstellung gilt: Texturdimension = Streamdimension. Dies kann jedoch zu Problemen führen. Eine Floating-Point-Textur ist begrenzt auf Zwei Dimensionen. Zusätzlich darf eine Textur nur 4096 (bei NVIDIA) bzw (bei ATI) Elemente pro Dimension enthalten. Wenn die Texturdimension gleich der Streamdimension ist treffen diese Beschränkungen auch auf die Streams zu. Hierfür gibt es eine Compileroption, welche die Streamdaten auf mehrere Reihen einer Textur verteilt. Eine beliebige Größe der Streams ist möglich, solange alle Elemente in eine Textur passen. Bei Zugriff auf ein Element im Stream erfolgt eine Konvertierung von der Streamposition zur entsprechenden Texturposition. Dabei wird der Position eines Streamelementes ein Integerindex zugewiesen. Die Größe des Integerindex ist jedoch wiederum abhängig von der Größe des Floating-Point-Formats. Bei ATI ist nur ein Integerindex von maximal möglich. Somit wurde die eindimensionale

11 Streamgröße nur von 2048 auf vergrößert. Ein allgemeineres Adressierungs-Model für den Speicher auf der Grafikkarte ist also wünschenswert. 3.3 Kernels Der Fragmentprozessor wird zum Ausführen von Kernel-Funktionen genutzt. Dabei wird der Body von dem Kernel in einen Cg-Shader umgewandelt. Danach werden diese Shader von NVIDIA / Microsoft Compilern in GPU Assemblercode übersetzt. Die Shader-Outputs sind bei der Hardware jedoch begrenzt. Ein Problem entseht hierbei wenn der Kernel mehr Outputs verwendet, als hardwareseitig unterstützt werden. Dies trifft auch bei der Verwendung von Strukturen zu, welche dann die Outputs der enthaltenen Streams hat. Wenn dies eintritt wird der Kernel auf mehrere Durchläufe verteilt. Jeder Durchlauf erzeugt eine Kopie des Kernels. Mat4Mult ist ein Programm, welches eine Multiplikation von zwei Matrizen der Form 4 zu 4 ausführt. Das Ergebnis beinhaltet 4 Outputs. Das Programm wurde einmal auf einer Hardware ausgeführt, welche die 4 Outputs unterstützt (Mat4Mult4) und einmal auf eine Hardware mit nur einem Output (Malt4Mult1). Man sieht, dass die Anzahl an Operationen bei beiden gleich ist. Die Begründung dafür ist, dass unabhängig jede Reihe der Output-Matrix berechnet werden kann. Somit müssen bei Math4Mult 1 keine Operationen wiederholt werden und jede Kernel kann unabhängig von den Berechnungen der anderen die Funktion ausführen. Die Texturzugriffe sind jedoch bei Mat4Mult1 höher da pro Durchlauf alle 16 Elemente aus dem Speicher geholt werden müssen. Die Anwendung Cloth stellt eine Animation eines bewegten Tuches dar. Hierbei treten Abhängigkeiten in Geschwindigkeit und Position auf. Wiederholte Berechnungen müssen somit bei Cloth1 getätigt werden und es erhöhen sich hier auch die arithmetischen Operationen. Also sind Berechnungen die nicht voneinander abhängen und multiplere Output- Unterstützung besser geeignet. DirectX rendert direkt Texturen welche Streamdaten enthalten. Bei OpenGL ist dies jedoch nicht so einfach möglich. Das Rendern der Texturen ist nur über den OpenGL Pbuffer realisierbar. Dieser Weg bringt jedoch Performanceverluste mit sich. Neue Spezifikationen seitens OpenGL sollen folgen und dieses Problem mildern

12 3.4 Reductions An sich werden Reductions von der Hardware nicht unterstützt. Diese werden über eine Multipass-Methode realisiert. Das heißt die Reductions werden in mehren Durchläufen ausgeführt. Hierbei werden bei jedem Durchlauf max 8 benachbarte Elemente gelesen und reduziert. Im Folgenden ist ein Benchmark für die arithmetische Summe, realisiert über eine Reduction von 2^20 Float4-Elementen, zusehen: 2.4 bzw Millisek. mit NVIDIA bzw. ATI DirectX 4.1 bzw. 1.3 Millisek. mit NVIDIA bzw. ATI OpenGL 14.6 Millisek. Mit optimierter CPU-Implementierung Dabei ist anzumerken, dass die GPU öfters auf den Speicher zugreifen muss als die CPU. Theoretisch ist mit einem Register, welches Zwischenergebnisse speichert, nur ein Durchlauf möglich. Dabei würden theoretisch folgende Werte zustande kommen: 0.41 bzw Millisek. mit NVIDIA bzw. ATI DirectX

13 4 Evaluation 4.1 Testumgebung Im Folgenden werden Testergebnisse von BrookGPU aufgezeigt. Dabei erfolgt der Vergleich von OpenGL und DirectX. Außerdem existiert eine Referenzversion, bei der die Codierung für die GPU von Hand erfolgte. Getestet werden Grafikkarten von ATI und Nvidia. Zudem gibt es eine CPU-Implementierung. Hierbei wurde der Code für die CPU optimiert. Bei der Evaluation wurde eine ATI RadeonX800 XT Platinum mit der Treiberversion 4.4. und eine NVIDIA GeForce6800 mit der Treiberversion verwendet. Das Betriebssystem ist Windows XP und für die CPU-Implementierung findet ein 3 GHz Intel Pentium 4 Prozessor Verwendung. 4.2 Testprogramme Die Evaluation erfolgt mit mehreren Programmen. BLAS SAXPY / SGEM enthalten Subroutinen für lineare Algebra. SAXPY führt die Berechnung y = ax + y durch. Dabei sind y und x Vektoren und a ist ein Skalar. Mit SGEM wird ein Matrix-Vektor- Produkt gebildet und diese anschließend mit einem skalierten Vektor addiert. Die Berechnung sieht wie folgt aus: y = atx + by. Hierbei sind y und x Vektoren, T ist eine Matrix und a und b sind Skalare. Segment führt eine 2D-Segementierung, wie sie z.b. in der Medizin verwendet wird, durch. Hierbei findet der Region-growing Algorithmus Verwendung. Auch eine zweidimensionale FFT und ein GPU Ray-Tracer, der komplett auf der GPU realisiert wurde, werden getestet. Segment FFT GPU Ray-Tracer

14 4.3 Ergebnisse Bei diesem Diagramm wurde die CPU-Leistung relativ zu den restlichen Ergebnissen gesetzt. Durch die schwarze, gestrichelte Linie ist die Leistung der CPU- Implementierung gekennzeichnet. Anhand von SAXPY ist zu erkennen, dass eine einzelne Multiplikation und Addition ausreicht um die CPU bei weitem zu übertreffen. SGEMV wurde mit einer Multipass-Reduction realisiert. Daher geht der Geschwindigkeitsvorteil der GPU ein wenig zurück. OpenGL verliert hier wegen dem Pbuffer-Problem. Bei der FFT sieht man, dass BrookGPU sehr weit zur CPU-Implementierung herunterfällt - teilweise mit Nvidia sogar darunter. Für die CPU-Implementierung wurde hierbei der Speicherzugriff blockiert. Der Prozessor ist somit darauf angewiesen den Cache zu nutzen. Dies Bringt einen entschiedenen Vorteil mit sich. Bei der FFT und bei SGEMV ist sogar ein Geschwindigkeitsvorsprung von Brook gegenüber der Referenzversion zu vermerken. Im Allgemeinen kann man sagen das ATI schneller als NVIDIA aufgrund der Floating-Point-Texturbandbreite arbeitet

15 Wenn man die Ergebnisse von FFT und von SAXPY vergleicht, kann man erkennen wann die GPU ihre Leistung am meisten ausschöpfen kann: Werden Daten nicht häufig wieder verwendet so ist die GPU der CPU deutlich überlegen. Bei hoher Wiederverwendung der Daten, wie es bei der FFT der Fall ist, verliert die GPU deutlich. Dies ist auf die vorher beschriebenen Probleme (z.b. die Begrenzung der Hardware-Outputs) zu begründen. 4.4 Schlussfolgerungen StreamRead und streamwrite wurden bei der Evaluation vernachlässigt. Diese Operationen sind für die GPU notwendig um Daten vor und nach einer Kernel- Sequenz aus dem bzw. in den Speicher zu transferieren. Sie entfallen aber bei der CPU. Unter diesem Aspekt definiert sich der Geschwindigkeitsunterschied zwischen GPU und CPU neu. Um dies genauer darzustellen kann man folgende Formeln betrachten: Tgpu= n *(Tr+ Kgpu) Tcpu= n * Kcpu Dabei beschreibt Tgpu die gesamte Zeit um eine Sequenz von Berechnungen mit der GPU auszuführen. Tcpu hingegen die Zeit, die die CPU dafür braucht. n gibt die Anzahl der auszuführende Befehl an. Und mit Kgpu bzw. Kcpu wird die Zeit der Ausführung des Kernels angegeben. Zudem kommt nun bei der GPU noch Tr, die Transferzeit für streamread und streamwrite hinzu. Bringt man nun die Bedingung Tgpu > Tcpu mit ein und stellt beide Gleichungen nach Tr um, erhält man folgende Formel: (Kcpu Kgpu)> Tr Resultierend daraus kann man sagen, dass der Geschwindigkeitsunterschied zwischen GPU und CPU mindestens die Transferzeit decken muss, damit die GPU wirklich schneller als die CPU ist

16 Dieses Diagramm gibt an wie sich die Gesamtkosten für einen Kernelaufruf in Abhängigkeit zu den Operationen pro Kernel verhalten. Jeder Kernelaufruf verursacht auch konstante Kosten für die CPU. Die CPU muss den Kernelaufruf konfigurieren und einrichten. Bei dem Diagramm ist zu erkennen, dass die Gesamtkosten am Anfang ungefähr konstant bleiben. Daraus ist zu erkennen, dass die CPU-Kosten die Gesamtkosten bei Verwendung weniger Operationen dominieren. Die CPU könnte den Kernel gar nicht voll auslasten. Bei wenigen Operationen braucht der Kernel an sich viel weniger Zeit. Dies muss man bei der Wahl der Streamgröße bedenken. Die Streamgröße für einen Kernel muss also mindestens die CPU-Kosten decken

17 5 Ausblick Probleme bereiten unter anderem streamread und streamwrite in punkto Gesamtperformance. Als Lösung werden neue GPUs vorgeschlagen, bei denen StreamRead und StreamWrite asynchron zu Berechnungszeit ablaufen. Somit ergäbe sich: Kgpu = Max (Kgpu, Tr) Die Kernelkosten wären so nur noch das Maximum von Transferzeit und Kernelkosten der GPU. Eine andere Alternative stellt ein gemeinsamer Speicher für CPU und GPU dar. Auch die Kernel-Outputs, im Bezug zu den Hardware-Outputs, und die begrenzte Streamgröße stellen Probleme dar. Hierfür wird an einem Algorithmus gearbeitet, der die Kernelberechungen aufteilt um die gewünschten Outputs zu erzielen. Zusammenfassend kann man sagen das BrookGPU ein einfaches und effektives Tool für die GPU-Programmierung ist. Es ist Open-source und vereinfacht somit die Nutzung. Zukünftig soll die GPU nicht nur eine Renderingeinheit, sondern eine zusätzliche Berechnungseinheit für den Computer darstellen

18 Quellen Brook for GPUs: Stream Computing on Graphics Hardware Ian Buck, Tim Foley, Daniel Horn, Jeremy Sugerman, Kayvon Fatahalian, Mike Houston, and Pat Hanrahan To appear at SIGGRAPH Merrimac: Supercomputing with Streams William J. Dally, Patrick Hanrahan, Mattan Erez, Timothy J. Knight, François Labonté, Jung-Ho Ahn, Nuwan Jayasena, Ujval J. Kapasi, Abhishek Das, Jayanth Gummaraju, and Ian Buck in the Proceedings of the SC'03 Conference, November 2003, Phoenix, Arizona. Using Modern Graphics Architectures for General-Purpose Computing: A Framework and Analysis Chris J. Thompson, Sangyun Hahn, and Mark Oskin International Symposium on Microarchitecture (MICRO), Turkey, Nov Advanced Computer Organization - Stream Processor Architecture Vector Architectures Prof. Bill Dally, James Bonanno, Mattan Erez Eine Einführung in Cg (C for graphics) Andreas Holzer