RFC/WIP: Texture dumping support for GLES

[Alexandros Frantzis]

On Tue, Nov 29, 2011 at 11:28:09AM +0000, José Fonseca wrote:
> On Mon, Nov 28, 2011 at 6:59 PM, Alexandros Frantzis
> <alexandros.frantzis at linaro.org> wrote:
> > On Mon, Nov 28, 2011 at 03:20:38PM +0000, José Fonseca wrote:
> >> I think it would be better a separate glesstate.cpp and
> >> glesstate_params.cpp modules -- it looks like the differences will be
> >> very big it it will be crowded of if (api == foo) { .. } plus #ifdef
> >> HAVE_FOO .... #endif to allow to build on systems with/without full
> >> GLES, making the code hard to read and maintain.  Of course, there
> >> would be a bit of duplication, but I think the net result of separate
> >> state dump for GLES would be positive.
> >
> > I wholeheartedly agree with this. To take it one step further, I think
> > it would be much cleaner to consider GL, GLES and GLES2 as completely
> > separate APIs, at least from the retracing perspective.
> >
> > As you mention, there will be some duplication, and we can choose if/how
> > to handle it on a per-case basis, perhaps by extracting and reusing
> > common code.
> >
> > For GLES2, the process should look like:
> >
> >  * Add specs/gles2.py, specs/gles2params.py, (specs/gles2types.py?)
> >  * Add gles2retrace.py
> >  * Add gles2state.cpp, gles2state.py
> >  * Anything else I am missing?
> >  * Make all the above work together to produce a 'gles2retrace'
> >   application that will use libGLESv2 to retrace, effectively
> >   supporting only EGL/GLES2 traces.
> >  * Add a GLES2 mode to qapitrace
> >
> > The same can be done for GLES1, but it is not a priority for me.
> >
> > The existing 'eglretrace' application will not be affected at all; it
> > will continue to support GL/GLES1/GLES2 with libGL (for Mesa, at least).
> > Of course, 'glretrace' will remain unaffected, too.
> >
> > How does that sound?
> 
> State dumping for GL, GLES1, and GLES2 can be cleanly separated, but
> retracing cannot, as these APIs are supposed to interoperate and they
> share the same entry points.

Well, technically you can separate them (as described), but as you said,
you lose the benefit of being able to retrace multiple APIs at once
(where supported). Depending on the environment, this may be more or
less important, but I understand that apitrace needs to be as flexible
as possible.

> Also, when retracing, 99% of the calls amount nothing more than dumb
> unmarshalling of the arguments and dispatch to the entry point,
> regardless of the API. (I actually think that glretrace and eglretrace
> might be eventually unified without any disadvantage).
>
> But sure, the 1% of the calls that require manual coding could be
> refactored such that the API-specific bits are isolated.
> 
> 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).
>
> And I also want to do some cleanups on glproc, namedly always dlopen
> () libGL.so/libEGL.so/etc when retracing.

If the plan is to have a single retracer that has support for every GL
(plus flavors) function, and is able to run with any flavor as a
backend, I believe that the glproc cleanup you mention (plus more) is
actually a prerequisite for a clean and flexible implementation.

In this scheme, *all* gl functions would be accessed through pointers
acquired with dlsym() or *GetProcAddress(), as is happening now for some
functions. The right library would be dlopen-ed on demand, and chosen
depending on the type of the GL context requested by the application, or
as requested by the retrace caller.

Thanks,
Alexandros