- Jeff Bier’s Impulse Response—Why Do Embedded Processor Software Development Tools Suck? It’s the Unknown Knowns
- Jeff Bier’s Impulse Response—When Comparing Processors, Beware of the Uncertainty Principle
- Jeff Bier’s Impulse Response—A Tale of Two Chips
- Jeff Bier’s Impulse Response—The Memory Bandwidth, Stupid!
- Jeff Bier’s Impulse Response—Neural Network Processors: Has Their Time Come?
Jeff Bier’s Impulse Response―Unleashing Mobile Multimedia Applications, Part 2
Last month I made the case that multimedia applications are central to the value of smart phones and tablets. I also pointed out that it is difficult for app developers to utilize the multimedia processing power of these devices, which mainly resides in specialized coprocessors. These coprocessors are difficult for application developers to use for two reasons. First, while the vast majority of application processors use ARM CPUs, there’s a great deal of diversity in coprocessors—but app developers can’t afford to write separate versions of their applications for each different set of coprocessors. Second, application processor suppliers generally don’t allow app developers to program their coprocessors–typically because they aren’t equipped to provide support for large numbers of developers.
The obvious solution to this problem is a common application programming interface (API) that app developers could use to enable multimedia applications to be written once, and then to run on any processor, automatically making use of relevant coprocessors when available. And indeed, there have been some attempts at this, such as the OpenMax family of APIs. But none of these existing APIs have yet caught on in a major way with mobile application developers. In part, I think that’s because the existing APIs tend to be designed to support specific types of applications, which means that they’re often not well suited to the next wave of applications.
Lately, however, OpenCL has begun to emerge as a promising potential solution to the needs of application developers across a broad range of applications (including multimedia applications). Unlike application-domain-specific APIs, OpenCL is a programming language and set of APIs for parallel programming that can be used for any application that is parallelizable.
OpenCL was originally developed to enable personal computer application developers to harness the massive parallel computing power of modern graphics processing units (GPUs) for tasks other than rendering 3D graphics. This concept, often called “GPU computing” or “general-purpose GPU,” was pioneered by NVIDIA with its CUDA technology. But CUDA has one major disadvantage: it is unique to NVIDIA chips. OpenCL, in contrast, can be enabled by any GPU supplier that chooses to do so.
What makes this relevant to mobile applications is that OpenCL support is starting to appear for the GPUs found in mobile application processors, such as those offered by Imagination Technologies and Vivante. And while the GPUs found in application processors don’t offer anything close to the eye-popping processing power of desktop GPUs, they are nevertheless powerful and energy-efficient parallel processors.
In addition to its applicability to a wide range of applications, and to its broad support among silicon providers, OpenCL has another important attractive attribute: it is not architecture-specific. Though originally targeted at GPUs, OpenCL can be supported on a variety of parallel processing architectures. For example, Altera has described an OpenCL implementation targeting FPGAs. While I don’t expect to see FPGAs doing parallel computing in handsets anytime soon, the fact that OpenCL can be used across architectures as different as GPUs and FPGAs is encouraging, and suggests that it may eventually enable access not only to the GPUs in mobile application processors, but also to other parallel processing engines in these chips.
So, will OpenCL finally make it practical for large numbers mobile multimedia application developers to harness the parallel processing power of the coprocessors found in application processor chips? I think OpenCL has a fighting chance, but it’s by no means a sure thing.
One factor working against OpenCL in the mobile domain is that it is based on the C language, whereas most mobile application developers work in more modern, higher-level languages. More fundamentally, parallel programming is parallel programming, regardless of the language or API used. And parallel programming is a profoundly different type of programming from what most application developers are accustomed to. (I can still remember the way my head hurt during the first few weeks of my first class on parallel programming.) For OpenCL, or any other parallel-programming-enabling paradigm to really take off, a huge amount of education will be needed.
I’m hoping that OpenCL does succeed, at least for the vanguard of intrepid mobile app developers, because I can’t wait to see what results when the creativity of these developers is combined with the energy-efficient parallel processing capabilities available in mobile devices.