Weekly Edition
Return to the Kernel page
| |||||||||||||
Raspberry Pi VideoCore driver code released
The Raspberry Pi Foundation has announced that the
source code for its video driver is now available under the BSD license.
"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."
(Log in to post comments)
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 14:25 UTC (Wed) by swetland (subscriber, #63414) [Link]
To be fair, the driver/library here is an RPC interface for remoting OpenGLES to their VideoCore GPU (which has its own closed firmware for handling translation between that API and the bare metal). Claiming that Broadcom is the first vendor to "open their GPU drivers up this way" feels a little misleading to me, given that what they've opened is RPC stubs and associated glue, not any actual internals.
The model here is similar to how video codec blocks and camera/isp pipelines are supported on a number of SoCs already.
However it does mean that they're able to drop full sources for the userspace and kernel bits, which is indeed really nice. Zero proprietary binaries on the Host/AP side of the world is quite impressive.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 15:15 UTC (Wed) by cthart (subscriber, #4457) [Link]
I don't understand how this is any different to a video card in which the firmware is effectively burned into the silicon rather than being a binary blob downloaded (uploaded?) at boot time.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 15:22 UTC (Wed) by swetland (subscriber, #63414) [Link]
For PC GPU cards and for the majority of SoC GPUs, there is significant software that runs on the host CPU to transform OpenGL (or DirectX) command/data streams into whatever native formats the GPU understands, shader compilers, etc.
In the Broadcom VideoCore implementation, the embedded RISC processor in the GPU does all of this (including the shader compiler, I'm told), and the interface exposed to the host is the OpenGL|ES API (via RPC). Firmware to support this is downloaded at some point during/after boot.
At the end of the day, from the perspective of the person on the other side, you get an open source driver and no proprietary code that has to run on the host (big win), but from the perspective of "opening up their GPU drivers" it's sort of apples and oranges -- the BCM GPU driver is RPC glue and stubs, the drivers from (most) other vendors contain a pile of "secret sauce" related to how the hardware works.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 16:00 UTC (Wed) by arnd (subscriber, #8866) [Link]
I only briefly looked at the source code, but I can confirm that the shader compiler, like almost anything else, is indeed just called via RPC into the VideoCore.
Describing this as a fully open source graphics stack is of course a gigantic marketing stunt, but I also agree that it is a major step forward. Not so much because of the technical merits of that code but because it shows how even a company that is as closed as Broadcom can move towards an open ecosystem, and because it provides a good argument to counter all the SoC and GPU companies that require proprietary blobs running in user space or even in the kernel.
It's worth mentioning that the same GPU is used in the BCM28145/55 smartphone SoCs, and I really hope that having a completely open user space implementation gives Broadcom an advantage in Android products that leads to other companies moving to even more open graphics stacks.
Since you mentioned other implementations: are you aware of any GPU besides this one that has everything including the shader compiler in the GPU itself and can do the same trick?
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 21:15 UTC (Wed) by swetland (subscriber, #63414) [Link]
Nope -- every other GPU implementation I've seen thus far requires the shader compiler and even the general translation from OpenGLES API to native formats and command queues to happen on the host side. Including a full general purpose processor in the GPU block is unique to Broadcom to the best of my knowledge (though it is similar to how a lot of codec blocks work -- a pretty powerful, relatively general purpose cpu or dsp combined with dedicated hw accel units for heavy lifting).
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 23:30 UTC (Wed) by pabs (subscriber, #43278) [Link]
The best thing about giant marketing stunts is that they can be used as blunt objects to beat other vendors with :D
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 15:32 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Well, it depends.
At one end of the scale it's no different. I've owned devices where they shipped with a CD containing some version of the firmware that had passed their internal QA and they never released any other version. That firmware might just as well be on a ROM welded to the board and I don't feel at all uncomfortable owning such hardware even though the FSF don't like it.
At the other end of the scale you've got systems where the "firmware" is very much a constantly developing independent software project whose source code you can't see and which is capable of operating somewhat independently of the CPU. Newer drivers (which get pushed into the Linus source tree) may require a newer firmware, leaving you with little choice but to update as the vendor desires. If you do something the hardware manufacturer doesn't like, a newer "firmware" can retaliate, you are not really in control of your own hardware after all.
The Raspberry Pi GPU firmware is definitely leaning over toward the second category, this is actively developed code, if somebody figures out how to, say, reverse engineer a RPi into doing something Broadcom wish it not to do you can expect to see updated firmware to resist that, albeit the foundation would probably try to spin that as a bug fix or something.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 15:48 UTC (Wed) by njwhite (subscriber, #51848) [Link]
Thanks for this clear explanation; it's very useful for somebody like me who doesn't know a great deal about how video drivers / firmwares work.
Presumably getting them to open up their firmware will be an even more difficult challenge. Still, this strikes me as progress, though as you say, we aren't yet at the point of having complete control over your device.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 17:19 UTC (Wed) by robert_s (subscriber, #42402) [Link]
I also don't quite get what level of control this gives us over the graphics. i.e. will an RPi using this be able to do all the clever things DRI2 drivers can do?
Would wayland ever run on it? (not that you should peg me as a wayland fanboy, it's just serving as a good example)
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 17:21 UTC (Wed) by robert_s (subscriber, #42402) [Link]
Ah I just RTFA in full which says wayland should be possible.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 7:58 UTC (Thu) by ebassi (subscriber, #54855) [Link] Ah I just RTFA in full which says wayland should be possible. I honestly cannot see how that would follow: the shim driver does not allow adding required extensions, in case they are not present and exposed already; and it doesn't allow fixing bugs — which I just know are there because all GLES and EGL implementations for Linux on embedded hardware suck beyond belief. this is the same exact situation we already have with nVidia and their proprietary blob, or with the IMG open source Linux driver (which was used, amongst other platforms, on the Intel "Poulsbo" netbooks).
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 8:10 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> this is the same exact situation we already have with nVidia and their proprietary blob, or with the IMG open source Linux driver (which was used, amongst other platforms, on the Intel "Poulsbo" netbooks).
There is one difference that I see as being critical.
The binary blob doesn't run on the main CPU, and as a result, cannot affect or be effected by the rest of the code running on that CPU.
This means that changes in locking, changes in the kernel->driver API, and even changes in the X-> driver API (including making a Wayland or android driver) cannot be blocked because the vendor hasn't updated their driver for the new kernel yet.
It's much harder for bugs in the binary blob to break the kernel. locking problems in the binary blob cannot cause problems in the kernel, Other than DOS type problems, the only thing the binary blob can do to break the system is to start scribbling on memory that's not allocated to the CPU. this is still possible, but is a much, much smaller level of vunerability than when the binary blob is running in the same address space and on the same processor as the kernel.
I seem to remember a case a few years ago when Fedora didn't use the latest kernel that was out because NVIDIA hadn't updated their drivers to be compatible with it yet.
This sort of thing is not possible with everything that's running on the main CPU being open.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 8:20 UTC (Thu) by swetland (subscriber, #63414) [Link]
The big question I always ask about these designs is "can the peripheral processor access arbitrary memory"... if so, then you need to worry about bugs in the fw blob possibly splattering something you care about... on a number of the more modern ARM SoCs, the peripherals sit behind IOMMUs, so the kernel has final say in what exactly the fw can interact with. Not sure how things work in this particular BCM SoC.
Obviously, a completely open driver where you can fiddle with any part of it beats the implementation running on an embedded core, but I'll take the embedded core any day of the week over having to have random proprietary binaries in userspace or (shudder) the kernel.
All I ask is that the architecture give the kernel a way to protect the apps processor and main memory from the dedicated cores. Debugging memory corruption issues originating from blackbox coprocessor firmware: very not fun.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 11:09 UTC (Thu) by endecotp (guest, #36428) [Link]
> The big question I always ask about these designs is "can the
> peripheral processor access arbitrary memory" > Not sure how things work in this particular BCM SoC.
I hear that when this chip powers on, it's the GPU that starts first; it autonomously loads its firmware from flash, sets up the world, and then enables the ARM. It is Linux that is, in effect, running on the "secondary" processor.
Raspberry Pi VideoCore driver code released Posted Oct 28, 2012 16:52 UTC (Sun) by JanC_ (guest, #34940) [Link]
Which makes the ARM that you can run linux on a coprocessor that now can do callbacks to the main processor...
As if you would have an open source Arduino program send graphics commands over the USB/serial interface to your Windows PC, let a closed source program on the PC render stuff on its screen based on those commands, and then claim the Arduino has an open source GPU driver.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 17:32 UTC (Wed) by daniels (subscriber, #16193) [Link]
Actually, Pekka (one of the other Collaborans) already has Wayland/Weston running on RPi, albeit only for software-rendered clients. We should have more on that shortly. :)
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 16:38 UTC (Wed) by Zizzle (guest, #67739) [Link]
It doesn't look possible to add OpenGL/OpenCL extensions or new OpenGL versions. Therefore it's not a video driver (as others have pointed out).
It also means that RasberryPi will be forever stuck at whatever OpenGL version Broadcom has decided to throw over the wall since the real smarts are in the firmware.
> Raspberry Pi is the first ARM-based multimedia SoC with fully-functional, vendor-provided (as opposed to partial, reverse engineered) fully open-source drivers
is a complete lie and makes me want to have nothing to do with the Raspberry Pi or it's Foundation.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 16:44 UTC (Wed) by tuna (guest, #44480) [Link]
I agree.
I am happy that Broadcom opened up the user space parts of their driver, but I do not like being lied to.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 17:27 UTC (Wed) by dw (subscriber, #12017) [Link]
I find it a stretch to call this a lie; at some point a piece of hardware reaches a sufficiently advanced stage that it can fully represent a high level API to its host system, and somewhere an ill-defined line is crossed where the hardware's internals are now considered "software" and we have a prerogative to understand and exercise dominion over every aspect.
By that logic, the FSF should be picketing the Intel offices due to presenting a high level X86 API to GNU/Hurd, and demand immediate release of their microcode toolchain and all associated documentation. Join us now and share the hardware..
Ssomewhere we cross the line to activism for the sheer sake of activism, free of any underlying meaningful, useful goal to achieve. It's difficult to imagine Broadcom agreed to this release with disingenuity at heart, their solution to the problem domain just happened to evolve some strange CPU-like hardware that probably includes some bizarre opcodes for tokenizing GLSL, and due to this technical choice we're suddenly branding them liars.
Where is the limit defined? "Gee thanks for your firmware release, but I really need to see the netlist for your PARSEGLSLTOKENB instruction, otherwise this isn't truly free software". From certain angles the entire universe looks like software, and it's even fun to think about things like this, but at some point you have to accept that dirt is dirt.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 17:45 UTC (Wed) by Zizzle (guest, #67739) [Link]
Someone posted above that the shader compiler is in the closed blob.
I don't consider anything that contains a whole compiler to be hardware or microcode. Probably a stretch to call it firmware.
But the real test is how extensible this is. How future proof is it? And the answer seems to be "at the mercy of Broadcom". i.e. not very.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 17:57 UTC (Wed) by glisse (subscriber, #44837) [Link]
You want to know where the line is ? It's right there in front of your eyes :
Can you improve/fix/increase performance of GLES/GL with what have been released : no
Could you do such things if the firmware was opensource : yes
Then go compare other GPU, for instance firmware of AMD or NVidia GPU are mostly glorified register writter engine that are there so one does not need to constantly use the CPU to change GPU state. You can improve the opensource GPU driver for AMD or NVidia without knowing anything about the firmware. For this broadcom GPU you can't.
Which is why me and many other open source GPU driver developer just see this announcement as a complete lie.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 18:51 UTC (Wed) by robclark (subscriber, #74945) [Link]
I guess the closest analogy I can think of.. this would be like any of the other GPU vendors opening up their EGL implementation. It is better than any of the other ARM GPU players have done so far (which is not to say much), but it certainly is not an open GPU driver.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 19:55 UTC (Wed) by Lumag (subscriber, #22579) [Link]
Hmmm. Please expand my register-based nVidia Riva TNT2 to OpenGL 3.1
Of course I see your point. And I (mostly) agree with all the comments telling that Broadcom did less than the say in PR. I would certainly welcome disassembling/reverse engineering of broadcom firmware (it is doable, nouveau people did it for firmware-based cards). What I'm telling is that the border line is not that straight and clear.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 20:16 UTC (Wed) by GhePeU (subscriber, #56133) [Link]
I was going to say the same. I love the work TI is doing with the Pandaboard (they opensourced all they could, they're collaborating with the community, using a modern stack, expanding the closed source components to support Wayland, etc.) but the moment they stop development it's over, the pvr binary works with specific X and kernel releases and we'll be stuck with those forever.
In this case, the driver exposes some level of OpenGL/GLES, and all the rest can be built on that; if there are bugs or if some new extension is required there's nothing to do, but it seems to me that this is a lot more than what's possible with other SoCs. At least that's what I understood, please correct me if I'm wrong.
PS. robclark, if you're TI's robclark, I'm a fan! fan of glisse too, I've been using a r300 card for years.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 20:58 UTC (Wed) by robclark (subscriber, #74945) [Link]
Yeah, what BCOM has done should be enough to enable the community to add support for different window systems, and that sort of thing. So it is certainly better than nothing, and certainly better than what what the other embedded GPU vendors have done so far. But not as much as their PR would lead you to believe.
I think the progress on open drivers for mali and adreno, and what is starting to happen on tegra, is a lot more interesting and more beneficial for the community in the long run :-P
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 21:27 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> I think the progress on open drivers for mali and adreno, and what is starting to happen on tegra, is a lot more interesting and more beneficial for the community in the long run :-P
Hard to say.
On the one hand, a reverse engineered driver with access to low-level functions gives you a huge amount of capabilities with that system
On the other hand, having the Vendor directly open up the driver, even if there are only high-level functions available to the GPU is likely to mean that future GPUs from this Vendor will ship with similarly open drivers and not need reverse engineering to function.
Which is better?? hard to say. In many ways, having the Vendor loosen their grip on a part of the stack is much better than having reverse engineered drivers, even if those drivers give you more capabilities.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 7:51 UTC (Thu) by nhippi (subscriber, #34640) [Link]
> Yeah, what BCOM has done should be enough to enable the community to add support for different window systems
What BCOM has now done, allows community to keep maintaining code regardless of how the kernel/X abi's change over time. Compare it with OMAP and PowerVR, once TI stops supporting beagleboard/beaglebone/pandaboard, community is stuck with the X and kernel's that remain compatible with last binary release of PowerVR drivers.
Community still can't fix any bugs in the BCOM firmware side or add new gl extensions - which can become a problem if new versions of X/wayland/whatever need a new extension.
But it is a step in the right direction.
> I think the progress on open drivers for mali and adreno, and what is starting to happen on tegra, is a lot more interesting and more beneficial for the community in the long run :-P
What worries me is the long run might take too long. Once mali400 and adreno support starts to work, SoC vendors may already have migrated to newer GPU designs.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 13:05 UTC (Thu) by robclark (subscriber, #74945) [Link]
yup, what BCOM has done is an improvement over what any of the other ARM GPU vendors have done so far. I'm certainly not criticising that. But it amounts to an open source EGL plus a GL shim, not a GL driver.
Perhaps the line is blurry about when a firmware is just "some microcode" and when it is a driver. In this case, the "some microcode" on r-pi runs threadx, it includes the shader compiler, and basically all the GL APIs map 1:1. This is most certainly not just "some microcode". Since, afaiu, the display hw is also controlled by the videocore cpu/coproc, you could probably port some gles apps and run them directly on the coproc, if you had the src to that "some microcode". So the line may be blurry, but the r-pi is so far past that line that it doesn't really matter.
So I'm not criticising what was released.. I'm only criticising that it was called an open source driver, when it clearly was not.
-----
As far as the open source drivers keeping up w/ new generations of hw.. well, it is true to some degree. But there has already been a huge amount of progress in the last year or less. Of course if it is always based on r/e products that are already released then we'll always be a bit behind. I would hope that eventually we can get to the point where some GPU vendors start working with the open source community, releasing specs, etc, like AMD and intel do in the desktop world.
At least on the plus side, we don't have the huge reclocking complications like there is on desktop GPUs. For the ARM embedded GPUs all the clock control is in the open src kernel drivers. (Well, maybe not the case for r-pi, but at least for all the mainstream embedded GPUs.)
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 20:24 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
This is like complaining that your modem cannot be upgraded because you can only talk to it via the AT command set, while other types of modems (i.e. winmodems) require that you do far more processing in ram, and therefor require lots of special drivers.
I'm actually very happy with everything that runs on the ARM now being open. This means that as these pieces get accepted the the upstream kernel I can now compile and run my own kernel on the pi, while getting full graphics support and without having to wait for any vendor to update their drivers.
In many ways this is far better than the situation for just about everyone on x86 systems. Yes, you can run the open drivers for AMD and the reverse engineered drivers for NVIDIA, but neither of those options will give you the performance of the closed drivers.
The fact that this is a high-level interface to the GPU does limit some things, but it also makes it possible for the GPU to optimize things that it couldn't do if the lower level interfaces were exposed.
Would I like the source for the GPU firmware? Sure. Especially with the DSI and CSI (display and camera interfaces) requiring that they be accessed through the GPU there are things that the hardware could do that we can't do with it since we don't have this access.
But this is a very good step in the right direction as it now means that everything that runs on the main CPU is open.
note that they are speculating on the option of releasing a different version of the pi hardware that would have this firmware burned into ROM instead of being loaded through the bootloader. This would satisfy the FSF and make the device both more expensive and less flexible. I hope that they do create such an option someday, simply so that we can get proof that all those people who whine about closed firmware won't actually pay more for something complient with their demands.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 22:14 UTC (Wed) by pboddie (subscriber, #50784) [Link] I hope that they do create such an option someday, simply so that we can get proof that all those people who whine about closed firmware won't actually pay more for something complient with their demands. While I'm sure that some people would like to point the finger at anyone objecting to closed firmware and put one label on them all, there is by no means widespread acceptance of closed, immutable firmware within the FSF-supporting Free Software community, let alone the open hardware movement. Of course, I wouldn't put it past the Raspberry Pi people to do what you suggest, as it would be quite the marketing stunt and yet another opportunity to be condescending to people with reasonable concerns. From what I've seen, quite a few people are baffled by the argument that closed, immutable firmware should be approved by the FSF and feel that it would be far better if the FSF extended its principles as far into hardware as possible. Here, the FSF is actually being kind of pragmatic: if the functioning of an otherwise fully interoperable device depended on a proprietary software stack to make it functional through the loading of firmware, then mandating that the firmware reside in some kind of non-volatile storage and not require "updates" to unlock functionality somewhat levels the playing field for systems that need to work with that device. However, I feel that the FSF would be better off withholding approval, even if that meant never or rarely giving approval at all, than granting it on the basis of apparently counterintuitive or contradictory reasoning. After all, the FSF is meant to adopt moral positions that are not necessarily convenient but which express a direction in which things should be moving. Telling people that they have arrived at this moral destination, when one would really like them to go beyond it, is arguably counterproductive.
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 22:55 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
Most people will agree that the firmware on different layers is different levels of importance.
The idea that what matters is if it's in ROM or if it can be updated is the most bizarre boundary that I can imagine.
By far the most important thing is having the source to anything running on the main CPU
Next would be anything that can write to the memory without restraint (setting up an IOMMU that restricts where a card can write largely closes this one) because things can write to memory can interact with your main OS
For anything that isn't able to directly interact with memory is a peripheral of some sort.
The levels of openness on a peripheral are:
1. I can't use it.
2. I can use it only with some proprietary software that I don't know what it's doing.
3. I can use it with reverse engineered software, but I still don't know why the software is doing what it's doing.
4. the interface for accessing the device are documented so now I know what the software is doing and why
5. I can replace the firmware on the peripheral with reverse engineered firmware
6. I can replace the firmware on the peripheral with firmware that is using documented APIs of the peripheral internals.
I consider a peripheral that has the firmware in rom to be crippled as it forever prevents #5 or #6.
Almost all ARM devices are stuck at #2 (if they aren't at #1)
With this announcement, Raspberry Pi went from #2 to #4
Now, some people are complaining that the API to the GPU is a higher level than they would like. As far as I am concerned, as long as every OS that talks to this chip uses that high-level API, that's the appropriate API to put in drivers.
As a device designer, you may say that it's a bad API and choose to use a different device instead, but to declare that such an API should not be allowed into the kernel because it's too high level (like I've seen from some people) is wrong. High level or not, it is the API to the device.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 0:21 UTC (Thu) by airlied (subscriber, #9104) [Link]
the API to the hw device isn't known, but I can guarantee this isn't it. HW has in the past had an API quite close to GL (even nvidia does it kinda like that now). but the thing is GLES requires a compiler, no one sane puts a compiler in hardware, GLSL isn't at the opcode level, its at the C level. Not opcodes at an assembly language.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 0:46 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
The API to a modem is the AT command set
does anyone seriously think that this is what the bare hardware understands? NO. But this is still the API to the peripheral.
Unless there is some other way to interact with this GPU, this is the API for the GPU. You may not like it, or may want to have a lower-level API, but that's not relavent to what the API is.
let's look at storage.
you can have a very, very low-level API (MFM/RLL era)
step this many cylinders in this direction from where you are, wait this long from the 'start of track' marker and start reading/writing data
you can have a low-level API (IDE/ATA/SCSI era)
write this chunk of data to this disk block, potentially with reordering of actions
you can have a medium-level API (filesystems)
you say you want to create a new file and write to it, the filesystem creates directory entries, decides where the file will actually live, etc
If a device plugs into your network and implements the NFS protocol, it doesn't make your OS any less 'open' to use this device, even if you don't have access to the software running on this device, or if said software in in ROM
and you can have a high-level API
object based storage, think web based storage (although people keep talking about having this at the drive level as well), you tell the storage what blob you are dealing with and you read/write the entire blob
note that the way the storage is attached doesn't have that much to do with the API level.
you have experimental drives that you talk object based APIs via a SCSI buss, and you have SCSI level APIs that you talk to over an ethernet bus.
It doesn't matter that most GPU vendors are shipping devices where the API is at the same level as the old MFM/RLL hard drives. Having this GPU operate at a higher level (ATA/SCSI equivalent) may be a dead end, or it may be the wave of the future, people will disagree and only time will tell.
There can be very real advantages to having higher level APIs to devices
But in any case, API for this device really is the high-level interface. you can prove this by talking to it.
> no one sane puts a compiler in hardware
what about ACPI? I thought that handling those calls required a compiler in the BIOS
you may argue that CPI isn't sane, but sanity (expecially by the terms prior to a new thing being released) is a poor indicator for how successful something is going to be.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 0:54 UTC (Thu) by airlied (subscriber, #9104) [Link]
there is an ACPI interpreter in the BIOS, its not a compiler, it doesn't take highlevel C like language and compile it down to basic assembler opcodes, ACPI langugage is like assembly, GLSL is exactly like C.
But anyways I'm not sure why you think I care about your opinion, you've made up your mind that you want to live with what you are given by vendors, I'm more interested in what vendors can do to help Linux than themselves.
Like if I put the whole of Linux below the syscall interface onto a second CPU and didn't give you the source, but all apps called into it via an RPC interface, you'd probably think it was the greatest open-sourcing ever.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 1:18 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> Like if I put the whole of Linux below the syscall interface onto a second CPU and didn't give you the source, but all apps called into it via an RPC interface, you'd probably think it was the greatest open-sourcing ever.
not the greatest open-sourcing ever no :-)
but if you were talking about open-sourcing the application and software running on the first CPU, I would say that yes, the system on the first CPU was open-source, even though it called an independent system that lives on the second CPU.
I don't see this as being significantly different from an Open Source tool that makes calls to Google Maps.
If it's running on a separate CPU, and it's not doing things like sharing memory, then it doesn't count as far as the Openness of the first software.
As others have noted, if you keep drilling down, you get to things like the microcode on the x86 CPU as something that's not open, and that you are accessing through a much higher level API from what the native chip supports. The x86 CPUs can even include compilers to convert the x86 instruction set to lower level code.
Does it make Linux any less free if it's running on a Transmeta CPU than on a 80386 CPU?
Does it make Linux any less free if it's running on vmware emulating a x86 CPU instead of on native hardware?
what about running Linux on an ARM emulator running on Windows instead of on a real ARM chip?
at what point does the manipulation of the commands before they hit the actual circuit mean that the API for those commands is not 'legitimate'?
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 13:23 UTC (Thu) by pboddie (subscriber, #50784) [Link] but if you were talking about open-sourcing the application and software running on the first CPU, I would say that yes, the system on the first CPU was open-source, even though it called an independent system that lives on the second CPU. I think the objections people have to this announcement are mostly centred on the assertion that Broadcom have opened up access to the underlying technology when in practical terms all they have really done is acknowledged the nature of the API for specific functionality provided by the SoC. And all of this publicity downplays the fact that they've moved software behind the curtain and onto the proprietary CPU core. So although this release helps people to write software against that narrow API, it's very much business as usual. Does it make Linux any less free if it's running on a Transmeta CPU than on a 80386 CPU? Although you can have CPUs with loadable microcode, I don't think these arguments really help the discussion along because they inevitably lead to remarks like "You can't fabricate your own CPUs, and I suppose you extremists won't be happy until the proletariat have seized control over the means of production!" Far more illustrative is to consider things like printers supporting standard interfaces like PostScript. It's a positive thing that you can (or could) get a printer that any system could talk to using a well-defined (and hopefully standard) communications mechanism, but it's a different matter from being able to enhance the printer's own operation, if this is desirable. And it's always necessary to question the redefinition of system boundaries because you can easily end up with a dumb terminal talking to a proprietary mainframe that does all your graphics and printing for you. Or you have all your applications running in a proprietary cloud. And so on.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 20:26 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
did they move functionality, or has their chip always worked this way?
pushing functionality away from the main CPU and providing higher level abstractions and APIs is an ongoing process that has been going on as long as computers have been around.
The assertion is that everything running on the ARM processor is now open.
They have said for a while that the source for this userspace code was not going to be particularly interesting to people, but there was still a loud demand for this code to be opened. They did so and now people are complaining that it's not interesting.
no matter what you believe the boundary of openess should be, there is no doubt that this is a move in the right direction.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 22:07 UTC (Thu) by pboddie (subscriber, #50784) [Link]
It's actually not correct to bundle things like abstraction together with where functionality has migrated to over the years, mostly because functionality has migrated in different directions, whereas the level of abstraction in the components of the average system has mostly increased.
For example, video control was indeed done by the CPU in various microcomputers and then migrated to dedicated circuits of different forms and with increased sophistication, but other activities - notoriously, modems and printers - have seen the CPU bear the bulk of the workload in various periods. Much of this depends on whether it is considered worthwhile to have dedicated hardware for a particular task that could be done in software running on general purpose hardware.
I agree that for practical purposes being able to build these "drivers" from source increases the general level of support for the SoC in Free Software projects and is thus an improvement on the previous situation, but given the limitations on actually modifying the system's behaviour (the objections brought up by various driver developers), it's clearly not the milestone that we've been sold by the announcement.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 23:23 UTC (Thu) by ncm (subscriber, #165) [Link]
It depends on whether the second CPU has access to the RAM and devices of the first, no?
Raspberry Pi VideoCore driver code released Posted Oct 26, 2012 9:37 UTC (Fri) by renox (subscriber, #23785) [Link]
>It depends on whether the second CPU has access to the RAM and devices of the first, no?
As if there wasn't other devices with drivers in the Linux kernel which has closed source firmware and which can corrupt your RAM with DMA.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 1:23 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
> what about ACPI? I thought that handling those calls required a compiler in the BIOS
No, ACPI code is never executed by the BIOS.
Sane companies and compilers in hardware Posted Oct 26, 2012 0:11 UTC (Fri) by ncm (subscriber, #165) [Link]
"no one sane puts a compiler in hardware"
Funny that you should say this... Every 686+ chip produced by Intel and AMD today has a compiler in hardware. It takes for its input x86 instructions, compiles them to RISC operations, and peephole-optimizes the hell out of that. It is very unlikely that the shader compiler in this gadget is within one order of magnitude as complex as what is in every i5. Maybe not even two.
I don't know if those x86->RISC compilers are in rewritable microcode, but that's the way I would bet. That compiler's output has total access to all memory and devices. It might even run when you install new microcode, and doctor that, Ken Thompson-style, to have the same back door as the old.
There are probably good reasons for China to have their own, independent CPU designs, even at a cost of reduced performance. And for the rest of us, too, maybe.
Shader compiler on the GPU Posted Oct 26, 2012 14:43 UTC (Fri) by alex (subscriber, #1355) [Link]
I don't think that was done for this particular release. As far as I can tell it's a design feature of this family of GPUs. So all platforms using the chip will use the same RPC like API to the GPU.
Raspberry Pi VideoCore driver code released Posted Oct 26, 2012 18:30 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
> the API to the hw device isn't known, but I can guarantee this isn't it.
If that's the case, please point to the code that talks the "real" API
It's not in the kernel, it's not in userspace, so where is it?
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 6:52 UTC (Thu) by paulj (subscriber, #341) [Link] The idea that what matters is if it's in ROM or if it can be updated is the most bizarre boundary that I can imagine.It's a perfectly sensible boundary. Indeed, it's perhaps the only reasonable boundary you can draw if you wish to make a distinction between software and hardware. Otherwise they blur into each other. If your goal is to afford users/owners the same level of control over modifications as the designer (as it was for the FSF), then this is a logical boundary to draw. If you have other goals could you draw other boundaries (e.g. "I want to change all code running on the main CPU", "I want to be able to verify all code able to access main RAM")? Sure, as you have done. However, to argue this invalidates the boundary others have chosen only demonstrates you've ignored why they chose that boundary.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 7:17 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the designer doesn't have the ability to force you to run an updated program, or to plug in a offline update process. so the designer doesn't have as much control as you make them out to have
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 7:40 UTC (Thu) by smurf (subscriber, #17840) [Link]
Frankly I don't care why the FSF has chosen that boundary.
The point is that this policy prevents opening up existing devices – either by the original manufacturer or by somebody else. So to me this makes no sense whatsoever.
If a philosophical argument, well-intentioned or not, results in less freedom, it is wrong. Plain and simple.
Raspberry Pi VideoCore driver code released Posted Oct 27, 2012 9:24 UTC (Sat) by paulj (subscriber, #341) [Link]
How exactly?
Raspberry Pi VideoCore driver code released Posted Oct 27, 2012 10:56 UTC (Sat) by smurf (subscriber, #17840) [Link]
That should be obvious.
Today I need to buy a device with closed-source firmware. It's available with the binary either as a BLOB, or on ROM. As the FSF says that only the latter is OK, so I decide to buy that.
Tomorrow the manufacturer finds a bug and releases updated firmware. Oops, mine is on ROM so I'm screwed and can't get the bugfix.
Next month somebody reverse-engineers the firmware and creates a free replacement. Oops, my device has the firmware on ROM so I can't switch.
Next year the manufacturer realizes the game's over, and releases the source code. Oops, my device has the firmware on ROM so I can't use that source code.
Yet the FSF says that firmware-on-ROM is OK while firmware-as-BLOB is not.
Raspberry Pi VideoCore driver code released Posted Oct 27, 2012 22:13 UTC (Sat) by paulj (subscriber, #341) [Link]
That's an interesting dichotomy. However, it will never exist. If a hardware vendor produces a board without a ROM, with drivers that have to download a blob to bootstrap that hardware, then why would they ever release a hardware WITH that blob on ROM? That hardware would be more expensive.
We could go into the economics of downloaded v fixed firmware. The former will be quicker to market, the latter will need higher quality engineering to avoid the expense of returns and so perhaps less buggy compared to the former. etc. The burned-in firmware will have had to have had to be developed in a more rigorous manner, with more QA. Potentially, it will have had to have been designed with more attention paid to the architecture (simpler/cleaner), with more complex functionality left to the host software. So there are side-effects besides freedom - the competing products will *not* be equal on quality / price.
In the field of networking, there are the more simple, functional network adapters and there are the more complex ones that require significant amounts of firmware. In ethernet, the complex firmware ones are things like the TCP/IP offload cards. In wireless, its the difference between cards that do lots of the 802.11 logical functionality onboard, and ones that are more like radio modems with logical 802.11 functionality left to the host. The more simple devices are ultimately more flexible, precisely because more of the software is implemented in the OS than by the hardware vendor.
Anyway.. A line had to be drawn somewhere (RMS can be quite pragmatic). The freedom to modify was a line. There may be other lines, and they have different trade-offs.
Personally, I'll hold my nose and supply firmware blobs to hardware that really needs it. However, the more that hardware is like a general purpose computing device and the more it's expected to be updated regularly, the less I like it, and the more I'll try avoid those products. The more a blob looks like something that needs ongoing software engineering, the more I want the software engineers concerned to be the Linux kernel developers. Unfortunately, that's perhaps too amorphous to draw a clear line between.
Raspberry Pi VideoCore driver code released Posted Oct 28, 2012 3:41 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
> why would they ever release a hardware WITH that blob on ROM?
because the FSF will say that their device is Free if they do so, but won't if they don't.
for some segment of users, this is significant, and manufacturers aiming for such users (which most don't) would like to make their buyers happy.
The Raspberry Pi team mentioned the possibility of making a version that had the firmware in ROM, specifically to satisfy such users.
Raspberry Pi VideoCore driver code released Posted Oct 28, 2012 16:23 UTC (Sun) by khim (subscriber, #9252) [Link] To claim that this idiocy can never exist is just wrong. It was discussed quite recently. And since noone of sane mind will ever think of designing something specifically for the FSF-lovers what you get is obsolete and crippled stuff with firmware which is not updateable not because it's so perfect that you never need to update it but because team which designed said hardware is disbanded and no longer creates new versions. Is it really what you want to endorse? As I've already said: FSF approach leads to the "solution" which is not only more expensive, but also less hackable! FSF's preferred "solution" is always, always, ALWAYS worse from the hackability POV!
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 5:35 UTC (Thu) by kevinm (guest, #69913) [Link]
The driver is everything that runs on the CPU that runs your kernel and applications - so yes, they have open-sourced the video driver. That's the most plain reading of the term "video driver".
On top of that it's perfectly legitimate to say "the interface exposed by the closed-source firmware is very high level, so this release doesn't let improvements to the OpenGL/ES implementation be made.". But calling it a "lie" is twisting words beyond their breaking point.
Obviously it would be nice to have the firmware source and toolchain as well, but it doesn't look (to me) like they've implemented the GL functionality off-CPU as end-run around open-sourcing the code that runs on the CPU, but rather for engineering reasons (offloading work from the underpowered CPU).
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 11:44 UTC (Thu) by Jan_Zerebecki (guest, #70319) [Link]
The lie is that they claim that they released their OpenGL ES (and more other APIs) implementation and the the Linux kernel parts under a BSD and/or GPL licence (my summary). If they said they released the shim which calls to those implementations which runs on another processor and which isn't in that release I wouldn't call them liars, but only applaud their step towards more free software.
To verify my summary look at the image in their post: http://www.raspberrypi.org/wp-content/uploads/2012/10/Arc...
In the comments the lie goes from omission to denying the truth: http://www.raspberrypi.org/archives/2221#comment-34981
I like that they released the shim. I don't like being lied to and I don't understand why they would do that in this case. What do they have to gain from this?
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 13:35 UTC (Thu) by edt (subscriber, #842) [Link]
I look at this a little differently. What this release should allow us to do is rebuild the module for any Linux version. Which means, unless other drivers hold the kernel back, a using an up to date linux should be possible. This is a good thing.
As Dave Arlie pointed out the real problem will occur when we find problems with the firmware. We still need to depend on the vendor to fix these.
All in all it is a baby step forward.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 19:45 UTC (Thu) by swetland (subscriber, #63414) [Link]
The thing that has me scratching my head is the approach of absolute rejection of incremental moves in the right direction that many people seem to embrace.
I certainly agree that full open source code for everything top to bottom is a great ideal, but in absence of that, a solution that involves no closed source in the userspace or kernel side is nicer than a solution with a big closed source userspace library blob but an open kernel driver handling resources/queueing, which is nicer than a solution with an entirely closed user + kernel library/driver stack, etc.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 21:48 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
I haven't seen much "absolute rejection". More so what I have seen is people who think this has been misrepresented as better than it is.
They are entitled, indeed in my opinion, right to say that.
Consider the 1832 Representation of the People Act (the "Great Reform act"). This fixed some of the very worst things about British parliamentary elections in the 19th century. It was heralded by its supporters as a triumph for democracy. But it was by no means a complete solution to every problem at that time. For example the franchise was still withheld from most of the poor and all women, and in the absence of even today's poor excuse for a secret ballot many voters were bribed or intimidated.
So, I think that any person who said at the time "This so-called Great Reform act is not so very great after all" would be quite right, and it would be mistaken to say that they were engaged in "rejection" of the act, they're just pointing out that it doesn't go nearly far enough.
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 23:55 UTC (Thu) by Jan_Zerebecki (guest, #70319) [Link]
Yes. IMHO because the actual OpenGL driver is not free software and thus not easily fixable it is important that it is not accepted in mainline Linux if only for strategic reasons.
I found this post by David Airlie http://airlied.livejournal.com/76383.html and quote part of it: "Will this mean the broadcom kernel driver will get merged? No."
Raspberry Pi VideoCore driver code released Posted Oct 26, 2012 0:44 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
the good news is that he is not the one who makes that decision, Linus is. and as noted elsewhere in this thread, Alan Cox doesn't see a problem with merging this.
Raspberry Pi VideoCore driver code released Posted Oct 26, 2012 10:07 UTC (Fri) by smurf (subscriber, #17840) [Link]
I always thought fundamentalism belongs in the realm of Religion, not Kernel Programming.
Silly me.
|
|||||||||||||
