In which case this article should be retracted. The developers have spoken!
Announcement
Collapse
No announcement yet.
Raspberry Pi Gets Fully Open-Source Graphics Stack
Collapse
X
-
Originally posted by glisse View PostThey 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.
"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
Comment
-
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.
Comment
-
Not open enough
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.
Comment
-
Originally posted by M?P?F View PostHey, 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
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...
Comment
-
Originally posted by glisse View PostYes 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...
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)?
Comment
-
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.
Comment
-
hollow marketing, rude supporters
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.
Comment
-
Originally posted by notzed View PostOk 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.
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.
Comment
Comment