OpenCL

Ein OpenCL-System besteht aus einem Host und einem oder mehreren OpenCL-Geräten. Ein Gerät besteht aus einer oder mehreren unabhängigen Recheneinheiten (englisch „compute unit“, kurz „CU“). Dies sind bei einem Mehrkernprozessor die verfügbaren Kerne, die zusammengefasst die Central Processing Unit ergeben, und für die Grafikkarte die Shader. Die Compute Unit ist in ein oder mehrere ausführende Elemente (englisch „processing element“, kurz „PE“) unterteilt. Der Host verteilt dabei die Kernel (Programme, dt. Kerne) zur Laufzeit auf die verfügbaren Geräte.

Es gibt zwei Arten von Kernel:

OpenCL-Kernel

Diese sind in der Programmiersprache OpenCL C geschrieben. OpenCL C basiert auf ISO C99 und wurde um Funktionen und Datentypen zur parallelen Verarbeitung erweitert.

Native Kernel

Diese Kernel sind optional und implementierungsspezifisch.

Die OpenCL-Kernel werden zur Laufzeit vom OpenCL-Compiler übersetzt und danach von einem OpenCL-Gerät ausgeführt. Hierdurch braucht zur Entwicklungszeit nicht bekannt zu sein, auf welcher Hardware das Programm später ausgeführt wird.

Die Berechnungen werden zur Laufzeit von den sogenannten Work-Items durchgeführt. Diese Work-Items werden zu einem ein-, zwei- oder dreidimensionalen Gitter angeordnet, über das die Work-Items adressiert werden können. Work-Items werden zu Work-Groups gruppiert, in denen eine Synchronisation möglich ist und die auf einen gemeinsamen Speicher zugreifen können. Ein einzelnes Work-Item kann also absolut, durch seine Koordinate und relativ, durch die Koordinate der es enthaltenden Work-Group und die Koordinate innerhalb der Work-Group angesprochen werden.

Speichermodell

In OpenCL werden fünf Arten von Speicher unterschieden:

• Hostspeicher (host memory): Beim Hostspeicher handelt es sich um den regulären Arbeitsspeicher des Leitprogramms. Ein OpenCL-Kernel kann darauf nicht direkt zugreifen.
• globaler Speicher (global memory): Hierbei handelt es sich um den Arbeitsspeicher der OpenCL-Kernel. Jede Instanz eines Kernels hat auf den gesamten Bereich wahlfreien Zugriff.
• konstanter Speicher (constant memory): Der konstante Speicher unterscheidet sich vom globalen Speicher darin, dass die Kernelinstanzen diesen Speicher ausschließlich lesen, aber nicht verändern können.
• lokaler Speicher (local memory): Eine Gruppe von Kernelinstanzen hat wahlfreien Zugriff auf einen kleinen Bereich von typischerweise 16 kiB lokalen Speicher. Jede Gruppe hat ihren eigenen Bereich, auf den jeweils nur die Mitglieder zugreifen können.
• privater Speicher (private memory): Dieser Speicher ist einer Kernelinstanz vorbehalten. Andere Kernelinstanzen und das Leitprogramm können nicht auf den Inhalt dieses Speichers zugreifen.

Die Sprache OpenCL C basiert auf der Syntax von ISO C99, erweitert um zusätzliche Datentypen und Funktionen zur parallelen Verarbeitung, wurde an anderer Stelle aber auch eingeschränkt (siehe unten). Es handelt sich somit nicht um eine Obermenge von C, dennoch haben beide Sprachen viele Gemeinsamkeiten.

Ergänzend zu den C99-Datentypen unterstützt OpenCL C folgende Datentypen:

• half: 16 Bit Gleitkommazahlen nach IEEE 754r.
• Vektordatentypen: Die Datentypen char, uchar, short, ushort, int, uint, long, ulong und float gibt es als Vektoren mit 2, 4, 8 und 16 Elementen. Die Elementanzahl wird hierbei an den Namen der Datentypen angehängt, also z. B.: uchar4, float8 oder int16. Mit OpenCL 1.1 wurden zusätzlich drei-elementige Vektoren eingeführt.
• image2d_t: Ein zweidimensionales Bild.
• image3d_t: Ein dreidimensionales Bild.
• sampler_t: Ein sampler, der definiert, wie ein Bild abgetastet wird.
• event_t: Ein Ereignisbehandler.

Folgende Datentypen wurden zudem für spätere Versionen von OpenCL reserviert:

• booln: Ein Vektor mit Wahrheitswerten.
• double, doublen: 64-Bit-Gleitkommazahlen und -vektoren. Eine Erweiterung für double existiert bereits, deren Unterstützung ist aber bei OpenCL 1.0 nicht erforderlich.
• halfn: Ein Vektor mit 16-Bit-Gleitkommazahlen.
• quad, quadn: 128-Bit-Gleitkommazahlen.
• complex {half | float | double | quad}: Komplexe Zahlen mit unterschiedlicher Genauigkeit.
• complex {half | float | double | quad}n: Vektoren komplexer Zahlen mit unterschiedlicher Genauigkeit.
• imaginary {half | float | double | quad}: Imaginäre Zahlen mit unterschiedlicher Genauigkeit.
• imaginary {half | float | double | quad}n: Vektoren imaginärer Zahlen mit unterschiedlicher Genauigkeit.
• {float | double}nxm: nxm Matrizen mit 32 oder 64 Bit Genauigkeit.
• long double, long doublen: Gleitkommazahlen und -vektoren mit mindestens der Genauigkeit von double und maximal der Genauigkeit von quad.
• long long, long longn: Vorzeichenbehaftete 128-Bit-Ganzzahlen und -vektoren.
• unsigned long long, unsigned long longn: Vorzeichenlose 128-Bit-Ganzzahlen und -vektoren.

Arithmetische Operationen (+, -, *, /, %, ++, --), Vergleichsoperationen (>, >=, ==, !=, <= <), Bitoperatoren (&, |, ^, ~) sowie logische Operatoren (&&, ||) sind sowohl für skalare Datentypen definiert als auch für Vektoren. Werden sie auf Vektoren angewendet, so wird die Operation komponentenweise durchgeführt. Hier verhält sich OpenCL analog zu bekannten Shadersprachen wie zum Beispiel GLSL.

Ebenfalls den Shader-Sprachen entlehnt sind eine Reihe mathematischer Funktionen, die ebenfalls komponentenweise durchgeführt werden, beispielsweise Sinus, Cosinus, Wurzel, Minimum, Maximum etc.

Gegenüber C ist OpenCL C unter anderem in folgenden Punkten eingeschränkt:

• Es gibt keine Funktionszeiger
• Rekursion ist nicht möglich.
• Felder („arrays“) dürfen keine variable Länge haben.

OpenCL kann direkt auf Objekte von OpenGL oder DirectX (nur unter Windows) zugreifen, etwa auf Texturen. Somit kann OpenCL genutzt werden, um beispielsweise Texturen zu ändern, ohne die Daten umkopieren zu müssen.

Wie OpenGL kann auch OpenCL durch herstellerspezifische Erweiterungen um zusätzliche Funktionen ergänzt werden. Beispiele für bereits definierte Erweiterungen sind:

• Gleitkommazahlen mit doppelter Genauigkeit (64-Bit-Gleitkommazahlen, cl_khr_fp64).
• Vektoren von Gleitkommazahlen mit halber Genauigkeit (16-Bit-Gleitkommazahlen, cl_khr_fp16).
• Die Art des Rundens bei Gleitkommaoperationen zu definieren (cl_khr_select_fprounding_mode).
• Schreiben in 3D-Bilder (cl_khr_3d_image_writes).

OpenCL wurde ursprünglich von der Firma Apple entwickelt.

In Zusammenarbeit mit den Firmen AMD, IBM, Intel und Nvidia wurde der erste Entwurf ausgearbeitet und schließlich von Apple bei der Khronos Group zur Standardisierung eingereicht.^[2] Die Spezifikation für OpenCL 1.0 wurde am 8. Dezember 2008 veröffentlicht.^[3][4] Es folgte 1.1 im Juni 2010.^[5][6] Am 16. November 2011 folgte die Spezifikation 1.2 mit Verbesserungen, die zu 1.0 abwärtskompatibel bleibt.^[7][8] Zwei Jahre später, am 18. November 2013, wurde dann die OpenCL-2.0-Spezifikation eingeführt.^[9][10]

OpenCL 1.0 wurde erstmals am 28. August 2009 von Apple mit dem Betriebssystem Mac OS X Snow Leopard 10.6 auf den Markt gebracht, die dazugehörigen Programme („Kernel“) können zur Laufzeit auf verschiedene vorhandene OpenCL-fähige Geräte verteilt werden. Derzeit wird abhängig von der Hardware nur OpenCL 1.0 bis 1.2 von Apple unterstützt.^[11][12] Weiterer Hauptunterstützer ist AMD mit vorherigem AtiStream in Konkurrenz zu NVidia mit CUDA.^[13] Trotz seiner primären Unterstützung von CUDA unterstützt Nvidia wegen der Nachfrage der Nutzer auch OpenCL 1.2, später mit einigen Elementen aus 2.0 und nun 2021 auch 3.0.^[14]

Mit OpenCL 2.0 kompatible Hardware unterstützt mit aktualisierten Treibern auch die höheren Versionen 2.1 und 2.2 laut Khronos-Group.^[15]

OpenCL 2.1 wurde im November 2015 offiziell freigegeben.^[16] Eine entscheidende Neuerung in OpenCL 2.1 ist die Integration von SPIR-V, dem SPIR-Nachfolger (Standard Portable Intermediate Representation). SPIR-V ist eine Zwischensprache mit nativer Unterstützung für Grafik-Shader und Prozessor-Kernels. Sie ermöglicht die Aufteilung der Compiler-Kette auf die unterschiedlichen Recheneinheiten. Somit können High-Level-Sprachen über SPIR-V die heterogene Architektur ansprechen, ohne sich selbst um die Übersetzung auf die unterschiedlichen Hardware-Komponenten zu kümmern. SPIR-V wird außer in OpenCL auch in der Vulkan-Grafik-API genutzt.^[17][18]

OpenCL 2.2 wurde offiziell freigegeben im Mai 2017.^[19][20] Als wichtigste Änderung nennt die Bekanntmachung die Integration der OpenCL C++ Kernel Language in OpenCL, was unter anderem beim Schreiben parallel arbeitender Programme helfen soll. Die im Rahmen der Open Computing Language als statische Untermenge des C++14-Standards definierte Kernel-Sprache enthält Klassen, Templates, Lambda-Ausdrücke und andere Konstrukte. Im Mai 2018 erschien ein „maintenance update“ mit Fehlerkorrekturen und Aktualisierungen in den Headern von Spir-V.^[21][22][23]

In Zukunft soll OpenCL mit Vulkan so weit wie möglich verschmelzen und so noch breitere Unterstützung gewinnen.^[24][25] Dies wurde mit dem Premiere Rush von Apple gezeigt, der den Open Source Compiler clspv^[26] benutzt, um einen großen Teil des OpenCL C Kernel Codes für eine Vulkan-Umgebung auf Android-Geräten zu kompilieren.^[27] Zuletzt wurde nun OpenCL Next für 2019 angekündigt mit neuen Informationen und dabei auch betont, dass die „roadmap“ von OpenCL von der von Vulkan unabhängig ist, also beide Projekte nicht völlig fusionieren werden.^[28]

Am 27. April 2020 wurde OpenCL 3.0 (provisional) veröffentlicht.^[29] Der Status Final wurde am 30. September 2020 erreicht.^[30][31]

Auf der IWOCL 2021 wurde Version 3.0.7 mit einigen optionalen Erweiterungen angekündigt.^[32]

OpenCL kann für beliebige Betriebssysteme und Hardwareplattformen – genau wie OpenGL und OpenAL – implementiert werden. So ist in der Spezifikation von CPUs, GPUs, DSPs und dem Cell-Prozessor die Rede. Es existiert zudem eine Spezifikation für eingebettete Systeme mit reduzierten Anforderungen.

Aktuelle Implementierungen, in der Regel Open Source (mit Ausnahme von Nvidia):

• AMD ROCm: Im Rahmen der Initiative OpenCompute hat AMD in Zusammenarbeit mit der Open-Source-Gemeinschaft das Projekt ROCm gestartet. ROCm läuft ab Grafikkarten der Generation GCN 3 und CPUs mit PCI Express 3.0 (AMD Ryzen oder Intel Haswell). Der Funktionsumfang von OpenCL 2.2 wird unterstützt^[33][34], wobei auch Image-Support enthalten ist. Dadurch läuft mit ROCm ab Version 3.7 auch Software wie Darktable oder LuxCoreRender 2.5 ohne zusätzliche Dateien von AMDGPU.^[35] Seit der Version 1.8 werden experimentell auch Prozessoren mit PCIe 2.0 mit AMD GCN 3-Grafikkarten bei geringerer Rechenleistung unterstützt. ROCm-Version 2.4 hat einige Leistungsverbesserungen und Unterstützung für TensorFlow 2.0.^[36] Version 2.5 unterstützt die Thrust-Bibliothek mit rocThrust.^[37] Aktuell ist die Version 5.5.1. Diese unterstützt jedoch nur noch GCN gfx9, CDNA und RDNA hardware. Ältere Hardware muss auf vorherige ROCM-Versionen zurückgreifen oder zukünftig auf RustiCL.^[38]
• Clover (GalliumCompute): Mit Clover^[39] ist seit Mitte 2011 eine unter der GPL stehende Implementierung für Linux in der Entwicklung, die ebenfalls auf LLVM aufsetzt und eine CPU oder – indirekt über Mesa 3D – eine Grafikkarte nutzen soll. Clover wurde in das Mesa-Projekt integriert und ist Teil von GalliumCompute.^[40] Einige Tests für OpenCL 1.0 bis 1.2 werden damit noch nicht bestanden. Mit dem Wechsel von TGSI auf NIR wird OpenCL in Mesa wieder stärker entwickelt, um mit Open-Source-Treibern für Grafikkarten von AMD (mit RadeonSI und R600) und nVidia (mit Nouveau) nutzbar zu sein. Weiterhin fehlt der Image-Support in den verschiedenen Stufen von OpenCL.^[41] Mit der Entwicklung und Ablösung durch RustiCL wird der Support bald enden.
• Intel NEO (Compute Runtime): Unter dem Codenamen NEO wurde ein neuer Open-Source-Treiber für Hardware ab Skylake entwickelt mit OpenCL 2.1-Unterstützung (neu auch ab Broadwell).^[42] OpenCL 2.2 soll in „Compute Runtime“ zeitnah folgen.^[43] OpenCL 3.0 (OpenCL 1.2 mit OpenCL 2.x-Komponenten) ist seit 2020 und nun ab Broadwell (Gen 8) bis Gen 12 aktuell verfügbar.^[44]

• Kallaballa Compute Runtime: Ein inoffizieller Fork der Intel Compute Runtime, welcher Nutzung von OpenGL-Objekten unter Linux mit Intels iGPUs ermöglicht. Dabei zielt das Projekt darauf ab, möglichst kompatibel^[45] zum offiziellen Treiber zu bleiben.
• Nvidia: Nvidia bietet eine OpenCL-Implementierung für seine GPGPU-Schnittstelle CUDA unter Linux, Windows und macOS an.^[46] Diese Implementierung ist nicht Open Source, weshalb sie in gängigen Linux-Distributionen nicht enthalten ist. Die Generation der Tesla-Chips G80 und GT200 (Nvidia Tesla) unterstützt OpenCL 1.1 mit aktuellen Treibern ab Version 341.95.^[47] Fermi unterstützt OpenCL 1.1. Maximal wird OpenCL 1.2 (mit den Chips der Kepler- und Maxwell-GPU) unterstützt. Auch die neue Pascal-GPU unterstützt mit den bisherigen Treibern der 370er-Reihe nur OpenCL 1.2, sowohl in der GeForce-10-Reihe als auch der Quadro- und Tesla-Serie. Mit der Treiber-Version 378.66 wird erstmals OpenCL 2.0 als Beta in wichtigen Funktionen unterstützt.^[48] Seit 2021 wird 3.0 ab Kepler mit aktuellen Treibern unterstützt. Optionale Elemente aus 2.x werden wie bisher nur teilweise unterstützt.^[49] Nvidia erweitert die Interaktion von Vulkan zu openCL 3.0 mit Treiberversion 510+ mit Erweiterungen für semaphores und gemeinsame Speichernutzung.^[50]
• POCL: Portable OpenCL (OpenCL 1.2, OpenCL 2.0 überwiegend),^[51] in der Version 1.0 mit experimentellem Nvidia Cuda Backend für die Nutzung von Nvidia GPUs. Damit ist Open Source OpenCL auf Nvidia-Hardware möglich mit erheblich mehr Möglichkeiten als bei Mesa.^[52][53][54] Die Leistung ist durch fehlende Optimierung und Software teilweise schwach mit Faktor 1:5 bis 1:10 zur AMD-Windows-Implementierung: mit POCL 1.1 wird sie zum Teil stark verbessert und SPIR mit SPIR-V experimentell unterstützt.^[55] Mit Version 1.2 wird HWOC 2.0 sowie nun OpenCL 1.2 vollständig unterstützt.^{[56][57][58][59]} Mit Version 1.3 wird macOS unterstützt.^[60] Version 1.4 unterstützt mehr SPIR und SPIR-V.^[61] Version 1.5 unterstützt neu auch LLVM 10.0.^[62] Version 1.6 zeigt große Fortschritte in der Emulation von OpenCL mit CUDA. Es ist ähnlich schnell wie der Nvidia Treiber. Dazu wird wieder Power PC 8/9 Hardware und LLVM 11 unterstützt. Das Packaging ist nun flexibler.^[63] POCL ist mit manueller Optimierung auf demselben Niveau wie Intel compute runtime.^[64] POCL 1.7 unterstützt nun auch Clang/LLVM 12 und erste OpenCL-3.0-Funktionen wurden implementiert.^[65] POCL 1.8 ist seit Dezember 2021 verfügbar mit Clang/LLVM 13.^[66] Version 3.0 implementiert OpenCL 3.0 auf minimalen Status und LLVM/Clang 14.^[67][68] POCL 4.0 unterstützt als Highlight nun auch Intel ONE API Level Zero. Dazu wurde die Unterstützung von Spir-V ausgebaut und fp16 wird nun unterstützt.^[69]

• RustiCL (OpenCL für Galliumcompute): RustiCL implementiert OpenCL 3.0 in Rust, und ist seit Mesa 22.3 verfügbar. Rust hat hier als Programmiersprache Vorteile in der Wartung des Codes und Vermeidung von Fehlern gegenüber C.^[70] Durch den vorhandenen (optionalen) Image-Support unterstützt RustiCL im Unterschied zu Clover zum Beispiel das Programm Darktable.^[71] Hardware für AMD GCN GPUs und Intel Gen8+ wird zuerst unterstützt. Dazu kommen llvmpipe in Software und Nvidia Fermi und jünger sowie ARM Panfrost. Intel Gen 12 Xe erreicht schon volle OpenCL 3.0 inklusive OpenCL 1.2 in den Khronos-Tests.^[72][73] Double Precision FP64 und FP16 für KI sind in 23.2-dev experimentell verfügbar für numerische Simulationen. AMD R600 wird experimentell unterstützt in Mesa 23.3-dev. Mesamatrix zeigt den aktuellen Stand der Entwicklung auch für Clover.

• Shamrock: Ein Ableger von Clover für Android ARM V7+ ist Shamrock.^[74][75] OpenCL 1.2 wird voll unterstützt. Der Khronos-Test wurde mit der „OpenCL 2.0 Samples Suite“ für die Beispiele bis 1.2 zuletzt bestanden.

• triSYCL: Freie OpenCL-2.2-Implementierung mit SYCL. Status: geringe Entwicklung, nicht komplett^[76]

Eine Liste zertifizierter Produkte liegt bei Khronos vor.^[77]

Diese müssen wie die Implementierungen die Tests der Khronos Conformance Test Suite (CTS) bestehen.^[78]Veraltete Implementierungen:

Veraltete Implementierungen:

• AMD: Die OpenCL-Implementierung von AMD ermöglicht die Nutzung von GPUs über ihre GPGPU-Schnittstelle ATI-Stream und von CPUs mit SSE3 für Linux und Windows.^[79] Grafikkarten der Generationen GCN 4 (RX 400 / RX 500) sowie GCN 5 (Vega) unterstützen OpenCL 2.0 vollständig.^[80] Dies gilt auch für die Grafikkarten der älteren Generationen GCN 2 und GCN 3. Die veralteten Architekturen GCN 1 sowie Terascale 2 unterstützen OpenCL 1.2. Ab der R700-Baureihe wurde OpenCL 1.1 unterstützt. Unter Windows wird ab dem Treiber 19.1.1 auch OpenCL 2.1 unterstützt. Unklar ist hier, welche Hardware hiervon profitieren kann. Vega-Chips können aktuell nur bis OpenCL 2.0 agieren.^[81] OpenCL 3.0 wird für alle GCN und RDNA-Karten unterstützt. Die optionalen Elemente von OpenCL 2.x werden dabei unterschiedlich unterstützt werden wie bisher abhängig von Hardware und System.
• ARM: Weitere Implementierungen für GPUs kommen von ARM,^[82] Intel,^[83] S3^[84] und VIA.^[85]
• IBM: IBM bietet eine Implementierung für die Power-Architektur und die Cell Broadband Engine an.^[86]
• Intel Beignet: Intel hat für Linux und Android das Open-Source-Projekt „Beignet“ aufgesetzt.^[87][88] Zuletzt wurde im November 2016 nach der schon längeren Unterstützung von OpenCL 1.2 (ab Ivy Bridge) die Unterstützung von OpenCL 2.0 angekündigt.^[89] Aktuell ist Version 1.3.2 mit optionalem OpenCL 2.0 mit Optimierungsbedarf.
• Intel OpenCL SDK: kommerzielles SDK von Intel, (OpenCL 2.0 für GPU und 2.1 für CPU ab Gen7).^{[90][91][92][93]}

Viele rechenintensive Programme nutzen OpenCL zur Beschleunigung:^[94]

Grafikprogramme

• GIMP ab Version 2.8^{[95][96][97][98]}
• Adobe Photoshop Creative Suite^[99][100]
• ImageMagick^[101][102]
• PhotoScan^[103][104]
• darktable^{[105][106][107][108]}
• Blurate^[109]
• MVTec HALCON^[110]
• Musemage^[111]
• FAST: Bildverarbeitung für Medizinanwendungen^[112][113]
• KLMeansCL: Entrauscher-Plugin für AVISynth^[114]
• UFO: Bildverarbeitung von Synchrotron-Spuren^[115]

3D-Renderer

• Autodesk Maya^[116]
• Blender^[117][118] Von den Entwicklern von Blender wird der aktuelle Status von OpenCL als “stalled” mit ärgerlichen Fehlern und zu uneinheitlicher Implementierung der aktuell unterstützten GPUs von AMD und Intel eingestuft und die Unterstützung von OpenCL in der Blender Version 3.0 entfernt. Version 2.93 LTS wird damit als letzte OpenCL unterstützen.^[119]
• LuxCoreRender^[120]
• Houdini (Software)
• mandelbulber: Software für das Rendern von 3D-Fraktalen

Audio

• CUETools: Mit dem CUERipper von den CUETools können die FLAC-Dateien besonders schnell mit der Funktion FLACCL von WAV-Format in FLAC konvertiert werden mit der Nutzung von OpenCL in den modernen Grafikkarten.^[121] Dabei sind Beschleunigungen von Faktor 10 bis 100 für diesen Teil des Rip-Prozesses möglich, abhängig von schnellen Grafikkarten und SSD-Datenspeichern gegenüber normaler CPU und Festplatte.

• CN24: semantisches Analysewerkzeug^[122]

Video

• HandBrake^[123]
• FFmpeg^[124]
• Final Cut Pro X^[125]
• RealFlow Hybrido2^[126]
• Sony Catalyst family^[127]
• MAGIX Vegas (vorher Sony Vegas)^{[128][129][130]}
• AlchemistXF^[131]
• vReveal von MotionDSP^[132][133]
• Total Media Theater (TMT) von ArcSoft^[134]
• C4D

Simulation

• Advanced Simulation Library^[135]
• SecondSpace OpenCL-Programm zur Simulation von Wellen im 2D-Raum.
• PATRIC Particle-in-cell-Code^[136]
• Bullet: GPU rigid body simulation using OpenCL^[137][138]
• Monte-Carlo Simulation on AM57x^[139]
• Intel Demo Real-Time Shallow Water Simulation^[140][141]
• Intel Code Samples^[142]
• GROMACS molekulare Simulationen ab Version 5.1^[143][144] Ab Version 2021 wird OpenCL hier als deprecated eingestuft und zukünftig durch SYCL ersetzt.^[145]
• FEM: SIEMENS NX Nastran 9.1+ und Simulia Abaqus 6.11+^{[146][147][148][149]}
• Neuronale Netze: clgen: Deep Learning Program Generator^[150]
• Neuronale Netze: nengo_ocl Gehirn-Simulationen mit Nengo^[151]
• Entschlüsselung: JohnTheRipper^[152]

Web

• Google Chrome^[153]
• Mozilla Firefox^[154]

Bibliotheken

• ACL: AMD Compute Libraries^[155]
  • clBLAS: complete set of BLAS level 1, 2 & 3 routines^[156] weiteres in BLAS
  • clSparse^[157]: Routinen für schwachbesetzte Matrizen
  • clFFT^[158]: schnelle Fourier-Transformation
  • clRNG^[159]: Zufallszahlengeneratoren MRG31k3p, MRG32k3a, LFSR113 und Philox-4×32-10

• AMGCL: AMG algebraischer Multi-Grid Solver^[160]
• ArrayFire: is for parallel computing with an easy-to-use API with JIT-Compiler (Open Source)^[161]
• Bolt: STL compatible library for creating accelerated data parallel applications^[162]
• Boost.Compute: GPU/Parallel C++ Library für OpenCL^[163]
• Chlorine: C++11 Bibliothek zum einfachen Nutzen von OpenCL 1.2+^[164]
• CLBlast: getuntes clBlas^[165]
• clMAGMA: OpenCL port of the MAGMA project, a linear algebra library similar to LAPACK but for Multicore+GPU Systems^[166][167]
• DeepCL: Bibliothek für neurales Training^[168]
• GEGL-OpenCL: Gimp GEGL mit OpenCL^[169]
• GpyFFT: Python Wrapper for FFT mit clFFT^[170]
• MOT: Maastricht Optimization Toolbox^[171]
• Neanderthal: BLAS und LAPACK Implementierung für Clojure^[172]
• Netlib BLAS^[173] mehr in BLAS
• OpenCLGA: genetische Algorithmen mit PYOpenCL^[174]
• PARALUTION^[175]
• random123: Kollektion von Zufallszahlengeneratoren (counter-based random number generators (CBRNGs))^[176]
• VexCL: vector expression template library (MIT-Lizenz)^[177]
• ViennaCL: freie Open-Source Linear Algebra Bibliothek der TU Wien^[178]

• HIP: Open Source C++ Toolkit für OpenCL und Cuda^[179]

• Projekt Coriander: Konvertierung von CUDA in OpenCL 1.2 mit CUDA-on-CL^[180][181]

• Projekt TF-Coriander: Tensorflow mit OpenCL 1.2^[182]

Sprachenkopplung

• ClojureCL: parallel OpenCL 2.0 mit Clojure^[183]
• dcompute: natives Ausführen von D^[184]
• Erlang OpenCL Binding^[185]
• OpenCLAda: Binding Ada zu OpenCL^[186]
• OpenCL.jl: Julia Bindings^[187]
• PyOpenCL: Python Kopplung^[188]
• JavaScript: WebCL

• OpenCL bei der Khronos Group – Offizielle Webseite (englisch)
• OpenCL bei AMD (englisch)
• OpenCL bei Intel (englisch)
• OpenCL bei Nvidia (englisch)
• OpenCL bei Texas Instruments (englisch)
• Portable OpenCL POCL

Tutorials

• OpenCL. Universität Erlangen, archiviert vom Original am 4. März 2016; abgerufen am 6. Januar 2019.