Mesa Does A Bit More Of OpenGL 4

[phoronix]

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

[popper]

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

[DanL]

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

[schmidtbag]

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.

[blackiwid]

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

[Hamish Wilson]

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?

[Plombo]

"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:

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.

[bridgman]

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.