If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

No it isn't, not even close.
ADRENO (it is no coincidence that it's name is made with the exact same letters that spell RADEON) is the best and most free at the moment. Why? Because a HUGE chunk of AMD documentation applies to it. Do you know why that is? Its because Adreno 200 is... an AMD Z430.

Freedreno is being written, at least to some extent, with the assistance of the AMD hardware documentation.

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?

It looks like you can use /dev/mem to modify the GPU's assigned memory, so I'm guessing the GPU can write to CPU-assigned memory as well. You have to trust that the firmware won't do anything undesirable.

It looks like you can use /dev/mem to modify the GPU's assigned memory,

*If* you can really access all GPU memory (including the GPU code) from ARM, then it is just asking to be reverse engineered. But VideoCore has one more MMU for mapping ARM physical addresses onto system bus addresses as explained in http://www.raspberrypi.org/wp-conten...eripherals.pdf

so I'm guessing the GPU can write to CPU-assigned memory as well. You have to trust that the firmware won't do anything undesirable.

There is a difference between doing something undesirable accidentally or intentionally. *If* VideoCore MMU has any means of protecting ARM memory from accidental accesses by GPU, then I guess this configuration is likely to be enabled.

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.

"As of right now, all of the VideoCore driver code which runs on the ARM is available under a FOSS license (3-Clause BSD to be precise). The source is available from our new userland repository on GitHub. If you’re not familiar with the status of open source drivers on ARM SoCs this announcement may not seem like such a big deal, but it does actually mean that the BCM2835 used in the Raspberry Pi is the first ARM-based multimedia SoC with fully-functional, vendor-provided (as opposed to partial, reverse engineered) fully open-source drivers, and that Broadcom is the first vendor to open their mobile GPU drivers up in this way."

(the second paragraph of "Open Source ARM Userland")

Michael just didn't check it and hurriedly published that "news" here.

Yeah, its a crap and epic fail for Raspberry Pi and Broadcom. They are liars! I was thinking about buying Raspberry Pi, but now I'll never ever want to. Let's see what Samsung (maybe with the help of Google) will propose us with their Exynos 5.

"Turns out to be crap"? It's more like it turned out to be exactly what the foundation said instead of being the unicorn people want to believe in. If you actually read and understand the announcement, it becomes quite clear what to expect from the source release. The vast majority of tech sites got it wrong.

Seriously, guys. Just because it's less than you want and expected, this is still quite useful, and a step in the right direction.

Why would students need fast GUIs and to run Ubuntu in order to learn the ARM/Assembly programming that the RPi is intended for?

Why would students need a Raspberry Pi, when they can just use their laptop or a normal computer in school lab?
Why would they need a Raspberry Pi when they can use any Gumstix, Arduino, OMAP, Snapdragon, Allwinner, O-DROIDX, etc system-on-a-chip?

It's not like Raspberry Pi is the only soc, there are lots of other competition.