Results 1 to 8 of 8

Thread: Mesa Does A Bit More Of OpenGL 4

  1. #1
    Join Date
    Jan 2007
    Posts
    14,369

    Default 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...

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

  2. #2
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote 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; 06-18-2012 at 04:46 PM.

  3. #3
    Join Date
    Oct 2007
    Posts
    1,259

    Default

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

  4. #4
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,210

    Default

    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.

  5. #5
    Join Date
    Jul 2008
    Posts
    729

    Default

    Quote 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 ^^?

  6. #6
    Join Date
    Oct 2011
    Location
    Rural Alberta, Canada
    Posts
    1,019

    Default

    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?

  7. #7
    Join Date
    Sep 2010
    Posts
    146

    Default

    Quote 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.

  8. #8
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •