RFC/WIP: Texture dumping support for GLES

[José Fonseca]

On Tue, Nov 29, 2011 at 1:37 PM, Alexandros Frantzis
<alexandros.frantzis at linaro.org> wrote:
> 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.

Several toolkits and graphic libraries and web browsers are adding
backends to GL and/or GLES, so the odds of both of them being used on
the same process seem to be getting higher.

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

Yes.

glproc is also a mess and needs a good cleanup on its own right.

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

Precisely.

Jose