Because our own work was independent and pre-dates this information by a couple of years (in the case of the VPU), we have some alignment work to do in terms of mnemonics.
This release adds a lot of knowledge to the table - extending our understanding beyond the core instruction sets (which were already well reverse engineered) into a deeper understanding of the various hardware registers.
Proud to have worked on this during my 8-month internship at Broadcom. It remains one of the toughest and rewarding projects to tackle within the company. I am pleasantly surprised to see Broadcom open up like this and release the full documentation. A step in the right direction for a grossly under-rated company.
That's really a surprise. Broadcom is cemented in my mind as one of the hardest companies to get even basic datasheets out of.
I know the saying is "don't look a gift horse in the mouth", but could it be that their graphics cores are not competitive in pure technical capabilities, so they've decided to compete on open-ness? I'm not really involved in that area of hardware/software.
Looking at the long term future of the market, Broadcom's move isn't surprising at all. Broadcom (and Qualcomm for that matter) is feeling a lot of pressure from Intel and NVidia, both of whom have a lot of new stuff that are scaring competitors (which is fucking great for us). They're scared not from just a technological or capital/market perspective, but also from a community exposure one. They're both firing on all cylinders right now improving their technology and trying to get as many engineers to use it as possible. While firmware engineers tend to be older, there is a constant cycle and the industry is starting to see the importance of open source, especially as die complexity grows and more and more testing is required for each silicon design.
Intel: 2.5W TDP quad core Atoms with Intel's x86 instruction pipeline and memory management unit have been released as well as a low cost SDR that should be able to dynamically switch between unlicensed, GSM, CDMA, and LTE spectrum. Intel's graphics work is also quickly catching up and will soon start trickling into their low power embedded chips. Intel has also made clear moves with Galileo to open up their technology to the hobbyist engineers.
NVIDIA: The Tegra K1 is out to NVIDIA's partners (supposedly it beats VideoCore and even low end integrated desktop graphics) and they are currently being worked into tablets. NVIDIA also has recently released the i500, their own software defined radio to compete with Intel, and both companies have the resources to end the lock-in that Qualcomm and Broadcom have had in their respective baseband markets. If you're already buying radios from them, it makes sense to get your processor from them too and Broadcom may be trying to hedge against that.
NVIDIA (and maybe Intel) aren't known to be pioneers of open source but they're better than most other Silicon companies and everyone else is really starting to feel the pressure. The problem of supporting many different device configurations is an old one on desktop systems and that problem is only magnified 10x for embedded engineers because of the opacity. With Intel and NVIDIAs expertise on the desktop as they're running full steam ahead into embedded (and kicking ass along the way), they're scary to the old guard.
Nope (though note, I'm biased for several reasons). In terms of performance per unit area and performance per Watt, VideoCore IV is about as good as you're going to get. There are chips with higher performance GPUs out there, but they get there by brute force: throwing area (and therefore cost) and/or power at the problem.
This is almost certainly driven entirely by Eben Upton, who is the link between Broadcom and Raspberry Pi. He's probably been bundling up the huge list of demands for OSS video drivers and dumping them on the desk of the right person, while wearing down the objectors. It's something that Raspberry Pi have wanted for ages.
But we’re incredibly proud that VideoCore IV is the first publicly documented mobile graphics core
Wasn't Intel first by virtue of using their in-house "HD Graphics" hardware in Silvermont (Bay Trail-M and -T)? Regardless, this is a huge thing in the ARM world, and I hope other vendors will begin to open up documentation.
Bay Trail-M means "mobile" as in "laptop", not "mobile" as in "smartphone". Intel's smartphone stuff all still using PowerVR, including the upcoming Merrifield which will be using the PowerVR G64x0.
>"Earlier today, Broadcom announced the release of full documentation for the VideoCore IV graphics core, and a complete source release of the graphics stack under a 3-clause BSD license. The source release targets the BCM21553 cellphone chip, but it should be reasonably straightforward to port this to the BCM2835, allowing access to the graphics core without using the blob. As an incentive to do this work, we will pay a bounty of $10,000 to the first person to demonstrate to us satisfactorily that they can successfully run Quake III at a playable framerate on Raspberry Pi using these drivers. "
Just $10,000? Nice gesture, but they can afford to dig a
little deeper. Their card running Quake III at reasonable frame rate on a Pi is a big deal, and these cheap skates know it. (I hope the person who figures it out, doesn't
give them the code; just show them and collect $10,000 (A
years rent in a bad part of Oakland).
On the one hand as someone who owns half a dozen Raspberry Pis this is really cool news and I hate to look a gift horse in the mouth.
On the other hand, ARM vendors really have to start opening everything up much more than they have or Intel is going to start eating their lunch in the small embedded Linux arena, and I suspect Intel's mobile resurgence with Bay Trail is at least partly behind this "gift" to us all.
I don't know anything about mobile, but I've been looking at replacing my htpc ION system (edit: not that it really needs it, frankly it works great) and fanless baytrail boards/cases look very interesting. More cost than a pi + pi codec licensing obviously - but not that much, and all open as you pointed out...
I looked up the documents on it and Bay Trail is surprisingly open for an Intel SoC... although there's probably still plenty of stuff they won't tell you about.
The main touchy-feely moment for me here is that a notoriously closed, $17-billion company was brought around by a friendly, gentle approach to convincing it to be more open. Group hug for Broadcom.
Same could be said of their (albeit paltry) wifi open driver support since 2011. They at least have one now, for very few chipsets. Doesn't work with any of the half dozen Broadcom NICs I have in my "junk parts" bin, though.
This is a step in the right direction. Does this mean that the RaspberryPi can run blob-free now or with one less blob? I don't know what else is needed for the SoC to operate.
"This isn’t the end of the road for us: there are still significant parts of the multimedia hardware on BCM2835 which are only accessible via the blob."
Will running without relying on blobs mean that processing can be further optimised or is it more of a moral victory than a technical progression.
I'm assuming doing away with the shim means that there is some gain but in practical terms is it likely to be quite minimal? Will there be routines accessible that weren't accessible via the shim?
Well, let's see if someone can get Android to use the GPU now.
And yes, I'm not expecting miracles -- even though Broadcom never released their 4.x port, what they demoed on the-teaser-video-that-was-never-followed-up-on seemed "fast enough" for a number of purposes.
IIRC one of the bigger obstacles to RPi Android support was that the driver libs were linked against glibc. There will be other bumps, but just getting these linked against bionic will be a big help.
I'd love to see Android support, if only for Android's recovery system and read-only system images.
I'm building an environment for computer vision, and I recently made a client that can run on the rpi (two minute video if you're interested: http://www.youtube.com/watch?v=qSigkvbpb_Q). I'm not exactly sure what possibilities this opens up, but I'm definitely going to dig into it and find out.
Wow. In due time these guys might start actually releasing datasheets to developers who, you know, need to know the register set and API to like, make their chips work. I don't know why the hell these idiots treat their firmware APIs with Manhattan-project style secrecy, but I would highly advise against designing a new product with a broadcom chipset. They are totally asinine.
Quick noob question...is the Pi still the best/most flexible option for general hardware hacking? What about ARM dev boards from Samsung, Qualcomm etc?
'Best' can measured in a few ways, the RPi has a huge community, and it's certainly a bargain (though you will end up buying a bunch of odds and ends to get going). The Beaglebone Black is probably the other major contender, way more GPIO pins, can boot from the onboard memory, is ARMv7, for $10 more.
This is genuinely great news & a vast improvement over the previous graphics driver!
Hopefully this means we'll see proper DRM / Gallium support for the IV & I'm looking forward to seeing what people can come up with now that they have full access to the GPU.
I remember how satisfying it was to get that demo to work back in 2011 (thanks to the help of Dave Emett). Feels like an incredibly long time ago now! I wonder what framerate people will be able to achieve...
[+] [-] jxf|12 years ago|reply
* BCM21553 VideoCore IV graphics driver source: http://www.broadcom.com/docs/support/videocore/Brcm_Android_...
* BCM21553 VideoCore IV documentation: http://www.broadcom.com/docs/support/videocore/VideoCoreIV-A...
[+] [-] hermanhermitage|12 years ago|reply
We released a QPU assembler at https://github.com/hermanhermitage/videocoreiv-qpu/blob/mast... a couple of weeks ago. And a reference javascript VPU assembler is due very soon (mirroring the path taken with the QPU assembler).
Because our own work was independent and pre-dates this information by a couple of years (in the case of the VPU), we have some alignment work to do in terms of mnemonics.
This release adds a lot of knowledge to the table - extending our understanding beyond the core instruction sets (which were already well reverse engineered) into a deeper understanding of the various hardware registers.
[+] [-] ansimionescu|12 years ago|reply
edit: FWIW, a friend who works there told me flat-out to just avoid them (I'm job-hunting)
[+] [-] srcmap|12 years ago|reply
I created the srcmap index of raspberrypi_userland src tree here:
http://www.srcmap.org/s/sl.htm/p=raspberrypi_userland#c=P&d=...
Hope you guys find it useful.
[+] [-] tejbirwason|12 years ago|reply
[+] [-] samolang|12 years ago|reply
[+] [-] bliti|12 years ago|reply
[+] [-] patrickyeon|12 years ago|reply
I know the saying is "don't look a gift horse in the mouth", but could it be that their graphics cores are not competitive in pure technical capabilities, so they've decided to compete on open-ness? I'm not really involved in that area of hardware/software.
[+] [-] akiselev|12 years ago|reply
Intel: 2.5W TDP quad core Atoms with Intel's x86 instruction pipeline and memory management unit have been released as well as a low cost SDR that should be able to dynamically switch between unlicensed, GSM, CDMA, and LTE spectrum. Intel's graphics work is also quickly catching up and will soon start trickling into their low power embedded chips. Intel has also made clear moves with Galileo to open up their technology to the hobbyist engineers.
NVIDIA: The Tegra K1 is out to NVIDIA's partners (supposedly it beats VideoCore and even low end integrated desktop graphics) and they are currently being worked into tablets. NVIDIA also has recently released the i500, their own software defined radio to compete with Intel, and both companies have the resources to end the lock-in that Qualcomm and Broadcom have had in their respective baseband markets. If you're already buying radios from them, it makes sense to get your processor from them too and Broadcom may be trying to hedge against that.
NVIDIA (and maybe Intel) aren't known to be pioneers of open source but they're better than most other Silicon companies and everyone else is really starting to feel the pressure. The problem of supporting many different device configurations is an old one on desktop systems and that problem is only magnified 10x for embedded engineers because of the opacity. With Intel and NVIDIAs expertise on the desktop as they're running full steam ahead into embedded (and kicking ass along the way), they're scary to the old guard.
[+] [-] ebenupton|12 years ago|reply
[+] [-] pjc50|12 years ago|reply
Edit: ah, Eben has turned up here himself :)
[+] [-] rwg|12 years ago|reply
Wasn't Intel first by virtue of using their in-house "HD Graphics" hardware in Silvermont (Bay Trail-M and -T)? Regardless, this is a huge thing in the ARM world, and I hope other vendors will begin to open up documentation.
[+] [-] kllrnohj|12 years ago|reply
[+] [-] ebenupton|12 years ago|reply
[+] [-] fnordfnordfnord|12 years ago|reply
At last!
[+] [-] marincounty|12 years ago|reply
[+] [-] georgemcbay|12 years ago|reply
On the other hand, ARM vendors really have to start opening everything up much more than they have or Intel is going to start eating their lunch in the small embedded Linux arena, and I suspect Intel's mobile resurgence with Bay Trail is at least partly behind this "gift" to us all.
[+] [-] penguindev|12 years ago|reply
[+] [-] userbinator|12 years ago|reply
[+] [-] paulofisch|12 years ago|reply
[+] [-] zanny|12 years ago|reply
[+] [-] davexunit|12 years ago|reply
[+] [-] ebenupton|12 years ago|reply
[+] [-] mhurron|12 years ago|reply
"This isn’t the end of the road for us: there are still significant parts of the multimedia hardware on BCM2835 which are only accessible via the blob."
[+] [-] pbhjpbhj|12 years ago|reply
I'm assuming doing away with the shim means that there is some gain but in practical terms is it likely to be quite minimal? Will there be routines accessible that weren't accessible via the shim?
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] rcarmo|12 years ago|reply
And yes, I'm not expecting miracles -- even though Broadcom never released their 4.x port, what they demoed on the-teaser-video-that-was-never-followed-up-on seemed "fast enough" for a number of purposes.
[+] [-] mik3y|12 years ago|reply
I'd love to see Android support, if only for Android's recovery system and read-only system images.
[+] [-] josh-wrale|12 years ago|reply
[+] [-] ZeroGravitas|12 years ago|reply
[+] [-] monk_the_dog|12 years ago|reply
[+] [-] aswanson|12 years ago|reply
[+] [-] userbinator|12 years ago|reply
What next, a full BCM2835 datasheet?
To put in the words of Torvalds: "Hey, this time I'm raising a thumb for Broadcom. Good times."
[+] [-] stbtrax|12 years ago|reply
[+] [-] LukeB_UK|12 years ago|reply
[+] [-] zurn|12 years ago|reply
The Lima driver for ARM Mali is open source and runs Quake 3!
[+] [-] wolfgke|12 years ago|reply
But the Lima driver was created by reverse engineering instead of using publicly available documentation.
[+] [-] 13throwaway|12 years ago|reply
[+] [-] ebenupton|12 years ago|reply
http://www.raspberrypi.org/archives/5535
a lot of this work goes upstream.
[+] [-] mjg59|12 years ago|reply
[+] [-] skykooler|12 years ago|reply
[+] [-] leigh_t|12 years ago|reply
[+] [-] caycep|12 years ago|reply
[+] [-] blacksmith_tb|12 years ago|reply
[+] [-] pja|12 years ago|reply
Hopefully this means we'll see proper DRM / Gallium support for the IV & I'm looking forward to seeing what people can come up with now that they have full access to the GPU.
Congrats to Eben & the team - you've done good.
[+] [-] Danieru|12 years ago|reply
[+] [-] rdb|12 years ago|reply