Also on the meta-cannot-use-Gen branch of my fd.o Mesa tree. This
branch will contain all of the current work... including patches beyond
this series.
On 11/09/2015 04:55 PM, Ian Romanick wrote:
> 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.
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
