RFC/WIP: Retracing without explicitly linking to libGL

[Chia-I Wu]

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
>



-- 
olv at LunarG.com