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

[Chia-I Wu]

On Sun, Nov 6, 2011 at 3:22 AM, José Fonseca <jose.r.fonseca at gmail.com> wrote:
> 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.
Oh, I see.  The changes on the gles branch just move the static
variables to a static tracer_context.  So a state in the static
tracer_context still applies for "any GL context", except for the new
"profile" state.  Should I fix that up by, say, querying GL_VERSION to
derive the current API?
>> 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?
There is a bug in Android that prevents dlopen from being overridden.
I don't recall whether apitrace's dlopen is just ignored, or apps
crash when it is called.

My tests for GLES support on desktop are limited to those simple demos
from Mesa.  As they do not dlopen EGL/GLES libraries too, it might be
better to keep libegl_sym simple until there is a real need.
>> 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.
I just ran "strings" on the binaries and there is no LD_LIBRARY_PATH.
So probably not.

Speaking of LD_LIBRARY_PATH, EGL and GLES symbols are in separate
libraries.  To support it, egltrace.so will also need to be separated.
 Most of changes required should be in the build system though.

>
> 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.
Yes, I will make the change.  For GLES, the platform dependent part is
defined in glplatform.h.  I should be able to

#ifdef HAVE_EGL // the platform has its own GLES platform headers
#include <GLES/glplatform.h>
#include <GLES/gl2platform.h>
#else
#define GL_API
#define GL_APIENTRY
#endif

// GLES enums are always defined
#include "GLES/glext.h"
#include "GLES2/gl2ext.h"

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



-- 
olv at LunarG.com