Slashdot Mirror
Broadcom Releases Source For Graphics Stack; Raspberry Pi Sets Bounty For Port
One of the few but lingering complaints about the Raspberry Pi is that it relies on a proprietary GPU blob for communication between the graphics drivers and the hardware. Today, Broadcom released the full source for the OpenGL ES 1.1 and 2.0 driver stack for the Broadcom VideoCore IV 3D graphics subsystem running on one of its popular cellphone systems-on-a-chip. It's available under a BSD license, and Broadcom provided documentation for the graphics core as well. The SoC in question is similar to the one used on the Raspberry Pi, and Eben Upton says making a port should be 'relatively straightforward.' The Raspberry Pi Foundation has offered a $10,000 bounty for the first person who can demonstrate a functional port. (The test for functionality is, of course, being able to run Quake III Arena.) Upton says, '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. But we're incredibly proud that VideoCore IV is the first publicly documented mobile graphics core, and hope this is the first step towards a blob-free future for Raspberry Pi.' Side note: the RPi is now two years old, and has sold 2.5 million units.
"One of the few but lingering complaints about the Raspberry Pi is that it relies on a proprietary GPU blob for communication between the graphics drivers and the hardware."
It wouldn't be so bad if this was the case. Unfortunately, closed GPU core is the main one in the device and the CPU is in fact a small, "slave core" in relation to the GPU. Without closed blobs running on the GPU, you cannot even boot CPU at all. Open OpenGL stack won't change that.
I'm not the OP, but:
The one that still had a ticket open.
If you slag the USB / Ethernet buses simultaneously, things nowadays slow to a crawl. Why? Because if they don't make them slow to a crawl, you drop USB packets silently, which makes the driver stack crash.
The bug was reported within weeks of release by a guy doing lots of USB / SD / Ethernet work simultaneously and I'm linked into it. Still unresolved, but they tweaked the "firmware" (really software) of the RPi to lessen the impact by degrading some performance.
It's a timing issue on the shared bus that's part of the hardware design and can't be "resolved" without a redesign. They just worked around it so that the blindingly-obvious bug when it was first released isn't so prevalant, but there's a cost.
My pre-order RPi ended up in my loft for 6 months after I waited a year for them to fix it (and also - on the request of some of the RPi designers / distributors - I had sent off SD cards to some guy at Broadcom who worked on the RPI "in his spare time" who then later discovered that it was because of things like this that SD cards weren't reading, not that they were old / strange cards). It's a nice gadget, but it is basically a bodge-job and for my use was useless for over 18 months without sight of permanent resolution.
If I spend days writing a GPU core port, I MIGHT get $10,000, unless someone beat me to it.
I appreciate the injection of funds into the open source community, but that's no way to run an economy. Hire someone. If you want more than one implementation or you want to have it fast, hire multiple people and offer a bonus for completion. But if you do the latter, don't expect to actually use the first one you receive, as it will likely be the shoddiest, meeting the bare minimum of your specs.
Someone had to do it.
The OTG host is now relatively bomb-proof as far as USB2.0 high-speed devices (i.e. onboard network) are concerned. Of course, performance and total throughput is never going to be on a par with EHCI hosts because, well, BCM2835 has an ARM11 performing the job that the EHCI controller otherwise does.
In the last few weeks a major rewrite has been pushed that, following some beta testing, should squash the remaining issues with the Achilles heel (USB1.1 devices on a USB2.0 host - via split transactions) and at least draw a line in the sand saying "these are the things that work flawlessly, and these are the things that will never work". The aim is to make the second set of devices an extremely small one.
Disclaimer: I am the guy that's spent the last 6 months slaving over a dual-port USB2.0/OTG analyzer figuring out *ALL* the damn bugs.
The Videocore IV on the Raspberry Pi (which totally kicks arse, BTW, it's a beautiful, beautiful processor. Did you know it's dual core?) currently doesn't have an open source compiler that's any good[*] which I'm aware of. I have tried porting gcc, and got a reasonable way into it, but ground to a halt because gcc. I know another guy who's similarly about half-way through an LLVM port. And Volker Barthelmann's excellent vbcc compiler has a VC4 prototype which makes superb code, but that's not open source at all.
Without a compiler, obviously the source isn't much good, although the VC4-specific code is really interesting to look through.
In addition, having done a really brief scan of the docs they've released, this isn't what the article's implying: what we've got here looks like the architecture manual for the QPU and the 3D engine. The QPU is the shader engine. Don't get me wrong, this is awesome, and will allow people to do stuff like compile their own shaders and do an OpenCL port, but I haven't seen any documentation relating to the VideoCore IV processor. The binary blob everyone complains about runs on that.
It does looks like the source dump contains a huge pile of stuff for the VC4, so maybe they're going to release more later. But even incomplete, this is a great step forward, and much kudos to Broadcom for doing this.
[*] I have done a really crap port of the Amsterdam Compiler Kit compiler for the VC4. It generates terrible, terrible code, but I have got stuff running on the Raspberry Pi bare metal. It's all rather ground to a halt because there's still a lot of stuff to figure out in the boot process, but interested parties may wish to visit http://cowlark.com/piface.