OpenCL

OpenCL defines a four-level memory hierarchy for the compute device:[13]

• global memory: shared by all processing elements, but has high access latency (__global);
• read-only memory: smaller, low latency, writable by the host CPU but not the compute devices (__constant);
• local memory: shared by a group of processing elements (__local);
• per-element private memory (registers; __private).

Not every device needs to implement each level of this hierarchy in hardware. Consistency between the various levels in the hierarchy is relaxed, and only enforced by explicit synchronization constructs, notably barriers.

Devices may or may not share memory with the host CPU.[13] The host API provides handles on device memory buffers and functions to transfer data back and forth between host and devices.

OpenCL C[20] is a C99-based language dialect adapted to fit the device model in OpenCL. Memory buffers reside in specific levels of the memory hierarchy, and pointers are annotated with the region qualifiers __global, __local, __constant, and __private, reflecting this. Instead of a device program having a main function, OpenCL C functions are marked __kernel to signal that they are entry points into the program to be called from the host program. Function pointers, bit fields and variable-length arrays are omitted, and recursion is forbidden.[21] The C standard library is replaced by a custom set of standard functions, geared toward math programming.

OpenCL C is extended to facilitate use of parallelism with vector types and operations, synchronization, and functions to work with work-items and work-groups.[21] In particular, besides scalar types such as float and double, which behave similarly to the corresponding types in C, OpenCL provides fixed-length vector types such as float4 (4-vector of single-precision floats); such vector types are available in lengths two, three, four, eight and sixteen for various base types.[20]^{: § 6.1.2} Vectorized operations on these types are intended to map onto SIMD instructions sets, e.g., SSE or VMX, when running OpenCL programs on CPUs.[13] Other specialized types include 2-d and 3-d image types.[20]^: 10–11

Each invocation (work-item) of the kernel takes a row of the green matrix (A in the code), multiplies this row with the red vector (x) and places the result in an entry of the blue vector (y). The number of columns n is passed to the kernel as ncols; the number of rows is implicit in the number of work-items produced by the host program.

The following is a matrix–vector multiplication algorithm in OpenCL C.

// Multiplies A*x, leaving the result in y.
// A is a row-major matrix, meaning the (i,j) element is at A[i*ncols+j].
__kernel void matvec(__global const float *A, __global const float *x,
                     uint ncols, __global float *y)
{
    size_t i = get_global_id(0);              // Global id, used as the row index
    __global float const *a = &A[i*ncols];    // Pointer to the i'th row
    float sum = 0.f;                          // Accumulator for dot product
    for (size_t j = 0; j < ncols; j++) {
        sum += a[j] * x[j];
    }
    y[i] = sum;
}

The kernel function matvec computes, in each invocation, the dot product of a single row of a matrix A and a vector x:

${\displaystyle y_{i}=a_{i,:}\cdot x=\sum _{j}a_{i,j}x_{j}}$.

To extend this into a full matrix–vector multiplication, the OpenCL runtime maps the kernel over the rows of the matrix. On the host side, the clEnqueueNDRangeKernel function does this; it takes as arguments the kernel to execute, its arguments, and a number of work-items, corresponding to the number of rows in the matrix A.

This example will load a fast Fourier transform (FFT) implementation and execute it. The implementation is shown below.[22] The code asks the OpenCL library for the first available graphics card, creates memory buffers for reading and writing (from the perspective of the graphics card), JIT-compiles the FFT-kernel and then finally asynchronously runs the kernel. The result from the transform is not read in this example.

#include <stdio.h>
#include <time.h>
#include "CL/opencl.h"

#define NUM_ENTRIES 1024

int main() // (int argc, const char* argv[])
{
	// CONSTANTS
	// The source code of the kernel is represented as a string
	// located inside file: "fft1D_1024_kernel_src.cl". For the details see the next listing.
	const char *KernelSource =
		#include "fft1D_1024_kernel_src.cl"
			;

	// Looking up the available GPUs
	const cl_uint num = 1;
	clGetDeviceIDs(NULL, CL_DEVICE_TYPE_GPU, 0, NULL, (cl_uint*)&num);

	cl_device_id devices[1];
	clGetDeviceIDs(NULL, CL_DEVICE_TYPE_GPU, num, devices, NULL);

	// create a compute context with GPU device
	cl_context context = clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU, NULL, NULL, NULL);

	// create a command queue
	clGetDeviceIDs(NULL, CL_DEVICE_TYPE_DEFAULT, 1, devices, NULL);
	cl_command_queue queue = clCreateCommandQueue(context, devices[0], 0, NULL);

	// allocate the buffer memory objects
	cl_mem memobjs[] = { clCreateBuffer(context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, sizeof(float) * 2 * NUM_ENTRIES, NULL, NULL),
						 clCreateBuffer(context, CL_MEM_READ_WRITE, sizeof(float) * 2 * NUM_ENTRIES, NULL, NULL) };

	// create the compute program
	// const char* fft1D_1024_kernel_src[1] = {  };
	cl_program program = clCreateProgramWithSource(context, 1, (const char **)& KernelSource, NULL, NULL);

	// build the compute program executable
	clBuildProgram(program, 0, NULL, NULL, NULL, NULL);

	// create the compute kernel
	cl_kernel kernel = clCreateKernel(program, "fft1D_1024", NULL);

	// set the args values

	size_t local_work_size[1] = { 256 };

	clSetKernelArg(kernel, 0, sizeof(cl_mem), (void *)&memobjs[0]);
	clSetKernelArg(kernel, 1, sizeof(cl_mem), (void *)&memobjs[1]);
	clSetKernelArg(kernel, 2, sizeof(float)*(local_work_size[0] + 1) * 16, NULL);
	clSetKernelArg(kernel, 3, sizeof(float)*(local_work_size[0] + 1) * 16, NULL);

	// create N-D range object with work-item dimensions and execute kernel
	size_t global_work_size[1] = { 256 };
	
	global_work_size[0] = NUM_ENTRIES;
	local_work_size[0] = 64; //Nvidia: 192 or 256
	clEnqueueNDRangeKernel(queue, kernel, 1, NULL, global_work_size, local_work_size, 0, NULL, NULL);
}

The actual calculation inside file "fft1D_1024_kernel_src.cl" (based on Fitting FFT onto the G80 Architecture):[23]

R"(
  // This kernel computes FFT of length 1024. The 1024 length FFT is decomposed into
  // calls to a radix 16 function, another radix 16 function and then a radix 4 function

  __kernel void fft1D_1024 (__global float2 *in, __global float2 *out,
                          __local float *sMemx, __local float *sMemy) {
    int tid = get_local_id(0);
    int blockIdx = get_group_id(0) * 1024 + tid;
    float2 data[16];

    // starting index of data to/from global memory
    in = in + blockIdx;  out = out + blockIdx;

    globalLoads(data, in, 64); // coalesced global reads
    fftRadix16Pass(data);      // in-place radix-16 pass
    twiddleFactorMul(data, tid, 1024, 0);

    // local shuffle using local memory
    localShuffle(data, sMemx, sMemy, tid, (((tid & 15) * 65) + (tid >> 4)));
    fftRadix16Pass(data);               // in-place radix-16 pass
    twiddleFactorMul(data, tid, 64, 4); // twiddle factor multiplication

    localShuffle(data, sMemx, sMemy, tid, (((tid >> 4) * 64) + (tid & 15)));

    // four radix-4 function calls
    fftRadix4Pass(data);      // radix-4 function number 1
    fftRadix4Pass(data + 4);  // radix-4 function number 2
    fftRadix4Pass(data + 8);  // radix-4 function number 3
    fftRadix4Pass(data + 12); // radix-4 function number 4

    // coalesced global writes
    globalStores(data, out, 64);
  }
)"

A full, open source implementation of an OpenCL FFT can be found on Apple's website.[24]

In 2020, Khronos announced[25] the transition to the community driven C++ for OpenCL programming language[26] that provides features from C++17 in combination with the traditional OpenCL C features. This language allows to leverage a rich variety of language features from standard C++ while preserving backward compatibility to OpenCL C. This opens up a smooth transition path to C++ functionality for the OpenCL kernel code developers as they can continue using familiar programming flow and even tools as well as leverage existing extensions and libraries available for OpenCL C.

The language semantics is described in the documentation published in the releases of OpenCL-Docs[27] repository hosted by the Khronos Group but it is currently not ratified by the Khronos Group. The C++ for OpenCL language is not documented in a stand-alone document and it is based on the specification of C++ and OpenCL C. The open source Clang compiler has supported C++ for OpenCL since release 9.[28]

C++ for OpenCL has been originally developed as a Clang compiler extension and appeared in the release 9.[29] As it was tightly coupled with OpenCL C and did not contain any Clang specific functionality its documentation has been re-hosted to the OpenCL-Docs repository[27] from the Khronos Group along with the sources of other specifications and reference cards. The first official release of this document describing C++ for OpenCL version 1.0 has been published in December 2020.[30] C++ for OpenCL 1.0 contains features from C++17 and it is backward compatible with OpenCL C 2.0. A work in progress draft of its documentation can be found on the Khronos website.[31]

C++ for OpenCL supports most of the features (syntactically and semantically) from OpenCL C except for nested parallelism and blocks.[32] However, there are minor differences in some supported features mainly related to differences in semantics between C++ and C. For example, C++ is more strict with the implicit type conversions and it does not support the restrict type qualifier.[32] The following C++ features are not supported by C++ for OpenCL: virtual functions, dynamic_cast operator, non-placement new/delete operators, exceptions, pointer to member functions, references to functions, C++ standard libraries.[32] C++ for OpenCL extends the concept of separate memory regions (address spaces) from OpenCL C to C++ features - functional casts, templates, class members, references, lambda functions,  operators. Most of C++ features are not available for the kernel functions e.g. overloading or templating, arbitrary class layout in parameter type.[32]

The following code snippet illustrates how kernels with complex-number arithmetic can be implemented in C++ for OpenCL language with convenient use of C++ features.

// Define a class Complex, that can perform complex-number computations with
// various precision when different types for T are used - double, float, half.
template<typename T>
class complex_t {
    T m_re; // Real component.
    T m_im; // Imaginary component.

public:
    complex_t(T re, T im): m_re{re}, m_im{im} {};
    // Define operator for complex-number multiplication.
    complex_t operator*(const complex_t &other) const
    {
        return {m_re * other.m_re - m_im * other.m_im, 
                m_re * other.m_im + m_im * other.m_re};
    }
    T get_re() const { return m_re; }
    T get_im() const { return m_im; }
};

// A helper function to compute multiplication over complex numbers read from
// the input buffer and to store the computed result into the output buffer.
template<typename T>
void compute_helper(__global T *in, __global T *out) {
    auto idx = get_global_id(0);    
    // Every work-item uses 4 consecutive items from the input buffer
    // - two for each complex number.
    auto offset = idx * 4;
    auto num1 = complex_t{in[offset], in[offset + 1]};
    auto num2 = complex_t{in[offset + 2], in[offset + 3]};
    // Perform complex-number multiplication.
    auto res = num1 * num2;
    // Every work-item writes 2 consecutive items to the output buffer.
    out[idx * 2] = res.get_re();
    out[idx * 2 + 1] = res.get_im();
}

// This kernel is used for complex-number multiplication in single precision.
__kernel void compute_sp(__global float *in, __global float *out) {
    compute_helper(in, out);
}

#ifdef cl_khr_fp16
// This kernel is used for complex-number multiplication in half precision when
// it is supported by the device.
#pragma OPENCL EXTENSION cl_khr_fp16: enable
__kernel void compute_hp(__global half *in, __global half *out) {
    compute_helper(in, out); 
}
#endif

C++ for OpenCL language can be used for the same applications or libraries and in the same way as OpenCL C language is used. Due to the rich variety of C++ language features, applications written in C++ for OpenCL can express complex functionality more conveniently than applications written in OpenCL C and in particular generic programming paradigm from C++ is very attractive to the library developers.

C++ for OpenCL sources can be compiled by OpenCL drivers that support cl_ext_cxx_for_opencl extension.[33] Arm has announced support for this extension in December 2020.[34] However, due to increasing complexity of the algorithms accelerated on OpenCL devices, it is expected that more applications will compile C++ for OpenCL kernels offline using stand alone compilers such as Clang[35] into executable binary format or portable binary format e.g. SPIR-V.[36] Such an executable can be loaded during the OpenCL applications execution using a dedicated OpenCL API.[37]

Binaries compiled from sources in C++ for OpenCL 1.0 can be executed on OpenCL 2.0 conformant devices. Depending on the language features used in such kernel sources it can also be executed on devices supporting earlier OpenCL versions or OpenCL 3.0.

Aside from OpenCL drivers kernels written in C++ for OpenCL can be compiled for execution on Vulkan devices using clspv[38] compiler and clvk[39] runtime layer just the same way as OpenCL C kernels.

C++ for OpenCL is an open language developed by the community of contributors listed in its documentation.[31]  New contributions to the language semantic definition or open source tooling support are accepted from anyone interested as soon as they are aligned with the main design philosophy and they are reviewed and approved by the experienced contributors.[19]

OpenCL 1.0 released with Mac OS X Snow Leopard on August 28, 2009. According to an Apple press release:[43]

Snow Leopard further extends support for modern hardware with Open Computing Language (OpenCL), which lets any application tap into the vast gigaflops of GPU computing power previously available only to graphics applications. OpenCL is based on the C programming language and has been proposed as an open standard.

AMD decided to support OpenCL instead of the now deprecated Close to Metal in its Stream framework.[44][45] RapidMind announced their adoption of OpenCL underneath their development platform to support GPUs from multiple vendors with one interface.[46] On December 9, 2008, Nvidia announced its intention to add full support for the OpenCL 1.0 specification to its GPU Computing Toolkit.[47] On October 30, 2009, IBM released its first OpenCL implementation as a part of the XL compilers.[48]

Acceleration of calculations with factor to 1000 are possible with OpenCL in graphic cards against normal CPU.[49] Some important features of next Version of OpenCL are optional in 1.0 like double- or half-precision operations.[50]

OpenCL 1.1 was ratified by the Khronos Group on June 14, 2010[51] and adds significant functionality for enhanced parallel programming flexibility, functionality, and performance including:

• New data types including 3-component vectors and additional image formats;
• Handling commands from multiple host threads and processing buffers across multiple devices;
• Operations on regions of a buffer including read, write and copy of 1D, 2D, or 3D rectangular regions;
• Enhanced use of events to drive and control command execution;
• Additional OpenCL built-in C functions such as integer clamp, shuffle, and asynchronous strided copies;
• Improved OpenGL interoperability through efficient sharing of images and buffers by linking OpenCL and OpenGL events.

On November 15, 2011, the Khronos Group announced the OpenCL 1.2 specification,[52] which added significant functionality over the previous versions in terms of performance and features for parallel programming. Most notable features include:

• Device partitioning: the ability to partition a device into sub-devices so that work assignments can be allocated to individual compute units. This is useful for reserving areas of the device to reduce latency for time-critical tasks.
• Separate compilation and linking of objects: the functionality to compile OpenCL into external libraries for inclusion into other programs.
• Enhanced image support (optional): 1.2 adds support for 1D images and 1D/2D image arrays. Furthermore, the OpenGL sharing extensions now allow for OpenGL 1D textures and 1D/2D texture arrays to be used to create OpenCL images.
• Built-in kernels: custom devices that contain specific unique functionality are now integrated more closely into the OpenCL framework. Kernels can be called to use specialised or non-programmable aspects of underlying hardware. Examples include video encoding/decoding and digital signal processors.
• DirectX functionality: DX9 media surface sharing allows for efficient sharing between OpenCL and DX9 or DXVA media surfaces. Equally, for DX11, seamless sharing between OpenCL and DX11 surfaces is enabled.
• The ability to force IEEE 754 compliance for single-precision floating-point math: OpenCL by default allows the single-precision versions of the division, reciprocal, and square root operation to be less accurate than the correctly rounded values that IEEE 754 requires.[53] If the programmer passes the "-cl-fp32-correctly-rounded-divide-sqrt" command line argument to the compiler, these three operations will be computed to IEEE 754 requirements if the OpenCL implementation supports this, and will fail to compile if the OpenCL implementation does not support computing these operations to their correctly-rounded values as defined by the IEEE 754 specification.[53] This ability is supplemented by the ability to query the OpenCL implementation to determine if it can perform these operations to IEEE 754 accuracy.[53]

On November 18, 2013, the Khronos Group announced the ratification and public release of the finalized OpenCL 2.0 specification.[54] Updates and additions to OpenCL 2.0 include:

• Shared virtual memory
• Nested parallelism
• Generic address space
• Images (optional, include 3D-Image)
• C11 atomics
• Pipes
• Android installable client driver extension
• half precision extended with optional cl_khr_fp16 extension
• cl_double: double precision IEEE 754 (optional)

The ratification and release of the OpenCL 2.1 provisional specification was announced on March 3, 2015 at the Game Developer Conference in San Francisco. It was released on November 16, 2015.[55] It introduced the OpenCL C++ kernel language, based on a subset of C++14, while maintaining support for the preexisting OpenCL C kernel language. Vulkan and OpenCL 2.1 share SPIR-V as an intermediate representation allowing high-level language front-ends to share a common compilation target. Updates to the OpenCL API include:

• Additional subgroup functionality
• Copying of kernel objects and states
• Low-latency device timer queries
• Ingestion of SPIR-V code by runtime
• Execution priority hints for queues
• Zero-sized dispatches from host

AMD, ARM, Intel, HPC, and YetiWare have declared support for OpenCL 2.1.[56][57]

OpenCL 2.2 brings the OpenCL C++ kernel language into the core specification for significantly enhanced parallel programming productivity.[58][59][60] It was released on May 16, 2017.[61] Maintenance Update released in May 2018 with bugfixes.[62]

• The OpenCL C++ kernel language is a static subset of the C++14 standard and includes classes, templates, lambda expressions, function overloads and many other constructs for generic and meta-programming.
• Uses the new Khronos SPIR-V 1.1 intermediate language which fully supports the OpenCL C++ kernel language.
• OpenCL library functions can now use the C++ language to provide increased safety and reduced undefined behavior while accessing features such as atomics, iterators, images, samplers, pipes, and device queue built-in types and address spaces.
• Pipe storage is a new device-side type in OpenCL 2.2 that is useful for FPGA implementations by making connectivity size and type known at compile time, enabling efficient device-scope communication between kernels.
• OpenCL 2.2 also includes features for enhanced optimization of generated code: applications can provide the value of specialization constant at SPIR-V compilation time, a new query can detect non-trivial constructors and destructors of program scope global objects, and user callbacks can be set at program release time.
• Runs on any OpenCL 2.0-capable hardware (only a driver update is required).

The OpenCL 3.0 specification was released on September 30, 2020 after being in preview since April 2020. OpenCL 1.2 functionality has become a mandatory baseline, while all OpenCL 2.x and OpenCL 3.0 features were made optional. The specification retains the OpenCL C language and deprecates the OpenCL C++ Kernel Language, replacing it with the C++ for OpenCL language[19] based on a Clang/LLVM compiler which implements a subset of C++17 and SPIR-V intermediate code.[63][64][65] Version 3.0.7 of C++ for OpenCL with some Khronos openCL extensions were presented at IWOCL 21.[66] Actual is 3.0.11 with some new extensions and corrections. NVIDIA, working closely with the Khronos OpenCL Working Group, improved Vulkan Interop with semaphores and memory sharing.[67]

• June, 2008: During Apple’s WWDC conference an early beta of Mac OS X Snow Leopard was made available to the participants, it included the first beta implementation of OpenCL, about 6 months before the final version 1.0 specification was ratified late 2008. They also showed two demos. One was a grid of 8x8 screens rendered, each displaying the screen of an emulated Apple II machine — 64 independent instances in total, each running a famous karate game. This showed task parallelism, on the CPU. The other demo was a N-body simulation running on the GPU of a Mac Pro, a data parallel task.
• December 10, 2008: AMD and Nvidia held the first public OpenCL demonstration, a 75-minute presentation at SIGGRAPH Asia 2008. AMD showed a CPU-accelerated OpenCL demo explaining the scalability of OpenCL on one or more cores while Nvidia showed a GPU-accelerated demo.[120][121]
• March 16, 2009: at the 4th Multicore Expo, Imagination Technologies announced the PowerVR SGX543MP, the first GPU of this company to feature OpenCL support.[122]
• March 26, 2009: at GDC 2009, AMD and Havok demonstrated the first working implementation for OpenCL accelerating Havok Cloth on AMD Radeon HD 4000 series GPU.[123]
• April 20, 2009: Nvidia announced the release of its OpenCL driver and SDK to developers participating in its OpenCL Early Access Program.[124]
• August 5, 2009: AMD unveiled the first development tools for its OpenCL platform as part of its ATI Stream SDK v2.0 Beta Program.[125]
• August 28, 2009: Apple released Mac OS X Snow Leopard, which contains a full implementation of OpenCL.[126]
• September 28, 2009: Nvidia released its own OpenCL drivers and SDK implementation.
• October 13, 2009: AMD released the fourth beta of the ATI Stream SDK 2.0, which provides a complete OpenCL implementation on both R700/R800 GPUs and SSE3 capable CPUs. The SDK is available for both Linux and Windows.[127]
• November 26, 2009: Nvidia released drivers for OpenCL 1.0 (rev 48).
• October 27, 2009: S3 released their first product supporting native OpenCL 1.0 – the Chrome 5400E embedded graphics processor.[128]
• December 10, 2009: VIA released their first product supporting OpenCL 1.0 – ChromotionHD 2.0 video processor included in VN1000 chipset.[129]
• December 21, 2009: AMD released the production version of the ATI Stream SDK 2.0,[130] which provides OpenCL 1.0 support for R800 GPUs and beta support for R700 GPUs.
• June 1, 2010: ZiiLABS released details of their first OpenCL implementation for the ZMS processor for handheld, embedded and digital home products.[131]
• June 30, 2010: IBM released a fully conformant version of OpenCL 1.0.[4]
• September 13, 2010: Intel released details of their first OpenCL implementation for the Sandy Bridge chip architecture. Sandy Bridge will integrate Intel's newest graphics chip technology directly onto the central processing unit.[132]
• November 15, 2010: Wolfram Research released Mathematica 8 with OpenCLLink package.
• March 3, 2011: Khronos Group announces the formation of the WebCL working group to explore defining a JavaScript binding to OpenCL. This creates the potential to harness GPU and multi-core CPU parallel processing from a Web browser.[133][134]
• March 31, 2011: IBM released a fully conformant version of OpenCL 1.1.[4][135]
• April 25, 2011: IBM released OpenCL Common Runtime v0.1 for Linux on x86 Architecture.[136]
• May 4, 2011: Nokia Research releases an open source WebCL extension for the Firefox web browser, providing a JavaScript binding to OpenCL.[137]
• July 1, 2011: Samsung Electronics releases an open source prototype implementation of WebCL for WebKit, providing a JavaScript binding to OpenCL.[138]
• August 8, 2011: AMD released the OpenCL-driven AMD Accelerated Parallel Processing (APP) Software Development Kit (SDK) v2.5, replacing the ATI Stream SDK as technology and concept.[139]
• December 12, 2011: AMD released AMD APP SDK v2.6[140] which contains a preview of OpenCL 1.2.
• February 27, 2012: The Portland Group released the PGI OpenCL compiler for multi-core ARM CPUs.[141]
• April 17, 2012: Khronos released a WebCL working draft.[142]
• May 6, 2013: Altera released the Altera SDK for OpenCL, version 13.0.[143] It is conformant to OpenCL 1.0.[144]
• November 18, 2013: Khronos announced that the specification for OpenCL 2.0 had been finalized.[145]
• March 19, 2014: Khronos releases the WebCL 1.0 specification.[146][147]
• August 29, 2014: Intel releases HD Graphics 5300 driver that supports OpenCL 2.0.[148]
• September 25, 2014: AMD releases Catalyst 14.41 RC1, which includes an OpenCL 2.0 driver.[149]
• January 14, 2015: Xilinx Inc. announces SDAccel development environment for OpenCL, C, and C++, achieves Khronos Conformance.[150]
• April 13, 2015: Nvidia releases WHQL driver v350.12, which includes OpenCL 1.2 support for GPUs based on Kepler or later architectures.[151] Driver 340+ support OpenCL 1.1 for Tesla and Fermi.
• August 26, 2015: AMD released AMD APP SDK v3.0[152] which contains full support of OpenCL 2.0 and sample coding.
• November 16, 2015: Khronos announced that the specification for OpenCL 2.1 had been finalized.[153]
• April 18, 2016: Khronos announced that the specification for OpenCL 2.2 had been provisionally finalized.[59]
• November 3, 2016 Intel support for Gen7+ of OpenCL 2.1 in SDK 2016 r3.[154]
• February 17, 2017: Nvidia begins evaluation support of OpenCL 2.0 with driver 378.66.[155][156][157]
• May 16, 2017: Khronos announced that the specification for OpenCL 2.2 had been finalized with SPIR-V 1.2.[158]
• May 14, 2018: Khronos announced Maintenance Update for OpenCL 2.2 with Bugfix and unified headers.[62]
• April 27, 2020: Khronos announced provisional Version of OpenCL 3.0.
• June 1, 2020: Intel Neo Runtime with OpenCL 3.0 for new Tiger Lake.
• June 3, 2020: AMD announced RocM 3.5 with OpenCL 2.2 support.[159]
• September 30, 2020: Khronos announced that the specifications for OpenCL 3.0 had been finalized (CTS also available).
• October 16, 2020: Intel announced with Neo 20.41 support for OpenCL 3.0 (includes mostly of optional OpenCL 2.x).
• April 6, 2021: Nvidia supports OpenCL 3.0 for Ampere. Maxwell and later GPUs also supports OpenCL 3.0 with Nvidia driver 465+.[160]

To be officially conformant, an implementation must pass the Khronos Conformance Test Suite (CTS), with results being submitted to the Khronos Adopters Program.[161] The Khronos CTS code for all OpenCL versions has been available in open source since 2017.[162]

The Khronos Group maintains an extended list of OpenCL-conformant products.[4]

All standard-conformant implementations can be queried using one of the clinfo tools (there are multiple tools with the same name and similar feature set).[173][174][175]

Products and their version of OpenCL support include:[176]

All hardware with OpenCL 1.2+ is possible, OpenCL 2.x only optional, Khronos Test Suite available since 2020-10[177][178]

• (2020) Intel NEO Compute: 20.41+ for Gen 12 Tiger Lake to Broadwell (include full 2.0 and 2.1 support and parts of 2.2)[179]
• (2020) Intel 6th, 7th, 8th, 9th, 10th, 11th gen processors (Skylake, Kaby Lake, Coffee Lake, Comet Lake, Ice Lake, Tiger Lake) with latest Intel Windows graphics driver
• (2021) Intel 11th, 12th gen processors (Rocket Lake, Alder Lake) with latest Intel Windows graphics driver
• (2022) Intel 13th gen processors (Raptor Lake) with latest Intel Windows graphics driver
• (2022) Intel Arc discrete graphics with latest Intel Arc Windows graphics driver
• (2021) Nvidia Maxwell, Pascal, Volta, Turing and Ampere with Nvidia graphics driver 465+.[160]
• (2022) Nvidia Ada Lovelace with Nvidia graphics driver 520+.

None yet: Khronos Test Suite ready, with Driver Update all Hardware with 2.0 and 2.1 support possible

• Intel NEO Compute: Work in Progress for actual products[180]
• ROCm: Version 3.5+ mostly

• (2018+) Support backported to Intel 5th and 6th gen processors (Broadwell, Skylake)
• (2017+) Intel 7th, 8th, 9th, 10th gen processors (Kaby Lake, Coffee Lake, Comet Lake, Ice Lake)
• Khronos: with Driver Update all Hardware with 2.0 support possible

• (2011+) AMD GCN GPU's (HD 7700+/HD 8000/Rx 200/Rx 300/Rx 400/Rx 500/Rx 5000-Series), some GCN 1st Gen only 1.2 with some Extensions
• (2013+) AMD GCN APU's (Jaguar, Steamroller, Puma, Excavator & Zen-based)
• (2014+) Intel 5th & 6th gen processors (Broadwell, Skylake)
• (2015+) Qualcomm Adreno 5xx series
• (2018+) Qualcomm Adreno 6xx series
• (2017+) ARM Mali (Bifrost) G51 and G71 in Android 7.1 and Linux
• (2018+) ARM Mali (Bifrost) G31, G52, G72 and G76
• (2017+) incomplete Evaluation support: Nvidia Kepler, Maxwell, Pascal, Volta and Turing GPU's (GeForce 600, 700, 800, 900 & 10-series, Quadro K-, M- & P-series, Tesla K-, M- & P-series) with Driver Version 378.66+

• (2011+) for some AMD GCN 1st Gen some OpenCL 2.0 Features not possible today, but many more Extensions than Terascale
• (2009+) AMD TeraScale 2 & 3 GPU's (RV8xx, RV9xx in HD 5000, 6000 & 7000 Series)
• (2011+) AMD TeraScale APU's (K10, Bobcat & Piledriver-based)
• (2012+) Nvidia Kepler, Maxwell, Pascal, Volta and Turing GPU's (GeForce 600, 700, 800, 900, 10, 16, 20 series, Quadro K-, M- & P-series, Tesla K-, M- & P-series)
• (2012+) Intel 3rd & 4th gen processors (Ivy Bridge, Haswell)
• (2013+) Qualcomm Adreno 4xx series
• (2013+) ARM Mali Midgard 3rd gen (T760)
• (2015+) ARM Mali Midgard 4th gen (T8xx)

• (2008+) some AMD TeraScale 1 GPU's (RV7xx in HD4000-series)
• (2008+) Nvidia Tesla, Fermi GPU's (GeForce 8, 9, 100, 200, 300, 400, 500-series, Quadro-series or Tesla-series with Tesla or Fermi GPU)
• (2011+) Qualcomm Adreno 3xx series
• (2012+) ARM Mali Midgard 1st and 2nd gen (T-6xx, T720)

• mostly updated to 1.1 and 1.2 after first Driver for 1.0 only