Raspberry Pi GPU Goes Open Source! $10,000 Bounty For Quake 3

raspberrypi_logo

One of the thorns in the side of the Raspberry Pi crowd has been the closed source GPU. Today that all changes. [Eben Upton] reports that Broadcom is opening the source to the VideoCore® IV 3D graphics subsystem. In Broadcom’s own words:

The VideoCore driver stack, which includes a complete standards-compliant compiler for the OpenGL® ES Shading Language, is provided under a 3-clause BSD license; the source release is accompanied by complete register-level documentation for the graphics engine

Full documentation is available on Broadcom’s support site. To celebrate this, The Raspberry Pi Foundation is offering $10,000 to the first person to run Quake III at a playable frame rate on Raspberry Pi with open source drivers. The competition is worldwide. Full rules available here.

This release doesn’t cover everything, as there are still parts of the Pi’s BCM2835 which are hiding behind the blob files. However, it is a very big step for open source. Congrats to the Raspberry Pi Team, and good luck to all the entrants.

48 thoughts on “Raspberry Pi GPU Goes Open Source! $10,000 Bounty For Quake 3

    1. Bad news is that I don’t think they’ve released the toolchain required to actually build this code, so until someone develops a compatible assembler and C compiler for VideoCore IV it’ll be of limited use. Also, they don’t appear to have released any architecture documentation on the VPU, which is the custom-designed processor core within the VideoCore IV that most of the released code runs on. (The released documentation is for the QPU and graphics rendering hardware and only mentions the VPU in passing.) Basically, we’ve got a bunch of code for a processor that we don’t even know the instruction set of except through reverse-engineering, let alone have a working compiler or assember for.

      At a guess, the part that’s going to be most useful in the short term is the QPU documentation (roughly the equivalent of shaders on a desktop GPU), which will probably help with running QPU-accelerated compute code through the existing binary driver blob. In the long term someone will probably manage to write a compiler and make use of this code; there’s already been a fair amount of reverse engineering work on VideoCore IV.

      1. Ah, Eben’s commented elsewhere and corrected me on this. Apparently the code originally ran on the VPU (and appears to roughly correspond to the binary blob that runs on the VPU on the Pi), but it’s been ported to the ARM core on the BCM21553 since that SoC doesn’t actually have a VPU. There’s just a huge amount of dead VPU-specific code that’s still referenced. (Still not sure exactly how this fits with the Pi, where currently the VPU blob has control of the GPU and is required to boot everything. I guess the promised barebones replacement for the VPU code will help.)

    1. That’s how the electronics economics function. You charge a bit over the production cost but in the meantime the part prices go down, yield improves by new processes, you are able to negotiate better deals because of established reputation and provider competition.
      I would guess the PIs should have come down in price at least 15-20% or at least upgrade them constantly, but it’s fine if they put the extra money into useful projects. At least it is greener ( no moral obsolition) and moves the community forward instead of going the megapixel path.

  1. Can somebody explain how big of a deal opening a blob like this is? What’s at stake for Broadcomm? I mean my RPi functions quite well with the blob… not that I think it’s a bad idea, I just want to understand exactly how much I should be celebrating.

    1. Accelerated graphics drivers for Linux are now a possibility – which means the heavy lifting will be done by the vid core rather than the CPU, as is the case now. Also there is now scope to get web based video playing within linux at a reasonable frame rate. Oh, and games just became a lot more interesting on the Pi…
      Anyone will be able to write / tweak new or custom graphics drivers, which should bring up some interesting results. Perhaps even the ability to harness the GPU for other tasks (number crunching, distributed projects, Bit-Coin mining, etc).

      In other words, it will make the pi faster and more useable in general.

      1. no no and nooo
        “Accelerated graphics drivers for Linux” is something pee shipped with, I dont really know what you mean by “web based video playing within linux”, but openmax also works on pee just fine now. So do games.
        also lol for bitcoin mining

        The only thing this enables is an OPEN source driver, it _might_ be better than the closed sourced one, and it _might_ enable new uses, but not the ones you listed (as they are possible right now)

        1. People just see the popular OSes, there are other OSes out there more than Windows and Linux and opening the documentation for a graphics core etc enables also them to make use of the hardware rather then just sitting with some vesa mode .. wake up and smell the coffee, alternative OSes have been around since the dawn of time but propertiery driver blobs has hindered many to shine with more recent hardware =)

        2. Except that, when running the Pi as a desktop computer, the user is limited to unaccelerated X. Now, an accelerated X driver will be a real possibility, making the Pi more useful in that scenario. It also, as others have mentioned, will possibly allow using the GPU for more than just graphics.

          (BTW, I’m not sure why you’re saying “pee” unless you’re trying to be cute or trying to troll for angry retorts.)

        3. rasz_pl – I sense by your comment that you neither like / use or possibly own a Raspberry Pi board. Or “pee” board in your case…

          Oh, and as for the “lol for bitcoin mining”, I think you will find a SNES being used for bitcoin mining, right here on Hackaday. Not very practical either, so then “Why?” – for the LOLs of course. Doesn’t have to be practical to make it fun to do.

          Anyway, I think I’ve done enough “feeding the troll” here for now. Back to the topic at hand.

    2. Updates, improvements, new stuff.

      Example, I have a PC with an Radeon 9600SE. Which still has issues with the open-source driver (3D graphics random hang). I know the binary blob drivers from ATI (now AMD) did not has this problem, however, they do not support any recent kernel version.

      1. Your Radeon is one of hundreds of video card chipsets for general purpose computers, and is over 10 years old at that; at this point it’s mostly an abandoned project. The Raspberry Pi has a very dedicated following, and has only been out for a couple of years, with freshly open-sourced video drivers. The community will be all over this, and will likely find tons of innovative uses for the newly released info. At the very least, we’ll probably see accelerated X, as well as custom, task-specific drivers. I bet we’ll even see vastly improved performance in projects like Raspbmc and game emulators.

        1. Forgot to mention, I do feel your pain regarding the old Radeon card. I’ve got a 9600 Pro in a retro gaming rig; no more Windows driver updates means broken games remain broken. No more GNU/Linux driver updates means it doesn’t run well on that platform either. But I use it specifically for a few old Windows games anyway, so I’m fine with that.

        2. Accelerated X? Does anyone even need that? Everything of note that actually uses X is handing pre-rendered pixmaps to the server… Yeah, sure, if you care about Xeyes being a tad faster, then you may wish for X acceleration…

          1. If you’ve ever used a Linux desktop interface on a standard PC with accelerated drivers, then used Lxde on the Raspberry Pi with the current unaccelerated framebuffer, you’d notice a huge difference. Dragging windows, redraw, everything is slow to the point of being a pain to use. Even the aforementioned 10 year old video cards can do better.

      1. Already possible – search around on HaD and Google, some kind French chap did it for us and I made a quadcopter camera stabilistion system primarily using OpenCV.

    1. HA! got me thinking though… does this mean anything interesting for the composite output? It’s just a DAC good for a few MHz, right? Could make for a pretty capable function / arbitrary waveform generator.

    1. THIS is a (first) good question under this news :)
      This could potentially enable access to MIPI DSI port. There are SHITTONS of cheap/big/with good resolution mipi screens on fleabay (for cellphones) that are just waiting for a platform that can draw on them. So far the only project that can use them that I know of is Mikeselectricstuff hack for Ipod nano screens.

      so far It doesnt appear to be this way tho :(((
      http://www.raspberrypi.org/archives/6299#comment-493964

      1. This might help, but I don’t think it’ll do as much as you’re hoping. I spent a long tme researching MIPI-DSI as I had a couple of project ideas that would have needed access to “retina display” smartphone displays from a system like the Raspberry PI. As far as I was ever able to find, the problem isn’t in not having access to the GPU code. The problem is in not having drivers for the specific display.

        As far as I understand it, the MIPI standards aren’t really complete standards like something like HDMI or DVI. They specify the basic electronics and signaling but don’t hold the manufacturers to maintain compatibility in tings like plug shape or timing. Each individual display requires a driver that defines the unique timing information of that specific panel and that info, as far as I know, is closely guarded trade secrets that you can’t get unless you are allowed to sign an NDA.

        Basically, it was set up as a closed industry big-wig club from the start. The manufacturer’s have never wanted users to have the freedom to mix and match displays between smartphones or to use something like the iPhone display in their own personal project.

        1. its a LOT better than the old rgb/lvds screens. MIPI screens act same way SPI screens do, only layer 0 is different
          mipi is a data connection to lcd buffer, and not a connection to row/column drivers like in the case of LVDS lcd screens of the past
          MIPI has a set of clearly standard instructions (initialize, start of frame, end of frame, etc). Screens can have non standard ‘acceleration’ instructions just like SPI screens (memory fill, copy, shift etc).

      1. To be honest I hope they are working on a revision. It certainly would’t hurt to switch to a more recent arm core (possibly add more than 1 core), up the Mhz and increase the RAM. While they are at it, integrate a Wifi and ethernet chip in there as well to reduce the component count.

        1. Seeing as they dropped out of cellphone market this is something of a pipe dream. Lowest spec Chinese parts are more advanced, faster and more integrated than anything Broadcom has to offer, at a fraction of a price.
          They had a foothold with Nokia using videocore, but that came and went. Maybe if they released datasheets and sources back then people would take them seriously.
          Now they are relegated to TV/appliance market, and even there Chinese/Koreans are winning.

          1. I was referring to Raspberry Pi foundation, rather than broadcom. I appreciate that the project was helped along by Broadcom employees (and I imagine the company in some respects). But the foundation doesn’t have any overwhelming ties with Broadcom and could jump ship if necessary. I would love to see an FPGA version either to co-habit the board or built into the SoC fabric…. Now I’ll admit that I’ve probably moved into fantasy land. But you have to start the ball rolling somewhere.

          2. Broadcom helped out the foundation a heck of a lot and have been helpful at most steps along the path the foundation has taken, including the release of the videocore.

            @rasz_pl, China might be producing some better chips, then again, so does samsung….. but that’s not the point of the pi is it?

          3. I think releasing documentation and going opensource is a great thing for the community and helps extend the product life. I really couldn’t expect the same for new products but I hope other manufacturers will take notes from this for their older products.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.