HPCwire: OpenCL Update

Since 1986 - Covering the Fastest Computers
in the World and the People Who Run Them

Translation Disclaimer

Subscribe | Sign In

Visit additional Tabor Communication Publications

Leading HPC
Solution Providers

November 21, 2008

OpenCL Update

by Michael D. McCool and Stefanus Du Toit, RapidMind

OpenCL (the Open Computing Language) is under development by the Khronos Group as an open, royalty-free standard for parallel programming of heterogeneous systems. It provides a common hardware abstraction layer to expose the computational capabilities of systems that include a diverse mix of multicore CPUs, GPUs and other parallel processors such as DSPs and the Cell, for use in accelerating a variety of compute-intensive applications. The intent of the OpenCL initiative is to provide a common foundational layer for other technologies to build upon. The OpenCL standard will also have the effect of coordinating the basic capabilities of target processors. In particular, in order to be conformant with OpenCL, processors will have to meet minimum capability, resource and precision requirements. This article reviews the organizations and process behind the OpenCL standard proposal, gives a brief overview of the nature of the proposal itself, and then discusses the implications of OpenCL for the high-performance software development community.

The Khronos organization supports the collaborative development and maintenance of several royalty-free open standards, including OpenGL, OpenGL ES, COLLADA, and OpenMAX. OpenCL is not yet ratified, but the member companies involved have already arrived at a draft specification of version 1.0, which is currently under review. The OpenCL effort was initiated by Apple, and the development of the draft specification has included the active involvement of AMD, ARM, Barco, Codeplay, Electronic Arts, Ericsson, Freescale, Imagination Technologies, IBM, Intel, Motorola, Movidia, Nokia, NVIDIA, RapidMind, and Texas Instruments.

The OpenCL specification consists of three main components: a platform API, a language for specifying computational kernels, and a runtime API. The platform API allows a developer to query a given OpenCL implementation to determine the capabilities of the devices that particular implementation supports. Once a device has been selected and a context created, the runtime API can be used to queue and manage computational and memory operations for that device. OpenCL manages and coordinates such operations using an asynchronous command queue. OpenCL command queues can include computational kernels as well as memory transfer and map/unmap operations. Asynchronous memory operations are included in order to efficiently support the separate address spaces and DMA engines used by many accelerators.

The parallel execution model of OpenCL is based on the execution of an array of functions over an abstract index space. The abstract index spaces driving parallel execution consists of n-tuples of integers with each element starting at 0. For instance, 16 parallel units of work could be associated with an index space from 0 to 15. Alternatively, using 2-tuples, those 16 units of work could be associated with (0,0) to (3,3). Three-dimensional index spaces are also supported. Computational kernels invoked over these index spaces are based on functions drawn from programs specified in OpenCL C. OpenCL C is a subset of C99 with extensions for parallelism. These extensions include support for vector types, images and built-in functions to read and write images, and memory hierarchy qualifiers for local, global, constant, and private memory spaces. The OpenCL C language also currently includes some restrictions relative to C99, particularly with regards to dynamic memory allocation, function pointers, writes to byte addresses, irreducible control flow, and recursion. Programs written in OpenCL C can either be compiled at runtime or in advance. However, OpenCL C programs compiled in advance may only work on specific hardware devices.

Each instance of a kernel is able to query its index, and then do different work and access different data based on that index. The index space defines the "parallel shape" of the work, but it is up to the kernel to decide how the abstract index will translate into data access and computation. For example, to add two arrays and place the sum in an a third output array, a kernel might access its global index, from this index compute an address in each of two input arrays, read from these arrays, perform the addition, compute the address of its result in an output array, and write the result.

A hierarchical memory model is also supported. In this model, the index space is divided into work groups. Each work-item in a work-group, in addition to accessing its own private memory, can share a local memory during the execution of the work-group. This can be used to support one additional level of hierarchical data parallelism, which is useful to capture data locality in applications such as video/image compression and matrix multiplication. However, different work-groups cannot communicate or synchronize with one another, although work items within a work-group can synchronize using barriers and communicate using local memory (if supported on a particular device). There is an extension for atomic memory operations but it is optional (for now).

OpenCL uses a relaxed memory consistency model where the local view of memory from each kernel is only guaranteed to be consistent after specified synchronization points. Synchronization points include barriers within kernels (which can only be used to synchronize the view of local memory between elements of a work-group), and queue "events." Event dependencies can be used to synchronize commands on the work queue. Dependencies between commands come in two forms: implicit and explicit. Command queues in OpenCL can run in two modes: in-order and out-of-order. In an in-order queue, commands are implicitly ordered by their position in the queue, and the result of execution must be consistent with this order. In the out-of-order mode, OpenCL is free to run some of the commands in the queue in parallel. However, the order can be constrained explicitly by specifying event lists for each command when it is enqueued. This will cause some commands to wait until the specified events have completed. Events can be based on the completion of memory transfer operations and explicit barriers as well as kernel invocations. All commands return an event handle which can be added to a list of dependencies for commands enqueued later.

In addition to encouraging standardization between the basic capabilities of different high-performance processors, OpenCL will have a few other interesting effects. One of these will be to open up the embedded and handheld spaces to accelerated computing. OpenCL supports an embedded profile that differs primarily from the full OpenCL profile in resource limits and precision requirements. This means that it will be possible to use OpenCL to access the computational power of embedded multicore processors, including embedded GPUs, in mobile phones and set-top boxes in order to enable high-performance imaging, vision, game physics, and other applications. Applications, libraries, middleware and high-level languages based on OpenCL will be able to access the computational power of these devices.

In summary, OpenCL is an open, royalty-free standard that will enable portable, parallel programming of heterogeneous CPUs, GPUs and other processors. OpenCL is designed as a foundational layer for low-level access to hardware and also establishes a level of consistency between high-performance processors. This will give high-performance application and library writers, as well as high-level language, platform, and middleware developers, the ability to focus on higher-level concerns rather than dealing with variant semantics and syntax for the same concepts from different vendors. OpenCL will allow library, application and middleware developers to focus their efforts on providing greater functionality, rather than redeveloping code or lower-level interfaces to each new processor and accelerator.