golkeeper's picture

OpenGL 4.1 support

Hi all!

I wrote graphical engine based on OpenGL 3.2 Core API some time ago. OpenTK was used for OpenGL binding and I really like it. Now, when OpenGL4.1 drivers are released, I'm about to start engine rewrite for OpenGL4.1, but OpenGL 4.1 support status in OpenTK slightly confuse me. Does OpenGL4.1 (with extensions) function signatures and constants present in OpenTK now? If not, may it be generated from .spec files?

On "Issues" page there are some issues named like "Add support for OpenGL 4.0 tokens", "[GL 4.0] Tessellation Shader" and so on. As I understand the problem is to update function arguments types and add new ones for new functions. Does this means that it is only problem and everything else may be generated from .specs? Does constants that needs to be grouped in function argument types and functions themselves already included in OpenTK source?
Although, there is issues about OpenGL 3.2 and 4.0 tokens, and nothing about OpenGL4.1 ones, why?

OpenTK source in SVN repo seem not to be updated frequently and recent updates is minor (as I understand) changes and bug-fixes, not related to modern OpenGL support. Maybe the_fiddler planned this to be done by OpenTK community? Or does this means that development is slowed down for any reasons? Some weeks ago I see post from guy, how tries to generate bindings for OpenGL 4.1 lib, I found no related commit in SVN. I'll be glad to dig into OpenTK too and join development in part of OpenGL 4.1 support, but a need to estimate complexity and scale of work before.

Thanks for your answers, I'm sorry about my awful english)


Comments

Comment viewing options

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

Stage 1 of the GL 4.1 cleanup is complete now.

@Rawn: you cannot tell beforehand on which platform the application will run. Solely OutOfMemory errors can happen at any and every point when allocating resources. So for example you cannot remove glBind*** safety checks whether a handle was generated beforehand with glGen***.
You may find more of this in open-source drivers, or contact an IHV for a better answer.

@golkeeper: I believe what Nvidia is trying to say: No matter what we do to VBO, we cannot make it faster and consume less memory than our highly optimized Display List compiler. ;)

@swiftcoder: static geometry is easy mode, what I was referring to is skeletal rigs deforming correctly using control points and displacement. Tbh the last time I've dealt with Zbrush was a trial for 2.0 quite some time ago, and back then your workflow was something like this: Build the first lowpoly model in a standard 3D modeller, import that into Zbrush as a base. Repeatedly subdivide the mesh, paint detail, subdivide, paint finer detail etc. . The biggest issue with this was that the final outcome of this process depended heavily on the quality of your original lowpoly mesh, ideally the whole mesh was quads and all quads would be somewhat same size to achieve best subdivision. When done with the highres mesh, export the model back into the standard 3D modeller, build a second -new- medium polycount model ontop of that highres model which will be used in realtime rendering which would then get UV unwrapping, receive normal map projection from the high res version of the first model and be rigged. The problem with this is, that any seams in the UV unwrap are very noticable in the normal map and it's also very difficult to rig it in a way that stretching of neck/shoulder/elbows/etc. looks good.
I just checked, there's no trial version for 4.0, have they changed Zbrush in this regard? I imagine the problem with the initial lowpoly mesh just gets worse with displacement mapping, with the "old" workflow described above, you can still take some steps to fix problems that come from a sub-perfect lowpoly mesh, but if the lowpoly mesh is actually what you will rig and animate in the end this must redefine the meaning of "far beyond extremely difficult"? I'd rather build the second model and project the highres one onto it, again.
All these complications are, why I asked whether there are better tools for this out there, yet ;)

tksuoran's picture

I am also very much waiting to get an updated version of OpenTK. So it is really good news that there may be a new version coming soon :-)

Personally I think the OpenTK binding creation should be fully automatic. I know, this would possibly mean that some enums were not possible. How about splitting OpenTK into one lower level binding library with the bare minimum OpenGL C# bindings that can be updated automatically, and a higher level library that adds the nice stuff? It has always somewhat bothered me that C# bindings are not strictly just OpenGL bindings, and I would find such split more comfortable.

One of the issues I've had with OpenTK is the DLL size. It's too huge compared to what I really need. Splitting into smaller DLL's would help. I also think that each API should be in separate DLL, not one huge one.

the Fiddler's picture
tksuoran wrote:

Personally I think the OpenTK binding creation should be fully automatic. I know, this would possibly mean that some enums were not possible. How about splitting OpenTK into one lower level binding library with the bare minimum OpenGL C# bindings that can be updated automatically, and a higher level library that adds the nice stuff? It has always somewhat bothered me that C# bindings are not strictly just OpenGL bindings, and I would find such split more comfortable.

Strong enums were one of the design goals from the beginning. The generator can generate Tao-style bindings, however.

Quote:

One of the issues I've had with OpenTK is the DLL size. It's too huge compared to what I really need. Splitting into smaller DLL's would help. I also think that each API should be in separate DLL, not one huge one.

The dll is 600KB zipped (or 400KB 7zipped), which is half the size of a 1024x1024 DDS texture. It's really not that huge in the large scheme of things.

I'm looking into splitting the various profiles into different dlls but this won't help reduce size. No really, I've tried it: the bulk of the code comprises of OpenGL extensions and chances are you'll have to pull that anyway. The difference between GL2 vs GL3 is something like 500 vs 150 functions, which might translate to ~30KB compressed.

If size optimization is what you are interested in, you will either have to compile a custom dll (which will be much easier after the dll split, admittedly) or use a static linker / obfuscator that can eliminate unused code.

tksuoran's picture
the Fiddler wrote:

Strong enums were one of the design goals from the beginning. The generator can generate Tao-style bindings, however.

I wonder if it would be possible to push strong enums into the GL spec files themselves.. ?-)

swiftcoder's picture

Pardon if this is a stupid question (or already answered elsewhere), but is there a way to manually load extension pointers in OpenTK? And to manually pass integer textension tokens in the place of strongly-typed enums? I really need just the tessellation functionality from OpenGL 4.0, so I was considering accessing it manually.

the Fiddler wrote:

Strong enums were one of the design goals from the beginning.

I would say that they are OpenTK's killer feature as well - it makes OpenGL development considerably less error-prone than *any* other environment I have used.

the Fiddler's picture
tksuoran wrote:
the Fiddler wrote:

Strong enums were one of the design goals from the beginning. The generator can generate Tao-style bindings, however.

I wonder if it would be possible to push strong enums into the GL spec files themselves.. ?-)

The specs used to list strong enums up till version 1.1 (the rest are all written by Inertia, me and several other contributors).

We used to add new enums directly into the specs but I'm now moving them into separate xml "override" files.

swiftcoder wrote:

Pardon if this is a stupid question (or already answered elsewhere), but is there a way to manually load extension pointers in OpenTK? And to manually pass integer textension tokens in the place of strongly-typed enums? I really need just the tessellation functionality from OpenGL 4.0, so I was considering accessing it manually.

Try updating gl.spec and enumext.spec(*) with the latest files from opengl.org. The generator should be able to consume those without issue or with some small massaging (the specs sometimes contain bugs or new properties not recognized by the generator - just comment those out if necessary).

The new functions will use enums called "Version40" or "Version41". You can also cast values from the "All" enum, which contains every single value listed in the specs.

(*)One warning: enumext.spec contains extra enums at the end that were added manually (scroll to the bottom, they are marked as such). Do not overwrite this file - instead, open it and paste the contents from the new version taking care not to overwrite the extra enums.

Edit: you can also specify the necessary function pointers manually (using delegates) and load the extensions with:

var context = GraphicsContext.CurrentContext as IGraphicsContextInternal;
FooBar glFooBar = (FooBar)Marshal.GetDelegateForFunctionPointer(context.GetAddress("glFooBar"), typeof(FooBar));
tksuoran's picture

According to the extension spec page, there is a plan - or at least idea - to eventually move the spec files to XML. This might be an opportunity to put strong enums back properly. We could propose a new schema for example.

Maybe one day the bindings generator could check the latest spec XML directly from Khronos page?

the Fiddler's picture
tksuoran wrote:

According to the extension spec page, there is a plan - or at least idea - to eventually move the spec files to XML. This might be an opportunity to put strong enums back properly. We could propose a new schema for example.

Maybe one day the bindings generator could check the latest spec XML directly from Khronos page?

That note has been on the specs page for at least three years...

The generator is actually using an xml representation internally. I am planning to split the generation process into two parts, from spec->xml and then from xml->C#, which should simplify things a little (ES and CL already work like this, going from C->xml->C#). The GL generator is older and is only using the xml files partially.

Writing a script that downloads and parses the specs automatically is not hard. The problem is that this is not very useful for OpenTK, which has to maintain an ABI (i.e. we cannot release a weakly-typed enum and then convert it to a strong type later on).

tksuoran's picture
the Fiddler wrote:

That note has been on the specs page for at least three years...

I know it is been there for a while. The intention has not changed, there just is too much other things to do, so XML has not happened yet. Like I said, if there would be a proposal for the new XML format, we might be able to get the strong enums back.

the Fiddler's picture

You can follow the work on OpenGL 4.1 by checking out the gl4 branch: https://opentk.svn.sourceforge.net/svnroot/opentk/branches/gl4