Announcement

Collapse
No announcement yet.

Mesa Does A Bit More Of OpenGL 4

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

  • Mesa Does A Bit More Of OpenGL 4

    Phoronix: Mesa Does A Bit More Of OpenGL 4

    Patches emerged last week for supporting the GL_ARB_base_instance OpenGL extension within Mesa and Gallium3D's Mesa state tracker. This OpenGL extension was only conceived last year and became part of the specification with OpenGL 4.2...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Originally posted by phoronix View Post
    Phoronix: Mesa Does A Bit More Of OpenGL 4Patches emerged last week for supporting the GL_ARB_base_instance OpenGL extension within Mesa and Gallium3D's Mesa state tracker. This OpenGL extension was only conceived last year and became part of the specification with OpenGL 4.2...http://www.phoronix.com/vr.php?view=MTEyMjI
    "It's too bad though that overall we're still a ways out from seeing OpenGL 4.0/4.1/4.2 compliance in Mesa. Full compliance with OpenGL 3.1 isn't even expected until next year . "

    that's exactly what GSOC etc is for..... so new dev's can come in, look at the spec such as this http://www.opengl.org/registry/specs...e_instance.txt etc, sit down and write a basic C code for each missing function, then optimize it and test for correctness etc write a piglit test for this feature then have a mentor pop it on the Mesa and Gallium3D done list
    Last edited by popper; 18 June 2012, 04:46 PM.

    Comment


    • #3
      Every bit helps, especially when it's done by a dev that doesn't normally work on mesa.

      Comment


      • #4
        i personally think i'd rather have more attention drawn toward better performance rather than adding features. seeing as how most linux 3d programs don't take advantage of ogl4.x, it seems like a pretty low priority to me. even if 3d programs did take advantage of ogl3 or 4, the open source drivers are still too slow. i'm sure there might be something here and there where the open source drivers might actually go faster because of future ogl releases, but i'm sure that'd be minimal.

        Comment


        • #5
          Originally posted by schmidtbag View Post
          i personally think i'd rather have more attention drawn toward better performance rather than adding features. seeing as how most linux 3d programs don't take advantage of ogl4.x, it seems like a pretty low priority to me. even if 3d programs did take advantage of ogl3 or 4, the open source drivers are still too slow. i'm sure there might be something here and there where the open source drivers might actually go faster because of future ogl releases, but i'm sure that'd be minimal.
          Is that really possible through mesa-patches to make that things faster? Isnt that primary a task for the drivers? Or is it more a issue of the gallim3d state trackers ^^?

          Comment


          • #6
            You do know that it does not necessarily follow that a person working on one part of the driver stack can contribute to another, right?

            Comment


            • #7
              Originally posted by popper View Post
              "It's too bad though that overall we're still a ways out from seeing OpenGL 4.0/4.1/4.2 compliance in Mesa. Full compliance with OpenGL 3.1 isn't even expected until next year . "

              OpenGL 3.1 probably won't be in a stable Mesa release until early next year, but it will likely be supported in Mesa git much sooner than that. Take a look at the current completion list for OpenGL 3.1 in Mesa:

              Code:
              GL 3.1:
              
              GLSL 1.40                                             missing: UBOS, inverse(),
                                                                    highp change
              Instanced drawing (GL_ARB_draw_instanced)             DONE (i965, gallium, swrast)
              Buffer copying (GL_ARB_copy_buffer)                   DONE (i965, r300, r600, swrast)
              Primitive restart (GL_NV_primitive_restart)           DONE (i965, r600)
              16 vertex texture image units                         DONE
              Texture buffer objs (GL_ARB_texture_buffer_object)    needs GL3.1 enabling (i965)
              Rectangular textures (GL_ARB_texture_rectangle)       DONE (i965, r300, r600, swrast)
              Uniform buffer objs (GL_ARB_uniform_buffer_object)    not started
              Signed normalized textures (GL_EXT_texture_snorm)     DONE (i965, r300, r600)
              The inverse() GLSL function was added to master a couple of weeks ago, leaving uniform buffers (UBOs) the only major unfinished thing in GL 3.1. Work has actually started on those as well.

              Comment


              • #8
                Originally posted by blackiwid View Post
                Is that really possible through mesa-patches to make that things faster? Isnt that primary a task for the drivers? Or is it more a issue of the gallim3d state trackers ^^?
                Mesa *is* the 3D driver, and it is also the first of the Gallium3D state trackers.
                Test signature

                Comment

                Working...
                X