On Mon, Jan 10, 2011 at 3:23 PM, Chad Versace <chad.vers...@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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
o...@lunarg.com
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
