RFC/WIP: Texture dumping support for GLES

[José Fonseca]

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.

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.

And after these are complete, lets see where we stand, and revaluate.

Jose