[Mesa-dev] [PATCH 00/23] Don't pollute the buffer object namespace in meta

[Ian Romanick]

In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions.  The GL spec is very
clear about how you can mix-and-match generated names and non-generated
names: you can use any name you want for a particular object type until
you call the Gen function for that object type.  After calling Gen,
making up your own names is not guaranteed to work.

Meta uses Gen all over the place, and this can conflict with names the
application may try to use.  It's not hard to find OpenGL demos that do
things like:

   glBindTexture(GL_TEXTURE_2D, 1);
   ...    

   glBindTexture(GL_TEXTURE_2D, 2);
   ...    

I suspect there are even demos in the mesa-demos repository that do
this.

This is, IMO, a case of premature optimization in OpenGL 1.0.  In OpenGL
1.0, almost all implementations were indirect-renderers.  If names had
to be allocated from the server, that meant you had to (queue dramatic
music) have an extra round-trip to the server to get some names.  In
addition, allowing user-defined names meant that you could name the
display list (the only pseudo-object in OpenGL 1.0) that drew the letter
A, (int)'A'.  It was common to see text rendering loops like:

    while (*str) {
        glCallList((GLuint)*str);
        str++;
    }

On the systems of 1992, that may have mattered.  It's certainly not an
optimization that has mattered on any system that I've programmed OpenGL
on, and the damage that it does inside drivers is... this is a 23-patch
series to fix a bug that should never have existed!

Here's the problem scenario:
    
 - Application calls a meta function that generates a name.  The first
   Gen will return 1.

 - Application decides to use the same name for an object of the same
   type without calling Gen.  Many demo programs use names 1, 2, 3,
   etc. without calling Gen.

 - Application calls the meta function again, and the meta function
   replaces the data.  The application's data is lost, and the app
   fails.  Have fun debugging that.

This patch series is longer than is strictly necessary.  I wanted to
make each individual step easy to review.  It's a good thing too.  There
were a couple places where I made typos or cut-and-paste errors that
were much easier to bisect.

This patch series also *only* fixes the problem for buffer objects.
Texture, sampler, framebuffer, renderbuffer, and assembly program
objects still need to be fixed.