5 ms·

Raspberry Pi GPU Driver Turns Out To Be a Shim

115 points by ari_elle 14y ago

bryanlarsen 14y ago
It's cool that phoronix linked and quoted Dave Airlie. It's too bad they didn't quote or respond to the last line of his blog post: "(and really phoronix, you suck even more than usual at journalism)"
- mikestew 14y ago
  For me, the not-one-but-two "tip for a tiny belly" ads gave it away before I even got to Airlie's post. Right or wrong, those types of ads prejudice me against a site before I even get to the content. In this case the content did little to change my judgement.
  - dfc 14y ago
    As far as the linux graphics stack goes, its hard to find someone with more experience than arlied. I think you may have misjudged the author.
andyjohnson0 14y ago
Describing the driver as crap seems a bit harsh when the problem appears to be that the driver doesn't open-up as much gpu functionality as the author hoped. Perhaps a better title for the article would be "Raspberry Pi GPU Driver Not As Open As I Would Like".
- wladimir 14y ago
  It seems that Phoronix is going to new depths here in sensationalizing titles. They don't mention any reason why it would be crap as a driver. Reasons it'd be 'crap' is if it is much slower than the binary one, or buggy, or lacks features. But that's not the case is it? Even if it is not as open as people would like, I suppose it does give some information (like the entry points) that can be useful in "full" reverse engineering...
  - fusiongyro 14y ago
    I thought the article was pretty clear about this. The open source driver is just pipelining commands and data from the OS to the firmware blob. The open source driver isn't doing any work, it's just proxying to the firmware which is doing all the work. The situation is isomorphic to a closed source driver.
    - noselasd 14y ago
      Note that the "binary blob" is not executing within the linux kernel or the arm core at all, it's running on the videocore, a mostly undocumented piece of a black box. At some level this is the case for all hardware. Take a ordinary ethernet nic. Back in the days it was a piece of silicon on a PCB and some glue to get the data onto the CPU and main memory. Such a chip is treated as just hardware, a black box in which we can poke at some registers, get some interrupts a shuffle data back & forth. Now, inside that black box of a NIC is a whole world in itself. The act of framing and deframing ethernet with all the details around it is actually quite complicated, the spec. even for 100mbit ethernet is orders of magnitude bigger than e.g. the spec of TCP/IP. There's a lot of stuff happening inside that NIC - and there's parts that break. (e.g. as shown in some parts of this rather hilarius piece: https://www.youtube.com/watch?v=8Q8EFwKVKdA https://www.youtube.com/watch?v=8Q8EFwKVKdA). Now - as NICs got even more complicated, and supported even more stuff, checksum offloading, more buffering, SSL offloading and many other things, parts of many NICs today have a lot of the functionality implemented in FPGAs. Which we some times doen't see, and in other cases have to upload a binary blob to before it can be activated. The difference is now that the pre-made chip on our NICs can change, with software, after it's been shipped from the factory. This is increasingly common for many types of hardware, in this case for an OpenGL core, though perhaps even a level up from FPGAs. But we can still treat it as a black box, through which we just send commands, poke at registers and so on. Now - I'm not saying such stuff shouldn't be open source - it would be awesome if it were, it'd allow us to fix and extend them. I'm just saying that what's done with the "shim" for the videocore on the raspberry is a common approach to interfacing with peripherals - the main difference is the black box have to be programmed after it has left the factory.
      - 14y ago
jws 14y ago
Wanted a flying pony. Got a pony. An open userspace means that I will be able to use the GPU as far into the future as I like. It means that if anything is screwed up on my ARM processor I can see it and fix it (or thank the person that beat me to it.) That's a good thing. The code blob that is not open is what runs on the GPU. I'd love to have that too so that the OpenGL could possibly be extended beyond what the vendor chooses or it could be ditched as a GPU entirely and used as a big parallel DSP. BroadCom didn't give us that. Some reasons I can think of: • GPU litigation – If you don't have a pre-emptive patent arsenal, open sourcing your GPU code and design is like inviting your competitors' lawyers over for tea and depositions. • Unbuildable – The toolchain to build the GPU code is likely a cobbled together mess of tools, many built to minimally functional in house standards. • Undocumented – They probably have not spent the hundreds of thousands of dollars to properly document how the GPU works. What documentation exists is possibly not in English. • Unsafe – It is possible that the GPU has HCF[1] opcodes or sequences, or at the very least hasn't been lightly proven not to. In particular, there could be thermal issues depending how you drive it. • IP Ownership – Portions of their implementation could be licensed under terms that do not permit release. EOM [1] http://en.wikipedia.org/wiki/Halt_and_Catch_Fire http://en.wikipedia.org/wiki/Halt_and_Catch_Fire
- Nursie 14y ago
  A more apt analogy would be "Was old I was getting a pony but got a small plastic model of a mule". Pi made a huge song and dance about this yesterday, nobody can fault their media savvy, but in the end they didn't really release much.
  - jws 14y ago
    I'm still happy. It wanders a bit from topic, but I eventually gave away stacks of Broadcom based WRTSL54GS wifi routers because their closed source driver was stuck at linux 2.4 and I needed 2.6 for some attached hardware. That went on for years. Having everything that runs on the host CPU open means things like this can't happen. Much better than a plastic mule. Even further afield… When my first daughter was 3 or 4 we got her a magic wand for her birthday. A plastic star on the end of a plastic stick. She was thrilled, pointed it at her grandmother and said "I turn you into a bug!". She was crushed when it didn't work. Rather spoiled the whole day for her. She assures us she was going to turn her back.
talmand 14y ago
Every time I read an article like this it seems that the implied consensus is that companies with millions of dollars in yearly revenue are unable to hire good talent when it comes to hardware programming and all the "good" ones are open-source people who may or may not have worked for one of these companies in the past. With all these "this thing is bad" articles it just seems like no hardware company has ever been able to write good drivers and are completely unable to hire the right people to do the job. This is implied in all of the history of electronics. But they also almost always come across as more opinions than facts. Does the Pi GPU driver suck? I don't know because this article says so but doesn't explain why exactly. As someone else pointed out, this article is pointing out that the company simply did not create certain things the way the community wanted. I'm not a hardware programmer so I don't much about such things, but what do these people actually expect out of a piece of hardware that costs around $25-50 US? What exactly are the goals these people want that require the type of access they are asking for? What goals are they failing to achieve that makes them decide the hardware and/or drivers suck? That's all I ask when one of these "this thing is bad" type of article.
- jotux 14y ago
  >I don't know because this article says so but doesn't explain why exactly. I think it's pretty clear. What broadcom released was a binary file and and code to interface with it. It's not that the driver functionality is any different than what's already available it's that all the important functionality is in the binary file that was provided without any source code. They made a big deal about the first open source ARM gpu driver but, for the most part, it's still a black box and it's not really useful to developers looking to change/improve the gpu performance.
  - talmand 14y ago
    I get what you're saying, but that doesn't really say the hardware or its drivers suck. It just tells me that the community doesn't have the access they would like. Complaining that the GPU isn't open is one thing and I totally understand that, saying it sucks is completely different to me. Saying it sucks implies that there is something wrong with the hardware and/or its drivers. It would be similar to claiming that a Macbook Pro sucks because you can't swap the battery yourself. Now, if someone can show where the binary file has a flaw in it so that it could be said to be defective in some way, then sure, let the accusations of suckage begin. Especially if the flaw prevents usage of the device as described and it remains closed so the community cannot fix it. But then if they don't fix it themselves nor allow the community access to fix it then the platform will die anyway. So, back to my comment, I don't understand the point of the article and others like it.
dfc 14y ago
The nut graph from arlied's post[1] (linked to in phoronix article): "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)." Emphasis mine. [1] http://airlied.livejournal.com/76383.html http://airlied.livejournal.com/76383.html
ChuckMcM 14y ago
I find this conversation, and the previous one, instructive. The discussion illustrates the challenge that Linux has accommodating third parties. Two entire classes of software are categorically unable to embrace the 'rules' of open software, the graphics folks and the wireless folks (and to some extent the Printer folks). This has meant that these areas generally had a much poorer to non-existent user experience for Linux users than users of systems with support for IP protection built into them. I think the 'shim' model is certainly one way to compromise here. I think the Raspberry Pi folks have done a great service to developers by helping this get done.

115 points by ari_elle 14y ago

It's cool that phoronix linked and quoted Dave Airlie. It's too bad they didn't quote or respond to the last line of his blog post: "(and really phoronix, you suck even more than usual at journalism)"

mikestew 14y ago
For me, the not-one-but-two "tip for a tiny belly" ads gave it away before I even got to Airlie's post. Right or wrong, those types of ads prejudice me against a site before I even get to the content. In this case the content did little to change my judgement.
- dfc 14y ago
  As far as the linux graphics stack goes, its hard to find someone with more experience than arlied. I think you may have misjudged the author.

andyjohnson0 14y ago

Describing the driver as crap seems a bit harsh when the problem appears to be that the driver doesn't open-up as much gpu functionality as the author hoped. Perhaps a better title for the article would be "Raspberry Pi GPU Driver Not As Open As I Would Like".

wladimir 14y ago
It seems that Phoronix is going to new depths here in sensationalizing titles. They don't mention any reason why it would be crap as a driver. Reasons it'd be 'crap' is if it is much slower than the binary one, or buggy, or lacks features. But that's not the case is it? Even if it is not as open as people would like, I suppose it does give some information (like the entry points) that can be useful in "full" reverse engineering...
- fusiongyro 14y ago
  I thought the article was pretty clear about this. The open source driver is just pipelining commands and data from the OS to the firmware blob. The open source driver isn't doing any work, it's just proxying to the firmware which is doing all the work. The situation is isomorphic to a closed source driver.
  - noselasd 14y ago
    Note that the "binary blob" is not executing within the linux kernel or the arm core at all, it's running on the videocore, a mostly undocumented piece of a black box. At some level this is the case for all hardware. Take a ordinary ethernet nic. Back in the days it was a piece of silicon on a PCB and some glue to get the data onto the CPU and main memory. Such a chip is treated as just hardware, a black box in which we can poke at some registers, get some interrupts a shuffle data back & forth. Now, inside that black box of a NIC is a whole world in itself. The act of framing and deframing ethernet with all the details around it is actually quite complicated, the spec. even for 100mbit ethernet is orders of magnitude bigger than e.g. the spec of TCP/IP. There's a lot of stuff happening inside that NIC - and there's parts that break. (e.g. as shown in some parts of this rather hilarius piece: https://www.youtube.com/watch?v=8Q8EFwKVKdA https://www.youtube.com/watch?v=8Q8EFwKVKdA). Now - as NICs got even more complicated, and supported even more stuff, checksum offloading, more buffering, SSL offloading and many other things, parts of many NICs today have a lot of the functionality implemented in FPGAs. Which we some times doen't see, and in other cases have to upload a binary blob to before it can be activated. The difference is now that the pre-made chip on our NICs can change, with software, after it's been shipped from the factory. This is increasingly common for many types of hardware, in this case for an OpenGL core, though perhaps even a level up from FPGAs. But we can still treat it as a black box, through which we just send commands, poke at registers and so on. Now - I'm not saying such stuff shouldn't be open source - it would be awesome if it were, it'd allow us to fix and extend them. I'm just saying that what's done with the "shim" for the videocore on the raspberry is a common approach to interfacing with peripherals - the main difference is the black box have to be programmed after it has left the factory.
    - 14y ago

jws 14y ago

Wanted a flying pony. Got a pony. An open userspace means that I will be able to use the GPU as far into the future as I like. It means that if anything is screwed up on my ARM processor I can see it and fix it (or thank the person that beat me to it.) That's a good thing. The code blob that is not open is what runs on the GPU. I'd love to have that too so that the OpenGL could possibly be extended beyond what the vendor chooses or it could be ditched as a GPU entirely and used as a big parallel DSP. BroadCom didn't give us that. Some reasons I can think of: • GPU litigation – If you don't have a pre-emptive patent arsenal, open sourcing your GPU code and design is like inviting your competitors' lawyers over for tea and depositions. • Unbuildable – The toolchain to build the GPU code is likely a cobbled together mess of tools, many built to minimally functional in house standards. • Undocumented – They probably have not spent the hundreds of thousands of dollars to properly document how the GPU works. What documentation exists is possibly not in English. • Unsafe – It is possible that the GPU has HCF[1] opcodes or sequences, or at the very least hasn't been lightly proven not to. In particular, there could be thermal issues depending how you drive it. • IP Ownership – Portions of their implementation could be licensed under terms that do not permit release. EOM [1] http://en.wikipedia.org/wiki/Halt_and_Catch_Fire http://en.wikipedia.org/wiki/Halt_and_Catch_Fire

Nursie 14y ago
A more apt analogy would be "Was old I was getting a pony but got a small plastic model of a mule". Pi made a huge song and dance about this yesterday, nobody can fault their media savvy, but in the end they didn't really release much.
- jws 14y ago
  I'm still happy. It wanders a bit from topic, but I eventually gave away stacks of Broadcom based WRTSL54GS wifi routers because their closed source driver was stuck at linux 2.4 and I needed 2.6 for some attached hardware. That went on for years. Having everything that runs on the host CPU open means things like this can't happen. Much better than a plastic mule. Even further afield… When my first daughter was 3 or 4 we got her a magic wand for her birthday. A plastic star on the end of a plastic stick. She was thrilled, pointed it at her grandmother and said "I turn you into a bug!". She was crushed when it didn't work. Rather spoiled the whole day for her. She assures us she was going to turn her back.

talmand 14y ago

Every time I read an article like this it seems that the implied consensus is that companies with millions of dollars in yearly revenue are unable to hire good talent when it comes to hardware programming and all the "good" ones are open-source people who may or may not have worked for one of these companies in the past. With all these "this thing is bad" articles it just seems like no hardware company has ever been able to write good drivers and are completely unable to hire the right people to do the job. This is implied in all of the history of electronics. But they also almost always come across as more opinions than facts. Does the Pi GPU driver suck? I don't know because this article says so but doesn't explain why exactly. As someone else pointed out, this article is pointing out that the company simply did not create certain things the way the community wanted. I'm not a hardware programmer so I don't much about such things, but what do these people actually expect out of a piece of hardware that costs around $25-50 US? What exactly are the goals these people want that require the type of access they are asking for? What goals are they failing to achieve that makes them decide the hardware and/or drivers suck? That's all I ask when one of these "this thing is bad" type of article.

jotux 14y ago
>I don't know because this article says so but doesn't explain why exactly. I think it's pretty clear. What broadcom released was a binary file and and code to interface with it. It's not that the driver functionality is any different than what's already available it's that all the important functionality is in the binary file that was provided without any source code. They made a big deal about the first open source ARM gpu driver but, for the most part, it's still a black box and it's not really useful to developers looking to change/improve the gpu performance.
- talmand 14y ago
  I get what you're saying, but that doesn't really say the hardware or its drivers suck. It just tells me that the community doesn't have the access they would like. Complaining that the GPU isn't open is one thing and I totally understand that, saying it sucks is completely different to me. Saying it sucks implies that there is something wrong with the hardware and/or its drivers. It would be similar to claiming that a Macbook Pro sucks because you can't swap the battery yourself. Now, if someone can show where the binary file has a flaw in it so that it could be said to be defective in some way, then sure, let the accusations of suckage begin. Especially if the flaw prevents usage of the device as described and it remains closed so the community cannot fix it. But then if they don't fix it themselves nor allow the community access to fix it then the platform will die anyway. So, back to my comment, I don't understand the point of the article and others like it.

dfc 14y ago

The nut graph from arlied's post[1] (linked to in phoronix article): "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)." Emphasis mine. [1] http://airlied.livejournal.com/76383.html http://airlied.livejournal.com/76383.html

ChuckMcM 14y ago

I find this conversation, and the previous one, instructive. The discussion illustrates the challenge that Linux has accommodating third parties. Two entire classes of software are categorically unable to embrace the 'rules' of open software, the graphics folks and the wireless folks (and to some extent the Printer folks). This has meant that these areas generally had a much poorer to non-existent user experience for Linux users than users of systems with support for IP protection built into them. I think the 'shim' model is certainly one way to compromise here. I think the Raspberry Pi folks have done a great service to developers by helping this get done.