Build egltrace/eglretrace with different flavors of API (was: RFC/WIP: Texture dumping support for GLES)

Chia-I Wu olvaffe at gmail.com
Wed Nov 30 23:14:09 PST 2011


On Thu, Dec 1, 2011 at 11:49 AM, Kan-Ru Chen <kanru at kanru.info> wrote:
> José Fonseca <jose.r.fonseca at gmail.com> writes:
>
>> Lets:
>> 1) split GLES state dumping out of GL
>> 2) make eglretrace / egltrace build/run without full GL support
>> (actually, make it build/run with any subset of GL/GLES1/GLES2 APIs).
>
> This is great! I have build a egltrace that works on Android and now
> want to retrace the traces natively on the device.
>
> I can think of two ways to accomplish this:
>
> 1. Annotate specs/glapi.py and specs/glparams.py so that we can select
>   different subsets of API to build.
For eglretrace not to depend on libGL, it may suffice to remove GL 1.2
and ARB_multitexture entrypoints from public_symbols in glproc.py.
That is, make all GL entrypoints dynamically looked up.

GLES state dumping still needs to be resolved though.

> 2. Include full definitions of these APIs so we can build without system
>   headers, then dlsym on every needed symbols as suggested below.
>> And I also want to do some cleanups on glproc, namedly always dlopen
>> () libGL.so/libEGL.so/etc when retracing.
>>
>> And after these are complete, lets see where we stand, and revaluate.
>
>
> --
> Kanru
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/apitrace



-- 
olv at LunarG.com


More information about the apitrace mailing list