hehe2
Posts: 4
Joined: Thu Jun 21, 2012 12:32 pm
Location: Paris, FRANCE
Contact: ICQ

Re: GPU Processing API

Sat May 25, 2013 9:10 pm

How comes there is still no open source driver to do GPU computing?

Broadcom just fears what ? There are no leaders at all in any of their domain of activity (look at intel / samsung / amd) so better take advantage of the open source community that being pissing them of imho...

Next "Raspberry Pi" like project (in like two or three years may be) will have a MASSIVE users base who will be willing EVERYTHING to be open BY DESIGN and there must be some business to be made by providing sources and selling hardware/service at the same time.

I bet that won't be broadcom...

I can still dream of some "Anonymous" or some "Julian Assange" fan people that would steal those piece of information and make the RPi community finally able to use all of the power the device has to deliver...

I bet that wouldn't hurt broadcom financial results at all...

Imagine all the noise that would be if one can do some GPU computing using like 3 watts of power ?


Anyway... this world is far from being perfect... but people can still change it together !

hermanhermitage
Posts: 65
Joined: Sat Jul 07, 2012 11:21 pm
Location: Zero Page

Re: GPU Processing API

Sun May 26, 2013 12:13 am

hehe2 wrote:How comes there is still no open source driver to do GPU computing?
Probably business reasons, and BRCM not having their own suitable implementation.

We the community can produce such a driver if everyone steps up and contributes. So roll up those sleeves and please throw us some of your time.
Right now there are multiple compilers targeting the Videocore Integer SIMD units in development, and there is a method for calling the code from the ARM side.

For exposure of the QPUs, its a matter of when not if. It just requires hands on deck.

hehe2
Posts: 4
Joined: Thu Jun 21, 2012 12:32 pm
Location: Paris, FRANCE
Contact: ICQ

Re: GPU Processing API

Sun May 26, 2013 1:09 am

hermanhermitage wrote:
hehe2 wrote:How comes there is still no open source driver to do GPU computing?
Probably business reasons, and BRCM not having their own suitable implementation.

We the community can produce such a driver if everyone steps up and contributes. So roll up those sleeves and please throw us some of your time.
Right now there are multiple compilers targeting the Videocore Integer SIMD units in development, and there is a method for calling the code from the ARM side.

For exposure of the QPUs, its a matter of when not if. It just requires hands on deck.
Well, I'm glad to hear that but... what skills are required to provide some of the needed help ? Must one be top notch asm programmer/coder to be able to join the working force ?

Is there some dedicated place about this topic endeavors ?

I still think that would be easier for everyone with some release of information from broadcom...

hermanhermitage
Posts: 65
Joined: Sat Jul 07, 2012 11:21 pm
Location: Zero Page

Re: GPU Processing API

Tue May 28, 2013 11:58 pm

hehe2 wrote:
hermanhermitage wrote:
hehe2 wrote:How comes there is still no open source driver to do GPU computing?
... It just requires hands on deck.
Well, I'm glad to hear that but... what skills are required to provide some of the needed help ? Must one be top notch asm programmer/coder to be able to join the working force ?

Is there some dedicated place about this topic endeavors ?

I still think that would be easier for everyone with some release of information from broadcom...
Some contact points listed here: https://github.com/hermanhermitage/videocoreiv
"Active discussions take place on IRC (freenode) on #raspberrypi-internals, #raspberrypi-osdev, #raspberrypi-dev, and #raspberrypi.
There is a raspberrypi-internals mailing list, you can subscribe at mailing list page at freelists.org."

No need for top notch asm/coding, its just a bunch of typical folks. As much as anything we need to engage a community of users / people with problems that need solving. That way we could roll some tools / APIs that are useful.

hermanhermitage
Posts: 65
Joined: Sat Jul 07, 2012 11:21 pm
Location: Zero Page

Re: GPU Processing API

Wed Jul 24, 2013 5:18 am

For anyone interested, I've begun documenting the Shader Processor portion of the RaspberryPi at https://github.com/hermanhermitage/videocoreiv-qpu. I've sat on this for a while, but it feels like the time is right now.
Basically the shader processor (QPU) is the floating point monster inside the RaspberryPi. Approx 24 GFLOPS of peak single precision floating point seems to be available.
Still along way from being able to utilize this, but we can capture and inspect live shader fragments.

I'm very interested to hear from anyone who wants to poke around and learn more about this amazing bit of silicon.

On another note the documentation on the main videocore processor is closer to final now, and there are two (alpha/beta) compilers targeting it, with some work being done on LLVM as well.

At the end of the day its all about making the most of the RaspberryPi...

hermanhermitage
Posts: 65
Joined: Sat Jul 07, 2012 11:21 pm
Location: Zero Page

Re: GPU Processing API

Mon Feb 10, 2014 12:26 am

I've started putting some QPU samples at https://github.com/hermanhermitage/vide ... u-tutorial
There's enough there to get results back out of the QPUs.

I really need to add a VPM read example, and a working assembler (or something like Dynasm) for this to be useful to most people.

The long term plan is to put a set of useful QPU (SIMD floating point / stream processing) routines at https://github.com/hermanhermitage/libqpu, and VPU (SIMD integer / general processing) routines at https://github.com/hermanhermitage/libvpu.

The QPU is best suited to heavy floating point crunching, and the VPU to fixed point / integer or image/graphics/audio processing (eg blitting, emulation screen format conversion, etc).

Any ideas on the sort of applications they would like to see accelerated?

marked
Posts: 218
Joined: Fri Jul 29, 2011 4:25 pm

Re: GPU Processing API

Mon Feb 10, 2014 12:48 pm

hermanhermitage wrote:Any ideas on the sort of applications they would like to see accelerated?
openssl
streaming crypto (aes; sha256/512; rc4/5)
streaming compression/raid/checksumming (e.g. disk routines. lzo kernel modules, btrfs/zfs checksum/ crypto support) - does LVM (logical volume manager benefit?)

there has been some work on accelerating crypto using opencl on pc cards at https://groups.google.com/forum/#!forum/engine-cudamrg, so maybe something similar, or at least as a jumpoff point.

There has also been some work done with accelerating a beaglebone black by using the h/w crypto for use with tor. This, I think uses a plugin to cryptodev, which openssl then utilises. Tor then just has a config change to use h/w acceleration.

mark

Jeti
Posts: 1
Joined: Sat Feb 15, 2014 10:27 pm

Re: GPU Processing API

Sat Feb 15, 2014 10:34 pm

Hi there,

i would really like to use the gpu for aes encryption, mostly with cryptsetup.
Actually i found this thread while researching on that.

Some (even) easier examples on how to use the gpu instructions for other purposes would be great, but i might be able to figure it out from what is already in your github when my university stuff is finally done for this semester ... ;)

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 12124
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: GPU Processing API

Sat Feb 15, 2014 10:51 pm

hehe2 wrote:How comes there is still no open source driver to do GPU computing?
because having one is simply wishful thinking

User avatar
duberry
Posts: 379
Joined: Mon Jan 28, 2013 10:44 pm
Location: standing on a planet that's evolving. And revolving at nine hundred miles an hour

Re: GPU Processing API

Sun Feb 16, 2014 9:39 am

mahjongg wrote:
hehe2 wrote:How comes there is still no open source driver to do GPU computing?
because having one is simply wishful thinking
perhaps that or this CBA because CBA.


[1] urbandictionary.com/#Can't be arsed
[2] wikipedia.org#Cost-benefit_analysis

..
lend me your arms, fast as thunderbolts, for a pillow on my journey.
If the environment was a bank, would it be too big to fail
so long; and thanks for all the pi

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 12124
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: GPU Processing API

Sun Feb 16, 2014 10:36 am

or simply because its much harder to do than anyone assumes, or is willing to admit.... :mrgreen:

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

Re: GPU Processing API

Sun Feb 16, 2014 3:43 pm

mahjongg wrote:or simply because its much harder to do than anyone assumes, or is willing to admit.... :mrgreen:
This. It is a hell of a lot of very very difficult work.

There, I admitted it.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

hermanhermitage
Posts: 65
Joined: Sat Jul 07, 2012 11:21 pm
Location: Zero Page

Re: GPU Processing API

Sat Feb 22, 2014 1:35 am

jamesh wrote:
mahjongg wrote:or simply because its much harder to do than anyone assumes, or is willing to admit.... :mrgreen:
This. It is a hell of a lot of very very difficult work.

There, I admitted it.
Not necessarily meeting the open source criteria, but if the OpenGL ES driver was extended to include glTransformFeedbackVaryings() from OpenGL ES3, then folks could use vertex shaders for stream processing. Theoretically its possible to patch the current blob, but its more feasible with access to source...

Otherwise on the open source side, https://github.com/hermanhermitage/vide ... /qpuasm.md now has a working QPU assembler thanks to a group of folks on the internals mailing list. Still a long way from a accessible GPU processing API, but its a start. If I disassemble all the QPU fragments in the blob (or capture QPU fragments from shaders) and reassemble them - it produces the same binaries - with the exception of a few cases where there are mutliple ways of assembling the same mnemonics. It also successfully assembles a disassembly of the QPU-FFT routine from Andrew - producing an identical binary. So at least we aren't losing information (even if our understanding may be utterly wrong). The biggest gap right now is getting a complete handle on the VPM transfers and ldi/movi.never instructions that the QPU-FFT routine uses but we haven't traced.

To those suggesting crypto in this thread, what are your use cases? Isnt the IO (sdcard & 100Mbps) ethernet so constrained that you can do RC4, SHA and to a lesser extent AES at line speed using optimized ARM code?

Heater
Posts: 13111
Joined: Tue Jul 17, 2012 3:02 pm

Re: GPU Processing API

Sat Feb 22, 2014 10:36 am

jamesh,
This. It is a hell of a lot of very very difficult work.
Not "This" at all. I have no doubt that is is a lot of difficult work.

However that is not actually a reason for not open sourcing the entire thing.

If "lot of very very difficult work" were a show stopper we would not have Linux or the rest of the worlds open source software.

Broadcom and other suppliers of closed source binaries may have good reason to keep them closed but "this" is not one of them.

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

Re: GPU Processing API

Sat Feb 22, 2014 1:48 pm

Heater wrote:jamesh,
This. It is a hell of a lot of very very difficult work.
Not "This" at all. I have no doubt that is is a lot of difficult work.

However that is not actually a reason for not open sourcing the entire thing.

If "lot of very very difficult work" were a show stopper we would not have Linux or the rest of the worlds open source software.

Broadcom and other suppliers of closed source binaries may have good reason to keep them closed but "this" is not one of them.
What are you talking about? Have you just completely changed the subject or have I completely misunderstood? The reason Brcm have not done it is because it a lot of time consuming difficult work. With no actual benefit to their bottom line. Nothing to do with open source, and has no influence on open source. This part of the discussion was not about open sourcing the code (Which isn't going to happen, so no need to keep asking), but about the complexity of writing an OpenCL compiler for the GPU or similar. That complexity is why its not been done, that's on little benefit to the majority of their users.

Which sort of segues in to another point - if the people who designed the GPU and its processors think it s big big job, and very difficult, that means it will be mind bendingly difficult for those without any experience in the area. Which is why I am somewhat in awe of the achievements of Herman Hermitage, but he seems to be the only person outside Broadcom who has a grasp on the GPU. I'm surprised we haven't offered him a job.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1425
Joined: Sat Sep 10, 2011 11:43 am

Re: GPU Processing API

Sat Feb 22, 2014 2:59 pm

Unfortunately Herman isn't in the UK otherwise I would have!

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

Heater
Posts: 13111
Joined: Tue Jul 17, 2012 3:02 pm

Re: GPU Processing API

Sat Feb 22, 2014 3:31 pm

Jamesh.
What are you talking about? Have you just completely changed the subject or have I completely misunderstood?
Taking those questions in turn: I'm replying to the question of open source drivers to do GPU computing. No, I have not changed the subject I commented on your comment on the very same subject and yes you have.

Let me recap the last few posts:

hehe2: "How comes there is still no open source driver to do GPU computing?"

mahjongg: "because having one is simply wishful thinking"

duberry: "perhaps that or this CBA because CBA." (Whatever that means)

mahjongg: "or simply because its much harder to do than anyone assumes, or is willing to admit..."

jamesh: "This. It is a hell of a lot of very very difficult work."

Heater: Whatever I said above...


To continue:

Yes writing such drivers is not a simple affair.Yes, such a project might not have a financial benefit to Broadcom. And yes it may have no benefit to the majority of their users.

However that difficulty is no reason not to have opensource drivers. There are plenty of smart enthusiastic guys out side of Broadcom who might love to have a go at it. If the GPU were documented and the current firmware open sourced then there would be more chance for people to try.

Herman is an an example by the sounds of it.

Now, I'm not particularly asking for opensource firmware. As far as I'm concerned its as much part of the chip as if it were blown into ROM or implemented in a sea of gates. Just making an observation.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1425
Joined: Sat Sep 10, 2011 11:43 am

Re: GPU Processing API

Sat Feb 22, 2014 3:42 pm

Heater wrote: Now, I'm not particularly asking for opensource firmware. As far as I'm concerned its as much part of the chip as if it were blown into ROM or implemented in a sea of gates. Just making an observation.

As you can see from Herman's work he's pretty much there, if you've got an itch to start working on it then go ahead, I'd start on the VPU since he's got far more information than the QPU but he'll get there. Just go write yourself some code...

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

Heater
Posts: 13111
Joined: Tue Jul 17, 2012 3:02 pm

Re: GPU Processing API

Sat Feb 22, 2014 5:07 pm

gsh,
Just go write yourself some code...
Love to. That is impressive work Herman has put up on hes github page.

Of course progress would be a bit quicker if his pleas for help were headed. I quote:
The hope is that Broadcom will be flattered by the interest in the device and understand the benefits of opening up understanding to a larger audience of potential customers and developers.

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

Re: GPU Processing API

Sat Feb 22, 2014 6:25 pm

Heater wrote:gsh,
Just go write yourself some code...
Love to. That is impressive work Herman has put up on hes github page.

Of course progress would be a bit quicker if his pleas for help were headed. I quote:
The hope is that Broadcom will be flattered by the interest in the device and understand the benefits of opening up understanding to a larger audience of potential customers and developers.
You need to approach Broadcom, not whinge about it here as that has no effect whatsoever. The Foundation is contractually unable to help, I am contractually (under threat of dismissal) unable to help as is any Broadcom employee below director level (and even then that might not be possible due to legal repercussions). So, you need to talk to Broadcom.

I would expect them to completely ignore you as this brings them no benefits whatsoever (what larger audience? Evidence? SO far Herman seems to be the only interested developer), in fact it would cost them millions of $, but it might be worth a go.

Better approach, help Herman out. He's pretty much done all this stuff single handedly, which is am impressive effort. There are already some basic functions to allocate memory and execute remote GPU code - Herman has examples, and I use something similar in the HW cursor code to allocate bitmap memory and communicate with the GPU. So the building blocks are there - it just needs people to put in a bit of effort.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

cellux
Posts: 6
Joined: Tue Jan 08, 2013 8:36 am

Re: GPU Processing API

Tue May 13, 2014 3:42 pm

Re: why anybody would need a completely open Pi

I grew up on a Commodore 64. This machine had a fixed architecture: if I wrote some code and brought it over to my neighbour, I could be sure that on his computer the program would do the same thing and produce the same output. Because of the homogeneity of hardware, portability concerns did not arise and bare metal programming was a natural thing to do.

With the C64, we had a chance to understand the entire system, to the point of ultimate mastery. In 1985, some guys found out how to trick the VIC-II graphics chip into "forgetting" that it shall draw the horizontal borders on the left and right side of the screen, and sprites - which till then were constrained to move between the borders - suddenly escaped their "prison", showed up on the side border, apparently defying the laws of the known universe.

Some other guy discovered that you can upload snippets of code to the floppy disk drive's memory through the cable which connected it to the C64. They used this trick to upload the server part of a new transmission protocol (fast loader) which - through clever synchronization and utilizing two wires of the cable instead of one - increased load speed by a factor of five.

For me, developments like these had far-reaching philosophical implications. I began to see these machines - the C64, the ZX Spectrum and the Amiga - as worlds of potentiality, each with its own laws, waiting to be discovered, inhabited and eventually developed into works of perfection. The company-provided ROMs were only the beginning, providing examples of what could be done. But we were not constrained by what was given. Having sufficient understanding of the machine, we could leave the safety net and begin to mold the universe to our own liking, into our own shape and form - sometimes discovering things which even the original creators were not aware of.

For these reasons, I got very excited when I first heard about the Raspberry Pi. To me, the Pi could easily be the fixed platform of the XXI. century. It has enough juice that almost anything worth doing can be implemented on it and it runs Linux, the richest, most permissive safety net I can imagine. I am thrilled by the idea that one day I might be able to download countless SD card images from the internet, each of them storing a little world, a piece of art realized by someone who wanted to express themselves and used the Pi as a widely shared medium. But for that to happen, users should be able to take complete control of their machines.

I'd like to see people implementing their own Forth and LISP systems, building special purpose OSes, taking ideas from each other's implementations. I'd like to see graphics effects which are only possible by directly fiddling with the GPU's registers because the OpenGL route would be too slow. I'd like to see single-purpose apps which sidestep every API and get as close to the metal as possible, simplifying their code to the bare minimum, in the pursuit of perfection. I'd like to see innovative user interfaces which are hand-tailored to the application's needs, while getting away from the tiring "desktop metaphor". I'd like to see librarians who collect all knowledge about the Pi and organize it into the "Book of the Pi", an interactive encyclopedia which can be edited by its users (just like Wikipedia). All of this in the form of downloadable SD card images.

One could argue that this is already happening: projects like RaspBMC or Volumio could be seen as implementations of this "world on an SD card" concept. But I think they are not the same. Those projects are like Raspberry Pi versions of something which could be equally done on any other hardware. What I'm talking about is an intimate relationship with the hardware, a form of man-machine symbiosis, which leads to the mutual development of both. When the soul of man can flawlessly express itself through the machine, it's a sort of enlightenment.

I hope someone will dig it.

Ravenous
Posts: 1956
Joined: Fri Feb 24, 2012 1:01 pm
Location: UK

Re: GPU Processing API

Tue May 13, 2014 3:52 pm

cellux wrote:To me, the Pi could easily be the fixed platform of the XXI. century. It has enough juice that almost anything worth doing can be implemented on it...
and then...
cellux wrote:I'd like to see graphics effects which are only possible by directly fiddling with the GPU's registers because the OpenGL route would be too slow.
Does anyone see a problem with these arguments?

ghans
Posts: 7871
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany

Re: GPU Processing API

Tue May 13, 2014 3:52 pm

Check
http://www.raspberrypi.org/forums/viewt ... 66#p522307

and the other posts following that one.

ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org

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

Re: GPU Processing API

Tue May 13, 2014 4:08 pm

cellux wrote:I'd like to see graphics effects which are only possible by directly fiddling with the GPU's registers because the OpenGL route would be too slow. I'd like to see single-purpose apps which sidestep every API and get as close to the metal as possible, simplifying their code to the bare minimum, in the pursuit of perfection.
Actually, the 3D side is already released, but to be honest, the 3D HW is designed around OpenGLES as a first class interface, so there are not really any 'tricks' you can do by poking bits here and there - it already runs as fast as possible (YMMV). Given the register set for the VC4 is IIRC over 100k in size (that's 100k different registers..), this is a somewhat more complex system than that of the early Micros (I was a BBC Micro person..), so the sort of tweaks you envisage are not really valid. A lot of time and money was spent on making the 3D engine as quick as possible already - mobile device customers are pretty picky...

There are things you can play with - dispmanx for example can do some compositing stuff that is currently underused IMO (XBMC uses it I believe to get its higher performance), but that is available to play with via a first class API. You really don't want to play at the bit level on devices this complicated! I've been doing that today on some lens driver code for a camera. It sucks.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

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

Re: GPU Processing API

Wed May 14, 2014 11:04 pm

That's good work - I have forwarded it to someone who mentioned this sort of thing to me the other day...
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Return to “C/C++”