That's not correct. The code that's been released is for BCM21553, which doesn't have a VPU. There are bits and pieces of VPU assembler in there, but they're unused on the ARM target. The intention is that people port this (ARM-based) drop to run on the ARM on BCM2835. No reverse engineering required.
Ah, that makes more sense, thanks! There's an awful lot of vestigial VPU-related stuff lying around the source tree, including what I'm guessing are the unused remnants of a dead build system...
BSD-like licenses seem to be the standard for userland graphics libraries. There's a lot of useful stuff in there (for example the shader compiler) that may be of general use elsewhere, and we wanted to make sure people could use it.
The 3-clause BSD is a compromise - we're happy for the stuff to be used but it's nice to get some credit :)
Thank you for the clarification. It seems overly generous =)
Often code is GPL'd with pricey licenses for commercial applications - which always makes me think twice about investing my time into familiarizing with it.
I'm very impressed they aren't trying to make a quick buck here. It sounds like they have a very innovative long term strategy that will pay off many times over.
I think your competition is also fantastic, as it will encourage people to open source their improvements.
More a moral victory from my PoV. Remember, code that runs in the blob is running on another processor, so not costing you ARM cycles. That's why we've set the Quake fps target much lower than what you can hit with the blob.
Thanks for all the effort to get to this stage Eben. As someone who was repeatedly told (on the RP forums) that I had no business to desire the user-land graphics to be open-sourced, and that only hardware engineers would get any benefit from this code, I thought this day would never come!
I'm happy to be proved wrong, and happy that many little 'RasPis' will have an extended lifespan from this decision by your employer. :-)
Fingers crossed. I'm most excited about the GPGPU stuff people will be able to do now we've documented the instruction set for the QPU. More on this next week.
I think this is another example of how Raspberry Pi Foundation's decision not to move forward with a gazillion different boards, but rather to stick with A and B and let the software evolve, was a good one.
I'm very excited to see what the next year brings.
Different development boards (like the Beaglebone Black) are already more open, but get much less attention. The Raspberry Pi has an enormous amount of mindshare, but they've been doing a pretty poor job until now of shifting the status quo of this industry.
Yea with this happening I think what I would love is a bit more cpu power on the pi. Not even the new 64bit arm cores or anything but an A-15 or A-9 at double the MHz of the existing PI would put it in a huge sweetspot for embedded performance and make it far more usable for a desktop (with ideally more ram too but that's always good).
To be fair, the Pi opened the floodgates in terms of ARM boards; there are now loads of them.. not $25 but nothing like the insane pre-pi prices. The beaglebone black from TI is a good step up: 1Ghz A8 (~2x rPi performance), 1GB ram, $45. They don't really need to segment themselves (yet), as others can fill in the gaps.
The ability to boot a kernel with USB (and thus Ethernet) running. Probably not display in the first instance (we're hella-resource-constrained), but we'd want to add that later on.
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 confirmed by the recent move of AMD towards extremely hot GPUs. You already see that in the most recent 290x, but they're talking about making hardware that is comfortable running at >100C.
I'm not sure how relevant that is with regards to performance per watt, but I do know that heat is one of the most expensive (by-)products of electricity.
That's not really relevant. Broadcom's VideoCore competes against the likes of PowerVR, ARM's Mali, and Qualcomm's Adreno. Those GPUs are all designed for mobile use, and cannot easily scale up to compete with desktop/workstation-class GPUs due to architectural differences and fab process differences.
AMD's chips aren't egregiously power-hungry, they just sell into a market where the product segments are defined by the thermal and electrical limitations of the PCIe expansion card form factor. It will always be the case that the top of the line card draws as much power as can be delivered through the slot and two extra connectors, and as much as can be dissipated through a two-slot cooling system. If AMD can safely operate their chips at a higher temperature, then their cooling system will be a bit more efficient, so their thermal envelope expands a bit and they can increase performance by a few percent.
Early indications are that NVidia's upcoming Maxwell architecture achieves significant efficiency improvements due to being designed with mobile use in mind, but it hasn't yet been demonstrated in a large enough configuration to compare against high-end desktop graphics chips.
I just switched my GPU to an nVidia GTX 750 for precisely this reason. I have been near exclusively using Radeons for ten years, but the last few generations just run too hot and loud.
Isn't there some theorem of thermodynamics that says your device gets more efficient as the temperature difference between the hot and cold parts of the device increases?
AFAIK the only reasons devices aren't run at arbitrarily high temperatures is that material properties change unfavorably, or you risk fires.
The efficiency thing is more about heat engines. When we're just dissipating heat, the relevant relationship is that the rate of heat transfer is proportional to the temperature difference. This is why a hot object that isn't producing heat will cool exponentially. In the case of a steady-state source of heat, the temperature difference will be inversely proportional to the thermal conductivity of the connection between hot and cold reservoirs. Heatsinks and fans are used to increase that thermal conductivity so that the temperature difference stays small enough that the absolute temperature is safe. If you can double the tolerable temperature difference, then you can cut your fan speeds by more than half, or even get by with passive convection.
Or, approaching things differently, if you're only going to keep your graphics card for two or three years, there's no reason to let the fans spin up to an audible level until the chip reaches at least 80 degrees C.
Addressing a common misconception: fan speed/noise is not directly related to how much the graphics card is heating up the room by. Whether you run the fans at full tilt or you let the chip almost melt, the heat output will depend only on the workload.
Waiting for the VideoCore V :)
I noticed that the Broadcom LTE offerings such as the M320 do not use VideoCore and instead use PowerVR 5XT. Is it because they were originally Renesas designs? Hoping to see more VideoCore action in the future :)
Two years ago (or whenever the BCM2835 itself came out on the market), sure, but surely things have improved since? We've at least jumped a technology node, and hasn't nVidia improved?
Less than you'd think. Other vendors have improved somewhat, but from often from pretty poor starting points. Jumping a process node is a "brute force" approach: we can all do that. I'm more interested in apples-to-apples comparisons on a given node.
Had you worked on it directly, or were working on other parts of the chip while at Broadcom? I've always been hoping to see some hard benchmarks. I had worked on a video codec IP for a competing (but defunct) chip, hence my curiosity :)
I'm curious about the technological history of the VideoCore. The wikipedia page [1] and Broadcom marketing page [2] don't give a lot of information to distinguish it from competing cores (such as ARM's own Mali or nVidia's Tegra line). In fact, the information I see makes it seems pretty run-of-the-mill tech of 5 years ago.
I guess I could RTFM now that it's available :D
Edit/afterthought: none of this really matters actually, as there is no other chip on the market with the BCM2835's capabilities and that is more open-sourced.
I did work on it directly. James (now working solely for Pi as HW director), Gordon (now working solely for Pi as SW director) and I (still working for Broadcom, and for Pi) were members of the VideoCore IV design team. James and I were responsible for the QPU (quad processor unit) design and implementation in the V3D block.
There's no one thing about V3D which makes it superior to other cores. Just lots of attention to detail at the design, RTL implementation and layout stages.
