Aliased names for glCreateShader and glCreateShaderObjectARB

[José Fonseca]

On Tue, Aug 28, 2012 at 7:59 PM, Carl Worth <cworth at cworth.org> wrote:
> José Fonseca <jose.r.fonseca at gmail.com> writes:
>>> I recently found a program mixing calls to glCreateShaderObjectARB and
>>> glUseProgram, (rather than sticking to consistent use of
>>> glUseProgramObjectARB).
>
> And yesterday I found myself uselessly going through the process of
> debugging the exact same failure mode (with the exact same program).
>
> Apparently, I failed to hold on to the quick hack I had made to make
> apitrace work with this program. (And, also, I failed to get anything
> upstream to fix this.) So here I hope to document things better and
> hopefully move toward getting something upstream.
>
>> Concerning this app, what about masking out support for
>> GL_ARB_shader_objects when tracing? Does that yield a lean trace that
>> only uses the core entrypoints?
>
> We tried this yesterday, and unfortunately it didn't cause any behavior
> change in the program. So clearly there's a bug in the program. We'll
> try to talk to the application authors and get things fixed, (might as
> well not doing any mixing of the calls at all). So hopefully this
> problem will go away for this particular application.
>
>>> I implemented a quick hack with a single table for all of the above uses
>>> and that fixed our particular problem, (particularly since I know that
>>> our implementation uses a single namespace for all of the above).
>
> Here's that quick hack, (so that if I lose it again, I can find it in my
> email):
>
> diff --git a/retrace/glretrace_gl.cpp b/retrace/glretrace_gl.cpp
> index 425634d..d11478a 100644
> --- a/retrace/glretrace_gl.cpp
> +++ b/retrace/glretrace_gl.cpp
> @@ -17,7 +17,8 @@ static retrace::map<GLuint> _list_map;
>  static retrace::map<GLuint> _texture_map;
>  static retrace::map<GLuint> _query_map;
>  static retrace::map<GLuint> _buffer_map;
> -static retrace::map<GLuint> _program_map;
> +#define _program_map _handleARB_map
> +#define _shader_map _handleARB_map
>  static retrace::map<GLuint> _shader_map;
>  static std::map<GLhandleARB, retrace::map<GLint> > _location_map;
>  static retrace::map<GLuint> _programARB_map;
>
> (And, in generating this patch I realized why I lost it earlier. This is
> an edit of a generated file that's untracked by git.)
>
> As described above, this patch is not portable since it assumes that the
> OpenGL implementation uses a single table for both shaders and
> programs. So this works for me on Mesa, but it's definitely not
> guaranteed to work on other implementations.
>
>>> Eric pointed out that an implementation supporting
>>> glCreateShaderObjectARB is effectively forced to have a single namespace
>>> for shaders and programs, (so that one map is the correct answer). But
>>> an implementation without this support might have separate namespaces,
>>> (in which case we would want one shader_map and one program_map). But in
>>> no case do we actually want three tables.
>
> I've now started work on this better solution. See the patch attached
> below.
>
> This patch seems to work in the testing I've done. It has some code to
> support an OpenGL implementation without support for the
> GL_ARB_shader_objects extension but I have not tested that.
>
> Meanwhile, the code is not ideal. It has a couple of layering
> violations, where code in retrace.py is generating GL-specific code, and
> one piece of the code generation has a fixed string "_handleARB_map"
> where similar code goes through a function call to construct a string
> such as "_program_map".

I haven't forgotten about this patch. I'd prefer a more robust solution however.

The fact is that this issue is not an isolated case. GL handle mapping
is a mess: some objects namespaces are per context, some are per
share-group, and often the interpretation depends on the extensions
(e.g., ARB vs EXT FBOs).

So the only way to address this is to stop pretending that handle
swizzling is simple, stop generating code to maintain these busted
swizzling maps. Instead, implement hand written code to swizzling
every handle, using a predictable interface, and simply generate code
that invokes the hand written functions.

For example, something like:

   void add_GLframebuffer_swizzling(int orig_fbo, new_fbo);
   int swizzle_GLframebuffer(int orig_fbo)


  etc.

Jose