nythrix's picture

GL3 forward compatible context

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.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
objarni's picture

On a side not (feel free to ignore):

I think "future proof" is a bald statement ... How do you know it is future-proof? Rather, it is "the latest development" or "state of the art".

I would agree with "future proof" of things like integers, floating-point numbers and vectors. Anything more hardware-related is hard to "future prove".

Eg. Don't you think the original OpenGL API designers thought Vertex3* would be "future proof"?

nythrix's picture

Sorry for being vague. By "future proof" I mean "will be in the next GL version". That applies to every non-deprecated core feature. You're right in that we can't assume anything else.

Kamujin's picture

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.

Inertia's picture

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:

  1. Why are we splitting OpenTK.Graphics at all? 1 Namespace worked so far.
  2. Why now and not wait for GL 3.1?
  3. 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)?
  4. 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?
  5. Difficulty to maintain the generator and .spec should not be neglected?
  6. How well does the solution respond to manual fixes, e.g. adding inline documentation by hand?
  7. 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.
objarni's picture

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.

Inertia's picture

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.

objarni's picture

Cool.

Actually if it is not available anymore - it would be a great OSS project to develop such functionality!

Tell me, in the ShaderGen program - were you supposed to use things like glLight* anyway, even though you had "rolled you own pipeline"?

the Fiddler's picture

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.

Edit: Late reply... :)

objarni's picture

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?

the Fiddler's picture

You can implement FF transform, lighting and (multi-)texturing with surprisingly few lines of shader code. In general terms, shaders let you replace the math of the OpenGL pipeline.

Writing a shader != implementing the OpenGL state machine, by several orders of magnitude.

Edit: fixed function is actually emulated through shaders on recent hardware (R300+, NV40+).