Board index FlightGear Development Google Summer of Code

OpenCL support for FlightGear (GPGPU programming)

Project proposals, student applications and all related discussions.

OpenCL support for FlightGear (GPGPU programming)

Postby Hooray » Tue Oct 11, 2011 4:47 pm

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):

http://www.khronos.org/opencl/
OpenCL™ is the first open, royalty-free standard for cross-platform, parallel programming of modern processors found in personal computers, servers and handheld/embedded devices. OpenCL (Open Computing Language) greatly improves speed and responsiveness for a wide spectrum of applications in numerous market categories from gaming and entertainment to scientific and medical software.


http://en.wikipedia.org/wiki/OpenCL
OpenCL (Open Computing Language) is a framework for writing programs that execute across heterogeneous platforms consisting of CPUs, GPUs, and other processors. OpenCL includes a language (based on C99) for writing kernels (functions that execute on OpenCL devices), plus APIs that are used to define and then control the platforms. OpenCL provides parallel computing using task-based and data-based parallelism. It has been adopted by Intel, AMD, ATI, and ARM. OpenCL is an open standard defined by the Khronos Group.

OpenCL gives any application access to the graphics processing unit for non-graphical computing. Thus, OpenCL extends the power of the Graphics Processing Unit beyond graphics (general-purpose computing on graphics processing units).

OpenCL is analogous to the open industry standards OpenGL and OpenAL, for 3D graphics and computer audio, respectively.




Overview:



Tutorials


Specs:

Reference:
http://www.khronos.org/registry/cl/sdk/ ... man/xhtml/
http://www.khronos.org/developers//opencl/

More videos:
http://www.multicoreinfo.com/2011/03/parprog-part-9u/


Also see: viewtopic.php?f=6&t=17034&p=162483#p162415
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 10757
Joined: Tue Mar 25, 2008 8:40 am

OpenCL

Postby sgofferj » Thu Jul 19, 2012 7:57 pm

Hi,

I'm still in the middle of a project but I am having quite some interesting stuff here. There is a strong-crypto subproject which uses FPGAs with OpenCL. I have learned that also the ATI and NVIDIA GPU drivers support OpenCL in addition to their proprietary stuff (CUDA, etc.). During a presentation, the tech-guy said that e.g even modern game engines also use CUDA or OpenCL for the physics engine and those hypothetically could also run on the FPGAs then.
I was wondering if anybody has ever given thought to this stuff. Considering that a reasonably good GPU has about 20x the computing power of a quadcore CPU, using OpenCL as some kind of abstraction layer (there's also OpenCL implementations for CPUs, of course) would be a hell of a cool thing.
Power users or people who want to build simulators for "real" training could just buy another GPU or an FPGA board to get an extreme performance boost.

-Stefan
FG 3.1 GIT / Opensuse 12.3 / Phenom II X4 / GForce GTX560
Stefan's little Flightgear corner | The Finnish Weather Center | Wolves in Finland

Working on: EFTP
COM: IAX2:home.gofferje.net/stefan (MO-FR 0700-2000 UTC, SA+SU 0900-2000 UTC)
sgofferj
 
Posts: 790
Joined: Mon Dec 05, 2011 4:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: OpenCL

Postby Hooray » Fri Jul 20, 2012 9:11 pm

sgofferj wrote in Thu Jul 19, 2012 7:57 pm:Power users or people who want to build simulators for "real" training could just buy another GPU or an FPGA board to get an extreme performance boost.


The thing is, OpenCL-based parallelization 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.

Like I said, you won't get anything "for free" automatically. If you are looking for better use of idle resources, then OpenMP is far easier to adopt and support.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 10757
Joined: Tue Mar 25, 2008 8:40 am

Re: OpenCL

Postby sgofferj » Fri Jul 20, 2012 9:27 pm

Hooray wrote in Fri Jul 20, 2012 9:11 pm: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.

From what I understood from this presentation, there's also OpenCL drivers for Intel and AMD CPUs exactly to avoid the need for double coding and for easy scalability.

But I think, I get your other points.
Well, it was just an idea...
FG 3.1 GIT / Opensuse 12.3 / Phenom II X4 / GForce GTX560
Stefan's little Flightgear corner | The Finnish Weather Center | Wolves in Finland

Working on: EFTP
COM: IAX2:home.gofferje.net/stefan (MO-FR 0700-2000 UTC, SA+SU 0900-2000 UTC)
sgofferj
 
Posts: 790
Joined: Mon Dec 05, 2011 4:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: OpenCL support for FlightGear (GPGPU programming)

Postby Hooray » Fri Jul 20, 2012 9:35 pm

Yes, there are CPU wrappers - however, 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://forums.x-plane.org/index.php?showtopic=56808
http://forums.xplanefreeware.net/topic/ ... -and-cpus/
http://stackoverflow.com/questions/4005 ... ith-opengl
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 10757
Joined: Tue Mar 25, 2008 8:40 am


Return to Google Summer of Code

Who is online

Users browsing this forum: No registered users and 1 guest