airlied (airlied) wrote,

raspberry pi drivers are NOT useful

So I awake to find an announcement that the userspace drivers for the rPI have been released, lots of people cheering, but really what they've released is totally useless to anyone who uses or develops this stuff.

(libv commented on their thread:
maybe he'll follow up with a blog post at some point).

So to start the GLES implementation is on the GPU via a firmware. It provides a high level GLES RPC interface. The newly opened source code just does some marshalling and shoves it over the RPC.

Why is this bad?
You cannot make any improvements to their GLES implementation, you cannot add any new extensions, you can't fix any bugs, you can't do anything with it. You can't write a Mesa/Gallium driver for it. In other words you just can't.

Why is this not like other firmware (AMD/NVIDIA etc)?
The firmware we ship on AMD and nvidia via nouveau isn't directly controlling the GPU shader cores. It mostly does ancillary tasks like power management and CPU offloading. There are some firmwares for video decoding that would start to fall into the same category as this stuff. So if you want to add a new 3D feature to the AMD gpu driver you can just write code to do it, not so with the rPI driver stack.

Will this mean the broadcom kernel driver will get merged?

This is like Ethernet cards with TCP offload, where the full TCP/IP stack is run on the Ethernet card firmware. These cards seem like a good plan until you find bugs in their firmware stack or find out their TCP/IP implementation isn't actually any good. The same problem will occur with this. I would take bets the GLES implementation sucks, because they all do, but the whole point of open sourcing something is to allow other to improve it something that can't be done in this case.

So really Rasberry Pi and Broadcom - get a big FAIL for even bothering to make a press release for this, if they'd just stuck the code out there and gone on with things it would have been fine, nobody would have been any happier, but some idiot thought this crappy shim layer deserved a press release, pointless. (and really phoronix, you suck even more than usual at journalism).

  • Post a new comment


    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
Heh. Yeah, Michael tends to get dinged a lot by the actual coders for tabloiding.

Quick question for you then: what code would be useful for you, or other coders, from Broadcom, and where would interested users start applying pressure to get that code released under an Open-License?
Well it all depends on the architecture of their SoC. If they use the DSP videocore to control another separate 3D core, then it would be better to just allow the separate 3D core to be exposed to the ARM directly. If videocore is a separate block that has no interface except via shared memory to the DSP core, then they'd need to open the videocore firmware or provide enough information to write your own.

But really its like TCP/IP offload or HW raid cards, seem like a good idea, but generally ends up sucking if you want to fix anything. Except in this case its worse since, its like a TCP/IP offload network card you can't directly send packets though or a HW raid card you can't use as an IDE/SCSI controller. (I'm sure these all exist, but they suck just like this).

Maximilien Noal

8 years ago

So, er, if the stuff is so useless, why are we munging the Fedora packaging guidelines so we can include it? Or does this not apply to some of the stuff that's coming out?

This was my only concern with the Fedora 'we'll let firmware in' stance; I think we need to draw a line at some point between the two types of firmware implementations you describe. I don't think Fedora should be letting in firmwares which basically do all the work and are unhackable.
just as a follow-up, turns out those changes are about different firmware, firmware for the platform itself, which doesn't have these concerns.
That's a shame about the Broadcom code. However, I think you're being unnecessarily harsh in your criticism of Phoronix.


October 25 2012, 11:52:07 UTC 8 years ago

I don't think he's bashing Phoronix, but rather the original announcement here:


8 years ago


8 years ago

So I get that the code that was opened up is pretty trivial and the fanfare is thus a bit overblown. And I get that the GLES-in-firmware architecture is less than desirable. But I guess I don't get why it doesn't make sense for the kernel to have a driver that can play with the RPC interface anyway. It's still hardware presenting a usable interface to the kernel. Is it just not possible to expose this to userspace in a useful way?


October 25 2012, 15:18:14 UTC 8 years ago

my point exactly. lets keep presurring broadcom to make their firmware open and for the time being the best we can do is use a driver that interfaces with that firmware. i guess raspian and other distros do that already. the real candy wud have been if every piece of code either firmware/driver used in rpi was freely available to everyone


8 years ago


8 years ago

When driver was open?


October 25 2012, 13:51:12 UTC 8 years ago

Between you and Greg KH's complaint about the Raspberry Pi USB driver ( ) the source of the Raspberry Pi has taken a brow beating. It's a shame as one would have thought a little open would have met a more welcoming audience than completely closed...

It sounds like any move towards open source that isn't 100% needs to be done very quietly to prevent backlash.
In many practical ways, this "a little open" driver is actually more closed off than AMD or NVidia's "completely closed" drivers, though. For instance, both of those allow you to submit your own shaders using a documented IL bytecode format or even as fully-documented native binaries in the case of AMD, which means you can do things that are hard to manage in the shader subset supported by OpenGL/DirectX/OpenCL. That's impossible on Pi - all you can do is submit your OpenGL ES shader code to the GPU and have it compile it for you. AMD and NVidia's closed source drivers also make available more diagnostic and debugging information than you could possibly get out of the "open" Broadcom drivers, as I believe do competing ARM GPU manufacturers.
So how do you feel about FullMAC 802.11, non-Winmodems, and PostScript printers? I thought self-contained hardware with a clear interface and a simple driver was a good thing.
You do know RMS started all of this because of postscript printer firmwares?

you also know that network connected postscript printers are full of bugs and exploits.

Just because someone calls something firmware doesn't mean its not as capable as the operating system you are running on, would you prefer to run Linux in a VM under an embedded Windows OS and have someone tell you the Windows bit is just firmware?

Wes Felter

8 years ago


October 25 2012, 23:58:27 UTC 8 years ago

They are very useful for moving away from Linux and porting to a BSD.


October 26 2012, 12:16:09 UTC 8 years ago

OpenBSD developers seem to disagree:


October 26 2012, 07:11:12 UTC 8 years ago

"interested users start applying pressure to get that code released under an Open-License"

Pressure ? What about joining an effort to produce real open hardware and software instead to "put pressure" on corporations that will eventually get fed up if not upset of such incompetent fan-boy behaviors ? It's easy to reclaim "source openness" of a work you do not live upon wages.

So start your own firm, engage engineers and coders, develop your own hardware and software and throw everything in the wild for people to tear everything down and spit to your face because you forgot to release a last bit of source code and/ or because you dared to leave a bug in your hardware design.

Now that you have your own unfriendly Quran-like little GPLv3 to empowers you over other people's IP you can use to "pressure" your beliefs down coders' throat like a religion, go for it, because you cannot do even 10% of the task they done if you cannot get them to slip down their pants to slap their butts.
All this does is let all free software call the same binary blob the same way. Not super useful, but nice for people trying to run different stuff on the pi. That's all.