RFC/WIP: Texture dumping support for GLES

[José Fonseca]

On Mon, Nov 28, 2011 at 12:26 PM, Alexandros Frantzis
<alexandros.frantzis at linaro.org> wrote:
> Hi all,
>
> thanks to recent patches, apitrace now has basic EGL/GLES(2) support.
> Unfortunately, as GLES(2) lacks a way to read texture parameters and
> directly read texture contents, the current texture dumping code does
> not work.

That's a pretty unfortunate decision from Khronos IMHO, as it would be
trivial for GLES implementors to provide at least the full
GetTexParameter/glGetTexLevelParameteriv set of parameters.

> The branch at:
>
> http://git.linaro.org/gitweb?p=people/afrantzis/apitrace.git;a=shortlog;h=refs/heads/gles-teximage-wip
>
> explores a way to add texture dumping functionality by manually tracking
> basic texture state while retracing, and using FBOs to read actual
> texture content.

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.

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?

> The patchset is still in an experimental state. It only supports the
> base texture level, and hardcodes decisions on what methods to use to
> access texture information and contents. However, it does work, and it
> illustrates the result I am aiming for.
>
> Ideally, the retracer would track the currently bound API (GL vs
> GLES(2)), and decide which method to use based on that.

Yes, the bound API should be stored in glws::Context.

> If the overhead
> of manually tracking state is considered high, we could skip the
> relevant snippets when producing code for the non-EGL retracers.

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).

> 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.

Jose