Ageia communique enfin le prix des cartes à base du PhysX, le premier processeur dédié exclusivement à la physique, censé révolutionner la façon dont les joueurs font voler les boites de conserve dans CounterStrike Source ... enfin, si ils ont les moyens de se l'offrir.

Les cartes (uniquement PCI dans une premier temps) devraient en effet s'échelonner entre 249 et 299 $. N'importe quoi. Pour ce prix là, le joueur fortuné aura une puce regroupant presque autant de transistors qu'un Pentium IV, un ventilo supplémentaire dans sa tour pour le fond sonore et 128 Mo de GDDR3 qu'il pourra toujours désouder pour jouer aux osselets. Sortie de la blague prévue au dernier trimestre.

Lire la suite sur le site : Prix nobel de PhysX.

Apparemment ils ont un peu foiré leur présentation de l'E3, ils devaient présenter Bet on soldier acceléré avec cette carte mais les drivers n'ont pas été prêt à temps pour mettre à jour la démo.

Ben si quelqu'un de vraiment calé en architecture PC pouvais m'expliquer comment ce truc marche ...

Je suis un ignorant complet, mais il me semble que pour l'affichage, le proc envoie tout le bordel a traiter à la carte sans se poser de questions. Pour pour la physique, j'imagine qu'il faut un minimum de retour d'information entre la gestion des boites de conserve et le reste du programme, non ? Si tel est le cas, pourquoi faire des cartes PCI et non PCI Express ?

le prix est incensé ?

aktus a écrit :
le prix est incensé ?

Non, du tout. C'est très raisonable d'investir le prix d'une carte graphique moyen de gamme pour faire joujou avec des boites de conserve dans CS:S.

en théorie, c'est censé géré super bien les fluides en temps réel, bientot des simulateurs de surf !

De toutes façons si on continue comme ça, on va aussi avoir des cartes pour gérer l'IA, la reconnaissance vocale... Heureusement le multi-core va nous sauver de ces pompes à fric.

haha bonne chance surtout pour expliquer au grand public qu'il faut claquer au moin 250$ pour faire tomber des tonneaux correctement.

Dans 5 ans dans la Xbox 3 et la PS4 !

Tiens, ça me fait penser à la Voodoo 1, plus qu'une carte gérant l'IA et le CPU aura plus rien à faire.

Niko a écrit :
Ben si quelqu'un de vraiment calé en architecture PC pouvais m'expliquer comment ce truc marche ...

Je suis un ignorant complet, mais il me semble que pour l'affichage, le proc envoie tout le bordel a traiter à la carte sans se poser de questions. Pour pour la physique, j'imagine qu'il faut un minimum de retour d'information entre la gestion des boites de conserve et le reste du programme, non ? Si tel est le cas, pourquoi faire des cartes PCI et non PCI Express ?

C'est une histoire de drivers : le driver, adapté pour la carte, va sous-traiter les informations liées directement au moteur physique. Bien sûr, il faut que les jeux soient prévus pour ça, ou que le prochain DirectX inclue directement les instructions de physique (auquel cas ces instructions seront directement dirigées par le driver sur cette carte).

A propos du port, pas besoin de PCI Express, ce n'est pas une carte qui va faire de l'affichage, mais du calcul. En gros, ce qu'elle va transmettre, c'est des chiffres à virgules flottantes, beaucoup moins lourds que des patés de pixels en 24 bits. Donc une carte PCI fera amplement l'affaire.

Merci pour ces précisions, ekianjo

Ah oui, j'oubliais : si le prochain DirectX gère la physique (ce qui est très probable), les constructeurs comme ATI et nVidia intégreront d'eux-mêmes des proc' spécifiques pour gérer ces instructions dans leurs prochaines cartes graphiques, en plus du chip graphique de base.

Donc l'achat d'une carte séparée pour la physique n'est de toute façon que temporaire. A terme, ça sera comme les shampoings : du 2 en 1.

Alors la jme demande vraiment quelles conventions ils ont choisis pour etre le plus universel possible dans les calculs physiques !
Sur les cartes graphiques, les vertex et pixels shaders permettent maintenant un controle universel et optimum des elements graphiques.. en sera t-il de meme sur les processeurs physiques ? ca serait pas mal du tout d'avoir un equivalent des pixels shaders, mais dédié a la physique..

ekianjo a écrit :
Donc l'achat d'une carte séparée pour la physique n'est de toute façon que temporaire. A terme, ça sera comme les shampoings : du 2 en 1.

Ah non ! Du 3 en 1, tu oublies que depuis la Voodoo Banshee la 2D et la 3D sont dans la même carte :)

Attention, les pixels shaders ne sont que des effets 2d appliqués aux pixels de l'écran, individuellement par rapport aux autres pixels. C'est un "trucage" qui a été inventé pour faire des rendus 3d rapides en image de synthèse - ce n'est pas un véritable effet 3d en soi-même.
Les vertex-shaders, eux, sont de véritables effets 3d appliqués à chaque point de l'espace considéré.

Dans les deux cas, cependant, il s'agit de simples manipulations graphiques. Rien à voir avec du calcul physique, qui lui implique des collisions, des centres de gravité, des déformations, etc...

Les moteurs physiques sont régis de toute façon, par les mêmes lois de base. La physique (des objets solides en tout cas) est déjà, dans les équations, universelle.
Après, ce qui différencie les moteurs physiques actuels de l'un à l'autre, c'est leur manière d'effectuer des approximations. Si les proc' devaient calculer en termes exacts les trajectoires de chaque objet, on aurait même pas une image pas seconde dans un jeu. C'est pour ça que les moteurs physiques actuels ne sont pas "super réalistes". Alors après, il existe différentes techniques pour essayer de se rapprocher le plus possible d'une trajectoire parfaite.

Pour une trajectoire, bon nombre de facteurs sont à prendre en compte :
- la résistance de l'air, différente en chaque point suivant la vitesse relative de ces points
- le poids de l'objet
- la force à l'origine du mouvement
- les frotemments éventuels au sol
- les interactions avec les autres objets, qui induisent une déperdition d'énergie suivant leur caractère élastique ou non (ou entre les deux)

Bref, autant dire que de tels calculs en temps réel sont pour l'instant impossibles. On est bien trop occupés à pousser des polygones pour faire en meme temps du moteur physique de haut niveau.

Et c'est justement l'intéret de ces processeurs dédiés aux moteurs physiques : de faire de moins en moins d'approximations - et de rendre donc l'effet de plus en plus réaliste.

LeChat a écrit :

Ah non ! Du 3 en 1, tu oublies que depuis la Voodoo Banshee la 2D et la 3D sont dans la même carte :)

Non, désolé mais tu as tort depuis DirectX 9. Depuis le 9, la 2D n'existe formellement plus dans DirectX, mais est présentée sous forme de 3D plane, chaque point étant considéré comme un vecteur. On a donc un affichage entièrement unifié. C'est d'ailleurs la merde quand on programme de la 2d au niveau DirectX de base.

Par contre, tu avais raison pour DirectX 7 (et le 8, qui était en fait un 7 très légèrement amélioré).

vi vi jle sais bien :) (je programme en ce moment un moteur 3d qui gere un vrai displacement mapping en temps reel grace aux pixels shaders www.divideconcept.net/d2k4 )

Mais j'entendai par la, peut etre qu'ils arriveront à une architecture similaire, enfin des sortes de bout de codes qui se déclencherait en fonction de collisions par exemple, comme un pixel shader se declenche lorsqu'un pixel doit etre calculé a l'ecran.. Enfin je suis juste curieux de voir comment il vont architecturer ca :) (surtout, comme tu le dis, qu'il existe actuellement une plétore de manières de résoudre les problemes physiques.. donc de la à adopter une methode universelle..)

ekianjo a écrit :
...
Par contre, tu avais raison pour DirectX 7 (et le 8, qui était en fait un 7 très légèrement amélioré).

Eh oui, je me fais vieux... mais j'ai toujours une Voodoo Banshee ( en plus de ma X800 XL, hein :)

divide a écrit :

Mais j'entendai par la, peut etre qu'ils arriveront à une architecture similaire, enfin des sortes de bout de codes qui se déclencherait en fonction de collisions par exemple, comme un pixel shader se declenche lorsqu'un pixel doit etre calculé a l'ecran.. Enfin je suis juste curieux de voir comment il vont architecturer ca :)

[Edité le 25-05-2005 à 00:28 par divide]

Je vois ce que tu veux dire... Cependant il sera nécessaire de calculer les trajectoires indépendamment de l'affichage - si jamais un objet sort du champ de vision et rebondit, il faudra bien qu'une unité de calcul se charge de calculer quand l'objet doit à nouveau être affiché (vu qu'il n'est pas statique). T'en penses quoi ?