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.
OpenCL only looks useful for programs that don’t use the GPU at all. Using it on a game will take up precious rendering resources. If object rendering can be offloaded to the GPU and it’s faster then that will be good. Otherwise if objects could at least be threaded and really push all cores it should make a big difference. Objects and clouds seem to have the biggest performance impact, especially in a sim where they are so widespread. By the way I really like what you have planned with the cloud puffs vs distance from camera in XP10.
Well, not 100% sure I agree re: OpenCL. If the GPU is not 100% maxed out or the machine has two GPUs, and the problem that needs accelerating can’t easily be expressed in graphic terms, OpenCL could be useful. The structure of programs for OpenCL is different from both a traditional C program on the host CPU and pixel shaders.
It just happens to be that in X-Plane graphics makes the CPU slow, so OpenGL is more useful.
Perhaps a slightly misplaced question, but I will ask it anyway:
Are we going to be able to run multiple scenery views on one computer with X-plane 10, in contrast to X-plane 9? I am thinking of a situation with 6-8 fast CPU cores and a powerful graphics card (perhaps with SLI or CrossFire) running 3 projectors using matrox triplehead2go or ATI eyefinity setup. Then having three scenery views angled to, say, -70,0,+70 degrees with 70 degrees FOV on each. The same computer could also show panels on separate monitors using the same or another graphics card.
Is this going to be possible, or would this still require 4 networked computers?