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