[PATCH 8/9] optionally track the GL state manually

[José Fonseca]

On Wed, Apr 11, 2012 at 4:19 PM, Imre Deak <imre.deak at intel.com> wrote:
> At the moment apitrace uses GL/GLES calls to querry the current GL status.
> This might not work if the underlying implementation doesn't support
> these calls. This is the case at least with the Android software GL
> implementation, where the following calls/arguments are not implemented:
>
> - glGetIntegerv with the following pname parameters, with for example
>   GL_VERTEX_ARRAY_BUFFER_BINDING and in general any GL_*_ARRAY_BUFFER_BINDING
>   pname parameter.
>
> - glEnabled with several cap parameters.
>
> Also glGetBufferSubData is not supported by GLES, so we need to track
> buffer contents, at least in some cases.
>
> This patch won't provide tracking for the full state, only for those
> parts that are essential for tracing GLES applications on Android. For
> the rest fall back to calling the the platform's GL function as it's
> used to be.

Imre,

I've been looking at the latest version of your "android manual
tracking" patches in more detail, but there are still some issues that
need more attention, so I'll need to tax your patience a little more.

- what state needs to be tracked to work around android bugs? what
state needs to be tracked to work around gles limitations?

   My understanding is that :

      - >  GL_VERTEX_ARRAY_BUFFER_BINDING/  GL_*_ARRAY_BUFFER_BINDING,
 glEnabled  are android bugs

      -> glGetBufferSubData are GLES limitations.

   Also please verify that the workarounds for android bugs are still
necessary with latest emulator. My understanding is that emulator is
open source, so I'd prefer that those issues were fixed there, as
these workarounds really complicate apitrace for all platforms.

    Concerning glGetBufferSubData, could we fallback to MapBufferOES instead?

-  We should only work  around andoird bugs on andoird, workaround
gles limiitations on all gles contexts (even outside android)  that
is, we should have helper Context methods like

    inline bool
    gltrace:::Context::needsShadowBuffers(void) const {
        return profile == PROFILE_ES1 || profile == PROFILE_ES2;
    }

    inline bool
    gltrace:::Context::needsShadowState(void) const {
#ifdef ANDROID
        return true;
#else
     return false
#endif
    }

and then the generated code should do

  if (ctx->needsShadowBuffers()) {
    /* keep state shadow */
    ...
  }

in generate I'd prefer the term "shadow" instead of "manual" to refer
to the state we need to keep ourselves.

-  glDeleteBuffers is munging the "n" argument. That means that the
call for the real glDeleteBuffers will always pass n=0, and buffer
objects leak.

- gl_buffer should be named "Buffer. Also, please use c++
constructor/destructor and other methods, so that the generated code
smaller and  easier to understand

- please hook into glGenBuffers, and allocate our shadow buffers  there


Finally, the state shadowing would be useful for retrace too.

This means that all state shadowing should be in a layer immediately
above dispatch so it can be reused everywhere.


Jose