Porting a project to OpenGL3

Question

I'm working on a cross-platform C ++ OpenGL application (Windows, Linux, and MacOS), and I wonder if some of you can share tips on porting a large application to OpenGL 3. The reason I look at OpenGL 3 is because I think we could benefit from using the new “synchronization objects”. Nvidia supports this extension with GeForce 256 days (gl_nv_fences), but there seems to be no equivalent functionality on ATI hardware up to OpenGL 3.0 + ...

Our code makes extensive use of the functions glut / freeglut, glu, OpenGL 2 and CUDA extensions (on supported hardware). The problem I'm currently facing is that "gl3.h" and "gl.h" are mutually incompatible (as indicated in gl3.h). Do you guys know if there is an equivalent to GL3? Also, looking at the CUDA-toolkit header files, it seems that GL-CUDA compatibility is only available when using older versions of OpenGL ... (cuda_gl_interop.h includes gl.h ...). Did I miss something?

Many thanks for your help.

Answer 1

The last glut update was version 3.7, about 10 years ago. Given this, I doubt that it will support OpenGL 3.x (or 4.x).

The people working on OpenGlut seem to be considering supporting OpenGL 3.x, but haven't done anything with it yet.

FLTK has a (partial) glut simulation, but it is so inferior that a program that "heavily uses glut" may not work with it in the first place. Since FLTK is under active development, I assume that it will eventually support OpenGL 3.x (or 4.x), but I don’t think it has been provided yet, and there may be an open question how soon it will be either.

Change Regarding CUDA, the obvious (though, of course, non-trivial) answer would be to use OpenCL. This is significantly more compatible with both equipment (for example, ATI / AMD cards) and newer versions of OpenGL.

This leaves glue. Honestly, I do not think there is a clear or obvious answer to this question. OpenGL moves away from supporting things like glu, and instead refuses to support even more vague glu-like functionality that used to be part of the core OpenGL specification (like all matrix manipulation primitives), Personally, I think this is a mistake. but whether it is good or bad, how it all happens. Unfortunately, glu is a bit like oversaturation - the last specification update was in 1998 and complies with OpenGL 1.2. This probably does not do the update. Unfortunately, I do not know of any direct replacements. Obviously, there are other graphics libraries that provide (at least some) similar capabilities, but all of them that I can think of will require substantial rewriting.