Search code examples
windowswinapiopenglwgl

OpenGL 1.0 and 1.1 Function Pointers on Windows


I'm a bit confused about the nature of OpenGL 1.0 and 1.1 function pointers on Windows. I think I have it down, but I'm not 100% sure, so I'm hoping that someone will be able to confirm or comment on my current understanding:

My understanding at the moment is that you're supposed to load 1.2+ functions with wglGetProcAddress(), but that 1.0 and 1.1 function have to be loaded with GetProcAddress() through opengl32.dll. What catches my attention, however, is that wglGetProcAddress() supposedly returns different function pointers depending on which HGLRC context is current. Yet presumably the 1.0 and 1.1 pointers from GetProcAddress() are always the same. This disparity in behavior feels unusual.

So, let's say that I have a situation where I have multiple HGLRC objects, we'll call them A and B. I call wglGetProcAddress() and I keep the results in separate pointer pools, one for A and another for B. Yet I also have to load 1.0 and 1.1 functions into these pointer pools, and in this case it seems that the pointers for A and B will always be the same.

What surprises me is that the 1.0 and 1.1 functions must therefore be thin wrappers which redirect OpenGL calls to whichever driver is associated with the current HGLRC. Yet if such a redirect mechanism is already in place on Windows then I wonder why wglGetProcAddress() can't also use it, because doing so would alleviate the danger of it returning context-dependent pointers. I don't necessarily even need to know the answer to this question, but the very presence of the question is what makes me wonder whether or not I understand things correctly at all to begin with.


Solution

  • The reason for this is a simple one: The symbols for OpenGL-1.1 are a fixed set, so the interface DLL opengl32.dll can contain both the fallback implementation and the trampolines into the full blown OpenGL implementation provided by the graphics driver (ICD). Those symbols are exposed by the interface DLL in the symbol table and hence are reachable with GetProcAddress.

    Anything that goes beyond version OpenGL-1.2 is unknown to the interface library. Hence opengl32.dll does neither contain fallbacks nor trampolines into the ICD for those functions. Instead it acts as a proxy that passes the call to wglGetProcAddress to the actual OpenGL implementation in the graphics driver (ICD). However since different OpenGL contexts may be served by different graphics drivers (ICD) the result may be symbols residing at different addresses. wglGetProcAddress does not look at the symbol table of some DLL but may be implemented in whatever the ICD sees fit.