Aliased names for glCreateShader and glCreateShaderObjectARB

[José Fonseca]

On Thu, Aug 2, 2012 at 9:23 PM, Carl Worth <cworth at cworth.org> wrote:
> José,
>
> I recently found a program mixing calls to glCreateShaderObjectARB and
> glUseProgram, (rather than sticking to consistent use of
> glUseProgramObjectARB).
>
> The current apitrace code uses three different tables for mapping
> shaders and programs:
>
>         _shader_map
>         _program_map
>         _handleARB_map
>
> The problem we ran into with this trace is that we could not trim out
> calls to glCreateShader for unused shaders without causing link failures
> for subsequent programs.
>
> 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).
>
> 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 was trying to decide whether to write the clever code to determine
> whether to use one or two tables or just punt with a single table for
> now. And then I ran across this existing comment in the gltypes.py:
>
> # Share the same mapping table for uniform locations of both core and
> # GL_ARB_shader_objects programs.  For a combination of reasons:
> #
> # - all OpenGL implementations appear to alias the names for both kind of
> #   programs;
> #
> # - most applications will use only one kind of shader programs;
> #
> # - some applications actually mix glUniformXxx calls with
> #   GL_ARB_shader_objects programs and glUniformXxxARB calls with core
> #   programs, and therefore, rely on a joint implementation.
> #
> # We use GLhandleARB as program key, since it is wider (void *) on MacOSX.
>
> This looks like plenty of justification to merge the above three tables
> into one. Do you agree, José?

I'm alright with assuming that program == programObj, as the risk of
corruption is minimal/non-existance, but assuming that shader and
program have the same namespace is slightly different, as it risk
affecting apps/drivers that stick to the core OpenGL spec.

It's still a bit concerning that one day an OpenGL implementation that
doesn't support GL_ARB_shader_objects and uses separate namespaces for
shaders and programs, which would cause the name remapping to fail
when the same id is used both for a shader and a program.

For example, what do OpenGL ES 2 implementations do? They don't
support GL_ARB_shader_objects, so it seems quite possible that they
use separate namespaces for shader/programs...

In summary, two tables seems doable, but one table seems risky.


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?


Jose