Opencl On Omap

[klikklak]

I don't follow this forum that much (I get enough from the blog), so maybe this has been asked:

What are the chances of having an openCL implementation for Pandora? I suppose it's dependant on the closed source drivers and ARM or the reverse engineering efforts that I heard of. And I'll ask another silly question: Could OpenCL be used for emulators in some way? OpenGL as such wouldn't help say mame that much, besides screen scaling, but if there's some tasks that can be pushed to the graphics chip it would be neat.

 

[maciek_urbanski]

I don't follow this forum that much (I get enough from the blog), so maybe this has been asked:

What are the chances of having an openCL implementation for Pandora? I suppose it's dependant on the closed source drivers and ARM or the reverse engineering efforts that I heard of. And I'll ask another silly question: Could OpenCL be used for emulators in some way? OpenGL as such wouldn't help say mame that much, besides screen scaling, but if there's some tasks that can be pushed to the graphics chip it would be neat.

Hmm, I didn't heard about any plans of OpenCL-on-SGX driver development... And in fact I'd advise against it.
SGX as a tiled architecture is very tuned to rendering by eliminating overdraw. It not the fastest GPU out there, but it does things "smart way" automatically eliminating unnecessary shader invocations.
You can't eliminate any shaders invocations when executing OpenCL code. Everything must be calculated according to algorithm, which is in stark contrast with rasterization where, let me repeat it again, shaders for invisible pixels are not executed.

...and let's not forget SGX has clock of only 110MHz (up to 440M op/s).

Better fit for any GPGPU would be NEON (4-way SIMD usually at 600MHz = 2400M op/s) or DSP (8-way VLIW at 430MHz = 3440M op/s).

This does not mean it can't be done - it only means that there are better ways to implement OpenCL than on SGX.

(all figures above are "best case" = take them with a grain of salt)

B)

 

[sindbad]

As far as I know, OpenCL is supposed to use DSPs and SSE/NEON instructions as well. There doesn't seem to be any open source implementation, though.

 

[klikklak]

Thanks for the replies, this clarified the issue for me. The reverse engineering I mentioned wasn't about opencl on SGX, but just something someone mentioned on a thread about free software status on the panda (all else free except the SGX driver).

Also, isn't Gallium3d the openCL implementation everyone's raving about? It's not there yet, but looks quite promising. I've only tried cuda and gpugrid, there aren't that many programs around for this type of stuff yet.

EDIT: wait, was maciek saying that omap has a dsp and neon as well? .. sweet.

 

[darkblu]

...and let's not forget SGX has clock of only 110MHz (up to 440M op/s).

Better fit for any GPGPU would be NEON (4-way SIMD usually at 600MHz = 2400M op/s) or DSP (8-way VLIW at 430MHz = 3440M op/s).

This does not mean it can't be done - it only means that there are better ways to implement OpenCL than on SGX.

(all figures above are "best case" = take them with a grain of salt)

let's not forget, though, that of all devices listed above, SGX is the one that has state-of-the-art latencies-handling mechanism (the built-in thread scheduler). in comparison, both neon and the dsp are dumb ALU pipelines. as a resuly, SGX will likely run most of the time close to its theoretical limits, whereas with the other two it will be very much up to the skills of the programmer.

edit: ok, i keep shunning that dsp fella in the pandora (sorry, my bad) but i just bothered to check on it and it does not seem to support floats at all. if so then no openCL on the dsp at all, no matter how fast it is (yes, single-precision floating point support is manadatory for openCL). so the only pandora-hosted deviced on the openCL table are SGX and neon. potentially the VFP.

 

[Zeno Arrow]

Also, isn't Gallium3d the openCL implementation everyone's raving about?

Gallium3D is for OpenGL not OpenCL. This is as much info as I could find about linking the two:
http://www.phoronix.com/scan.php?page=news...m&px=NjMyMg

 

[spinghed]

I think some people are getting confused between openCL openGL and mixing in a good dollop of openVG too...

Right now there is no support for openCL - it is a very new standard anyway. But if you are clever about "subbing out" your tasks to the other processing units, you can kind of get the performance advantages you'd get from using openCL and of course cycle down the core to reduce the battery draw.

Rick

 

[sindbad]

Also, isn't Gallium3d the openCL implementation everyone's raving about?
Gallium3D is for OpenGL not OpenCL. This is as much info as I could find about linking the two:
http://www.phoronix.com/scan.php?page=news...m&px=NjMyMgGallium3D can have any number of frontends made. Right now it has OpenGL and DirectX. It would be possible to write an OpenCL frontend for it.

 

[klikklak]

QUOTE
Gallium3D can have any number of frontends made. Right now it has OpenGL and DirectX. It would be possible to write an OpenCL frontend for it.


But it's been worked on, right? .. it IS a very new standard, but the talk on phoronix is about OpenCL as part of Gallium3D

 

[sindbad]

QUOTE
Gallium3D can have any number of frontends made. Right now it has OpenGL and DirectX. It would be possible to write an OpenCL frontend for it.
But it's been worked on, right? .. it IS a very new standard, but the talk on phoronix is about OpenCL as part of Gallium3D
Not that I know of.

 

[klikklak]

QUOTE
OpenCL support would not exist in the Xorg drivers, because it has nothing to do with display or windowing.

What it (very likely) will exist as in the open source world is a state engine atop Gallium3D. Gallium3d basically provides a bytecode compiler and interface (TGSI) which allows generic bytecode to be sent to the driver and compiled JIT for the GPU.

http://www.phoronix.com/forums/showthread....4683&page=3

This was on a thread on phoronix (apologies for cross site posting). But yeah, I was jumping the gun (both regarding OpenCL and the state of pandora).

 

[maciek_urbanski]

let's not forget, though, that of all devices listed above, SGX is the one that has state-of-the-art latencies-handling mechanism (the built-in thread scheduler).

in comparison, both neon and the dsp are dumb ALU pipelines. as a resuly, SGX will likely run most of the time close to its theoretical limits, whereas with the other two it will be very much up to the skills of the programmer.

That's a valid point.
For a positive note - NEON is very similar to Intel SSE extensions, and most latency hiding mechanisms described for SSE should apply to NEON. But yes - SGX does this for free (and has significantly greater register set too - another thing that helps hiding memory latencies).

edit: ok, i keep shunning that dsp fella in the pandora (sorry, my bad) but i just bothered to check on it and it does not seem to support floats at all. if so then no openCL on the dsp at all, no matter how fast it is (yes, single-precision floating point support is manadatory for openCL). so the only pandora-hosted deviced on the openCL table are SGX and neon. potentially the VFP.

You are right again.
I completely forgot about that.

For the interested: TMS320C64x/C64x+ DSP CPU and Instruction Set Reference Guide - no floats there.

 

[ldesnogu]

For a positive note - NEON is very similar to Intel SSE extensions, and most latency hiding mechanisms described for SSE should apply to NEON.

I don't know much about SSE, but isn't it using the same renaming strategy as the integer pipelines which helps hiding latency? NEON is strictly in order and blocks when there are hazards.