Drivers XGI, la suite

Suite à la news concernant les bizarreries dans les drivers XGI, nous avons fait quelques essais en modifiant le fichier des drivers XGI afin que les applications ne soit plus reconnues (modification de la chaîne de caractère 3 d m a r k 0 3 . e x e en 3 d m u r k 0 3 . e x e par exemple) puisque le simple renommage de fichier ne permettait pas de contourner la détection. Les résultats sont assez impressionnants, puisque par exemple on passe de 20.6 fps à 8.8 fps dans la scène Mother Nature de 3DMark03 (1024*768, le score global suit la même tendance), ou encore 88.2 à ... 18.7 fps dans le bench BotMatch intégré à Unreal Tournament 2003 (1600*1200). On remarquera que la baisse est toutefois moindre dans notre propre démo, plus réaliste, puisque le score ne passe « que » de 28.6 à 14.6 fps ...

D’où vient cette baisse de vitesse ? D’optimisations spécifiques à ces applications bien entendu. Ces dernières sont peut être multiples, mais la vérification par exemple de l’intégration de clip plane pour les démos (comme NVIDIA dans 3DMar03 à une époque) n’est pas vérifiable sans aide du développeur. Toutefois, nous avons remarqué que lorsque le driver détectait une des applications listées, il désactivait le filtrage trilinéaire pour ne faire que du simple bilinéaire, c'est-à-dire sans aucune transition entre les différents niveau de mip map. Bien entendu cela réduit la charge de travail par deux (interpolation à partir de 4 texels au lieu de 8). En fait étant donné l'importance de la baisse on peut même se demander si le second GPU est bien activé "par défaut" ...

Voici pour illustrer nos propos un screenshot sous Unreal Tournament 2003 avec les drivers d’origines, et un autre screenshot une fois que ces detections sont désactivées :

Nous avons ici utilisé la commande firstcoloredmip pour que les différents niveaux de détails soit colorés afin de bien mettre en évidence la différence au niveau du filtrage.

Pire, sous Halo avec la détection d’origine, la qualité graphique est vraiment déplorable, a tel point qu’on se croirait en 640*480 quand on est en 1024*768, si bien que l’on pense qu’il ne s’agit pas uniquement d’un problème de filtrage trilinéaire. Ce problème est résolu lorsque l’on désactive les optimisations, mais du coup on assiste à un slide show. Il est à noter que la fonction screenshot ne fonctionne pas correctement lorsque Halo est détecté par le driver, ce qui nous empêche de vous faire voir la différence de qualité graphique.

Voilà qui explique donc en grande partie pourquoi dans les benchs courant la Volari s’en sort relativement bien, et pourquoi dans des jeux moins courants pour les benchs mais pas forcément moins joués c’est la catastrophe. Dans notre protocole de test habituel utilisant en majeure partie des jeux non détectés, la Volari Duo V8 Ultra arrivait en effet à 55% des performances d’une GeForce4 Ti 4600, avec dans le meilleurs des cas 77% des performances de cette dernière sous UT2003 et les optimisations spécifiques qui vont avec (40% sans) et 15% de mieux sous Quake 3, puisqu'en OpenGL par défaut et contrairement à ce qui se passe en Direct3D XGI désactive d'office le filtrage trilinéaire et baisse également par défaut le niveau de détail des textures comme vous pouvez le constater en comparant les filtrages d'ATI et de XGI :


Au final, on peut se demander quel est l’intérêt pour XGI d’intégrer ce genre de choses dans ces drivers. En effet, si XGI pense que ses puces ne sont pas assez rapides pour effectuer un filtrage trilinéaire, autant le désactiver totalement des drivers plutôt que de le désactiver que dans certaines applications qui sont généralement utilisées pour mesurer les performances des cartes graphiques. Il ne reste plus qu’à espérer pour XGI qu’il apprendra de ses erreurs et que de futurs drivers viendront corriger le tir et améliorerons fortement les performances comme la qualité afin d'avoir un résultat digne d’une carte à 400 € ...