Official feedback on OpenGL 3.1 thread

[Heiko]

Well, perhaps the vendors will be releasing something like `legacy drivers' in the future? Say every once in a while they release a driver that includes the ARB_compatibility extension, but their newest lean and mean driver won't contain it (like they do for old graphics cards, every once in a while a new legacy driver is released for old graphics cards, but the mainline drivers don't have support for them). My guess is that the old code won't need every newest driver anyway.

I think that could be a perfect way to phase out the pre-GL3 code and focus on an OpenGL 3.1 driver that is clean.

Personally I'm quite happy with the 3.1 release, I didn't expect the deprecated stuff really to be removed from this release. The uniform buffer is also quite a nice feature. Besides that: 9 months after the previous release, who would have expected that after what happened with OpenGL 3.0?

My guess (hugely based on hope) is that we will see an OpenGL 4.0 version that will be the new rewritten API sooner than most expect. The OpenGL 3.x line is needed for transistion to a new API. They just couldn't make that huge step at once.

Here is a nice blogpost written by Paul Martz on the topic:
http://www.skew-matrix.com/bb/viewtopic.php?f=3&t=4

[Y-tension]

Cool! Great! But just 1 question: Why not geometry shaders?

[Groovounet]

Because geometry shaders are going to be deprecated in few years. It's just a good bad idea.

When I read how nVidia push with "WE WANT BACKWARD COMPATIBILTY", I don't think this dreamy rewritten OpenGL will exist any soon.

[Groovounet]

This extension / feature seams to have been rushed released ^_^

[skynet]

ARB_compatibility is absolutely necessary

No, its not. You want to use ARB_uniform_buffer_object in immediate mode? No problem, ARB_uniform_buffer_object written against the GL2.1 specs. Just open a GL2.1 context and use them together.

A lot of time and money has been invested in writing pre-GL3 code, expecting that will be thrown away just to use uniform buffers is unreasonable.

Just because GL3.1 came out, it doesn't mean, the 2.x (and even 3.0) driver and functionality automatically goes away. Your existing software will function as always. If you want to stay with old funcionality, just request a 2.1 context. There's absolutely no problem. But please don't penalize those that want to upgrade their software to benefit from faster and more stable drivers.

Backwards compatibility is one of the main wins for GL vs D3D,

IMHO backwards compatibility has become the major drawback of OpenGL. But this has been discussed in lengths already...

[glfreak]

It's really a stripped version of GL that gets rid of all CAD stuff. That's good if it makes GL implementation more stable and easier.

Because geometry shaders are going to be deprecated in few years. It's just a good bad idea.

Why? It's now standard feature of the modern graphics pipeline.
Why not there?

Where's direct state access?

Now we have no reason not to prefer Direct3D.

[Rob Barris]

IMO the distinction between making the geometry shader feature core or not would be more significant, if there were vendors that were avoiding implementation of the extension. i.e. if you as a developer wanted to use it but found out that a particular IHV had not implemented it, this could pose a real problem. But my understanding is that it is readily available on both AMD and NVIDIA implementations. So since the actual hard work of implementing it is complete, I would expect that extension to be around as long as the feature still exists in the hardware. Whether that interval is "forever" or "a couple of generations" I do not know.

[Heiko]

IMO the distinction between making the geometry shader feature core or not would be more significant, if there were vendors that were avoiding implementation of the extension. i.e. if you as a developer wanted to use it but found out that a particular IHV had not implemented it, this could pose a real problem. But my understanding is that it is readily available on both AMD and NVIDIA implementations. So since the actual hard work of implementing it is complete, I would expect that extension to be around as long as the feature still exists in the hardware. Whether that interval is "forever" or "a couple of generations" I do not know.

I was under the impression that AMD did not implement the extension for the geometry shader yet. Am I wrong?

Check this news post on geeks3d about the extensions supported by AMD hardware:
http://www.geeks3d.com/?p=3522

There are no extensions for the geometry shader. Also:
Geometry Shader Texture Units: 0
Max Geometry Uniform Components: 0
Max Geometry Bindable Uniforms: 0

I think putting them into core would finally make AMD implement the geometry shader as well...

[glfreak]

Then based on assumption that a feature may or may not exist in hardware, we would end up having no core, everything is extension,
unless GS is going under revising whether or not useful...

But with all these features deprecated, it makes it a bit more Direct3D 10...with more overhead and backward compatibility issues.

[ebray99]

I think the idea of the ARB_compatibility extension is a good one. However, I think this extension should be revised to contain a new token for "enabling" compatibility. For instance:

// enable compatibility for the life of the application.
glEnable( GL_COMPATIBILITY_ARB );

If the extension is enabled, then old GL calls would work fine. If the extension is disabled, then the old GL calls would generate an error. Also, having header files that remove deprecated functionality would be a great thing!

My biggest concern with this particular extension has to do with the fact that modern code bases are large. If you're porting an old code base to GL3.1, and you miss something, ARB_compatibility would make it "just work", and you'd end up with a pretty serious bug in your program that could go completely unnoticed until your product has long since shipped to the masses. I'd like to be able to avoid these kinds of scenarios to ensure the maximum longevity of my applications.

Kevin B