What did we miss from Longs Peak

For those of you who were familiar with LP, GL 3.0 isn’t that. It isn’t close. A whole lot of things were missed.

What I want is a full accounting of the features we didn’t get, so that we can reprioritize them. I’ve looked over the old PDFs, and I have a list, but I’m not certain it is comprehensive. Feel free to add to this anything you remember.

BTW: though I’m all for the complaining about 3.0, don’t do it in this thread. We know we didn’t get the new object model; there’s no need to restate that. What I want are the bits of functionality that we didn’t get.

  • Backing-store controls: LP was going to provide a way to set textures and buffers, on an object-to-object basis, to not have a backing store.

  • Dividing image from sampling parameters: Basically, taking TexParams out of texture objects and putting them in another place, then combining them as needed at texture/program bind time.

  • Constant program data: In LP, there was going to be a thing where, when you linked a program, you could specify that certain uniforms had constant values. This gave the optimizer the chance to make some adjustments, and it also stopped crazy implementations like nVidia’s from recompiling your shader just because you changed a uniform.

  • Separation of Program and Program Environment: mixing and matching different stages, instancing programs, etc.

  • Uniform buffers

I can’t think of anything else offhand.

Fine grain sharing of objects between contexts.


Speaking of which, that jogged my memory:

  • Asynchronous object creation.

What I miss most in 3.0 is ARB_sync.
They promised that in 2006!
See this powerpoint:

Then this post from Barthold/NVIDIA

So we have OGL3.0 but no sync API :frowning:


Totally forgot about that one. I suppose the ARB did too…

  • Fence or other similar synchronization token. (though I wonder if you can overload occlusion queries to get the same functionality?)

Also, I seem to recall something from LP about being able to create objects in one thread (ie: textures) and then render to them in a different thread. Basically:

  • Improved specification of how OpenGL interacts with threading.

That one’s only going to get more important as time goes on.

Yeah it (threading) is. For a stop gap, having ARB support for fences which are shareable across contexts would help. Currently the only vendor NV/APPLE_fence is not context shareable.

For a stop gap, having ARB support for fences which are shareable across contexts would help.

I’m not sure how that would help. Well, depending on what you’re trying to do in another thread, that is.

Yeah, but it would just give you better ability to manage dynamic buffers/textures from other thread(s). For now you would still have to manually queue up your own version of “draw calls” in separate thread(s), and then have one master thread access the API and do the real draw calls.

I basically missed the promised object model, threading/multiGPU and resource sharing.