GPGPU on the R-PI.

[AlterA]

hey, I was wondering is there support for stuff like OpenCL or any other gpgpu language.
because the arm cpu core is supposed to be slow as **** can we use the gpu for nice little projects?

[RaTTuS]

YMMV

no openCl is not going to be supported but there are ways to get at the gpu for some use - no details yet

[_Big_Mac_]

Are there technical reasons for not supporting OpenCL on the GPU (and/or CPU) or just lack of manpower to do the implementation? Is the hardware capable of conforming to OpenCL embedded profile?

[jamesh]

_Big_Mac_ said:


Are there technical reasons for not supporting OpenCL on the GPU (and/or CPU) or just lack of manpower to do the implementation? Is the hardware capable of conforming to OpenCL embedded profile?


I don't believe there are any technical reasons. Just the man years of work required to do it, and that would need to be done by Broadcom  (very specialist knowledge of the GPU required), so is very unlikely since there is little chance of making the money spend back.

[tufty]

And to anticipate the next moan, that of "why would Broadcom not make their money back?"

The SoC being used in the Pi is aimed squarely at multimedia processing, particularly set top boxes and the like. Its use in the Pi as a general purpose processor is a definite bastardisation of what it was originally intended to do (and part of why the ARM part used is so far behind the curve). GPGPU in general, and OpenCL in particular, are of little to no use in the market Broadcom are aiming at - that"s why Broadcom have shedloads of codec support and no OpenCL implementation. Developing an OpenCL implementation for the GPU makes no commercial sense when the only use would be on a platform that sells small quantities and where the SoC is, AIUI, being provided with a very limited profit margin.

This might, of course, change if VC4 starts being integrated into more compute-oriented SoCs.

Just my (NS)HO, of course.

Oh, and no, Broadcom are not going to provide the information you need to develop your own.

Simon

[jamesh]

re: Money back. Tufty is on the money.

Let's say it costs $500k to implement OpenCL (probably an underestimation). Let's say that a VC4 equipped chip makes $10 profit per sale (this is an entirely made up figure, and probably completely wrong and much too high). You need to sell 50k chips to make back the money, and those need to be sold in an area that is using OpenCL.

Now 50k chips is a LOT to sell in to a GPU compute area, and that is just to break even, and doesn't include support cost and ongoing maintenance.

[_Big_Mac_]

So, how about doing GPGPU the old fashioned way, with hacky compute shaders? Is that a workable idea?

[jamesh]

Yes, its a complete implementation of OGL ES2.0, so does support shaders. What you do with them is up to you!

[tufty]

Perfectly viable.

[mole125]

Does it provide enough of an API to do GPU accelerated encoding/decoding of video using the generic portions of the chip (not the custom silicon) if so presumably it is then the people distributing that code who would have to worry about patant licensing not the foundation.

[lb]

OpenGL ES 2.0 is definitely NOT a viable option for GPGPU computing. Pretty much all of the features that make OpenGL 3.x+ capable of (somewhat) flexible and fast general-purpose computing are missing in OpenGL ES.

[lb]

mole125 said:


Does it provide enough of an API to do GPU accelerated encoding/decoding of video using the generic portions of the chip (not the custom silicon) if so presumably it is then the people distributing that code who would have to worry about patant licensing not the foundation.


No. This is a silly idea to start with; it is inefficient and not all stages of the decoding pipeline can be parallelized on a GPU shader processor. However, GLSL ES does not support integer operations, which makes it completely unsuitable for this task.

[mole125]

lb said:


mole125 said:


Does it provide enough of an API to do GPU accelerated encoding/decoding of video using the generic portions of the chip (not the custom silicon) if so presumably it is then the people distributing that code who would have to worry about patant licensing not the foundation.


No. This is a silly idea to start with; it is inefficient and not all stages of the decoding pipeline can be parallelized on a GPU shader processor. However, GLSL ES does not support integer operations, which makes it completely unsuitable for this task.


I'm intrigued by your definition of inefficient here? Even if it ended up being a mainly linear process on the GPU shader perhaps with some parts still being done on the main CPU that is still 2 parallel threads of execution as opposed to everything being done on a single core CPU.  Even if the entire chain can't do it presumably some parts of it could be done (even if it is just colour space conversion or resampling?).

[tufty]

lb said:


OpenGL ES 2.0 is definitely NOT a viable option for GPGPU computing. Pretty much all of the features that make OpenGL 3.x+ capable of (somewhat) flexible and fast general-purpose computing are missing in OpenGL ES.


I'd be interested in hearing what you think is missing from OpenGL ES 2 that would stop it being useful for GPGPU work.  It's been a while since I've done any myself, and I've not tried porting any of my code over to ES, but I can't see anything that's fundamentally lacking.

Simon

[lb]

tufty said:


I'd be interested in hearing what you think is missing from OpenGL ES 2 that would stop it being useful for GPGPU work.  It's been a while since I've done any myself, and I've not tried porting any of my code over to ES, but I can't see anything that's fundamentally lacking.


Well, from the top of my head:

No PBO or buffer mapping support: say goodbye to fast, asynchronous DMA transfers between GPU and CPU.
No native integer support in GLSL ES: you're basically screwed if your calculations require integers (for bitwise operations and/or accuracy).
No floating point texture support: if you want to work with floats all the way, you're screwed, too.
No 3D textures: very useful for fast lookup tables.
No multiple render targets.
Various missing functionality in GLSL ES (it's a stripped-down GLSL 1.20).

You definitely can use OpenGL ES to do arbitrary calculations, but the various restrictions do not make it easy nor perform well. OpenGL already has limited usefulness for GPGPU applications, but OpenGL ES is much more restricted, harder to develop GPGPU code for, and less likely to offer usable performance.

[teh_orph]

Can we not have manuals, so that we can do it all ourselves?
I'm not adverse to writing code the long way...

This would be much cheaper (for Broadcom) than writing a run-time for a small amount of users.

[oninoshiko]

teh_orph said:


Can we not have manuals, so that we can do it all ourselves?
I'm not adverse to writing code the long way...

This would be much cheaper (for Broadcom) than writing a run-time for a small amount of users.



The GPU is considered a closely guarded secret. They will not give us anything more then the binary blob which the open-source code interfaces with.

My understanding is that manuals would require NDAs.

[jamesh]

teh_orph said:


Can we not have manuals, so that we can do it all ourselves?
I'm not adverse to writing code the long way...

This would be much cheaper (for Broadcom) than writing a run-time for a small amount of users.


It was also be fantastically difficult to do, involving learning a custom vector instruction set, plus learning how to use some of the other cores on the Videocore. There are only a few Brcm employees even, who know how to do that stuff.

If it was easy, Broadcom would probably have done it, but I reckon there is probably 5 or more man years of work involved, and you need very experienced people to do it.

[teh_orph]

Oh I don't doubt it would be difficult, but people will try nonetheless! Doing something with proper docs is always better than reverse engineering something

Since those (cut-down) data sheets for the rest of the SoC were made available for us, sans NDA, is there any scope to do something similar for the GPU? Sure their technology may be a guarded secret but there's rarely anything worth protecting in an instruction set encoding...

[cpslashm]

Never mind performance. If we cannot use the GPU at all, we'll have to build an OpenCL which uses a simulated GPU. The important thing is to be able to learn to do heterogenous parallel programming.

[andrewbrowning]

You can use OpenGL 2.0 ES just like you would have done in the old days before GPGPU was an industry.  You'll have to characterize and understand your data conversions carefully and empirically assess your error, but for lots of things, including most 8-bit computer vision type problems you should be fine.

Check out the GPU Gems series of books (some are available free online), and look here for what someone did with it on the iPhone 3 - 60fps computer vision algorithms  http://www.sunsetlakesoftware......ac-and-ios.

[willanth]

So for the sake of a poor electronics engineer.. My understanding of the above is that we have no access to the GPU for calculations, only to "do video".  So if we want to make pretty pictures or process video (saw a mention of offloading X onto the GPU which will be nice of course) it'll be fine but if we want to actually experiment with this system and squeeze some performance out of it we're in for a nightmare.

Now I personally can't wait to get my hands on several of these things, and I really applaud the designers.  It's a brilliant idea.  But I admit I am a bit nonplussed that there would be something as obvious as access to the GPU that is a stumbling block in development.  May have been a case of "best of a tough situation", I don't know, but it's very unfortunate.

My request to the community (and the developers) would be to find a way to open some aspects of the GPU up.  After all, I don't think that sales of these things are going to be a problem!

Cheers,

Will

[finnw]

I see that OpenCL/CUDA are probably never going to be implemented.

But is there any chance of an implementation of GL_OES_texture_float in the future, or of increasing GL_MAX_DRAW_BUFFERS? Even increasing this to 2 would greatly increase the range of tasks that could be performed on the GPU using GLSL hacks.

[jdobmeier]

I'm pretty sure that the GPU is softfloat only but there are different/better ways to do the conversions (e.g. http://flip.gforge.inria.fr/). I would be happy with tutorials 0-3 from here: http://gpgpu.org/developer/legacy-gpgpu-graphics-apis, though if there is a software way to do 4 that would be good, though I'm guessing the restriction is hardware based.

[shirro]

I'm pretty sure that the GPU is softfloat only

Although I know nothing about the internals of the GPU I would be shocked if it didn't have lots of floating point hardware considering what it does and how fast it does it.

The opengl, egl, openvg, openmax libraries all use vfp for floating point and are available in both softfloat and hardfloat abi versions.

Also as far as the ARMv6 is concerned the floating point appears to perform better than the vfp-lite in a Cortex A8 as used in several more expensive machines. Though if you are stuck doing stuff on the ARM side you really want a dual core A9 at least.