RFC/WIP: Retracing without explicitly linking to libGL

[Alexandros Frantzis]

On Thu, Dec 01, 2011 at 09:42:03PM +0000, José Fonseca wrote:
> Hi Alexandros,
> 
> Looks good overall.
> 
> But there's one detail I'd prefer see done differently: it's better not to
> introduce this reverse/cyclic dependency from glproc to glws. glproc should
> be self-sufficient, and the code organized in the following layers:
> 
>   (e)glimports  // type definitions
>    |
>    V
>   glproc        // dynamic binding of the entrypoints
>    |
>    V
>   glws          // window system abstraction
>    |
>    V
>  (e)glretrace   // actual application
> 
> The https://github.com/apitrace/apitrace/tree/glproc-cleanup takes some of
> your changes but obverses the above scheme.  There's more stuff I wanna do
> in glproc, but it's a good step. I've already tested it on
> Linux/MacOSX/Windows, so if it doesn't regress Android for you I'll merge
> it.

The main problem I see, is that __libegl_sym() opens only libEGL.so, so
it can only access egl (not gl) symbols through dlsym(). On Mesa, the
core gl* symbols are actually returned by the call to eglGetProcAddress(),
but this behavior goes against the EGL spec: "eglGetProcAddress may not
be queried for core (non-extension) functions in EGL or client APIs",
and is not supported by strictly conforming drivers. For example, this
fails with the PVR driver for the embedded SGX cores.

Consequently, we need a mechanism, like the one in the
'retrace-no-link-gl-wip' patchset, to select and dlopen() the correct gl
library depending on the current context. Of course, in this case we
don't have access to saved glws state, but we can easily figure out the
current API and version using EGL functions.

If you'd like, I can work on a patch for this. We just need to make sure
we don't both start working on it :)

Thanks,
Alexandros