Function pointer validity between shared contexts

I am creating two shared contexts, and use the same function pointers (from wglGetProcAddress) for both, which seems to work.
However, as by the wording “address of an OpenGL extension function for use with the current OpenGL rendering context”, if one is being pedantic, this would mean that using the same set of function pointers for two shared contexts is undefined.

On the other hand, using an invalid function pointer during initialisation, such as for getting hold of wglCreateContextAttribsARB or for choosing MSAA pixelformats is well-known “good practice”, and as such seems kind of legitimate even when it is not.
This would suggest that using the same function pointers for two shared contexts (which are basically just two names for the same thing) could be seen as kind of legitimate as well, and should generally work more or less reliably.

Is this assumption correct? Having two sets of function pointers would be totally annoying and a maintenance nightmare, so I’d really like to avoid that if possible.
On the other hand, if it is a reasonable expectation that this will crash and burn on another system, then I may have to go the other route.

It is theoretically possible for function pointers from one context to not work in another. But this could only happen if the two contexts used fundamentally different drivers. Like if you got the NVIDIA driver for one context, but the Microsoft default for the other.

So long as you’re reasonably sure that you’re getting an accelerated context, there won’t be a problem.

What about having Nvidia card + ATI card ?
Does this even works ?

I suppose that won’t as you should use the different function implementations for your NVIDIA and ATI contexts.
Anyway, the question is very good, and I agree with thomas.d that it would be good to know when we can assume that the two set of function pointers are equivalent or not.

What about having Nvidia card + ATI card ?
Does this even works ?

Currently, no. The ICD only allows one installed driver. So you would get either the ATI card or the NVIDIA card.

From wglGetProcAddress info page at wglGetProcAddress function (wingdi.h) - Win32 apps | Microsoft Learn

The OpenGL library supports multiple implementations of its functions. Extension functions supported in one rendering context are not necessarily available in a separate rendering context. Thus, for a given rendering context in an application, use the function addresses returned by the wglGetProcAddress function only.

The spelling and the case of the extension function pointed to by lpszProc must be identical to that of a function supported and implemented by OpenGL. Because extension functions are not exported by OpenGL, you must use wglGetProcAddress to get the addresses of vendor-specific extension functions.

The extension function addresses are unique for each pixel format. All rendering contexts of a given pixel format share the same extension function addresses.

So if you’re using different pixel formats, you will need to deal with multiple sets of function pointers.

If you’re using GLX, the function pointers are context-independent, as the spec for GLX_ARB_get_proc_address contains:

  • Are function pointers context-independent?

Yes. The pointer to an extension function can be used with any context which supports the extension.

Oh duh… I should learn to read better. This last paragraph explains it, thank you. :slight_smile: