Typical OpenGL issues under Windows

OpenGL
1

Okay, I’m a bit fed up as this time of writing, so please excuse me if I come out as a bit obtuse.
I’ve been using OpenGL on Windows XP/Windows Vista/Debian/Ubuntu since about 2003.
Using OpenGL on Xorg is a breeze, but there are some issues on Windows which just never seem to go away. First of all, prior Windows Vista, the Windows’ OpenGL reference driver shipped with OpenGL v1.1. Vista seem to ship with v1.4. For the sake of discussion, let’s stick with only Vista and its WDDM.

1.) Why can’t IHVs ship their own OpenGL runtime?
2.) Why doesn’t wglGetProcAddress give me valid function pointers to the OpenGL API calls which are exposed in the OpenGL runtime that ships with Windows? (1.4 API calls and prior for Vista)
3.) Why are function pointers from wglGetProcAddress context dependent on different pixelformats?
4.) Why does the WGL documentation on MSDN still suck after 12 years?

For my first question, see this overview of Vista’s Display Driver Model. IHVs have to implement a usermode display driver, a display miniport driver, and optionally an OpenGL ICD. They are all marked as gray. But the OpenGL runtime is not (opengl32.dll). In my opinion, if IHVs could ship their own runtime, OpenGL would be just as easy to use on Windows as on Xorg.
For my third question, I kind of understand that the extra indirection requires that wglGetProcAddress has to query the ICD driver for the function. But this MSDN page on wglGetProcAddress 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.

So if you change your pixelformat, you might have to fetch the function pointers again, even if you use the same opengl context API call.
AMD’s and NVidia’s binary Xorg drivers expose all the OpenGL API calls in the OpenGL runtime. Where you have to jump through a dozen hops on Windows, you can just define the OpenGL prototypes in Xorg and you’re set. The worst thing that could happen is that the dynamic linker complains over missing symbols and bails. No dummy contexts or GetProcAddress() hell needed. [/end rant]

2

Why can’t IHVs ship their own OpenGL runtime?

They already do. If they didn’t, you wouldn’t be able to use OpenGL at all.

Why are function pointers from wglGetProcAddress context dependent on different pixelformats?

Because that’s how you decide what driver you want. The pixel format is how you communicate what features you want and who you want to provide them.

Why does the WGL documentation on MSDN still suck after 12 years?

Because Microsoft doesn’t care. Besides, what it documents hasn’t changed since OpenGL 1.1.

WGL extensions are not part of WGL core, so the WGL core documentation wouldn’t document them.

In my opinion, if IHVs could ship their own runtime, OpenGL would be just as easy to use on Windows as on Xorg.

No, it wouldn’t. You’d have to search for a .dll, who’s name you would hopefully be able to find on the IHV’s website. That means digging around to find the name of the dlls. And if tomorrow PowerVR comes out with a desktop graphics chip and starts shipping GL drivers, you’d have to modify your application to load their GL implementation.

The ICD model makes all of this unnecessary.

So if you change your pixelformat, you might have to fetch the function pointers again, even if you use the same opengl context API call.

If you could query function pointers once, you can query them again; just call the function you use to get the pointers. Besides, if you get the same renderer, then you don’t have to.

3

[quote]Why can’t IHVs ship their own OpenGL runtime?
They already do. If they didn’t, you wouldn’t be able to use OpenGL at all.[/QUOTE]
opengl32.dll is not bundled with ICDs, it’s an integral part of Windows for some obscure reason, hence me asking. And opengl32.lib is shipped with the Windows Platform SDK, not available from IHVs. If IHVs shipped their own runtime, newer OpenGL calls could be exported directly in the runtime, just as OpenGL 1.1/1.4 calls are currently. This is how it works under Xorg as I mentioned.
Also, under Xorg, only the context creation call matters. That is glXCreateContext and glXCreateContextAttribsARB. You can use dlsym or declare function prototypes directly if you want (I do). The difference between the pixelformats is handled by the driver, not by a dozen different functions for the same API call. Basically, glXGetProcAddress is redundant.

4

opengl32.dll is not bundled with ICDs

It is also not the OpenGL runtime. It is your connection with the implementation-supplied OpenGL runtime.

If IHVs shipped their own runtime

They already do. If you want, you can actually find their .dlls and grab the function pointers yourself.

5

[quote]opengl32.dll is not bundled with ICDs
It is also not the OpenGL runtime. It is your connection with the implementation-supplied OpenGL runtime.[/QUOTE]

Okay, it’s always nice to agree on the terminology :slight_smile:
Still, why does Windows have this context-dependent scheme while Xorg does not? Why is one half of the OpenGL functions only available in the implementation-supplied OpenGL runtime, while the other half is in the ICD driver? Quite frankly, I think it’s a mess.

6

Still, why does Windows have this context-dependent scheme while Xorg does not?

Partially because Xorg is 6 years old, and the OpenGL ICD is about 12 years go. And partially because Microsoft doesn’t care.

Why is one half of the OpenGL functions only available in the implementation-supplied OpenGL runtime, while the other half is in the ICD driver?

Why does this bother you? GLEW is always available for loading OpenGL functions. Just call one function, and you get everything you need.

7

Sorry, I had a brainfart recently. So Windows supports several display drivers at the same time, while Xorg does not. That does still not answer why half of the OpenGL calls from 1.4 are stuck in opengl32.dll however. Fetching them with wglGetProcAddress gives me a NULL pointer, so to get all the OpenGL API calls needed for OpenGL 3.2, I still have to use the prototypes.
My questions were asked out of curiosity behind the WDDM design due to how messy this whole state of affairs is, which I think was pretty well explained here.

As for GLEW, GLEE and similar wrappers, I don’t like them. They are rarely up to date, and they don’t allow for a lot of control on how the context is made or which pixelformat/visual attributes to use(if at all). GLEW still leaves you with that pesky dummy window you need to create, in order to fetch wglCreateContextAttribsARB via wglGetProcAddress.

Thanks for your time :slight_smile:

8

GLEW still leaves you with that pesky dummy window you need to create, in order to fetch wglCreateContextAttribsARB via wglGetProcAddress.

That’s not the fault of glew. That’s the way it is on Windows.
wglGetProcAddress() needs a valid context to work properly because functions pointers returned by wglGetProcAddress() are dependent of the currently bound context. On the contrary, the functions pointers returned by glXGetProcAddress() are independent of the currently bound context.

9

Of course it isn’t GLEW’s fault, I’m simply stating why GLEW doesn’t fit my use.

10

I’m simply stating why GLEW doesn’t fit my use.

It does fit your use. It’s really simple:

1: Create base window and init OpenGL.

2: Get WGL function pointers.

3: Destroy base window.

4: Create actual window with the actual pixel format using the WGL function pointers.

5: Done.

This is how it is. It will not change. So you can either accept it, or stop using OpenGL on Windows.

11

It does fit your use.

You don’t even know what I use OpenGL for, or what I do. Feel free to have an opinion, but don’t pretend you somehow know more about my needs than I do.

This is how it is. It will not change. So you can either accept it, or stop using OpenGL on Windows.

I don’t like the status-quo for OpenGL on Windows, but I sure accept it, since I use it. No need for an aggressive tone.

12

Yes, fetching the GL 1.1 functions with wglGetProcAddress gives you NULL. So, what is your point?

This is why I suggested 8 years ago that a new dll should be created everytime a new GL version was released. Each time, a new DLL name should be given : opengl_1_4.dll, opengl_1_5.dll and a new binder should be created as well (.lib) so that we could get rid of the need for wglGetProcAddress.

Unfortunately, I was naive. There are a lot of compilers and the ARB doesn’t want to complicate their lives. There wasn’t any Wiki, no decent documentation (I didn’t like the spec since it wasn’t a how to manual).

Long story short, GLEW came along and the concept of Wiki came along and I added my contribution to the Wiki and I’m happy.

13

Yes, fetching the GL 1.1 functions with wglGetProcAddress gives you NULL. So, what is your point?

I’ve seen people use wglGetProcAddress and fall back to (LoadLibrary and) GetProcAddress when that fails. GLEW/GLEE is still superior but at least this allows you to work around the <=1.1 and >1.1 function pointer divide.

14

Summary is that you can either work with OpenGL on Windows or work against it. If you’re utterly determined to work against it (or you just want to rant about it) then feel free, but I guarantee you that it’s nothing anybody hasn’t heard before, or dealt with before.

For what it’s worth, the whole wglGetProcAddress thing is not difficult to deal with. It even has the added advantage that you can create your own wrapper around it and fall back on ARB or EXT (or even vendor-specific if you want) entry points (assuming that the baseline function is the same, of course).

Overall though it’s just code you need to write once and keep in your own code library, then update irregularly every time there’s a new version of OpenGL. It’s not like it’s a huge body of work you need to do with every app you make. Create a static lib of your own and do everything in there the way you want it, reuse as required, problem solved, drama over, next.

15

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.