Between the 9th and 13th of March, the major game developer conference, the GDC 2010 will take place in San Francisco. Last year, GDC 2009 was the event where OpenGL 3.1 was announced. My little findger tells me that we can expect OpenGL 3.3 or at least some ARB extensions to be released this year. With this post, I am dealing with what will could expect for the future OpenGL specifications.
nVidia has released a really interesting presentation with audio at GPU Technology Conference about OpenGL. Three different speekers for three different topics. Barthold Lichtenbelt about OpenGL strategy and Shader Model 5, Mark Kilgard about OpenGL 3.2 and nVidia developments and Michael Gold about OpenGL interopability with other APIs and itself. With such a crew and such topics, I really pay attention to each detail!
Barthold Lichtenbelt, also OpenGL ARB Working Group Chair, gave the ARB discussion feature list for future releases. On top of the list SM5 features support, means D3D11 hardware. On second position there is making GLSL a true superset of GLSL ES. Crossing information, OpenGL ES could become an OpenGL profile like OpenGL core or OpenGL compatibility ... so maybe OpenGL embedded? That's would be absolutely nice! My personnal guess is that OpenGL for D3D11 hardware will be called OpenGL 4.0. This doesn't imply a possible API rewrite, this is so off the table. Beside, I don't believe in changes but in evolutions and on that matter, the deprecation and profiles mechanisiums did great. It's a major jump and this way OpenGL 3.x would remain for SM4 hardware. It makes a lot of sens to me especially because graphics card has tend to be more stable feature wise since SM4 generation. I don't picture any OpenGL embedded profile any time soon.
In this feature list a lot of "oldies" that the OpenGL community is pushing for: Direct State Access, splitting of the texture object into an image and a sampler object, shader binaries, anisotropic filtering. Even if I would love to see it as soon as possible, I don't see Direct State Access or seperated image and sampler objects for OpenGL 3.3... maybe OpenGL 4.0?
Two elements "Use program objects without linking" and "semantics" implies to me a single idea: seperate shader objects. I really don't like this extension but this is definetely where we are going for good reasons: software design and Direct3D compatility. I just don't like the way problems are solved. Basically, developers defined variables could not be used and we should rely on the old and deprecated build-in variables which makes the code absolutely missleading: For example, what the fuck does it means to use a variable called texcoord for a tangent?! Other issue, it introduces a new selector "glActiveProgramEXT" which is absolutely bug prone. Semantics like Cg would allows no linking and no missleading language use as it just introduce some kind of binding points that variable could be attached to. Also, Direct State Access removes selectors. Every elements are here to make it right... findger crossed! I expect this concept to be in OpenGL 3.3.
Last really important part: API interopability which became really important these days because of OpenCL and CUDA but also because of the whole SLI / CrossFire thing. There are considering cross process texture sharing. (why not buffer?) I think it will be in the OpenGL 3.3 train. Some results of this work is probably the recent OpenCL question CL_KHR_gl_sharing. Previous work like the acknowledge WGL_AMD_gpu_association extension or the older WGL_NV_gpu_affinity extension give more clues.
ATI driver 10.2 reports an extension called GL_ARB_blend_func_extended which isn't documented yet. I read here and there that ATI hardware have much more flexible ROPs than what OpenGL or Direct3D exposed but I don't know about nVidia hardware. Is this an atempt to fill this gap? Probably, but I'm quite sure we will have details about it during the GDC 2010. It will definetly give some anwers to people who asked for programmable blending. nVidia has published the great extension GL_NV_texture_barrier which allows to safely write on a binded texture. Probably, a part of this GL_ARB_blend_func_extended extension.
SM5 support? I think it will be with an OpenGL 4.0 release at Siggraph 2010. I expect to see SM5 supports by nVidia with nVidia extensions at GeForce GTX 480 launch end of March. Will we have an OpenGL 3.3 at GDC 2010? What would it be? Answers will be given in 2 weeks!