Hi all,
I had started OpenGL coding 10 years ago for several years, and then, I quited graphics programming. Nowadays, I returned to graphics sector again, and what i see is coding OpenGL has changed in a strange and complicated way.
Previously, it was easy to learn, simple to write, and fast to develop for graphics applications, and the better part was its simplicity over D3D.
My question is:
Why do people want to remove the old API part, which made openGL a better choice at that time?
OpenGL 3+ version is not as simple as previous API at first sight. (no matrix operations, no transformations, etc. )
Thanks
First of all, being a better choice at some time doesn’t mean to be the better choice later. That’s especially true for graphics programming and graphics hardware.
Second, no one is telling you to forsake fixed-function coding style, GL2 paradigms and so on. NVIDIA and AMD fully support the compatibility profile which basically garantuees functionality dating back to before you started graphics programming. If you want to use immediate mode, if you want to use FF gouraud shading and so forth, feel free to do so. Still, no one serious about OpenGL programming can suggest to you that ignoring recent developments is a good idea.
Third, matrix operations and the matrix stack have been dropped, yes. But that doesn’t mean anything - if you wanted to really do matrix math in the past, you’d have had to exploy a third party library or your own functions anyway. Implementing a matrix stack is 1-2 days of work. And there are plenty of well designed math libraries out there which allow for almost anything you could ask for in graphics programming, most notably GLM by board moderator Groovounet.
Forth, no transformations? You are aware that shaders give you complete freedom to affect the orientation and position of every single vertex in the scene in almost all thinkable ways, right? This goes hand in hand with my first and second point. Ten years ago there were no shaders, register combiners maybe, assembly language programs maybe but no shading languages and compilers near as powerful as what we have today. Please pardon the language, but dude, you absolutely gotta learn about shaders.
Why do people want to remove the old API part, which made openGL a better choice at that time?
For many reasons.
The fixed function pipeline often gives the illusion of knowledge. For example, all of these questions represent persons who think that they know how OpenGL works, but don’t. In reality, these people have been copying and pasting code in all of their projects, and now suddenly, they want to do something different that there’s no code to copy from. Or their mass of conflicting copy-and-paste code has resulted in a bug.
You cannot get that with shaders. If you’re using shaders, you have to know how they work.
Another thing is that shaders are much simpler than the various fixed-function state to actually understand. Shaders spell out in meticulous detail exactly what’s going on. They’re programs, written in a C-like language.
They’re not some conflicting mass of global enables and state that could be set from anywhere in your code. To know what happens when you render with a shader, all you need to know is what uniforms were given, what textures were bound, and what attributes were passed. Some of those bugs I linked to came from not setting some arbitrary piece of state to enable some thing in order to cause some effect to happen.
Dealing with fixed function can be painful unless you know every detail about how it works. How TexEnv works. How the lighting works, and what the lighting computes. How to feed data from lighting into TexEnv. How to feed texture coordinate generation into TexEnv. Using crossbar to change the order of things. Etc.
Once you understand shaders, they’re a lot easier to work with than fixed-function. Oh, they don’t hold your hand. They don’t allow you to use lighting without knowing the algorithm behind lighting. But that too is a benefit, because it requires the person to at least minimally understand what’s going on.
I wrote the tutorial in my signature as a way to help people over that hump.
I agree there were very nice features in the old API (AKA compatibility API) that you already mentioned. However, video hardware changed, fixed pipeline becomes ancient, and the API needs to catch up with the new hardware.
Now what next? I anticipate no API very soon, just let the CPU giants create a super CPU and problem solved! Remember the FPU Emu era? or even the Phyics hardware? All done in CPU.
So what I expect no need for an API, shading is doe in your standard programming pipeline.
Yes, GL 1.1 was a easy API to learn but not successful in the Windows market. D3D was a better success because it represented what the hw can do. D3D was guaranteed to be fast.
I’m not gone give a full lesson here, but matrix functions are not done by the GPU and neither are the matrix stacks. Therefore, it belongs in an external library such as GLU or something else. PS : GLU is dead so you need to use somthing else.
Anyway, to each his own. Use GL 1.1. If your objective is not to make a high end game, then 1.1 does the job.
Curiously, GL3 is not a big success either. Most games use DX9 OR 10 OR 11. Perhaps GL will never take over that market. However, GL ES 1.1 has been a big success. GL ES 2.0 is big too and does away with fixed function.
glMatrixMode()/glMultMatrix()/glPushMatrix()/glPopMatrix()/etc. have never been the part of GLU!
What is done on the GPU is not the predominant factor. Many functions are still executed on the CPU side.
The main advantage of the “new” approach is flexibility. Everything what is done with fixed functionality can be done by shaders, but the opposite is not (and never will be) the case. On the other hand, using shaders and leaving to programmers to implement their own functionality enables lean and more optimized implementation of the drivers (at least it could be if the core functionality take precedence in the optimization).
Honestly, the learning curve is now steeper, but when you come to any serious problem you’ll find that without shaders many of them will be hard or even impossible to solve.
API does not matter now. It did before, at least to me, when GL 1.x was a very straight forward and “clean” compared to another competitor.
But now APIs almost compete on the same ugliness in order to take advantage of the new HW and how it works.
But who cares? I mean you can abstract your graphics rendering path on top of whatever API or even your own software renderer. Then you make the switch trivial and transparent.
And I quote myself here: “My graphics API of choice is C++” - glfreak 
I have never said it is part of GLU. I am using the word “belongs” in the sense that it should have been in GLU or some other library.
Which functions are done by the CPU? Sure, there are functions for setting things up and then you fire a “Draw” function call but those don’t exactly count.
I would say that it is a major factor. D3D’s ideology has always been to be a thin layer between your program and the hardware. GL3 seems to have picked up the same concept but not too well since nvidia and AMD still implement there “compatibility” profile.
Although that is true, the same can be said about GL 2.0. So, it isn’t something specific to “core profile”.
Probably. I saw some article that compared the core profile with compatibility on a nvidia and there was a 5% speed advantage.
But it isn’t just about flexibility and speed. It is also about simple and stable drivers (I hope).
Do you have any links to that comparison ? The last info I saw on that subject from Nvidia said that compatibility is always at least as fast if not faster than core, but that info is already a year old.
(http://www.slideshare.net/Mark_Kilgard/gtc-2010-opengl, page 97)
Core profile being slower than compatibility is only the fault of the driver developers as they did a quick and dirty implementation of the core profile by adding another wrapper to the functions and check for the added restrictions of the core profile there.
If using only core features, core profile should have the very same speed as compatibility, and using compatibility features will be slower in most cases than their core equivalents.
Maybe today it is not yet the case, but I wouldn’t use it as an indication about future performance. If you really need ultimate performance, use core features only, that’s what the hardware really supports (at least in 99% of the cases). Compatibility features are really nothing more than something that could be done with a 3rd party library built on top of OpenGL.
I don’t dispute that future drivers or graphics cards may drop hardware support for compatibility-only features, but Nvidia claims to support them in hardware in the current generation GPUs, having at least equal or sometimes better performance than the equivalent rewritten core code.
Vendor’s performance claims have been wrong in the past, and a benchmark can’t run on hypothetical future GPU’s so I was just interested in seeing some actual numbers.
I didn’t say that vendors will not support compatibility features, I said that they are actually done in “software”. It is hardware accelerated, but even fog, fixed function lighting and all other deprecated features are actually done using shaders. In fact, they were done so for a long time now.
We are not talking about hypothetical future GPUs, we are talking about the last 5 year’s GPUs. These don’t have hardware for almost any of the fixed function stuff. Those are just emulated by driver magic, nothing more.
I didn’t keep the link anywhere. I think it was on gamedev article and the person admitted that he didn’t render anything extensive.
I found that slide while searching. I also found that post in the Linux forum about core being slower than compatibility.
Is this something that has been properly tested? Is it slow on Windows as well?
We are not talking about hypothetical future GPUs, we are talking about the last 5 year’s GPUs. These don’t have hardware for almost any of the fixed function stuff. Those are just emulated by driver magic, nothing more.
One bit worth noting: most of the time if a driver implements a bit of FF, it will do a better job than one would do implementing oneself on top of a shader only API. Makes sense as the GL implementation has greater access to the gizmo.
[rant]
Along those lines, GLES2 had an epic brain fart: it does not have user defined clipping planes (be it via gl_ClipDistance or old school gl_ClipVertex), likely because someone said “just us discard” instead… with no realization that hardware clipping is SOOOO much better than hackey clipping via discard… hardware has to clip anyways to something that looks like user defined clip distances of -1<=clip_z<=1
[/rant]
On another note I really, really wish people would not call them “GL drivers”… it totally borks the mental image of the jazz in my eyes. I’d prefer to call it a GL implementation… the reason being that a driver implies something simple and low-level “feed these bytes to the device to make it beep” where as a GL implementation really is a renderer (different rendering strategies, etc)… not to mention all the other stuff it has… like a compiler.
I would rather say that this is true only if there is also FF hardware behind it. I agree that sometimes the driver writers are really able to optimize certain use cases better, but in general, unless there is also FF hardware behind the thing FF API vs programmable one is more of a limitation than a feature.
I would rather say that this is true only if there is also FF hardware behind it. I agree that sometimes the driver writers are really able to optimize certain use cases better, but in general, unless there is also FF hardware behind the thing FF API vs programmable one is more of a limitation than a feature. [/QUOTE]
I’d go 50/50.
If you’re trying to write a fully featured FF-replacement shader yourself (or if the shader you’re writing is starting to veer in that direction) then you should definitely stop and ask yourself “does the driver actually do this better?”
On the other hand, you know your own program better than the driver does. The driver needs to make fairly general assumptions for the sake of flexibility, conformance and invariance rules, but you can probably do better. You know your data sets, you know the operations you want to perform, you know the operations you can afford to skip, and you should be able to pull out better performance by rolling your own with specific reference to your use case requirements.
They’re two extremes and any individual case is more likely to be somewhere in the middle. In that case I doubt if the performance difference is going to be anything other than marginal (your main bottlenecks are almost certainly elsewhere), so what should tip the decision is your general code architecture and personal preferences.
Unless you are AAA title maker, in which case driver knows your program pretty damn well too.
I didn’t keep the link anywhere. I think it was on gamedev article and the person admitted that he didn’t render anything extensive.
I found that slide while searching. I also found that post in the Linux forum about core being slower than compatibility.
Is this something that has been properly tested? Is it slow on Windows as well? [/QUOTE]
For an embedded system I’m working on under Linux, we still get slower performance with Core profile than with Compatible profile.
Compatible profile (4.1.1161 driver) 115 fps.
Core profile (4.1.11161) 93 fps.
As we’ve already concluded, the AMD developers have most probably implemented the Core profile above the compatible profile, with additional run time checks. This is why it’s slower.
They’re two extremes and any individual case is more likely to be somewhere in the middle. In that case I doubt if the performance difference is going to be anything other than marginal (your main bottlenecks are almost certainly elsewhere), so what should tip the decision is your general code architecture and personal preferences.
Examples of where FF is better on modern hardware than programmable:
- [li] Alpha test (many GPU’ have a dedicated bit for that) [] “Built in primitive types” vs “Using a geometry shader”, for example GL_QUADS and GL_QUAD_STRIP[] Clipping vs discard[] image format conversion (there is hardware out there with that have FF image conversion jazz, usually on top of and separate from the GPU though)[] filtered texture look up and gather (witness all the texture look up functions that can be “implemented” with unfiltered texture lookup).
The first is a minor improvement on desktop, but can be notable on embedded. The 2nd can be a big improvement on desktop. The 3rd is a HUGE freaking difference. The 4th is sometime pretty critical on embedded, and the last is huge everywhere.
So yes it depends, but for common uses (such as the above) dedicated FF is likely better. For other things (like texture combiners ala days of GeForce3) I am all for programmable interface.
Clipping is supported in the core profile. Only gl_ClipVertex has been removed from core, but gl_ClipDistance has not.