OpenCL im Handel - Seite 3

Neuer Kommentar
 

AMD Developer Central: Webinar-Reihe zur OpenCL-Programmierung.2. Einführung in OpenCL



2- Einführung in OpenCL

Dieses Video bietet eine detaillierte Einführung in OpenCL, eine Plattform für paralleles Rechnen, die CPUs und GPUs verwenden kann, um Berechnungen zu beschleunigen. In OpenCL geschriebene Programme können auf verschiedenen Geräten und Architekturen ausgeführt werden, wodurch Code über verschiedene Plattformen hinweg portierbar ist. Das Video diskutiert die verschiedenen Ausführungsmodelle in OpenCL, einschließlich Datenparallelität und Aufgabenparallelität, und behandelt auch die verschiedenen Objekte und Befehle, die in OpenCL verwendet werden, wie z. B. Speicherobjekte, Befehlswarteschlangen und Kernelobjekte. Das Video befasst sich auch mit den Vorteilen und Einschränkungen der Verwendung von OpenCL, wie z. B. der Notwendigkeit einer expliziten Speicherverwaltung und dem Potenzial für erhebliche Leistungsverbesserungen in parallelen Programmen.

  • 00:00:00 In diesem Abschnitt stellt der Redner OpenCL und seine Fähigkeit vor, CPUs und GPUs zu verwenden, um parallele Berechnungen zu beschleunigen, was zu erheblichen Beschleunigungen führt. Obwohl manchmal Zahlen wie 100X oder 1000X zitiert werden, werden realistischerweise Beschleunigungen von etwa 10-20X für optimierte Programme erwartet. OpenCL kann portablen Code für verschiedene Geräte und Architekturen schreiben; Daher können Programme, die für AMD-GPUs geschrieben wurden, normalerweise auch auf NVIDIA-GPUs ausgeführt werden. Bei der AMD-Implementierung werden im Gegensatz zu einigen Implementierungen anderer Wettbewerber sowohl die CPU- als auch die GPU-Implementierung von OpenCL bereitgestellt. Der Abschnitt endet mit einem Überblick über heterogenes Computing und wie OpenCL darin Platz findet.

  • 00:05:00 In diesem Abschnitt bietet der Referent eine Einführung in OpenCL, eine Low-Level- und ausführliche Plattform, die in Bezug auf die Leistung lohnend sein kann, wenn die Anwendung die richtigen Eigenschaften hat. OpenCL ist ein plattformbasiertes Modell, das aus einer Host-API, einem Modell verbundener Geräte und einem Speichermodell besteht. Die Geräte werden als Sammlung von Recheneinheiten betrachtet, und jede Recheneinheit ist in Verarbeitungselemente unterteilt, die in SIMD ausgeführt werden. Das Ausführungsmodell basiert auf der Vorstellung eines Kernels, der die Einheit ausführbaren Codes ist, die parallel auf mehreren Daten ausgeführt werden kann. Darüber hinaus bietet OpenCL eine Reihe von Warteschlangen, die die asynchrone Ausführung von Lese- und Schreibvorgängen sowie die Ausführung des Kernels ermöglichen, die in der richtigen oder in der falschen Reihenfolge sein können.

  • 00:10:00 In diesem Abschnitt erörtert der Referent die beiden wichtigsten Ausführungsmodelle in OpenCL: Datenparallelität und Aufgabenparallelität. Das datenparallele Modell ist für die Ausführung auf GPUs am effizientesten und umfasst eine N-dimensionale Berechnungsdomäne, in der jedes einzelne Element als Arbeitselement bezeichnet wird, das potenziell parallel ausgeführt werden kann. Die Ausführung von Arbeitsaufgaben kann in lokale Dimensionen gruppiert werden, die als Arbeitsgruppen bezeichnet werden und auf einer der verfügbaren Recheneinheiten ausgeführt werden. Der Referent erklärt auch, wie die Schleife in der datenparallelen Welt von OpenCL impliziert ist und wie die Get-Global-Identifier-Routine verwendet wird, um in a und b zu indizieren.

  • 00:15:00 In diesem Abschnitt erläutert der Redner den lokalen Speicher, der einem Cache ähnelt und vom Benutzer verwaltet wird, da er eine geringe Latenz hat und schneller ist als der globale Speicher. Die Synchronisierungsfunktion ermöglicht es Arbeitsaufgaben, in einen Speicherplatz zu schreiben, auf den Abschluss zu warten und dann eine andere Arbeitsaufgabe diese Speicherstelle lesen zu lassen und den von der vorherigen Arbeitsaufgabe geschriebenen Wert zu erhalten. Die Synchronisierung kann nur innerhalb der Arbeitsgruppe erfolgen. OpenCL unterstützt auch Aufgabenparallelität, die von einem einzelnen Arbeitselement ausgeführt wird, und profitiert von der Verwendung des OpenCL-Warteschlangenmodells und der Synchronisierungsfunktionen der Host-API, die nativ kompilierten Code ermöglichen. OpenCL unterscheidet sich von C darin, dass die Speicherhierarchie bestimmter GPUs explizit offengelegt wird und der Programmierer durch die Verwendung von Barriereoperationen und Synchronisierung eine Ordnung und Konsistenz der Daten herbeiführen kann.

  • 00:20:00 In diesem Abschnitt geht der Referent auf die Vorteile von OpenCL ein, wie z. B. seine starke Leistungsfähigkeit. Sie weisen jedoch darauf hin, dass die Speicherverwaltung in OpenCL explizite Operationen erfordert, die kompliziert sein könnten und eine sorgfältige Prüfung des Algorithmus erfordern. Das Kompilierungsmodell basiert auf OpenGL und verfügt über ein Online-Kompilierungsmodell, das die Übergabe von Streams oder Zeichenfolgen des OpenCL-Quellcodes zur Online-Kompilierung ermöglicht. OpenCL ist um den Kontext herum aufgebaut, eine Sammlung von Geräten und Speicherobjekten, und Warteschlangen werden verwendet, um Arbeit an ein bestimmtes Gerät zu senden, das dem Kontext zugeordnet ist. Speicherobjekte sind Puffer, bei denen es sich um eindimensionale Speicherblöcke handelt, die man sich als Arrays vorstellen kann.

  • 00:25:00 In diesem Abschnitt erklärt der Referent die verschiedenen OpenCL-Objekte, darunter Speicherobjekte, Bilder, Programme und Kernel. Speicherobjekte können Puffer oder Bildtypen sein, wobei Bilder eine Hardwareimplementierung haben, um den Zugriff zu optimieren. Programme, die Kernel zur Ausführung definieren, können erstellt und extrahiert werden, und Kernargumentwerte können unter Verwendung von Kernelobjekten gesetzt werden. Befehlswarteschlangen werden verwendet, um Kernel und andere Befehle zur Ausführung einzureihen. Darüber hinaus sind OpenCL-Ereignisse nützlich, um Abhängigkeiten zwischen Befehlen aufzubauen und den Status von Befehlen abzufragen. Der Referent gibt auch Beispiele für die Abfrage von Geräten und deren IDs.

  • 00:30:00 In diesem Abschnitt erklärt der Referent, wie OpenCL Fehlercodes und Objekte zurückgibt. Wenn eine Funktion ein CL-Objekt zurückgibt, gibt sie dieses Objekt als Ergebnis zurück. Wenn es jedoch kein CL-Objekt zurückgibt, wird es den Fehlercode als Ergebnis zurückgeben. Der Kontext wird besprochen und wie Speicher auf Kontextebene zugewiesen wird, was bedeutet, dass Puffer und Bilder geräteübergreifend gemeinsam genutzt werden. Der Redner erwähnt auch die Funktion CL get X info, insbesondere CL get device info, die es Entwicklern ermöglicht, Gerätefunktionen abzufragen, um festzustellen, welches Gerät am besten für den Algorithmus geeignet ist. Abschließend diskutiert der Redner Puffer und Bilder und wie Kernel auf sie zugreifen können, zusammen mit den Einschränkungen für den Bildzugriff.

  • 00:35:00 In diesem Abschnitt erläutert der Redner, wie Puffer und Bilder in OpenCL zugewiesen werden, einschließlich der Beschreibung, wie auf die Puffer zugegriffen wird, und die Vorteile der Verwendung von Bildern. Der Referent erklärt auch, wie man mit expliziten Befehlen auf Speicherobjektdaten zugreift und wie man Befehle in eine Warteschlange einreiht. Darüber hinaus erklärt das Video, wie eine Region abgebildet und Daten zwischen Puffern übertragen werden, sowie die Vor- und Nachteile der Verwendung von DMA-Einheiten. Der Abschnitt schließt mit der Diskussion von Programm- und Kernel-Objekten und dem Festlegen von Argumentwerten.

  • 00:40:00 In diesem Abschnitt geht der Referent auf Dispatch und Abhängigkeiten in OpenCL ein. Sie erklären, wie der Versand basierend auf der Domäne oder dem Ausführungsraster ausgeführt wird und wie Abhängigkeiten eingerichtet werden können, um sicherzustellen, dass sich die Dinge nicht gegenseitig überholen. Der Sprecher erläutert auch die Argumente für den NQ-Befehl, die die Anzahl der Ereignisse in der Warteliste und das mit dem Befehl verbundene Ereignis berücksichtigen. Abschließend gibt der Referent einen Überblick über die OpenCL C-Sprache, die auf C basiert und gewisse Einschränkungen und Ergänzungen wie Vektortypen und Synchronisationsprimitive aufweist. Die Sprache ermöglicht Arbeitselemente und Arbeitsgruppen sowie Adressraumqualifizierer und integrierte Funktionen.

  • 00:45:00 In diesem Abschnitt gibt der Referent einen kurzen Überblick über OpenCL und seine Funktionen, wie z. B. die verschiedenen Adressräume, Vektortypen und Skalartypen, die beim Programmieren von Kerneln verwendet werden können. Sie besprechen auch, wie Speicherobjekte erstellt und Programme mit der OpenCL-API erstellt und ausgeführt werden. Der Referent geht dann auf die Frage ein, wie sich die Datenparallelität in OpenCL vom Loop-Unrolling in Compilern unterscheidet.

  • 00:50:00 In diesem Abschnitt erläutert der Referent das Konzept der parallelen Ausführung von Daten und die Schwierigkeiten von Komponenten bei der effizienten Ausführung. Er betont auch die Notwendigkeit, Programme explizit für OpenCL oder jedes andere Modell zu parallelisieren. Der inq_marker ist ein weiteres Thema, das behandelt wird und wie er in Out-of-Order-Cues nützlich ist. Der Sprecher wiederholt, dass konstanter Speicher bedeutet, dass die Werte konstant sind, und dass er auf speziellen GPUs verwendet wird, um in einen sehr schnellen konstanten Speicher zu laden, der schreibgeschützt ist. Er schlägt vor, die OpenCL-Zone auf der MD-Website zu besuchen, um weitere Informationen zu OpenCL und paralleler Programmierung zu erhalten. Zuletzt spricht er darüber, wie get_global_ID(0) bei jedem Aufruf des Kernels denselben Wert zurückgeben würde.

  • 00:55:00 In diesem Abschnitt erklärt der Sprecher, dass, wenn zwei verschiedene Anwendungen beide laufen und versuchen, OpenCL auf demselben Computer zu verwenden, alle Implementierungen heute die Hardware gemeinsam nutzen und das Betriebssystem die Anwendungen multiplext. Sie empfehlen die Verwendung visueller Profiler für OpenCL, wie das Visual Studio-Plug-in oder die Linux-Befehlszeilenversion, mit denen Informationen über id-Hardware abgefragt werden können. Der Aufwand für das Laden von Daten in ein Bildobjekt oder einen Puffer würde vom Gerät abhängen, wo die Übertragung über den PCIe-Bus eine größere Latenz hätte. Abschließend erwähnte der Redner, dass die neue AMD 680-GPU-Serie und die besten Programmierpraktiken für sie der Evergreen-Architektur ähneln, auf der sie basieren.
 

AMD Developer Central: Webinar-Reihe zur OpenCL-Programmierung. 3. GPU-Architektur



3 - GPU-Architektur

Dieses Video bietet einen Überblick über die GPU-Architektur, wobei die Ursprünge und die primäre Verwendung von GPUs als Grafikprozessoren berücksichtigt werden. GPUs sind für die Verarbeitung von Pixeln mit einem hohen Grad an Parallelität ausgelegt, im Gegensatz zu CPUs, die für die skalare Verarbeitung mit Pipelines mit geringer Latenz ausgelegt sind. Die Architektur von GPUs ist für grafikspezifische Aufgaben optimiert, die möglicherweise nicht für allgemeine Berechnungen geeignet sind. Der Referent erklärt, wie die GPU den Durchsatz einer Reihe von Threads maximiert, anstatt die Ausführungslatenz eines einzelnen Threads zu minimieren. Die Architektur des GPU-Engine-Blocks wird ebenfalls diskutiert, einschließlich lokaler Datenfreigaben, Wellenfronten und Arbeitsgruppen. Das Video untersucht verschiedene Funktionen der GPU-Architektur, die dazu beitragen, den Packumfang des Compilers zu erhöhen, einschließlich der Ausgabe abhängiger Operationen in einem einzigen Paket und der Unterstützung abhängiger Zähler mit globalem Beta-Anteil. Obwohl die Designs der GPU- und CPU-Kerne ähnlich sein können, müssen ihre Workloads konvergieren, damit sie ähnliche Designs haben.

In diesem Video zur GPU-Architektur geht der Referent auf das Konzept von Barrieren und deren Funktion ein. Wenn eine Arbeitsgruppe mehrere Wellenfronten in einer GPU enthält, werden Barrieren verwendet, um diese Wellenfronten zu synchronisieren. Existiert jedoch in einer Gruppe nur eine Work Wavefront, werden Barrieren bedeutungslos und auf Non-Operations reduziert.

  • 00:00:00 In diesem Abschnitt stellen die Referenten den Zweck des Webinars vor, das darin besteht, einen Überblick über die GPU-Architektur aus einer anderen Perspektive zu geben als beim traditionellen Ansatz, die Low-Level-Architektur oder Optimierungen zu beschreiben. Die Referenten möchten die GPU-Architektur in einen Kontext stellen, indem sie ihre Ursprünge und ihren primären Anwendungsfall als Grafikprozessoren diskutieren. Sie erklären, wie GPUs für die Verarbeitung von Pixeln mit einem hohen Grad an Parallelität ausgelegt sind, was sich von CPUs unterscheidet, die für skalare Verarbeitung mit Pipelines mit geringer Latenz ausgelegt sind. Die Referenten gehen auch darauf ein, dass die Architektur von GPUs aufgrund ihrer optimierten Hardwareblöcke, die für die Beschleunigung grafikspezifischer Aufgaben ausgelegt sind, möglicherweise nicht für allgemeine Berechnungen geeignet ist.

  • 00:05:00 In diesem Abschnitt erfahren wir, wie Fragmentprogramme ausgeführt werden, die unabhängig sind und sich auf ein einzelnes Pixel beziehen, geschrieben in GLSL oder HLSL, und wie dieses Programmiermuster eine effiziente Parallelität ohne Abhängigkeitsanalyse oder Kommunikation zwischen Pixeln ermöglicht. Die Hardware ist so konzipiert, dass sie Shader-Code auf mehreren Pixeln gleichzeitig ausführt, bekannt als Wavefront, aber mit dem Problem von Blockcode und Verzweigungen. Das Problem tritt auf, wenn alle Verzweigungen den gleichen Weg gehen und ein Problem verursachen, aber die Hardware eine Maske generiert, um sicherzustellen, dass alle Pixel dieselbe Anweisung ausführen.

  • 00:10:00 In diesem Abschnitt erörtert der Sprecher, wie die Cindy-Ausführung einfache Anweisungen und die Verwendung von Vektoranweisungen erfordert. Obwohl Vektorbefehle von Hardware oder einem Compiler generiert werden können, kann dies die Entwicklung fummelig und schwierig machen, da verschiedene Operationen manuell verpackt, Zweigmasken und sorgfältige Handcodierung erforderlich sind. Andererseits birgt die Programmierung der Cindy-Ausführung mit Vektoranweisungen das Risiko, dass der Entwickler denkt, dass sich die Bahnen unabhängig voneinander verzweigen, was nicht stimmt. Trotzdem ist es für Programmierer immer noch einfacher, darüber nachzudenken, und für aktuelle AMD-GPUs wird die Maskierung von der Hardware gesteuert. Dies ist wichtig für die Berechnung, die der Zweck des Vortrags ist, da dies die Leistung beeinträchtigen kann, insbesondere bei Zweigdivergenzen im weiteren Waveland.

  • 00:15:00 In diesem Abschnitt erörtert der Redner die sichtbaren Aspekte von GPU-Architekturen, die auf Durchsatzberechnung basieren, was bedeutet, dass ein Befehlsvektor in einer GPU blockiert, was passieren kann, wenn die Gleitkomma-Addition einige Zyklen dauert abgeschlossen ist, kann dieselbe Anweisung verwendet werden, um die Verzögerungszeit im nächsten Vektor abzudecken, wodurch die Anweisungsdecodierung effizienter wird. Der Sprecher erklärt, dass mehrere Wellenfronten, anstatt die Vektorbreite zu erhöhen, was die Nutzung von ALUs reduzieren kann, Anweisungen von anderen laufenden Threads einschleichen können, was die Wahrscheinlichkeit erhöht, dass sie nicht einfach ins Stocken geraten, während sie darauf warten, dass Textureinheiten Speicherdaten zurückgeben. Aufgrund der Funktionsweise der Architektur dauert es jedoch länger, eine einzelne Wellenfront auf diese Weise auszuführen.

  • 00:20:00 In diesem Abschnitt erklärt das Video, wie die GPU den Durchsatz einer Reihe von Threads maximiert, anstatt die Ausführungslatenz eines einzelnen Threads zu minimieren. Das bedeutet, dass die GPU versucht, die Auslastung von Threads zu erhöhen, indem sie darauf wartet, dass der erste Thread die Ausführung abschließt, und dann die nächste Wellenfront einspeist, während die Ergebnisse des ersten Pixelsatzes wiederverwendet werden, um die Pipeline so nahe wie möglich an der vollen Auslastung zu halten . Die GPU verwaltet einen großen Pool an Registern, um die volle Breite des Vektors für jeden laufenden Thread abzudecken, was Platz auf dem Gerät beansprucht, der mit der Anzahl der Zustände und der Breite des Vektors skaliert. Die GPU ist darauf ausgelegt, die Latenz abzudecken, und daher maximiert die GPU die verfügbare Speicherbandbreite, anstatt die Latenz zu minimieren, sodass sie alle Parallelitäten erfüllen kann, indem Textur-Caches und lokaler Speicher für die Wiederverwendung von Daten zwischen Arbeitselementen verwendet werden.

  • 00:25:00 In diesem Abschnitt erörtert der Referent, wie Caches und programmgesteuerte gemeinsam genutzte Speicherbereiche eine Reduzierung der Datenübertragung erreichen können, indem sie ermöglichen, dass Daten nur einmal von der Hauptspeicherschnittstelle kopiert und dann von verschiedenen Arbeitselementen auf unterschiedlichen Pfaden wiederverwendet werden. Sie erklären, wie der Textur-Cache so konzipiert ist, dass er automatisch eine 2D-Struktur in seinen Daten erzwingt, um 2D-Zugriffe durch die Quads effizient zu erfassen. Lokale Datenregionen bieten erheblich mehr Kontrolle, aber es liegt in der Verantwortung des Entwicklers, Lasten effizient zu strukturieren, um diesen Speicher zu nutzen und Daten gemeinsam zu nutzen, um die globalen Speicheranforderungen zu reduzieren. Der Abschnitt untersucht auch, wie die GPU als eine Sammlung verkabelter Cindy-Kerne mit mehreren Programmzuständen betrachtet werden kann, die 4, 8 oder 16 Threads verschachteln, um die Pipeline-Latenz abzudecken. Der Kompromiss zwischen der Anzahl der Kerne und der ALU-Dichte wird diskutiert, mit dem Vorteil einer zunehmenden Auslastung je nach Arbeitslast.

  • 00:30:00 In diesem Abschnitt erörtert der Referent die Ähnlichkeiten und Unterschiede zwischen CPU- und GPU-Core-Designs anhand von Beispielen wie Andy Phenom 2 X6 6 und Intel i7. Während der von Pentium 4 und ultraSPARC T2 verfolgte Ansatz größere Kerngrößen mit mehreren Statussätzen beinhaltete, um die Parallelität auf Befehlsebene zu erhöhen, befinden sich GPUs am äußersten Ende des Spektrums mit einem hohen Grad an Datenausgleich. Die technischen Details der AMD Radeon HD 5870 werden ebenfalls besprochen, wobei auf ihre hohe Bandbreite und die Anzahl gleichzeitig verfügbarer Wellenformen hingewiesen wird, die von der Anzahl der von jeder Wellenfront verwendeten Register abhängen. Der Redner kommt zu dem Schluss, dass es zwar Ähnlichkeiten im Designbereich zwischen CPU- und GPU-Neunern geben kann, ihre Workloads jedoch konvergieren müssen, damit sie ähnliche Designs haben.

  • 00:35:00 In diesem Abschnitt erfahren wir mehr über die Designelemente der GPU, einschließlich lokaler Datenfreigaben und der Wellenfronten und Arbeitsgruppen, in die sie unterteilt ist. Das Design der GPU umfasst einen Dispatch-Befehlsprozessor eines Colonels, der Wellenfronten erzeugt, die einer verfügbaren SIMD-Einheit zugewiesen werden, die über genügend Ressourcen verfügt, um in den Raum zu passen. Der gesamte Chip verfügt über 20 Cindy-Engines mit 8 GDDR5-Speicherbänken für Crossbars und Caches. Darüber hinaus verfügt es über ein entspanntes globales Speicherkonsistenzmodell, das Fence-Anweisungen erfordert, um Sichtbarkeitsrechte sicherzustellen, sodass die Cindy-Engines und festen Einheiten ein möglichst hohes Maß an paralleler Datenausführung ohne den Overhead der Leistungsleistung aufrechterhalten können. Die GPU verwendet ein auf Klauseln basierendes Ausführungsmodell, das es ihr ermöglicht, viele Ablaufsteuerungsprogramme gleichzeitig auf der einfachsten Engine auszuführen.

  • 00:40:00 In diesem Abschnitt wird die Architektur des GPU-Engine-Blocks besprochen. Der Engine-Block hat zwei Hauptkomponenten: lokale Datenfreigabe, die die gemeinsame Nutzung von Daten zwischen Arbeitselementen in einer Arbeitsgruppe und den Post-Testing-Elementen oder Stream-Kernen ermöglicht, die Anweisungen von ALU-Klauseln im Kernel ausführen. Die lokale Datenfreigabe hat 32 Bänke, jedes der 16 Verarbeitungselemente in der Engine kann anfordern, 32-Bit-Wörter von LDS in jedem Zyklus an beliebigen Adressen zu lesen oder zu schreiben, und Konflikte werden von der Einheit erkannt. Atomare Operationen werden unter Verwendung von Nur-Ganzzahl-ALUs ausgeführt, und Gleitkomma-Atomoperationen wären komplizierter durchzuführen. Das Verarbeitungselement der 5870-Architektur ist ein Cluster aus fünf identischen ALUs, die auf einem sehr langen Befehlswortpaket mit fünf vom Compiler gepackten Operationen mit einigen eigenen Abhängigkeiten arbeiten, und die meisten grundlegenden Operationen können ausgeführt werden.

  • 00:45:00 In diesem Abschnitt beschreibt der Referent verschiedene GPU-Architekturfunktionen, die dazu beitragen, den Packumfang des Compilers zu erhöhen, einschließlich der Ausgabe abhängiger Operationen in einem einzigen Paket und der Unterstützung abhängiger Zähler mit globalem Beta-Anteil. Die globale Beta-Freigabe ist eine weniger bekannte Funktion, die mit dem gesamten Satz von Compute-Engines auf dem Gerät verbunden ist und eine weitaus geringere Latenz hat als der Zugriff auf andere Speicher. Der Sprecher warnt auch davor, dass der Zugriff auf zufällige Pixel im Textur-Cache zu Leistungsproblemen führen kann, da dies schneller ist als der Zugriff auf den globalen Speicher, wenn die Daten nur geclustert sind.

  • 00:50:00 In diesem Abschnitt beantwortet der Referent Fragen zum Erreichen der Vollauslastung in der GPU-Architektur. Das angegebene Beispiel ist, dass Arbeitsgruppen aus Vielfachen von 64 Arbeitselementen bestehen sollten, um eine volle Auslastung zu erreichen. Wellenfronten und die Anzahl der Wellenfronten, die auf jeden Kern passen, wirken sich ebenfalls auf die Vollbelegung aus. Der Sprecher erwähnt auch, dass es keine Vollpräzisionsversionen der transzendentalen Funktionen gibt, die von der 5. Spur generiert werden, die schnelle Annäherungen sind, die gut genug sein können oder nicht, je nach den Anforderungen des Codes. Auf die Frage, ob es eine Möglichkeit gibt, die Wellenfrontgröße in allen Geräten abzufragen, lautet die Antwort, dass es keine solche Möglichkeit gibt.

  • 00:55:00 In diesem Abschnitt erläutert der Referent, was vollständig verschmolzen in Bezug auf globale Speicherzugriffe in einer GPU-Architektur bedeutet. Im Wesentlichen bedeutet dies, dass eine Viertelwellenfront eine Speicheranforderung ausgibt, bei der jede Spur nacheinander auf 128 Bits von ausgerichteten Adressen zugreift, die über die Recheneinheit laufen. Es gibt jedoch je nach Zugriffstyp, ob verbunden oder getrennt, und ob es sich um eine zufällige Sammlung handelt, Effizienzstufen. Der Redner stellt auch klar, dass eine Wavefront eine Arbeitseinheit ist, die aus 64 Arbeitselementen besteht, die zusammen mit einer einzigen Anweisung ausgeführt werden, und nicht dasselbe ist wie eine Arbeitsgruppe, die ein Satz von Arbeitselementen ist.

  • 01:00:00 In diesem Abschnitt erläutert der Referent das Konzept der Barrieren in der GPU-Architektur. Wenn eine Arbeitsgruppe mehrere Wellenfronten hat, werden diese Wellenfronten durch das Ausgeben einer Sperranweisung synchronisiert. Wenn es jedoch nur eine Work Wavefront in einer Gruppe gibt, werden Barrieren auf Nicht-Operationen reduziert und haben keine Bedeutung.
 

AMD Developer Central: Webinar-Reihe zur OpenCL-Programmierung. 4 OpenCL-Programmierung im Detail



4 - OpenCL-Programmierung im Detail

In diesem Video gibt der Referent einen Überblick über die OpenCL-Programmierung und diskutiert seine Sprache, Plattform und Laufzeit-APIs. Sie erläutern das Programmiermodell, das eine feinkörnige Parallelisierung, Arbeitselemente und Gruppen oder Threads, Synchronisierung und Speicherverwaltung erfordert. Der Sprecher erörtert dann den n-Körper-Algorithmus und seine rechnerische Ordnung als n-Quadrat-Natur. Sie erklären, wie OpenCL-Kernel-Code die Position und Geschwindigkeit von Partikeln in der Newtonschen Mechanik aktualisiert, einen Cache zum Speichern einer Partikelposition einführt und wie der Kernel die Partikelposition und -geschwindigkeit mithilfe von Float-Vektordatentypen aktualisiert. Der Referent geht auch darauf ein, wie der Host-Code mit OpenCL-Kernels interagiert, indem er die Parameter und Argumente explizit setzt, Daten zwischen dem Host und der GPU überträgt und die Kernel-Ausführung für die Synchronisierung in die Warteschlange stellt. Schließlich untersucht das Video, wie der OpenCL-Code geändert wird, um mehrere Geräte zu unterstützen, Daten zwischen den GPUs zu synchronisieren und Geräte-IDs für Arrays halber Größe festzulegen, die diese repräsentieren.

Der zweite Teil behandelt verschiedene Aspekte der OpenCL-Programmierung. Es behandelt Themen wie das Doppelpufferschema zum Synchronisieren der aktualisierten Partikelposition zwischen zwei Arrays, OpenCL-Einschränkungen und den Unterschied zwischen globalen und lokalen Zeigern bei der Speicherzuweisung. Darüber hinaus werden Optimierungstechniken für die OpenCL-Programmierung hervorgehoben, einschließlich Vektoroperationen, kontrollierter Speicherzugriff und Loop-Unrolling, zusammen mit Tools, die zur Analyse der OpenCL-Implementierung verfügbar sind, wie z. B. Profiling-Tools. Der Moderator empfiehlt den OpenCL-Standard als Ressource für OpenCL-Programmierer und stellt URLs für den Standard und das ATI Stream SDK bereit. Das Video behandelt auch Fragen zu Themen wie Memory-Sharing, Code-Optimierung, Speicherzuordnung und Auslastung von Recheneinheiten.

  • 00:00:00 In diesem Abschnitt stellt der Referent OpenCL-Konzepte vor und diskutiert die Entstehung hybrider CPU-GPU-Architekturen und die Herausforderungen, die sie für die Programmierung darstellen. OpenCL bietet eine plattform- und geräteunabhängige API mit branchenweiter Unterstützung, und der Referent umreißt die drei Teile der OpenCL-API: die Sprachspezifikation, die Plattform-API und die Laufzeit-API. Das Ausführungsmodell ist in zwei Teile unterteilt: den Kernel, der den ausführbaren Code darstellt, der auf dem OpenCL-Gerät ausgeführt wird, und das Hostprogramm, das die Speicherverwaltung durchführt und die Kernelausführung auf einem oder mehreren Geräten mithilfe der Befehlswarteschlange verwaltet. Die für die Kernelprogrammierung verwendete C-Spracherweiterung basiert auf ISO C99 mit einigen Einschränkungen und Ergänzungen zur Unterstützung der Parallelität.

  • 00:05:00 In diesem Abschnitt erklärt der Referent das Programmiermodell von OpenCL, das eine feinkörnige Parallelisierung über Threads hinweg und Synchronisation erfordert. Workitems und Arbeitsgruppen werden als Threads eingeführt und in Arbeitsgruppen gruppiert, die besondere Eigenschaften hinsichtlich der Synchronisation und des Zugriffs auf den gemeinsam genutzten Speicher haben. Der Redner geht auch auf das Ausführungsmodell auf der Hostseite ein und erklärt, dass alles in einem Kontext zusammengefasst wird, der eine Sammlung von Geräten, Programmobjekten, Kerneln, Speicherobjekten und die Befehlswarteschlange zum Einreihen von Kerneln und Speicher- oder Datenübertragungsvorgängen umfasst . OpenCL unterstützt auch eine Hierarchie verschiedener Speichertypen, um die Art des Speichers in einem Hybridsystem mit verteiltem Speicher widerzuspiegeln.

  • 00:10:00 In diesem Abschnitt erörtert der Referent die Bedeutung der Speicherverwaltung und Synchronisierung bei der Verwendung von OpenCL-Programmierung. OpenCL hat ein entspanntes Speicherkonsistenzmodell, wodurch es in die Verantwortung des Programmierers fällt, Datenübertragungen zu verwalten und zu kontrollieren, wann Daten von einem Gerät auf ein anderes verschoben werden. Die Synchronisierung wird unerlässlich, wenn mehrere Geräte verwendet werden, und es liegt in der Verantwortung des Programmierers sicherzustellen, dass Ereignisse, einschließlich Kernel-Ausführung und Datenübertragungen, korrekt synchronisiert werden. Der Referent stellt die Verwendung von Standard CL vor, einer vereinfachten Schnittstelle zu OpenCL, die einen gebrauchsfertigen Standardkontext bereitstellt, der alle Geräte umfasst und von der vollen OpenCL-Funktionalität nicht unterbrochen wird. Darüber hinaus vereinfacht Standard CL die Speicherverwaltung durch CL Maylock, das Speicher zuweist, der von OpenCL-Geräten gemeinsam genutzt werden kann.

  • 00:15:00 In diesem Abschnitt diskutiert der Redner den grundlegenden n-Körper-Algorithmus, der die Bewegung von nPartikeln modelliert, die einer Form von Partikel-Partikel-Wechselwirkung unterliegen. Der Algorithmus beinhaltet die Berechnung der Kraft auf jedes Teilchen durch Summieren der Beiträge der Wechselwirkung mit allen anderen Teilchen im System. Sobald die Kraft auf jedes Partikel bekannt ist, werden die Partikelposition und -geschwindigkeit über einen kleinen Zeitschritt aktualisiert. Dieser Vorgang wird für jedes Partikel wiederholt, was zu einer Simulation dieser Partikel führt, die sich unter den Wechselwirkungskräften bewegen. Der Algorithmus ist rechnerisch n-Quadrat geordnet, was eine gute Beschleunigung unter Verwendung von Coprozessoren mit Einschränkungen in der Speicherübertragungsbandbreite ermöglicht. Der gesamte Algorithmus kann in nur wenigen Dutzend Codezeilen in C geschrieben werden.

  • 00:20:00 In diesem Abschnitt erklärt der Sprecher die Implementierung des n-Körper-Algorithmus durch eine Schleife, die die Wechselwirkung zwischen Partikeln akkumuliert. Der Kernel-Code ist so konzipiert, dass er eine einigermaßen standardisierte Implementierung mit bewährten Verfahren aus OpenCL-Perspektive bietet, aber er ist möglicherweise nicht optimal für eine bestimmte Architektur. Der Kernel wird für jedes Arbeitselement innerhalb eines Indexbereichs ausgeführt, wobei jeder Thread für die Aktualisierung der Position und Geschwindigkeit eines einzelnen Partikels verantwortlich ist. Die Anwendung hat eine einfache eindimensionale Indexbasis, wobei die Anzahl der Arbeitselemente gleich der Anzahl der Partikel im System ist. Der Host-Code ist auch für die Initialisierung, Speicherverwaltung und Koordinierung von Operationen auf OpenCL-Geräten unerlässlich.

  • 00:25:00 In diesem Abschnitt stellt der Sprecher den Kernel-Code zum Aktualisieren der Position und Geschwindigkeit von Teilchen in der Newtonschen Mechanik vor. Der Prototyp für den Kernel-Code ähnelt dem einer C-Funktion, jedoch mit einigen Qualifizierern, die den Adressraum und die Verwendung eines Blockierungsschemas qualifizieren. Der Kernel-Code wird in einer separaten Datei gespeichert und bei der Just-in-Time-Kompilierung verwendet, wenn das Programm ausgeführt wird. Der Referent erklärt dann, wie der Kernel-Code Größen- und Indexbestimmung vornimmt, bevor er in die eigentliche Berechnung der Physik einsteigt. Die globalen und lokalen Thread-IDs werden ebenfalls ausführlich erklärt, und der Referent merkt an, dass eine äußere Schleife im Kernel-Code impliziert ist, da der Kernel automatisch für jedes Partikel im System ausgeführt wird.

  • 00:30:00 In diesem Abschnitt erläutert der Referent die Implementierung des OpenCL-Kernels für die paarweise Kraftberechnung unter Verwendung eines Caches. Der Kernel speichert eine Partikelposition im Cache und verlässt sich darauf, dass die anderen Arbeitselemente in der Arbeitsgruppe den Cache ebenfalls füllen. Sobald die 64 Partikelpositionen zwischengespeichert sind, durchläuft der Kernel die zwischengespeicherten Partikelpositionen und implementiert die gleiche Kraftberechnung wie im C-Code gezeigt, mit bemerkenswerten Unterschieden, die für OpenCL spezifisch sind. Dazu gehören die Verwendung eines Float-Vektors für die Partikelposition, eine in OpenCL integrierte Funktion für die Quadratwurzel und das bequeme Speichern der Masse in der nicht verwendeten vierten Komponente des Float-Vektors. Der Kernel aktualisiert die Partikelposition und -geschwindigkeit auf einer einzigen Uhr unter Verwendung des Float-Vektordatentyps. Abschließend erklärt der Sprecher die Notwendigkeit von Sperren für die Synchronisation während der Cache-Auffüll- und Schleifenoperationen.

  • 00:35:00 In diesem Abschnitt lernen wir, wie die neue Position und die neue Geschwindigkeit in einem neuen Array in den globalen Speicher zurückgeschrieben werden, um zu vermeiden, dass Daten überschrieben werden, die noch von anderen Threads benötigt werden. Dieses doppelte Pufferungsschema wird in späteren Phasen verwendet, um die Partikelposition sicher zu aktualisieren, ohne dass Probleme mit der Thread-Parallelität auftreten. Weiter zur Host-Code-Implementierung des Kernels erfahren wir, wie das Programm die Parameter setzt, Speicher zuweist, Positionen und Geschwindigkeiten initialisiert, den OpenCL-Kernel erstellt und kompiliert, den erforderlichen aktuellen n-Body-Kernel namentlich abfragt und eine Eins erstellt -dimensionale Kernel-Rechendomäne und legt die Kernel-Argumente explizit fest. Insgesamt zeigt der Code, wie sich OpenCL von einfachen C-Programmen dadurch unterscheidet, dass der Host den Kernel per Proxy ausführt und wie die Argumente für den Kernel direkt gesetzt werden müssen.

  • 00:40:00 In diesem Abschnitt erläutert der Referent den Prozess der Datenübertragung vom Host zur GPU mithilfe eines clm-Senkenaufrufs und die Synchronisierung der Arrays auf dem Gerät (GPU) mithilfe der Flags zum Blockieren von Aufrufen. Dann besprechen sie die Loop-Over-Schritte, führen den Wert und den Burst ein, die für Diagnosezwecke verwendet werden, und verzögern das Setzen der Kernel-Argumente zwei und drei für die doppelte Pufferung. Der Sprecher merkt an, dass die Kernel-Ausführung in die Warteschlange eingereiht ist und der CL-Wait-Synchronisationsaufruf verwendet wird, um sicherzustellen, dass alle Kernel-Ausführungen abgeschlossen sind, bevor fortgefahren wird. Schließlich bringen sie die Daten mithilfe des CL-Enqueue-Lesepuffers von der GPU zum Host zurück.

  • 00:45:00 In diesem Abschnitt behandelt das Video die Änderung des Codes zur Unterstützung mehrerer Geräte, insbesondere die Ausführung des Codes auf zwei GPUs. Der Ansatz besteht darin, die Arbeit für die Kraftberechnung und die Aktualisierung der Partikelposition zwischen den beiden GPUs aufzuteilen, wobei eine GPU für die Hälfte der Partikel verantwortlich ist. Der Kernel-Code sieht wenig Austausch, nur ein zusätzliches Argument namens „position remote“ wurde dem Prototyp hinzugefügt, das auf die Partikelpositionen für Partikel verweist, die eine bestimmte GPU nicht für die Aktualisierung verantwortlich ist, aber dennoch benötigt, um die Gesamtkraft zu berechnen . Auf der Host-Seite gibt es bemerkenswerte Änderungen in Bezug auf Speicherverwaltung und Synchronisierungsprobleme, die sich aus der Verwendung von zwei Geräten ergeben.

  • 00:50:00 In diesem Abschnitt erklärt der Vortrag die Änderungen, die am Kernel-Code vorgenommen werden müssen, um die Partikelsimulation auf zwei GPUs durchzuführen. Die Schleife über die Cache-Partikelpositionen bleibt die gleiche wie zuvor, aber vor Zeile 21 befindet sich die Schleife jetzt über lokalen Partikelpositionen, die der GPU gehören. Der Code wird dann für entfernte Partikel wiederholt, für deren Aktualisierung die andere GPU verantwortlich ist. Der Code zum Aktualisieren von Partikelposition und -geschwindigkeit bleibt gleich. Um den Hostcode für zwei GPUs zu ändern, bleibt die Initialisierung gleich, aber es werden auch Arrays für Partikelpositionen und -geschwindigkeiten zugewiesen, die die Hälfte der Partikel enthalten, wobei A und B die beiden GPUs darstellen. Eine Berechnungsdomäne mit einem Indexraum von nur der Hälfte der ursprünglichen Größe wird erstellt, und der Code zum statischen Setzen des Argumentzeigers auf das Geschwindigkeitsarray wird entfernt.

  • 00:55:00 In diesem Abschnitt erfahren wir, wie Sie die Geräte-ID festlegen, um zu definieren, auf welche GPU die Daten geschrieben werden, wenn über halbgroße Arrays auf die jeweiligen GPUs kopiert werden. Wir sehen auch, dass wir, um Daten zwischen mehreren GPUs auszutauschen, die aktualisierten Partikelpositionen zurück zu den GPUs synchronisieren müssen, indem wir die Partikelarrays halber Größe, die sie darstellen, umschalten. Wir erfahren auch, dass für einige Implementierungen von OpenCL möglicherweise ein CL-Flush-Aufruf für echte Parallelität eingeführt werden muss, dies ist jedoch nicht Teil des Standards.

  • 01:00:00 In diesem Abschnitt geht der Präsentator den Code durch, der das Doppelpufferschema implementiert, um die alten und neuen Partikelpositionen zwischen zwei Arrays auszutauschen. Dieses Schema stellt sicher, dass die aktualisierten Partikelpositionen wieder entweder in Array A oder B eingefügt werden. Sobald die Partikel mit dem Host synchronisiert sind, müssen sie zurück in das größere Array kopiert werden, um einige der Hilfsfunktionen wiederzuverwenden. Der Moderator empfiehlt den OpenCL-Standard als notwendige Ressource für OpenCL-Programmierer und stellt URLs für den Standard und das ATI Stream SDK bereit. Der Referent beantwortet auch Fragen dazu, ob OpenCL für Algorithmen wie Singulärwertzerlegung oder nichtnegative Matrixfaktorisierung verwendet werden kann, und bestätigt, dass die Daten im globalen Speicher auf der GPU zwischen Kernelausführungen gleich bleiben, was für komplexere Algorithmen entscheidend ist.

  • 01:05:00 In diesem Abschnitt diskutiert das Video die aktuellen Einschränkungen der OpenCL-API, die nur Unix/Linux-Systeme unterstützt und an der für eine Windows-Portierung gearbeitet wird. Das Video befasst sich auch mit der Frage der gemeinsamen Nutzung von Speicher zwischen einer GPU und dem Host und erklärt, dass dies zwar möglich ist, aber Leistungseinbußen mit sich bringt, weshalb es typisch ist, globalen Speicher zu verwenden, der auf der Grafikkarte zugewiesen ist. Bei der Zuweisung von Speicher über die OpenCL-API gibt es Möglichkeiten, die Handhabung zu steuern, aber einiges davon erfolgt automatisch auf der Implementierungsebene. Darüber hinaus erklärt das Video den Unterschied zwischen globalen und lokalen Zeigern bei der Speicherzuweisung und wie die Auswahl der optimalen Anzahl von Kernen vom ausgeführten Algorithmus abhängt.

  • 01:10:00 In diesem Abschnitt erörtert der Referent verschiedene Fragen im Zusammenhang mit der OpenCL-Programmierung, z. B. ob das FTL-FGL-RX-Modul geladen und ausgeführt werden soll, die Kompatibilität von Lib-Standard-CL mit C++-Bindungen, die Optimierung von OpenCL-Kerneln zur Leistungsverbesserung und die Verwendung von CL mem Read-Only oder das Versiegeln von Read/Write-in beim Zuweisen von Speicherpuffern. Der Redner weist auch darauf hin, dass es möglicherweise spezielle Tools zum Bearbeiten von OpenCL-Kerneln und zum Optimieren für AMD-GPUs gibt, während er auch feststellt, dass Optimierungstechniken sehr subtil sein können und viel Feinabstimmung erfordern.

  • 01:15:00 In diesem Abschnitt erörtert der Referent Optimierungstechniken für die OpenCL-Programmierung, einschließlich der Organisation von Daten zur Nutzung von Vektoroperationen, der sorgfältigen Steuerung des Speicherzugriffs für eine bessere Leistung und des manuellen Entrollens von Schleifen zur Optimierung. Darüber hinaus sind die Verwendung komplexer Datentypen und die Möglichkeit, Daten zwischen GPUs zu übertragen, ohne zum Host zurückzukehren, implementierungsspezifisch und können je nach Compiler variieren. Der Redner erwähnt auch, dass es Größenbeschränkungen für Speicherpuffer gibt, die vom verfügbaren Speicher auf allen OpenCL-Geräten im System abhängen. Es ist möglicherweise möglich, einfachere Float-Parameter für eine bessere Leistung im konstanten Speicher zu speichern.

  • 01:20:00 In diesem Abschnitt erklärt der Referent, dass in verschiedenen SDKs Tools zur Analyse der OpenCL-Implementierung verfügbar sind, einschließlich Profiling-Tools zur Messung der Auslastung von Recheneinheiten oder Speichertransfers. Der Redner stellt auch klar, dass die Verwaltung der Speicherfragmentierung auf der GPU-Seite implementierungsspezifisch ist und dass die Implementierung sie ordnungsgemäß verwalten muss. Bei Verwendung von doppelter Genauigkeit gibt es keine offensichtliche Antwort darauf, ob die lokale Arbeitsgruppengröße auf 32 oder 16 verringert werden soll, da dies von der verwendeten Architektur abhängt. Der Referent erwähnt auch die Verfügbarkeit von Helferrufen, um Informationen auf allen Geräten im Standard-GPU-Kontext einfach zu erhalten.
 

AMD Developer Central: Webinar-Reihe zur OpenCL-Programmierung. 5. Reale OpenCL-Anwendungen



5 - Reale OpenCL-Anwendungen

In diesem Video spricht Joachim Deguara über eine Multi-Stream-Videoverarbeitungsanwendung, an der er gearbeitet hat, mit Schwerpunkt auf Leistungsoptimierung. Das Video behandelt verschiedene Themen wie das Dekodieren von Videoformaten, die Verwendung von DMA zum Übertragen von Speicher zwischen CPU und GPU, doppeltes Puffern, Ausführen von Kerneln, Verwenden von Ereignisobjekten zum Synchronisieren und Profilieren von Vorgängen, OpenCL-OpenGL-Interop, Verarbeitung von Swipes in Videos und Auswahl zwischen OpenCL und OpenGL bei der Verarbeitung von Algorithmen. Joachim erörtert auch verschiedene Sampling- und SDKs, die für OpenCL-Anwendungen verfügbar sind, stellt jedoch fest, dass derzeit kein Beispielcode für die im Video besprochene spezifische Anwendung verfügbar ist.

  • 00:00:00 In diesem Abschnitt erläutert Joachim Deguara eine Multistream-Videoverarbeitungsanwendung, an der er gearbeitet hat. Die Anwendung umfasst das Öffnen mehrerer Videostreams, deren Dekodierung, das Anwenden von Videoeffekten auf sie, das Kombinieren und schließlich das Präsentieren eines Videostreams, der am Ende wiederholt verarbeitet wird. Joachim Deguara erwähnt, dass die Leistung ein Hauptaugenmerk für diese Anwendung ist, und um eine Echtzeitpräsentation zu erreichen, ist es wichtig, die Dekodierung, Verarbeitung und Anzeige in eine Schleifenstruktur einzupassen, die 30 Mal pro Sekunde oder der Bildrate des Eingangsvideos auftritt .

  • 00:05:00 In diesem Abschnitt liegt der Fokus auf der Decodierung von Videoformaten und dem Verschieben des Frames auf die GPU. Um das Videoformat zu decodieren, muss sichergestellt werden, dass dies so schnell wie möglich erfolgt, damit die Leistung nicht beeinträchtigt wird. Eine Möglichkeit, dies zu tun, besteht darin, die Dekodierfunktion getrennt von der Hauptschleife laufen zu lassen und bei Aufruf den letzten Frame zurückzugeben. Dadurch wird sichergestellt, dass die Dekodierung im Hintergrund erfolgt, während die Hauptschleife ununterbrochen fortgesetzt wird. Um den Frame auf die GPU zu verschieben, werden API-Aufrufe verwendet, die die Angabe des Bildes beinhalten, in das geschrieben werden soll, und ob das Schreiben synchron oder asynchron erfolgen soll.

  • 00:10:00 In diesem Abschnitt erläutert der Redner DMA (Direct Memory Access) und wie damit Speicher zwischen dem Hauptspeicher des Systems und dem Speicher der GPU übertragen werden kann, ohne dass die CPU ihn kopieren muss. Die DMA-Engine verarbeitet diesen Vorgang parallel und gibt Ressourcen für CPU und GPU frei. Die Übertragung von Puffern und Bildern kann asynchron erfolgen und erfordert spezielle Flags. Allerdings können Daten nach einer Kopie nicht sofort verwendet werden, sodass das Programm entsprechend umstrukturiert werden muss, um DMA nutzen zu können. Der Sprecher schlägt doppelte Pufferung und Restrukturierungsschleifenprozesse vor, um zu vermeiden, dass aktuell verarbeitete oder angezeigte Daten beschädigt werden. Insgesamt kann DMA die Anwendungsleistung erheblich verbessern, indem CPU- und GPU-Zyklen entlastet werden.

  • 00:15:00 In diesem Abschnitt erläutert der Redner den Double-Buffering-Ansatz, der in OpenCL verwendet wird, um Frames eines Videos zu verarbeiten und anzuzeigen. Bei diesem Ansatz werden ständig zwei Frames, A und B, gepuffert und einer verarbeitet, während der andere hochgeladen wird. Dadurch entfällt die Notwendigkeit, die Verarbeitungszeit und die Upload-Zeit zu addieren, und nimmt stattdessen nur die maximale Zeit in Anspruch, die für beide Prozesse benötigt wird. Der Referent geht auch auf das Einrichten von Argumenten für den Kernel ein, das nur einmal durchgeführt werden muss und für alle nachfolgenden Verarbeitungsausführungen verwendet werden kann, wenn die Parameter nicht geändert werden müssen.

  • 00:20:00 In diesem Abschnitt erläutert der Sprecher, wie der Kernel ausgeführt wird, und erwähnt zwei Möglichkeiten, die Verarbeitung aufzurufen, einschließlich blockierender und nicht blockierender Methoden. Das Blockieren ermöglicht zwar ein einfacheres Debugging, ist jedoch nicht optimal für die Leistung, daher stellt der Redner die Option vor, Ereignisse und Vektoren von Ereignissen zu verwenden, um auf Operationen zu warten oder Abhängigkeitsdiagramme für mehrere Operationen einzurichten. Indem die Ereignisobjekte verwendet werden, um den Abschluss bestimmter Arbeitselemente zu signalisieren, kann sichergestellt werden, dass der nachgelagerte Betrieb erst beginnt, wenn diese erledigt sind, was eine effizientere Verarbeitung ermöglicht.

  • 00:25:00 In diesem Abschnitt erläutert der Referent, wie OpenCL-Ereignisobjekte zum Synchronisieren von Vorgängen verwendet werden und wie die Ereignisprofilerstellung für Leistungstests verwendet wird. Beim Erstellen des Abhängigkeitsdiagramms für Filter wird als letztes Argument für Enqueue Operation ein Zeiger auf ein Ereignis übergeben, aber das Ereignisobjekt wird innerhalb der InQ erstellt. Dies kann zu Verwirrung führen, ermöglicht jedoch die Einrichtung von Abhängigkeiten zwischen Filtern und Upload-Vorgängen. Der Referent beschreibt, wie es mit der Ereignisprofilerstellung möglich ist, Zeitstempel vom Ereignis zurückzuerhalten, wann bestimmte Ereignisse im Lebenszyklus des Ereignisses aufgetreten sind, z. und fertig gelaufen. Dies ermöglicht die Profilerstellung, während alle Vorgänge asynchron bleiben.

  • 00:30:00 In diesem Abschnitt des Videos erklärt der Sprecher die verschiedenen Zustände, die ein Ereignis bei der Verwendung von OpenCL durchläuft, wie z und identifizieren Sie potenzielle Probleme wie lange Ausführungszeiten für Vorgänge oder Uploads von Daten. Der Referent erläutert auch, wie auf den Abschluss von Ereignissen gewartet werden muss, um die genaue Anzeige von Videostreams mit verschiedenen Filtern und Effekten sicherzustellen.

  • 00:35:00 In diesem Abschnitt erörtert der Redner die OpenCL- und OpenGL-Interop, die den Austausch bestimmter Informationen zwischen den beiden ermöglicht. Diese Funktionalität ist optional und muss daher nicht von allen Implementierungen unterstützt werden. Der Redner betont, wie wichtig es ist, nach der Erweiterung zu suchen und einen Kontext in OpenCL mit bestimmten Flags zu erstellen, um die OpenCL-OpenGL-Interop zu aktivieren. Dies funktioniert so, dass aus einer bereits erstellten OpenGL-Textur ein OpenCL-Image erstellt wird, sodass Daten nicht unnötig hin und her kopiert werden.

  • 00:40:00 In diesem Abschnitt erklärt der Referent, wie OpenCL und OpenGL Bilddaten über Interop gemeinsam nutzen können. Sie decken das Ziel, die NIP-Ebene und das Texturobjekt ab, die zum Referenzieren der Open GL-Textur benötigt werden. Einmal erstellt, kann das OpenCl-Image wie ein normales OpenCl-Image verwendet werden, aber die beiden Programme müssen etwas Handshaking durchführen, um sicherzustellen, dass sie sich nicht gegenseitig stören. Der Referent beantwortet auch eine Frage zum Erstellen von Übergängen beim Video-Rendering. Er sagt, dass dies möglich ist, indem die Position eines Wischens als Eingabe in den Filter verwendet wird. Schließlich wird das Endergebnis zu Anzeigezwecken an OpenGL übergeben, das alle Schritte abschließt.

  • 00:45:00 In diesem Abschnitt erklärt der Sprecher, wie er Swipes in einem Video verarbeitet, indem er sich die Zeitmarkierung jedes Frames ansieht und einen Keyframe verwendet, um die Position des Swipes zu interpolieren. Sie beantworten auch eine Frage zum Profiling in OpenCL und geben an, dass Zeitstempel von einem externen hochauflösenden Timer abhängig sind, aber nicht von einem Aufruf an CL Finish. Darüber hinaus erörtert der Referent die Ausführungsreihenfolge in OpenCL-Geräten und -Laufzeiten und bestätigt, dass die Vorgänge für die meisten Geräte der Reihe nach abgewickelt werden.

  • 00:50:00 In diesem Abschnitt untersucht der Referent die Unterschiede zwischen OpenCL und OpenGL bei der Verarbeitung von Algorithmen. Die Entscheidung, welche Plattform verwendet wird, hängt von individuellen Präferenzen ab, obwohl OpenCL aufgrund seiner umfassenden Sprachstruktur möglicherweise einfacher zu programmieren ist. In Bezug auf die Leistung kann OpenCL die Verarbeitung von Anwendungen ermöglichen, die komplexere Hardware erfordern. Es gibt jedoch Fälle, in denen die Verwendung von OpenGL-Shading zu einer besseren Leistung führen kann. Darüber hinaus konnte der Redner zwar keinen verfügbaren Beispielcode für die spezifische Anwendung bereitstellen, aber es gibt verschiedene Codebeispiele in AMDs OpenCL SDK, von denen Benutzer lernen können.

  • 00:55:00 In diesem Abschnitt erörtert der Referent verschiedene Beispiele und SDKs, die Entwicklern für OpenCL-Anwendungen zur Verfügung stehen. Die Beispiele zeigen, wie Geräte und Laufzeit abgefragt werden, um Erweiterungen zu erhalten, und bieten Beispiele für die Interoperation von OpenCL und OpenGL. Derzeit ist jedoch kein Beispielcode für die im Video besprochene spezifische Anwendung verfügbar, dies kann sich jedoch in Zukunft ändern. Das Webinar ist nun beendet und den Teilnehmern wird eine Aufzeichnung zur Verfügung gestellt.
 

AMD Developer Central: Webinar-Reihe zur OpenCL-Programmierung. 6. Device Fission-Erweiterungen für OpenCL



6 - Device Fission-Erweiterungen für OpenCL

In diesem Video behandelt der Referent verschiedene Themen im Zusammenhang mit Gerätespaltungserweiterungen für OpenCL. Sie erklären die verschiedenen Arten von Erweiterungen und wie die Gerätespaltung es ermöglicht, große Geräte in kleinere zu unterteilen, was nützlich ist, um einen Kern für Aufgaben mit hoher Priorität zu reservieren oder sicherzustellen, dass bestimmte Arbeitsgruppen bestimmten Kernen zugewiesen werden. Sie diskutieren die Bedeutung der Beibehaltung der sequentiellen Semantik bei der Parallelisierung von Vektor-Pushback-Operationen, der Verwendung paralleler Muster zur Optimierung des Prozesses und der Erstellung nativer Kernel in OpenCL. Der Redner demonstriert auch eine Anwendung, die die Gerätespaltung für OpenCL nutzt, und diskutiert die Speicheraffinität und die Zukunft der Gerätespaltung auf anderen Geräten.

  • 00:00:00 In diesem Abschnitt erörtert der Redner Erweiterungen in OpenCL, insbesondere die drei verschiedenen Arten von Erweiterungen: KHR-Erweiterungen, EXT-Erweiterungen und Herstellererweiterungen. KHR-Erweiterungen sind von der OpenCL-Arbeitsgruppe genehmigt und werden mit einer Reihe von Konformitätstests geliefert. EXT-Erweiterungen werden von mindestens zwei Arbeitsgruppenmitgliedern entwickelt und erfordern keine Konformitätstests. Anbietererweiterungen wie CL_AMD_printf werden von einem einzigen Anbieter entwickelt und möglicherweise nur von diesem Anbieter unterstützt. Die Dokumentation für alle Erweiterungen ist auf der Website der Chronos OpenCL-Registrierung verfügbar, was für Transparenz und Zugänglichkeit zwischen Anbietern sorgt.

  • 00:05:00 In diesem Abschnitt erwähnt der Redner die Device-Fission-Erweiterung für OpenCL namens Device Vision. Diese Erweiterung ermöglicht es dem Benutzer, große Geräte mit vielen Recheneinheiten in kleinere OpenCL-Geräte aufzuteilen, entweder nach Namen oder nach Speicheraffinität. Diese Unterteilung kann dabei helfen, einen Kern für eine vorrangige Aufgabe zu reservieren oder sicherzustellen, dass bestimmte Arbeitsgruppen bestimmten Kernen zugewiesen werden, wie in einem SMP-basierten System. Der Referent begründet die Verwendung von Device Vision mit einem Beispiel für parallele Algorithmen und parallele Container, die auf OpenCL aufbauen, und erklärt, dass diese Erweiterung derzeit von AMD und IBM auf ihren CPUs und Cell Broadband-Geräten unterstützt wird.

  • 00:10:00 In diesem Abschnitt erörtert der Referent die Bedeutung der Beibehaltung der sequentiellen Semantik bei gleichzeitiger Parallelisierung von Vektor-Pushback-Operationen. Sie erklären, dass beim Einfügen von Elementen in einen Vektor während einer sequentiellen Schleife die erwartete Reihenfolge als Funktion der Schleife erscheinen würde. Bei der Parallelisierung geht diese Reihenfolge jedoch verloren, und Elemente können in falscher Reihenfolge eingefügt werden, sodass der Sprecher vorschlägt, die sequentielle Semantik der Vektor-Pushback-Operation beizubehalten. Sie geben dann ein Beispiel dafür, wie dies in einer Anwendung wie einer vereinfachten Version eines MPEG-2-Streams wesentlich sein könnte. Abschließend führen sie eine C-Funktion ein und diskutieren, wie diese parallelen Operationen auf CPUs implementiert werden können.

  • 00:15:00 In diesem Abschnitt erläutert der Referent, wie parallele Muster verwendet werden, um den Device Fission Extensions for OpenCL-Prozess zu optimieren. Sie verwenden das Pipelinemuster, um Funktionen parallel auszuführen, und führen einen Datenblock ein, der aus den Eingabedaten gelesen werden muss, um eine Arbeitsaufgabe in einem lokalen Speicher zu verarbeiten. Der Ansatz schreibt dann den Offset des Postfachs in die entsprechende Arbeitsgruppe, um die Offsets zu berechnen, während die Reihenfolge der Ausgabe beibehalten wird. Die Reihenfolge wird durch Kommunikation zwischen Arbeitsgruppen erreicht, anstatt sich auf die globale ID zu verlassen, die in einer willkürlichen Reihenfolge ausgeführt werden kann. Das Pipeline-Muster stellt sicher, dass Funktionen parallel ausgeführt werden, um den Prozess zu optimieren.

  • 00:20:00 In diesem Abschnitt bespricht der Sprecher seine Pipeline und wie sie den Begriff „Zähler“ jetzt als Postfach verwenden, da sie über das bloße Zählen von Dingen hinausgegangen sind. Sie erklären, dass sie Gruppen-IDs für die Indizierung an die Postfächer übergeben und lokalen und globalen Speicher für einfache Berechnungen verwenden. Sie stellen jedoch fest, dass es keine Garantien für die Ausführung von Arbeitsgruppen gibt, und erklären, wie dies zu einer Deadlock-Situation führen kann. Um dieses Problem anzugehen, schlägt der Redner vor, das Gerät mithilfe von Device Vision in zwei separate Kerne zu unterteilen, eine Arbeitsgruppe auf jedem Kern zu starten und den Fortschritt zu garantieren. Sie führen auch einen wichtigen Mechanismus ein, der von OpenCL für die Ausführung auf einem Hostgerät bereitgestellt wird.

  • 00:25:00 In diesem Abschnitt erörtert der Referent die Vorteile der Verwendung nativer Kernel in OpenCL, die die Ausführung beliebiger C- oder C++-Funktionen ermöglichen. Es bietet mehr Flexibilität beim Ausprobieren verschiedener Implementierungen sowie die Möglichkeit, Standard-E/A-Routinen oder andere Bibliotheksfunktionen aufzurufen, die in OpenCL möglicherweise nicht verfügbar sind. Der Prozess zum Erstellen eines nativen Kernels in OpenCL umfasst das Übergeben einer Befehlswarteschlange und einer Funktion zusammen mit ihren Argumenten und Speicherobjekten. Bei Thread-lokaler Speicherung ist jedoch Vorsicht geboten, da die Funktion möglicherweise nicht im selben Thread ausgeführt wird, in dem sie eingebunden wurde. Der Referent stellt auch die OpenCL C++-Bindungs-API vor, die einige Abstraktionen zusätzlich zur C-API bietet. Das Programm beginnt damit, die verfügbaren Plattformen abzufragen und einen Kontext und Gerätetyp zu erstellen.

  • 00:30:00 In diesem Abschnitt erörtert der Referent die Verwendung von Gerätespaltungserweiterungen für OpenCL. Sobald ein gültiges Gerät abgefragt wird, wird eine Liste von Geräten zurückgegeben und das erste Gerät ausgewählt, um die Gerätespaltung zu unterstützen. Die Gerätespaltung ist neu in der OpenCL-API und erfordert Erweiterungsmechanismen, die es ermöglichen, eine Partition zu beschreiben. Sie verwenden die Partition gleichermaßen, um sie in Einheiten von Eins-Einheiten zu partitionieren. Anschließend werden die Subdevice-Eigenschaften eingerichtet und die Funktion zum Erstellen von Subdevices aufgerufen. Unter der Annahme, dass mindestens ein Untergerät erstellt wird, werden Mailboxen erstellt und eine Befehlswarteschlange für jedes Gerät erstellt. Die resultierenden Geräte sind genau wie alle anderen Geräte und können austauschbar mit bestehenden Bibliotheken verwendet werden. Der Referent geht dann zum Einrichten nativer OpenCL-Kernel über.

  • 00:35:00 In diesem Abschnitt diskutiert der Referent die Eingaben und Argumente, die für die Implementierung von Device Fission-Erweiterungen für OpenCL erforderlich sind. Der Referent erklärt, dass der Speicherpuffer für die Eingaben in vier Teile aufgeteilt wird, wo die Zeiger von der FN c-Laufzeit abgelegt werden. Der Speicherpuffer besteht aus Postfächern, Blöcken und Cache-Transaktionen, und für jeden Kernel werden eindeutige IDs generiert. Der Sprecher erklärt weiter, dass jede Instanz des Kernels auf einzelnen Geräten ausgeführt wird, und sobald alle Ereignisse abgeschlossen sind, werden die Daten mit dem eingefügten Padding ausgeschrieben. Der Kernel selbst wird Optimierungen in Bezug auf Blockierung und Caching enthalten, um eine effiziente Ausführung zu gewährleisten.

  • 00:40:00 In diesem Abschnitt erörtert der Referent die Implementierung einer Anwendung, die die Gerätespaltung für OpenCL nutzt. Sie erklären, wie die Anwendung funktioniert, indem sie verschiedene Typen wie Eingabe/Ausgabe, Postfächer, lokale Blockarrays, Blockgröße und Gruppen-IDs verwenden, um Datensätze parallel zu indizieren. Die Anwendung implementiert auch einfache Busy Waiting- und Blocking-Optimierungen, um sicherzustellen, dass alles so weit wie möglich parallel ausgeführt wird. Durch die Nutzung von Device Fission zeigt die Implementierung dieser Anwendung das Potenzial zur Erzielung von Beschleunigungen auf der CPU mit wenig bis gar keinen ALU-Operationen, die mit der Implementierung breiterer Vektoren in der Zukunft noch weiter zunehmen könnten. Der Referent diskutiert auch die anderen Anwendungen und Anwendungsfälle für die Gerätespaltung, wie z. B. die Teilung in Bezug auf Unendlichkeits- und Numa-Weltraumsysteme.

  • 00:45:00 In diesem Abschnitt erörtert der Redner die Vorteile der Speicheraffinität in OpenCL, die die genaue Zuordnung von Puffern zu einem bestimmten Gerät ermöglicht. Dies kann zu einer besseren Cache-Lokalität und einer verbesserten Leistung führen, indem Konflikte und negatives Teilen vermieden werden. Das in OpenCL verwendete Mailbox-Schema kann erweitert werden, um mehrere Iterationen zu unterstützen, wodurch eine Schleife ermöglicht wird, die die Wasserfall-Pipeline immer wieder startet. Der Redner erwähnt auch die Verfügbarkeit von Ressourcen in der OpenCL-Zone auf developer.amd.com, wo interessierte Parteien weitere Informationen über OpenCL finden können, darunter Webinare, frühere Präsentationen und ein bevorstehendes Gipfeltreffen zum Thema heterogenes Computing. Der Sprecher deutet auch die Möglichkeit an, Device Fission in Zukunft auf der GPU zu unterstützen, was einen Teil des Kerns für hochpriore Aufgaben reservieren und für eine bessere Performance sorgen würde.

  • 00:50:00 In diesem Abschnitt des Videos diskutiert der Sprecher die Zukunft der Gerätespaltung in Richtung anderer Geräte. Derzeit unterstützen nur AMD und IBM Gerätespaltungserweiterungen für OpenCL, aber andere Anbieter haben Interesse an dem Vorschlag gezeigt. Es wird die Frage aufgeworfen, ob mathematische Bibliotheken wie BLAS und FFT unterstützt werden, und der Referent bestätigt, dass an OpenCL-Implementierungen sowohl von BLAS als auch an verschiedenen Varianten und Implementierungen für lineare Algebra gearbeitet wird, die in einer Bibliothek im FFT-Stil präsentiert werden.
 

AMD Developer Central: Webinar-Reihe zur OpenCL-Programmierung. 7. Geglättete Partikelhydrodynamik




7 – Geglättete Partikelhydrodynamik

Dieses Video behandelt die Smoothed Particle Hydrodynamics (SPH), eine Technik zur Lösung von Gleichungen für die Fluiddynamik, insbesondere die Navier-Stokes-Gleichungen. Das Video erklärt die verschiedenen Terme in den Gleichungen, einschließlich der Terme für Dichte, Druck und Viskosität, und wie sie mit einem Glättungskern angenähert werden. Der für SPH verwendete numerische Algorithmus sowie die Verwendung von räumlicher Indizierung und Interop werden ebenfalls diskutiert. Der Referent erklärt den Prozess der Erstellung eines räumlichen Index und einer Nachbarkarte und wie die Physik berechnet wird. Das Video lädt Zuschauer ein, das Programm herunterzuladen und zu verwenden, und diskutiert die Grenzen der Simulation. Der Redner beantwortet dann Fragen aus dem Publikum zur GPU-Leistung, zum nicht komprimierbaren Verhalten und zur Verwendung von zwischengespeicherten Bildern.

  • 00:00:00 In diesem Abschnitt gibt Alan Hierich, Senior Member of Technical Staff bei AMD, einen Überblick über Computational Fluid Dynamics, insbesondere Smooth Particle Hydrodynamics (SPH). SPH wurde ursprünglich für astrophysikalische Berechnungen verwendet, ist aber in Videospielen und Simulationen sehr beliebt geworden. Die Technik wird zur Lösung der Navier-Stokes-Gleichungen verwendet, bei denen es sich um partielle Differentialgleichungen handelt, die in den 1900er Jahren formuliert wurden und heute die Grundlage der meisten Arbeiten zur Fluiddynamik bilden. Allen erklärt die Definition von Flüssigkeiten und bietet eine intuitive Erklärung ihrer Funktionsweise, wobei der Schwerpunkt auf Flüssigkeiten und Gasen liegt. Er skizziert auch, dass Flüssigkeiten im Allgemeinen durch die Navier-Stokes-Gleichungen beschrieben werden und die inkompressiblen Navier-Stokes-Gleichungen Flüssigkeiten wie Wasser bei normalen Geschwindigkeiten und normalen Temperaturen regeln.

  • 00:05:00 In diesem Abschnitt erklärt der Referent die Gleichungen, die Flüssigkeiten regeln, die als Navier-Stokes-Gleichungen bekannt sind. Die Bewegungsgleichung stellt die Geschwindigkeitsänderung als Funktion von Schwerkraft, Druck und Viskosität dar, während die Massenkontinuitätsgleichung besagt, dass Masse weder erzeugt noch zerstört wird. Die Phänomene, die eine Flüssigkeit bestimmen, sind Schwerkraft, Druck und Geschwindigkeit, und die Viskosität ist die Klebrigkeit der Flüssigkeit, die die Wahrscheinlichkeit bestimmt, dass sich Flüssigkeitspartikel in die gleiche Richtung bewegen. Der Begriff der Konvektionsbeschleunigung wird ebenfalls diskutiert, der die Beschleunigung einer Flüssigkeit beschreibt, wenn sie sich durch eine kleinere Öffnung bewegt, wie z. B. eine Düse an einem Gartenschlauch. Der Redner lädt das Publikum ein, das Programm herunterzuladen und damit zu spielen, das Flüssigkeiten in einer demonstrierten Box simuliert.

  • 00:10:00 In diesem Abschnitt erklärt der Referent die verschiedenen Begriffe in der Bewegungsgleichung für Fluiddynamik, einschließlich Konvektionsbeschleunigung, Druckgradient und Viskosität. Der Druck ist definiert als die Differenz zwischen der tatsächlichen Dichte der Flüssigkeit an einem Punkt und der Ruhedichte. Der Viskositätsterm, der letzte Term auf der rechten Seite der Bewegungsgleichung, verteilt den Impuls des Systems, was letztendlich zu einem Zustand führt, in dem die Geschwindigkeit an allen Stellen gleich ist. Es gibt auch eine Massenkontinuitätsgleichung, del dot V gleich 0, was impliziert, dass Masse in den inkompressiblen Gleichungen weder erzeugt noch zerstört wird. Um schließlich die Dynamik des Systems darzustellen, nimmt der Sprecher die materielle Ableitung der Gleichung, um die Bewegungsgleichung für ein Teilchen zu erhalten.

  • 00:15:00 In diesem Abschnitt erläutert das Video die Smoothed Particle Hydrodynamics (SPH)-Technik zur Lösung der vereinfachten inkompressiblen Navier-Stokes-Gleichungen, die im vorherigen Abschnitt eingeführt wurden. Die SPH-Technik wurde erstmals 1992 zum Studium der Astrophysik und Galaxien eingeführt, kann aber auch für Flüssigkeitsgleichungen verwendet werden. Es beinhaltet die Einführung von Glättungskerndarstellungen von Mengen, die wie Basisfunktionen sind, die es uns ermöglichen, jede Menge durch eine Summierung der Menge an nahe gelegenen Punkten, multipliziert mit einer Gewichtungsfunktion, zu approximieren. Die SPH-Technik wird verwendet, um Dichte- und Druckgradiententerme in den Navier-Stokes-Gleichungen anzunähern. Das Video erwähnt auch, dass die Navier-Stokes-Gleichungen numerisch maßstabsabhängig sind und dass Berechnungen in einem kleineren Maßstab durchgeführt werden, bevor sie auf den regulären räumlichen Maßstab erweitert werden, um die Partikel im Raum zu bewegen.

  • 00:20:00 In diesem Abschnitt erläutert der Referent die drei Hauptterme, die in der Smoothed Particle Hydrodynamics (SPH) angenähert werden, nämlich die Terme für Dichte, Druck und Viskosität. Um die Dichte zu berechnen, berechnet das Programm die Masse der Partikel an verschiedenen Punkten und multipliziert diese mit dem Gradienten eines Glättungskerns. Der Druckterm wird dann unter Verwendung einer skalaren Größe des Drucks dividiert durch die Dichte berechnet, die mit dem Gradienten des Glättungskerns multipliziert wird. Andererseits wird der Viskositätsterm unter Verwendung eines Skalarkoeffizienten angenähert, der das Niveau der Fluidviskosität und die Geschwindigkeitsdifferenz zwischen zwei Punkten dividiert durch die Dichte von Punkt J bestimmt. Der Referent erklärt auch die Eigenschaften des Glättungskerns, der ist in der SPH-Simulation verwendet wird und wie sie sich über einer Kugel mit Radius H zu eins summiert.

  • 00:25:00 In diesem Abschnitt erörtert der Referent den numerischen Algorithmus, der für Smoothed Particle Hydrodynamics (SPH) verwendet wird. Der Algorithmus umfasst die Berechnung von Dichte, Druck, Druckgradient, Viskositätsterm und Beschleunigung, die dann verwendet werden, um die Geschwindigkeiten und Positionen der Partikel zeitlich zu bestimmen. Der Referent erklärt, dass der anfängliche Algorithmus darin besteht, die Wechselwirkungen aller Teilchen gegen alle Teilchen zu testen, was richtig, aber nicht schnell genug ist. Daher wird ein besserer Algorithmus eingeführt, der den Raum in Voxel aufteilt und Interaktionen nur mit Partikeln innerhalb des Interaktionsradius erlaubt. Zusätzlich wird eine Teilmenge von Partikeln zufällig ausgewählt, um Wechselwirkungen zu berechnen, anstatt alle Partikel zu berücksichtigen, was ein effizientes Programm erzeugt.

  • 00:30:00 In diesem Abschnitt erörtert der Referent die Verwendung der räumlichen Indizierung, um nur Interaktionen mit einer begrenzten Anzahl von Partikeln in OpenCL-Simulationen zu berechnen, sowie die Bedeutung der Verwendung von Interop zur gemeinsamen Nutzung von Datenpuffern mit einem Grafiksystem. Während Interop das Rendern direkt aus dem GPU-Puffer ermöglicht und Platz im Grafikspeicher spart, müsste das Programm ohne Interop Daten in den Hostspeicher und zurück kopieren, was die Simulation erheblich verlangsamt. Der Referent erläutert die für die Verwendung von Interop erforderlichen Änderungen, einschließlich der Erstellung eines anderen Kontexts, und stellt den Satz von Puffern vor, der für die Simulation benötigt wird, einschließlich des Partikelindex zum Sortieren. Obwohl die Bedeutung von Interop diskutiert wird, verwendet das gezeigte Programm es nicht, was die Simulation verlangsamt.

  • 00:35:00 In diesem Abschnitt erörtert der Sprecher die verschiedenen Kernel, die im Smoothed Particle Hydrodynamics-Algorithmus verwendet werden. Der erste Kern sind „Hash-Partikel“, die Partikel mit einem Voxel verknüpfen. Dann sortieren "sort"- und "sort post pass"-Kernel die Partikel in Voxel und organisieren sie für die räumliche Indexkonstruktion. Als nächstes konstruieren die "Index"- und "Index Post Pass"-Kernel einen räumlichen Index von Voxeln zu Partikeln. Danach entscheidet der "feine Nachbarn"-Kernel, welche Nachbarn miteinander interagieren. Schließlich berechnen die Kernel "Dichtedruck berechnen", "Beschleunigung berechnen" und "Integrieren" die Wechselwirkungen und die Physik zwischen Partikeln. Der Referent erklärt, dass Radix-Sortierung in der GPU-Version des Codes verwendet wird, während Q-Sortierung in der CPU-Version des Codes verwendet wird.

  • 00:40:00 In diesem Abschnitt erklärt das Video den Prozess der Konstruktion eines räumlichen Index von Voxeln zu Partikeln in Smoothed Particle Hydrodynamics (SPH). Der Kernel verwendet eine binäre Suche, um das Teilchen mit der niedrigsten Nummer in jedem Voxel zu identifizieren, und hinterlässt einen Wert von minus eins in Voxeln, die keine Teilchen enthalten. Der Index-Post-Pass füllt dann einen Indexwert für leere Voxel aus, indem er den Wert des nächsten nicht leeren Voxels in den Gitterzellenindex kopiert. Sobald die Indizierung abgeschlossen ist, konstruiert das Programm eine Nachbarkarte, indem es die lokale Region von zwei mal zwei mal zwei Voxeln durchsucht, die jedes Partikel umgeben. Um Verzerrungen zu beseitigen, erzeugt das Programm einen zufälligen Versatz in jedem Voxel und wechselt die Richtung der Suche. Der Kernel wählt dann die ersten 32 Partikel innerhalb des Interaktionsradius aus und fügt sie der Nachbarkarte hinzu.

  • 00:45:00 In diesem Abschnitt erklärt der Sprecher, wie sie die Physik berechnet haben, indem sie eine Nachbarkarte erstellt haben, die es ihnen ermöglicht, mit 32 Teilchen zu interagieren. Sie gehen die Gleichungen durch, die zur Annäherung von Dichte und Druck verwendet werden, berechnen Beschleunigungsterme und kombinieren dann alles, um die Gesamtbeschleunigung zu bestimmen. Die Geschwindigkeit und Position werden dann durch numerische Integration vorangetrieben, wobei Randbedingungen vorhanden sind, um zu verhindern, dass Partikel aus der Box entweichen. Der Sprecher ermutigt die Zuschauer, den Quellcode herunterzuladen und damit zu spielen, und betont, dass es zwar viele langsame Methoden zum Lösen der Navier-Stokes-Gleichungen gibt, langsam aber nicht unbedingt gut bedeutet.

  • 00:50:00 In diesem Abschnitt des Videos erklärt der Sprecher den Aktualisierungsschritt der Simulation, bei dem die Geschwindigkeit in ihre neue Position integriert wird, bevor die Position aktualisiert wird. Die Aktualisierung der Geschwindigkeit ist explizit, während die Aktualisierung der Position halbimplizit ist, wobei der Wert der Geschwindigkeit beim nächsten Zeitschritt verwendet wird. Die Simulation befindet sich aus Leistungsgründen in Float, aber wenn hohe Wiedergabetreue und Genauigkeit erforderlich sind, wird die Verwendung von double empfohlen. Der Algorithmus ist vollständig parallelisierbar, aber die Kompromisse der räumlichen Partitionierung müssen berücksichtigt werden. Abschließend beantwortet der Referent Fragen zur Verwendung von Interop mit mehreren GPUs, zur Simulation von Turbulenzen und zur praktischen maximalen Anzahl von Partikeln in der Simulation.

  • 00:55:00 In diesem Abschnitt beantwortet der Sprecher einige Fragen aus dem Publikum. Sie erklären, dass die praktische Grenze ihrer Simulation die Leistungsrate ist, die von der Klasse der verwendeten GPU und CPU abhängt. Sie erwähnen auch, dass, obwohl ihre Simulation auf inkompressiblen Gleichungen basiert, sie nicht explizit nach der Inkompressibilitätsbedingung lösen, was ihr komprimierbares Verhalten einschränken könnte. Der Referent beantwortet auch eine Frage, warum sie Puffer anstelle von zwischengespeichertem Bildspeicher verwendet haben, und gibt an, dass sie zum Zeitpunkt der Entwicklung des Programms keinen Leistungsvorteil durch die Verwendung von zwischengespeicherten Bildern gesehen haben. Sie erwähnen jedoch, dass OpenCL in Zukunft Unterstützung für zwischengespeicherte Puffer bieten wird und dass sie das Programm möglicherweise ändern werden, um sie zu unterstützen. Insgesamt lädt der Redner das Publikum ein, das Programm herunterzuladen und auf beliebige Weise zu verwenden, da es keine Einschränkungen gibt.
 

AMD Developer Central: Webinar-Reihe zur OpenCL-Programmierung. 8. Optimierungstechniken: Bildfaltung



In diesem Video diskutiert Udeepta D. Bordoloi die Optimierungstechniken bei der Bildfaltung.

 

AMD Developer Inside Track: So optimieren Sie die Bildfaltung



So optimieren Sie die Bildfaltung

In diesem Video werden verschiedene Methoden zur Optimierung der Bildfaltung erläutert, darunter die Verwendung lokaler Datenfreigabe, die Optimierung von Konstanten und die Verwendung größerer lokaler Bereiche zur Verbesserung der Effizienz. Der Redner betont die Bedeutung der Minimierung der Verarbeitungszeit bei der Bildfaltung zur Verbesserung der Gesamtleistung und hebt ein neues Verfahren zur Wiederverwendung von Daten unter Verwendung von lokalem Speicher hervor. Das Video bietet Vorschläge für Optimierungsschritte wie die Verwendung von offensichtlichen oder Texturen, die Verwendung von Gedankenkraft und die Verwendung der Weitergabeoptionen an den Zähler. Ein Schritt-für-Schritt-Artikel zur Optimierung von Bildfaltungstechniken ist auf der Entwickler-Website von AMD verfügbar.

  • 00:00:00 In diesem Abschnitt erläutert Udeepta Bordolo vom Grafikteam von AMD das Konzept der Bildfaltung, bei der eine gewichtete Summe über einen Bereich des Eingabebilds erstellt wird, um ein Ausgabebildpixel zu erzeugen. Er verwendet OpenCL und eine 5870-GPU, um die Optimierung durchzuführen, und arbeitet sich schrittweise ausgehend vom grundlegenden Korrelationscode vor. Spiegelung und Verwendung von LDS (Local Data Share) sind einige der verwendeten Optimierungsmethoden, die zu einer erheblichen Reduzierung der Ausführungszeit führen.

  • 00:05:00 In diesem Abschnitt erörtert der Referent die Optimierung der Bildfaltung in einem Programm, das für alle Filtergrößen und alle Eingabegrößen funktioniert. Er konzentriert sich darauf, lokale Bereiche zu nutzen, um die gemeinsame Nutzung von Daten zu verbessern und Wartezeiten zu reduzieren. Durch die Interpretation von Konstanten und Eingaben als 128-Bit-Werte können Compiler und Genie den Code einfacher interpretieren und die Verarbeitungszeit verkürzen. Er zeigt, wie die Optimierung von Konstanten und die Verwendung größerer lokaler Bereiche die Effizienz bei der Bildfaltung erheblich verbessern können. Insgesamt betont der Redner, wie wichtig es ist, Wege zur Minimierung der Verarbeitungszeit bei der Bildfaltung zu finden, um die Gesamtleistung zu verbessern.

  • 00:10:00 In diesem Abschnitt erläutert der Referent, wie die Bildfaltung optimiert werden kann, indem die Filtergröße bestimmt und für verschiedene Masken geändert wird. Der Redner weist darauf hin, dass die Anwendung der Optimierung zu unterschiedlichen Zeiten die Leistung beeinträchtigen kann, aber dabei helfen kann, unerwartete Probleme zu finden. Der Redner erörtert auch das Ausführen der gleichen Anzahl von Elementen für ein 2k x 2k-Eingabebild mit Full-Force-Daten, was zu einem effizienteren Datenformat führte. Darüber hinaus hebt der Redner eine neue Methode zur Wiederverwendung von Daten hervor, anstatt den Motor zu verwenden, indem lokaler Speicher verwendet wird, der in der Hardware als LDS bekannt ist.

  • 00:15:00 In diesem Abschnitt spricht der Sprecher über die Optimierung von Bildfaltungstechniken. Sie laden alle Eingaben, verzögern sie um eine bestimmte Gruppe und arbeiten dann das Offensichtliche ab. Sie verwenden das Geld, wie sie es kennen, und hören auf, LDS zu verwenden, um es mit Texturen zu versuchen. Sie führen ein Experiment mit einer Auflösung von 2K mal 2K und verschiedenen Filtergrößen durch und erhalten die schnellste Zahl, wenn sie Texturen verwenden. Sie schlagen die Optimierungsschritte der Verwendung von offensichtlichen oder Texturen, der Verwendung von Gedankenkraft und der Verwendung der Weitergabeoptionen an den Zähler vor. Sie schlagen auch vor, wenn möglich das Bargeldmonster zu verwenden. Sie haben auf der Entwickler-Website von AMD einen Schritt-für-Schritt-Artikel über die Optimierung von Bildfaltungstechniken veröffentlicht, auf den sie neben dem Video verlinken.
 

AMD Developer Central: Technischer Überblick über OpenCL. Einführung in OpenCL



AMD Developer Central: Technischer Überblick über OpenCL. Einführung in OpenCL

In diesem Video gibt Michael Houston einen Überblick über OpenCL, einen Industriestandard für parallele Datenverarbeitung, der auf Mehrkern-CPUs, mobile Geräte und andere Formen von Silizium abzielt. OpenCL zielt darauf ab, zuvor konkurrierende proprietäre Implementierungen wie CUDA und Brook+ zu vereinheitlichen, was die Entwicklung für unabhängige Softwareanbieter vereinfachen wird. Es bietet eine Aufschlüsselung zwischen Code, der auf dem Gerät ausgeführt wird, und Code, der das Gerät mithilfe eines Warteschlangensystems verwaltet, das für Feedback mit Spieleentwicklern entwickelt wurde. OpenCL wurde entwickelt, um gut mit Grafik-APIs zusammenzuarbeiten und eine allgegenwärtige Computersprache zu schaffen, die für verschiedene Anwendungen wie Foto- und Videobearbeitung sowie für künstliche Intelligenzsysteme, Modellierung und Physik verwendet werden kann. Der Moderator erörtert auch die Verwendung von OpenCL für das Hollywood-Rendering und hofft auf weitere Arbeiten in diesem Bereich.

  • 00:00:00 In diesem Abschnitt erläutert Mike Houston den Zweck von OpenCL als Industriestandard für parallele Datenverarbeitung, der auf Mehrkern-CPUs, mobile Geräte und andere Formen von Silizium abzielt. OpenCL zielt darauf ab, zuvor konkurrierende proprietäre Implementierungen wie CUDA und Brook+ zu vereinheitlichen, was die Entwicklung für unabhängige Softwareanbieter vereinfachen wird. Obwohl es einen anderen Dialekt und geringfügige Unterschiede in OpenCL gibt, ist der Übergang von anderen Datenparallelsprachen wie CUDA direkt und schnell. OpenCL bietet auch eine Aufschlüsselung zwischen Code, der auf dem Gerät ausgeführt wird, und Code, der das Gerät mithilfe eines Warteschlangensystems verwaltet, das für Feedback mit Spieleentwicklern entwickelt wurde. Es wurde entwickelt, um gut mit Grafik-APIs zusammenzuarbeiten und eine allgegenwärtige Computersprache für den Verbraucherbereich in Anwendungen wie Foto- und Videobearbeitung zu schaffen.

  • 00:05:00 In diesem Abschnitt erläutert der Referent einige der anfänglichen Anwendungen von OpenCL, darunter die Verarbeitung von Bildern oder hochauflösenden Videos und das Ausführen von Virenscannern. Darüber hinaus ist die Technologie nützlich für Systeme mit künstlicher Intelligenz, Modellierungssysteme, Physik, Nachbearbeitung und Beschleunigung der Beleuchtung und des Renderings für Filme. Der Referent hofft, dass unter anderem mehr Arbeiten zur Verwendung von OpenCL für das Rendern in Hollywood zu sehen sind.
 

AMD Developer Central: Folge 1: Was ist OpenCL™?



AMD Developer Central: Folge 1: Was ist OpenCL™?

Dieses Video bietet eine Einführung in OpenCL und seine Designziele, die sich auf die Nutzung verschiedener Prozessoren konzentrieren, um parallele statt sequentielle Berechnungen zu beschleunigen. OpenCL ermöglicht das Schreiben von portablem Code für verschiedene Prozessoren unter Verwendung von Kerneln, globalen und lokalen Dimensionen und Arbeitsgruppen. Arbeitsaufgaben und Arbeitsgruppen können durch gemeinsame Nutzung von Ressourcen zusammenarbeiten, aber eine Synchronisierung zwischen Arbeitsaufgaben in verschiedenen Arbeitsgruppen ist nicht möglich. Die optimalen Problemabmessungen variieren je nach Verarbeitungsart, und es ist wichtig, die besten Abmessungen für die beste Leistung auszuwählen. OpenCL kann die Fähigkeiten eines Systems vollständig nutzen, indem Task- und Datenparallelität zusammen mit dem OpenCL-Ereignismodell ausgedrückt werden.

  • 00:00:00 In diesem Abschnitt erörtert Justin Hensley die Grundlagen von OpenCL und seine Designziele, die sich hauptsächlich auf die Nutzung von CPUs, GPUs oder anderen Prozessoren wie der Cell Broadband Engine oder DSPs konzentrieren, um parallele Berechnungen zu beschleunigen, anstatt sequentielle, was zu dramatischen Beschleunigungen führt. OpenCL ermöglicht das Schreiben von portablem Code, der auf jedem Prozessortyp ausgeführt werden kann, z. B. AMD-CPUs und -GPUs, unter Verwendung von Kerneln, die C-Funktionen ähneln, die zum Ausnutzen von Parallelität verwendet werden, und von Programmen, die Sammlungen von Kerneln und anderen Funktionen sind, wobei Anwendungen Kernel-Instanzen ausführen Warteschlangen, die entweder in der Reihenfolge oder außerhalb der Reihenfolge in die Warteschlange gestellt und ausgeführt werden. Die globalen und lokalen Dimensionen in OpenCL definieren den Berechnungsbereich, während der springende Punkt von OpenCL darin besteht, hochgradig parallele Geräte zu verwenden, um die Berechnung gleichzeitig zu beschleunigen und lokalen Arbeitsgruppen die Zusammenarbeit durch gemeinsame Nutzung von Ressourcen zu ermöglichen, da globale Arbeitselemente unabhängig sein müssen, wobei nur eine Synchronisierung möglich ist innerhalb einer Arbeitsgruppe.

  • 00:05:00 In diesem Abschnitt erfahren wir mehr über Arbeitselemente und Arbeitsgruppen und wie OpenCL es uns ermöglicht, Arbeitselemente innerhalb einer Arbeitsgruppe mithilfe von Barrieren oder Speicherzäunen zu synchronisieren. Arbeitselemente in verschiedenen Arbeitsgruppen können jedoch nicht miteinander synchronisiert werden. Die optimalen Problemdimensionen variieren auch für verschiedene Arten der Verarbeitung, und es ist wichtig, die besten Dimensionen für das gegebene Problem auszuwählen, um die beste Leistung zu erzielen. In OpenCL ist es auch möglich, Aufgabenparallelität auszudrücken, indem ein einzelnes Arbeitselement als Aufgabe unter Verwendung des OpenCL-Ereignismodells ausgeführt wird. Durch die Zusammenarbeit von Aufgaben- und Datenparallelität kann OpenCL die Leistungsfähigkeit des Systems voll ausschöpfen.
12345678910
Neuer Kommentar
Grund der Beschwerde: