OpenGL vs. OpenCL, welches soll man wählen und warum?

78

Welche Funktionen machen OpenCL für die Berechnung gegenüber OpenGL mit GLSL einzigartig? Gibt es trotz der grafischen Terminologie und der unpraktischen Datentypen eine echte Einschränkung für OpenGL?

Zum Beispiel kann eine parallele Funktionsbewertung durchgeführt werden, indem a in eine Textur unter Verwendung anderer Texturen gerendert wird. Das Reduzieren von Operationen kann durch iteratives Rendern auf immer kleinere Texturen erfolgen. Andererseits ist ein zufälliger Schreibzugriff auf keine effiziente Weise möglich (die einzige Möglichkeit besteht darin, Dreiecke durch texturgesteuerte Scheitelpunktdaten zu rendern). Ist das mit OpenCL möglich? Was ist mit OpenGL sonst noch nicht möglich?

Dronus
quelle
1
Eine weitere interessante Frage wäre, ob OpenGL etwas anbieten kann, was OpenCL nicht kann. Beispielsweise interpoliert OpenGL für Sie automatisch Scheitelpunktdaten, die mit dem varyingSchlüsselwort deklariert wurden. Wie würden Sie das entsprechende Ziel in OpenCL erreichen?
HelloGoodbye
Ich denke, dass dies leicht möglich wäre, wenn die Interpolation durch einen Index verwendet würde, der dem Rechenkern für jeden Aufruf gegeben wird.
Dronus
1
Wir haben 2015 immer noch keinen zuverlässigen Zugriff auf OpenCL auf allen Plattformen und sind immer noch gespannt, welche Rechenqualität mit OpenCL erreicht werden kann, nicht jedoch mit OpenGL2.0.
Dronus
1) OpenCL-Gerät kann eine CPU ohne GPus sein und funktioniert immer noch, wenn das Rendern von Grafiken überhaupt fehlschlägt.
Xakepp35
2) Überlegen Sie, welcher Stack dünner ist, z. B. auf einem Barebone-Linux-Kernel? OpenCL, für das nur einfache Dinge wie der Treiber amdgpu-pro erforderlich sind, der mit allen erforderlichen Bibliotheken geliefert wird (ich habe die OpenCL Miner-Firmware mit nur 50 MB Footprint erstellt). Oder Renderer (150 + mb), der mehr Chaos, mehrere schwere Frameworks, Xorgs usw. erfordert, und Dinge wie in mesa3d / gallium und so weiter. Wofür ist das alles? Wenn Ihre Aufgabe nur das Rechnen ist und Sie keinen laufenden x-Server und sogar keinen angeschlossenen Monitor haben. Im Grunde genommen ist GL also mehr "Junk-überladen" als CL, um alles zu unterstützen, was seit Jahren entwickelt wurde.
Xakepp35

Antworten:

62

OpenCL wurde speziell für die Datenverarbeitung erstellt. Wenn Sie mit OpenGL wissenschaftliches Rechnen durchführen, müssen Sie immer darüber nachdenken, wie Sie Ihr Rechenproblem dem Grafikkontext zuordnen können (dh in Form von Texturen und geometrischen Grundelementen wie Dreiecken usw. sprechen), um Ihre Berechnung in Gang zu bringen.

In OpenCL formulieren Sie Ihre Berechnung einfach mit einem Berechnungskern in einem Speicherpuffer und los geht's. Dies ist tatsächlich ein GROSSER Gewinn (aus der Perspektive, beide Varianten durchdacht und implementiert zu haben).

Die Speicherzugriffsmuster sind jedoch dieselben (Ihre Berechnung findet immer noch auf einer GPU statt - aber GPUs werden heutzutage immer flexibler).

Aber was würden Sie sonst erwarten, als mehr als ein Dutzend parallele "CPUs" zu verwenden, ohne sich den Kopf über die Übersetzung zu brechen - z. B. (dummes Beispiel) Fourier in Dreiecke und Quads ...?

cli_hlt
quelle
1
Fourier zu Dreiecken und Quads ... nun, mit einem einfachen Gerüst zum Rendern eines großen Quad auf einer Textur haben wir nur eine einfache parallele Zuordnung eines oder mehrerer großer Speicherblöcke zu einem anderen. Mit Texturen unterschiedlichen Maßstabs ist es auch einfach, eine andere Menge (normalerweise 2 ^ n) von Werten auf eine andere abzubilden. Das ist nicht zu viel GL-Code und passt zu einem großen Bereich von Problemen. Also ich möchte wissen, was OpenCL mehr kann ...
Dronus
2
Wenn Sie OpenCL verwenden, lassen Sie das Mapping einfach ganz weg, vermeiden das Schreiben der Shader, die sich mit Geometrie und Fragmenten befassen sollen, vermeiden das Nachdenken über die verschiedenen Transformationen von Koordinaten (Welt, Bildschirm / Puffer, Textur) und drücken Ihren Algorithmus direkt aus, wie Sie es in Ihrem gelernt haben numerische Klasse. Ich hatte kein Problem mit dem ersten, aber ich mag das letztere mehr. Und nun, ich hatte überhaupt keine Idee zu OpenCL - aber wie jemand anderes, warum sollte es nicht für den beabsichtigten Gebrauch verwendet werden? GPGPU war vorerst cool, jetzt benutze einfach OpenCL.
Cli_hlt
7
@cli_hlt, OpenCL ist auch GPGPU.
Simon
@ Simon Im weitesten Sinne ja, Sie haben Recht. Laut Wikipedia ist "Allzweck-Computing auf Grafikprozessoren (GPGPU, selten GPGP oder GP²U) die Verwendung einer Grafikverarbeitungseinheit (GPU), die normalerweise nur die Berechnung für Computergrafiken übernimmt, um Berechnungen in Anwendungen durchzuführen, die traditionell verarbeitet werden von der Zentraleinheit (CPU) "(sie haben zusätzliche Referenzen, die ich jetzt weglasse). Mit OpenCL wird der ganze Punkt "der normalerweise nur für Computergrafiken berechnet" nicht mehr angegeben. Es ist also keine GPGPU in der ursprünglichen Bedeutung.
Cli_hlt
@cli_hlt: Vielleicht, aber die Geräte sind immer noch hauptsächlich für Computergrafiken gedacht. Immerhin heißen sie immer noch GPUs!
Tim am
53

Etwas, das bisher in keiner Antwort erwähnt wurde, war die Geschwindigkeit der Ausführung. Wenn Ihr Algorithmus in OpenGL-Grafiken ausgedrückt werden kann (z. B. keine verstreuten Schreibvorgänge, kein lokaler Speicher, keine Arbeitsgruppen usw.), wird er sehr oft schneller ausgeführt als ein OpenCL-Gegenstück. Meine spezifische Erfahrung damit war das Erstellen von Kerneln zum Filtern (Sammeln) von AMD-, nVidia-, IMG- und Qualcomm-GPUs. Die OpenGL-Implementierungen werden auch nach der Hardcore-OpenCL-Kerneloptimierung immer schneller ausgeführt. (Abgesehen davon: Ich vermute, dass dies darauf zurückzuführen ist, dass jahrelange Hardware und Treiber speziell auf grafikorientierte Workloads abgestimmt wurden.)

Mein Rat wäre, wenn Ihr Rechenprogramm sich gut auf die Grafikdomäne abbildet, dann verwenden Sie OpenGL. Wenn nicht, ist OpenCL allgemeiner und einfacher, Rechenprobleme auszudrücken.

Ein weiterer Punkt, den Sie erwähnen (oder fragen) sollten, ist, ob Sie als Hobbyist (dh für sich selbst) oder kommerziell (dh zur Weitergabe an andere) schreiben. Während OpenGL fast überall unterstützt wird, fehlt OpenCL auf Mobilgeräten völlig die Unterstützung, und es ist sehr unwahrscheinlich, dass es in den nächsten Jahren auf Android oder iOS erscheint. Wenn eine breite plattformübergreifende Kompatibilität von einer einzelnen Codebasis aus ein Ziel ist, kann OpenGL Ihnen aufgezwungen werden.

user2746401
quelle
Ich denke, diese Antwort braucht wirklich mehr Upvotes, um früher in diesem Thread zu erscheinen. Leistungsaspekte und Kompatibilität mit Mobilgeräten sollten wichtige Aspekte sein, die zuerst berücksichtigt werden müssen ... zumindest die Leistungsaspekte, falls Sie kein Interesse an Mobilgeräten haben (aber wie können Sie es heute nicht oder eher, wie können Sie es sich leisten, dies nicht zu tun? : p)
Kriegsschiff
Wie kann OpenGL schneller sein als OpenCL? Es macht viel mehr und der Aufwand für die Verwaltung des OpenGL-Status ist hoch. Haben Sie OpenCL mit native_ * -Funktionen verglichen? Welche Art von Operationen haben Sie verglichen? Können Sie den Code veröffentlichen?
Yoav
2
Hallo Ben-Uri. Leider kann ich keinen Code teilen. Sie haben Recht damit, dass der GL-Status ziemlich schwer ist, aber gut geschriebener GL-Code kann Statusänderungen meistens vermeiden, insbesondere bei rechnerähnlichen Aufgaben (Vulkan ist in dieser Hinsicht übrigens viel besser). Einzelne Operationen sind zwischen GL / CL in der Regel ungefähr gleich, aber die GLSL-Compiler scheinen ausgereifter zu sein und erzeugen insgesamt engeren Code. Für strukturierte Schreibvorgänge können GL-Pixel-Shader die Render-Ausgabeeinheiten (ROPs) verwenden, während CL das generische Speichersubsystem (langsamer) verwenden muss, da es (normalerweise) zur Kompilierungszeit nicht bekannt ist, ob die Schreibvorgänge strukturiert werden.
user2746401
27

Welche Funktionen machen OpenCL für die Berechnung gegenüber OpenGL mit GLSL einzigartig? Gibt es trotz der grafischen Terminologie und der unpraktischen Datentypen eine echte Einschränkung für OpenGL?

Ja, es ist eine Grafik-API. Daher muss alles, was Sie darin tun, unter diesen Bedingungen formuliert werden. Sie müssen Ihre Daten als eine Art "Rendering" verpacken. Sie müssen herausfinden, wie Sie mit Ihren Daten in Bezug auf Attribute, einheitliche Puffer und Texturen umgehen.

Mit OpenGL 4.3 und OpenGL ES 3.1 Compute Shadern werden die Dinge etwas durcheinander. Ein Compute-Shader kann über SSBOs / Image Load / Store auf ähnliche Weise wie OpenCL-Rechenoperationen auf den Speicher zugreifen (obwohl OpenCL tatsächliche Zeiger bietet, GLSL jedoch nicht). Ihr Interop mit OpenGL ist auch viel schneller als das OpenCL / GL-Interop.

Trotzdem ändern Compute-Shader nichts an einer Tatsache: OpenCL-Compute-Operationen arbeiten mit einer ganz anderen Genauigkeit als die Compute-Shader von OpenGL. Die Gleitkomma-Präzisionsanforderungen von GLSL sind nicht sehr streng, und die von OpenGL ES sind noch weniger streng. Wenn also die Gleitkomma-Genauigkeit für Ihre Berechnungen wichtig ist, ist OpenGL nicht die effektivste Methode, um das zu berechnen, was Sie zur Berechnung benötigen.

Außerdem erfordern OpenGL-Compute-Shader 4.x-fähige Hardware, während OpenCL auf viel minderwertigerer Hardware ausgeführt werden kann.

Wenn Sie durch Kooptieren der Rendering-Pipeline rechnen, gehen OpenGL-Treiber weiterhin davon aus, dass Sie rendern. Auf dieser Grundlage werden Optimierungsentscheidungen getroffen. Dadurch wird die Zuweisung von Shader-Ressourcen optimiert, sofern Sie ein Bild zeichnen.

Wenn Sie beispielsweise in einen Gleitkomma-Framebuffer rendern, entscheidet sich der Treiber möglicherweise nur für einen R11_G11_B10-Framebuffer, da er erkennt, dass Sie mit dem Alpha nichts tun und Ihr Algorithmus die geringere Genauigkeit tolerieren kann. Wenn Sie jedoch das Laden / Speichern von Bildern anstelle eines Framebuffers verwenden, ist die Wahrscheinlichkeit, dass dieser Effekt auftritt, sehr viel geringer.

OpenCL ist keine Grafik-API. Es ist eine Berechnungs-API.

Außerdem bietet OpenCL nur Zugriff auf weitere Inhalte. Sie erhalten Zugriff auf Speicherebenen, die in Bezug auf den GL implizit sind. Bestimmter Speicher kann von Threads gemeinsam genutzt werden, aber separate Shader-Instanzen in GL können sich nicht direkt gegenseitig beeinflussen (außerhalb von Image Load / Store, OpenCL wird jedoch auf Hardware ausgeführt, die keinen Zugriff darauf hat).

OpenGL verbirgt, was die Hardware hinter einer Abstraktion tut. OpenCL setzt Sie fast genau dem aus, was gerade passiert.

Sie können OpenGL verwenden, um beliebige Berechnungen durchzuführen. Aber Sie müssen nicht wollen zu; nicht, solange es eine absolut praktikable Alternative gibt. Compute in OpenGL wird für die Wartung der Grafikpipeline verwendet.

Der einzige Grund, OpenGL für jede Art von Nicht-Rendering-Rechenoperation auszuwählen, ist die Unterstützung von Hardware, auf der OpenCL nicht ausgeführt werden kann. Gegenwärtig umfasst dies viel mobile Hardware.

Nicol Bolas
quelle
6
'OpenGL verbirgt, was die Hardware hinter einer Abstraktion tut. OpenCL setzt Sie fast genau dem aus, was gerade passiert. ' ist immer noch auf einer abstrakten Ebene, denke ich. Die GPUs verfügen über feste Module (wie "Render Output Units" und "Texture Mapping Units"), die in OpenGL-Funktionen ausgedrückt werden.
Dronus
1
@ybungalobill Gemäß der Beschreibung von glTexImage2D"wählt der GL eine interne Darstellung, die der von internalFormat angeforderten sehr nahe kommt, aber möglicherweise nicht genau übereinstimmt".
GuyRT
1
@GuyRT: Es normalerweise tut Ihnen 32F für 32F --- die typische Veränderung ist eine andere Reihenfolge der Kanäle, obwohl (zB BGRA statt RGBA).
Tim am
Bezieht sich diese Antwort auf "OpenGL / GSLS" oder nur auf OpenGL?
Wotanii
1
@wotanii: GLSL ist die von OpenGL verwendete Schattierungssprache. Es gibt also kein "nur OpenGL".
Nicol Bolas
12

Ein bemerkenswertes Merkmal wären verstreute Schreibvorgänge, ein anderes wäre das Fehlen von "Windows 7-Intelligenz". Wie Sie wahrscheinlich wissen, wird Windows 7 den Anzeigetreiber beenden, wenn OpenGL etwa 2 Sekunden lang nicht leert (nageln Sie mich nicht auf die genaue Zeit fest, aber ich denke, es sind 2 Sekunden). Dies kann ärgerlich sein, wenn Sie eine längere Operation haben.

Außerdem funktioniert OpenCL offensichtlich mit einer viel größeren Vielfalt an Hardware als nur der Grafikkarte, und es gibt keine starre grafikorientierte Pipeline mit "künstlichen Einschränkungen". Es ist einfacher (trivial), auch mehrere Befehlsströme gleichzeitig auszuführen.

Damon
quelle
+1 für die Erwähnung der Streuung, obwohl die jüngsten Erweiterungen (wie shader_image_load_store) daran arbeiten, oder Sie können den Geometrie-Shader verwenden, um zusätzliche Punkte zu generieren oder verschiedene Ausgabeziele auszuwählen. Aber nichts im Vergleich zur Flexibilität von OpenCL.
Christian Rau
Die Sache ist, dass Sie überhaupt nicht wissen, was passiert, weil alles im Wesentlichen vom Fahrer abhängig ist. Natürlich können Sie z. B. einen zufälligen Speicherzugriff durchführen, wenn die Implementierung dies zulässt. Was wäre jedoch der Vorteil, wenn sich herausstellt, dass der Treiber auf diese Weise nur Ihre gesamte Berechnung auf den Host überträgt, anstatt auf die Hardware, auf der Ihr Code ausgeführt werden soll ...
cli_hlt
2
@cli_hlt: Sie können vorher entscheiden, auf welchem ​​Gerät Ihre Task-Warteschlangen (und damit Kernel) ausgeführt werden sollen. Die Implementierung hat keine Möglichkeit, später etwas anderes zu entscheiden. Außerdem sind Funktionen wie gestreute Schreibvorgänge oder lokaler Speicher nichts "Besonderes", das die Hardware unterstützt oder nicht unterstützt. Es ist nur so, dass unter OpenGL dieselbe Hardware es nicht verfügbar macht, da OpenGL eine Grafikpipeline implementiert. Daher ist es einfach nicht sinnvoll , das Schreiben in den lokalen Speicher in einem Pixel-Shader zu unterstützen (und "historische" Hardware könnte dies tatsächlich nicht tun). Unter OpenCL ist dies sinnvoll und zulässig.
Damon
2
("es macht einfach keinen Sinn" mag eine etwas zu harte Formulierung sein, aber Sie verstehen, was ich meine. Es ist nicht das, was Sie normalerweise für Grafiken wollen, und es ist nicht das, was GPUs beispielsweise vor einem Jahrzehnt tun konnten. OpenGL implementiert einen Dienst "Vertices und Konnektivitätsinformationen in Image umwandeln". OpenCL implementiert einen "Crunch Arbitrary Data in einige andere Daten" -Dienst.)
Damon
1
Sie wissen, dass das Betriebssystem auch den Treiber tötet, wenn OpenCL eine lange Berechnung auf der GPU durchführt?
Tara
11

Obwohl derzeit OpenGL die bessere Wahl für Grafiken ist, ist dies nicht dauerhaft.

Es könnte für OpenGL praktisch sein, sich schließlich als Erweiterung von OpenCL zusammenzuschließen. Die beiden Plattformen sind zu etwa 80% gleich, haben jedoch unterschiedliche Syntaxmerkmale und unterschiedliche Nomenklaturen für ungefähr dieselben Hardwarekomponenten. Das bedeutet, zwei Sprachen zu lernen, zwei APIs herauszufinden. Entwickler von Grafiktreibern würden eine Zusammenführung vorziehen, da sie nicht mehr für zwei separate Plattformen entwickeln müssten. Dadurch bleibt mehr Zeit und Ressourcen für das Debuggen von Treibern. ;)

Eine andere zu berücksichtigende Sache ist, dass die Ursprünge von OpenGL und OpenCL unterschiedlich sind: OpenGL begann und gewann an Dynamik in den frühen Tagen der festen Pipeline über ein Netzwerk und wurde im Zuge der technologischen Entwicklung langsam angehängt und veraltet. OpenCL ist in gewisser Weise eine Weiterentwicklung von OpenGL in dem Sinne, dass OpenGL für die numerische Verarbeitung verwendet wurde, da die (ungeplante) Flexibilität von GPUs dies zuließ. "Graphics vs. Computing" ist eigentlich eher ein semantisches Argument. In beiden Fällen versuchen Sie immer, Ihre mathematischen Operationen der Hardware mit der höchstmöglichen Leistung zuzuordnen. Es gibt Teile der GPU-Hardware, die Vanilla CL nicht verwendet, die jedoch keine separate Erweiterung davon abhalten.

Wie könnte OpenGL unter CL funktionieren? Spekulativ könnten Dreiecksrasterer als spezielle CL-Aufgabe in die Warteschlange gestellt werden. Spezielle GLSL-Funktionen könnten in Vanilla OpenCL implementiert und dann vom Treiber während der Kernel-Kompilierung auf hardwarebeschleunigte Anweisungen überschrieben werden. Das Schreiben eines Shaders in OpenCL, bis die Bibliothekserweiterungen bereitgestellt wurden, klingt überhaupt nicht nach einer schmerzhaften Erfahrung.

Es macht wenig Sinn, einen anzurufen, um mehr Funktionen als den anderen zu haben, da beide zu 80% dieselben Funktionen erhalten, nur unter unterschiedlicher Nomenklatur. Zu behaupten , dass OpenCL ist nicht gut für Grafiken , da es für die Berechnung ausgelegt ist nicht sinnvoll , da Grafikverarbeitung wird die Berechnung.

user515655
quelle
6

Ein weiterer wichtiger Grund ist, dass OpenGL \ GLSL nur auf Grafikkarten unterstützt wird. Obwohl die Multi-Core-Nutzung mit der Verwendung von Grafikhardware begann, arbeiten viele Hardwareanbieter an einer Multi-Core-Hardwareplattform, die für die Berechnung vorgesehen ist. Zum Beispiel siehe Intels Knights Corner.

Wenn Sie Code für die Berechnung mit OpenGL \ GLSL entwickeln, können Sie keine Hardware verwenden, die keine Grafikkarte ist.

Tal Darom
quelle
Ich denke, OpenCL wird auch verhindern, dass mein Code auf Hardware, die heute keine Grafikkarte ist, effizient ausgeführt wird. Weil die günstige parallele Berechnung in OpenCL gut für die GPU geeignet ist, aber auf heutigen Vanilla-CPUs ziemlich ineffizient ist.
Dronus
4

Ab OpenGL 4.5 sind dies die Funktionen, die OpenCL 2.0 hat, die OpenGL 4.5 nicht bietet (soweit ich das beurteilen kann) (dies gilt nicht für die Funktionen von OpenGL, die OpenCL nicht bietet):

Veranstaltungen

Bessere Atomik

Blöcke

Arbeitsgruppenfunktionen: work_group_all und work_group_any work_group_broadcast: work_group_reduce work_group_inclusive / exklusiver_scan

Den Kernel vom Kernel in die Warteschlange stellen

Zeiger (obwohl dies wahrscheinlich keine Rolle spielt, wenn Sie auf der GPU ausführen)

Einige mathematische Funktionen, die OpenGL nicht hat (obwohl Sie sie selbst in OpenGL erstellen könnten)

Freigegebener virtueller Speicher

(Mehr) Compileroptionen für Kernel

Einfache Auswahl einer bestimmten GPU (oder auf andere Weise)

Kann auf der CPU ausgeführt werden, wenn keine GPU vorhanden ist

Mehr Unterstützung für diese Nischen-Hardwareplattformen (z. B. FGPAs)

Auf einigen (allen?) Plattformen benötigen Sie kein Fenster (und dessen Kontextbindung), um Berechnungen durchzuführen.

OpenCL ermöglicht nur ein wenig mehr Kontrolle über die Genauigkeit von Berechnungen (einschließlich einiger über diese Compileroptionen).

Viele der oben genannten Punkte dienen hauptsächlich der besseren Interaktion zwischen CPU und GPU: Ereignisse, gemeinsam genutzter virtueller Speicher, Zeiger (obwohl diese möglicherweise auch anderen Dingen zugute kommen könnten).

OpenGL hat die Möglichkeit erhalten, Dinge in verschiedene Bereiche des Client- und Serverspeichers zu sortieren, da viele der anderen Beiträge hier verfasst wurden. OpenGL bietet jetzt eine bessere Speicherbarriere und Atomics-Unterstützung und ermöglicht es Ihnen, Dinge verschiedenen Registern innerhalb der GPU zuzuordnen (in etwa gleichem Maße, wie OpenCL dies kann). Beispielsweise können Sie Register in der lokalen Rechengruppe jetzt in OpenGL freigeben (unter Verwendung der AMD-GPUs LDS (Local Data Share) (obwohl diese spezielle Funktion derzeit nur mit OpenGL-Compute-Shadern funktioniert). OpenGL verfügt über leistungsfähigere Implementierungen Einige Plattformen (wie Open Source Linux-Treiber). OpenGL hat Zugriff auf Hardware mit fester Funktion (wie andere Antworten bereits sagten). Zwar kann Hardware mit fester Funktion manchmal vermieden werden (z. B. verwendet Crytek eine "Software"). Implementierung eines Tiefenpuffers) Hardware mit fester Funktion kann den Speicher einwandfrei verwalten (und normalerweise viel besser als jemand, der nicht für ein GPU-Hardwareunternehmen arbeitet) und ist in den meisten Fällen einfach überlegen. Ich muss zugeben, dass OpenCL eine ziemlich gute Texturunterstützung für feste Funktionen bietet, die einer der wichtigsten Bereiche für feste Funktionen von OpenGL ist.

Ich würde argumentieren, dass Intels Knights Corner eine x86-GPU ist, die sich selbst steuert. Ich würde auch argumentieren, dass OpenCL 2.0 mit seinen Texturfunktionen (die tatsächlich in kleineren Versionen von OpenCL enthalten sind) in etwa dem vom Benutzer 2746401 vorgeschlagenen Leistungsgrad verwendet werden kann.

afree100
quelle
3

OpenCL (in Version 2.0) beschreibt eine heterogene Rechenumgebung, in der jede Systemkomponente Aufgaben erzeugen und verbrauchen kann, die von anderen Systemkomponenten generiert werden. Es werden keine CPU-, GPU- (usw.) Begriffe mehr benötigt - Sie haben nur noch Host & Device (s).

OpenGL hingegen hat eine strikte Aufteilung in CPU, Task Task Producer, und GPU, Task Task Consumer. Das ist nicht schlecht, denn weniger Flexibilität sorgt für mehr Leistung. OpenGL ist nur ein Instrument mit engerem Anwendungsbereich.

Roman Arzumanyan
quelle
2

Zusätzlich zu den bereits vorhandenen Antworten passt OpenCL / CUDA nicht nur mehr in die Berechnungsdomäne, sondern abstrahiert auch die zugrunde liegende Hardware nicht zu sehr. Auf diese Weise können Sie direkter von Dingen wie Shared Memory oder Coalesced Memory Access profitieren, die sonst in der tatsächlichen Implementierung des Shaders vergraben wären (der selbst nichts anderes als ein spezieller OpenCL / CUDA-Kernel ist, wenn Sie möchten).

Um von solchen Dingen zu profitieren, müssen Sie sich auch der spezifischen Hardware bewusst sein, auf der Ihr Kernel ausgeführt wird, aber versuchen Sie nicht, diese Dinge mithilfe eines Shaders explizit zu berücksichtigen (wenn dies überhaupt möglich ist).

Wenn Sie etwas Komplexeres als einfache BLAS-Routinen der Stufe 1 ausführen, werden Sie sicherlich die Flexibilität und Großzügigkeit von OpenCL / CUDA zu schätzen wissen.

Christian Rau
quelle
1
Ich bin mir nicht sicher über 'aber abstrahiert auch nicht die zugrunde liegende Hardware zu sehr'. Es scheint, dass OpenCL tatsächlich Teile der Hardware, zum Beispiel Rasterisierungseinheiten, völlig ignorieren würde.
Dronus
@dronus Nun ja, es ignoriert die Teile mit fester Funktion. Auf der anderen Seite abstrahieren Shader die Vielkernigkeit der Hardware und solche Dinge wie die verschiedenen Speichertypen und optimierten Speicherzugriffe.
Christian Rau
1
Die Rasterung ermöglicht sogar einen zufälligen Speicherzugriff (auf "dreieckig verbundene" Bereiche ...) mit einem garantierten Ergebnis (Fragmente überschrieben, geordnet nach z-Tiefe). Wenn man in Kerneln und Speicherströmen denkt, würde die Emulation eines solchen Verhaltens einen wahlfreien Zugriff mit genau definierten geordneten Mutexen zwischen allen parallelen Threads oder etwas anderem bedeuten. Was ist ein verwendbares OpenCL-Ideom für einen solchen parallelen Direktzugriff?
Dronus
2

Die "Funktion", mit der OpenCL für allgemeine Berechnungen entwickelt wurde, während OpenGL für Grafiken vorgesehen ist. Sie können alles in GL tun (es ist Turing-vollständig), aber dann fahren Sie mit dem Griff des Schraubendrehers als Hammer in einen Nagel.

OpenCL kann nicht nur auf GPUs ausgeführt werden, sondern auch auf CPUs und verschiedenen dedizierten Beschleunigern.

Basil Marte
quelle