On Mon, Dec 10, 2012 at 4:06 PM, Jordan Justen <jljus...@gmail.com> wrote:
> On Mon, Dec 10, 2012 at 2:28 PM, Matt Turner <matts...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
