Parallel programming model adopted by AMD, Nvidia, among others

The graphics processor that's typically relegated to the process of filling triangles in geometric space with color, took a huge step closer to becoming an all-purpose code execution tool today, with the ratification of OpenCL 1.0.

Most PCs today have a minimum of two extraordinarily powerful processing mechanisms, and I'm not talking about "cores." The first is a compilation of multiple cores -- today, more often as many as four per unit, for 16 in a four-way server. The second uses a fundamentally different architecture, designed for pipelining identical instructions that are repeated tens of thousands of times, to be executed in parallel, in a process that on paper resembles the stretching and folding of taffy.

But for most computer users, only the core structure is utilized for everyday tasks. And in retrospect, it's obvious that a huge opportunity has been missed for as long as the past decade -- a chance to use the GPU, which for everyday tasks can be relatively dormant, for more than just graphics. To take advantage of that opportunity, however, the complexities of pairing any one manufacturer's set of cores with any other's assembly of pipelines, must be masked from the software developer, who must pay attention to the task of making his application crunch numbers.

So today, Khronos Group -- the consortium of manufacturers and developers born out of the project that made the OpenGL 3D graphics libraries -- has formally published its 1.0 specification for Open Computing Language (OpenCL). Essentially, this is a toolset for constructing applications that can leverage any grouping of CPUs and GPUs, running any operating system, to perform high-speed parallel processing tasks.

But OpenCL is not an API or a high-level language library of the usual sort, and because of that, it will require a fairly steep learning curve. OpenCL programs truly are programs unto themselves, written using a variant of C and compiled using their own compiler. The results are task-specific nuggets of code called kernels, using the classic nomenclature for raw components that don't require other libraries. These kernels become the libraries of the computer which houses them.

In OpenCL architecture, the processing space for kernels is mapped out in two-dimensional space -- a fact which is specifically related to the GPU architecture being leveraged here. The total capacity of the processor units available to the system, regardless of where they reside in the system or network, or perhaps even whether they're physical or virtual, becomes what OpenCL calls the index space. Here, tasks are assigned geometric locations in a process similar to the way pipelining determines where to shade texels in a memory image of graphics. Tasks that can be replicated for parallel processing, are replicated, and each instance becomes a work item.

But the realm in which these work items reside isn't Windows, isn't Linux, isn't Mac. It's a completely different universe of computing. Its contact with the world where we live and work is the host program, which is the conventional application that's written in the native language(s) of our choice. Rather than an API, the host program issues commands in the language of the OpenCL work items, which each await their turn in a command queue. Using the available processing power from the available GPUs and perhaps the CPUs, the kernels accept the commands in sequence, but perform their tasks asynchronously and report back when they're done.

Rather than returning their results to the function that called them, like in classical programming, OpenCL work items generate event objects that represent the results of their job -- the complete solution to the task at hand, using whatever data structure is required.

Principal contributors to the OpenCL project hail from AMD, Apple, ARM, Broadcom, Electronic Arts, IBM, Intel, Nvidia, and Texas Instruments.