RFC/WIP: Retracing without explicitly linking to libGL

[José Fonseca]

On Fri, Dec 2, 2011 at 4:35 AM, Chia-I Wu <olvaffe at gmail.com> wrote:

> On Fri, Dec 2, 2011 at 8:13 AM, José Fonseca <jose.r.fonseca at gmail.com>
> wrote:
> > 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)
> EGL/GLES says nothing about ABI, sadly.  EGL spec only states that:
>
>  eglGetProcAddress may not be queried for core (non-extension) functions in
>   EGL or client APIs.
>
> Yet, it does not define the corresponding versions of client APIs..
> Worse, there are also implementations that eglGetProcAddress is
> somewhat broken.  There are also systems that dlopen cannot be
> overridden.
>
> Currently, __libegl_sym tries dlsym(RTLD_NEXT, ...) and, if that
> fails, then eglGetProcAddress.  It obviously will not work for many
> cases, but it may not be easy to find a way to work reliably across
> OSes/implementations.
> > 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?
> Nothing is said about this case.  Implementations I've seen allow any
> of the libraries to be picked. Function pointers returned by
> eglGetProcAddress are required to work with any context.  But then,
> glEnable cannot be queried with eglGetProcAddress...
> >
> >>
> >> 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
> >
> >
> > _______________________________________________
> > apitrace mailing list
> > apitrace at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/apitrace
> >
>
>
I've pushed a follow on patch that tries to do the right thing, namelly
dlopen the right libGL/GLES*.so on demand. I also tried to document this
better.

Let me know if it works ok.

Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20111202/72bb7641/attachment-0001.htm>