Yup. We know lots of people don't love the shiny (or love the speed more than the shiny), so we'll be providing the ability to turn off fades and scaled window browsing. Disabling fades has the nice side effect of removing 120Mpixels/s of blending, so you can have more windows on the screen before the back of the stack falls back to 30fps (for responsiveness the front of the stack will always run at 60fps regardless of scene complexity).
As the video and Daniel's post explain, we don't lose backwards compatibility because we can host legacy X applications in a Wayland window using XWayland. We get all of the benefits of doing top-level composition in hardware, none of the pain of writing (and maintaining) a hardware-accelerated X driver. Can you explain why anyone starting from a clean slate today would chose to accelerate X itself instead?
Now the question is how much of the work is done by the firmware on the GPU rather than the driver running on the CPU?
Easy answer - the majority of the intricate register-level work is done by the firmware, rather than by the driver. This is how we've been able to reconcile the legitimate interests of Broadcom in keeping the fine detail of the implementation private, while also providing a workable FOSS driver suitable for use in (for example) porting other operating systems to the Pi.
Apart from purists who want to have source for every programmable block on the SoC, everybody wins.
That's my hope. My issue with the purists is that it's not obviously clear why they want to see the microcode running on a proprietary RISC core inside the GPU, but not for example the Verilog. Stallman is one of the few people who has a self-consistent model of what he wants to be able to see, arguing that code which is "equivalent to a circuit" (i.e. in ROM) need not be made visible. Now we don't meet this criterion as our microcode lives on the SD card, but that's largely a cost and flexibility issue and we may yet go there to get the FSF endorsement.
From one point of view the cost to Broadcom to making this open source is not nearly the same as for the other GPU vendors -- I suspect this RPC glue is not among the crown jewels of Broadcom's IP
I should have kept some of my notes from those meetings:)
Does this (or will this) support future / higher end parts using the same VideoCore architecture? It definitely increases my interest in the BCM SoC family if so...
While I can't commit to this, I'm certainly a very vigorous advocate for this position, from a commercial and a community relations standpoint. Fingers crossed.
Absolutely agree with the sentiment here. Hopefully one day someone will produce a decent GPU that's free down to the Verilog level, but until then we'll have to keep taking one step at a time.
Actually, if you look at Broadcom's recent behaviour around Bluetooth drivers, I think there's good (public) evidence of a sea change in the attitude towards open source.
That is correct. Like many other pieces of hardware with open-source drivers, when you get down to it there's a chunk of microcode in ROM or RAM (ours lives on the SD card) which makes the hardware spring into life and talk to the open source stuff. The codec licensing stuff lives in there.
You're correct. The VideoCore GPU exposes a fairly high-level interface to the ARM side, so passing messages *is* the interface. We're lucky that VideoCore provides for a good tradeoff between the Broadcom's legitimate desire to maintain a degree of secrecy around the register-level operation of the hardware (read concern about competitors and patent trolls) and FOSS users' need for source code access and control.
Sorry - slightly loose use of language in the post on the blog. I wouldn't consider the DaVinci to be a "multimedia SoC" because it doesn't have a 3d accelerator. YMMV however, and there are certainly several examples of video-only ARM SoCs with FOSS driver stacks.
That was our feeling. This model is an order of magnitude easier to sell to the chip vendor, and provides all the benefits normally associated with open source drivers (provided the interface is adequately documented, which it will be in the near future).
That's a fair observation. We're lucky that, with firmware installed, the VideoCore GPU exposes a much higher-level interface to the ARM side than some other architectures. This has allowed us to provide a viable, useful open source stack while also addressing Broadcom's (completely legitimate) interest in protecting the fine detail of the underlying IP from competitors and patent trolls.
To help people get the most out of this, we hope to sponsor some efforts to formally document the interface exposed by the GPU over the next few months.
Off the top of my head, we save around a buck at 10K-off through a combination of 6 layer, coarser T&G and limited HDI. Figures for UK manufacture; YMMV in elsewhere, particularly in the far east (where cutting edge volume manufacturing is much easier).
The particular stack-up we've chosen is only one possible cost minimum; I've heard it suggested that 8 layers with zero HDI is quite competitive for 0.65mm BGA.
As I understand it, the biggest challenge was escaping a 0.65mm BGA without using significant amounts of HDI on a 6-layer board, while keeping good solid power and ground planes and large (i.e. cheap) track and gap specs. Relax more or more of those and it is indeed trivial - our alpha boards were done in about four days by doing exactly that.
Would be great to get all the components on the top side. Unfortunately, you pay for that in extra track length between the SoC decoupling caps and the BGA balls. I believe Beagle and Panda both do this with their OMAPs, and (mostly) get away with it, and we may investigate it in a later revision; in general departing from datasheet recommendations makes me queasy, even for a chip I worked on...
I completely understand the concerns around availability of datasheets and TRMs. For people who want this, Raspberry Pi may well not be a suitable platform; I'd suggest these people consider the many other small-board computers that are available *today*.
What I don't understand is why the OP feels he needs to say "probably the real reason is that easy physical access to the ports would more rapidly piss off those who buy it and realize the BCM2835 datasheet isn't available unless you're a megacorporation or an ex-employee like Eben is". That's just random hate.
Good question. We know the Beagleboard went through quite a long revision period before it got completely stable, though we've paid a bit more attention to things like ground plane configuration up front so hopefully we should converge a bit faster. Eyeballing it, probably a few layout tweaks in each production batch for the first six months.
It's interesting that the community's scepticism about the price point is pretty much inversely related to my own. As we've nailed down the BOM and assembly costs, and become more confident that we have a saleable product with margin, the level of doubt *outside* the foundation has crept up:)
The proof of the business model pudding will be when we've sold 100k and I still have a house.
Thanks. The selling millions thing is an interesting one. When you look at the amount of working capital required to get beyond the 100k units per annum point, it's pretty intimidating. Which is why we'll be giving away the schematics and Gerbers in due course to enable clone makers.
Not sure where the hate is coming from here. I totally agree Beaglebone is a very neat product for people with a bit more cash and no need to drive a display.
And ex-employee? My badge didn't let me in the car park this morning, so maybe you know something I don't:)
Massive agreement with this. We're *big* Arduino fans (and I personally am a big Atmel AVR fan). The few bright spots in computing education right now are around exactly this sort of cheap and cheerful hardware platform. We wouldn't want to do anything to undermine them.
Thanks for the kind words. I think we're about to learn some fun lessons about what selling tens of thousands of something involves, and we'll be doing it all in public:)
In all seriousness, we haven't taken anyone's money, and have spent a lot of our own time and money on this. We've been very open with people about the challenges we face in getting something like this done, and will continue to be open in the run up to and aftermath of launch. We're big boys, and can handle the hate.
I'd agree with this. Although we provide a bit of GPIO, we're aiming for a rather different market from Arduino. In particular, we consume much more power, don't have the ADC and PWM facilities that Arduino offers, and only do 3v3 I/O. Of course, I'd like to see the Arduino *tools* running on the Raspberry Pi.
Slashdot Mirror
Yup. We know lots of people don't love the shiny (or love the speed more than the shiny), so we'll be providing the ability to turn off fades and scaled window browsing. Disabling fades has the nice side effect of removing 120Mpixels/s of blending, so you can have more windows on the screen before the back of the stack falls back to 30fps (for responsiveness the front of the stack will always run at 60fps regardless of scene complexity).
Amen. X seems to have the highest complexity to documentation ratio of any major software subsystem I've ever come across.
As the video and Daniel's post explain, we don't lose backwards compatibility because we can host legacy X applications in a Wayland window using XWayland. We get all of the benefits of doing top-level composition in hardware, none of the pain of writing (and maintaining) a hardware-accelerated X driver. Can you explain why anyone starting from a clean slate today would chose to accelerate X itself instead?
Now the question is how much of the work is done by the firmware on the GPU rather than the driver running on the CPU?
Easy answer - the majority of the intricate register-level work is done by the firmware, rather than by the driver. This is how we've been able to reconcile the legitimate interests of Broadcom in keeping the fine detail of the implementation private, while also providing a workable FOSS driver suitable for use in (for example) porting other operating systems to the Pi.
Apart from purists who want to have source for every programmable block on the SoC, everybody wins.
That's my hope. My issue with the purists is that it's not obviously clear why they want to see the microcode running on a proprietary RISC core inside the GPU, but not for example the Verilog. Stallman is one of the few people who has a self-consistent model of what he wants to be able to see, arguing that code which is "equivalent to a circuit" (i.e. in ROM) need not be made visible. Now we don't meet this criterion as our microcode lives on the SD card, but that's largely a cost and flexibility issue and we may yet go there to get the FSF endorsement.
From one point of view the cost to Broadcom to making this open source is not nearly the same as for the other GPU vendors -- I suspect this RPC glue is not among the crown jewels of Broadcom's IP
I should have kept some of my notes from those meetings :)
Does this (or will this) support future / higher end parts using the same VideoCore architecture? It definitely increases my interest in the BCM SoC family if so...
While I can't commit to this, I'm certainly a very vigorous advocate for this position, from a commercial and a community relations standpoint. Fingers crossed.
Absolutely agree with the sentiment here. Hopefully one day someone will produce a decent GPU that's free down to the Verilog level, but until then we'll have to keep taking one step at a time.
Actually, if you look at Broadcom's recent behaviour around Bluetooth drivers, I think there's good (public) evidence of a sea change in the attitude towards open source.
That is correct. Like many other pieces of hardware with open-source drivers, when you get down to it there's a chunk of microcode in ROM or RAM (ours lives on the SD card) which makes the hardware spring into life and talk to the open source stuff. The codec licensing stuff lives in there.
Bwahahaha? Making thing people want to buy considered devious plan to make people buy thing.
You're correct. The VideoCore GPU exposes a fairly high-level interface to the ARM side, so passing messages *is* the interface. We're lucky that VideoCore provides for a good tradeoff between the Broadcom's legitimate desire to maintain a degree of secrecy around the register-level operation of the hardware (read concern about competitors and patent trolls) and FOSS users' need for source code access and control.
Sorry - slightly loose use of language in the post on the blog. I wouldn't consider the DaVinci to be a "multimedia SoC" because it doesn't have a 3d accelerator. YMMV however, and there are certainly several examples of video-only ARM SoCs with FOSS driver stacks.
That was our feeling. This model is an order of magnitude easier to sell to the chip vendor, and provides all the benefits normally associated with open source drivers (provided the interface is adequately documented, which it will be in the near future).
That's a fair observation. We're lucky that, with firmware installed, the VideoCore GPU exposes a much higher-level interface to the ARM side than some other architectures. This has allowed us to provide a viable, useful open source stack while also addressing Broadcom's (completely legitimate) interest in protecting the fine detail of the underlying IP from competitors and patent trolls.
To help people get the most out of this, we hope to sponsor some efforts to formally document the interface exposed by the GPU over the next few months.
Off the top of my head, we save around a buck at 10K-off through a combination of 6 layer, coarser T&G and limited HDI. Figures for UK manufacture; YMMV in elsewhere, particularly in the far east (where cutting edge volume manufacturing is much easier).
The particular stack-up we've chosen is only one possible cost minimum; I've heard it suggested that 8 layers with zero HDI is quite competitive for 0.65mm BGA.
As I understand it, the biggest challenge was escaping a 0.65mm BGA without using significant amounts of HDI on a 6-layer board, while keeping good solid power and ground planes and large (i.e. cheap) track and gap specs. Relax more or more of those and it is indeed trivial - our alpha boards were done in about four days by doing exactly that.
Would be great to get all the components on the top side. Unfortunately, you pay for that in extra track length between the SoC decoupling caps and the BGA balls. I believe Beagle and Panda both do this with their OMAPs, and (mostly) get away with it, and we may investigate it in a later revision; in general departing from datasheet recommendations makes me queasy, even for a chip I worked on...
I completely understand the concerns around availability of datasheets and TRMs. For people who want this, Raspberry Pi may well not be a suitable platform; I'd suggest these people consider the many other small-board computers that are available *today*.
What I don't understand is why the OP feels he needs to say "probably the real reason is that easy physical access to the ports would more rapidly piss off those who buy it and realize the BCM2835 datasheet isn't available unless you're a megacorporation or an ex-employee like Eben is". That's just random hate.
Eben Upton
Raspberry Pi Foundation
Good question. We know the Beagleboard went through quite a long revision period before it got completely stable, though we've paid a bit more attention to things like ground plane configuration up front so hopefully we should converge a bit faster. Eyeballing it, probably a few layout tweaks in each production batch for the first six months.
It's interesting that the community's scepticism about the price point is pretty much inversely related to my own. As we've nailed down the BOM and assembly costs, and become more confident that we have a saleable product with margin, the level of doubt *outside* the foundation has crept up :)
The proof of the business model pudding will be when we've sold 100k and I still have a house.
Eben
Raspberry Pi Foundation
Thanks. The selling millions thing is an interesting one. When you look at the amount of working capital required to get beyond the 100k units per annum point, it's pretty intimidating. Which is why we'll be giving away the schematics and Gerbers in due course to enable clone makers.
Eben
Raspberry Pi Foundation
Not sure where the hate is coming from here. I totally agree Beaglebone is a very neat product for people with a bit more cash and no need to drive a display.
And ex-employee? My badge didn't let me in the car park this morning, so maybe you know something I don't :)
Eben
Raspberry Pi Foundation
Massive agreement with this. We're *big* Arduino fans (and I personally am a big Atmel AVR fan). The few bright spots in computing education right now are around exactly this sort of cheap and cheerful hardware platform. We wouldn't want to do anything to undermine them.
Eben
Raspberry Pi Foundation
Thanks for the kind words. I think we're about to learn some fun lessons about what selling tens of thousands of something involves, and we'll be doing it all in public :)
Eben
You know how it is. Haters gonna hate :)
In all seriousness, we haven't taken anyone's money, and have spent a lot of our own time and money on this. We've been very open with people about the challenges we face in getting something like this done, and will continue to be open in the run up to and aftermath of launch. We're big boys, and can handle the hate.
Eben Upton
Raspberry Pi Foundation
I'd agree with this. Although we provide a bit of GPIO, we're aiming for a rather different market from Arduino. In particular, we consume much more power, don't have the ADC and PWM facilities that Arduino offers, and only do 3v3 I/O. Of course, I'd like to see the Arduino *tools* running on the Raspberry Pi.
Eben