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

[Chia-I Wu]

On Mon, Jan 10, 2011 at 3:23 PM, Chad Versace <chad.versace at intel.com> 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.
Great work.  In patch 1, some for-loops look like

  for (GLboolean *i = base; i != sentinel; ++i)

I think the declarations should be moved to the beginning of the
containing block.
> 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.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



-- 
olv at LunarG.com