OpenGL 4.1 and 3.1+, What are key differences?

Question

I understand that OpenGL 4 and 3 are fairly similar, especially 3.1 and 4.1. With both being essentially released together, it can be difficult to understand the rationale for OpenGL 4.0/4.1.

In previous releases of OpenGL, minor version increments upward until substantial changes accumulated into a new major version. OpenGL 3.x and 4.x introduced backwards-incompatible API changes and then OpenGL 3.2 and 3.3 are said to be specifically branches of the 3 series which are not forward compatible while 3.1 is compatible with 4.1+

What key differences does OpenGL 4.1 offer compared with OpenGL 3.1 that warrant it to be classified under a new major version?

Bonus: Do any of the differences provide performance increases in any situations over GL3 or just accessibility?

Edit: Some extra findings based on answers

---

OpenGL 3.3 was made to compliment OpenGL 4.0 to incorporate as much of the functionality as they could into older hardware. Choosing between OpenGL 3 and 4, 3.3 may be a better choice sometimes. 4.1 has added GL ES 2.0 compatibility however and some nice features.

---

One of the bigger workflow differences would be added GPU programing steps in the pipeline via the new tessellation shaders. Another would be multiple viewports to render to. I believe the new level of detail feature would change the workflow I'm using and perhaps other quite a bit, though I have not looked into this feature in depth.

Please let me know if you see any misconceptions or areas to improve.

Keynotes (apparently removed from answer while asking on meta.. For temporary reference of what the actual answer was.)

Appendix G - K For OpenGL 3.1 features through OpenGL 4.1 features

Khronos Group Release Of OpenGL 4.0 may be "easier to read" :)

• Sampler Objects
• Instanced Arrays and Shaders

• texture_cube_map_array and texture_gather

• GLSL 4.0 and dynamic LOD

• shader_subroutine and sample_shading
• separate_shader_objects
• Increase required sizes for texture/renderbuffers
• 64 bit floating point vertex attributes
• get_program_binary
• +2 Tesselation shaders

Solution

If your question is "How can the workflow be better in 4.1", that's simply not what 4.1 is about.

First, a quick definition, to make sure we're talking about the same thing. For me, "workflow" means API improvements and things that make performance better. These don't allow the hardware to do anything you couldn't before; they just make it easier for the programmer or let you get faster performance.

The vast majority of the API improvements, the ones that aren't based on new features, are available to 3.3 implementations as core extensions. Since they are core extensions, you don't even have to change your code to remove the "ARB" suffix from your 3.3 code to use them in 4.1 code. It all just works. In particular, I'm talking about program separation (GL_ARB_separate_program_objects) and retrieving binaries of compiled programs (GL_ARB_get_program_binary). Both are supported on 3.3 hardware; NVIDIA even extends these all the way back to GeForce 6xxx chips.

The main exception to this is shader subroutines, which is limited to 4.x hardware. However, this specification is so poorly specified that I'm not sure that anyone even can use it, let alone should. It is convoluted and somewhat confusing.

There isn't much that one could easily use to boost performance that is unique to 4.1. Bindless rendering (GL_NV_vertex_buffer_unified_memory) is probably the biggest performance enhancement if that is a bottleneck for you. As you probably noticed from the name, it is an NVIDIA extension and not core. I'm sure the ARB is working on something not entirely unlike this for a core feature in a future spec. And Bindless isn't unique to 4.x hardware; again, NVIDIA extends this all the way back to GeForce 6xxx chips.

There are some things in 4.x that can enhance hardware, but they all ultimately revolve around some form of GPGPU work. Indirect rendering (GL_ARB_draw_indirect) would be a good speedup if you are generating rendering data from OpenCL. And Civilization V has already shown the value of using GPGPU technologies (they use DXCompute, but you could do it with OpenCL too) to decompress textures; this helps tremendously in loading performance, as you don't have to load as much data from disk.

If you want to really stretch the definition of performance improvement, Tessellation could be considered a performance enhancement. You could use it to send smaller meshes, or use your lower LOD meshes closer to the camera. Or you could consider it a way to render higher polygon meshes than you ever could before.

4.x really isn't about providing hardware features that make things go faster. It's more about being able to render in different ways than you could before.

And one more thing: there isn't a choice between 3.1 and 3.3. Pretty much any hardware that could run 3.1 can run 3.3. If it doesn't, then that's because the hardware maker is slacking off on their OpenGL drivers (I'm looking at you, Intel).

Comments

[That Realty Programmer Guy]

"4.x really isn't about providing hardware features that make things go faster. It's more about being able to render in different ways than you could before." When I'm talking about workflow this is what I'm after. If you are building a render system from the ground up, there should be a different point of attack that makes life simpler.

[Nicol Bolas]

Not really. Not for OpenGL 4.x. Like I said, the biggest convenience features are program binaries and separation of programs. And neither of those are restricted to 4.x hardware. So I stand by my conclusion: there's nothing that will affect your rendering system in OpenGL 4.x that "makes life simpler".