AlterA
Posts: 1
Joined: Fri Feb 24, 2012 5:29 am

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 5:38 am

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?

User avatar
RaTTuS
Posts: 10504
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
Contact: Twitter YouTube

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 8:14 am

YMMV

no openCl is not going to be supported but there are ways to get at the gpu for some use - no details yet
How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe

_Big_Mac_
Posts: 2
Joined: Fri Feb 24, 2012 10:08 am

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 10:15 am

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24168
Joined: Sat Jul 30, 2011 7:41 pm

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 10:41 am

_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.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 11:09 am

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24168
Joined: Sat Jul 30, 2011 7:41 pm

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 11:37 am

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.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

_Big_Mac_
Posts: 2
Joined: Fri Feb 24, 2012 10:08 am

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 1:16 pm

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

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24168
Joined: Sat Jul 30, 2011 7:41 pm

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 1:26 pm

Yes, its a complete implementation of OGL ES2.0, so does support shaders. What you do with them is up to you!
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 1:27 pm

Perfectly viable.

mole125
Posts: 228
Joined: Tue Jan 10, 2012 2:01 pm

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 2:19 pm

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
Posts: 263
Joined: Sat Jan 28, 2012 8:07 pm

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 2:37 pm

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
Posts: 263
Joined: Sat Jan 28, 2012 8:07 pm

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 2:42 pm

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
Posts: 228
Joined: Tue Jan 10, 2012 2:01 pm

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 3:03 pm

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
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 3:20 pm

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
Posts: 263
Joined: Sat Jan 28, 2012 8:07 pm

Re: GPGPU on the R-PI.

Fri Feb 24, 2012 11:41 pm

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.

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: GPGPU on the R-PI.

Sat Feb 25, 2012 12:21 am

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
Posts: 76
Joined: Sun Jan 29, 2012 9:16 pm

Re: GPGPU on the R-PI.

Sat Feb 25, 2012 12:47 am

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24168
Joined: Sat Jul 30, 2011 7:41 pm

Re: GPGPU on the R-PI.

Sat Feb 25, 2012 9:32 am

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.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: GPGPU on the R-PI.

Sat Feb 25, 2012 4:19 pm

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
Posts: 10
Joined: Tue Dec 27, 2011 5:28 pm

Re: GPGPU on the R-PI.

Sun Mar 11, 2012 10:34 pm

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
Posts: 1
Joined: Sat Apr 14, 2012 4:56 pm

Re: GPGPU on the R-PI.

Sat Apr 14, 2012 6:02 pm

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
Posts: 4
Joined: Thu Apr 19, 2012 2:47 am

Re: GPGPU on the R-PI.

Tue Apr 24, 2012 10:31 am

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
Posts: 24
Joined: Wed May 16, 2012 7:05 pm

Re: GPGPU on the R-PI.

Thu May 24, 2012 2:52 am

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
Posts: 19
Joined: Sat Dec 10, 2011 4:49 pm

Re: GPGPU on the R-PI.

Thu May 24, 2012 4:04 am

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
Posts: 248
Joined: Tue Jan 24, 2012 4:54 am

Re: GPGPU on the R-PI.

Thu May 24, 2012 4:21 am

jdobmeier wrote: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.

Return to “General discussion”