[Mesa-dev] [PATCH 01/13] Add ES 3 handling to get.c and get_hash_generator.py

[Jordan Justen]

On Mon, Dec 10, 2012 at 2:28 PM, Matt Turner <mattst88 at gmail.com> wrote:
> @@ -966,6 +973,15 @@ find_value(const char *func, GLenum pname, void **p, union value *v)
>     int api;
>
>     api = ctx->API;
> +   /* We index into the table_set[] list of per-API hash tables using the API's
> +    * value in the gl_api enum. Since GLES 3 doesn't have an API_OPENGL* enum
> +    * value since it's compatible with GLES2 its entry in table_set[] is at the
> +    * end.
> +    */
> +   STATIC_ASSERT(Elements(table_set) == API_OPENGL_LAST + 2);
> +   if (_mesa_is_gles3(ctx)) {
> +      api = API_OPENGL_LAST + 1;
> +   }

This seems somewhat unexpected. How do we keep track of the fact that
API_OPENGL_LAST + 1 is used for GLES3 in this case?

Are we sure GLES3 isn't a separate API from GLES2? :) I guess I don't
know the motivation for keeping GLES2/3 under a combined API_GLES2
brings. Wasn't there the idea that since GLES3 was backward
compatible, we'd just upgrade GLES2 to add the GLES3 features? But,
now it seems we keep separating them in various ways.

> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 57dddf8..bd180a5 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3335,6 +3335,7 @@ typedef enum
>     API_OPENGLES,
>     API_OPENGLES2,
>     API_OPENGL_CORE,
> +   API_OPENGL_LAST = API_OPENGL_CORE,

We could instead add:
   API_COUNT

Then we wouldn't need to update the API_OPENGL_LAST enum if newer
API's are added.

-Jordan