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


                    • #11
                      Just for the records, does that mean we can have fully accelerated X11 (quite) soon?

                      Comment


                      • #12
                        It's really great that Broadcom open sourced the code that interfaces with the GPU and the documentation. On the OpenGL ES side, it looks like they included only the RPC wrapper and not the actual driver or shader compiler:

                        Code:
                        brcm_usrlib/dag/vmcsx/interface/khronos/glxx/glxx_client.c:
                        
                        /* OES_shader_source */
                        GL_APICALL void GL_APIENTRY glCompileShader (GLuint shader)
                        {
                        	LOG_FUNC
                           if (IS_OPENGLES_20()) {
                              RPC_CALL1(glCompileShader_impl_20,
                                        GLCOMPILESHADER_ID_20,
                                        RPC_UINT(shader));
                           }
                        }
                        That's a shame, but if the real OpenGL implementation runs on their GPU people couldn't have hacked on it without their GPU toolchain anyway.

                        At least now it's easier to write an open source driver for it. Hopefully someone with a RPi will write a Mesa driver and a compiler backend for QPU!

                        Comment


                        • #13
                          Originally posted by pasaulais View Post
                          It's really great that Broadcom open sourced the code that interfaces with the GPU and the documentation. On the OpenGL ES side, it looks like they included only the RPC wrapper and not the actual driver or shader compiler
                          Its all in there take another look it to a while for me to find it too.

                          Comment


                          • #14
                            Originally posted by Calinou View Post
                            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...
                            This time, it looks like they've done it right, and then some. Both src *and* docs. I didn't look at the src (not terribly interested in that myself), the doc looks actually pretty comprehensive (from a fairly quick flip-thru). Even with an errata section, which is pretty nice when you are working on a driver and the hw isn't doing what you think it should. So kudos for bcm! Let's hope now that the rest of the mobile gpu players are paying attention.

                            Comment


                            • #15
                              Originally posted by robclark View Post
                              This time, it looks like they've done it right, and then some. Both src *and* docs. I didn't look at the src (not terribly interested in that myself), the doc looks actually pretty comprehensive (from a fairly quick flip-thru). Even with an errata section, which is pretty nice when you are working on a driver and the hw isn't doing what you think it should. So kudos for bcm!
                              Wow, hearing this from you makes me even more confident that this is a useful contribution to open-source by Broadcom.
                              About a year ago, I had the opportunity to talk to Pete Lomas from the RPi foundation, and back then he wasn't optimistic
                              freely available programming docs for the GPU will ever happen.

                              Originally posted by robclark View Post
                              Let's hope now that the rest of the mobile gpu players are paying attention.
                              This.

                              Comment

                              Working...
                              X