[Mesa-dev] [PATCH 0/2] RFC: Refactor handling of extension strings

Chad Versace chad.versace at intel.com
Sun Jan 9 23:23:08 PST 2011

I am refactoring the method by which extension strings are handled in
mesa/main/extensions.c. If there are no objections, regressions, nor
significantly better refactoring alternatives proposed, then I plan to push
the patch set on Friday 14.

The patch set causes no Piglit regressions on Intel Ironlake.

I would appreciate it if someone would take the time check for Piglit
regressions on non-Intel. Also, if anyone has access to a GLES1/2 test suite,
I would like to know if this causes any GLES1/2 regressions.

Patch 1/2
This patch is large and sprawling, so it deserves a detailed explantion.

These are the problems that this patch solves:
1. The names of GLES1 and GLES2 extensions did not exist in any data structure.
2. As a result of problem 1, the extension strings for GLES1 and GLES2
   contexts were constructed in a messy procedural fashion, rather than in
   a delcarative, table-driven approach.
3. As a result of problem 2, it was impossible to query the status of or
   enable/disable a GLES extension by name.

The solution this patch implements is to place all extensions -- GL, GLES1,
and GLES2 -- in a unified extension table. The elements of the table have this
   { extension name, byte offset, set of api's in which extension is enabled }
For example,
   { "GL_OES_read_format", o(OES_read_format),          GL | ES1       },
   { "GL_OES_mapbuffer",   o(ARB_vertex_buffer_object),      ES1 | ES2 },

Patch 2/2
According to a discussion I had with Ian Romanick, Mesa does not actually
support some of the extensions advertised in the GLES1 and GLES2 extension
strings. This patch removes those extensions.

More information about the mesa-dev mailing list