Video ARM Code for Raspberry Pi Goes Open Source (Video) 91
Slashdot: Alex, we're talking today about open sourcing parts of the
code that run the Raspberry Pi, simply the BCM2835 chip. Can you talk a little bit about what that chip does?
Alex: Sure. So the 2835, that's the core system-on-chip, which is comprised
essentially, the whole of the Raspberry Pi in a sense, in that you've got on there the ARM, the GPU,
and that the various libraries that are used to access that GPU by OpenGL-ES or OpenPG.
Slashdot: And how much closed-source code is actually used to run
the Raspberry Pi right now? In other words, how much is not already open source? I think a lot of people are under the
misimpression that the Raspberry Pi is an entirely open source project because it is so Linux centric and there's been so much open source involvement.
Alex: Yeah. Certainly we had, I mean, a substantial amount of it is open source. The Linux kernel module, which we use to communicate with the GPU, is fully open-sourced, GPL and BSD licensed. And the -- what we're open sourcing now are the libraries which run on the ARM side, the GL, the GL ES implementation, the OpenVG implantation, VGL, and so on. So really, how the architecture of the video core works is that there is some code that's running on the video core side that is quite proprietary, and that's unlikely to change in the near future, but what we've now been able to do is open up everything which runs on the ARM side. So everything which runs from Linux kernel up is now open source, essentially.
Slashdot: And is there new functionality that will -- either immediately or that you anticipate will -- be opened up by having this, the ARM side of the software stack being open source?
Alex: I think that in the near future it's going to make it a lot easier to
get things like native Wayland implementations working because of the EGL implantations being opened up, which allows
programmers to implement the Wayland platform requirements using the toolkits which we already have available. I mean, in general, I think it's going to make it much easier to work with the existing open source Linux stack, because quite understandably most people working graphics on Linux, it's all very centric around MESA and Gallium, the existing open source projects. It's very difficult to work with libraries which are closed and which they're constantly adding features to. Well, we've solved that problem now, and hopefully we'll start to see more people porting that technology to use Raspberry Pi.
Slashdot: Now you mentioned the GPL and BSD licenses are used extensively. What license is the new code or anything that's being open sourced now, is it all going be under the GPL?
Alex: It's all 3-clause BSD.
Slashdot: Okay.
Alex: So the reason, so the stuff we use in the kernel module is BCHIQ,
which is basically the machinery required to create a layer between the user space graphics driver implementation and
the video core. So that's actually dual GPL and BSD, to be friendly to the BSD guys. Now that we've got all the user space stuff also BSD, which is a very, very permissive license, we anticipate it will be very useful to people who are wanting to port -- other people who are working on FreeBSD, NetBSD, Haiku, Plan 9, RISCOS, etc.
Slashdot: Has there been, to your knowledge, much sort of cross pollenization of the existing code that's under that license?
Alex: How do you mean by cross pollenization?
Slashdot: Have any of those projects you just named, have they been interacting with Raspberry Pi developers? You just named several big . . .
Alex: Oh yeah. We have had that to a certain extent, certainly reports on . . .
they've been working with us on further developing through the API for doing low-level graphics, they've tried to build, you know, bring up their platforms. We've actually started to see patches reaching the mainline Linux kernel to start to provide platform support for the Raspberry Pi. We have a ways to go there, but that's something we're keen on pushing. I think we'll start to see much more collaboration with those projects with this open-source code. And we've also seen people who've been [hacking] on all the various device drivers, USB in particular. There's a Plan 9 guy, he got pretty far in doing a crash-free implementation implementation of the USB driver, which
is going to be interesting to a lot of people because it's currently rather large and difficult to do.
Slashdot: Now, one thing, the term "open source" can mean a lot of
things. In what way will this code that you're talking about open sourcing now on the ARM side of the stack be accessible to either developers, other programmers? Is it going to be, say, in
a public facing Git repository? Or will it be distributed on request? How will the Raspberry Pi project get that open source goodness out to other people?
Alex: Yeah, totally, fully, 100% OSI, FSF compliant, open source Free Software. So it's available under a BSD license. We have a GitHub repository -- do your standard "Clone it, send your patches," or pull
requests or whatever. Exactly what we do regarding opening up the development process, that's always quite difficult for us because when you have people who are contributing in their spare time, working on things, they don't always want to make promises they can't keep. So that's quite difficult too. We have to
strike a balance there between talking about what we're actually working on and making sense of people's disappointment.
Slashdot: Now, Alex, Eben Upton basically described you as the
project's Linux guru. Is there a team of people involved, both inside and outside Raspberry Pi, in making this open-source release happen? Or how many people are involved?
Alex: There's a small handful who've been involved in this open-source
release particularly. I mean, the main issue as with most of these open-sourcing efforts, is, of course, working through all the necessary legals, persuading the people who matter that actually there's not going to be a really big downside for not releasing access. They're not good at giving away valuable IP which is
going to downturn market position. So I think most of the work's being done with people like Eben, talking with Broadcom executives. Beyond that, there is a small handful of protocol engineers who then very generously give their time, and they've done the necessary legwork on cleaning up the code and making sure that it's ready for public distribution.
Slashdot: From that, it doesn't sound like you've faced a whole lot
of resistance in opening this code. Is that true?
Alex: Well, my understanding is that it's something which has taken a long
time. So it's been a slow process, but I think that it's partially due to the way that the video core is structured,
whereby most of stuff which runs in user space is pretty much just a serialization of your GL request and then it sends it over to the video core. So there's still plenty of stuff on the video core side, which remains private. I think that structure makes it more palatable.
Slashdot: You describe this as a process, and it's obviously got
both the actual development work, with the programming, coming up with open-source alternatives to closed-source options in some cases, and the licensing. What is the timeline going forward? Is this announcement, is there going to be a big 'We've open sourced all the ARM stuff" that is going to hit users immediately? If someone has a Raspberry Pi already, will they in the month of December be downloading a patch? What goes on for users from this point? For developers as well, for that matter?
Alex: Okay. Well, the big announcement is going to be on Wednesday, and the
GitHub repository will go public and everybody can clone it to their heart's content and get hacking. I would say that there might not be an immediate difference to users. But what we'll see over the next few months is better integration with the open source with its graphics stack.
Slashdot: Okay. What's the most exciting aspect of this?
Alex: Well, for me, I think that this is a major announcement in that this is the first [open-source driven] SOC. Broadcom was the first vendor to fully open source their user space graphics drivers. So I think its a pretty major step for embedded Linux.
People have been campaigning for, or begging for, for Mali
drivers, the Adreno drivers and so on. So I hope that this is a step that other companies will look at it, they'll see the
benefits which we're hoping to accrue over the next few months, and hopefully we'll start to see others following in our
footsteps.
Hallelujah (Score:5, Interesting)
Hopefully this means we can get a working CyanogenMod for R-Pi. There will allegedly eventually be an official (foundation) release of ICS, and hopefully this announcement helps pave the way for that since allegedly releasing the videocore was part of the problem, but since R-Pi now has 512MB it's likely the official release will target that.
Re: (Score:3, Insightful)
I feel like the tech press really dropped the ball on this and swallowed the hype from the Raspberry Pi Foundation. The drivers are not open source. The userspace stubs are.The stubs just use RPC to talk to the real driver which is still closed. Go look at the source code linked:
https://github.com/raspberrypi/userland/blob/master/interface/khronos/glxx/glxx_client.c#L488 [github.com]
The code here does nothing except RPC – this is not a driver. Which means that it’s not possible add OpenCL or new OpenGL ver
Re: (Score:2)
While you are entirely correct about that, I don't feel robbed; ISTR always being told that there would be binary blobs. We're talking about Broadcom, so that was always what to assume. On the other hand, I always had the impression that the kernel and the user space video driver would both be open source. Now they are. The only thing remaining is that we continue to get firmware updates, and that the interface be documented. This is what is needed to actually use the blob, which is enough for me for this p
Count me stunned (Score:2)
Obviously this is great news for open source, and especially awesome for the RPi project and all associated hobbyists... I'm just amazed that Broadcom, a company with a long-renowned disdain for revealing the specs on anything, had anything to do with this. Does anyone have more information on how this process came about? Reading the blurb I see that the videocore firmware is still closed, but operationally I don't think that's much of an issue.
Apologies if it's in the video, I cannae watch it at work cap'n
Re:Count me stunned (Score:5, Informative)
Hiding under the video is a "Hide/Show Transcript" link that displays a full transcript if you can't watch the video (or just prefer reading).
Re: (Score:2)
Many thanks, I'd skipped straight to the RPi page and missed the now glaringly obvious transcript button.
Re:Count me stunned (Score:5, Funny)
I'm told that authorities are awaiting the results of an MRI for confirmation; but there are strong suspicions that Richard Stallman succeeded in burrowing in to Scott A. McGregor, concealing himself inside the host body, and gradually subverting the host's central nervous system.
Re:Count me stunned (Score:5, Insightful)
Maybe he saw some money on it... They've sold about a million units just by virtue of supporting Free Softwre, how many more can they sell if they really support it? Anyway, it doesn't cost too much to find out.
Also, maybe the chineese promissing* that the A10 will have an entirely free stack helped a bit on this decision.
* As far as I know, they still didn't deliver it... But just the promisse should be enough to change Broadcom's strategy.
Re:Count me stunned (Score:5, Informative)
A lot of people have been complaining very loudly about this, because they announced that they had ICS running two months ago and there's been nothing released since, and the community has been unable to assist because not only has there not been any source release, but they haven't even released the videocore binary. Well, here's the sources needed to make it happen.
For the last month or so, I have been advocating the alternatives to the R-Pi specifically because the graphics driver has not only been closed, but has had an inadequate release schedule. This release should address that issue nicely.
Re:Count me stunned (Score:4, Informative)
Also, maybe the chineese promissing* that the A10 will have an entirely free stack helped a bit on this decision.
* As far as I know, they still didn't deliver it... But just the promisse should be enough to change Broadcom's strategy.
yes, that's the whole point. you play one company off against the other. the first one that *actually* goes and releases full GPL-compliant source code of their 3D GPU for example, i will INSTANTLY be recommending it to our clients. our clients are PRC State-Sponsored companies: one of them has a production capacity of 20 million units a *week*.
regarding the A10: *sigh* yeah i know. they can't actually release the source code of MALI, because that's locked down by ARM playing silly-buggers, including deleting public requests on ARM's forums for them to release the source code, *and* despite loads of ARM employees repeatedly advising ARM that releasing the source code is in ARM's best interests.
so we have to rely on the limadriver project, basically, which is making good progress.
we know that Allwinner made a promise to look at releasing the source code of the CedarX audio/video engine, but again, there, i think there will be more mileage out of reverse-engineering it. a "wrapper" has been written which traps system calls, giving a clear idea of what's going on.
the last part, the DDR3 "setup" phase, has already been reverse-engineered. it was a few hundred lines of assembler, that's all. so, the boot process is at least entirely free software.
Re: (Score:2)
If it was that easy... It seems that the Allwinner doesn't sell the A10 outside of China, and the boards I can find with it just don't have a good GPIO. As far as I know, there is no Raspberry Pi equivalent using the A10.
It probably won't be a problem for your client that is sponsored by the PRC, but it will limit the spread of the chip. Still, it se
Cubieboard? Re:Count me stunned (Score:2)
This is the system I'm watching, [cubieboard.org] http://cubieboard.org/ [cubieboard.org] 1GHz ARM cortex-A8, Mali400, 1GB RAM, Ethernet, USB, SATA, $49. I would need to learn more about both to compare GPIO. From their web page (and links), they've shipped one batch, getting ready to ship another, and larger batch in about a month.
If Cubieboard was available now I would have picked one up, but with the Raspberry Pi upgraded to 512MB and this source code release it's
Re: (Score:1)
"kickstarter" like project for the cubieboard up too ...
http://www.indiegogo.com/cubieboard?c=home
Re: (Score:2)
Thanks. It was about time somebody made a good board from that chip. Now I'll look closer for their promissed open source GPU driver :)
(But yeah, I've already brought a Pi. Maybe I'll want another in the future, and it could be this board, maybe not.)
Re: (Score:3, Insightful)
Perhaps the success of the RPi, coupled with people complaining about it being not-entirely-open, put enough pressure on Broadcom. Pressure in the sense of potential sales lost (possibly including other devices / markets that might use the same SoC). To the point where "It might be a commercial advantage if [fully open] checkbox can be marked" won out over "can't release sources due to to patents, 3rd parties, bla bla".
Of course I'm speculating here. But some markets are fiercely competitive, times are t
Re: (Score:3, Insightful)
Apparently - and I haven't confirmed this personally myself yet - the ARM code for the GPU is basically a thin RPC layer that forwards OpenGL API calls to the actual GPU driver, running on the GPU, which does all the interesting stuff. It's kind of a practical demonstration of why Richard Stallman is so opposed to binary blobs even if they don't run on the main CPU - if you find a bug in the drivers, you still can't fix it because it's almost certain to be in the bit for which you don't even have a disassem
Re: (Score:2)
It's more expensive to open it than to keep it closed, even if there's nothing valuable in it.
Re: (Score:3)
This assumes isolation of course. If it is more "expensive" but you end up selling a shit ton more than you would have otherwise, it is possible that it is indeed less expensive (more profitable) to open it up, even if it doesn't appear to be at the start. However, all of that is predicated upon knowing both outcomes beforehand. However, it should be possible to know how much more you'd have to sell before you reach the break even point is.
Re: (Score:2)
Perhaps Broadcom believed that the driver specs were the only thing standing between us and the zombie apocalypse.
Re: (Score:1)
The real question is, what did Broadcom think was so important about their shim layer that they needed to keep it closed source in the first place?
The intention is not necessary to keep it hidden but rather to enforce that the end user accesses the hardware in the correct way. By not opening up the extra layer they can use that layer to create compatible workarounds if they later on find hardware bugs. Now that they have opened it up they no longer have complete control over the usage so someone could be accessing the hardware directly. If they now need to meddle with the OpenGL data there might be users that gets their stuff broken because they acces
Re: (Score:2)
Now that they have opened it up they no longer have complete control over the usage so someone could be accessing the hardware directly.
That's a load of crap. Just because the Linux kernel and device drivers are GPL'd doesn't mean that there are dozens of office suites displaying document pages by writing into graphics card registers. In fact, I don't know anyone doing any such thing. People are still going through the drivers.
Re: (Score:1)
Re: (Score:2)
I've checked the code, and this is in fact the case. All it does is marshal the function arguments into a buffer and send them off into the GPU core, for every OpenGL function.
For the people who want open drivers because of e.g. linking problems, the ability to rebuild them, ABI issues, etc, this is good. For the people who want open drivers to improve them, fix bugs, see how they work, add new APIs, etc., this is useless. It certainly isn't an "open source driver"; it's just "open source ARM libraries". Br
Re: (Score:2)
Yeah... I have been avoiding the RPi due to Broadcom's long history of treating the open source community like shit... This is something I NEVER expected to see coming from them.
I'll be ordering a Pi tonight.
Broadcom began supporting open-source in 2010 (Score:4, Funny)
Broadcom broke down and released open-source drivers for Linux back in Sept. of 2010. See LWN [lwn.net]. They then joined the Linux Foundation in early 2011 (reference [zdnet.com]).
Their reputation for being open-source-hostile is well-deserved, but not entirely up-to-date. I can understand why people continue to avoid them, but it may not be strictly necessary any more. I haven't researched how well their open-source drivers work, because I haven't needed to in the brief period of time that it's been an option, so that may or may not be a factor as well.
Extremely Good News (Score:3)
Re: (Score:2, Insightful)
Which begs the question, how do you know what your dog's asshole tastes like?
Re: (Score:3)
This *partially* changes the ball game. ARM isn't a chip, it is a CPU component on the processor. The "chip" is comprised of many different parts, like Legos. That is why it is called a System on a Chip (SoC).
Other components, for example the GPU, are still very proprietary and closed.
Re: (Score:2)
Raspberry Pi is the first ARM-based multimedia SoC with fully-functional, vendor-provided (as opposed to partial, reverse engineered) fully open-source drivers, and that Broadcom is the first vendor to open their mobile GPU drivers up in this way
By ARM code they mean code compiled for the ARM CPU, the GPU drivers are compiled for the ARM CPU. GPU firmware is another thing
Re: (Score:3)
It's a step. Another step towards freedom. We may not get there all at once but if we keep taking steps we'll make it eventually. This is a big step.
Re: (Score:2)
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.
Re: (Score:2)
Hopefully one day someone will produce a decent GPU that's free down to the Verilog level
You raise an interesting point, but how would you make money from it? AFAICT current open source software companies make their money from consultancy rather than the actual product. Also things like opencores never really got much momentum behind them thanks to the twitchy legal departments.
I think the bigger problem though is you'd need the tool chain to go with it, so perhaps the first step would be an open source verilog simulator and debugger. There's no hardware equivalent of gcc.
I don't know this woul
Re: (Score:2)
You raise an interesting point, but how would you make money from it?
I'm sure the Chinese will be more than happy to demonstrate the answer to that question...
Re: (Score:2)
Hopefully one day someone will produce a decent GPU that's free down to the Verilog level
You raise an interesting point, but how would you make money from it?
Be first to market. Have the product on the market for six months or more before releasing the sources. Be a major vendor with partnerships with OEMs that will get the device into products, and further, with partners who will buy the chips from you even if another source crops up, at least for long enough for you to recoup your costs, probably protected by contract. Having the VHDL for a really complex GPU is only the first step to actually having a product on the market.
Re: (Score:1)
Other components, for example the GPU, are still very proprietary and closed.
From raspberry pi blog:
As of right now, all of the VideoCore driver code which runs on the ARM is available under a FOSS license (3-Clause BSD to be precise). The source is available from our new userland repository on GitHub. If you’re not familiar with the status of open source drivers on ARM SoCs this announcement may not seem like such a big deal, but it does actually mean that the BCM2835 used in the Raspberry Pi is the first ARM-based multimedia SoC with fully-functional, vendor-provided (as opposed to partial, reverse engineered) fully open-source drivers, and that Broadcom is the first vendor to open their mobile GPU drivers up in this way.
Yup, that's the GPU.
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?
Re:Extremely Good News (Score:4, Informative)
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.
Re: (Score:1)
Would you say this is the way forward for other GPU vendors to offer open source drivers - by embedding the actual implementation within the chip itself? Does this also have a benefit in offloading the high-level processing from the system CPU by running that within the GPU as well?
Does the VideoCore IV also incorporate it's own CPU-function that the embedded firmware runs on (I believe the VideoCore lines are fully fledged CPUs in their own right, with large vector/dsp/etc engines? Therefore it's the engi
Not the first. (Score:3, Interesting)
"ARM multimedia SoC with a fully-open-source ARM user and kernel implementation"
No. It's the first from Broadcom. I've got chips on my desk right now from TI (DaVinci series), with a fully open-sourced UBL and U-Boot (primary and secondary bootloaders), and a full GPL'd kernel. All ARM-connected interfaces also use open-source drivers. The only binary/proprietary part of this is the DSPBIOS and DSPlink section, but that applies to the C64x DSP processor half of the chip. The ARM part is ALL fully open-source.
Re: (Score:3)
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.
Re: (Score:3)
That's not really a multimedia SoC - it has no GPU.
It doesn't have a PVR subcomponent, so it manages to be fully open-source by not having a GPU... Which is the component that is usually closed-source.
This announcement is the first example of a GPU with open source support.
Interesting, interesting... (Score:3)
I wonder if this is some relatively isolated 'Yeah, go RPi! freedom and stuff! Now, back to business...' thing, or if this represents an actual shift in thinking on BCM's part, to the effect that keeping relatively banal code proprietary does actually inconvenience potential buyers of their chips without necessarily providing a commensurate competitive advantage?
Re:Interesting, interesting... (Score:5, Informative)
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.
Re: (Score:2)
I for one would definitely welcome more broadcom participation in open source. For example, there's some routers which aren't supported by alternative firmwares because they use one bcm chip or another. It's hard to see how that would help them sell more parts, though :)
Looks like the heavy lifting is done elsewhere (Score:5, Informative)
Haven't had a chance to wade through all the code here, but it looks an awful lot like it's basically rpc stubs and glue (allocator, buffer management, etc) to remote the OGLES calls to the media processor, which presumably handles all the actual translation of OGLES API to whatever the internal architecture of the GPU looks like. Which is a perfectly reasonable approach, just not necessarily 1:1 with the other SoCs (which don't have a GPU block capable of speaking remoted OGLES, thus requiring knowledge of the underlying hardware "secret sauce" in the GL libraries or drivers on the host side).
Awesome that they're releasing this as open source rather than insisting on keeping it closed -- much easier to work with this way.
Looks like the heavy hiding is done elsewhere (Score:2, Interesting)
Which is another way of saying the proprietary is simply "hidden" in a different manner. Also this could be a simple trial balloon for Broadcom. And last someone needs to fix the USB drivers.
Re: (Score:2)
To be fair, "open drivers / libraries plus proprietary firmware binary to download to hw block" is a better model than "closed userspace libraries/drivers" -- at least you have control/ownership over all the software running on the host side in this model.
Re:Looks like the heavy hiding is done elsewhere (Score:5, Informative)
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).
Re:Looks like the heavy lifting is done elsewhere (Score:5, Informative)
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.
Re:Looks like the heavy lifting is done elsewhere (Score:4, Interesting)
Yup. It's a common solution for video codec blocks, camera pipelines, etc, on ARM SoCs (open driver/library, closed firmware for the peripheral) -- less common for GPUs. I'm personally not at all offended by the "open drivers/libraries on host, closed firmware on peripheral" model -- it's a reasonable tradeoff and, as you point out, lets the vendors keep control over their secret sauce while still allowing for completely open software stacks on the host/AP side of the world. Apart from purists who want to have source for every programmable block on the SoC, everybody wins.
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 -- but from the viewpoint of someone who doesn't want to have to muck with closed binaries on the host side that are hard to debug, keep supported, adapt to changing APIs/ABIs, none of that matters -- the important bit is you get all the host side source.
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...
Re:Looks like the heavy lifting is done elsewhere (Score:5, Informative)
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.
Re: (Score:1)
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.
I consider "ability to redistribute the firmware for use on the hardware it belongs to" totally reasonable, but I definitely fall into the more pragmatic camp.
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 :)
I'm sure they were highly entertaining. Once upon a time I was involved in arguing with a SoC vendor's lawyers over the ability to open source *GPIO* driver support... progress in these areas can be amazingly hard to achieve...
Re: (Score:3, Insightful)
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.
Most likely because no-one's going to convert (for instance) their entire OpenGL ES driver implementation to Verilog and shove it down into hardware in order to claim to be open source, whilst adding a proprietary RISC core to the GPU and moving the driver on to that is a lot more practical but still destroys most of the reasons why people would want open source drivers in the first place. For instance, if the shader compiler chokes on your code and you want to figure out why, you're stuffed. If the shader
Re: (Score:2)
The "much higher-level interface" is basically just the OpenGL ES API, though. For instance, this file [github.com] contains Broadcom's ARM-side code for the vast majority of the OpenGL ES API calls, and it literally just forwards them over RPC to the closed firmware running on the VideoCore GPU. Even shader compilation runs entirely on the closed VideoCore. As far as I can tell, the only thing that doesn't is context setup and buffer management, which appears to involve mucking with some undocumented and decidedly low-
Re: (Score:1)
The biggest advantage here is that if the "top side" interfaces change, or something needs to change with how the library is compiled (say against glibc for a stock linux platform vs bionic for android), that's pretty trivial to resolve compared with getting a handful or .so or .ko binaries. And yeah, it doesn't help you fix the firmware if the firmware is busted, but it's still an improvement over where things were before, so hey, progress.
Re: (Score:2)
That doesn't surprise me. I suspect that some of the delay may have been due to Broadcom developing both sides of the driver as a single code base; the buffer management also looks like it might rely on them having similar code on both sides.
neat (Score:1)
I guess this means there's no holding back for openbsd on the pi.
Re: (Score:2)
The firmware is still a binary blob. My guess is that the codec support is controlled at that level.
Re: (Score:3)
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.
I'm confused (Score:1)
So the directory is called "/userland" and the code it contains for VCHIQ (the GPU driver) *appears* to be userland side - it does open, ioctl, etc. I'm not seeing any code that receives ioctls, nor any code that does virtual-to-physical mapping, or any register-writing. So if all the ARM code is opensource now, where is the VCHIQ kernel driver?
I infer from the comments on the Rasp Pi site that the GPU itself implements OpenGL, so passing messages to the GPU *is* the low-level interface. Correct? So all
Re: (Score:3, Informative)
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.
Re: (Score:2)
That is already included in the Linux kernel sources (GPL + BSD licence) available on the RPi kernel github: https://github.com/raspberrypi/linux [github.com]
Re: (Score:2)
That part was already open source. It's probably somewhere in here [github.com].
Re: (Score:1)
Is there an OpenCL interface on the VideoCore IV? Can one be added by upgrading the firmware, or by implementing it in userland and RPC to a lower level interface on the VideoCore IV?
Re: (Score:2)
Bwahahaha? Making thing people want to buy considered devious plan to make people buy thing.
Re: (Score:2)
And it works.
I'm going to order another Raspberry Pi because of this announcement.
way to see slashdot video with open source? (Score:2, Offtopic)
Sadly it seems the only way to see the video is to use the adobe flash plugin which is not open source. Is there some alternative trick that can be used to see the video with open source software?
Re: (Score:1)
--continuing clipped message--
I hope this will be just the start of a new era in broadcom that they do release and open things up, so that some serious open development can take place.
Re: (Score:2)
What Broadcom gives us? Well, I have the datasheet downloaded from somewhere else because I couldn't find a link on their Website and thats it. Where are all the docs?
On the other side of an NDA associated with an order of what was the quote? At least 10,000 units? Maybe it was 100k, but ISTR 10k.
I'm not all that upset about not getting the firmware code. This is the part that is necessary to be able to do things. Maybe not to fix things, but at least to do things. This is a very big deal.
The lack of documentation is distressing, but it's not a stopping point, only an inconvenience.
Brave of them... (Score:2)
Having worked with some of Broadcom's SoC code in (closed source) projects and having had to debug it. I'm surprised they're brave enough to put it in to the public domain. I suspect that's why there's been a delay.They've been sorting it out!
Meh (Score:2)
As Luc Verhaegen points out in the blog comments [raspberrypi.org], the code they just released is doesn't do any real, interesting work; for instance, the real work of glClear is done by making a "remote procedure call" [github.com] to the presumably proprietary glClear_impl:
GL_API void GL_APIENTRY glClear (GLbitfield mask)
{
CLIENT_THREAD_STATE_T *thread = CLIENT_GET_THREAD_STATE();
if (IS_OPENGLES_11_OR_20(thread)) {
GLXX_CLIENT_STATE_T *state = GLXX_GE
Re: (Score:1)
Eben Upton has a pretty good response to this [raspberrypi.org]:
We happen to have a GPU which exposes a comparatively high level (GL-like) interface, such that many of our userland functions are message passing shims. You are dealing with a GPU which exposes a lower-level interface, so LIMA driver functions often boil down to writing registers directly. These are design decisions on the part of the respective GPU teams, which have wide-ranging implications for the software and hardware structure of the devices which use the resulting cores. The VideoCore driver isn’t structured this way to pull the wool over your eyes[;] it’s structured this way because of a genuine judgment that this is the best structure given the resources we have on the chip, which includes a vector DSP to which we can offload much of the low-level register access.
GPU is not open in any sense (Score:1)
With this code release, the GPU is still 100% closed source. Only thing that's remarkable is that the GPU is so general-purpose that it can run even the shader compilers in itself. The ARM-part of the system doesn't do anything, it merely sends the requests via a dedicated RPC-method.
If this kind of "freedom" gets popular, I expect that graphics cards could easily integrate a small ARM-core with proprietary firmware to handle high-level OpenGL processing, and leave just a light shim to the main CPU.
Result