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.
the Fiddler's picture

Unfortunately, getting rid of all legacy functions is not really an option. However, what about this?

d) remove GL2.1 from the core, but ship it in a separate dll (e.g. OpenTK.Legacy.dll). Core contains only GL3.

Pros:

  • Keeps the core smaller.
  • Keeps specs easier to maintain (we've modified the current ones heavily and merging the new changes is not easy).
  • Gets rid of the obsolete Sgi enums littering the universe.

Cons:

  • GL2-level apps need to include 2 dlls.
  • Which extensions go to which dll?
Inertia's picture

d) Cons:
- is it possible at all to modify the binding generator to split the functions into separate namespaces|dlls, without creating a table for all ~1500 functions manually?

e) stick with b) for OpenTK.dll and write an abstraction OpenTK.Framework.dll ontop of it, which only uses GL3 functionality. The Framework's API could be somewhat similar to XNA's approach, which is built ontop of DirectX 9.

the Fiddler's picture

- is it possible at all to modify the binding generator to split the functions into separate namespaces|dlls, without creating a table for all ~1500 functions manually?
The generator actually takes the namespace as a parameter, so it's not a problem (it's also used for glu and wgl). It outputs simple .cs files which can be placed in projects as needed. Moreover, the namespace could even stay the same, provided common enums don't clash.

e) stick with b) for OpenTK.dll and write an abstraction OpenTK.Framework.dll ontop of it, which only uses GL3 functionality. The Framework's API could be somewhat similar to XNA's approach, which is built ontop of DirectX 9.
Good: 1 dll contains the core, just like now.
Bad: You don't get any compile-time guarantee that you don't call any invalid functions (GL2 funcs with a GL3 context).

The OpenTK.Framework.dll could also be layered on top of ideas (c) or (d).

f) Go completely modular. OpenTK.Graphics.dll for GL3, OpenTK.Graphics.Legacy.dll for GL2, user picks whichever they want. I don't see how's that better than rolling the GL3 stuff into the core though.

Inertia's picture

I think we may not lose sight of the difficulty to maintain the project, so a path that leads to making an upgrade to GL 3.1 (or whatever is next) more awkward would be a disadvantage.

Bad: You don't get any compile-time guarantee that you don't call any invalid functions (GL2 funcs with a GL3 context).
Let me be more precise about the Framework's definition (to give some basis for discussion)

  • The Framework would internally call all GL commands, OpenTK.Graphics is not needed. (But ofcourse may be included manually)
  • Matrices would be calculated by OpenTK.Math, rather than Glu.
  • You don't call GL.Enable&Co. at all. State objects would encapsulate several parameters that work together to describe OpenGL's state, similar to Long Peak's approach. e.g. A DepthBufferState instance would track parameters like GL.DepthFunc, GL.DepthRange, GL.DepthMask and GL.Enable(EnableCap.DepthTest).
  • The User will not see any Texture|VBO|Shader handles. e.g. if you want to create a new Texture, you instantiate a TextureObject.

(Ok, this is a poor design document to build the Framework from, but at least gives a better description of what I had in mind when mentioning the word.)

Like this, it should not be possible achieve any implicit GL2 call, without manually doing so by including the bindings and calling GL.IndexPointer or something like that manually.

So far I like a) and d) best. The Framework is just something I consider worth discussing as an option, but I believe most users don't want that kind of abstraction done for them.

nythrix's picture

g) How about namespaces that would directly map the GL profiles as specified by the ARB?

the Fiddler's picture

Something like GL21, GL30 and GL31 in a single dll? That was the original plan actually. What's the advantage of this over (for example) splitting the profiles on different dlls?

nythrix's picture

Should have been more specific there:
1) By namespaces I mean full separation of different versions (not really important if it's different classes, namespaces, dlls). The outline for these modules could be the OpenGL profiles that the ARB proposes. This way you don't have to deal with "where goes what" problems. Let The Board decide it.
2) The forward compatible context means core minus deprecated functions. And that's not the same as the full GL3 context (which still contains deprecated features). How will OpenTK reflect this?

GL2-level apps need to include 2 dlls.
Frankly, I don't think this is a big problem. If the application is updated regularly it'll probably switch to GL3 (no need for legacy). If it's not, than it won't need the new contexts (and two dlls) anyway.

Edit: To spice things up there's different behavior of non-deprecated functions that take deprecated values. While in a full context this will work, in a forward context the call will cause an error. Just blow off the whole deprecated stuff, I say :D

the Fiddler's picture

I see what you mean now and it makes sense.

From an implementation stand-point, I believe different profiles make sense as a compile-time distinction (different dlls for different profiles). I'll have to think a bit about the api, maybe try a few things on windows (ati/linux don't support GL3 yet) and see what comes up.

Keep the ideas coming, this is a significant design choice!

Inertia's picture

Not sure whether we should let the ARB decide what belongs into OpenTK and what doesn't. For example the PixelBufferObject Extension is redundant, because FBO was promoted to core. On many widescreen display resolutions you cannot render to a 1024^2 Texture with PBO. Imho it can rot in OpenTK.Legacy.dll, guess it's all about how you define "lightweight".

nythrix's picture

Not sure whether we should let the ARB decide what belongs into OpenTK and what doesn't.
Being in charge of OpenGL they actually DO tell what goes into OpenTK. If you don't follow the ARB you can't put the OpenGL sticker on this project.

As I understand it we can put every function of every OpenGL profile in one of these:
1) Profile.Core - future-proof functionality
2) Profile.Deprecated - contains deprecated functions and values that may be removed (or moved to Extensions) in the next version of GL
3) Extensions - functions falling out of profiles or yet to be added to them
This fully reflects the expected evolution mechanism of OpenGL and clearly states what goes into which part of OpenTK aswell.

Thus we have:
a) Only forward compatible GL3 context: Core + Extensions (safe usage)
b) Only full GL3 context: Core + Deprecated + Extensions (safe usage)
c) Both contexts and let the user deal with deprecated features. This is subject to runtime errors as in the example I mentioned in my previous post (accessing Deprecated in a forward context).