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

[Matt Turner]

On Mon, Dec 10, 2012 at 4:06 PM, Jordan Justen <jljusten at gmail.com> wrote:
> 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?

The order of elements in api_enum in get_hash_generator.py is the
order of the per-API hash tables in table_set[].

> 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.

I like this idea.