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

I just wanted to post here that this is not being ignored, but simply low priority. Only you have requested support for this so far. Even the big commercial studios develop for DX 9c hardware, so asset creation cost is lower and consoles can be targeted aswell. It will inevitably be added though.

Meanwhile I have some questions regarding GL 4.1

  1. What's the intent of the multiple-viewport extension? Do lighting and e.g. shadow maps in a single draw call?
  2. Would you like to see some class in OpenTK that handles GLSL binary format detection/load/save or do you prefer to roll your own?
  3. Are there any tools out there, which can export 3D models for usage with that DX 11 tesselation shader extension?
golkeeper's picture

Thank you for your answer.

OK, I see it's low priority task for you, but not for me. So I'll be glad to do it by myself, but there is still no answers for my questions 'bout OpenGL 4.1 bindings generation. Although It is interesting for me to get a post from the_fiddler, especially on the OpenTK development and support.

Inertia's picture

Yeah sorry, I dodged that because there is no simple answer to it and every time we did update to a new GL version, we found gremlins or desireable features that needed to be addressed at the generator source code, and that is why it's a non-trivial task adding GL 4.1 (also 4.0 and 3.3). No offense, but it will cost considerably more time teaching you how to make all the modifications than simply doing them.

While waiting for Fiddler's input, feel free to comment on my questions or explain what makes GL 4.1 a priority for you.

Edit: Nvidia just released slides from the GPU technology conference 2010 and indirectly answered all questions. Thanks ;)
http://www.slideshare.net/Mark_Kilgard/gtc-2010-opengl

the Fiddler's picture

4.1 support is coming. I tested the generator as soon as 4.1 was announced and it consumed the new specs quite well. However, the released spec files were incomplete at that point so it didn't make any sense to devote any more time on that.

I've spent the last month working on less visible stuff (tests for faster extension loading, better debugging, a new build server and build process) and we should start getting results by next week or so. I've also working on a few features to make new specs easier to support.

What we are missing now is a cleanup of the new 4.1 functionality in the essence of the 3.3/4.0 enums that are in the bug tracker.

Rawn's picture

I have a slightly off-topic question about post-3.3 support: How will you handle Core- and Compatibility-profiles in the Toolkit?

I for one would like to be able to separate these, on a programmatic level. Perhaps a namespace for Core and an additional namespace, Compatibility, with only the now deprecated functionality. Preferable in separate assemblies.

Inertia's picture

GL 4.1 cleanup should be complete by the end of the week(end), I need to cross-check some enums with the GL 4.0 cleanup to ensure we are not creating unnecessary duplicates.

Rawn, there are several lengthy discussions in the forum regarding this, but in short we agreed not to take any actions regarding core and compatibility. In practice, applications will encapsulate the low level GL calls into a class, and after that it's not transparent anymore whether you're using comp. or core anyways. OpenTK 2 will go that road (look for keyword "GLOO", and/or CLOO and ALOO) which will be a lighter API with core features only. (lowlevel access is not going to disappear, we provide both)
What we have atm is automatic error checking when doing Debug builds. This helps alot to find any invalid functions/tokens, when using a core profile. IIRC this is the only action we are taking regarding deprecation.

Note: In the presentation linked 3 posts above, Nvidia does recommend to use compatibility - NOT core - profile in your applications! It's a misbelief that core profile will be any faster, in contrary: the additional "is this allowed?"-checks can cause the core profile to be slower. I have no written proof for it, but it's very likely true for Ati's drivers, too.

Rawn's picture

Thanks for the fast and lengthy reply. I look forward to OpenTK 2.0 then. I will take a look at GLOO for now and see what it is about. Again thanks.

Note: I have never held any beliefs about performance differences between the profiles, nor have i particularly cared. If i cared about every little percentage of performance, i would never have looked at OpenTk to begin with. I do think however, that using the core profile will make your code look a lot cleaner, something i care a great deal about.

Why would the core profile be slower however? Why would you need to make those checks at all? From an engineering standpoint it seems... unnecessary. Isn't it something that should be decided on header/library level and discarded by the compiler if it differs? I.e if i was using C++ and added the coreGL header file, that would be enough to make sure i couldn't call anything deprecated. No extra run-time check would be necessary. The same should apply to OpenTK. Namespaces are resolved at compile-time.

the Fiddler's picture

Gloo is not ready yet but it is coming together. I'll make an announcement once it becomes ready for testing.

I'm actually adding the facilities to make a split between OpenGL profiles possible. I don't know how far I should take this, but at the very least you should be able to compile a custom OpenTK version that contains only the profiles you need. I'm still weighting our options.

golkeeper's picture

Thanks for good news, I'm glad to hear that OpenTK is alive!

Inertia wrote:

While waiting for Fiddler's input, feel free to comment on my questions or explain what makes GL 4.1 a priority for you.

OpenGL is interesting for me in general, cause I have a hobby - graphical engines, and I rewrite my one with each major change in OpenGL. Last one I wrote uses OpenTK and OpenGL 3.2 and is written on C#4.0.
In OpenGL 4.1 I especially wait for debug output extension and 64bit vertex attributes which allows me for example to render star system and galaxies using one global coordinate system.
Now I was about to choose what to do - go back to C++/SDL or dig into OpenTK Generator code, but if you are going to done with OpenGL 4 in a week, I have no doubts :)
Also I'm surprised that this task have no priority for you - recent versions of OpenGL is popular, there is a lot of news, rumors and noise in WWW about them. All this can draw a bit of public attention to OpenTK if you declare latest OpenGL support, cann't it?

Inertia wrote:

Edit: Nvidia just released slides from the GPU technology conference 2010 and indirectly answered all questions. Thanks ;)
http://www.slideshare.net/Mark_Kilgard/gtc-2010-opengl
Nvidia does recommend to use compatibility - NOT core - profile in your applications!

Too few new nice renderings in comparison with last presentation :(
And indeed, as in last presentation NVIDIA again declare that core profile as slow profile..
IMHO NVIDIA actually says: we done no clean and new core profile for now, but make a wrapper on the top of old profile. So current core implementation is temporary and it cann't be faster then compatibility profile even in theory. But I belive potentially it may be optimized mach better. And will be, in other case there is no reason for it to be. I hope in future code of different profiles would be separated.
Also note all this relates to NVIDIA drivers.

the Fiddler wrote:

I'm actually adding the facilities to make a split between OpenGL profiles possible.

It would be great! Waiting with impatience :)

swiftcoder's picture
Inertia wrote:

I just wanted to post here that this is not being ignored, but simply low priority. Only you have requested support for this so far. Even the big commercial studios develop for DX 9c hardware, so asset creation cost is lower and consoles can be targeted aswell. It will inevitably be added though.

Add my voice to those requesting OpenGL 4.0 support at least - and 4.1 support wouldn't go amiss.

Quote:
  1. Are there any tools out there, which can export 3D models for usage with that DX 11 tesselation shader extension?

Any displacement-mapped model can be used for tessellation, so ZBrush, etc. are perfect for it. However, I find the tessellation support is much more interesting with respect to terrains and environments...