A birthday present from Broadcom • Hacker News Board

Re: A birthday present from Broadcom

#121

Post by ebenupton » Sat, Mar 01, 2014, 1:52 AM UTC

hermanhermitage wrote: post #117

jxf wrote: post #21

If you want to go straight to the horse's mouth and just start hacking (this is Hacker News, after all!), the Broadcom downloads are here: * 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...

For those interested, as far as I understand it this release doesn't include VPU or QPU assembler tools. 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…

Figured you'd get a kick out of this release. Should be enough for people to figure out how Andrew's FFT code works.

Re: A birthday present from Broadcom

#122

Post by hermanhermitage » Sat, Mar 01, 2014, 2:01 AM UTC

ebenupton wrote: post #121

hermanhermitage wrote: post #117

Earlier quoted context omitted.

For those interested, as far as I understand it this release doesn't include VPU or QPU assembler tools. 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…

Figured you'd get a kick out of this release. Should be enough for people to figure out how Andrew's FFT code works.

Terrific release, thanks for all that hard work! (Who would have thought! well that crazy dataflow stuff actually works... :)

Re: A birthday present from Broadcom

#123

Post by userbinator » Sat, Mar 01, 2014, 2:25 AM UTC

aswanson wrote: post #101

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.

Wow. Much open, such surprise.

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."

Re: A birthday present from Broadcom

#124

Post by csense » Sat, Mar 01, 2014, 2:29 AM UTC

stingraycharles wrote: post #32

ebenupton wrote: post #11

Earlier quoted context omitted.

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.

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.

Re: A birthday present from Broadcom

#125

Post by ebenupton » Sat, Mar 01, 2014, 2:35 AM UTC

blah32497 wrote: post #113

ebenupton wrote: post #109

Earlier quoted context omitted.

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 fantast…

You're most welcome. Good times.

Re: A birthday present from Broadcom

#126

Post by Perdition » Sat, Mar 01, 2014, 2:37 AM UTC

stingraycharles wrote: post #32

ebenupton wrote: post #11

Earlier quoted context omitted.

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.

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.

Re: A birthday present from Broadcom

#127

Post by jotux » Sat, Mar 01, 2014, 3:13 AM UTC

ansimionescu wrote: post #40

jxf wrote: post #21

If you want to go straight to the horse's mouth and just start hacking (this is Hacker News, after all!), the Broadcom downloads are here: * 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...

Good ol' gzip download, because fuck source control. edit: FWIW, a friend who works there told me flat-out to just avoid them (I'm job-hunting)

Why would a large company release the commit history of source code when it could open them up to all kinds of lawsuits? It seems perfectly reasonable for them to release it as a zip.

Re: A birthday present from Broadcom

#128

Post by Taniwha » Sat, Mar 01, 2014, 3:14 AM UTC

embedded wrote: post #85

akiselev wrote: post #55

Earlier quoted context omitted.

This is almost a universal problem with firmware and chip engineers, who are generally older and more experienced, and thus apparently can't be taught new tricks. There are also issues with bureaucracies in each and every semiconductor company (which are on average decades old) so firmware is usually hot potatoed around by management and ends up lighting the customers' projects on fire almost every damn time. I don't…

Wow, armchair engineer, you sound like you really know what you're talking about. When this old engineer worked on embedded MIPS cores and 802.11[abgn] at Broadcom, everything was under source code control. This was pre-git, so I think we were using cvs. How the hell do you conclude that releasing a zip file means the engineers don't use source code control?

well as a many time Broadcom customer I've certainly seen the best and the worst of it - I've had large (1000 file) software releases for Broadcom chips that mutated their directory structure release to release, bug fixes would arrive and revert themselves, then after complaints return - integrating a new software drop into our VCS was always fraught and took weeks longer than we expected - people would fight not to be stuck with doing the next Broadcom integration and eventually we'd say "enough! we'll live with it" and refuse to take any new stuff - at one point we got the FE to admit that there was no one master tree inside Broadcom, just personal trees that were passed around - on the other hand other code from them was well maintained and obviously under good source code control.

I think the way to understand Broadcom is to realise that they are really a whole bunch of smaller startup companies, more are continually being bought and brought into the fold, this messes with their internal company culture, chips may have functional units in them that came from 5 different companies, each with their own coding standards, VCSs, documentation standards etc etc - as a result it's pretty hit and miss and may take a generation or two for a new technology to settle down - I kind of get the impression that there's ongoing friction between the remnants of these companies as they find their way in the new organisation

Re: A birthday present from Broadcom

#129

Post by Taniwha » Sat, Mar 01, 2014, 3:24 AM UTC

akiselev wrote: post #55

ansimionescu wrote: post #40

Earlier quoted context omitted.

Good ol' gzip download, because fuck source control. edit: FWIW, a friend who works there told me flat-out to just avoid them (I'm job-hunting)

This is almost a universal problem with firmware and chip engineers, who are generally older and more experienced, and thus apparently can't be taught new tricks. There are also issues with bureaucracies in each and every semiconductor company (which are on average decades old) so firmware is usually hot potatoed around by management and ends up lighting the customers' projects on fire almost every damn time. I don't…

akislev: I think you paint with too broad a brush - I've worked as a chip designer, embedded systems programmer, kernel hack - it really depends on the team - also most chip teams I've worked with have been relatively young (most in their 20s)- most big silicon projects depend on good version control software because you are doing continual integrations and practice tapeouts through the last half of a project - you may have 2-3 different versions of the code you're working on passing through different portions of the process at any one time

As the guy on the chip team who understood software well (or the guy on the software team who understood the gates) I do think there's a somewhat different issue that has to do with schedules: as a chip designer you get to do maybe 1 month a year of creative design and 11 months meeting timing and making damn sure that silicon will really work the first time - by the time you tape out you're really looking forward to that creative bit and about the time you've up to your armpits in it the silicon comes back and the firmware guys are doing bringup - you don't have a lot of time for the firmware guys because they're getting in the way of the cool part of your job, and besides you are sooo done with that chip you slaved over last year

I don't know what the answer is other than making sure you have firmware running on your logic simulator long before tapeout (you should be doing that anyway)

Re: A birthday present from Broadcom

#130

Post by fragmede » Sat, Mar 01, 2014, 3:38 AM UTC

fnordfnordfnord wrote: post #96

sneak wrote: post #58

Earlier quoted context omitted.

They aren't really a charity; they sell a product from a manufacturer (the Broadcom SoC) and were started by Broadcom employees. So, in a way, this "charity" is really just a marketing subsidiary of Broadcom.

>So, in a way, this "charity" is really just a marketing subsidiary of Broadcom. You could look at it that way if you like. But if you compare the rPi to the comparable low-priced educational development boards available when the project started (none). You might conclude that their marketing effort had a good and very real effect on the availability of low-cost edu dev-kits for both Broadcom SoC products and others'…

rPi is probably the most aggressively priced, but you talk about it like that market didn't exist. The BeagleBoard is probably the closest, though that was designed more as a dev-board for ARM processors and not a mini-computer like the Pi.