Announcement

Collapse
No announcement yet.

Raspberry Pi Gets Fully Open-Source Graphics Stack

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

  • Raspberry Pi Gets Fully Open-Source Graphics Stack

    Phoronix: Raspberry Pi Gets Fully Open-Source Graphics Stack

    The popular budget-friendly Raspberry Pi ARM development board now has a fully open-source graphics stack -- the user-space graphics drivers for the Broadcom VideoCore included!..

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

  • #2
    What's license?

    Comment


    • #3
      http://en.wikipedia.org/wiki/BSD_lic..._License.22.29

      Comment


      • #4
        This doesn't seem to include the h264 (and others) decoder does it? I quickly greped through the sources and only found references to h264 in header files and structures. I doubt it contains code to access the hardware de-/encoders. Does anyone have a deeper insight into this?

        Comment


        • #5
          Excellent. Broadcom sure has come a long way since their "we have binary-only linux drivers for our clients, but end-users are not our clients so f### off" stance years ago.

          Kudos!
          Last edited by [Knuckles]; 10-24-2012, 08:51 AM. Reason: typo

          Comment


          • #6
            Originally posted by Mathias View Post
            This doesn't seem to include the h264 (and others) decoder does it? I quickly greped through the sources and only found references to h264 in header files and structures. I doubt it contains code to access the hardware de-/encoders. Does anyone have a deeper insight into this?
            I can't imagine them having redesigned the video decoders from the ground up... certainly its virtually the same hardware as crystalhd (aka AMD Xilleon / UVD) - see kernel at drivers/staging/crystalhd/*. Now I don't know if they've made anything to link them up, but it should hopefully be not too much of a struggle to build that connection.

            Comment


            • #7
              In the comments section of the original announcement someone assumed that parts of the codec stuff are contained in the non-open bootloader, ensuring that noone can bypass the licensing fees.

              Comment


              • #8
                Note that this is *not* a proper driver!

                The parts published by Broadcom are very welcome indeed, because you can now have a fullly open source userland. It is not a full driver though: It's only a thin wrapper that forwards the client APIs more or less verbatim to the VideoCore IV by some means of remote procedure call. The actual drivers are all running on the VideoCore itself and are contained in the blob.

                This setup destroys some of Michael's high hopes:

                Their user-space bits unfortunately aren't based around the Mesa/Gallium3D architecture, although it's possible they could now be ported to such a driver
                Would be possible indeed, but would not make much sense: The stack would be "OpenGL -> Gallium3D -> OpenGL(ish) RPC", so there's no need for Gallium3D to be in the equation at all.

                The only bit that's not opened up is the microcode/firmware, which still must be loaded at boot, but still that's nothing different than how the AMD Radeon driver functions along with some other GPUs.
                That would be cool if it was true. But while the blobs in the Radeon and GeForce GPUs indeed just make a small (more or less) auxiliary microcontroller work, this blob here contains the actual driver, so there's no real way to get rid of it.

                Comment


                • #9
                  Meh. This is only an RPC-shim. Not even worth a mention.

                  Comment


                  • #10
                    They 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.

                    Comment


                    • #11
                      In which case this article should be retracted. The developers have spoken!

                      Comment


                      • #12
                        Originally posted by glisse View Post
                        They 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.
                        Hey, 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 isnt structured this way to pull the wool over your eyes, its 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


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


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


                            • #15
                              Originally posted by MPF View Post
                              Hey, 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 isnt structured this way to pull the wool over your eyes, its 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
                              Yes 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...

                              Comment

                              Working...
                              X