When I build an OpenGL application on Windows 10 I have to link to opengl32.lib. I use GLEW for loading OpenGL functions. GLEW internally uses wglGetProcAddress(). opengl32.lib provides support only for OpenGL 1.1. How does opengl32.lib work when wglGetProcAddress() asks for some newer OpenGL functionality? Does it act as a proxy and communicate with a graphics driver, for example OpenGL nvidia library?
Does it work the same way on Linux?
On Windows you have a so called OpenGL ICD (= Installable Client Driver). Essentially for every function that the OpenGL-1.1 specification defines this ICD provides an implementation proper that's passed through to by opengl32.dll, based on the currently active OpenGL context (i.e. you can have multiple ICDs installed, serving different OpenGL contexts within the same program).
The wglGetProcAddress function is part of that set, which is the reason, why you've to load extending/newer functions for each context separately on Windows. So essentially when you call wglGetProcAddress it will just call the actual ...GetProcAddress of the ICD.
On Linux we never had the concept of ICDs. A couple of years ago we finally got GLvnd (GL vendor neutral dispatch) which essentially gives Linux an ICD like mechanism. However the GLX specification clearly states, that the addresses obtained through glXGetProcAddress are invariant and identical for all OpenGL contexts. That means, that it's the OpenGL implementation's task (and not the intermediary layer between) to dispatch functions based on the context. The Mesa developers describe it here: https://docs.mesa3d.org/dispatch.html
In short: It's a mess.
Related
I'm migrating an OpenGL program over to C++. I have all of the library includes transitioned except for one. In my display function, I have this line (to display text on the screen):
glWindowPos2i(5,5);
This works fine when I run the program as a .c or when I run it as a .cpp in OSX. But I need it to compile as a .cpp on Linux, also. When I go to compile it there, I get this error:
error: 'glWindowPos2i' was not declared in this scope
I can't figure out if this is a missing library or what is going on. Does anyone know what I need to do to get this line to compile?
That is because glWindowPos__ (...) started life out as an extension: GL_ARB_window_pos. It was integrated into core OpenGL in version 1.4.
You are fortunate on OS X to have an implementation of OpenGL that supports OpenGL 2.1/3.2 (in newer versions) out-of-the-box. In Linux, the situation is much different. You have to use the GLX API to load the glWindowPos__ (...) function entry-points at run-time (because they are provided by the display driver).
The easiest way to solve this in all honesty would be to integrate the GLEW library into your build environment for non-OS X targeted builds. You will encounter this same problem in Microsoft Windows, because Windows only ships with OpenGL 1.1 libraries out-of-the-box - display drivers extend it at run-time just as in Linux.
GLEW will take care of loading the function entry-points that are not provided with the shipping OpenGL libraries on both Windows and Linux, and make the whole process painless. Just remember to disable GLEW when you build your software on OS X, it is not necessary and it actually creates more problems if you do link to it in OS X.
I am working with OpenCV, an open source image processing library, and due to complexities in my algorithm I need to use multiple threads for video processing.
How multi-threading is done on C++ 98? I know about C++ 11 has a built in support library for threading (std::thread) but my platform (MSVC++ 2010) does not have that. Also I read about Boost library, which is a general purpose extension to C++ STL, has methods for multi-threading. I also know with MSDN support (windows.h) I can create and manage threads for Windows applications. Finally, I found out that Qt library, a cross platform GUI solution, has support for threading.
Is there a naive way (not having any 3rd party libraries) to create a cross-platform multi-threading application?
C++98 does not have any support for threading, neither in the language nor the standard library. You need to use a third party library and you have already listed a number of the main candidates.
OpenCV relies on different external systems for multithreading (or more accurately parallel processing).
Possible options are:
OpenMP (handled at the compiler level);
Intel's TBB (external library);
libdispatch (on systems that support it, like MacOS, iOS, *BSD);
GPGPU approaches with CUDA and OpenCL.
In recent versions of OpenCV these systems are "hidden" behind a parallel_for construct.
All this applies to parallel processing, i.e., data parallel tasks (roughly speaking, process each pixel or row of the input in parallel). If you need application level multithreading (like for example having a master thread and workers) then you need to use frameworks such as POSIX's threads or Qt.
I recommend boost::thread which is (mostly) compatible with std::thread in C++11. It is cross-platform and very mature.
OpenCV's parallelism is internal and does not directly mix with your code, but it may use more resources and cores than you might expect (as a feature), but this might be at the expense of other external processes.
I am trying to capture images coming from my game using LD_PRELOAD method, by supplying my own library so file that will intercept OpenGL calls. This method works great for simple demo OpenGL code (see this project's file demo.cpp, make.sh, load.sh), however does not work for FPS game UrbanTerror which I thought was using OpenGL. My own supplied function gettimeofday is called properly, however my glXSwapBuffers is not, for some reason. Do these games use OpenGL differently? If so, how? Any tips on how to hook into UrT, and/or another FPS game would be welcome. I am on Ubuntu 11.
Related Question 1
Related Question 2
AFAIK the Quake3 engine (which is used for Urban Terror) implements a custom dynamic OpenGL loader system, i.e. the binary doesn't link against libGL.so directly, but uses dlopen to load libGL.so, then dlsym to retrieve all the OpenGL symbols. To avoid clashes with any directly linked code, all internal symbols are prefixed to "namespace" them.
The LD_PRELOAD environment variable however will have no effect then. To hook into dynamically loaded libraries you'll have to do some major trickery. There are several possibilities. I recommend also intercepting the dlopen and dlsym calls, and for functions you intend to hook into, return your trampoline (which will ultimately call the requested function) instead returning the function pointer directly.
BTW: It's good you asked this question now, as I'm about to write a similar preloading libGL.so as support for a window compositor I'm working on; and I'd probably fallen into the same pitfall.
I want to write some OpenGL 3.2, likely also OpenGL 4 stuff on Linux, and I just saw that libsdl 1.2 (the latest stable release) supports only 2.x. LibSDL 1.3 (which is in development) should support it, but it'll be a while before it gets into mainstream distributions. Is there any library out there right now which allows me to create an OpenGL window with a context of my choice, and preferably also help me with the input?
If not, is there some small library which reduces the pain with Xlib? My Windows path for OpenGL is written with plain-old WinAPI, with own message pump etc., and I wonder if X11 is worse than that. A quick web search indicates that one should use a library above Xlib. I'd be happy with something that just wraps XLib, so I can do the OpenGL context on my own with glX if XLib is really that horrible.
GLFW (GL Framework) supports creating 3.0+ contexts, and has input support, you can read about it on:
http://gpwiki.org/index.php/GLFW
http://www.glfw.org/
Sadly, the main page is down now.
I would like to learn graphics programming with OpenGL. And since I will just start learning it I decided to learn the new/OpenGL3 way of doing things.As far as I can see one has to create an OpenGL 3 context for this (Core profile in the new OpenGL 3.2 if I understand this correctly). Well I thought about using Qt for this, currently using version 4.5.2, since I know it already and like it and it supports creating the OpenGL widget. What I have the problem with is that it looks like the OpenGL widget is always crated with the old OpenGL 2 context and I can't see the option to make it in/switch it to OpenGL 3 way. Am I missing some obvious thing here or do I need something a bit more tricky to create OpenGL 3 context with Qt? Is it even supported in current version of Qt? I'm using Linux, if it makes any difference.
Mesa software rendering is still stuck on OpenGL 2.1. If you're using the binary NVidia drivers they provide OpenGL 3.2 support on sufficiently recent hardware. AMD's latest fglrx supports 3.1. Open Source drivers seem to top out around 1.3-1.4.
If you've gotten this far you'll probably have to hack the Qt sources to use GLX_ARB_create_context instead of GLXCreateContext to get a OpenGL 3.2 Core context.
This guy seems to have had partial success, if you haven't already come across the thread via Google.