I'm glad Inertia mentioned this:...
But there is also a big decision coming with GL3. Forward compatible contexts.
The way I understood the manual, a forward compatible context will generate invalid-operation errors whenever you call e.g. glVertex3f(). The solutions I see for this are
a) Use compiler conditionals to compile OpenTK either against GL 2.1 or GL 3.0
b) Don't do anything at all. Let the user sort out what's allowed in GL3+ contexts.
c) completely remove legacy extensions and functions. Set GL3.0 as standard.
...
See: http://www.opentk.com/node/490#comment-2414

The discussion definitely needs it's own thread. From my point of view (1/3 way to alpha, mid-sized project) I would very much prefer number three. It will probably break almost all of my code but I'd rather fix a bunch of syntax errors than a single runtime one.

I really haven't had much time to look at OpenGL 3 so please forgive my uninformed statement.

As a general principle, I think this project is young enough that it should not overly encumber itself with backwards compatibility issues. There will be plenty of those once it hits release state. Therefore, I am in the more pain now, less pain later camp.

Just noticed that I should probably clarify that whenever I said GL2.1 in the scope of this discussion, it was actually referring to complete OpenGL 1.2-3.0. (Imho OpenGL 3.0 is basically 2.1 with Extensions promoted to core, which you could use with OpenTK and latest Nvidia cards for over 1 year already.)

A "normal" OpenGL 3 driver usually supports features all the way back to it's roots. A "forward" OpenGL 3 driver might chose to implement only a small part of the "normal" driver's functions. To my knowledge no such drivers exist, but I expect this to become interesting for future consoles, or for a new graphics chip company that enters the business (since a "forward" driver will take months to implement, while a "normal" driver will take years).

My distinction in the usage is like:

GL2.1 - Fixed function rendering, with Shaders being an option. Tons of legacy Extensions which will only run on computers you find in museums.
GL3.0 - Shader based rendering. Without deprecated features which became obsolete due to better available choices like GLSL, VBO and FBO.

Note: this is not "official" or anything. Do not quote it -.- Just trying to clarify where I draw the line.

------

Maybe we're approaching this from the wrong direction.

Some things to consider:

Why are we splitting OpenTK.Graphics at all? 1 Namespace worked so far.

Why now and not wait for GL 3.1?

How many users are interested in programming against "normal" vs. "forward" contexts? How many would like to support hardware that cannot run OpenGL 2.1 or higher (i.e. where shaders-only won't work)?

Should the binding generator be adjusted to output to several namespaces, or rather 1 namespace and let the user decide through compiler conditionals which subset of functions will be included into the .dll?

Difficulty to maintain the generator and .spec should not be neglected?

How well does the solution respond to manual fixes, e.g. adding inline documentation by hand?

How about building a Framework ontop of OpenTK, rather than splitting the bindings? Kinda related to 3. because there's no point in it if noone uses that.

I for one am going to use "classic opengl" in the foreseeable future (say next two years). I don't know GLSL or other "modern" rendering techniques, nor do I feel the pressing need for it in my area (CAD visualization, small games/editors/viewers). That is to say - I'm not planning an AAA game using OpenTK.

I can also see the good stuff from shaders-based-rendering, more flexibility and higher control, of course, and I for one have been pissed off more than one time by the intrinsics of the OpenGL API (it is trying to do too much! Too many levels / things / concepts).

But implementing all lighting,texturing,filters etc. etc. in shaders is a big job for a single developer - so many "old projects" with the old OpenGL machinery will stay alive _at_least_ ten years.

So for me personally it is not a black-white situation.

But I know one thing - skipping the OpenGL roots will kill this project - that is my sincere belief - so you will have to adress this issue thoroughly.

Don't worry, fixed func is not going to disappear. Hopefully we can agree though that programmability of pipeline stages is not a "trend" that dies tomorrow and OpenGL goes back to fixed func. As developers it's our responsibility to make sure OpenTK does not ignore the future, there's many shades of gray between pong and AAA "ultra-realism". With GLSL you can decide which shade is your preference, with fixed func you are stuck.

Porting from fixed func to GLSL was actually really easy when 3DLabs ShaderGen was still available. You'd just select the fixed func states that the shader should consider and the program would return you GLSL source code. This program was actually what convinced me to abandon fixed func and learn GLSL, no clue what happened to it - all links to it appear dead.

This is about OpenGL itself evolving. GL3 deprecates and replaces most of GL2 with a leaner API (GL3 core is ~80 functions vs ~500 in GL2) and most of us consider this to be a step in the right direction. Indeed, the biggest complain about GL3 is that it didn't bring the promised object model - it wasn't nearly revolutionary enough.

That's not about AAA stuff either. A simpler API is easier to implement (better drivers), easier to learn and easier to use. This should have been done a long time ago, too (2003 with GL2). There's a good reason why most devs have since left for D3D a long time ago (hint - hardware evolved, OpenGL didn't).

But implementing all lighting,texturing,filters etc. etc. in shaders is a big job for a single developer - so many "old projects" with the old OpenGL machinery will stay alive _at_least_ ten years.
That's simply not true. Duplicating the fixed-function pipeline doesn't take more than a day (and that includes learning how to work with shaders).

That said, don't worry deprecated functionality isn't going away neither from drivers nor from the library. You'll be able to use it, even if it's not a terribly good idea nowadays.

Me: But implementing all lighting,texturing,filters etc. etc. in shaders is a big job for a single developer - so many "old projects" with the old OpenGL machinery will stay alive _at_least_ ten years.
Fildder: That's simply not true. Duplicating the fixed-function pipeline doesn't take more than a day (and that includes learning how to work with shaders).
--
Um. I just don't get this - how can it take a mere day to duplicate something that supposedly takes *months* for driver developers to get right?