The advantages of GL3/GL4 core contexts

[hendu]

Avoiding to derail the 1.8 release thread.

Things you gain only with a recent core context:
- immutable textures (may allow the driver to optimize texture reads better; conservative estimate would be no change to 10% at most)
- the compute stage (a whole new way to interact with the graphics pipeline, easier than using gpgpu separately. Requires very new hardware.)
- cleaner API -> less GL calls

The list of things you can use from GL 2.1 via extensions if your hw supports it is pretty long.
- texture arrays
- conditional rendering
- subranges
- half floats
- transform feedback
and so on.

Downsides to using a core context:
- minimum hw requirement goes up. With extensions you can treat them as optional features and run on lower hw with less effects.
- worse GLSL syntax (personal opinion)
- forcing everyone to rewrite basic shaders and matrix math

These lists may be incomplete.

[Mel]

- forcing everyone to rewrite basic shaders and matrix math

So, what does this mean?

[hendu]

It means that in pre-core GL, you could draw a solid or simply shaded model without having to write a shader. In core GL, you have to write a shader for everything, including simple passthrough things that didn't need one before. Pointless duplication of work.

The other part, matrix math, was removed in core GL. So now you have to code all matrix math client-side, or use some matrix math library to do it for you. In pre-core GL, matrix math was built in.

[Mel]

I read somewhere that the glTransform() wasn't useful any more, is that?

[bvanevery]

It means that in pre-core GL, you could draw a solid or simply shaded model without having to write a shader. In core GL, you have to write a shader for everything, including simple passthrough things that didn't need one before. Pointless duplication of work.

The other part, matrix math, was removed in core GL. So now you have to code all matrix math client-side, or use some matrix math library to do it for you. In pre-core GL, matrix math was built in.

This is the future of the 3D graphics industry however, and has been so for a good while now. More recent GLSL isn't just about nicer syntax. It's about what developers are going to keep maintaining as content, going forwards.

I don't believe that driver writers are going to do a good job implementing and debugging 3.x 4.x targeted extensions for 2.x contexts. I've never seen the graphics industry work that way. If you're not on the main path of expected case uses, things blow up. That means customers screaming about why your game is not working, and pointing fingers at you the developer when it's really some underlying device driver weirdness. So I can't even accept "on principle" that using 3.x 4.x features via a 2.x context is a good idea.

[hendu]

If the driver fails, then you point the finger at the driver vendor and be done with it. I disagree that using extensions makes you any more vulnerable to this, as crappy drivers fail even using basic functionality (case: Intel).

I don't believe that driver writers are going to do a good job implementing and debugging 3.x 4.x targeted extensions for 2.x contexts.

That very much depends. For most things there simply isn't anything that could break depending on the context version.

[bvanevery]

If the driver fails, then you point the finger at the driver vendor and be done with it.

Not in the real world. In the real world, the customer is pointing at you and you suffer the economic impact. The driver vendor is unlikely to respond in any timeframe that matters to your business, especially if you are pursuing 2.x contexts for 3.x 4.x targeted capabilities. It's not their testing path and nobody in industry is really going to produce infinite amounts of unit testing for your choice of weird configuration. You play towards the center of design of industry, or you take your lumps.

I disagree that using extensions makes you any more vulnerable to this, as crappy drivers fail even using basic functionality (case: Intel).

The difference is when you pursue "right and expected" contexts, over time those bugs actually get shaken out. You do something weird, then nobody cares and it's going to be your problem forever.

[hybrid]

While most of the simple tutorials tend to use the simple approach of using the new layout, all major examples still have to use the extension pattern. Whether this uses one or the other context is not important. But you usually cannot rely on any specific OGL version, since the speed of progress is too high in the last years. If you want to support a newly provided feature, you're almost forced to use extensions, as you have to rely on the most recent OGL versions (4.x) otherwise. Almost no company will have a certified 4.x driver within the next 2-3 years, as you have to wait for the typical update cycles. I'd expect a slow movement towards 3.x taking place right now. OGL 4 will take at least two more years. Maybe the current trends in OpenGL-ES will even let the companies wait for the actual developments and maybe skip OpenGL in favor of OGL-ES 4.x at that time.
But coming back to OT, let's summarzie Irrlicht's situation as follows: You can use Irrlicht with any OGL driver available on your system, so it's compatible in this sense with OGL 1.x to 4.x. There are a number of extensions (most of them now part of 3.x or 4.x profiles) which cannot be used easily with Irrlicht, as the required vertex layouts or buffers are not provided. But a much larger portion is either already available, or can be used by providing the necessary function calls. And a testbed for the FVF pipeline is already established and being developed, so in the end we will have everything available. Both as extensions and on the native contexts.

[bvanevery]

You can use Irrlicht with any OGL driver available on your system, so it's compatible in this sense with OGL 1.x to 4.x.

What happens when a driver offers only a 3.x or 4.x core profile and no compatibility profile?

[hendu]

No such driver exists, as not supporting the legacy apps of 20 years would be market suicide.

[bvanevery]

Ok, Irrlicht with a 3.x 4.x compatibility profile will work. But that doesn't mean trying to use Irrlicht with features intended for a 3.x 4.x core profile, via a 2.x context, is going to work. So the question seems to be Irrlicht "as it is" vs. what will be done in the near future.

[hendu]

But that doesn't mean trying to use Irrlicht with features intended for a 3.x 4.x core profile, via a 2.x context, is going to work.

I guess we'll just agree to disagree. It works fine for me.

[bvanevery]

But that doesn't mean trying to use Irrlicht with features intended for a 3.x 4.x core profile, via a 2.x context, is going to work.

I guess we'll just agree to disagree. It works fine for me.

"Works fine on my box" is the scourge of engineering. Far more important whether it works in installed deployments nearly everywhere. I don't know what the present circumstances of Irrlicht are in this regard, and perhaps nobody does, but I think I'll restrict my attention to the code path that is in fact 3.x 4.x oriented.