Detecting GPU performance

You don't.

You shouldn't try to provide functionality for specific cards, because it's possible that E.g. a 6600 could outperforma a 6800 if it's at a higher clockspeed. Also, what do you intend to do if the users card isn't recognised, or worse - is wrongly identified?
You can use the carious members of the D3DADAPTER_IDENTIFIER9 structure to identify known problems with some chipsets, but it's very rare that you'll need to do that.

You should let the user select the quality level, or monitor the game's FPS and change detail on the fly to adjust.

A possibility would be setting up a database that has the game settings for all the known cards at the time using the name returned at enumeration. If you cover all currently available SM3 cards (for example), you could safely assume that any unknown card that returns SM3 capabilities is newer, and thus would be fast enough. This is of course not always too exact.

Some older games (mostly) had an actual speedtest at the first run, to optimize selection of graphics settings. That could also be a possibility - and if you do it quick (2 seconds), and don't actually Present it, the user would never even know :).

Hope this helps.

You might want to check out the ConfigSystem sample in the SDK. It's a fairly neat way of enabling/disabling features and setting an initial config for different chipsets.

In particular, check out Samples\C++\Direct3D\ConfigSystem\config.txt - its got a list of most of the VendorID/DeviceID's that you can get from D3DADAPTER_IDENTIFIER (as per Steve's post).

hth
Jack

Drivers can also affect performance and even the feature set. Many companies seem to use databases, and I hope the indie community can do a joint project and create one that's free and open someday. Or maybe there is one already?

Quote:

Original post by Jonas B I hope the indie community can do a joint project and create one that's free and open someday. Or maybe there is one already?

DirectX8 one and another one. There have been various caps databases around over the years, but they're rarely as complete or as accurate as you might like - still, better than nothing [smile]

Jack

Again no easy solution.
Well runing the benchmark scene propably will do the job, but
my config screen is before full dx initialization so lots of
problems to solve...

Maybe there is the way to detect how many pixel and vertex processing units
is avaiable?

Thanks

Quote:

Original post by ex9 Maybe there is the way to detect how many pixel and vertex processing units is avaiable?

Nope. Not through D3D, and I very much doubt through the driver directly. That sort of information your application shouldn't need to know.
As Jonas B said, there's other factors that can affect performance. The older ATi drivers are rubbish for example [smile]
You'll just end up basing your performance on what you think the card is capable of, not what the card really is capable of.

The best solution is still letting the user decide what setting to use, or profiling the app when it boots up for the first time. You could maybe use the hardware information you can get as a rough guideline for the default settings, if you're letting the user select the settings, but I wouldn't force them on the user, but then there's no point in going into all the nitty-gritty detail like this.

Example scenario:
Your application detects that the card can do a lot of things, so it puts all the features on and all the details to maximum. The user is using a buggy / developer / old driver, and the game crawls along at 20FPS. Your application doesn't let the user change settings in game, it can only be done by changing settings in a config file. The average user doesn't want to / doesn't know how to mess around in the config file, so uninstalls your game thinking "This game is rubbish, it doesn't run on my super-awesome $3000 PC".

Quote:

Original post by jollyjeffers DirectX8 one and another one.

Cool! But I'd like to add some features:
a downloadable standalone database
and
a lib and source for auto-updating the standalone
and
some simple default benchmarks added to the upload program
and
possibly a moderated system where developers can add tests to the system which will be auto-downloaded by the community and results submitted. Maybe a system where the developer PayPals the testers a dollar or two for each new configuration submitted.

Shouldn't be too hard to write. But would people actually use it if I did?


BTW, I have a hidden Shockwave video-card/RAM detector which, used with the other usual browser-detectable items (screen res, .NET version etc), could gather a lot of useful demographics if placed on a number of sites with different types of users.

I can hand out scripts and provide a community database where this information could be browsable and downloaded.

(Though I'm not sure how it works with the latest patent-secured browsers - if the user has to click some popup to allow activeX components...)

Your post reminded me of a couple of other things...

Quote:

Original post by Jonas B a downloadable standalone database

There's the cardcaps.xls files shipped since the Oct '05 SDK. It covers all the caps for the major chipsets in use today.

Quote:

Original post by Jonas B some simple default benchmarks added to the upload program

As soon as you get into benchmarking territory you've got a whole new set of problems. Validity and usefulness of benchmarks is a very grey area. I think you have to sign-up (or pay), but Futuremark have a comparison database for the 3DMark benchmark software...

Quote:

Original post by Jonas B Shouldn't be too hard to write. But would people actually use it if I did?

Difficult to tell... such a project is only as successful as the number of people using it. You'd need to get a fairly full database in order to keep dragging people back in [smile]

Quote:

Original post by Jonas B BTW, I have a hidden Shockwave video-card/RAM detector which, used with the other usual browser-detectable items (screen res, .NET version etc), could gather a lot of useful demographics if placed on a number of sites with different types of users. I can hand out scripts and provide a community database where this information could be browsable and downloaded. (Though I'm not sure how it works with the latest patent-secured browsers - if the user has to click some popup to allow activeX components...)

Sounds like a good way of doing it, but I don't like the idea of "stealth/hidden" functionality in websites. I quite like the "click here to run/install..." feature in IE6/IE7...

Cheers,
Jack

With those resources available, it's not so important. I'll put it off until a crowd of people is kneeling in front of my door begging me to get on it ;)

I agree in principle about hidden data collection, but with all the stuff everyone's storing anyway today it's not such a long moral stretch. If you don't store the visitors IP/zip code/company/ISP, which many do, I feel it's even less intrusive than the Internet "standard".
And you could put it on a "Help us out" page explaining the information they'll be giving out, before they actually do it.

I think it would be really useful, especially the development over time - how long does it take for certain features to penetrate certain markets? Makes it a lot easier to decide on minimum specs for your next project.