Announcement

Collapse
No announcement yet.

Broadcom Open-Sources VideoCore IV 3D Graphics Stack

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

  • Broadcom Open-Sources VideoCore IV 3D Graphics Stack

    Phoronix: Broadcom Open-Sources VideoCore IV 3D Graphics Stack

    In celebrating two years that Raspberry Pi has been around, Eben Upton has announced today that they are open-sourcing their OpenGL ES 1.1/2.0 graphics stack for the Broadcom VideoCore IV 3D graphics subsystem and it will help the Raspberry Pi with having a truly free graphics stack...

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

  • #2
    wow, this is pretty amazing. It is a shame this is an old slow gpu though. If broadcom released a competitive videocore v with support for decoding vp9/h265, opencl etc then it would be more useful but it is good news for raspberry pi owners.

    Comment


    • #3
      Great news!

      Now, getting a Raspberry Pi is actually worth it

      Comment


      • #4
        Originally posted by sandy8925 View Post
        Now, getting a Raspberry Pi is actually worth it
        There is some analysis here.
        http://www.freelists.org/post/raspi-...ook-QPU-docs,1

        The docs seem very useful but there are some licensing issue and some gaps as well.

        Nevertheless, it is very good news for RPi owners.

        Comment


        • #5
          This is fantastic news, indeed!

          In particular, as it comes quite unexpected.

          Comment


          • #6
            Its amazing how messy the code seems after being used to looking at Mesa's.

            Something interesting a stumbled across was this in the glsl compiler

            /*
            detect uses of reserved keywords (anything from the list, or anything containing '__')
            */

            if ((type >= ASM && type <= USING) || (type == IDENTIFIER && strstr(data.s, "__")))
            glsl_compile_error(ERROR_LEXER_PARSER, 3, g_LineNumber, NULL);

            This is the same issue that was affecting Metro running on Mesa that was fixed recently. Looks like there are others who are abiding by the more strict definition.

            Comment


            • #7
              DSI displays finally usable?

              BTW, does that mean we can eventually make use of the DSI port (for LCD displays)?
              AFAIK this was not possible so far as each DSI display needs a dedicated bit of driver code.

              Comment


              • #8
                Originally posted by tarceri View Post
                Its amazing how messy the code seems after being used to looking at Mesa's.

                Something interesting a stumbled across was this in the glsl compiler

                /*
                detect uses of reserved keywords (anything from the list, or anything containing '__')
                */

                if ((type >= ASM && type <= USING) || (type == IDENTIFIER && strstr(data.s, "__")))
                glsl_compile_error(ERROR_LEXER_PARSER, 3, g_LineNumber, NULL);

                This is the same issue that was affecting Metro running on Mesa that was fixed recently. Looks like there are others who are abiding by the more strict definition.
                As always, thanks for your work on Mesa Timothy! Looking forward to your next crowd funding

                On another note, is someone able to evaluate already if these docs would facilitate the creation of a Gallium3D driver for VideoCore?

                Comment


                • #9
                  Broadcom saw the light. Now the question is is it the train.

                  Comment


                  • #10
                    Originally posted by curaga View Post
                    Broadcom saw the light. Now the question is is it the train.
                    Broadcom releasing the source code of something is more like "seeing the pretty lights of the community's BFG", they always get flamed around for doing it wrong...

                    Comment

                    Working...
                    X