PDA

View Full Version : Picking GL implementation on Windows



*Aaron*
09-23-2002, 01:08 PM
I would like to dynamically (i.e., after the program has started) switch between the MS software implementation and the hardware implementation if present. Does anyone know of some free software that does this? I remember reading something about this on opengl.org's main page, but I can't find it now.

*Aaron*
09-24-2002, 05:27 AM
It can't be that difficult. I just don't understand the windows ICD model. If I get the function pointers from opengl32.dll in the windows\system directory, which functions am I getting? Can anyone help?

zen
09-24-2002, 05:41 AM
I'm not very familiar with win32 but all you should have to do is 1) load a driver dll using win32 api calls and 2) retrieve the function pointers you need.If you get the pointers from opengl32.dll then you get the functions of whichever driver this dll implements.

Bob
09-24-2002, 05:52 AM
The closest you come to picking an implementation, is to look at the pixel format descriptor structure and then choose the pixel format. If the PFD_GENERIC_FORMAT flag is set, you have the MS software implementation. If the PFD_GENERIC_ACCELERATED flag is set, the pixel format is accelerated by the device driver (* see note below). Just enumerate all pixel formats, and choose whichever you want.

Changing implementation during runtime can be tricky. You can't keep your rendering context, and start using another implementation. You will have to destroy the rendering context and recreate it. I'm not sure about this, but I don't think it's possible to set pixel format of a device context more than once, which means you will have to destroy and recreate the window too.

As for the function pointer. Getting a function pointer manually and then call it is the same as calling any other function from a DLL. Either way, the function pointer must somehow be loaded. Either you do it manually, or you let the import library do it automatically for you. So when you call your function pointer, the call will be redirected by opengl32.dll to whichever implementation has the currecntly active rendering context.

(*) By accelerated by a device driver, I mean that the driver for your graphics board can handle this pixel format. It does not mean you have hardware acceleration, but it's a requirement for it.

*Aaron*
09-24-2002, 12:12 PM
zen, opengl32.dll on Windows is always provided by Microsoft, not the hardware vendor. Bob's right: manually loading functions from this DLL would not be any different than static linking; you could still get either hardware or software accelleration depending on the GL resource context. I hadn't thought about this.

Thanks for the info Bob. Do you know if all pixel formats which are supported by the generic implementation are still supported if GL drivers for a video card have been installed? Or is the generic implementation only available for pixel formats for which the accellerated implementation isn't available. I guess I could find this out for myself, but I'm too lazy. http://www.opengl.org/discussion_boards/ubb/wink.gif

*Aaron*
09-26-2002, 02:03 PM
I still don't have an answer to my question about whether driver pixel formats replace generic pixel formats, but I did find something interesting. I found that the generic implementation supports sever high and true color modes. Below is a list of pixel formats supported by the generic implementation of OpenGL on my system when the display mode is set to 32-bit color. I list the number of buts in the various buffers and some other information:

16 RGBA WINDOW BITMAP GENERIC Color:32 Accum:64 Depth:32 Stencil: 8
17 RGBA WINDOW BITMAP GENERIC Color:32 Accum:64 Depth:16 Stencil: 8
18 DOUBLE RGBA WINDOW GENERIC Color:32 Accum:64 Depth:32 Stencil: 8
19 DOUBLE RGBA WINDOW GENERIC Color:32 Accum:64 Depth:16 Stencil: 8
20 INDEX WINDOW BITMAP GENERIC Color:32 Accum: 0 Depth:32 Stencil: 8
21 INDEX WINDOW BITMAP GENERIC Color:32 Accum: 0 Depth:16 Stencil: 8
22 DOUBLE INDEX WINDOW GENERIC Color:32 Accum: 0 Depth:32 Stencil: 8
23 DOUBLE INDEX WINDOW GENERIC Color:32 Accum: 0 Depth:16 Stencil: 8
24 RGBA BITMAP GENERIC Color:24 Accum:64 Depth:32 Stencil: 8
25 RGBA BITMAP GENERIC Color:24 Accum:64 Depth:16 Stencil: 8
26 INDEX BITMAP GENERIC Color:24 Accum: 0 Depth:32 Stencil: 8
27 INDEX BITMAP GENERIC Color:24 Accum: 0 Depth:16 Stencil: 8
28 RGBA BITMAP GENERIC Color:16 Accum:32 Depth:32 Stencil: 8
29 RGBA BITMAP GENERIC Color:16 Accum:32 Depth:16 Stencil: 8
30 INDEX BITMAP GENERIC Color:16 Accum: 0 Depth:32 Stencil: 8
31 INDEX BITMAP GENERIC Color:16 Accum: 0 Depth:16 Stencil: 8
32 RGBA BITMAP GENERIC Color: 8 Accum:32 Depth:32 Stencil: 8
33 RGBA BITMAP GENERIC Color: 8 Accum:32 Depth:16 Stencil: 8
34 INDEX BITMAP GENERIC Color: 8 Accum: 0 Depth:32 Stencil: 8
35 INDEX BITMAP GENERIC Color: 8 Accum: 0 Depth:16 Stencil: 8
36 RGBA BITMAP GENERIC Color: 4 Accum:16 Depth:32 Stencil: 8
37 RGBA BITMAP GENERIC Color: 4 Accum:16 Depth:16 Stencil: 8
38 INDEX BITMAP GENERIC Color: 4 Accum: 0 Depth:32 Stencil: 8
39 INDEX BITMAP GENERIC Color: 4 Accum: 0 Depth:16 Stencil: 8

Based on the variety of generic GL formats available, I would guess that they are all still available regardless of what the driver supports. I posted this in case it might be useful to someone else.

Edit: Here's what all of that mess means:
DOUBLE = double buffered
RGBA/INDEX = RGBA/color index mode
WINDOW = can draw to window
BITMAP = can draw to bitmap
The number at the beginning of each line is the pixel format index. These will not be the same on every system.


[This message has been edited by *Aaron* (edited 09-26-2002).]

zen
09-26-2002, 02:33 PM
So if I understand this correctly the opengl32.dll is just a wrapper of some sort?Why do they have to make everything more complex than it has to be?Anyway the point is that there must somewhere exist some dll with the driver implementation.If you load it and use its functions you should be all set up right?I remember that there were a bunch of of dlls (something like voodoo.dll,powervr.dll etc.) lying around in the Quake 2 dir and the engine just loaded one based on what the user had selected.Q3A also chooses the library to link to at runtime at least in linux.
In any case thought the above method wouldn't go well with the user-friendly windows style.The user would have to specify the dll himself or you would have to guess which might be even worse.


[This message has been edited by zen (edited 09-26-2002).]