This article has multiple issues. Please help improve it or discuss these issues on the talk page . (Learn how and when to remove these messages)
|
Original author(s) | Apple Inc. |
---|---|
Developer(s) | Khronos Group |
Initial release | August 28, 2009 |
Stable release | |
Written in | C with C++ bindings |
Operating system | Android (vendor dependent), [2] FreeBSD, [3] Linux, macOS (via Pocl), Windows |
Platform | ARMv7, ARMv8, [4] Cell, IA-32, Power, x86-64 |
Type | Heterogeneous computing API |
License | OpenCL specification license |
Website | www |
Paradigm | Imperative (procedural), structured, (C++ only) object-oriented, generic programming |
---|---|
Family | C |
Stable release | |
Typing discipline | Static, weak, manifest, nominal |
Implementation language | Implementation specific |
Filename extensions | .cl .clcpp |
Website | www |
Major implementations | |
AMD, Gallium Compute, IBM, Intel NEO, Intel SDK, Texas Instruments, Nvidia, POCL, Arm | |
Influenced by | |
C99, CUDA, C++14, C++17 |
OpenCL (Open Computing Language) is a framework for writing programs that execute across heterogeneous platforms consisting of central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs) and other processors or hardware accelerators. OpenCL specifies a programming language (based on C99) for programming these devices and application programming interfaces (APIs) to control the platform and execute programs on the compute devices. OpenCL provides a standard interface for parallel computing using task- and data-based parallelism.
OpenCL is an open standard maintained by the Khronos Group, a non-profit, open standards organisation. Conformant implementations (passed the Conformance Test Suite) are available from a range of companies including AMD, ARM, Cadence, Google, Imagination, Intel, Nvidia, Qualcomm, Samsung, SPI and Verisilicon. [8] [9]
OpenCL views a computing system as consisting of a number of compute devices, which might be central processing units (CPUs) or "accelerators" such as graphics processing units (GPUs), attached to a host processor (a CPU). It defines a C-like language for writing programs. Functions executed on an OpenCL device are called "kernels". [10] : 17 A single compute device typically consists of several compute units, which in turn comprise multiple processing elements (PEs). A single kernel execution can run on all or many of the PEs in parallel. How a compute device is subdivided into compute units and PEs is up to the vendor; a compute unit can be thought of as a "core", but the notion of core is hard to define across all the types of devices supported by OpenCL (or even within the category of "CPUs"), [11] : 49–50 and the number of compute units may not correspond to the number of cores claimed in vendors' marketing literature (which may actually be counting SIMD lanes). [12]
In addition to its C-like programming language, OpenCL defines an application programming interface (API) that allows programs running on the host to launch kernels on the compute devices and manage device memory, which is (at least conceptually) separate from host memory. Programs in the OpenCL language are intended to be compiled at run-time, so that OpenCL-using applications are portable between implementations for various host devices. [13] The OpenCL standard defines host APIs for C and C++; third-party APIs exist for other programming languages and platforms such as Python, [14] Java, Perl, [15] D [16] and .NET. [11] : 15 An implementation of the OpenCL standard consists of a library that implements the API for C and C++, and an OpenCL C compiler for the compute devices targeted.
In order to open the OpenCL programming model to other languages or to protect the kernel source from inspection, the Standard Portable Intermediate Representation (SPIR) [17] can be used as a target-independent way to ship kernels between a front-end compiler and the OpenCL back-end.
More recently Khronos Group has ratified SYCL, [18] a higher-level programming model for OpenCL as a single-source eDSL based on pure C++17 to improve programming productivity. People interested by C++ kernels but not by SYCL single-source programming style can use C++ features with compute kernel sources written in "C++ for OpenCL" language. [19]
OpenCL defines a four-level memory hierarchy for the compute device: [13]
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.
The programming language that is used to write compute kernels is called kernel language. OpenCL adopts C/C++-based languages to specify the kernel computations performed on the device with some restrictions and additions to facilitate efficient mapping to the heterogeneous hardware resources of accelerators. Traditionally OpenCL C was used to program the accelerators in OpenCL standard, later C++ for OpenCL kernel language was developed that inherited all functionality from OpenCL C but allowed to use C++ features in the kernel sources.
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
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].__kernelvoidmatvec(__globalconstfloat*A,__globalconstfloat*x,uintncols,__globalfloat*y){size_ti=get_global_id(0);// Global id, used as the row index__globalfloatconst*a=&A[i*ncols];// Pointer to the i'th rowfloatsum=0.f;// Accumulator for dot productfor(size_tj=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:
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 1024intmain()// (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.constchar*KernelSource=#include"fft1D_1024_kernel_src.cl";// Looking up the available GPUsconstcl_uintnum=1;clGetDeviceIDs(NULL,CL_DEVICE_TYPE_GPU,0,NULL,(cl_uint*)&num);cl_device_iddevices[1];clGetDeviceIDs(NULL,CL_DEVICE_TYPE_GPU,num,devices,NULL);// create a compute context with GPU devicecl_contextcontext=clCreateContextFromType(NULL,CL_DEVICE_TYPE_GPU,NULL,NULL,NULL);// create a command queueclGetDeviceIDs(NULL,CL_DEVICE_TYPE_DEFAULT,1,devices,NULL);cl_command_queuequeue=clCreateCommandQueue(context,devices[0],0,NULL);// allocate the buffer memory objectscl_memmemobjs[]={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_programprogram=clCreateProgramWithSource(context,1,(constchar**)&KernelSource,NULL,NULL);// build the compute program executableclBuildProgram(program,0,NULL,NULL,NULL,NULL);// create the compute kernelcl_kernelkernel=clCreateKernel(program,"fft1D_1024",NULL);// set the args valuessize_tlocal_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 kernelsize_tglobal_work_size[1]={256};global_work_size[0]=NUM_ENTRIES;local_work_size[0]=64;//Nvidia: 192 or 256clEnqueueNDRangeKernel(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__kernelvoidfft1D_1024(__globalfloat2*in,__globalfloat2*out,__localfloat*sMemx,__localfloat*sMemy){inttid=get_local_id(0);intblockIdx=get_group_id(0)*1024+tid;float2data[16];// starting index of data to/from global memoryin=in+blockIdx;out=out+blockIdx;globalLoads(data,in,64);// coalesced global readsfftRadix16Pass(data);// in-place radix-16 passtwiddleFactorMul(data,tid,1024,0);// local shuffle using local memorylocalShuffle(data,sMemx,sMemy,tid,(((tid&15)*65)+(tid>>4)));fftRadix16Pass(data);// in-place radix-16 passtwiddleFactorMul(data,tid,64,4);// twiddle factor multiplicationlocalShuffle(data,sMemx,sMemy,tid,(((tid>>4)*64)+(tid&15)));// four radix-4 function callsfftRadix4Pass(data);// radix-4 function number 1fftRadix4Pass(data+4);// radix-4 function number 2fftRadix4Pass(data+8);// radix-4 function number 3fftRadix4Pass(data+12);// radix-4 function number 4// coalesced global writesglobalStores(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. In December 2021, a new provisional C++ for OpenCL version 2021 has been released which is fully compatible with the OpenCL 3.0 standard. [31] A work in progress draft of the latest C++ for OpenCL documentation can be found on the Khronos website. [32]
C++ for OpenCL supports most of the features (syntactically and semantically) from OpenCL C except for nested parallelism and blocks. [33] 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. [33] 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. [33] 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, and operators. Most of C++ features are not available for the kernel functions e.g. overloading or templating, arbitrary class layout in parameter type. [33]
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<typenameT>classcomplex_t{Tm_re;// Real component.Tm_im;// Imaginary component.public:complex_t(Tre,Tim):m_re{re},m_im{im}{};// Define operator for complex-number multiplication.complex_toperator*(constcomplex_t&other)const{return{m_re*other.m_re-m_im*other.m_im,m_re*other.m_im+m_im*other.m_re};}Tget_re()const{returnm_re;}Tget_im()const{returnm_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<typenameT>voidcompute_helper(__globalT*in,__globalT*out){autoidx=get_global_id(0);// Every work-item uses 4 consecutive items from the input buffer// - two for each complex number.autooffset=idx*4;autonum1=complex_t{in[offset],in[offset+1]};autonum2=complex_t{in[offset+2],in[offset+3]};// Perform complex-number multiplication.autores=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.__kernelvoidcompute_sp(__globalfloat*in,__globalfloat*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__kernelvoidcompute_hp(__globalhalf*in,__globalhalf*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. [34] Arm has announced support for this extension in December 2020. [35] 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 [36] into executable binary format or portable binary format e.g. SPIR-V. [37] Such an executable can be loaded during the OpenCL applications execution using a dedicated OpenCL API. [38]
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 [39] compiler and clvk [40] 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. [32] 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 was initially developed by Apple Inc., which holds trademark rights, and refined into an initial proposal in collaboration with technical teams at AMD, IBM, Qualcomm, Intel, and Nvidia. Apple submitted this initial proposal to the Khronos Group. On June 16, 2008, the Khronos Compute Working Group was formed [41] with representatives from CPU, GPU, embedded-processor, and software companies. This group worked for five months to finish the technical details of the specification for OpenCL 1.0 by November 18, 2008. [42] This technical specification was reviewed by the Khronos members and approved for public release on December 8, 2008. [43]
OpenCL 1.0 released with Mac OS X Snow Leopard on August 28, 2009. According to an Apple press release: [44]
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. [45] [46] RapidMind announced their adoption of OpenCL underneath their development platform to support GPUs from multiple vendors with one interface. [47] On December 9, 2008, Nvidia announced its intention to add full support for the OpenCL 1.0 specification to its GPU Computing Toolkit. [48] On October 30, 2009, IBM released its first OpenCL implementation as a part of the XL compilers. [49]
Acceleration of calculations with factor to 1000 are possible with OpenCL in graphic cards against normal CPU. [50] Some important features of next Version of OpenCL are optional in 1.0 like double- or half-precision operations. [51]
OpenCL 1.1 was ratified by the Khronos Group on June 14, 2010, [52] and adds significant functionality for enhanced parallel programming flexibility, functionality, and performance including:
On November 15, 2011, the Khronos Group announced the OpenCL 1.2 specification, [53] which added significant functionality over the previous versions in terms of performance and features for parallel programming. Most notable features include:
On November 18, 2013, the Khronos Group announced the ratification and public release of the finalized OpenCL 2.0 specification. [55] Updates and additions to OpenCL 2.0 include:
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. [56] 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:
AMD, ARM, Intel, HPC, and YetiWare have declared support for OpenCL 2.1. [57] [58]
OpenCL 2.2 brings the OpenCL C++ kernel language into the core specification for significantly enhanced parallel programming productivity. [59] [60] [61] It was released on May 16, 2017. [62] Maintenance Update released in May 2018 with bugfixes. [63]
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. [64] [65] [66] Version 3.0.7 of C++ for OpenCL with some Khronos openCL extensions were presented at IWOCL 21. [67] 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. [68] Last minor update was 3.0.14 with bugfix and a new extension for multiple devices. [69]
When releasing OpenCL 2.2, the Khronos Group announced that OpenCL would converge where possible with Vulkan to enable OpenCL software deployment flexibility over both APIs. [70] [71] This has been now demonstrated by Adobe's Premiere Rush using the clspv [39] open source compiler to compile significant amounts of OpenCL C kernel code to run on a Vulkan runtime for deployment on Android. [72] OpenCL has a forward looking roadmap independent of Vulkan, with 'OpenCL Next' under development and targeting release in 2020. OpenCL Next may integrate extensions such as Vulkan / OpenCL Interop, Scratch-Pad Memory Management, Extended Subgroups, SPIR-V 1.4 ingestion and SPIR-V Extended debug info. OpenCL is also considering Vulkan-like loader and layers and a "flexible profile" for deployment flexibility on multiple accelerator types. [73]
OpenCL consists of a set of headers and a shared object that is loaded at runtime. An installable client driver (ICD) must be installed on the platform for every class of vendor for which the runtime would need to support. That is, for example, in order to support Nvidia devices on a Linux platform, the Nvidia ICD would need to be installed such that the OpenCL runtime (the ICD loader) would be able to locate the ICD for the vendor and redirect the calls appropriately. The standard OpenCL header is used by the consumer application; calls to each function are then proxied by the OpenCL runtime to the appropriate driver using the ICD. Each vendor must implement each OpenCL call in their driver. [74]
The Apple, [75] Nvidia, [76] ROCm, RapidMind [77] and Gallium3D [78] implementations of OpenCL are all based on the LLVM Compiler technology and use the Clang compiler as their frontend.
As of 2016, OpenCL runs on graphics processing units (GPUs), CPUs with SIMD instructions, FPGAs, Movidius Myriad 2, Adapteva Epiphany and DSPs.
To be officially conformant, an implementation must pass the Khronos Conformance Test Suite (CTS), with results being submitted to the Khronos Adopters Program. [175] The Khronos CTS code for all OpenCL versions has been available in open source since 2017. [176]
The Khronos Group maintains an extended list of OpenCL-conformant products. [4]
Synopsis of OpenCL conformant products [4] | ||||
---|---|---|---|---|
AMD SDKs (supports OpenCL CPU and APU devices), (GPU: Terascale 1: OpenCL 1.1, Terascale 2: 1.2, GCN 1: 1.2+, GCN 2+: 2.0+) | X86 + SSE2 (or higher) compatible CPUs 64-bit & 32-bit, [177] Linux 2.6 PC, Windows Vista/7/8.x/10 PC | AMD Fusion E-350, E-240, C-50, C-30 with HD 6310/HD 6250 | AMD Radeon/Mobility HD 6800, HD 5x00 series GPU, iGPU HD 6310/HD 6250, HD 7xxx, HD 8xxx, R2xx, R3xx, RX 4xx, RX 5xx, Vega Series | AMD FirePro Vx800 series GPU and later, Radeon Pro |
Intel SDK for OpenCL Applications 2013 [178] (supports Intel Core processors and Intel HD Graphics 4000/2500) 2017 R2 with OpenCL 2.1 (Gen7+), SDK 2019 removed OpenCL 2.1, [179] Actual SDK 2020 update 3 | Intel CPUs with SSE 4.1, SSE 4.2 or AVX support. [180] [181] Microsoft Windows, Linux | Intel Core i7, i5, i3; 2nd Generation Intel Core i7/5/3, 3rd Generation Intel Core Processors with Intel HD Graphics 4000/2500 and newer | Intel Core 2 Solo, Duo Quad, Extreme and newer | Intel Xeon 7x00,5x00,3x00 (Core based) and newer |
IBM Servers with OpenCL Development Kit Archived August 9, 2011, at the Wayback Machine for Linux on Power running on Power VSX [182] [183] | IBM Power 775 (PERCS), 750 | IBM BladeCenter PS70x Express | IBM BladeCenter JS2x, JS43 | IBM BladeCenter QS22 |
IBM OpenCL Common Runtime (OCR) Archived June 14, 2011, at the Wayback Machine | X86 + SSE2 (or higher) compatible CPUs 64-bit & 32-bit; [185] Linux 2.6 PC | AMD Fusion, Nvidia Ion and Intel Core i7, i5, i3; 2nd Generation Intel Core i7/5/3 | AMD Radeon, Nvidia GeForce and Intel Core 2 Solo, Duo, Quad, Extreme | ATI FirePro, Nvidia Quadro and Intel Xeon 7x00,5x00,3x00 (Core based) |
Nvidia OpenCL Driver and Tools, [186] Chips: Tesla : OpenCL 1.1(Driver 340), Fermi : OpenCL 1.1(Driver 390), Kepler : OpenCL 1.2 (Driver 470), OpenCL 2.0 beta (378.66), OpenCL 3.0: Maxwell to Ada Lovelace (Driver 525+) | Nvidia Tesla C/D/S | Nvidia GeForce GTS/GT/GTX, | Nvidia Ion | Nvidia Quadro FX/NVX/Plex, Quadro, Quadro K, Quadro M, Quadro P, Quadro with Volta, Quadro RTX with Turing, Ampere |
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). [187] [188] [189]
Products and their version of OpenCL support include: [190]
All hardware with OpenCL 1.2+ is possible, OpenCL 2.x only optional, Khronos Test Suite available since 2020-10 [191] [192]
None yet: Khronos Test Suite ready, with Driver Update all Hardware with 2.0 and 2.1 support possible
A key feature of OpenCL is portability, via its abstracted memory and execution model, and the programmer is not able to directly use hardware-specific technologies such as inline Parallel Thread Execution (PTX) for Nvidia GPUs unless they are willing to give up direct portability on other platforms. It is possible to run any OpenCL kernel on any conformant implementation.
However, performance of the kernel is not necessarily portable across platforms. Existing implementations have been shown to be competitive when kernel code is properly tuned, though, and auto-tuning has been suggested as a solution to the performance portability problem, [195] yielding "acceptable levels of performance" in experimental linear algebra kernels. [196] Portability of an entire application containing multiple kernels with differing behaviors was also studied, and shows that portability only required limited tradeoffs. [197]
A study at Delft University from 2011 that compared CUDA programs and their straightforward translation into OpenCL C found CUDA to outperform OpenCL by at most 30% on the Nvidia implementation. The researchers noted that their comparison could be made fairer by applying manual optimizations to the OpenCL programs, in which case there was "no reason for OpenCL to obtain worse performance than CUDA". The performance differences could mostly be attributed to differences in the programming model (especially the memory model) and to NVIDIA's compiler optimizations for CUDA compared to those for OpenCL. [195]
Another study at D-Wave Systems Inc. found that "The OpenCL kernel’s performance is between about 13% and 63% slower, and the end-to-end time is between about 16% and 67% slower" than CUDA's performance. [198]
The fact that OpenCL allows workloads to be shared by CPU and GPU, executing the same programs, means that programmers can exploit both by dividing work among the devices. [199] This leads to the problem of deciding how to partition the work, because the relative speeds of operations differ among the devices. Machine learning has been suggested to solve this problem: Grewe and O'Boyle describe a system of support-vector machines trained on compile-time features of program that can decide the device partitioning problem statically, without actually running the programs to measure their performance. [200]
In a comparison of actual graphic cards of AMD RDNA 2 and Nvidia RTX Series there is an undecided result by OpenCL-Tests. Possible performance increases from the use of Nvidia CUDA or OptiX were not tested. [201]
OpenGL is a cross-language, cross-platform application programming interface (API) for rendering 2D and 3D vector graphics. The API is typically used to interact with a graphics processing unit (GPU), to achieve hardware-accelerated rendering.
LLVM is a set of compiler and toolchain technologies that can be used to develop a frontend for any programming language and a backend for any instruction set architecture. LLVM is designed around a language-independent intermediate representation (IR) that serves as a portable, high-level assembly language that can be optimized with a variety of transformations over multiple passes. The name LLVM originally stood for Low Level Virtual Machine, though the project has expanded and the name is no longer officially an initialism.
The Khronos Group, Inc. is an open, non-profit, member-driven consortium of 170 organizations developing, publishing and maintaining royalty-free interoperability standards for 3D graphics, virtual reality, augmented reality, parallel computation, vision acceleration and machine learning. The open standards and associated conformance tests enable software applications and middleware to effectively harness authoring and accelerated playback of dynamic media across a wide variety of platforms and devices. The group is based in Beaverton, Oregon.
Mesa, also called Mesa3D and The Mesa 3D Graphics Library, is an open source implementation of OpenGL, Vulkan, and other graphics API specifications. Mesa translates these specifications to vendor-specific graphics hardware drivers.
A free and open-source graphics device driver is a software stack which controls computer-graphics hardware and supports graphics-rendering application programming interfaces (APIs) and is released under a free and open-source software license. Graphics device drivers are written for specific hardware to work within a specific operating system kernel and to support a range of APIs used by applications to access the graphics hardware. They may also control output to the display if the display driver is part of the graphics hardware. Most free and open-source graphics device drivers are developed by the Mesa project. The driver is made up of a compiler, a rendering API, and software which manages access to the graphics hardware.
In computing, CUDA is a proprietary parallel computing platform and application programming interface (API) that allows software to use certain types of graphics processing units (GPUs) for accelerated general-purpose processing, an approach called general-purpose computing on GPUs (GPGPU). CUDA API and its runtime: The CUDA API is an extension of the C programming language that adds the ability to specify thread-level parallelism in C and also to specify GPU device specific operations. CUDA is a software layer that gives direct access to the GPU's virtual instruction set and parallel computational elements for the execution of compute kernels. In addition to drivers and runtime kernels, the CUDA platform includes compilers, libraries and developer tools to help programmers accelerate their applications.
nouveau is a free and open-source graphics device driver for Nvidia video cards and the Tegra family of SoCs written by independent software engineers, with minor help from Nvidia employees.
AMD FireStream was AMD's brand name for their Radeon-based product line targeting stream processing and/or GPGPU in supercomputers. Originally developed by ATI Technologies around the Radeon X1900 XTX in 2006, the product line was previously branded as both ATI FireSTREAM and AMD Stream Processor. The AMD FireStream can also be used as a floating-point co-processor for offloading CPU calculations, which is part of the Torrenza initiative. The FireStream line has been discontinued since 2012, when GPGPU workloads were entirely folded into the AMD FirePro line.
X-Video Bitstream Acceleration (XvBA), designed by AMD Graphics for its Radeon GPU and APU, is an arbitrary extension of the X video extension (Xv) for the X Window System on Linux operating-systems. XvBA API allows video programs to offload portions of the video decoding process to the GPU video-hardware. Currently, the portions designed to be offloaded by XvBA onto the GPU are currently motion compensation (MC) and inverse discrete cosine transform (IDCT), and variable-length decoding (VLD) for MPEG-2, MPEG-4 ASP, MPEG-4 AVC (H.264), WMV3, and VC-1 encoded video.
WebCL is a JavaScript binding to OpenCL for heterogeneous parallel computing within any compatible web browser without the use of plug-ins, first announced in March 2011. It is developed on similar grounds as OpenCL and is considered as a browser version of the latter. Primarily, WebCL allows web applications to actualize speed with multi-core CPUs and GPUs. With the growing popularity of applications that need parallel processing like image editing, augmented reality applications and sophisticated gaming, it has become more important to improve the computational speed. With these background reasons, a non-profit Khronos Group designed and developed WebCL, which is a Javascript binding to OpenCL with a portable kernel programming, enabling parallel computing on web browsers, across a wide range of devices. In short, WebCL consists of two parts, one being Kernel programming, which runs on the processors (devices) and the other being JavaScript, which binds the web application to OpenCL. The completed and ratified specification for WebCL 1.0 was released on March 19, 2014.
OpenACC is a programming standard for parallel computing developed by Cray, CAPS, Nvidia and PGI. The standard is designed to simplify parallel programming of heterogeneous CPU/GPU systems.
C++ Accelerated Massive Parallelism is a native programming model that contains elements that span the C++ programming language and its runtime library. It provides an easy way to write programs that compile and execute on data-parallel hardware, such as graphics cards (GPUs).
Heterogeneous System Architecture (HSA) is a cross-vendor set of specifications that allow for the integration of central processing units and graphics processors on the same bus, with shared memory and tasks. The HSA is being developed by the HSA Foundation, which includes AMD and ARM. The platform's stated aim is to reduce communication latency between CPUs, GPUs and other compute devices, and make these various devices more compatible from a programmer's perspective, relieving the programmer of the task of planning the moving of data between devices' disjoint memories.
OpenVX is an open, royalty-free standard for cross-platform acceleration of computer vision applications. It is designed by the Khronos Group to facilitate portable, optimized and power-efficient processing of methods for vision algorithms. This is aimed for embedded and real-time programs within computer vision and related scenarios. It uses a connected graph representation of operations.
Vulkan is a low-level, low-overhead cross-platform API and open standard for 3D graphics and computing. It was intended to address the shortcomings of OpenGL, and allow developers more control over the GPU. It is designed to support a wide variety of GPUs, CPUs and operating systems, and it is also designed to work with modern multi-core CPUs.
Standard Portable Intermediate Representation (SPIR) is an intermediate language for parallel computing and graphics by Khronos Group. It is used in multiple execution environments, including the Vulkan graphics API and the OpenCL compute API, to represent a shader or kernel. It is also used as an interchange language for cross compilation.
GPUOpen is a middleware software suite originally developed by AMD's Radeon Technologies Group that offers advanced visual effects for computer games. It was released in 2016. GPUOpen serves as an alternative to, and a direct competitor of Nvidia GameWorks. GPUOpen is similar to GameWorks in that it encompasses several different graphics technologies as its main components that were previously independent and separate from one another. However, GPUOpen is partially open source software, unlike GameWorks which is proprietary and closed.
SYCL is a higher-level programming model to improve programming productivity on various hardware accelerators. It is a single-source embedded domain-specific language (eDSL) based on pure C++17. It is a standard developed by Khronos Group, announced in March 2014.
ROCm is an Advanced Micro Devices (AMD) software stack for graphics processing unit (GPU) programming. ROCm spans several domains: general-purpose computing on graphics processing units (GPGPU), high performance computing (HPC), heterogeneous computing. It offers several programming models: HIP, OpenMP, and OpenCL.
oneAPI is an open standard, adopted by Intel, for a unified application programming interface (API) intended to be used across different computing accelerator (coprocessor) architectures, including GPUs, AI accelerators and field-programmable gate arrays. It is intended to eliminate the need for developers to maintain separate code bases, multiple programming languages, tools, and workflows for each architecture.