airlied (airlied) wrote,
2012-10-25 06:51:00

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: http://www.raspberrypi.org/archives/2221#comment-34981
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?
No.

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

    Error

    switch
    default userpic

    Your reply will be screened

    Help
  • 23 comments

saist

October 24 2012, 21:11:17 UTC 6 months ago

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?

airlied

October 24 2012, 21:53:42 UTC 6 months ago

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

October 25 2012, 07:16:58 UTC 6 months ago

Phoronix quoted you but they left your last sentance out : http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDk

Really laughable !

adamwill.id.fedoraproject.org

October 24 2012, 22:29:38 UTC 6 months 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.

https://lists.fedoraproject.org/pipermail/devel/2012-October/172995.html

adamwill.id.fedoraproject.org

October 26 2012, 01:48:47 UTC 6 months ago

just as a follow-up, turns out those changes are about different firmware, firmware for the platform itself, which doesn't have these concerns.

mefcon1

October 24 2012, 23:09:27 UTC 6 months ago

That's a shame about the Broadcom code. However, I think you're being unnecessarily harsh in your criticism of Phoronix.

Anonymous

October 25 2012, 11:52:07 UTC 6 months ago

I don't think he's bashing Phoronix, but rather the original announcement here: http://www.raspberrypi.org/archives/2221

Anonymous

October 25 2012, 19:24:49 UTC 6 months ago

Lol, harsh on Phoronix? Michael rarely if ever spends the 5min to dig deeper on a story. He barely does tabloid level research for most of his articles, in fact I'd say he does less work than most tabloid writers. This is just another prime example of his sensationalist money grubbing ways.

mefcon1

October 26 2012, 06:20:27 UTC 6 months ago

Sure, Larabel was a bit quick to post this and got caught out. But, he posted a follow-up pretty quickly. I don't think he deserves this kind of criticism considering the rather significant contribution he's made to the community around desktop Linux and Linux gaming.
AFAIK, he's one guy that's built Phoronix from nothing. He maintains the site, trawls the Internet mailing lists and blogs for content, talks to dev teams, organises conferences, attends conferences (travelling to do that), tries out new code, maintains and develops the Phoronix Test Suite, and runs performance comparison test after comparison test (just even setting up the hardware and OSes is a lot of work). I hope that he also still manages to have a life beyond all that work.
Therefore, it should come as no shock that he may not have the time to throroughly research every article that he chooses to publish. So, again, on balance, I do not think that he deserves such harsh criticism.

ForestBond

October 25 2012, 00:20:05 UTC 6 months 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?

Anonymous

October 25 2012, 15:18:14 UTC 6 months 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

Anonymous

October 26 2012, 04:51:40 UTC 6 months ago

That's also my question. It seems fine for the kernel to use SATA to talk to my laptop's disk, USB UVC to talk with my laptop's camera, etc. Why is OpenGL/ES so bad a protocol for communicating with a graphics core that it is Dave's view that code to support that should be excluded from the stock kernel?

It would be good to have the source code or the specifications for the graphics core, without a doubt. Just as it would be good to have the code from disk controllers, UVC cameras and the wear levelling code from USB flash memory storage.

But the kernel folk didn't prevent me from buying dud disks, poor webcams, unreliable USB flash, or even hardware RAID cards. I assume because it was my role as the purchaser to weight up the pros and cons of what I do with my money. I don't think I've ever seen a commit rejected because "it's a poor long-run buy", which seems to be at the heart of Dave's argument.

airlied

October 26 2012, 05:19:41 UTC 6 months ago

OpenGLES is a high level application interface, it is not and never was designed as a hw level interface. Its not a hw level interface and its not secure enough to be used as one. I'd block it entering the kernel under a number of different reasons in no useful order:

a) unknown security context - what can the GPU do, can I buffer overflow it into doing something bad to the main system RAM?

b) unknown attack surface - how much of the RPC interface do we not know about?

c) doesn't use any of the current Linux interfaces, there is no drm/kms drivers, there is no Mesa or DRI driver. You'd have to replace userspace libs with one built from their sources along with the kernel driver.

CSRedRat

October 25 2012, 07:43:43 UTC 6 months ago

When driver was open?

Anonymous

October 25 2012, 13:51:12 UTC 6 months ago

Between you and Greg KH's complaint about the Raspberry Pi USB driver ( http://lists.infradead.org/pipermail/linux-rpi-kernel/2012-September/000214.html ) 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.

makomk

October 26 2012, 20:32:25 UTC 6 months ago

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.

Wes Felter

October 25 2012, 20:40:27 UTC 6 months ago

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.

airlied

October 26 2012, 05:16:25 UTC 6 months ago

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

October 26 2012, 22:14:10 UTC 6 months ago

I admire your ambition. You don't just want to develop Linux, you want to fix all the world's firmware bugs!

Anonymous

October 25 2012, 23:58:27 UTC 6 months ago

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

Anonymous

October 26 2012, 12:16:09 UTC 6 months ago

OpenBSD developers seem to disagree:

http://marc.info/?l=openbsd-misc&m=135109499020826&w=2

Anonymous

October 26 2012, 07:11:12 UTC 6 months 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.

benanov

October 26 2012, 12:30:51 UTC 6 months ago

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.