Announcement

Collapse
No announcement yet.

Raspberry Pi GPU Driver Turns Out To Be Crap

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Raspberry Pi GPU Driver Turns Out To Be Crap

    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

  • #2
    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.

    Comment


    • #3
      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!

      Comment


      • #4
        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.

        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.

        Comment


        • #5
          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.

          Comment


          • #6
            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)

            Comment


            • #7
              Originally posted by ssam View Post
              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.

              Comment


              • #8
                Overhyped?

                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.

                Comment


                • #9
                  Originally posted by uid313 View Post
                  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.
                  Why would students need fast GUIs and to run Ubuntu in order to learn the ARM/Assembly programming that the RPi is intended for?

                  Comment


                  • #10
                    Originally posted by airlied View Post
                    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?

                    Comment


                    • #11
                      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"...

                      Comment


                      • #12
                        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.

                        Comment


                        • #13
                          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.

                          Comment


                          • #14
                            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.

                            Comment


                            • #15
                              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.

                              Comment

                              Working...
                              X