Raspberry Pi GPU Driver Turns Out To Be Crap

[phoronix]

Phoronix: Raspberry Pi GPU Driver Turns Out To Be Crap

While it looked hopeful at first with today's announcement of a fully open-source graphics stack for the Broadcom VideoCore found in the popular Raspberry Pi development board, upon closer examination it's actually not that good...

http://www.phoronix.com/vr.php?view=MTIxNDk

[ssvb]

It may be below somebody's expectations, but this is still the best what we have for ARM hardware at the moment. That's a major progress already. Let's see.

Are there kernel blobs causing big pain upgrading kernels or causing hard to debug stability issues? - No
Are there userland blobs which cause serious problems when changing ABI (softfp/hardfp) or implementing window system integration? - No

And David Airlie is IMHO overreacting. Judging by his logic, we must kick the IDE/SATA and SD/MMC code out of the kernel in order to force the vendors to provide the compilers targeting their internal controllers and the firmware sources. Otherwise we have no control over fixing the issues like this: http://www.theinquirer.net/inquirer/...drives-failing
As for SD/MMC cards, here is also some information: http://www.linux-mtd.infradead.org/d...l#L_raw_vs_ftl

Basically almost everyone is already using some hardware components driven by some sort of closed source firmware. Suddenly ganging on Raspberry Pi GPU is a bit hypocritical. I'm more worried about the memory sharing between GPU and CPU and whether the GPU is potentially able to cause memory corruption or stability issues. This would be very interesting to clarify.

[portets43]

Well said ssvb.

Another thing to mention is this code drop will directly help a lot of people. Many people were having trouble porting other OS's to the pi, that should (mostly) be gone now. RiscOS will now be ported, and the Android people said they will now be able to port Android 4.0/4.1 WITH graphics acceleration.

And to top it off, it will now make it easier for Simon to develop his X acceleration driver, which will make the Raspberry Pi's desktop much smoother and a bit faster. Not only that, but it will also allow hexxeh(Chrome browser and ChromeOS developer) to get hardware accel working there too. Which means Chrome browser will be way faster, and finally support HTML5 video(youtube) AND WebGL!

[airlied]

It may be below somebody's expectations, but this is still the best what we have for ARM hardware at the moment. That's a major progress already. Let's see.

Are there kernel blobs causing big pain upgrading kernels or causing hard to debug stability issues? - No
Are there userland blobs which cause serious problems when changing ABI (softfp/hardfp) or implementing window system integration? - No

And David Airlie is IMHO overreacting. Judging by his logic, we must kick the IDE/SATA and SD/MMC code out of the kernel in order to force the vendors to provide the compilers targeting their internal controllers and the firmware sources. Otherwise we have no control over fixing the issues like this: http://www.theinquirer.net/inquirer/...drives-failing
As for SD/MMC cards, here is also some information: http://www.linux-mtd.infradead.org/d...l#L_raw_vs_ftl

Basically almost everyone is already using some hardware components driven by some sort of closed source firmware. Suddenly ganging on Raspberry Pi GPU is a bit hypocritical. I'm more worried about the memory sharing between GPU and CPU and whether the GPU is potentially able to cause memory corruption or stability issues. This would be very interesting to clarify.

keep striving for mediocre then. I'm being pragmatic about things, at some point when you make an OS you have to ask can you support this for someone who can't. I don't strive to be RMS, I generally just strive to make sure anything that users get from the kernel or distro is something that can be supported.

This isn't useful in that if someone finds major rendering issues in their GL games, it can't be fixed by anyone except broadcom, why the hell would I want to inflict that on a bunch of users?

I don't have black/white view of firmware, but if the firmware/software divide is firmly on the firmware side, its a bad design decision for Linux to care about it. Manufacturers can continue doing what they want, but its of no benefit to the Linux ecosystem.

Dave.

[bnolsen]

The rpi being ancient armv6 doesn't help it much atall. Movement is very slow on the mali front, otherwise the allwinner a10 and the cubieboard would be gaining very quick public momentum. Time isn't friendly to any of these socs as they are getting rapidly outpaced by multi core cortex a9s.

[ssam]

it is still progress. also its seems to be the openest arm graphics chipset. its also nice to see movement coming from broadcom, who are pretty low in most linux users preferred vendor list due to their wireless cards.

there is no black and white in drivers and firmware. no easy place to draw the line on what needs to or doesn't need to be open to get a seal of approval.
if issue is about having only open code running on your CPU, then this is good progress.
if you want anything that can be modified to be open (RMS rules), then this makes no difference until the firmware is open (unless you burn the firmware to a ROM to make it 'hardware').
if its about ability to fix bugs, this probably makes life better, but does not solve everything. (what about hardware bugs?)

i'd love to see arm chips with an epiphany as the GPU. you could just run llvmpipe on it and everyone would be happy. (apart from the folk who want to see the asic verilog)

[airlied]

it is still progress. also its seems to be the openest arm graphics chipset. its also nice to see movement coming from broadcom, who are pretty low in most linux users preferred vendor list due to their wireless cards.

there is no black and white in drivers and firmware. no easy place to draw the line on what needs to or doesn't need to be open to get a seal of approval.
if issue is about having only open code running on your CPU, then this is good progress.
if you want anything that can be modified to be open (RMS rules), then this makes no difference until the firmware is open (unless you burn the firmware to a ROM to make it 'hardware').
if its about ability to fix bugs, this probably makes life better, but does not solve everything. (what about hardware bugs?)

i'd love to see arm chips with an epiphany as the GPU. you could just run llvmpipe on it and everyone would be happy. (apart from the folk who want to see the asic verilog)

Its certainly the most API/ABI friendly one, but really its not worthy of a major press release claiming some sort of new found openness. The whole thing was done to make a big press splash and watch people fall for it. Broadcom haven't opened anything that wouldn't have taken more than a few hours for someone to develop. Its a shim, yes its technically more open, but still a long way from something I would ever want to ship or support.

The thing is in x86 land, your CPU is a separate device, what if I had a quad-core ARM with the kernel one two cores and the secret GPU on the other two, blurring the line a lot more. Yes its blurry, but the answer generally lies in whats supportable and workable, and IMNSHO this is on the wrong side.

Dave.

[ssvb]

The thing is in x86 land, your CPU is a separate device, what if I had a quad-core ARM with the kernel one two cores and the secret GPU on the other two, blurring the line a lot more. Yes its blurry, but the answer generally lies in whats supportable and workable, and IMNSHO this is on the wrong side.

If the memory is shared between these cores then it's clearly a hell. But if there is a clear separation between system memory and video memory (enforced by a relatively simple MMU setup or by some sort of hardware firewall) and GPU can't corrupt system memory when it crashes or misbehaves, then we don't care much about the GPU firmware crashing in its own sandbox. The question is about the robustness of this whole setup, and I'm curious to learn more details.

Do we have a list of confirmed reports about Raspberry Pi GPU issues?

[ssvb]

Its certainly the most API/ABI friendly one, but really its not worthy of a major press release claiming some sort of new found openness. The whole thing was done to make a big press splash and watch people fall for it. Broadcom haven't opened anything that wouldn't have taken more than a few hours for someone to develop. Its a shim, yes its technically more open, but still a long way from something I would ever want to ship or support.

The thing is in x86 land, your CPU is a separate device, what if I had a quad-core ARM with the kernel one two cores and the secret GPU on the other two, blurring the line a lot more. Yes its blurry, but the answer generally lies in whats supportable and workable, and IMNSHO this is on the wrong side.

And to extend your analogy further, if you mean that this "secret GPU" is actually a userspace code running on a separate CPU core in a separate process, then I would definitely prefer it over loading some fishy proprietary dynamic library into my own process directly. Just because the separate process can't easily take down my own program and can be restarted in the case if it crashes.

Which also reminds me the design decisions made for an early NTFS read/write implementation (captive), see http://www.jankratochvil.net/project...doc/Details.pm Surely in the long run it was replaced by a better ntfs3g implementation. But it did serve as a stopgap placeholder solution. If you try to think out of the box, then the world is not just black and white anymore.

[uid313]

Is the Raspberry Pi overhyped?
Is it any more open than any other system-on-a-chip computer?

Seems just like any other proprietary hardware.

It's ARMv6 without floating-point and cant even run Ubuntu.
I've seen it run XMBC and while video playback works, the GUI is sluggish.

I look forward to ARMv7 (and ARMv8) system-on-a-chip computers.