Allzweck-Computing auf Grafikprozessoren - General-purpose computing on graphics processing units

Universal-Computing auf Grafikprozessoren ( GPGPU , oder seltener GPGP ) ist die Verwendung einer Grafikverarbeitungseinheit (GPU), die normalerweise nur Berechnungen für Computergrafiken durchführt , um Berechnungen in Anwendungen durchzuführen, die traditionell von der zentralen Verarbeitungseinheit ( ZENTRALPROZESSOR). Die Verwendung mehrerer Videokarten in einem Computer oder einer großen Anzahl von Grafikchips parallelisiert die bereits parallele Natur der Grafikverarbeitung weiter.

Im Wesentlichen ist eine GPGPU- Pipeline eine Art paralleler Verarbeitung zwischen einer oder mehreren GPUs und CPUs, die Daten analysiert, als ob sie in Bild- oder anderer Grafikform wären. GPUs arbeiten zwar mit niedrigeren Frequenzen, verfügen jedoch in der Regel über ein Vielfaches der Anzahl von Kernen . Somit können GPUs weit mehr Bilder und Grafikdaten pro Sekunde verarbeiten als eine herkömmliche CPU. Das Migrieren von Daten in grafische Form und die anschließende Verwendung der GPU zum Scannen und Analysieren kann zu einer erheblichen Beschleunigung führen .

GPGPU-Pipelines wurden Anfang des 21. Jahrhunderts für die Grafikverarbeitung (zB für bessere Shader ) entwickelt. Es wurde festgestellt, dass diese Pipelines gut zu den Anforderungen der wissenschaftlichen Informatik passen , und wurden seitdem in diese Richtung entwickelt.

Geschichte

Im Prinzip kann jede beliebige boolesche Funktion , einschließlich der Addition, Multiplikation und anderer mathematischer Funktionen, aus einem funktionell vollständigen Satz logischer Operatoren aufgebaut werden. 1987 wurde Conways Game of Life zu einem der ersten Beispiele für Allzweck-Computing, das einen frühen Stream-Prozessor namens Blitter verwendet , um eine spezielle Sequenz logischer Operationen an Bitvektoren aufzurufen .

Allzweck-Computing auf GPUs wurde nach etwa 2001 praktischer und beliebter, als sowohl programmierbare Shader als auch Gleitkomma- Unterstützung auf Grafikprozessoren aufkamen. Insbesondere Probleme mit Matrizen und/oder Vektoren  – insbesondere zwei-, drei- oder vierdimensionale Vektoren – ließen sich leicht auf eine GPU übertragen, die mit nativer Geschwindigkeit und Unterstützung für diese Typen arbeitet. Die Experimente der wissenschaftlichen Computergemeinschaft mit der neuen Hardware begannen mit einer Matrixmultiplikationsroutine (2001); Eines der ersten gängigen wissenschaftlichen Programme, das auf GPUs schneller lief als auf CPUs, war eine Implementierung der LU-Faktorisierung (2005).

Diese frühen Bemühungen, GPUs als Allzweckprozessoren zu verwenden, erforderten eine Neuformulierung von Rechenproblemen in Bezug auf Grafikprimitive, wie sie von den beiden wichtigsten APIs für Grafikprozessoren, OpenGL und DirectX, unterstützt werden . Diese umständliche Übersetzung wurde durch das Aufkommen von universellen Programmiersprachen und APIs wie Sh / RapidMind , Brook und Accelerator umgangen .

Es folgte Nvidias CUDA , das es Programmierern ermöglichte, die zugrunde liegenden grafischen Konzepte zugunsten gängigerer Hochleistungs-Computing- Konzepte zu ignorieren . Neuere, hardwareherstellerunabhängige Angebote umfassen Microsoft DirectCompute und OpenCL von Apple/Khronos Group . Das bedeutet, dass moderne GPGPU-Pipelines die Geschwindigkeit einer GPU nutzen können, ohne dass eine vollständige und explizite Konvertierung der Daten in eine grafische Form erforderlich ist.

Implementierungen

Jede Sprache, die es dem auf der CPU ausgeführten Code ermöglicht, einen GPU- Shader nach Rückgabewerten abzufragen, kann ein GPGPU-Framework erstellen.

Seit 2016 ist OpenCL die dominante offene Allzweck-GPU-Computing-Sprache und ein offener Standard, der von der Khronos Group definiert wurde . OpenCL bietet eine plattformübergreifende GPGPU-Plattform, die zusätzlich datenparalleles Computing auf CPUs unterstützt. OpenCL wird auf Intel-, AMD-, Nvidia- und ARM-Plattformen aktiv unterstützt. Die Khronos-Gruppe hat auch SYCL , ein übergeordnetes Programmiermodell für OpenCL, als domänenspezifische eingebettete Single-Source-Sprache auf Basis von reinem C++11 standardisiert und implementiert .

Das dominierende proprietäre Framework ist Nvidia CUDA . Nvidia hat CUDA im Jahr 2006 auf den Markt gebracht , ein Software Development Kit (SDK) und eine Anwendungsprogrammierschnittstelle (API), die es ermöglicht, die Programmiersprache C zu verwenden, um Algorithmen für die Ausführung auf GeForce 8-Serie und späteren GPUs zu codieren .

Zu den Programmierstandards für Parallel Computing gehören OpenCL (herstellerunabhängig), OpenACC und OpenHMPP . Mark Harris , der Gründer von GPGPU.org, hat den Begriff GPGPU geprägt .

Die Das vonXceleriterstellte Xcelerit SDK wurdeentwickelt, um große vorhandeneC++-oderC#-CodebasenaufGPUsmit minimalem Aufwandzu beschleunigen. Es bietet ein vereinfachtes Programmiermodell, automatisiert die Parallelisierung, verwaltet Geräte und Speicher und kompiliert zuCUDA-Binärdateien. Darüber hinaus können Multi-Core-CPUsund andere Beschleuniger aus demselben Quellcode angesteuert werden.

OpenVIDIA wurde zwischen 2003 und 2005 an der University of Toronto in Zusammenarbeit mit Nvidia entwickelt .

Der vonAltimesherstellte Altimesh Hybridizer kompiliertCommon Intermediate LanguageinCUDA-Binärdateien. Es unterstützt Generika und virtuelle Funktionen. Debugging und Profilerstellung sind inVisual StudioundNsight integriert. Es ist als Visual Studio-Erweiterung imVisual Studio Marketplaceverfügbar.

Microsoft hat die DirectCompute- GPU-Computing-API eingeführt, die mit der DirectX 11-API veröffentlicht wurde.

Die von QuantAlea erstellte Alea GPU führt native GPU-Computing-Funktionen für dieMicrosoft.NET-SprachenF#undC# ein. Alea GPU bietet auch ein vereinfachtes GPU-Programmiermodell basierend auf GPU-Parallel-for- und Parallel-Aggregation mit Delegaten und automatischer Speicherverwaltung.

MATLAB unterstützt die GPGPU-Beschleunigung mit der Parallel Computing Toolbox und dem MATLAB Distributed Computing Server sowie Drittanbieterpaketen wie Jacket .

Die GPGPU-Verarbeitung wird auch verwendet, um die Newtonsche Physik durch Physik-Engines zu simulieren , und kommerzielle Implementierungen umfassen Havok Physics, FX und PhysX , die beide typischerweise für Computer- und Videospiele verwendet werden .

Near to Metal , jetzt Stream genannt , ist AMDs GPGPU-Technologie für ATI Radeon-basierte GPUs.

C++ Accelerated Massive Parallelism ( C++ AMP ) ist eine Bibliothek, die die Ausführung von C++- Code beschleunigt, indem sie die datenparallele Hardware auf GPUs ausnutzt.

Mobile Computer

Aufgrund des Trends der zunehmenden Leistung mobiler GPUs wurde Allzweckprogrammierung auch auf mobilen Geräten verfügbar, auf denen die wichtigsten mobilen Betriebssysteme ausgeführt wurden .

Google Android 4.2 aktiviert die Ausführung von RenderScript- Code auf der GPU des Mobilgeräts. Apple hat die proprietäre Metal API für iOS- Anwendungen eingeführt, die in der Lage ist, beliebigen Code über die GPU-Computing-Shader von Apple auszuführen.

Hardware-Unterstützung

Computer -Grafikkarten werden von verschiedenen Anbietern wie Nvidia , AMD und ATI hergestellt . Karten dieser Anbieter unterscheiden sich in der Implementierung der Unterstützung von Datenformaten wie Integer- und Gleitkommaformaten (32-Bit und 64-Bit). Microsoft hat einen Shader-Modell- Standard eingeführt, um die verschiedenen Funktionen von Grafikkarten in eine einfache Shader-Modell-Versionsnummer (1.0, 2.0, 3.0 usw.) einzuordnen.

Ganzzahlige Zahlen

Pre-DirectX 9-Grafikkarten unterstützten nur Paletten- oder Integer-Farbtypen. Es stehen verschiedene Formate zur Verfügung, die jeweils ein rotes Element, ein grünes Element und ein blaues Element enthalten. Manchmal wird ein weiterer Alpha-Wert hinzugefügt, der für Transparenz verwendet wird. Gängige Formate sind:

  • 8 Bits pro Pixel – Manchmal Palettenmodus, in dem jeder Wert ein Index in einer Tabelle mit dem echten Farbwert ist, der in einem der anderen Formate angegeben ist. Manchmal drei Bits für Rot, drei Bits für Grün und zwei Bits für Blau.
  • 16 Bits pro Pixel – Normalerweise werden die Bits als fünf Bits für Rot, sechs Bits für Grün und fünf Bits für Blau zugewiesen.
  • 24 Bits pro Pixel – Es gibt jeweils acht Bits für Rot, Grün und Blau.
  • 32 Bits pro Pixel – Es gibt acht Bits für Rot, Grün, Blau und Alpha .

Gleitkommazahlen

Für frühe Grafiken mit fester Funktion oder eingeschränkter Programmierbarkeit (dh bis einschließlich DirectX 8.1-kompatible GPUs) war dies ausreichend, da dies auch die Darstellung ist, die in Displays verwendet wird. Es ist wichtig zu beachten, dass diese Darstellung gewissen Einschränkungen unterliegt. Bei ausreichender Grafikverarbeitungsleistung würden selbst Grafikprogrammierer gerne bessere Formate wie Fließkomma- Datenformate verwenden, um Effekte wie High-Dynamic-Range-Imaging zu erzielen . Viele GPGPU-Anwendungen erfordern eine Gleitkommagenauigkeit, die mit Grafikkarten geliefert wurde, die der DirectX 9-Spezifikation entsprechen.

DirectX 9 Shader Model 2.x schlug die Unterstützung von zwei Präzisionstypen vor: volle und partielle Präzision. Volle Präzisionsunterstützung könnte entweder FP32 oder FP24 (Gleitkomma 32- oder 24-Bit pro Komponente) oder höher sein, während die partielle Präzision FP16 war. ATI Radeon R300 Serie von GPUs unterstützt FP24 Präzision nur in der programmierbaren Fragmente Pipeline (obwohl FP32 in den Vertex - Prozessoren unterstützt wurde) , während Nvidia ‚s NV30 Serie sowohl FP16 und FP32 unterstützt; andere Anbieter wie S3 Graphics und XGI unterstützten eine Mischung von Formaten bis zu FP24.

Die Implementierungen von Gleitkomma auf Nvidia-GPUs sind größtenteils IEEE- kompatibel; Dies gilt jedoch nicht für alle Anbieter. Dies hat Auswirkungen auf die Korrektheit, die für einige wissenschaftliche Anwendungen als wichtig erachtet werden. Während 64-Bit-Gleitkommawerte (Double Precision Float) auf CPUs allgemein verfügbar sind, werden diese auf GPUs nicht universell unterstützt. Einige GPU-Architekturen opfern die IEEE-Konformität, während anderen die doppelte Genauigkeit fehlt. Es wurden Anstrengungen unternommen, Gleitkommawerte mit doppelter Genauigkeit auf GPUs zu emulieren; Der Geschwindigkeitskompromiß macht jedoch alle Vorteile zunichte, die das Computing von vornherein auf die GPU auslagern.

Vektorisierung

Die meisten Operationen auf der GPU arbeiten vektorisiert: Eine Operation kann mit bis zu vier Werten gleichzeitig ausgeführt werden. Wenn beispielsweise eine Farbe <R1, G1, B1> durch eine andere Farbe <R2, G2, B2> moduliert werden soll, kann die GPU die resultierende Farbe <R1*R2, G1*G2, B1*B2> in einem erzeugen Betrieb. Diese Funktionalität ist in Grafiken nützlich, da fast jeder grundlegende Datentyp ein Vektor ist (entweder 2-, 3- oder 4-dimensional). Beispiele sind Scheitelpunkte, Farben, Normalenvektoren und Texturkoordinaten. Viele andere Anwendungen können dies gut nutzen, und wegen ihrer höheren Leistung sind Vektorbefehle, die als Single Instruction, Multiple Data ( SIMD ) bezeichnet werden, seit langem auf CPUs verfügbar.

GPU vs. CPU

Ursprünglich wurden Daten einfach von einer zentralen Verarbeitungseinheit (CPU) zu einer Grafikverarbeitungseinheit (GPU) und dann zu einem Anzeigegerät weitergeleitet . Im Laufe der Zeit wurde es jedoch für GPUs wertvoll, zuerst einfache, dann komplexe Datenstrukturen zu speichern, die an die CPU, die ein Bild analysierte, oder einen Satz wissenschaftlicher Daten, die als 2D- oder 3D-Format dargestellt wurden, zurückgesendet wurden Grafikkarte verstehen kann. Da die GPU Zugriff auf jeden Draw-Vorgang hat, kann sie Daten in diesen Formen schnell analysieren, während eine CPU jedes Pixel oder Datenelement viel langsamer abfragen muss, da die Zugriffsgeschwindigkeit zwischen einer CPU und ihrem größeren Pool an Direktzugriffsspeichern (oder im schlimmsten Fall eine Festplatte ) ist langsamer als GPUs und Grafikkarten, die normalerweise kleinere Mengen teureren Speichers enthalten, auf den viel schneller zugegriffen werden kann. Die Übertragung des aktiv zu analysierenden Teils des Datensatzes in Form von Texturen oder anderen leicht lesbaren GPU-Formen an diesen GPU-Speicher führt zu einer Geschwindigkeitssteigerung. Das Unterscheidungsmerkmal eines GPGPU-Designs ist die Fähigkeit, Informationen bidirektional von der GPU zur CPU zurück zu übertragen; Im Allgemeinen ist der Datendurchsatz in beide Richtungen idealerweise hoch, was zu einem Multiplikatoreffekt auf die Geschwindigkeit eines bestimmten häufig genutzten Algorithmus führt . GPGPU-Pipelines können die Effizienz bei besonders großen Datensätzen und/oder Daten mit 2D- oder 3D-Bildern verbessern. Es wird in komplexen Grafik-Pipelines sowie im wissenschaftlichen Computing verwendet ; mehr noch in Bereichen mit großen Datensätzen wie Genomkartierung oder wo zwei- oder dreidimensionale Analysen nützlich sind – insbesondere derzeit Biomolekülanalysen , Proteinstudien und andere komplexe organische Chemie . Solche Pipelines können unter anderem auch die Effizienz in der Bildverarbeitung und Computer Vision erheblich verbessern ; sowie Parallelverarbeitung im Allgemeinen. Einige sehr stark optimierte Pipelines haben Geschwindigkeitssteigerungen um das Hundertfache der ursprünglichen CPU-basierten Pipeline bei einer häufig genutzten Aufgabe erbracht.

Ein einfaches Beispiel wäre ein GPU-Programm, das Daten über durchschnittliche Beleuchtungswerte sammelt , während es einige Ansichten von einer Kamera oder einem Computergrafikprogramm zurück zum Hauptprogramm auf der CPU rendert, damit die CPU dann Anpassungen am Gesamtbildschirm vornehmen kann Aussicht. Ein fortgeschritteneres Beispiel könnte die Kantenerkennung verwenden , um sowohl numerische Informationen als auch ein verarbeitetes Bild, das Umrisse darstellt, an ein Computer-Vision- Programm zurückzugeben, das beispielsweise einen mobilen Roboter steuert. Da die GPU schnellen und lokalen Hardwarezugriff auf jedes Pixel oder jedes andere Bildelement in einem Bild hat, kann sie es analysieren und mitteln (für das erste Beispiel) oder einen Sobel-Kantenfilter oder einen anderen Faltungsfilter (für das zweite) mit viel größerer Größe anwenden Geschwindigkeit als eine CPU, die normalerweise auf langsamere RAM- Kopien der fraglichen Grafik zugreifen muss .

GPGPU ist im Grunde ein Softwarekonzept, kein Hardwarekonzept; es ist eine Art Algorithmus , kein Gerät. Spezialisierte Gerätedesigns können jedoch die Effizienz von GPGPU-Pipelines, die traditionell relativ wenige Algorithmen für sehr große Datenmengen ausführen, noch weiter verbessern. Massiv parallelisierte, gigantische Aufgaben auf Datenebene können daher über spezielle Setups wie Rack Computing (viele ähnliche, hochgradig maßgeschneiderte Maschinen in einem Rack eingebaut ) noch weiter parallelisiert werden , was eine dritte Schicht hinzufügt – viele Recheneinheiten, die jeweils viele CPUs verwenden, um zu entsprechen zu vielen GPUs. Einige Bitcoin- „Miner“ verwendeten solche Setups für die Verarbeitung hoher Mengen.

Caches

In der Vergangenheit haben CPUs hardwareverwaltete Caches verwendet , aber die früheren GPUs boten nur softwareverwaltete lokale Speicher. Da GPUs jedoch zunehmend für allgemeine Anwendungen verwendet werden, werden moderne GPUs mit hardwareverwalteten mehrstufigen Caches entwickelt, die den GPUs geholfen haben, sich in Richtung Mainstream-Computing zu bewegen. Zum Beispiel GeForce 200 Serie GT200 - Architektur GPUs nicht einen L2 - Cache verfügte, der Fermi - GPU 768 KiB Last-Level - Cache hat, die Kepler GPU hat 1,5 MiB Last-Level - Cache, die Maxwell hat GPU 2 MiB Last-Level - Cache, und die Pascal- GPU verfügt über 4 MiB Last-Level-Cache.

Datei registrieren

GPUs haben sehr große Registerdateien , die es ihnen ermöglichen, die Latenz beim Kontextwechsel zu reduzieren. Die Registerdateigröße nimmt auch über verschiedene GPU-Generationen zu, zB beträgt die Gesamtregisterdateigröße auf Maxwell (GM200), Pascal und Volta GPUs 6 MiB, 14 MiB bzw. 20 MiB. Im Vergleich dazu ist die Größe einer Registerdatei auf CPUs klein, typischerweise zehn oder hundert Kilobyte.

Energieeffizienz

Die hohe Leistung der GPUs geht auf Kosten eines hohen Stromverbrauchs, der unter Volllast tatsächlich so viel Leistung wie der Rest des PC-Systems zusammen bringt. Die maximale Leistungsaufnahme der GPU der Pascal-Serie (Tesla P100) wurde mit 250W angegeben.

Stream-Verarbeitung

GPUs sind speziell für Grafik ausgelegt und daher sehr restriktiv in Bedienung und Programmierung. GPUs sind konstruktionsbedingt nur bei Problemen wirksam, die sich per Stream-Processing lösen lassen und die Hardware ist nur bedingt nutzbar.

Die folgende Diskussion, die sich auf Vertices, Fragmente und Texturen bezieht, betrifft hauptsächlich das Legacy-Modell der GPGPU-Programmierung, bei der Grafik-APIs ( OpenGL oder DirectX ) verwendet wurden, um allgemeine Berechnungen durchzuführen. Mit der Einführung der Allzweck-Computing-APIs CUDA (Nvidia, 2007) und OpenCL (Vendor-Independent, 2008) ist es in neuen GPGPU-Codes nicht mehr erforderlich, die Berechnung auf Grafikprimitiven abzubilden. Die Stream-Verarbeitung von GPUs bleibt unabhängig von den verwendeten APIs gültig. (Siehe zB,)

GPUs können nur unabhängige Vertices und Fragmente verarbeiten, können aber viele davon parallel verarbeiten. Dies ist besonders effektiv, wenn der Programmierer viele Scheitelpunkte oder Fragmente auf die gleiche Weise verarbeiten möchte. In diesem Sinne sind GPUs Stream-Prozessoren – Prozessoren, die parallel arbeiten können, indem ein Kernel auf vielen Datensätzen in einem Stream gleichzeitig ausgeführt wird.

Ein Stream ist einfach ein Satz von Datensätzen, die eine ähnliche Berechnung erfordern. Streams bieten Datenparallelität. Kernel sind die Funktionen, die auf jedes Element im Stream angewendet werden. In den GPUs sind Vertices und Fragments die Elemente in Streams und Vertex- und Fragment-Shader sind die Kernel, die darauf ausgeführt werden. Für jedes Element können wir nur von der Eingabe lesen, Operationen darauf ausführen und in die Ausgabe schreiben. Es sind mehrere Eingänge und mehrere Ausgänge zulässig, aber niemals ein Stück Speicher, das sowohl lesbar als auch beschreibbar ist.

Die arithmetische Intensität ist definiert als die Anzahl der Operationen, die pro übertragenem Speicherwort ausgeführt werden. Für GPGPU-Anwendungen ist es wichtig, eine hohe arithmetische Intensität zu haben, da sonst die Speicherzugriffslatenz die Rechengeschwindigkeit begrenzt.

Ideale GPGPU-Anwendungen haben große Datensätze, hohe Parallelität und minimale Abhängigkeit zwischen Datenelementen.

Konzepte zur GPU-Programmierung

Computerressourcen

Auf der GPU stehen verschiedene Rechenressourcen zur Verfügung:

  • Programmierbare Prozessoren – Vertex-, Primitiv-, Fragment- und hauptsächlich Compute-Pipelines ermöglichen es dem Programmierer, Kernel auf Datenströmen auszuführen
  • Rasterizer – erstellt Fragmente und interpoliert Konstanten pro Scheitelpunkt wie Texturkoordinaten und Farbe
  • Textureinheit – Nur-Lese-Speicherschnittstelle
  • Framebuffer – nur beschreibbare Speicherschnittstelle

Tatsächlich kann ein Programm anstelle des Framebuffers eine schreibgeschützte Textur für die Ausgabe ersetzen. Dies geschieht entweder über Render to Texture (RTT), Render-To-Backbuffer-Copy-To-Texture (RTBCTT) oder den neueren Stream-Out.

Texturen als Stream

Die gängigste Form für einen Stream in GPGPU ist ein 2D-Raster, da dies natürlich zum in GPUs integrierten Rendering-Modell passt. Viele Berechnungen werden auf natürliche Weise in Gitter abgebildet: Matrixalgebra, Bildverarbeitung, physikalisch basierte Simulation und so weiter.

Da Texturen als Speicher verwendet werden, werden Textur-Lookups dann als Speicherlesevorgänge verwendet. Aus diesem Grund können bestimmte Operationen automatisch von der GPU ausgeführt werden.

Kerne

Rechenkerne kann man sich als den Körper von Schleifen vorstellen . Beispielsweise könnte ein Programmierer, der auf einem Grid auf der CPU arbeitet, Code haben, der wie folgt aussieht:

// Input and output grids have 10000 x 10000 or 100 million elements.

void transform_10k_by_10k_grid(float in[10000][10000], float out[10000][10000])
{
    for (int x = 0; x < 10000; x++) {
        for (int y = 0; y < 10000; y++) {
            // The next line is executed 100 million times
            out[x][y] = do_some_hard_work(in[x][y]);
        }
    }
}

Auf der GPU gibt der Programmierer nur den Rumpf der Schleife als Kernel an und welche Daten durch Aufrufen der Geometrieverarbeitung durchlaufen werden sollen.

Ablaufsteuerung

Im sequentiellen Code ist es möglich, den Programmfluss durch if-then-else-Anweisungen und verschiedene Formen von Schleifen zu steuern. Solche Flusssteuerungsstrukturen wurden erst kürzlich zu GPUs hinzugefügt. Bedingte Schreibvorgänge konnten unter Verwendung einer richtig gestalteten Reihe von arithmetischen/Bit-Operationen durchgeführt werden, aber Schleifen und bedingte Verzweigungen waren nicht möglich.

Neuere GPUs ermöglichen Verzweigungen, aber normalerweise mit Leistungseinbußen. Verzweigungen sollten im Allgemeinen in inneren Schleifen vermieden werden, sei es in CPU- oder GPU-Code, und verschiedene Methoden, wie z existieren.

GPU-Methoden

Karte

Die Map-Operation wendet einfach die gegebene Funktion (den Kernel) auf jedes Element im Stream an. Ein einfaches Beispiel ist das Multiplizieren jedes Werts im Stream mit einer Konstanten (erhöht die Helligkeit eines Bildes). Die Kartenbedienung ist einfach auf der GPU zu implementieren. Der Programmierer erzeugt für jedes Pixel auf dem Bildschirm ein Fragment und wendet auf jedes ein Fragmentprogramm an. Der Ergebnisstrom der gleichen Größe wird im Ausgabepuffer gespeichert.

Reduzieren

Einige Berechnungen erfordern die Berechnung eines kleineren Streams (möglicherweise eines Streams mit nur einem Element) aus einem größeren Stream. Dies wird als Reduzierung des Stroms bezeichnet. Generell kann eine Reduktion in mehreren Schritten durchgeführt werden. Die Ergebnisse aus dem vorherigen Schritt werden als Eingabe für den aktuellen Schritt verwendet und der Bereich, über den die Operation angewendet wird, wird reduziert, bis nur noch ein Stream-Element übrig ist.

Stream-Filterung

Die Stromfilterung ist im Wesentlichen eine ungleichmäßige Reduktion. Beim Filtern werden Elemente basierend auf bestimmten Kriterien aus dem Stream entfernt.

Scan

Die Abtastoperation, auch als parallele Präfixsumme bezeichnet , nimmt einen Vektor (Strom) von Datenelementen und eine (beliebige) assoziative Binärfunktion '+' mit einem Identitätselement 'i' auf . Wenn die Eingabe [a0, a1, a2, a3, ...] ist, erzeugt ein exklusiver Scan die Ausgabe [i, a0, a0 + a1, a0 + a1 + a2, ...], während ein inklusiver Scan den Ausgang [a0, a0 + a1, a0 + a1 + a2, a0 + a1 + a2 + a3, ...] und erfordert keine Identität . Während die Operation auf den ersten Blick von Natur aus seriell erscheinen mag, sind effiziente parallele Scanalgorithmen möglich und wurden auf Grafikprozessoren implementiert. Die Scan-Operation hat Verwendungen zB bei Quicksort und Sparse-Matrix-Vektor-Multiplikation.

Streuen

Die Scatter- Operation wird am natürlichsten auf dem Vertex-Prozessor definiert. Der Vertex-Prozessor ist in der Lage, die Position des Vertex anzupassen , wodurch der Programmierer steuern kann, wo Informationen auf dem Raster abgelegt werden. Andere Erweiterungen sind ebenfalls möglich, z. B. Steuern, wie groß der Bereich des Scheitelpunkts ist.

Der Fragmentprozessor kann keine direkte Streuungsoperation ausführen, da die Position jedes Fragments auf dem Gitter zum Zeitpunkt der Erzeugung des Fragments festgelegt ist und vom Programmierer nicht geändert werden kann. Eine logische Streuungsoperation kann jedoch manchmal mit einem anderen Sammelschritt umgeformt oder implementiert werden. Eine Scatter-Implementierung würde zuerst sowohl einen Ausgabewert als auch eine Ausgabeadresse ausgeben. Eine unmittelbar folgende Sammeloperation verwendet Adressvergleiche, um zu sehen, ob der Ausgabewert dem aktuellen Ausgabeschlitz zugeordnet ist.

In dedizierten Rechenkernen kann Streuung durch indizierte Schreibvorgänge ausgeführt werden.

Versammeln

Sammeln ist das Gegenteil von Streuung. Nachdem Scatter Elemente gemäß einer Karte neu anordnet, kann Gather die Reihenfolge der Elemente gemäß der verwendeten Map-Streuung wiederherstellen. In dedizierten Rechenkernen kann das Sammeln durch indizierte Lesevorgänge durchgeführt werden. In anderen Shadern erfolgt dies mit Textur-Lookups.

Sortieren

Die Sortieroperation wandelt einen ungeordneten Satz von Elementen in einen geordneten Satz von Elementen um. Die häufigste Implementierung auf GPUs ist die Verwendung von Radix-Sort für Integer- und Gleitkommadaten und grobkörniger Merge-Sort- und feinkörniger Sortiernetzwerke für allgemein vergleichbare Daten.

Suche

Die Suchoperation ermöglicht es dem Programmierer, ein bestimmtes Element innerhalb des Streams zu finden oder möglicherweise Nachbarn eines bestimmten Elements zu finden. Die GPU wird nicht verwendet, um die Suche nach einem einzelnen Element zu beschleunigen, sondern wird verwendet, um mehrere Suchen parallel auszuführen. Die meist verwendete Suchmethode ist die binäre Suche nach sortierten Elementen.

Datenstrukturen

Auf der GPU können verschiedene Datenstrukturen dargestellt werden:

Anwendungen

Im Folgenden sind einige der Bereiche aufgeführt, in denen GPUs für Allzweck-Computing verwendet wurden:

Bioinformatik

GPGPU-Nutzung in der Bioinformatik:

Anwendung Beschreibung Unterstützte Funktionen Erwartete Beschleunigung† GPU‡ Multi-GPU-Unterstützung Freigabestatus
Barrakuda DNA, einschließlich Epigenetik, Sequenzkartierungssoftware Ausrichtung von kurzen Sequenzierungs-Reads 6–10x T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar , Version 0.7.107f
CUDASW++ Open-Source-Software für die Suche in Smith-Waterman-Proteindatenbanken auf GPUs Parallele Suche in der Smith-Waterman-Datenbank 10–50x T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar, Version 2.0.8
CUSHAW Parallelisierter Short-Read-Aligner Paralleler, genauer Long-Read-Aligner – lückenhafte Ausrichtungen zu großen Genomen 10x T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar, Version 1.0.40
GPU-BLAST Lokale Suche mit schneller k- Tupel-Heuristik Proteinausrichtung nach Blastp, Multi-CPU-Threads 3-4x T 2075, 2090, K10, K20, K20X Nur single Jetzt verfügbar, Version 2.2.26
GPU-HMMER Parallelisierte lokale und globale Suche mit versteckten Markov-Profilmodellen Parallele lokale und globale Suche nach Hidden-Markov-Modellen 60–100x T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar, Version 2.3.2
mCUDA-MEME Ultraschneller skalierbarer Motiverkennungsalgorithmus basierend auf MEME Skalierbarer Motiverkennungsalgorithmus basierend auf MEME 4–10x T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar, Version 3.0.12
SeqNFind Ein GPU-beschleunigtes Sequenzanalyse-Toolset Referenzmontage, Explosion, Smith-Waterman, hmm, De-novo-Montage 400x T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar
UGENE Opensource Smith–Waterman für SSE/CUDA, Suffix-Array-basierter Wiederholungsfinder und Dotplot Schnelle Ausrichtung bei kurzen Lesevorgängen 6–8x T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar, Version 1.11
WideLM Passt zu zahlreichen linearen Modellen zu einem festen Design und Ansprechverhalten Parallele lineare Regression auf mehreren ähnlich geformten Modellen 150x T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar, Version 0.1-1

Molekulardynamik

Anwendung Beschreibung Unterstützte Funktionen Erwartete Beschleunigung† GPU‡ Multi-GPU-Unterstützung Freigabestatus
Abalone Modelliert die Molekulardynamik von Biopolymeren für Simulationen von Proteinen, DNA und Liganden Explizites und implizites Lösungsmittel, hybrides Monte Carlo 4–120x T 2075, 2090, K10, K20, K20X Nur single Jetzt verfügbar, Version 1.8.88
ACEMD GPU-Simulation von Kraftfeldern der Molekularmechanik, implizites und explizites Lösungsmittel Geschrieben für die Verwendung auf GPUs Nur GPU-Version mit 160 ns/Tag T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar
BERNSTEIN Suite von Programmen zur Simulation der Molekulardynamik auf Biomolekülen PMEMD: explizites und implizites Lösungsmittel 89,44 ns/Tag JAC NVE T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar, Version 12 + Bugfix9
DL-POLY Simulieren Sie Makromoleküle, Polymere, ionische Systeme usw. auf einem Parallelcomputer mit verteiltem Speicher Zwei-Körper-Kräfte, Link-Zell-Paare, Ewald SPME-Kräfte, Shake VV 4x T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar, nur Version 4.0 Quelle
CHARMM MD-Paket zur Simulation der Molekulardynamik an Biomolekülen. Implizites (5x), explizites (2x) Lösungsmittel über OpenMM noch offen T 2075, 2090, K10, K20, K20X Jawohl In Entwicklung Q4/12
GROMACS Simulieren Sie biochemische Moleküle mit komplexen Bindungswechselwirkungen Implizit (5x), explizit (2x) Lösungsmittel 165 ns/Tag DHFR T 2075, 2090, K10, K20, K20X Nur single Jetzt verfügbar, Version 4.6 in Q4/12
HOOMD-Blau Particle Dynamics Package geschriebene Gründe für GPUs Geschrieben für GPUs 2x T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar
LAMPEN Klassisches Molekulardynamikpaket Lennard-Jones, Morse, Buckingham, CHARMM, tabellarisch, grobkörniges SDK, anisotropes Gay-Bern, RE-Quadrat, "Hybrid"-Kombinationen 3–18x T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar
NAMD Entwickelt für die Hochleistungssimulation großer molekularer Systeme 100M Atom fähig 6,44 ns/Tage STMV 585x 2050s T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar, Version 2.9
ÖffnenMM Bibliothek und Anwendung für Molekulardynamik für HPC mit GPUs Implizites und explizites Lösungsmittel, benutzerdefinierte Kräfte Implizit: 127–213 ns/Tag; Explizit: 18–55 ns/Tag DHFR T 2075, 2090, K10, K20, K20X Jawohl Jetzt verfügbar, Version 4.1.1

† Erwartete Beschleunigungen hängen stark von der Systemkonfiguration ab. GPU-Leistung im Vergleich zu Multi-Core- x86- CPU-Sockel. Die GPU-Leistung wird anhand von GPU-unterstützten Funktionen bewertet und kann ein Vergleich der Kernel- zu-Kernel-Leistung sein. Einzelheiten zur verwendeten Konfiguration finden Sie auf der Website der Anwendung. Beschleunigungen gemäß interner Nvidia-Tests oder ISV-Dokumentation.

‡ Q= Quadro-GPU , T= Tesla-GPU . Nvidia empfahl GPUs für diese Anwendung. Wenden Sie sich an den Entwickler oder ISV, um Informationen zur Zertifizierung zu erhalten.

Siehe auch

Verweise

Externe Links