OpenGL 3 Updates

[mfort]

Please calm down. I really understand CAD-like companies. Making new API with no backward compatibility would brake it all.

No. Why do you think that?
You could still use drivers written against the old API spec.
I think that IHVs would continue driver support for quite some time even for future hardware.

Why? It is simple. CAD like companies want to add few new OpenGL features to their renderer once a while without rewriting it all from scratch. Imagine they freeze OpenGL 2.x and offer new features only in OpenGL 3.0. Then the new features will never appear the large older applications.

Please also keep in mind that OpenGL is used for many non rasterizing graphical tasks, like GPGPU. (I am one of them as well). OpenGL is so wrong API for this but don't blame OpenGL for that. We have CUDA now, may OpenCL is coming. Raytracing rendering will probably replace all OpenGL/DX*. can you imagine OpenGL twisted for a ray tracing API?


/Marek

[LogicalError]

GL3 is a better match for current hardware

Oh really? which part of the gazillion different extensions?

GL3 has much of DX10 level functionality.

And DX10 had full DX10 level functionality since.. well.. when it was released several years back!

Personally I could care less what the API looks like as long as it is fast, it supports the hardware features, and all vendors actually provide drivers.

wait.. are you talking about DX10 now?
because that certainly doesn't sound like opengl!

Edit: yeah. sorry, i'm pissed off, please don't take it personally.

[bobvodka]

Personally I could care less what the API looks like as long as it is fast, it supports the hardware features, and all vendors actually provide drivers.

Except you are already dropping speed as the hardware drifts away from the API (the D3D10 model, what GL3.0 looked like before this... thing... is closer) and reliable drivers are harder to write because the new features have to interact with the old.

The fact of the matter is right now Intel's GL drivers suck and with more complication I don't expect this to improve. Even AMD's drivers have problems and a lack of features, which will delay their GL3.0 release as well and god knows how stable it will be.

For OpenGL2.2 it would have been a nice release, for a GL3.0 it's just another GL2.0 sized blunder and compromise.

[Rob Barris]

One feature of GL 3.0 is a mechanism for requesting a context where the deprecations are enforced - this was put in to give developers a way to run their apps in this mode early on.

There is a lot of alignment between the feature set marked deprecated in GL 3.0 and the set of features that Long's Peak was slated to remove.

[bobvodka]

Why? It is simple. CAD like companies want to add few new OpenGL features to their renderer once a while without rewriting it all from scratch. Imagine they freeze OpenGL 2.x and offer new features only in OpenGL 3.0. Then the new features will never appear the large older applications.

And as I recall there was ALWAYS plans to allow a crossover of GL2.x and Longs Peak features via the same context for just this sort of thing so companies could migrate. I guess the plans weren't good enough.

[MZ]

One feature of GL 3.0 is a mechanism for requesting a context where the deprecations are enforced - this was put in to give developers a way to run their apps in this mode early on.

What are supposed short term/long term benefits of running GL app in the deprecated mode?

[ZbuffeR]

There is a lot of alignment between the feature set marked deprecated in GL 3.0 and the set of features that Long's Peak was slated to remove.

Great, where can I download a GL 3.0 pdf spec without all the deprecated features now ?
Because currently it means "read the spec" - "skip to the end to check if this or that feature is deprecated" - "loop" and is very messy to read totally useless stuff.

[Korval]

As work is already underway for the next release, this is exactly the right time to bring up functionality that you want either as an OpenGL 3.0 extension or for the next core release.

OK, if you want. I mean, I don't care about OpenGL anymore, and I'll be abandoning OpenGL in the future, but if you insist:

GL "3.0" is not Longs Peak. It doesn't align with all (or even most) of the features of Longs Peak, even if you ignore the lack of the new object model. Here's a "short list" of features that Longs Peak promised that GL "3.0" doesn't deliver:

- Getting rid of GL_FRAMEBUFFER UNSUPPORTED. That is, providing a mechanism that makes this impossible, that allows a user to know beforehand whether a particular combination of images and state is allowed by the implementation. Without this, FBO still has the same problems it always did.

- Instancing programs. GL "3.0" program objects are still bound directly to their data. It is often the case that you want to use the same code, but with completely different sets of data. This requires constantly respecifying uniforms and attributes every time you want to use it. This is not conducive to performance. Longs Peak had "Program Environment Objects" which stored the state for a program. This also had the benefit of preventing stupid implementations (I'm looking at you, nVidia) from recompiling your program just because you changed a uniform.

- The ability to "mix&match" programs of different types. That is, the ability to use a vertex program that you did a full compile/link on and a fragment program that you did a full compile/link on that were not explicitly linked together. GL "3.0" still uses the 2.x model.

- Image Formats. These were supposed to be the way that you could ensure that images of a specific format could be created and used as you wanted. If you wanted to create a floating-point texture that required bilinear filtering, you needed an image format first. And if the image format creation failed, then you know you couldn't do it because the implementation didn't support it. GL "3.0" doesn't have this.

- Decoupling of Image from TexParameter. Longs Peak had "Texture Filter" objects that represented TexParameter stuff. Much like the program instance Program Environment object, this allowed a decoupling of data (Image, Program) from its use (TexParameter, uniforms and attributes).

- Forced "Hints". Buffer objects in particular were supposed to get hints that weren't actually hints; they were forced. Attempting to do certain operations with buffer objects that were set up incorrectly would produce non-functional code. GL "3.0" still has you able to map from any kind of buffer object and other nonsense.

- The ability to use it on 2.x hardware (Radeon 9700+/GeForceFX+). That was an explicit feature of Longs Peak: it could all be used on older DX9-compatible hardware. GL "3.0" requires DX10-class hardware, even though it doesn't even provide access to the main DX10 features (geometry shaders, uniform buffers, etc).

These were not minor features of LP; they were vital. They characterized what LP was: a way to do graphics while taking out the guesswork and needless weirdness. No "deprecated context" nonsense will bring these features back. And they weren't bound to the new object model; they were features that were introduced because API cleanup was happening.

[HAL-10K]

Why? It is simple. CAD like companies want to add few new OpenGL features to their renderer once a while without rewriting it all from scratch. Imagine they freeze OpenGL 2.x and offer new features only in OpenGL 3.0. Then the new features will never appear the large older applications.

That some decade old CAD application won't be able to use state of the art tesselation programs or whatever without rewriting the API interface at some point, is no rational reason to keep backwards compatibility on an API that is now going to be SEVEN years behind it's competitor in a very fast-pased market.

This is reason enough for us to abandon the 7% of our costumers on the MacOS platform.

[Brolingstanz]

I think some of us need to read the new specifications again. I think there's more to this deprecation model than first meets the eye ;-)

On point, I don't see what's preventing a new object model - or new anything else for that matter - from being introduced and deprecating the relevant parts as needed. If the driver only has to support the context version requested, it's pretty much all gravy.