Preview : Ageia PhysX

La carte

2 fabricants ont d’ores et déjà annoncé la fabrication de cartes à base de processeur PhysX : Asus et BFG. Asus nous a fait rapidement parvenir une carte que nous avons utilisé pour ce test.



La carte Asus avait été annoncée comme embarquant 256 Mo de mémoire contre 128 Mo pour la carte de BFG. Asus nous a cependant informé récemment que la quantité de mémoire était revue à 128 Mo pour "raison stratégique". Nous avons essayé d’en savoir plus et avons remarqué que la quantité de mémoire n’était plus indiquée dans les derniers panneaux de contrôle d’Ageia et avons été informés que les cartes Asus (tout du moins les premiers lots) seront bel et bien équipées de 256 Mo mais que les 128 Mo supplémentaires ne seraient pas utilisés. Il est donc probable que ce soit Ageia qui ait décidé de ne pas se compliquer la tâche en supportant diverses quantités de mémoire.

La carte est équipée d’un connecteur d’alimentation de type Molex, le bus PCI ne suffisant pas à l’alimenter. Notez à ce sujet que la consommation maximum annoncée est de 28 watts, mais sans test réellement capable de saturer la carte (et/ou de nous montrer que c’est le cas), il est difficile d’évaluer cette consommation en pratique. La carte Asus devrait être disponible rapidement pour un prix qui devrait avoisiner les 300 €.

Les drivers

Les drivers PhysX comprennent 2 parties : le driver à proprement parler et l’API. Le driver, en version 1.0.1.0 n’est pas la partie la plus importante. Il n’évolue d’ailleurs pas réellement au fil des versions. L’élément important, c’est l’API.

PhysX n’est pas réellement une puce programmable en ce sens que les développeurs ne peuvent pas écrire une sorte de physx shader. L’API expose un certain nombre de fonctions qui peuvent être utilisées d’une manière fixe. L’API se charge alors de transformer ces fonctions en programme que le PPU peut exécuter. Les changements apportés à cette API peuvent causer des problèmes puisque certaines fonctions fixes peuvent disparaître, remplacées par d’autres, et leur comportement peut être modifié. Les développeurs doivent donc faire appel non pas à l’API PhysX hardware mais bien à une version spécifique de celle-ci.


Chaque driver PhysX, en plus d’apporter une nouvelle API, contient toutes les Api précédentes. Enfin il est censé le faire. Ce n’est pas toujours le cas puisqu’un développeur peut avoir basé son travail sur une certaine branche de l’API, être tombé sur des bugs et avoir demandé une nouvelle révision de cette branche. Par exemple Bet on Soldier utilise la version 2.4.1 de l’API mais le driver qui l’inclut ne contient pas la 2.3.3 utilisée par Ghost Recon : Advanced Warfighter. A l’installation, le driver ne se contente pas d’ajouter les éléments supplémentaires, mais remplace tout. Autrement dit il n’est pas possible de faire tourner ces 2 jeux avec le même driver et il faut passer de l’un à l’autre ce qui n’est pas très pratique. Heureusement, Ageia a sorti il y a quelques jours une version 2.4.2 qui inclut la 2.3.3 et la 2.4.1. Il faut donc utiliser celle-là et refuser l’installation de celle proposée par ces 2 jeux. Ce système semble difficilement gérable sur le long terme et il est probable qu’Ageia devra revoir l’architecture de son API. Pourquoi ne pas inclure la dll de l’API directement dans le jeu ?


Le panneau de contrôle d’Ageia renseigne sur les versions des API installées, propose une petite démo qui permet de vérifier que le PPU est bien fonctionnel, un outil de diagnostique et un accès vers les mises à jour.

Système de test :

- A8N32 Deluxe
- Athlon FX 55
- 2x 1024 Mo Corsair (CAS2)
- 7900 GTX
- Windows XP SP2