separate gles1 and gles2 implementations

[Josua-SR]

Greetings,

I have been prototyping a glvnd vendor library for vivante gpus using their binary blobs.
One issue I have come across is that eglGetProcAddress has to know if symbols for OpenGL-ES 1 or OpenGL-ES 2 are required by the application.

I thought of two ways to deal with this:

1. directly inside getProcAddress:
   call the vivante eglQueryContext for EGL_CONTEXT_CLIENT_VERSION
   return symbols from either the vivante gles1 or vivante gles2 library

2. intercept calls to eglMakeCurrent
   call the vivante eglQueryContext for EGL_CONTEXT_CLIENT_VERSION
   call the vivante eglMakeCurrent
   in getProcAddress: look up previously recorded value of EGL_CONTEXT_CLIENT_VERSION

However both of these appear to share a problem:
getProcAddress is called for gl* symbols before the actual call of eglMakeCurrent is dispatched.
sadly getProcAddress can not look into the future.

I believe this case is being hit in src/EGL/libegl.c:eglMakeCurrent

/*
         * We don't have a current context, so we only need to make the new one
         * current.
         */
        ret = InternalMakeCurrentDispatch(newDpy, draw, read, context,
                newVendor);

Do you have any suggestions how this can be achieved?

[kbrenneman]

The functions pointers from eglGetProcAddress are defined by the EGL spec to be context independent. The same function pointers have to be usable regardless of which context is current -- GLES1, GLES2, or desktop GL. In the case of libglvnd, that extends to different vendor libraries as well.

If a vendor library needs to handle GLES1 and GLES2 differently, then one way to do that is to implement a dispatch layer within the vendor library. You can take a look at Mesa for an example of how that works.

[Josua-SR]

I understand, thank you.