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

[Brian Paul]

On 01/10/2011 12:23 AM, Chad Versace wrote:
> 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.

This looks great, Chad.  I've was thinking of doing this one day too.

Only minor comments coming...

-Brian