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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
