The HPEC (High Performance Embedded Computing) industry is embracing the amazing processing power of GPU processing. It becomes a drug to developers when they get over the learning curve, and get accustomed to the significant performance advantage the GPU has over the CPU. They look back and wonder why they didn’t make the transition sooner. Each new algorithm they create, they want to know if it would be processed on the GPU faster than the CPU. It’s just a matter of taking the same C or C++ code and just remove some outer loops. Over time, it becomes an addiction.
The primary GPU technologies (for processing) are NVIDIA’s CUDA and the open standard OpenCL. There are also higher level software APIs built on CUDA and OpenCL, such as OpenCV (open source) and OpenVX (open standard), which simplify image processing. All these software APIs include many quality GPU algorithms: FFTs, convolutions, image processing, signal processing, linear algebra, etc. Developers find that there is less need to roll their own algorithms.
There is, though, still one very big hurdle to cross in the GPU world: high performance visualization. GPUs were designed for 2D and 3D visualization decades ago, so results that were processed and live in GPU memory should be easy to display—right?
Not so much.
Different paradigm
OpenGL (an open standard) is the mostly widely used display engine for GPUs and has been around for many years. Unfortunately, it’s not like traditional CPU-based display engines that have simple commands to draw text, lines, boxes, circles, images, etc. OpenGL doesn’t have any APIs like that. It’s a completely different paradigm for displaying.
What’s worse is that OpenGL doesn’t even have the ability to create a display window for your desktop or device screen. Yet another open standard called EGL was created for that, but unfortunately it’s not even portable. Third party APIs like GLUT, SDL, or Qt are used to create the display window. It’s crazy how complex it is to natively display on a GPU.
So what does a developer do to display results sitting in GPU memory? Well, the easy way is to just copy the results back to the CPU, and then use a traditional CPU graphics API to easily display the results—which implicitly copies the data right back to the GPU. It’s a real downer after you just got your algorithm to run extremely fast on the GPU—and then displaying the results just kills performance.
The seemingly ideal solution would be to become an OpenGL expert. Once you learn it, you’ll realize what used to be a single line of code in a CPU graphics engine may now be hundreds of lines of code in OpenGL. There’s still one more thing to learn after that: interoperation between OpenGL and general purpose GPU technologies.
Not trivial, not intuitive
Even the interoperation is not trivial; it requires a lot of source code and it’s far from intuitive. In the HPEC industry, things need to be done quickly with high quality. OpenGL and the interoperation with GPU processing technologies require a lot of source code and maintenance, so even the experts with OpenGL are discouraged from using it. The HPEC industry needs high productivity and low cost, and OpenGL and its interoperation are large barriers.
Developers are addicted to GPU processing, and they need to find a way to interoperate with OpenGL to complete the GPU picture.
Well, now they have one. ImageFlex is Abaco’s new GPU-based high performance image processing and visualization toolkit. It simplifies interoperation between OpenGL and most other general purpose GPU processing technologies. You can find out much more about it here.
It could be that we just provided those developers with a whole new addiction. As if being addicted to GPU processing wasn’t enough, they can now get addicted to GPU visualization.
