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

[José Fonseca]

On Fri, Nov 4, 2011 at 7:05 AM, Chia-I Wu <olvaffe at gmail.com> wrote:
> 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.

Sounds good.

I like how the interactions with tracing/retracing of full GL have
been minimized, as that means that the likelihood of regressions on
current functionality is minized too, specially on platforms that
don't have EGL/GLES, making easier to merge in master.

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

Yes, I've been avoiding having per-context tracing state (which is why
user_arrays means "an user array was set in any context"), to avoid
messing with TLS, but it is indeed inevitable.

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

Sounds good.

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

Ok. Is this temporary, or is there a portability issue with hooking dlopen?

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

Do they respect LD_LIBRARY_PATH? I believe that that's a more reliable
interception approach than LD_PRELOAD, as it avoids hooking into
dlopen.


Anyway, I've reviewed the egl and gles series, and it looks good overall.

The only bit I prefer done differently is the gles enum pretty name
workaround -- I rather have all GLES enums that are not part of GL
defined on a header in the form:

  #ifndef GL_SOME_GLES_SPECIFIC_ENUM
  #define GL_SOME_GLES_SPECIFIC_ENUM 0xXXXX
  #endif

so that the C++ code can always rely on them being defined, regardless
of platform support.


I'll commit the egl series once I've finished testing on non-Linux platforms.


Jose