glCapsViewer (and online database)

[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 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.

[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