[PATCH 0/7] Add tracing and retracing for EGL (with desktop GL)

[Chia-I Wu]

On Fri, Nov 4, 2011 at 7:04 AM, José Fonseca <jose.r.fonseca at gmail.com> wrote:
> On Thu, Nov 3, 2011 at 10:56 AM, Chia-I Wu <olvaffe at gmail.com> wrote:
>> Hi list,
>>
>> We, at LunarG, use apitrace to trace GLES apps on Android.  This is an attemp
>> to contribute back our changes to apitrace, mainly to add support for EGL and
>> GLES.  In this first series, EGL (with desktop GL) support is added.
>>
>> Following this, I'd like to send an RFC series to add GLES support.  If you'd
>> like to see the complete changes to determine whether this series is to be
>> accepted, the changes for GLES are available on github
>>
>>  https://github.com/olvaffe/apitrace/tree/gles
>>
>> I could also send that RFC series to the list if that is preferred.
>>
>> This series adds a new target, egltrace.so, when EGL is found on the system.
>> It is supposed to be used like glxtrace.so, but is for EGL/OpenGL apps.  They
>> are tested with demos from Mesa demos repository.
>>
>> For now, only EGL 1.4 functions are traced.  No extensions are supported.
>> This could limit its usefulness a lot, but I'd like to get the infrastructure
>> ready first before expanding it to be more complete and useable.
>>
>> If you try to use it with an EGL/GLES app, first of all, the trace file will
>> be incomplete as GLES specific functions are not intercepted.  And when you
>> run glretrace on it, glretrace will abort with a warning when the first call
>> to eglCreateContext is retraced.
>
> Hi Olv,
>
> Thank you and LunarG for contributing this. I have't had much personal
> exposure to EGL/GLES, but it seems to have pickup a lot of interest
> lately.
>
> I'll need a bit more time to go through this series and the branch.
>
> I'm not very worry about the new functionality -- I've seen from the
> LunarG website that works pretty well --, but I'd like to understand
> better how it will interact with existing full GL support, given that
> some GLES entrypoints have same names as full GL. So, could you
> briefly explain what's the plan to handle that? Will GL vs GLES be
> selected at compile time? Or will GL and GLES be built side-by-side?
> And how do you envision that we should handle apps that use both GL
> and GLES?
In the series to be posted, GLES-specific entrypoints are described in
specs/glesapi.py.  egltrace.so will have all symbols from glapi.py and
glesapi.py.  That makes sure all entrypoints, GL or GLES, are
overridden.

When tracing, egltrace needs to know the client API in use.  It is so
that the tracer does not check for features that are not available in
GLES, such as secondary color array or PBO.  For that, the tracer
should have a local context that caches the necessary GL states:

  struct tracer_context {
      enum tracer_context_profile profile; // GL, GLES1, GLES2
      bool user_arrays;
      bool user_arrays_arb;
      bool user_arrays_nv;
  };

It is just a static variable for now, and replaces __user_arrays and
etc.  Longer term, it can cache more states to avoid any querying that
is currently done.  For example, it can cache whether there is a PBO
bound so that there is no need to check
GL_PIXEL_UNPACK_BUFFER_BINDING.  It should also be a prerequisite to
support multiple contexts or multiple threaded apps.

GL and GLES can be supported side-by-side in egltrace.so.  EGL says
nothing about exported symbols of the client API libraries.  But it
does specify that a function pointer returned by eglGetProcAddress can
be used for any client API (GL, GLESv1, GLESv2) that supports it.  We
take the liberty to believe that if an entrypoint exists in more than
one of the client APIs, all of them will behave the same.  That is the
case with Mesa when --enable-shared-glapi is given (without the
option, using both GL and GLES in an app will fail anyway).  Android
supports that from the beginning.

When egltrace.so(/glproc.hpp) needs to look up a symbol, it calls
__libegl_sym.  Right now, the function just tries both
eglGetProcAddress and dlsym with RTLD_NEXT to find the symbol.  It
does not try to find the right libraries to look up the symbol, nor
override dlopen.  As such, the apps must link to the client API
libraries at compile-time.

The thing is we ran into a class of apps that we believed use their
own ELF loader to load and find symbols.  It seems nothing will work
for them except for installing apitrace as the system's libraries.  We
do not have that done yet.  But because of those apps, we think it
might be better to not complicating __libegl_sym while knowing there
are always corner cases that it cannot handle.


> Jose
>



-- 
olv at LunarG.com