RFC/WIP: Retracing without explicitly linking to libGL

[José Fonseca]

On Thu, Dec 1, 2011 at 11:43 PM, Alexandros Frantzis <
alexandros.frantzis at linaro.org> wrote:

> 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.
>

hmm.. this is very confusing. I'll need to read more about EGL ABI.

So, in summary:
- dlsym(dlopen("libGL.so"), XXX) for core GL functions
- dlsym(dlopen("libGLESv1_CM.so"), XXX) for for GLES 1 core functions
- dlsym(dlopen("libGLESv2.so"), XXX) for for GLES 2 core functions
- eglGetProcAddress(XXX) for extensions (any API)

What about the functions which are common to all? e.g., glEnable? can we
pick any of the libGL(ES)*.so libraries or do we need to ensure that they
are only used in the right context?


> 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 :)
>

I'll be offline soon, so feel free to work on a follow on patch.

Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20111202/64cc1c78/attachment.html>