User: Password:
|
|
Subscribe / Log in / New account

Raspberry Pi VideoCore driver code released

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 15:15 UTC (Wed) by cthart (guest, #4457)
In reply to: Raspberry Pi VideoCore driver code released by swetland
Parent article: Raspberry Pi VideoCore driver code released

I don't understand how this is any different to a video card in which the firmware is effectively burned into the silicon rather than being a binary blob downloaded (uploaded?) at boot time.


(Log in to post comments)

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 15:22 UTC (Wed) by swetland (guest, #63414) [Link]

For PC GPU cards and for the majority of SoC GPUs, there is significant software that runs on the host CPU to transform OpenGL (or DirectX) command/data streams into whatever native formats the GPU understands, shader compilers, etc.

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.

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 16:00 UTC (Wed) by arnd (subscriber, #8866) [Link]

I only briefly looked at the source code, but I can confirm that the shader compiler, like almost anything else, is indeed just called via RPC into the VideoCore.

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?

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 21:15 UTC (Wed) by swetland (guest, #63414) [Link]

Nope -- every other GPU implementation I've seen thus far requires the shader compiler and even the general translation from OpenGLES API to native formats and command queues to happen on the host side. Including a full general purpose processor in the GPU block is unique to Broadcom to the best of my knowledge (though it is similar to how a lot of codec blocks work -- a pretty powerful, relatively general purpose cpu or dsp combined with dedicated hw accel units for heavy lifting).

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 23:30 UTC (Wed) by pabs (subscriber, #43278) [Link]

The best thing about giant marketing stunts is that they can be used as blunt objects to beat other vendors with :D

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 15:32 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

Well, it depends.

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.

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 15:48 UTC (Wed) by njwhite (guest, #51848) [Link]

Thanks for this clear explanation; it's very useful for somebody like me who doesn't know a great deal about how video drivers / firmwares work.

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.

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 17:19 UTC (Wed) by robert_s (subscriber, #42402) [Link]

I also don't quite get what level of control this gives us over the graphics. i.e. will an RPi using this be able to do all the clever things DRI2 drivers can do?

Would wayland ever run on it? (not that you should peg me as a wayland fanboy, it's just serving as a good example)

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 17:21 UTC (Wed) by robert_s (subscriber, #42402) [Link]

Ah I just RTFA in full which says wayland should be possible.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 7:58 UTC (Thu) by ebassi (subscriber, #54855) [Link]

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).

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 8:10 UTC (Thu) by dlang (subscriber, #313) [Link]

> 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).

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.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 8:20 UTC (Thu) by swetland (guest, #63414) [Link]

The big question I always ask about these designs is "can the peripheral processor access arbitrary memory"... if so, then you need to worry about bugs in the fw blob possibly splattering something you care about... on a number of the more modern ARM SoCs, the peripherals sit behind IOMMUs, so the kernel has final say in what exactly the fw can interact with. Not sure how things work in this particular BCM SoC.

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.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 11:09 UTC (Thu) by endecotp (guest, #36428) [Link]

> The big question I always ask about these designs is "can the
> peripheral processor access arbitrary memory"
> Not sure how things work in this particular BCM SoC.

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.

Raspberry Pi VideoCore driver code released

Posted Oct 28, 2012 16:52 UTC (Sun) by JanC_ (guest, #34940) [Link]

Which makes the ARM that you can run linux on a coprocessor that now can do callbacks to the main processor...

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.

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 17:32 UTC (Wed) by daniels (subscriber, #16193) [Link]

Actually, Pekka (one of the other Collaborans) already has Wayland/Weston running on RPi, albeit only for software-rendered clients. We should have more on that shortly. :)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds