One of the thorns in the side of the Raspberry Pi crowd has been the closed source GPU. Today that all changes. [Eben Upton] reports that Broadcom is opening the source to the VideoCore® IV 3D graphics subsystem. In Broadcom’s own words:
The VideoCore driver stack, which includes a complete standards-compliant compiler for the OpenGL® ES Shading Language, is provided under a 3-clause BSD license; the source release is accompanied by complete register-level documentation for the graphics engine
Full documentation is available on Broadcom’s support site. To celebrate this, The Raspberry Pi Foundation is offering $10,000 to the first person to run Quake III at a playable frame rate on Raspberry Pi with open source drivers. The competition is worldwide. Full rules available here.
This release doesn’t cover everything, as there are still parts of the Pi’s BCM2835 which are hiding behind the blob files. However, it is a very big step for open source. Congrats to the Raspberry Pi Team, and good luck to all the entrants.
Wow. I never thought this would happen! Very cool, I wonder what the extent of what can be done with it is?
Broadcomm is probably not getting a lot of new customers for this SOC but the Pi has become a money pump for them. Might as well go for the open source now and see what people can do with it. I wonder if OpenCL is a possibility?
Good news that isn’t a half truth this time.. shame the SoC on the Pi is now so long in the tooth.
Bad news is that I don’t think they’ve released the toolchain required to actually build this code, so until someone develops a compatible assembler and C compiler for VideoCore IV it’ll be of limited use. Also, they don’t appear to have released any architecture documentation on the VPU, which is the custom-designed processor core within the VideoCore IV that most of the released code runs on. (The released documentation is for the QPU and graphics rendering hardware and only mentions the VPU in passing.) Basically, we’ve got a bunch of code for a processor that we don’t even know the instruction set of except through reverse-engineering, let alone have a working compiler or assember for.
At a guess, the part that’s going to be most useful in the short term is the QPU documentation (roughly the equivalent of shaders on a desktop GPU), which will probably help with running QPU-accelerated compute code through the existing binary driver blob. In the long term someone will probably manage to write a compiler and make use of this code; there’s already been a fair amount of reverse engineering work on VideoCore IV.
Ah, Eben’s commented elsewhere and corrected me on this. Apparently the code originally ran on the VPU (and appears to roughly correspond to the binary blob that runs on the VPU on the Pi), but it’s been ported to the ARM core on the BCM21553 since that SoC doesn’t actually have a VPU. There’s just a huge amount of dead VPU-specific code that’s still referenced. (Still not sure exactly how this fits with the Pi, where currently the VPU blob has control of the GPU and is required to boot everything. I guess the promised barebones replacement for the VPU code will help.)
The RasPi foundation must be doing pretty well if they’re handing out $10K bounties.
That’s how the electronics economics function. You charge a bit over the production cost but in the meantime the part prices go down, yield improves by new processes, you are able to negotiate better deals because of established reputation and provider competition.
I would guess the PIs should have come down in price at least 15-20% or at least upgrade them constantly, but it’s fine if they put the extra money into useful projects. At least it is greener ( no moral obsolition) and moves the community forward instead of going the megapixel path.
wow never in 1 million years thought they would open source it. talk about a fantastic opportunity for the open source community.
Can somebody explain how big of a deal opening a blob like this is? What’s at stake for Broadcomm? I mean my RPi functions quite well with the blob… not that I think it’s a bad idea, I just want to understand exactly how much I should be celebrating.
Accelerated graphics drivers for Linux are now a possibility – which means the heavy lifting will be done by the vid core rather than the CPU, as is the case now. Also there is now scope to get web based video playing within linux at a reasonable frame rate. Oh, and games just became a lot more interesting on the Pi…
Anyone will be able to write / tweak new or custom graphics drivers, which should bring up some interesting results. Perhaps even the ability to harness the GPU for other tasks (number crunching, distributed projects, Bit-Coin mining, etc).
In other words, it will make the pi faster and more useable in general.
no no and nooo
“Accelerated graphics drivers for Linux” is something pee shipped with, I dont really know what you mean by “web based video playing within linux”, but openmax also works on pee just fine now. So do games.
also lol for bitcoin mining
The only thing this enables is an OPEN source driver, it _might_ be better than the closed sourced one, and it _might_ enable new uses, but not the ones you listed (as they are possible right now)
People just see the popular OSes, there are other OSes out there more than Windows and Linux and opening the documentation for a graphics core etc enables also them to make use of the hardware rather then just sitting with some vesa mode .. wake up and smell the coffee, alternative OSes have been around since the dawn of time but propertiery driver blobs has hindered many to shine with more recent hardware =)
Except that, when running the Pi as a desktop computer, the user is limited to unaccelerated X. Now, an accelerated X driver will be a real possibility, making the Pi more useful in that scenario. It also, as others have mentioned, will possibly allow using the GPU for more than just graphics.
(BTW, I’m not sure why you’re saying “pee” unless you’re trying to be cute or trying to troll for angry retorts.)
Perhaps because this is how you pronounce ᴨ in Greek?
rasz_pl – I sense by your comment that you neither like / use or possibly own a Raspberry Pi board. Or “pee” board in your case…
Oh, and as for the “lol for bitcoin mining”, I think you will find a SNES being used for bitcoin mining, right here on Hackaday. Not very practical either, so then “Why?” – for the LOLs of course. Doesn’t have to be practical to make it fun to do.
Anyway, I think I’ve done enough “feeding the troll” here for now. Back to the topic at hand.
Updates, improvements, new stuff.
Example, I have a PC with an Radeon 9600SE. Which still has issues with the open-source driver (3D graphics random hang). I know the binary blob drivers from ATI (now AMD) did not has this problem, however, they do not support any recent kernel version.
Your Radeon is one of hundreds of video card chipsets for general purpose computers, and is over 10 years old at that; at this point it’s mostly an abandoned project. The Raspberry Pi has a very dedicated following, and has only been out for a couple of years, with freshly open-sourced video drivers. The community will be all over this, and will likely find tons of innovative uses for the newly released info. At the very least, we’ll probably see accelerated X, as well as custom, task-specific drivers. I bet we’ll even see vastly improved performance in projects like Raspbmc and game emulators.
Forgot to mention, I do feel your pain regarding the old Radeon card. I’ve got a 9600 Pro in a retro gaming rig; no more Windows driver updates means broken games remain broken. No more GNU/Linux driver updates means it doesn’t run well on that platform either. But I use it specifically for a few old Windows games anyway, so I’m fine with that.
Accelerated X? Does anyone even need that? Everything of note that actually uses X is handing pre-rendered pixmaps to the server… Yeah, sure, if you care about Xeyes being a tad faster, then you may wish for X acceleration…
If you’ve ever used a Linux desktop interface on a standard PC with accelerated drivers, then used Lxde on the Raspberry Pi with the current unaccelerated framebuffer, you’d notice a huge difference. Dragging windows, redraw, everything is slow to the point of being a pain to use. Even the aforementioned 10 year old video cards can do better.
OpenCV running on a raspberryPi
Already possible – search around on HaD and Google, some kind French chap did it for us and I made a quadcopter camera stabilistion system primarily using OpenCV.
Will we be able to mine Dogecoin on it?
This is the important question
GPU calculation is not worth the time and money.
Would this make it possible to create an open-source bootloader for the Pi that could bring up the ARM core without the help of any proprietary blobs?
Short answer maybe, really answer no.
http://www.raspberrypi.org/archives/6299#comment-493990
Could this mean hardware accelerated android on the PI?
According to Liz from the R-Pi foundation, yes.
check our razdroid. Warg has been working on gralloc for a year or so now, I bet this will really kickstart the project.
It means you can now bit-bang a 0.5Hz square wave TWO pins at the same time and the black and white terminal will still be responsive.
HA! got me thinking though… does this mean anything interesting for the composite output? It’s just a DAC good for a few MHz, right? Could make for a pretty capable function / arbitrary waveform generator.
Console emulation is going to get much better too.
Awesome! :)
will this improve support for more lcd displays?
THIS is a (first) good question under this news :)
This could potentially enable access to MIPI DSI port. There are SHITTONS of cheap/big/with good resolution mipi screens on fleabay (for cellphones) that are just waiting for a platform that can draw on them. So far the only project that can use them that I know of is Mikeselectricstuff hack for Ipod nano screens.
so far It doesnt appear to be this way tho :(((
http://www.raspberrypi.org/archives/6299#comment-493964
This might help, but I don’t think it’ll do as much as you’re hoping. I spent a long tme researching MIPI-DSI as I had a couple of project ideas that would have needed access to “retina display” smartphone displays from a system like the Raspberry PI. As far as I was ever able to find, the problem isn’t in not having access to the GPU code. The problem is in not having drivers for the specific display.
As far as I understand it, the MIPI standards aren’t really complete standards like something like HDMI or DVI. They specify the basic electronics and signaling but don’t hold the manufacturers to maintain compatibility in tings like plug shape or timing. Each individual display requires a driver that defines the unique timing information of that specific panel and that info, as far as I know, is closely guarded trade secrets that you can’t get unless you are allowed to sign an NDA.
Basically, it was set up as a closed industry big-wig club from the start. The manufacturer’s have never wanted users to have the freedom to mix and match displays between smartphones or to use something like the iPhone display in their own personal project.
its a LOT better than the old rgb/lvds screens. MIPI screens act same way SPI screens do, only layer 0 is different
mipi is a data connection to lcd buffer, and not a connection to row/column drivers like in the case of LVDS lcd screens of the past
MIPI has a set of clearly standard instructions (initialize, start of frame, end of frame, etc). Screens can have non standard ‘acceleration’ instructions just like SPI screens (memory fill, copy, shift etc).
I knew I should have bought a raspi a few months ago. I doubt I could get my hands on one before this prize is claimed.
This is great news!
I gotta order me some more Pi’s
Mine are the older 256mb ones.. wish they’d take the Pi
to 1 gig of ram.
The current version of the Raspi is capped at a max of 512MB of RAM. There’s no way to get any more without a huge revision of the SoC.
To be honest I hope they are working on a revision. It certainly would’t hurt to switch to a more recent arm core (possibly add more than 1 core), up the Mhz and increase the RAM. While they are at it, integrate a Wifi and ethernet chip in there as well to reduce the component count.
Seeing as they dropped out of cellphone market this is something of a pipe dream. Lowest spec Chinese parts are more advanced, faster and more integrated than anything Broadcom has to offer, at a fraction of a price.
They had a foothold with Nokia using videocore, but that came and went. Maybe if they released datasheets and sources back then people would take them seriously.
Now they are relegated to TV/appliance market, and even there Chinese/Koreans are winning.
I was referring to Raspberry Pi foundation, rather than broadcom. I appreciate that the project was helped along by Broadcom employees (and I imagine the company in some respects). But the foundation doesn’t have any overwhelming ties with Broadcom and could jump ship if necessary. I would love to see an FPGA version either to co-habit the board or built into the SoC fabric…. Now I’ll admit that I’ve probably moved into fantasy land. But you have to start the ball rolling somewhere.
Broadcom helped out the foundation a heck of a lot and have been helpful at most steps along the path the foundation has taken, including the release of the videocore.
@rasz_pl, China might be producing some better chips, then again, so does samsung….. but that’s not the point of the pi is it?
I think releasing documentation and going opensource is a great thing for the community and helps extend the product life. I really couldn’t expect the same for new products but I hope other manufacturers will take notes from this for their older products.
If anyone is able to find the source and documentation on the completely useless Broadcom website he should be rewarded $10,000 already.
Document: http://www.broadcom.com/docs/support/videocore/VideoCoreIV-AG100-R.pdf
Source Code: http://www.broadcom.com/docs/support/videocore/Brcm_Android_ICS_Graphics_Stack.tar.gz
Amazing that it takes the Pi to get Broadcom to come out of their self imposed shell and actually work with their customers.