OpenCL in FlightGear
| This article is a stub. You can help the wiki by expanding it. |
| Started in | 12/2015 |
|---|---|
| Description | Provides basic OpenCL integration |
| Maintainer(s) | Hooray |
| Contributor(s) | Hooray (since 12/2015) |
| Status | Under active development as of 12/2015 |
| Multicore |
|---|
|
Configuration |
|
Ongoing Efforts |
|
Proposals & RFCs |
|
Background |
|
For developers |
Motivation
|
has anybody thought about using OpenCL |
|
|
|
there's also OpenCL drivers for Intel and AMD CPUs exactly to avoid the need for double coding and for easy scalability. |
|
|
|
OpenCL is about "kernels" (like your GLSL kernels), that can be executed on CPUs, just as well as on GPUs, but also on dedicated FPGA hardware. — Hooray (Dec 29th, 2015). Re: FGPython an propose for Python as an nasal alternative.
(powered by Instant-Cquotes) |
|
|
|
the point of this being that algorithms implemented in OpenCL can also be executed on an idle CPU core, so don't need to utilie GPU hardware at all.
You can get massive concurrency using OpenCL kernels, even beyond the typical "embarrasingly-parallel" stuff that lends itself to be executed on GPU hardware. — Hooray (Dec 29th, 2015). Re: FGPython an propose for Python as an nasal alternative.
(powered by Instant-Cquotes) |
|
|
|
the main advantage of OpenCL would be parallelism, but psadro_gm once explained to me that there's very little paralleliation opportunities left in TG code apparently. |
|
|
|
OpenCL runs stuff on the graphics card. I happen to know a few folks who ported fluid dynamics codes to OpenCL because you get a factor ~100 more performance that way. Despite that, they had pretty mixed feelings, because the results they got changed with every update of the graphics card driver. Um... yeah. It's not trivial to run accurate numerical code on floating point precision in the first place, and graphics cards sometimes, you know, do funny things. In rendering, it means the color value of some pixels might come out odd and often we can just shrug it off. In numerics - it means you're screwed. — Thorsten (Dec 29th, 2015). Re: FGPython an propose for Python as an nasal alternative.
(powered by Instant-Cquotes) |
|
|
|
We were recently talking about this in the context of speeding up the local weather system even more, the local weather system is increasingly sped up by moving more and more stuff out of Nasal space into C++ and particularly OpenGL/Shader space, so that the use of Nasal is no longer the primary bottleneck.
Moving computations out of Nasal and C++ onto the GPU is particularly intriguing as code running on the GPU is by design inherently concurrent, while code running inside Nasal (but also C++) space must be made concurrent explicitly, which is often very much complicated and tedious due to FlightGear's architecture. FlightGear's support for effects and shaders makes it possible to offload certain graphics-related computations onto the GPU, so that the CPU becomes more responsive and also more available for other computations. This is a good thing for FlightGear, because it basically means that the FlightGear main loop can run at higher update rates. Unfortunately, shaders are not suitable for all sorts of computations, such as computations that may be complex but not directly related to graphics or the runtime model employed by shaders. That means for example that certain computations may be done inefficiently (redundantly) because of the way shaders are invoked for each pixel, vertex or fragment. However, OpenCL provides support for offloading even more (non-graphics related) computations onto the GPU, so that general purpose computing becomes possible using the GPU, but also other processors in general. This is done by providing standalone "kernels" written in C-like language, pretty much similar to how shader programming works already in FlightGear (i.e. plain text source code files, transparently compiled by GPU drivers): |
|
Background
|
|
OpenCL-based paralleliation isn't automatically feasible for all sorts of computations in FlightGear, there's tons of stuff going on in FlightGear which wouldn't/couldn't directly benefit from OpenCL parallelization. There are really only a handful of scenarios currently where OpenCL may actually help provide better runtime performance. And that would require explicit coding, i.e. by moving certain code out of C++/Nasal into OpenCL, which requires reimplementing certain algorithms.
On the other hand, OpenCL is really only meant to be used as a "workhorse", so it would need to be interfaced to the FG property tree, so that its results can be actually used by other subsystems. In order to speed up FlightGear, you don't just need to throw better/faster hardware at it, you need to understand where FlightGear is slow, and why it is slow. Even today most of us have plenty of idle CPU cores and idle GPU power when running FlightGear, so the lack of hardware and idle resources is really not the problem, the real issue is leveraging all this horsepower. See for example this discussion which took place on the jsbsim RFE tracker, it was about running JSBSim on physX or CUDA hardware, as was pointed out by some users: the FDM could definitely be ported to run on the GPU, but that wouldn't necessarily have the desired effect on FlightGear framerate/performance. Now, for the FlightGear side of things, OpenCL support would obviously need to be optional, so that it is not required on platforms missing OpenCL. That would inevitably mean, that there needs to be a fall back path for such systems. OpenCL would only really be useful for very specific projects, like for example weather simulation or high fidelity physics computations (complex FDMs). At the moment, we don't have any code which could really benefit from OpenCL. And regarding legacy C++ code, it is MUCH easier to parallelize it using OpenMP rather than OpenCL. Don't get me wrong, OpenCL support would/will definitely be great - but it will just be a technology enabler, it will not speed up any of the existing code in FlightGear - it will only be useful for new projects, and it will require that people actually learn OpenCL and how to interface OpenCL code to existing FG systems. To me, it is out of question that FlightGear will eventually get support for OpenCL - just look at how FlightGear now has shader support (and if you know C++. it isn't that difficult to reimplement a "HelloWorld" example within FlightGear), the real question is how that is going to be useful and used within the time to come. |
|
Status
RFC/Proof-of-concept (See below)
Implementation
|
|
obviously these require driver-support. If you don't have the OpenCL drivers installed, OpenCL programs will not run. In other words, people would need to make sure that they have OpenCL drivers installed for the GPU/CPU.
Also see: http://developer.x-plane.com/2011/05/why-not-gpgpu/ http://stackoverflow.com/questions/4005935/mix-opencl-with-opengl |
|
Integration
- fgcommands
- autopilot/property rules
- Nasal
- SGSubsystem