Initializing WGL Extensions

Hello,

I’ve been fiddling around with WGL extensions lately (and also GLX extensions under Linux), mostly pbuffers and render-to-texture, and I have a question regarding the initialization of these extensions.
AFAIK, under Linux glXGetProcAddress is context independent, whereas wglGetProcAddress is not. So under Windows, every render context needs its own extension procedure table. So far so good.
But are all the WGL extensions also context dependent? Let’s take WGL_ARB_pixel_format for example. It’s kind of sick that you have to create a rendering context in order to query the extension procedures for it (since the extension is actually meant to be used for creating a rendering context). Since it’s perfectly fine with WGL_ARB_pixel_format to create a dummy window + RC and then destroy it after getting the procedures, I guess that WGL_ARB_pixel_format is context independent. But does that hold true for the other WGL extensions as well?
What I’d like to do is, create a dummy window + RC at engine startup, initialize the WGL extension procedure table, destroy the dummy window and context again and be done with it.
But is that legal?

Thanks for any advice.

I’m not sure if I understand. With WGL_ARB_pixel_format, you need to create a window and RC to query for pixel formats, which is context independent.

That has nothing to do with function adresses to begin with.

As for wglGetProcAddress, you need to consider the thread I beleive. In the same thread, you should be getting the same addresses. I’m not entirely certain, but if you get different addresses, then it would be weird. I’m talking about all the gl functions here.

Why not experiment and post your findings?

V-man

Originally posted by V-man:
[b]With WGL_ARB_pixel_format, you need to create a window and RC to query for pixel formats, which is context independent.

That has nothing to do with function adresses to begin with.[/b]

Well, it does, because I could have created any context + window (using a pixel format supported by the ICD, of course), and would have gotten the same function addresses. And I can even use those function pointers when there is no current context. Therefore, the function pointers returned by wglGetProcAddress for WGL_ARB_pixel_format are context independent.
My question is, is that true for other WGL extensions, such as WGL_ARB_pbuffer, where the function addresses could actually also be context independent.

Originally posted by V-man:
As for wglGetProcAddress, you need to consider the thread I beleive. In the same thread, you should be getting the same addresses.

That would be nice. But if you strictly follow the wglGetProcAddress documentation, it could actually happen that you get a different function address for every context you create. Or you don’t get any function address at all, because a particular context does not support an extension, whereas other contexts do.

Under GLX, with glXGetProcAddress, however, you always get the same function address, independent of the current context. But you must make sure by calling glGetString that a certain extension is available for the current context. IMHO, this design is much cleaner for applications.

It’s really dumb that wglGetProcAddress and glXGetProcAddress are defined differently regarding context dependence. Another reason why I really don’t like extensions.

Anyway, I’ll do some experimenting today and see how it goes. Still, it’s probably safer to get the function pointers for each context separately (following the documentation to wglGetProcAddress). Of course, I guess that most drivers will probably return the same function addresses for most WGL extensions anyway…

BTW, is there something like WGL_ARB_render_texture in GLX? Couldn’t find anything in the extension registry.
Or is my only option to use pbuffers + glCopyTexImage.

Regards.

Alright, I did some testing, and on my GeForce2 Pro with the 29.42 drivers it seems as if the WGL extension function addresses are context independent.

What I do is, create a dummy window with the first ICD pixel format I can find, then create a dummy context, make it current and use wglGetProcAddress to get the function addresses (in my case now for WGL_ARB_pixel_format, WGL_ARB_pbuffer and WGL_ARB_render_texture). Then I destroy the dummy context and window but keep the function addresses. Later on I create some more render contexts + windows and a pbuffer, and can use the retrieved function pointers without any problems.

Cheers

I don’t know how up to date my current docs are but MSDN says

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

and also

“Extension functions supported in one rendering context are not necessarily available in a separate rendering context.”

THe second one doesn’t make sense unless you are talking about a software mode. The first one should be taken seriously for sure.

I would be careful with multithreaded opengl because if memory serves me right, you do get different addresses.

V-man