glCapsViewer (and online database)

[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 (.zip, ~460Kbyte)
Version 0.4 - i386 Linux 32 Bit (.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?

[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