A commenter asked if we were planning to use a GPGPU API in X-Plane 10 or beyond. I really can’t answer for the far future, but I can say that we aren’t planning to use GPGPU for X-Plane 10. This post will explain a little bit about what GPGPU is and why we haven’t jumped on it yet.
Every new technology adoption has an adoption cost. So the question of GPGPU isn’t just “will it help” but “is it better than the alternative uses of our time”. For example, do we spend time coding GPGPU, or do we spend time optimizing the existing code to run faster on all hardware? But this post is about GPGPU itself.
GPGPU stands for General Purpose programming on Graphics Processing Units – the Wiki article is a bit technical, but the short of it is: graphics cards have become more and more programmable, and they are highly powerful. GPGPU technologies allow you to write programs that run on the GPU other than graphics.
There are two major APIs for writing GPGPU programs: OpenCL and CUDA. OpenCL is designed to be an open standard and is heavily backed by Apple and ATI; CUDA is NVidia specific. (At least, I don’t think you can can get CUDA to run on other GPUs.) I believe that NVidia does support OpenCL with their hardware. (There is a third compute option, DirectCompute, that is part of DX11, but that is moot for X-Plane because we don’t use Windows only technologies.
If that seemed confusing as hell, well, it is. The key to understanding the alphabet soup is that there are API standards (which essentially define a language for how a program talks to hardware) and then there are actual pieces of hardware that make applications that use that language fast. For drawing, there are two APIs (OpenGL and Direct3D) and there are GPUs from 2+ companies (ATI, NVidia, and those other companies whose GPUs we make fun of) that implement the APIs with their drivers.
The situation is the same for GPGPU as for graphics: there are two APIs (CUDA and OpenCL) and there is a bunch of hardware (from ATI and NVidia) that can run some of those APIs.*
So the question then is: why don’t we use a GPGPU API like OpenCL to speed up X-Plane’s physics model? If we used OpenCL, then the physics model could run on the GPU instead of on the CPU.
There are two reasons why we don’t use OpenCL for the physics engine:
- OpenCL and CUDA programs aren’t like “normal” programs. We can’t just pick up and move the flight model to OpenCL. In fact, most of what goes on in the flight model is not code that OpenCL would be particularly good at running.
- For a GPGPU program to be fast, it has to be running on the GPU. That’s where the win would be: moving work from the poor CPU to the nice fast GPU. But…we’re already using the GPU – for drawing!
And this gets to the heart of the problem. The vast majority of the cost of the flight model comes from interaction with the scenery – a data structure that isn’t particularly GPU-friendly at this point. Those interactions are also not very expensive in the bigger picture of X-Plane, particularly when the AI aircraft are threaded.
The biggest chunk of CPU time is being spent drawing the scenery. So to make X-Plane faster, what we really need to do is move the graphics from the CPU to the GPU – more time spent on the GPU on less time on the CPU for each frame of drawing we run through.
And the answer for why we don’t use OpenCL or CUDA for that should be obvious: we already have OpenGL!
So to summarize: CUDA and OpenCL let you run certain kinds of mathematically intense programs on the GPU instead of the CPU. But X-Plane’s flight model isn’t that expensive for today’s computers. X-Plane spends its time drawing, so we need to move more of the rendering engine to the GPU, and we can do that using OpenGL.
* Technically, your CPU can run OpenGL via software rendering. The results look nice, but aren’t fast enough to run a program like X-Plane. Similarly, OpenCL programs can be run on the CPU too.