This has been tested with both OpenGL and OpenGL ES on Android.
We can't use dlsym on Android to get all the function pointers since Android's libGLES* libraries are just shim libraries that pass everything through
to the real vendor specific libraries.
Due to this we must grab function pointers entirely through eglGetProcAddress instead of dlsym.
For performance, I want to be able to make single-context (well,
single-pixel-format-and-device) apps be able to directly call GL
functions through function pointers. Bake that into the ABI now so I
can get a release out the door and fix this up later.
This also fixes the lack of __stdcall annotation on the
PFNWHATEVERPROC typedefs.
This lets the compiler generate faster function calls (call through
function pointer, instead of call into a linker-generated stub func
containing jump to function pointer).
In addition to the failing testcase, there were a couple of
regressions in piglit's attribs test: one from glBegin_unwrapped vs
glBegin confusion in the __asm__ directives we were generating, and
one where the function pointers apparently were just getting mixed up
at application runtime.
This is going to change for macos and win32, and this will be easier
than trying to spread that logic through the python code and into the
generated code.
The dlopen bits are left in place, but the functions required the
types, and in the case of EGL, the types require that the platform
header actually exists.
This totally replaces the getprocaddress and dlsym code, which was
basically just stubs up until now. The is_glx/is_egl() is also
dropped -- they weren't doing anything, and the only false answer they
could give is if the dlopen were to fail.
I was thinking at one point that part of the build was going to
require not including the #defines from the generated code, but would
want these prototypes. It turns out that's not the case (and if it
is, I'll just wrap the #defines in an ifdef).
Unfortunately, for GLX 1.4+ entrypoints (just glxGetProcAddress
currently) or extensions, if there isn't a context bound then we don't
have a dpy and screen available to provide useful debug messages. Oh
well.
Ryan Houdek
Eric Anholt