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?
Advertisement
Answer
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.