More pages: 1 2
OpenGL 3
Friday, April 10, 2009 | Permalink
In my framework work I've started adding OpenGL 3.x support. I was one of the angry voices about what happened with OpenGL 3.0 when it was released. It just didn't live up to what had been promised, in addition to being a whole year too late. While OpenGL 3.0 didn't clean up any of the legacy crap, OpenGL 3.1 finally does. A bunch of old garbage that were simply labelled deprecated in 3.0 have now actually been removed from OpenGL 3.1. As it looks now, OpenGL is on the right track, the question is just whether it can make up for lost time and keep up with Direct3D going forward.
However, along with the OpenGL 3.1 specification they also came up with the horrible GL_ARB_compatibility extension. I don't know what substance they were under the influence of while coming up with this brilliant idea. Basically this extension brings back all legacy crap that we finally got rid of.
This extension really should not exist. Please IHVs, I urge you to NOT implement it. Please don't. Or at the very least don't ship drivers with it enabled by default. If you're creating a 3.1 context, you're making a conscious decision not to use any of the legacy crap. Really, before venturing into OpenGL 3.1 land, you should've made the full transition to OpenGL 3.0. Fine, if a developer for some reason still needs legacy garbage during a transitional period while porting over the code to 3.1 he can enable it via a registry key or an IHV provided tool. But if you're shipping drivers with it enabled by default, you know what's going to happen. An important game or application is going to ship requiring the support of this extension, and all the work done on cleaning up the OpenGL API is going to be wasted. It would have to be supported forever and we're back at square one.
In my framework I'm going to use the WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB flag. This means that all legacy crap will be disabled. For instance calling glBegin()/glEnd() will be a nop. This will ensure that I'm sticking to modern rendering techniques. All new code should be using this. The only reason for not using it is if you're porting over some legacy code. The deprecation model that OpenGL 3.0 added is fundamentally good. It allows us to clean up the API while giving developers the ability upgrade their code. If done right the whole OpenGL ecosystem would modernize by necessity. This of course relies on Khronos not to poop all over the efforts with stuff like GL_ARB_compatibility.
Anon
Sunday, April 12, 2009
You have nvidia to thank for this extension. Just like their implementation of the forward compatible flag (simgly ignored). Horrible, just horrible.
The biggest thing lacking from OpenGL right now is DSA. The bind-to-edit model is evil, especially for middleware libraries.
Humus
Monday, April 13, 2009
Rohit,
yes, I will enable it in the Linux code as well. I started on the Linux stuff yesterday and it's up and running now too.
n00body,
well, not necessarily. I can still expose features, even if I don't implement them in OpenGL. Also, with OpenGL 3.1 it's much closer than it was in the past. Things like constant buffers exist in OpenGL now. I'm going to need them to share a common interface, so OpenGL 3.1 will be a requirement. However, in some cases I suppose I may want to expose API specific features. The framework interface doesn't necessarily have to be 100% indentical between APIs. Where it makes sense I may divert from it.
Anon,
in my test the forward compatible flag is not ignored. It generates INVALID_OPERATION if you use deprecated features.
I definitely agree on Direct State Access. It's on top of my wish list right now. If any Khronos members are reading this, please include DSA in OpenGL 3.2.
Anon
Monday, April 13, 2009
They fixed that? Great! (Time to upgrade my drivers.)
Nvidia's original 3.0 drivers silently ignored the forward compatible bit (a situation oddly similar to their GLSL compiler accepting Cg code) and they did make a comment in the spirit of "our customers want GL2.1 so we'll keep that around".
Another question: if a) you set the forward compatible flag when b) ARB_compatibility is avalaible, will deprecated functions raise INVALID_OPERATION errors?
More pages: 1 2
