Announcement

Collapse
No announcement yet.

An OpenGL Optimization Extension Merged Into Mesa

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

  • An OpenGL Optimization Extension Merged Into Mesa

    Phoronix: An OpenGL Optimization Extension Merged Into Mesa

    Yesterday Mesa received support for a new OpenGL extension and after that another useful OpenGL 4.2 extension was added to Mesa and implemented within the Intel OpenGL Linux driver. This latest extension can be used for a driver performance optimization...

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

  • #2
    Funny article. The extension has actually been supported by all Gallium drivers for a very long time, but AFAIK most drivers ignore the shader output modifiers the extension provides.

    Comment


    • #3
      Nice

      There's an interesting link that shows progress related to OpenGL features for Mesa, for more curious people:
      http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt

      Comment


      • #4
        Originally posted by marek View Post
        Funny article. The extension has actually been supported by all Gallium drivers for a very long time, but AFAIK most drivers ignore the shader output modifiers the extension provides.
        So are you saying that even though it's been implemented for awhile must drivers don't take advantage of, what sounds to me to be analogous to early z cull but in this case it also looks to see if the fragment shader intends to alter depth relations and if it doesn't the resource is culled? Why wouldn't all drivers take advantage of that asap?

        Comment


        • #5
          Originally posted by rudregues View Post
          There's an interesting link that shows progress related to OpenGL features for Mesa, for more curious people:
          http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt
          Thanks, I was just thinking about trying to find that info. Kinda depressing how many 'not started's there are, but great work by the team, keep it up.

          Comment


          • #6
            Originally posted by marek View Post
            Funny article. The extension has actually been supported by all Gallium drivers for a very long time, but AFAIK most drivers ignore the shader output modifiers the extension provides.
            Yeah, I was going to say...the core support for this has been around since 2011. It looks like i965 is the first to actually take advantage of it, though, which is surprising.

            I did a quick read through the code, and it looks like everything is hooked up in st, but no drivers use TGSI_FS_DEPTH_LAYOUT_*.
            Free Software Developer .:. Mesa and Xorg
            Opinions expressed in these forum posts are my own.

            Comment


            • #7
              Hope in the end of November

              Originally posted by beaverusiv View Post
              Thanks, I was just thinking about trying to find that info. Kinda depressing how many 'not started's there are, but great work by the team, keep it up.
              Well, we are very close to Mesa 10.0 and it's OpenGL 3.2 and OpenGL 3.3 support. Expected to come before December: http://www.phoronix.com/scan.php?pag...tem&px=MTQ2OTU
              Then, they will be working just on OpenGL 4.0, 4.1, 4.2, 4.3 and 4.4.
              Last edited by rudregues; 10-06-2013, 05:26 PM. Reason: bad english :P

              Comment


              • #8
                Is Phoronix going to have an article every time a new OpenGL extension gets added?

                Comment


                • #9
                  Originally posted by liam View Post
                  Why wouldn't all drivers take advantage of that asap?
                  It's useful for not having to disable both HiZ/ZCULL's early pass AND early fail, but since ZCULL doesn't make much of a difference in the first place (at least for now) I don't particularly care. Last time I checked NV blob ignores this, too.

                  Comment


                  • #10
                    Originally posted by DanL View Post
                    Is Phoronix going to have an article every time a new OpenGL extension gets added?
                    Why not?

                    ... (10 chars) ...

                    Comment


                    • #11
                      The one thing I've never understood though is that all of these work is done completely out of order. It doesn't make sense to get a bunch or parts in 4.x working before 4.0 is working so that you can actually make good use of the spec.

                      Comment


                      • #12
                        Originally posted by Kivada View Post
                        The one thing I've never understood though is that all of these work is done completely out of order. It doesn't make sense to get a bunch or parts in 4.x working before 4.0 is working so that you can actually make good use of the spec.

                        why doesn't it? some apps can use extensions without the functionality level increase, though in some places the GLSL version increase is really important in others not so much.

                        Also some developers aren't up to the commitment to the full time task of doing something like geometry or tessellation shaders but have the spare time to add other smaller pieces of functionality and leave the bigger pieces to the full time devs.

                        Like I've no bandwidth to work on GL4.0 features, but I like to tinker around the edges and look at adding small extensions.

                        Intel have plans to get to GL4, but they can't control what independent devs work on anyways, you seem unfamiliar with open source.

                        Dave.

                        Comment


                        • #13
                          Some of the weird ordering is due to needs - if some program needs a specific feature, we'll do that first. The extension mechanism allows us to expose everything one piece at a time anyway.

                          Other parts of 4.x get done quickly because they're small and simple, while the remaining GL 3.x features are large and difficult. Lots of people can jump in and implement a simple 4.x extension, but not everybody is up for writing a full geometry shader implementation.
                          Free Software Developer .:. Mesa and Xorg
                          Opinions expressed in these forum posts are my own.

                          Comment


                          • #14
                            Originally posted by Kayden View Post
                            Some of the weird ordering is due to needs - if some program needs a specific feature, we'll do that first. The extension mechanism allows us to expose everything one piece at a time anyway.

                            Other parts of 4.x get done quickly because they're small and simple, while the remaining GL 3.x features are large and difficult. Lots of people can jump in and implement a simple 4.x extension, but not everybody is up for writing a full geometry shader implementation.
                            As an example for this, how trivial would it be to add the GL_ARB_clear_texture extension within the current codebase?

                            Comment


                            • #15
                              Not trivial, but also not horrendous.

                              Comment

                              Working...
                              X