RFC/WIP: Texture dumping support for GLES

[Alexandros Frantzis]

On Mon, Nov 28, 2011 at 03:20:38PM +0000, José Fonseca wrote:
> Binding textures as fbos will only work for textures which can be
> rendered. For other textures it will be necessary to quad blit into a
> temporary RGBA rendertarget.

Right. This code was meant as a quick way to get something running,
without messing with API differences (e.g. check the context to decide
how to implement the rendering).

> Given that querying state in GLES is so frowned upon, I wonder if it
> wouldn't be better to just use full GL + ARB_ES2_compatibility when
> dumping state? Or is the ability analyzing GLES traces on system not
> capable of full GL that important?

I believe it is an important feature to have, as it would allow using
apitrace in modern, GLES2-enabled mobile platforms.

> I doubt the overhead of tracking this is significant, but at any rate,
> we should skip for full GL and also for GL ES in benchmark mode.
>
> But no GL state whatsoever should be maintained inside glstate module.
> I'd like to eventually provide glstate module outside of apitrace
> (e.g., an app developer could simply bundle glstate in its own app,
> and invoke the dumper to see the current state in JSON). So this state
> should be maintained somewhere in glretrace and passed to glstate at
> dump time (as an optional parameter preferably).

Sounds good.

> > Comments?
>
> 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?

Thanks,
Alexandros