If you happened to do both GLES2 and GLES1 in a process, it meant that
you'd try to look up v1 procs in the v2 API, and lose. Caught by
piglit oes_fixed_point-attribute-arrays.
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).
For example, on desktop 2.1 GL on Apple, there's no glBindVertexArray,
but there is glBindVertexArrayAPPLE, and as far as a caller is
concerned, the APPLE variant should be able to stand in for the
core/ARB version. Similarly for trying to do FBOs on an old Mesa
implementation that didn't have ARB_fbo yet, but did have EXT_fbo.
When initially writing the Makefiles, I started from a Makefile.am
that had ajax's copyright instead of an Intel one. The only line I
can see that's left from the original Makefile.am is "pkgconfigdir" in
the root Makefile.am.
For a non-GLX application, at least, we need to pull our extensions
using dlsym, not glXGetProcAddress(). The symptom was a segfault in
glXGetProcAddress().
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.
These tell the linker to generate GNU_IFUNC relocs that rewrite the
PLT entries in the user's address space to point to our resolved GL
function, so there's no extra function pointer. It also, as a bonus,
cuts 400k out of the library.
This requires a toolchain from 2010 or so. Unfortunately, it's going
to take a bit more investigation to find out what specific bits are
required.
Fixes#4
We now initialize our dispatch table with function pointers that go
and do the rewrite, then we never have to check for a NULL table entry
again. On my 64-bit build, epoxy_glClear() drops from 83 bytes to 14,
while the total library size only goes up by 5%.
This also paves the way for fixing our dispatch table management using
TLS on windows.
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.
Note that the generated code is still generated, they just aren't
built and installed. The goal with that is that someone could take
the built .c and .h files and drop it into their own project, if they
want to avoid shared libs.
Eric Anholt