the Fiddler's picture

The Open Toolkit library 1.0 rc1

With the almost 4-year long development cycle drawing to an end, OpenTK 1.0 rc-1 is released. This is a release candidate, which means the code is considered production-ready.

Notable changes:

  • NSIS-based installer for Windows. OpenTK is automatically added to the "Add References" dialog - no need to hunt for the dlls manually anymore.
  • New targets for Build.exe: lib (build library), nsis (build installer), all (build everything!) Runtime for a complete build: 26 minutes 7 seconds on a 1.8GHz Core 2 and a 80GB X25-M Intel SSD.
  • Various improvements to behavior on Windows and (especially) Linux. Multithreaded rendering now works as expected.
  • Minor documentation fixes.

Depending on user feedback, a new release candidate may or may not be published in the following days.

Work will now focus on documentation and packaging. If you are interested in helping out, here are some things that would really help:

It is also time to start discussing desired features for the next version of OpenTK. If there were exactly three things that you would like to see in OpenTK +1, what would those be? Here is my list:

  1. Mouse hiding/grabbing without relying on WinForms hacks.
  2. Improved runtime debugging/tracing for OpenGL.
  3. Support for OpenGL 3.3/4.0.


Comment viewing options

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

First and short let me say: Congratz :-)

> Test and provide feedback on the new windows installer.
First installation under Vista without problems, good work. (Win 7 will follow later, perhaps this evening)
Also installed under XP (notebook, 6 year old): all green.

JTalton's picture

Installed great on Windows 7 32-bit. Looking forward to playing with the Multithreaded rendering.
Q: For Linux support is the OpenTK.dll.config still needed or was a way found to wrap that in?

the Fiddler's picture

OpenTK.dll.config is still needed.

aklev's picture

Support for CUDA ... ... ...

nythrix's picture

Support for CUDA ... ... ...

I'm not sure OpenTK is the right library to provide such thing. It wouldn't fit into the "portable" part of the OpenTK philosophy.
Why don't you try out Cloo? It's a wrapper over OpenCL which in turn resembles CUDA quite a lot. It can run on several hw and sw platforms and interops nicely with OpenTK.

the Fiddler's picture

Another vote for Cloo, OpenCL is the future.

That said, a quick search revealed at least one CUDA wrapper that should be usable in conjuction with OpenTK.

aklev's picture

OpenTK+OpenCL+[wrapper CUDA(GPU)] are almost impossible for use ..
In OpenCL there are no functions 2d-FFt and 3d-FFT for multiprocessing video-system, which are very necessary.
OpenTK+OpenCL+FFT is a dream for many programs ...

nythrix's picture

I don't know much about CUDA but I find it a bit hard to believe that FFT is built into the framework. Rather it looks like an extension. In that sense OpenCL can do FFT just as well:
If I were to pour money into this sort of apps I certainly wouldn't deliberately lock myself out of a huge market with the "wrong" HW especially when a comparable, open standard is available. On that basis CUDA is pretty much a dead end.

aklev's picture


You are right, basically...

But it "OpenCL_FFT" works more slowly usual FFT (for example FFTW).
True OpenCL_FFT does not exist yet...
FFT from CUDA in 5 - 10 times faster ...

c2woody's picture

a) Why do you post this in the RC discussion thread which is feature-settled and focuses on bug fixing?
b) Why don't you use the existing CUDA wrappers?
c) If what you call "OpenCL_FFT" (assuming it exists if you can compare its speed against FFTW) is slow why don't you contribute code that optimizes the routines? Surely a lot of people will benefit from your work (especially if it doesn't exist as you hint in your second statement).