I hope this is not needless repost but I was unable to find any info regarding this.

According to PoverVR SGX (The GPU on N900) fact sheet the chip ought to support OpenCL embedded profile and they are currently developing drivers for it. Are the OpenCL drivers eventually included in Fremantle or in future releases?

Considering the potential increase of available computing power combined with ease of development for Maemo platform I would rank this as a rather high priority for heavy duty multimedia applications and, this is my personal agenda, for signal processing/mobile data analysis purposes.

Small example application:
Add a AD converter as a USB device and you'll have cheap mobile oscilloscope with data-analysis (e.g FFT) performed via OpenCL.

If/When can we except OpenCL support?

Good question, and OpenCL sounds useful. Note that as far as we know so far the N900 won't support USB host mode (see http://talk.maemo.org/showthread.php?t=31921) so your particular use case may not be possible.

Shame about the lack of host mode.
I had plans to use N900 as a platform for applications similar such as this:
http://www.techshout.com/gadgets/200...sound-imaging/

Thankfully Bluetooth can be used as a replacement (Or make the client emulate an USB host). In order to keep the thread on topic the example ought to be considered disregarding the USB limitation.

I'd imagine the DSP would be better suited and have more power to do FFT...

Could OpenCL be used to address the DSP with proper drivers? (I know next to nothing about opencl atm...)

OpenCL aims at using graphics chip to perform specific operations which take a lot of time on the CPU. Usually, this is done when trying to enhance the speed of floating point operations, etc.

ARM works quite differently than the usual x86 platform (or PPC, for that matter). I'm not saying it wouldn't be useful, I'm saying it would be less useful that the performance gain you get on proper desktops/laptops.

The DSP, as was pointed out, will give pretty good performance when used properly, and developing for the DSP directly will be a lot easier than trying to write a wrapper that would then be used by a yet-to-be-written port of OpenCL. Let's not forget this is a limited hardware platform, and the more you wrap, the more you lose.

Think of it as a hot water bottle that you put in bed during cold winter nights. You can wrap it with a big towel, so you don't burn your beloved feet, but in the end, you'll lose some potential heating power. It's up to you to see how much performance you need.

That being said, using bluetooth/wifi to provide connectivity to your sensor, and then doing CPU/DSP intensive operations is going to be a big battery drainer.

(Disclaimer: I didn't read the link) Are you really sure the idea is sound?

There was a port scudding about on the N810 wasn't there?

Best bet would be to compile that and take a look at which operations could usefully be performed on the DSP (and the PowerVR too may even be possible), then convert (i.e. make the fn a wrapper to run code on the DSP) some functions and see if it's faster.

I'm interested anyway.

Second.

Although it may not have many real-world uses today, if the library is there, it may have a very real future benefit on newer hardware and can reach maturity when those use-cases become viable.

}:^)~

Would there be much interest in e.g. a widget you could use to offload larger, more complex operations onto your desktop PC or local supercomputer?

With a linux host and the special restricted clone call, it ought to be (securely) doable with native code, let alone embedding and sandboxing a parrot, mono, or java VM.

That is why we already run applications on remote computer with e.g. SSH (withand without X11 forwarding), and why ccache is useful to offload compilation to other computers.