What I'm interested in learning here is whether or not FM is going to include vendor code paths in its software in the future. I asked Worm about it in his other thread here but so far he hasn't replied. It seems to me a question in need of a definitive answer--because of statements they made earlier about considering such code paths in the future. I can't see how they might ever do that without invalidating all of their other rules and guidelines, but I'd like to hear a declarative statement by them to that effect--one way or the other. My concern is that inclusion of such code paths would move the "optimization" from the drivers into the 3dMk program itself, thereby completely invalidating its results when used to compare differing IHV products. Maybe they said something about this earlier and I missed it. Anyone?
I also think that releasing further recompile patches on a regular basis might be by far the easiest way to prevent driver ident going forward. For instance--if they released such patches quarterly--then it really wouldn't matter whether an IHV built in detection routines for a specific driver, as the next recompile patch would break them. Seems to me that would be *much easier* for them than worrying over and rigorously testing each and every driver the IHVs put out, beta and otherwise. In fact, it seems to me it would be so much easier that if they don't do something like this going forward I'd really like to know why.
In fact, they could parley it into a positive PR spin for the company--and call it something like "Cheat Guard" (TM), "Designed to protect the credibility and impartiality of our software each and every quarter." But really, none of this means anything if they are going to code in vendor paths into the benchmark...I'd really like an answer on that one.