At GDC 2010, the Khronos Group released two OpenGL specifications: OpenGL 3.3, for OpenGL 3 hardware class; and OpenGL 4.0, for OpenGL 4 hardware class. Since then we didn't had any update of the OpenGL 3 specification, but it doesn't mean that all the new extensions are designed only for OpenGL 4 hardware class. Actually a lot of them are OpenGL 3 hardware extensions or hardware independent extensions. In this post, we are studying AMD and NVIDIA OpenGL implementations of OpenGL 4 extensions on OpenGL 3 hardware.
It seems that Intel OpenGL implementation is becoming more relevant these days with the release of an OpenGL 4.0 drivers so that we might be able to target OpenGL 3.2 minimum (Apple implementation on MacOS X 10.7). I hope to come back soon with a discussion about Intel drivers but it might take some time as I don't have an Ivy Bridge system yets.
There are some extensions released after OpenGL 3.3 which could have form OpenGL 3.4 but this is unlikely to happen. How the ARB could justify that OpenGL 3.4 becomes a partial superset of OpenGL 4.0 and 4.1? I think, this would only fragment even more the OpenGL ecosystem which is already pretty fragmented as this rescent poll demonstrates.
The case of ARB_shader_image_load_store is quite specific. If we really look at it then it seems that most of the extension could be implemented on OpenGL 3 hardware. "Most of it" includes the load and store, the early-z and the memory barrier. AMD and NVIDIA implementations both supports NV_texture_barrier which is nothing less than a subset of ARB_shader_image_load_store memory barrier for texture memory transactions. This is a very important extension allowing rendering without framebuffer ping-pong on iterative image space algorithms.
There is no obvious equivalent to Direct3D 10.1 with OpenGL but if we consider OpenGL 3 plus a set of extensions we reach the equivalence. On contrary of Direct3D 11.1, which monstlys add OpenGL features that were already here basically since its creation, we see from this set of extensions that Direct3D 10.1 added quite a few interesting features. On OpenGL 3 hardware, this set of features is monstly available on AMD hardware through the HD 3000 and HD 4000 series. On NVIDIA side, there is few low end GeForce 200 and 300 series supporting them on OpenGL 3 hardware class. Indeed, all these features are available on all OpenGL 4 hardware.
Despite that OpenGL and OpenCL heterogenous rendering and compute is suposed to be a big thing, I am not aware of any implementation supporting
A lot of new extensions turns out to be hardware independent extensions shwoing a desire for redesign of OpenGL from the ARB: Texture storage which kills texture incomplete issues, separate programs which break the requirement of linked shader stages or debug output which actually says that debugging is the duty of the implementation not the application.
I am a huge fan of transform feedback and I believe that there are still under used and to become really useful we need at least a way to store the data in something else than 32 bits floats or ints. Does it make sense to store a color into four 32 bits floats? Most of the time, no, it just consumes too much bandwidth. Nevertheless, AMD implementation had an early start to bring OpenGL 4 transform feedback as the entire feature set was already supported from HD 2000 series.
I often thought that it would be great to have #include with GLSL because what I really want to do most of the time is sharing structures for my varying and uniform blocks accross a maximum set of shaders. When I saw the release of ARB_shading_language_include, I was very exited at first but after reading it, I decided to stick to my home made methods: The extension make it so complex to use includes! Actually, there is still no sample in the OpenGL Samples Pack demonstrating its usage. Also, I am a C++ programmer and I mostly did C and C++ programming for all my professional life so far and even most of my education (I chose to forget the rest...). Speaking with others programmers used to others languages, it now appears to me that there are alternatives to #include so maybe we should consider something else for GLSL than something which already feels like an odd hack in C++.
OpenGL with its extension mechanisum provides a lot of flexibility for applications that can afford to spend this developer effort. The desire for an OpenGL 3.4 specification comes from the need of cross platform support and shared code across platform which is certainly not optimal for performance but allows to release an application for a lower developers cost. With this post written, we can build our own OpenGL 3.4 using OpenGL 3.3 and a set of shared extensions across AMD and NVIDIA OpenGL 3 hardware.