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

[Chad Versace]

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.

Regressions
===========
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
form:
   { 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.