Is OpenCL The Next API of Fashion?
The Khronos Group held a technical briefing at SC08 to present the current state of play and plans for the OpenCL standard. The Khronos Group is a non-profit consortium whose members are all the major players in the dynamic media business – think graphics cards manufacturers and media-based systems manufacturers (televisions, PDAs, phones, music payers, etc.). Its members include Apple (who were the moving force), IBM, AMD, NVIDIA, Intel, Nokia, Freescale and so on. We estimate 100+ participants in the Khronos consortium based on the presentation slides. The purpose of the Khronos Group is to create industry-wide, open standards for all things media centric. The best known standard coming from the Khronos Group to date is OpenGL.
Why create a new standard? The members of the Khronos Group decided that there needed to be an open-standard API for handling the gamut of hardware associated with media presentation. In effect this is mostly about trying to provide some form of coherence in the “How to program GPUs” space. The various hardware vendors were each creating new hardware and software development frameworks, and it became clear to the Khronos Board that the ensuing division was likely to lead to chaos in the markets they compete in. So work was started to define an API that would enable some element of uniformity and hence allow operating system and media-based systems manufacturers to have a single API applicable to the gamut of hardware.
Normally, splintering to create lock-in is a way of ensuring market share or even monopoly. Why should the hardware manufacturers choose to introduce a common API and hence “commoditize” their product? If they don’t then the product manufacturers would have to make a choice and probably plump for a single provider – and they might not choose the obviously expected provider. Programmability and usability are powerful factors here rather than just sheer speed of processing which is the usual metric for things like graphics cards. As a share of a huge market is a better risk than all of a small market, or none of a big market, the business imperative is fairly obvious.
Having decided to create a standard the consortium is going for a record as far as completion is concerned. It started work on it in earnest in the summer and according to Neil Trevett, its President (from AMD), it hopes to announce the standard at SIGRAPH Asia in early December. Whether this will be in time for Apple to use it in Snow Leopard remains to be seen.
Why is this a parallelism issue? All the graphics engines are themselves multicore and multiprocessor systems – they are supercomputers on a board, cf. GPGPU including the CUDA-programmable GeForce cards, Tesla, Intel's Larrabee (when it arrives), Firestream and so on. Programming languages have no standard way of addressing these parallel processors. GPGPU APIs came and went, CUDA came and is still being mulled over. The core (!) idea was right but something more industry wide was demanded, hence OpenCL. OpenCL provides an API for programming these highly parallel machine with an element of abstraction – to hide the details of the hardware – whilst providing mechanisms for low-level control of the hardware. Given the low-level nature of the task, it seems natural to use a programming language such as C. Not only is this probably the right programming language to start with, it is the one the players have most experience of providing.
So OpenCL provides a memory model to provide an abstract description of the hardware, and an execution model to determine how code executes on all the processors available. The problem is that the OpenCL memory and execution models appear inconsistent with the memory model being introduced by the C++0x standard (which is currently in the final stages of ratification by ISO). This means that the OpenCL API is not directly usable from C++. It is a C-only API. Moreover, none of the member representing the Khronos Group at the briefing appeared to be interested in discussing Java support.
One of the representatives of the Khronos Group claimed that C++ support was important for OpenCL, but reluctantly admitted that it was an issue of separation, wrappers and clever compilation of C components with C++ code. Clearly this is a feasible way forward, but it is going to be clumsy and irritating in reality. The Khronos Group is clearly prioritizing C developers over C++ developers in a way that will likely lead to some conflict.
Java support appeared to have been brushed aside as almost an irrelevance. This seems surprising, particularly as some of the board members are actively involved in developing systems for mobile phones and PDAs, where Java (in the form of Java ME) is an important factor. It is certainly true that Java, via JNI, has the ability to make use of C code, but the question is how does the Java memory and execution models interact, or interfere, with the OpenCL memory and execution models. It appears that this is simply being left as an open question. There is no doubt that some solution will be found for compatibility between OpenCL and C++ and Java, hopefully it will be sooner rather than later.
OpenCL will clearly handle shared-memory devices adequately with low core counts (fewer than sixteen). Whether or not OpenCL will be able to address the longer-term issues of rising core counts and non-shared memory is very much something that the jury is out on just now. Whilst the consortium clearly has the capability within it to handle this issue, it appears that the consortium as a whole has not yet addressed it.
Overall though OpenCL is going to be good, in the same way that OpenGL has been good. There are crufty bits, but overall having a standard has improved the end user experience and hence created more income for the manufacturers and vendors. The real worry is that the standard is being rushed; it is being finalized at break-neck speed. We just have to hope that the undoubted experience and capability of the people involved means they can deal with things sensibly despite the speed of activity. Only time will tell, but OpenCL is definitely on Concertant's “one to watch” list.