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)




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 (.zip, ~960 Kbytes)
Version 0.5 - i386 Linux 32 Bit (.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
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 (.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.