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.
I have given up on the rpi and moved to the BBB since I could not stand the issues related to the broken-by-design usb system.
since ethernet goes thru usb and usb was flawed, this really put a damper in my networking use of this box.
its been at least a year since I checked in; have they fully and completely gotton around the usb 'elephant' bug yet?
--
"It is now safe to switch off your computer."
"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.
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.
Upton sez: "But we're incredibly proud that VideoCore IV is the first publicly documented mobile graphics core,"
Uh.. considering that the graphics cores in Baytrail tablet chips have had open source drivers in the mainline Linux kernel since at least early last year (the earliest commits may go all the way back to 2012), and considering that Intel's Gen7 graphics system is very well documented, I'd have to disagree there.
AntiFA: An abbreviation for Anti First Amendment.
BBB uses a fairly documented TI chip. Freescale has good products too. Why stick with this Broadcom crap?
I love that Q3 is the test case. That was probably the greatest multiplayer FPS game ever created. A good chunk of my life was spent playing and administrating a server.
My favorite "accomplishment" while playing was always "Rampage!".
"No matter where you go, there you are." -- Buckaroo Banzai
How about : Compile that to an ASIC.
meh
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.
Depending on what you're trying to do, you may or may not ACTUALLY have any performance trouble with this bug. I've been using an rpi as a router / firewall / proxy / etc. in my home for about 1.5 years now. I'm using the Ethernet port, plus a USB -> Ethernet adapter to get a second port. Performance may not be spectacular, but it's still good enough to saturate my home (15-20mbps) connection, with about 8-10 devices on the other side. Not bad, for a device that cost (including case, power supply, SD card, and ethernet dongle) about $60. Granted, there's lots of applications for which the rpi is not well-suited - but basic home-networking stuff doesn't necessarily have to be written off.
"The Foundation has discovered that the controller and its driver expect realtime response from the ARM core, and if Linux’s non-realtime scheduling doesn’t respond in 1 ms, a split transaction USB event can be dropped. Not surprisingly, this occurs regularly and produces lost mouse clicks, stuck keyboard keys, etc."
There are also unrelated USB power issues, however. Just use a good power supply :)
A router/firewall? With one ethernet port? Why would you do that?
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Well, I started off trying it out just to make sure I could get the software running the way I wanted to. My plan was to trial it with the rpi, and then move to "proper" hardware with dual ethernet ports eventually. But, as I mentioned, I'm saturating my connection with the rpi and a USB->Ethernet adapter, so I haven't seen any reason to move "up". Works great, draws very little power, and gives me all the speed I need. So, why wouldn't I?
YIS! now maybe i can start scrypt mining on my rpi! only got like ~1kh on the cpu core, with the gpu maybe i can get it to 20! hellllllllllllllllllllllllllooooooooooooooooooooooooo 15 cents a day! ILL NEVER HAVE TO WORK AGAIN
WÌÌfÍ--ÍSÌÒÍ...Í...ÌHÌÍfÍÍÍ--ÍÍÍ
http://www.videocore.com/
This guy's got it running on a dead badger.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
I am so god damn tired of this stupid argument. The CPU is not a "slave core". It is an ARM6 RISC core (with MMU) and it is what runs Linux and all the applications, not the GPU . The GPU does control the L2 cache and the memory controller/arbitrator which allows it to have the highest priority access to memory and meet the video memory bandwidth requirements. I haven't had time to read the hardware documentation now that it has been released (making it no longer closed contrary to your assertion otherwise ) so I don't know if a proprietary code blob will still be necessary to boot the CPU any longer or not. A quick scan did not reveal any specific mention of this in the documentation but with the release of the GPU instruction set in the documentation it should be fairly straight forward, although not easy to disassemble the proprietary boot loader code. I would prefer a fully open boot loader but as long as the current boot loader allows just about any OS to be booted, and as far as I know it does I can live with that. And finally, the only other two GPU cores available for ARM SoCs, PowerVR and Mali (the one used on the Beaglebone Black) are still, for now completely proprietary. This clearly means that contrary to another comment in this thread, the Beaglebone Black is not completely open.
If the video core in the BCM21553 is so close to the one in the BCM2835 (Raspberry PI CPU) that its possible to port from one to the other, why cant they release the source for the BCM2835 bits so no port is necessary?
Or is it too hard to disconnect all the video codec stuff (MPEG etc) that they cant legally release from the OpenGL stuff in the PI firmware?
BBB was interesting to me, but right from the get-go I couldn't get usb-modeswitch and looking into other drivers they just weren't there. Raspbian had things available that I needed. BBB is "better" but from a newbie perspective it seems it's for the more adventurous. I can write python but I can't write Linux drivers...
The GPU doesn't control anything. The VPU does. No documentation has been released for that. The ARM chip is totally slaved to the VPU. it does all hardware access by VHCI messaging. It has no direct access to any hardware.
The SoC has been designed this way so that hardware features can be disabled in the blob. This information was all publicly available before the first boards even shipped.
In short, you have no fucking clue what you are talking about.
And interestingly, neither do you.
The GPU does indeed starts up the ARM core - that a handover from the development of the chip itself which started as a GPU coprocessor. But from that point the ARM is independent (although can talk to the GPU if it wants to). AIUI, the ARM can access the HW registers directly, which is how the released software works. So, after the ARM is started it can run independently of the GPU processors.
Unfortunately, if you look at the "driver sources" carefully, it's just another shim to the real driver that does the heavy lifting. This implementation does not submit GPU instructions directly nor does it expose the shader compiler where someone can trace how shaders are being transformed into native instructions. In the end, it's just a layer that just submits user data to some specialized (probably proprietary) ioctl that exposes the functionality of the real driver implemented as a binary kernel blob and/or microcode running on the firmware.
See https://github.com/raspberrypi/userland/blob/master/interface/khronos/glxx/glxx_client.c for example.
On a related topic, I had an issue with my motherboard, which hasn't been resolved. It's an Asrock Z87 Extreme4. Running Windows 7 - I notice that the first hyperthread of my i7 4770k is pegged at 50%. Lots of digging, it looks like it might be a faulty design, putting the intel management engine and the USB subsystem on the same interrupt. What do you lot think?
http://forum.sysinternals.com/...
char*f="char*f=%c%s%c;main(){printf(f,34,f,34);}";main(){printf(f,34,f,34);}
Unfortunately, USB requires much CPU power. Some folks believe Intel pushed USB so hard specifically because it required higher-powered CPUs to run effectively, unlike the competing FireWire which is DMA.
Kriston