glCapsViewer (and online database)

[Sascha Willems]

What is it?
glCapsViewer is a small tool that reads out all the OpenGL capabilities (limits for basic stuff, shaders, etc. OpenGL extensions, etc.) and stores them away into an XML-file. It also allows you upload these files into an online database, so everyone can check the OpenGL capabilites of your OpenGL implementation.
(Thumbnails, click for bigger view)

http://www.saschawillems.de/images/tglcapsviewer01_screenshot.jpg (http://www.saschawillems.de/images/glcapsviewer01_screenshot.jpg) http://www.saschawillems.de/images/tglcapsviewer_linux.jpg (http://www.saschawillems.de/images/glcapsviewer_linux.jpg)


Why is it?
So from the above paragraph some of you guys, especially those that code apps/games with OpenGL might realize where this is going. A long time ago Tom Nyudens ran a similar database (and a similar tool) on his page and that database was a valuable ressource for all OpenGL coders out there. So my goal (in the long-run) is to do the same again but including all current info. And as this tool uses XML-files for storing data it's easy to adapt to changes/additions into the OpenGL standard. As of now all imporant limits and caps of OpenGL 4.1 are detected and stored.
So my intention behind this little tool was to (again) create an online database for OpenGL-developers to get info on all the different graphics cards out there, as everyone doing OpenGL-stuff (including me) knows that you sometimes can run into odd combinations of capabilites and extensions on especially older hardware.


Where is it going?
As of version 0.5 there is now a real database (SQL) behind the tool, and all reports that are sent will be converted into the database by a PHP script. So now more slow listing of simple XML-reports, but instead fast database listings with much more possibilites like comparing several reports, sorting by different criteria, etc. The long-goal will be to also have that functionality within the application, though the online database is more important as of now.

Where can I get it?
Version 0.5 - Windows 32 Bit (http://www.saschawillems.de/download/glcapsviewer-win32.zip) (.zip, ~960 Kbytes)
Version 0.5 - i386 Linux 32 Bit (http://www.saschawillems.de/download/glcapsviewer-i386-linux.tar.gz) (.tar.gz, ~2.6 MBytes)


How do I use it?
If you start the application it will automatically detect the capabilites of your OpenGL implementation. If you press the upload button that information will be transferred to my temporary database.
Note : Reports for the same renderer/version will be overwritten. So if your graphics card is already in the list there is no need to upload your report. Especially for ATI as the renderer is only identified for a graphics card range. So instead of an entry for a Radeon HD6850 you only get one for the 6800 series. This seems to be different for NVidia e.g. So if you own a Radeon HD68xx with a current driver (like I do) there is no need to upload the report. Note that there are no checks on wether a report is already online or not.


Where are the reports?
The reports can be viewed over here (http://delphigl.de/glcapsviewer/listreports.php)
Note that this is a temporary place for the reports until we have a real database backend up und running. So it's possible that I wipe the directory from time to time, e.g. if I need to make big changes to the fileformat, though that isn't planned to happen yet.

[azrael11]

Thank you sascha... I surerly use it...

[User137]

Well, now i know i can use textures of 16384 x 16384 size :)

[WILL]

Great new tool Sascha. :)

I remember how we had the GLInfo tool when Delphi3D.net was online before. It had a similar DB where you could look up various cards and their capabilities all reported in from the GLInfo tool I assume that this tool is following it it's footsteps?

I'd surely contribute should you make a Mac version for it too. ;)

[Traveler]

Ohh, I can see why this might be useful. I've added my specs.

(btw, I noticed that your program opened half outside my monitor (on the right side). I assume because I use two monitors.)

[Sascha Willems]

Yes Will, that's the exact plan. We've been talking about such a database like the one Tom had back in the days on delphi3d.net for years now over at DelphiGL but somehow the idea never really took off or people couldn't find a common ground to base something like that on. So yesterday i decided to just do it (mostly) on my own. Or at least the first steps. Right now the reports are just listed online, but we're already talking about setting up a SQL database over at the DGL to which the tool will then in the future upload it's reports (instead of the XMLs plainly uploaded to my webspace). That would also mean you can then search and compare the different reports online which is the main goal that I want ot achieve with this : an online database for all the different GPUs out there that can be searched and compared.

And as for a mac port : That would be great, cause we also have a person that would do a linux port so we would have all major operating systems covered. As soon as I finished the basics of the tool I'll release the source so people can port it to different platforms.

@Traveler :
Yeah, that's proably because the form's position is set to desktopcenter. Didn't take multiple screens into account, but thanks for the info, I'll change that for the next release.

[Sascha Willems]

After porting glCapsViewer over to Lazarus (and FPC) I did install ubuntu in a virtual box and made a linux port of it. Though it was kinda hard to get all the stuff done for someone that did never code anything under linux I got around all the hurdles of cross-plattform development and just uploaded a linux port, along with the new windows version (both are now Lazarus/FPC). Tested and working inside the virtual box as well as on a real linux desktop :

Version 0.4 - Windows 32 Bit (http://www.saschawillems.de/download/glcapsviewer-win32.zip) (.zip, ~460Kbyte)
Version 0.4 - i386 Linux 32 Bit (http://www.saschawillems.de/download/glcapsviewer-i386-linux.tar.gz) (.tar.gz, ~2,4MByte)

[WILL]

Excellent! I like where this project is going. Nice work Sascha.

You know what would be useful for most developers using OpenGL? knowing some informative stats that are pulled from all these reports. Maybe throw these on a single page that developers can see and get a good idea of where they stand with the majority of graphics hardware out there.

For example:


number of total reports (to know how many computers/users it has canvased so far)
average maximum texture size for all systems (total & hardware that's < 3 years old)
list of the most commonly accepted version standard within the last # years
Number of ATI users and number of nVidia users
Number and versions of each version of shaders

Any the like... just stats that will give all developers an idea of what is really out there for users hardware what what part of it they will be targeting with their choices of shaders, texture sizes and other specific feature choices a developer might have to make.

I think by doing that you'd be taking it to the next level from what Tom did with Delphi3D's GLinfo. :)

[VilleK]

Great stuff, I will definitely use this.

[Sascha Willems]

Yea, I plan to do statiscs, but e.g. "avg. texture size for hardware older than xxx years" would be really hard to implement. Cause the driver information doesn't include age or release data of the hardware, so I would gather a list of releasedates from the web by myself. But some simple stats (no. of cards per vendor etc.) will come soon.

But first on my list is searching the database (gotta read up on that stuff for PHP, only got very basic PHP skills). So that you will be able to e.g. search for a given extension and all graphics cards that support it are listed. Same with e.g. texture size, so you say "I need a list with all cards that support at least textures of 4096x4096 pixels" and the database will list them. I think that's a pretty important thing for developers and so I'll put priority on this as devs can then quickly check what hardware has what extension etc.

Though I'm still not sure about the database. As I mentioned the reports are XML and are uploaded to the "database" and the PHP scripts just iterate through them (PHP has DOM support, so you can easily get node information from XML). But since I don't really know that much about web development I'm kinda unsure about the load that a search would put on the server. I mean each search for an extension e.g. would make the search script go through all XMLs and check the extension nods for a string. But I think as long as the database doesn't include hundreds of reports that won't be a problem. And yes, I even tried with a real database (SQL), but putting something dynamic and extensible like an XML into a SQL database is nothing trivial, so I'm not sure if it's better to leave it like it currently is with the plain XMLs uploaded and searching through them via PHP.

[phibermon]

Thanks for this Sascha! an incredibly useful tool, even more so as the database grows.

I'm afraid I get an error upon 'Detect caps' :

Invalid object path .

--

XP 64bit SP2, local NTFS volume, No file/folder security issues (admin user), GTX 460 with driver 270.61.

I've extracted the content to a sub-folder and the root of a drive with the same results.

EDIT :

http://zrusin.blogspot.com/2011/04/apitrace.html

This tool allows one to trace GL / D3D calls that are made by an application by utializing pass a through OpenGL32.dll, d3d9.dll etc

Perhaps the output from this tool or somthing similar could be parsed in a such a way that it can be cross-referenced against your database in order to show a developer the cards that support the features they use? statistical techniques could then be employed to highlight extensions that when avoided, provided the greater additional number of suported cards, or to select a card and to highlight unsupported calls and possibly one day provide contextual hints as to unused extensions that may be preferable to those utilized by the app.

If the information is available to use, perhaps statistics from 3D Mark on used cards would provide a useful data-feed to sort functions/extensions by their availability in the wild.

Regarding the searching of the database, even if it contained every card in existance, it probably wouldn't be very big. You could retain an online database but have the app download updated data now and then and do the intensive searches client side, this would help alleviate server load and help avoid possible security holes.

[Sascha Willems]

Could you please post the whole error message (unless "invalid object" is really all that's displayed)? Sounds kinda odd.

But btw. I see you're using XP 64-Bit? Or is that a typo? 64-Bit XP was never a real release and only intended for testing usage, so the problem might come from my function that uses WMI for getting the OS-Name under windows, maybe it's not working with XP 64 bit?

[phibermon]

Yes full error text (other than Press Ok to ignore etc)

You could very well be right. Since I'm the only one that has this issue, it's most likely related to XP 64bit. As it's effectivly not in use it's probably safe to ignore my bug.

I would like to defend XP 64bit however if I may, it's still fully supported (32bit xp had it's support ended, 64bit is still in support cycle) and has a very low memory footprint when compared to vista/7 64bit while still allowing >4gb memory.

It doesn't have the improved scheduling of vista/7 but is used widely in academic institutions as the 64bit windows platform due to it's slight edge in performance and again, low memory footprint. Also a lot of render farms use it for the same reasons.

---

Having said that, yes I know I'm a nutter :) I despise the 7 interface so much, that I only use it for >= DX10 games. Hopefully ReactOS will be my Windows OS one day.

[vgo]

I get the same "Invalid object path" error on Windows 2003 Server x64 too, the GLView (http://www.realtech-vr.com/glview/) tool works so at least it's nothing OpenGL related...

[Sascha Willems]

Well, as I said it's propably related to WMI, which I'm using to retrieve the OS string under windows. It's possible that the needed WMI object is not defined under your os'es.

So I've compiled an exe without the WMI-capturing of the OS name (just commented out), please try and tell me if it works : http://www.saschawillems.de/misc/glcapsviewer_nowmi.exe

If it works for you two I'll see how I can get around this, as I'd like to include the OS string in order to differentiate same driver versions on same GPUs for different OSes and need the OS name for that.

[phibermon]

EDIT : started posting before you posted.

I can confirm that the new executable works on XP 64bit, you were spot on with your WMI theory.

XP64bit and 2003 Server 64bit are so nearly identical that differentiating between the two is probably not needed. You can probably get away with determining 64bit from directives and then checking the system drive for 'Documents and Settings' which I believe is not present on later 64bit Windows.

A bit of a cheap hack I'll admit..

Oh and thank you very much for your time! it is most appriciated

[Sascha Willems]

Thanks for the information phibermon. If possible please refrain from uploading reports until I get this issue fixed, or otherwise your report will be shown with an unkown OS. I'll try to find a way to detect windows OS information on all available systems, and will release an updated version then.

[phibermon]

I actually just had exactly the same thought as my mouse hovered over upload so I didn't.

Windows API function GetVersionEx will do the trick :

http://msdn.microsoft.com/en-us/library/ms724451(v=vs.85).aspx

EDIT :

Page has a table towards the bottom showing factors of windows version from 2000 to windows 7 :

http://msdn.microsoft.com/en-us/library/ms724833(v=vs.85).aspx

Page has C example covering everything from 2000 to 7 (half way down there are updates, bug fix)

http://msdn.microsoft.com/en-us/library/ms724429(v=vs.85).aspx


Thanks again, will wait until next release before I upload.

[Sascha Willems]

I just made a small update to the database :
Added extension search
You can now display only reports that support a given extensions. So if you want to use some special extension, just enter it into the search box and all reports that support it are listed.
Basic stats
Number of reports divided by vendor and os are now displayed.

@Phibermon :
Thanks for the links. Though I'd prefer to have just a simple string with OS and version info returned I'll have a look at those functions to see what I can do to get away from WMI. Though WMI is a very nice thing, cause it even allows you to read out the videocard's memory and much much more.

[Sascha Willems]

Win32-Version updated to 0.4a

I noticed on my second PC that the error message even showed up for a 32-Bit XP. So I dumped the WMI thing completly and replaced it with a simple method that reads out the OS product name from the registry. This should workt better, and at least worked on Vista 64 and XP 32. It woulbe be great if everyone that got the error with the old version could test out the new one and tell me if it works!

Download : http://www.saschawillems.de/download/glcapsviewer-win32.zip

[phibermon]

Yes I can confirm it works, it returns "Microsoft Windows XP" on this system. No indication of 32/64bit but it's probably only worthwhile making the distinction for Vista and 7, there's going to be barely anyone on XP64 and server users will be a minority.

Thanks again for your time on this, such a database will be invaluable to so many people.

I've experimented with APITrace (commented on in my first responce) and it's quite in-depth, it might be a bit of a pain to parse the info (if it was a good idea)

--

Does anybody reading know of any other 'pass-through' tools that log the GL calls made by an application?

[Sascha Willems]

Thanks for your feedback. I'm glad it works, and it was actually not only XP64 that had the problems. Tried in a 32 Bit XP on an older machine and got the same error, so I guess it's best to leave WMI out of the app. And yes, I don't think it's important to know wether the report is from a 64 or 32-Bit machine as the OpenGL capabilities should be the same for the same driver.

And as for logging GL calls, have you tried GLDebugger. It became freeware some time ago and is a pretty in-depth debugger for OpenGL apps.

[Jimmy Valavanis]

Worked fine here, I've uploaded the results!

[vgo]

No OpenGL info is displayed when the program starts and when I click "Detect caps" I get access violation.

[Sascha Willems]

Do you have a driver with OpenGL support installed? A user over at DGL reported the same problem and it turned out he only had the default windows drivers for his card installed, and these don't include an OpenGL ICD. So make sure you have OpenGL driver installed. And if you have them installed could you tell me which OS you're running on and what graphics card you use?

And I'll try to implement hardware support detection for the next version so users without proper OpenGL support won't get crashes or AVs.

[WILL]

Personally, I'd parse all the data into proper fields and have each report it's own record. I'd try to parse specific data from XML into certain fields that would be best for doing queries, such as max texture size, OpenGL supported versions, etc...

Most of your Query work should be done in SQL not in PHP. Let the database do it's job and you'll be happier with the results. The trick is going to be parsing your XML data from the app into proper fields in your records.

I'd save as much data into fields of a record, but also keep a raw copy into a field as a chunk of text. This way you can write a script later on that can re-parse old saved reports in the DB and update to a new and improved database later on with even better statistics that are even more useful to developers than the previous version of your DB. :)

When I was heavy into web development a few years ago I cound the php.net and mysql.com sites' documentation infinitely useful as a reference. Also I'd recommend using phpmyadmin for developing your DB structure. It makes things so much easier than trying to write script that'll create a DB.


Yea, I plan to do statiscs, but e.g. "avg. texture size for hardware older than xxx years" would be really hard to implement. Cause the driver information doesn't include age or release data of the hardware, so I would gather a list of releasedates from the web by myself. But some simple stats (no. of cards per vendor etc.) will come soon.

But first on my list is searching the database (gotta read up on that stuff for PHP, only got very basic PHP skills). So that you will be able to e.g. search for a given extension and all graphics cards that support it are listed. Same with e.g. texture size, so you say "I need a list with all cards that support at least textures of 4096x4096 pixels" and the database will list them. I think that's a pretty important thing for developers and so I'll put priority on this as devs can then quickly check what hardware has what extension etc.

Though I'm still not sure about the database. As I mentioned the reports are XML and are uploaded to the "database" and the PHP scripts just iterate through them (PHP has DOM support, so you can easily get node information from XML). But since I don't really know that much about web development I'm kinda unsure about the load that a search would put on the server. I mean each search for an extension e.g. would make the search script go through all XMLs and check the extension nods for a string. But I think as long as the database doesn't include hundreds of reports that won't be a problem. And yes, I even tried with a real database (SQL), but putting something dynamic and extensible like an XML into a SQL database is nothing trivial, so I'm not sure if it's better to leave it like it currently is with the plain XMLs uploaded and searching through them via PHP.

[Sascha Willems]

Version 0.5 is here along with a real SQL-database
After a crash course in SQL (and PHP) druing the last days (and with some help from Horazont and Frase) I finally got a real SQL database up and running, with all the old reports migrated (so no need to reupload if you did already). So now the database is running atop of SQL, making it much faster and also allowing stuff that the old PHP-parsing-XML-thingy could never do. So for example you can now compare up to 8 reports to get a nice table with all values and the possibility to direclty compare supported extensions, along with a statsitics page listing the number of reports supporting a given extensions.

Though this is just the beginning as I can do a lot more with a SQL running in the background than what could've been done before.

Note that all links are the same, both win32 and linux-i386 versions have been updated, and the database is still here (http://delphigl.de/glcapsviewer/listreports.php)

[Sascha Willems]

Thanks to the help of damadmax (a user from the delphigl.com forums) I can now present a Mac OS X port of glCapsViewer! So with Mac OS X, Linux (i386) and Windows I got the most common operating systems covered and hopefully this tool along with it's database will become a valuable resource for all OpenGL developers out there.

The Mac OS X version is 0.6. It's just a minor fix that stops it from creating a temporary report file for upload and instead directly sends the stream to the server. This was necessary to make it work from a .dmg (which I was told is the preferred way of distributing Mac OS apps) and therefore I changed the version number for the Mac release.


Note that the database now has it's own subdomain, so be sure to use this if you want to access it or link to it : http://openglcaps.delphigl.de/
You can grab the Mac OS X version over here : http://www.saschawillems.de/?page_id=771


Note : I don't have a mac myself and therefore can't compile for it (thanks to Apples stupid policy of not distributing developer libs for it's OS free, at least not afaik). So I would be happy to get some feedback from Mac OS X users wether it actually works or if it's making problems. Though there are already Mac reports in the database so it should work I guess.

[WILL]

I can now present a Mac OS X port of glCapsViewer!

Excellent, I'll be glad to submit my iMac's hardware as well then! That's if it works. ;)

[WILL]

It worked (http://delphigl.de/glcapsviewer/generatereport.php?reportID=65). :) Nice job! Works like a charm, except the App icon is a bit small and looks silly tiny on my system. lol

I submitted a report (and it seems I did so before while running WinXP in Parallels on this system too!) which worked just great. Kudos to whomever did the porting. Maybe they can take a look at one of my game projects I'm trying to port over to Mac just now.

Well if you got it going for Mac, the next logical step is iOS! :D You'd only need a single report from each device, unless you are trying for popularity of hardware.

Oh and don't forget to update your new URL in your downloads page! I noticed it wasn't changed yet. ;)

[Sascha Willems]

Ah great that it worked. Mac OS X reports are coming in, so I guess the tool works fine everywhere. As for the icon, it's out of my hands but I gave damadmax the same Icon that I used for the linux/windows versions, so dunno why it's so small.

And the port was pretty easy, as I mostly prepared it before sending it to damadmax, so he only hat to add a few lines (mostly for getting the OS-version info). And yeah, iOS would be nice too I guess, I'll have to think about that one.

[WILL]

I think it's the case of it being only 16x16 or 32x32. Mac OS X uses a much higher resolution for their icons. That's why they look so much nicer than older Windows I think. Unless he did something to resize it, but that wouldn't make sense. Just try sending him a bigger size icon. 64x64 or 128x128 or 256x256 even should do it.