RFC/WIP: Retracing without explicitly linking to libGL

[Alexandros Frantzis]

On Fri, Dec 02, 2011 at 08:06:26AM +0000, José Fonseca wrote:
> 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

Hi Jose,

I have pushed some fixes/improvements at:

http://git.linaro.org/gitweb?p=people/afrantzis/apitrace.git;a=shortlog;h=refs/heads/glws-egl-xlib-fixes

This branch is based on 'glproc-cleanup', although I am not sure if all
the changes belong there conceptually. Here is a summary:

1. Use libGLESv2.so.2 as the OpenGL ES 2.0 library SONAME.
2. Cast native types to EGL types when calling EGL functions.
  
  These are straightforward.

3. Add 'profile' parameter to glws::createVisual().
4. Try to find the best matching EGL visual according to the profile.
5. Recreate the EGL visual to increase chances that it supports the requested api. 
  
  The existing mechanism for the selection of visuals could produce
  strange results in some cases. For example, on systems that support
  only ES1 and ES2, an ES1 visual was _always_ selected if there were
  no ES1|ES2 visuals, even if we actually needed an ES2 visual.

  By making the glws::createVisual() function aware of the requested
  profile, we can provide better matching visuals.

Thanks,
Alexandros