Page 2 of 7 FirstFirst 1234 ... LastLast
Results 11 to 20 of 63

Thread: Raspberry Pi GPU Driver Turns Out To Be Crap

  1. #11
    Join Date
    Mar 2012
    Posts
    52

    Default

    Imho the only over hype was made by Michael, the rasperry pi site only talks about "open source USERLAND", Michael talks about a misleading "full open source graphic stack"...

  2. #12
    Join Date
    Oct 2009
    Posts
    2,081

    Default

    Quote Originally Posted by ssvb View Post
    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.

  3. #13
    Join Date
    Aug 2008
    Posts
    99

    Default

    Quote Originally Posted by ssvb View Post
    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.

  4. #14
    Join Date
    Jan 2012
    Posts
    111

    Default

    Quote Originally Posted by unix_epoch View Post
    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.

  5. #15
    Join Date
    Jan 2012
    Posts
    111

    Default

    Quote Originally Posted by airlied View Post
    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.

  6. #16
    Join Date
    Jul 2011
    Posts
    44

    Exclamation

    Quote Originally Posted by freedam View Post
    Imho the only over hype was made by Michael, the rasperry pi site only talks about "open source USERLAND", Michael talks about a misleading "full open source graphic stack"...
    Actually, not. Look at http://www.raspberrypi.org/. Quote:

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

  7. #17
    Join Date
    Oct 2012
    Posts
    1

    Default Not that bad

    The opensourced parts enable some new developments: DirectFB, Wayland, other OSes, special Qt release without X ...

  8. #18
    Join Date
    Jul 2011
    Posts
    44

    Angry

    What s f@ck! They erasing comment from www.raspberrypi.org on their "openness". Liars!

    Also they banned my IP to prevent me from commenting. I had to use Tor...

    I've send them another comment and made a screenshot:

    Last edited by dogsleg; 10-25-2012 at 03:30 AM. Reason: added screenshot

  9. #19
    Join Date
    Jan 2010
    Posts
    361

    Default

    "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.
    Last edited by brent; 10-25-2012 at 04:36 AM.

  10. #20
    Join Date
    Dec 2011
    Posts
    2,021

    Default

    Quote Originally Posted by boast View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •