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

[Kenneth Graunke]

On 12/11/2012 11:04 AM, Ian Romanick wrote:
> On 12/10/2012 04:06 PM, Jordan Justen 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?
>
> Having API_OPENGL_LAST and the STATIC_ASSERT should be sufficient.
>
>> 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.
>
> The problem is that we have a zillion places that check of GLES2.  I
> don't want to have to find and update all of those to check for separate
> GLES2 and GLES3.  Every single place that checks for GLES2 would have to
> be updated.

Where "zillion" means 50 (measured by git grep API_OPENGLES2 | wc -l). 
In contrast, there are 72 occurrances of API_OPENGLES3.

I'm not taking a position one way or another, just saying that 50 isn't 
that much work.

--Ken