Originally posted by kansler: But the version of ati2dvag.dll is the version which ATI uses for it’s driver packages. So it’s usable as a test for current driver version. As stated in the first article of this post, the OpenGL version can be found by using glGetString().
Yes but in the case of ATI, they return the driver version in glGetString after the GL version as ehart said. I find this to be the most simple solution.
A few other vendors do this but NVidia hasn’t.
Are you sure that solution will work on all Windows versions? We know how MS likes to move things around to keep us busy .
According to the source it works with NT, 2000 and XP. I guess, but don’t know for sure, that it will work on 98.
Nope, sorry. I’m running WinME, and I don’t have HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\VIDEO in the registry.
As for the EnumDisplaySettings method, according to my documentation, the dmDeviceName and dmDriverVersion fields are for printer drivers. And besides, if EnumDisplaySettings isn’t even supposed to fill these fields, then its not really a reliable method. Back to square one…
Originally posted by Tom Nuydens: For my Radeon 9000, the version number of ati2dvag.dll (found using kansler’s method) is different from that of atioglxx.dll (the file we’re actually interested in).
– Tom
Is this a problem? I guess it would be a bit nicer to know the ogl version incase a newer driver decided to roll back to a previous ogl driver .dll, but I don’t expect that to happen.
Couldn’t you just use the check the video driver version instead of the ogl driver version since all a user really needs to know is they have an old driver that should be updated. And you still need to do this on a per vendor basis. The only thing is the registry way is “future proof” in the sense that you don’t have to specifically look for nvoglnt.dll, atioglxx.dll, mtxogl.dll, etc incase a vendor decides to rename their file.
Originally posted by Obli: So you had intel integrated (and you said it’s ok), then the 9700 primary and secondary… then a GeForce2? another 9700? Looks strange. Is that really what you installed on your PC in that order?
Yep. I’m pretty sure that those were listed in the order I installed them.
Originally posted by Aaron: As for the EnumDisplaySettings method, according to my documentation, the dmDeviceName and dmDriverVersion fields are for printer drivers. And besides, if EnumDisplaySettings isn’t even supposed to fill these fields, then its not really a reliable method. Back to square one…
i doubt nVidia uses printer driver/hardware for their graphic chips:
Originally posted by Obli:
[b]
Looks that in fact it also update these two and there are the results I am getting:
Device name = NV4_DISP
Driver version = 1025
[/b]
[This message has been edited by matt_weird (edited 06-12-2003).]
There are three reasons you might want to get the OGL driver version rather than the 2D driver version. (None would likely exist in a perfect world, but …)
You are developers. As such you may from time to time have access to special builds from an ihv. The build may have a 2D/3D combination that does not match up with real released drivers.
As I mentioned previously, the dll search path allows a user to over-ride the gl driver installed on the system.
In the past, fan sites have been known to produce their own custom “drivers”. Such a beast is often an install kit that take pieces from multiple different releases.
Now, I don’t think any of these is necessarily enough of a reason to not use the 2D driver version, but you need to be aware of how this mechanism can break.
Originally posted by titan: Yep. I’m pretty sure that those were listed in the order I installed them.
So, they are added in installation order. Nice, we may effectively scan all the keys here and pull out information from the most recent. This is not difficult but it still won’t work in some cases:
1- Titan had a 9700 primary and secondary for a while.
2- I have a Ti4400 but I want to have ViVo and I put in my old permedia2 PCI. This means the most recent driver install won’t be the primary device.
Maybe I can do both the DX poll and the registry poll.
Now, I can use those to parse the window registry so, starting from the most recent and going back I’ll search for the description string, in my case “NVIDIA GeForce4 Ti 4400”. Maybe this will work. Anyone has a way to make this fail?
Originally posted by titan: Yes but in the case of ATI, they return the driver version in glGetString after the GL version as ehart said. I find this to be the most simple solution.
A few other vendors do this but NVidia hasn’t.
I’m not so sure, but I think nVidia does it under linux. I feel being able to detect driver version from GL_VERSION string is bad. The GL spec does not forces vendors to do that and it’s not a widely spread solution.
Everything would be easier if this were supported but unluckly for us, it is not.
We should make sure this feature will be present in GL2!
EDIT: fixed a small typo.
[This message has been edited by Obli (edited 06-12-2003).]
Originally posted by titan: And you still need to do this on a per vendor basis. The only thing is the registry way is “future proof” in the sense that you don’t have to specifically look for nvoglnt.dll, atioglxx.dll, mtxogl.dll, etc incase a vendor decides to rename their file.
The approaches posted by kansler and myself are both vendor-independent – there’s never any need to hardcode the names of the DLLs in your app. However, the difference between my method and kansler’s is that kansler finds the name of the 2D driver, whereas I (try to) find the name of the OpenGL driver. As ehart pointed out, it is possible that these two have different version numbers.
For my particular application (the hardware database at Delphi3D), the distinction is an important one!
What I’d really like to see is a watertight mechanism for figuring out the name of the nvoglnt/atioglxx/… DLL. As pointed out earlier, the method I use at the moment may break down if the user has had multiple drivers installed on the same system, so we need a way to figure out which of the registry entries points to the current driver.
Obli, your suggestions seem like a little too much guesswork to me. Surely there has to be an unambiguous way to figure this out?
– Tom
[This message has been edited by Tom Nuydens (edited 06-12-2003).]
well, EnumDisplaySettings returns the name of 2D driver as well.
Interesting that the version of the particular DLL you’re trying to find doesn’t necessary correspond to a driver version, rather to a build version of that dll. For example, the driver of Radeon9000Pro i have has the version number 5.13.1.6143, meanwhile atioglxx.dll is of 6.13.10.3259 build version(the same is ati3duag.dll universal DirectDraw/D3D), but ati2dvag.dll (2D driver) is 5.13.1.6143 – so THIS file supposed to be of the right version of the currently installed driver, i guess.
[This message has been edited by matt_weird (edited 06-12-2003).]
Originally posted by Tom Nuydens: What I’d really like to see is a watertight mechanism for figuring out the name of the nvoglnt/atioglxx/… DLL. As pointed out earlier, the method I use at the moment may break down if the user has had multiple drivers installed on the same system, so we need a way to figure out which of the registry entries points to the current driver.
A watertight solution would be to enumerate the currently loaded dlls for your program (CreateToolhelp32Snapshot, Module32First and Module32Next). You should check all the dlls for an opengl export function(LoadLibrary and GetProcAddress), for intstance glBegin(). If you find multiple dlls with an opengl export you should discard opengl32.dll. This way, you should end up with the currently rendering opengl dll. GetFileVersionInfo should take care of the rest.
Originally posted by Tom Nuydens: …Obli, your suggestions seem like a little too much guesswork to me. Surely there has to be an unambiguous way to figure this out?..
I don’t know exactly how I got this registry key. However, titan has a lot of video cards around here and I am quite sure I can pull out the correct one by doing the directX poll as stated above.
Yes, I am trying without too much control over it, however, it does not hurt since looks like we are not figuring out a bulletproof way…
Anyway, the query results are definetly encouraging to me. It also works on matrox, nVidia and ATi.
Query results on my system: Video card is a “NVIDIA GeForce4 Ti 4400” running driver release “4.4.0.3” by “NVIDIA”.
So, I cannot get the exact version of the GL driver but I am still quite happy with the number I get since I am using 44.03. This makes everything easier to me.
I just got some very interesting feedback by email. The algo is getting refined.
Now, I am going to pull out info from HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D36E968-E325-11CE-BFC1-08002BE10318}[i]{nx}[/i] where {nx} is the most recent key (in form 0000, 0001…) which has the “driverDesc” field set to the value returned by the DirectX poll. All the most interesting values are still there but now there’s another nice field called “DriverDate” (REG_SZ) set to “2-28-2003”. This is on ATi.
I don’t know how the win registry is structured, but right now, this makes sense to me. The subkey {4D36E968-E325-11CE-BFC1-08002BE10318} is actually hardcoded since it appears to be always the same but you can always parse all the keys here and figure out what it is by looking at the “Class” subfield. I have not found any other subkey with that name.
Thank you everyone for what this is turning out to be! I was having the same problem a week ago or so and this looks very constructive.
EDIT: small thing in the key path.
[This message has been edited by Obli (edited 06-13-2003).]
ok, guys, but maybe i should note this again: EnumDisplaySettings returns the 2D-driver DLL name in the dmDeviceName member, which has the same build version as a driver version. Then next you could retrieve the file version info using GetFileVersionInfo passing only the name string with the extension. But… er… i have some problem to get it to work .Here’s what i ended up with:
so this doesn’t fill out the VS_FIXEDFILEINFO structure, can’t get what’s wrong: both GetFileVersionInfo and VerQueryValue do return non-zero, which means all is OK. Maybe there’s something tricky with lpSubBlock parameter of VerQueryValue. Also tried to specify the filename directly, such as this:
I’m surprised that code doesn’t crash. Obviously you haven’t taken the time to read the manual or even bother to look at warning messages from your compiler. First of all, there is a reason why you get the size of the structure needed, in GetFileVersionInfoSize. Second, in GetFileVersionInfo you pass a pointer to a pointer which is pointing to what?
[This message has been edited by roffe (edited 06-13-2003).]
OK, i got your drift – i must confess that i didn’t read the info about dwLen to the end. Moreover,assuming previous, i thought that lpData recieves the pointer to a buffer already allocated somewhere else – ok, my bad. And that ampersand sign in GetFileVersionInfo – i just forgot to remove it when pasting the code to post it here; i just was trying everything there since the return from that function was non-zero in any case and it still didn’t work as i expected.
So, if now i understand it correctly, it needs you to allocate the memory for the buffer and pass the pointer to it, something like this:
Yick-yacking about the Windows registry and how to do some Windows programming is sure sign of it. I wonder why C++ doesn’t jump in and yell switch to DirectX.
OH NO! Now when you said THAT – throw OpenGL outta the window and get under the desk! 'Coz that dude is already rushing with a light speed to your door!..
…oooops … he was right under your window when you threw OpenGL out Go pick up that unbeatable one – you’ll need it. And… oh yeah, don’t forget to tear that guy off the sidewalk
[This message has been edited by matt_weird (edited 06-14-2003).]
.
Now when you said THAT – throw OpenGL outta the window and get under the desk! 