Raspberry Pi VideoCore driver code released
Posted Oct 24, 2012 15:22 UTC (Wed) by swetland (guest, #63414)
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.
Posted Oct 24, 2012 16:00 UTC (Wed) by arnd (subscriber, #8866)
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?
Posted Oct 24, 2012 21:15 UTC (Wed) by swetland (guest, #63414)
Posted Oct 24, 2012 23:30 UTC (Wed) by pabs (subscriber, #43278)
Posted Oct 24, 2012 15:32 UTC (Wed) by tialaramex (subscriber, #21167)
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.
Posted Oct 24, 2012 15:48 UTC (Wed) by njwhite (guest, #51848)
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.
Posted Oct 24, 2012 17:19 UTC (Wed) by robert_s (subscriber, #42402)
Would wayland ever run on it? (not that you should peg me as a wayland fanboy, it's just serving as a good example)
Posted Oct 24, 2012 17:21 UTC (Wed) by robert_s (subscriber, #42402)
Posted Oct 25, 2012 7:58 UTC (Thu) by ebassi (subscriber, #54855)
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).
Posted Oct 25, 2012 8:10 UTC (Thu) by dlang (subscriber, #313)
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.
Posted Oct 25, 2012 8:20 UTC (Thu) by swetland (guest, #63414)
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.
Posted Oct 25, 2012 11:09 UTC (Thu) by endecotp (guest, #36428)
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.
Posted Oct 28, 2012 16:52 UTC (Sun) by JanC_ (guest, #34940)
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.
Posted Oct 24, 2012 17:32 UTC (Wed) by daniels (subscriber, #16193)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds