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