Raspberry Pi Gets Fully Open-Source Graphics Stack

[cb88]

In which case this article should be retracted. The developers have spoken!

[MùPùF]

They did not release the driver, there is absolutely no driver code in what they released. It's just header and some egl/glx glue code. Things that have been public for ages.

Hey, I would you like to point to you a comment from one of the guy that seems to be from the raspbery pi foundation in response to Luc Verhaegen:

"We happen to have a GPU which exposes a comparatively high level (GL-like) interface, such that many of our userland functions are message passing shims. You are dealing with a GPU which exposes a lower-level interface, so LIMA driver functions often boil down to writing registers directly. These are design decisions on the part of the respective GPU teams, which have wide-ranging implications for the software and hardware structure of the devices which use the resulting cores. The VideoCore driver isn’t structured this way to pull the wool over your eyes, it’s structured this way because of a genuine judgment that this is the best structure given the resources we have on the chip, which includes a vector DSP to which we can offload much of the low-level register access."

Source: http://www.raspberrypi.org/archives/2221

[cb88]

The same could be said of a Voodoo graphics card.. the API is similar to Glide/OpenGL etc.. however there is still an acutal software <-> hardware driver whereas this is a software <-> software interface entirely it seems. Calling that a driver is a strech.

[uid313]

Still it is not nearly open enough.

How is the Raspberry Pi anymore open than Gumstix, Samsung Exynos, TI OMAP, Qualcomm Snapdragon, ODROID-X, PandaBoard, BeagleBoard, etc?

I don't see any open source PCB, flowcharts, schemata, registers, pinouts, etc.

Raspberry Pi is just another proprietary hardware soc.

[glisse]

Hey, I would you like to point to you a comment from one of the guy that seems to be from the raspbery pi foundation in response to Luc Verhaegen:

"We happen to have a GPU which exposes a comparatively high level (GL-like) interface, such that many of our userland functions are message passing shims. You are dealing with a GPU which exposes a lower-level interface, so LIMA driver functions often boil down to writing registers directly. These are design decisions on the part of the respective GPU teams, which have wide-ranging implications for the software and hardware structure of the devices which use the resulting cores. The VideoCore driver isn’t structured this way to pull the wool over your eyes, it’s structured this way because of a genuine judgment that this is the best structure given the resources we have on the chip, which includes a vector DSP to which we can offload much of the low-level register access."

Source: http://www.raspberrypi.org/archives/2221

Yes i saw that. My view and Luc view and i would bet the view of any one doing open source GPU driver, is that an open source driver for this GPU would include the source to the firmware. Firmware in other GPU are way smaller and don't do much. For instance on AMD or NVidia the firmware is mostly an helper to write/read register without involving the CPU in the process. While in this case the firmware is responsible for thing like compiling shader, converting high level api to low level register write. So the true driver is the firmware. No one will be able to improve the driver of this GPU without an open source firmware. While on AMD/NVidia one can improve the open source driver without ever touching the firmware code.

For instance you can't do shader optimization or even have some clever shader binary caching functionality, i am guessing here that the firmware do a lot of useless work like rebuilding shader more often than necessary when it runs out of shader binary cache memory...

[curaga]

Yep, just like Glide, that big blob will have bugs. Michael, a followup with Luc's comments?

[MùPùF]

Yes i saw that. My view and Luc view and i would bet the view of any one doing open source GPU driver, is that an open source driver for this GPU would include the source to the firmware. Firmware in other GPU are way smaller and don't do much. For instance on AMD or NVidia the firmware is mostly an helper to write/read register without involving the CPU in the process. While in this case the firmware is responsible for thing like compiling shader, converting high level api to low level register write. So the true driver is the firmware. No one will be able to improve the driver of this GPU without an open source firmware. While on AMD/NVidia one can improve the open source driver without ever touching the firmware code.

For instance you can't do shader optimization or even have some clever shader binary caching functionality, i am guessing here that the firmware do a lot of useless work like rebuilding shader more often than necessary when it runs out of shader binary cache memory...

Don't get me wrong, I think this is as closed as it can be from a dev point of view. Not being able to drive the actual GPU but actually send such high-level commands is not something desirable from a developper point of view (and is pretty much equivalent to a closed driver).

However, from a user point of view, it is now possible to build our own kernels or port the RaspPi to *BSD and I think this was the main objective behind this move.

Now, the real question is, when will someone actually reverse-engineer what is actually executed on the side-processor (the one that actually compiles the shaders and pokes the regs)?

[oliver]

I was so excited when I first saw this, but found out, that as mentioned here, it's only a shim.

What they basically did, is have the entire 'driver' in the firmware, and expose the calls via VideoCore.

This videocore -> chip 'driver' has now be opensourced, which .... is still useless.

[notzed]

Ok so you can now build your own kernel (fancy that, i thought that was a gpl requirement anyway), but this is what they claimed in the blog post:

"first ARM-based multimedia SoC with fully-functional, vendor-provided (as opposed to partial, reverse engineered) fully open-source drivers"

Now clearly this is completely bunk. It isn't fully functional (e.g. video decode) nor 'open source'.

The actual driver is still just a blob - just like OMAP or A10 or all the other ARM SOCs (at least TI provide a compiler for their DSP). They even state that it is still not 'FSF endorsable' in the comments. What's more laughable is that they're considering creating a new product where the firmware is burned on the board and not replaceable - as a cheat workaround to gain 'FSF endorsablity'.

They are also aggressively rude to the qualified people pointing out the hollowness of their claims. Somehow claiming that because the GPU's CPU isn't just the main ARM chip, you've no business expecting to be able to programme it. Particularly very offensive to the lad working on the lima driver.

[droidhacker]

Ok so you can now build your own kernel (fancy that, i thought that was a gpl requirement anyway), but this is what they claimed in the blog post:

"first ARM-based multimedia SoC with fully-functional, vendor-provided (as opposed to partial, reverse engineered) fully open-source drivers"

Now clearly this is completely bunk. It isn't fully functional (e.g. video decode) nor 'open source'.

The actual driver is still just a blob - just like OMAP or A10 or all the other ARM SOCs (at least TI provide a compiler for their DSP). They even state that it is still not 'FSF endorsable' in the comments. What's more laughable is that they're considering creating a new product where the firmware is burned on the board and not replaceable - as a cheat workaround to gain 'FSF endorsablity'.

They are also aggressively rude to the qualified people pointing out the hollowness of their claims. Somehow claiming that because the GPU's CPU isn't just the main ARM chip, you've no business expecting to be able to programme it. Particularly very offensive to the lad working on the lima driver.

Yeah, I'm not at all impressed with them on this, and am in fact starting to regret the $35 I handed over to them. If I'd known that they would be dealing with it like this, I'd rather pay more elsewhere for a more powerful piece of hardware and support that is at least consistent with established standards.

Although I dislike the blob, I would accept it if it was properly advertised as such rather than having them try to cover it up. The fact that the GPU is programmable via firmware is absolutely a reason why I DO expect to be able to program it -- especially when the device is advertised as the open sourcer's dream. Just like every other GPU out there. I don't care that its not part of the main ARM core, it is still programmable.

Now what I really take exception to, is that vile woman "liz" they have handling PR. I have a feeling that she has no idea about the equipment itself. The "engineer" (probably her husband, I'm guessing) made some statements and she ran with it, made an ass of the whole [basement] "organization", now all defensive and hostile when called out on the carpet over making false statements, and trying to back them up with nonsense.

I really prefer honesty to this bull.