On 09/08/2012 12:02 AM, Eric Anholt wrote:
Ian Romanick <i...@freedesktop.org> writes:
From: Ian Romanick <ian.d.roman...@intel.com>
NOTE: This is a candidate for the 9.0 branch
GL_ARB_shader_objects and friends are marked as GL not GLL in
extensions.c -- should their functions still be exposed if we're
exposing the extensions?
Oops. Good catch.
/* GL_EXT_gpu_shader4 / GL 3.0 */
- SET_BindFragDataLocationEXT(exec, _mesa_BindFragDataLocation);
- SET_GetFragDataLocationEXT(exec, _mesa_GetFragDataLocation);
+ if (ctx->API != API_OPENGLES2 || _mesa_is_gles3(ctx)) {
+ SET_BindFragDataLocationEXT(exec, _mesa_BindFragDataLocation);
+ }
+ if (ctx->API != API_OPENGLES2 || _mesa_is_gles3(ctx)) {
+ SET_GetFragDataLocationEXT(exec, _mesa_GetFragDataLocation);
+ }
Fold these two ifs together? Also, should the EXTs actually be exposed
on gles3? (seems like just the core versions below should)
The EXT and non-EXT functions go through the same dispatch slot. This
is an area where we have a bug that I don't know how to fix.
eglGetProcAddress will give a valid, working function pointer for
functions in ES2 that are not valid in ES2. That is,
f1 = eglGetProcAddress("glMapBufferOES");
f2 = eglGetProcAddress("glMapBufferARB");
will set f1 and f2 to the same pointer. I believe it will do the same
for desktop GL.
That said, I'm not sure we care.
@@ -1778,8 +1788,10 @@ _mesa_init_shader_dispatch(struct _glapi_table *exec)
SET_ShaderBinary(exec, _mesa_ShaderBinary);
/* GL_ARB_blend_func_extended */
- SET_BindFragDataLocationIndexed(exec, _mesa_BindFragDataLocationIndexed);
- SET_GetFragDataIndex(exec, _mesa_GetFragDataIndex);
+ if (ctx->API != API_OPENGLES2) {
+ SET_BindFragDataLocationIndexed(exec, _mesa_BindFragDataLocationIndexed);
+ SET_GetFragDataIndex(exec, _mesa_GetFragDataIndex);
+ }
#endif /* FEATURE_GL */
}
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
