Depuis quelques temps, on trouve les Physic Processing Units, des cartes comme les cartes vidéo, dédiée aux calculs de physiques en temps réel...
À mon avis, ce sera bientôt du matériel indispensable pour tout hard gamer...
À cette vitesse, dans quelques années, on trouvera de la simulation de fluides, de tissus et même de poils dans tout bon jeu qui se respect... Il manque plus qu'une API libre !!
Le site de la carte : http://physx.ageia.com/
Vidéo de démonstation : http://physx.ageia.com/cellfactor_hd.mov
Journal Les PPU !!
27
mar.
2006
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Une idée comme ça ...
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Haypo
[^] # Re: Une idée comme ça ...
Posté par mdlh . Évalué à 2.
Non. Ceci dit, il est pas impossible d'imaginer un tel systeme utilisant NUMA pour l'acces memoire, surtout si les couts de communications entre la carte mere et la carte d'extension sont couteux. C'est d'ailleurs pour cela que les "bonnes" cartes graphiques ont leur propre memoire, plutot que de partager la memoire principale.
Sinon, il y avait les cartes VME dans le principe "extensible". T'as un boitier qui ressemble a un grill comme chez les vendeurs de hot-dog, ou plus simplement comme pour les blades, et tu emboites des cartes:
- CPUs
- Extensions memoires
- Lecteur disquette (oui, ca date)
Chaque carte a un controleur qui dialogue sur un bus temps-reel. Ce fut utilise un temps dans des applications aussi bien industrielles que militaires.
[^] # Re: Une idée comme ça ...
Posté par Sebastien Binet . Évalué à 3.
C'est toujours vachement utilise en physique nucleaire et en physique des particules.
Voila le catalogue si ca t'interesse:
http://www.caen.it/nuclear/product_list.php?cat=fe
http://www.caen.it/nuclear/short_form.php
[^] # Re: Une idée comme ça ...
Posté par Sylvain Briole (site web personnel) . Évalué à 3.
http://www.microsys.de/index.php?l=d&p=Products/VMEbus&a(...)
[^] # Re: Une idée comme ça ...
Posté par or zax . Évalué à 5.
Ca a été abandonné je pense pour des raisons de commerces pour ce qui concerne le marché grand public.
Après il faut réaliser aussi que la bande passante de ton bus pour les extensions n'est pas illimité, donc quand tu rajoutes des composants de calculs ... tu ne peux pas y aller sans fin, tu seras ralenti par ton bus de communication
[^] # Re: Une idée comme ça ...
Posté par ackbar . Évalué à 2.
Si je ne m'abuse, Sun faisait déjà ça il y a quelques années (et doit toujours le faire) avec des cartes d'extensions pour rajouter des CPUs et de la RAM.
Sinon, je suis tombé sur ça (non, je ne fais pas de pub pour le site en question :)) :
http://www.ciao.fr/Carte_processeur_171325_4
PS : après une courte lecture des descriptions des produits, le premier me rappelle les adaptateurs Slot 1/Socket 370 pour Celeron/P3
[^] # Re: Une idée comme ça ...
Posté par Pooly (site web personnel) . Évalué à 4.
[^] # Re: Une idée comme ça ...
Posté par champi . Évalué à -4.
[^] # Re: Une idée comme ça ...
Posté par couriousous . Évalué à 4.
[^] # Re: Une idée comme ça ...
Posté par dawar (site web personnel) . Évalué à 8.
# question technique :
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Autant je comprend comment fonctionne une carte graphique : on peu envoyer directement des instructions à son écran sans que le CPU doivent les calculer. La carte graphique reçoit des inputs sur son BUS et sort sur le connecteur VGA ou DVI.
No problemo.
Mais là ? Comment ça fonctionne exactement ? Qu'est-ce qui différencie des calculs "physiques" d'un autre calcul ? Quels sont les input/output ?
Bref, je suis curieux.
(ceci dit, le jeu de la démo est complètement nul mais j'avoue que ça ouvre des tas de perspectives ultra-intéressantes !)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: question technique :
Posté par agmk . Évalué à 5.
"Physical simulation already exists in games but you need a lot horsepower to do it properly. It requires massive floating point capabilities and collision detection in particular requires potentially massive memory bandwidth. General purpose CPUs have neither of these and are consequently not very good at these simulations. It is for physics and other similar tasks that the processors in next generation games consoles such as the XBox 360 and PS3 have high bandwidth and huge floating point capabilities."
Soit, dans la langue de Molière (qui doit être passablement décomposée d'ailleurs, mais passons) :
"La simulation physique existe déjà dans les jeux mais elle requiert beaucoup de puissance pour être correcte. Elle nécessite une capacité massive en calcul flottant et la détection de collision en particulier réclame une bande passante mémoire potentiellement énorme. Les CPU généralistes n'ont ni l'un ni l'autre, et par conséquent ne sont pas très doués dans ces domaines. C'est pour la physique et les tâches similaires que les processeurs des consoles nouvelle-génération comme la XBox 360 et la PS3 ont une bande passante mémoire élevée et de bonnes performances en calcul flottant."
[ Traduction rapide et approximative (merci au passage à schyzomarijks< pour la traduction de "memory bandwidth" qui m'échappait). ]
Comme le fait remarquer l'auteur, PhysX est très similaire au Cell question concept.
[^] # Re: question technique :
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
bon je peux me tromper, mais pr moi ça marche pareil que pr une carte 3D. Y a pas grand chose qui différencie un calcul d'affichage pr simuler la 3D d'un autre calcul.
Dc tout simplement pour la 3D, on "dit" à notre programme quand on veut qu'il utilise la carte 3D. Pour cela, on va utiliser des standards comme OpenGL (ou bien DirectX, qui n'est pas un standard, sinon de fait). Et les drivers faits par les constructeurs savent utiliser ces standards. Dc à chaque fois que tu utilises OpenGL, tu dis finalement à ton programme de passer par la carte 3D s'il y en a une (ou bien logiciellement sinon). Mais sinon un calcul 3D n'a rien de spécial hein. Tu peux tout à fait faire un prog en 3D sans utiliser OpenGL, et tout calculer "à la main" pour finalement envoyer le résultat de ton calcul à l'écran.
Ben là ça devrait être pareil. Quand on se balade sur le site, on voit que la boîte fournit ce qu'ils appellent le "AGEIA PhysX SDK", lequel doit être connu par le driver de la carte, et dc quand tu veux faire un calcul physique, tu le fais faire à travers l'interface de programmation du SDK fourni, ce qui aura par conséquence de l'envoyer à la carte physique si elle existe.
Maintenant pour moi il manque encore le côté "standard" d'OpenGL comme je le dis ds mon message plus bas. Parce qu'utiliser une norme comme OpenGL, c'est cool, mais si le programmeur doit être conscient de tous les SDK proprio différents fournis par tous les constructeurs... ben c'est infaisable.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: question technique :
Posté par salvaire . Évalué à 1.
Prenons comme exemple, un casse brique pour faire simple.
Le cpu transmet au ppu la position des briques, la vitesse et la direction de la balle. Le ppu calcul en temps réel la dynamique de la balle en fonction de la loi de la gravité et du rebond sur les briques, transmet le résultat en continu au gpu. Quand le joueur interagit le cpu envoi les nouveaux ordres au ppu et au gpu.
On peut aussi imaginer d'utiliser le ppu, comme les vieux coprocesseur mathématiques. Tu charge des registres, appelle une fonction, puis récupère le résultat dans des registres de calcul.
Maintenant, je n'ai aucune idée de ce que fait en réalité cette puce, et comment tu programme ton killer game ...
[^] # Re: question technique :
Posté par Émilien Kia (site web personnel) . Évalué à 3.
Chaque périphérique donne une liste de fonctionnalités qui requiert des paramètre et retourne un résultat, pour l'appeler, tu fous tes paramètres à des endroits précis (registres, mémoire ...) et tu appelles une interruption (en gros). Le matos fais sont chtit bordel dans son coin (en synchrone ou asynchrone) et renvoi un résultat quelquepart.
Tu as juste à utiliser le résultat.
Quand il s'agit d'un modem, pour envoyer un flot de bits, tu lui file le flot de bit et tu lui dit "envoyer".
Quand tu utilise une carte graphique, tu lui passes des points, une matrice, et il te fais la transformation.
Pour la carte PPU, c'est pareil, tu dois pouvoir lui filer, un certain nombre de points et d'objets, et il te dis si les points sont dans l'objet ou pas (détection des collisions par exemple).
Comme tout matériel, tu peux y accéder de deux façon (théoriquement) directement via le système en appelant les interruptions à la main (très lourd, rien ne t'empeche de programmer un jeu 3D-accélérer sans passer par opengl, mais tu vas galérer); ou tu passe par des niveaux intermédiaires (drivers, API ...) où le boulôt pénible est fait à ta place. Pour rappel, l'opengl n'est qu'une surcouche d'appel par-dessus les SDK de chaque carte graphique qui sont eux-mêmes des surcouches des appels matériels vers les cartes.
Un jour libre ?
# Questions sur la normalisation
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
je n'y connais pas grand chose en hardware. Dc corrigez moi si je me plante. Mais en fait, pour une carte graphique, un programme est capable d'accéder à ses possibilités de calcul par une librairie "lien" (des interfaces quoi, finalement des drivers) entre software, et hardware, c'est ça? Et ce sont ces drivers-interfaces qui sont conscients et savent s'interfacer à leur tour avec les librairies graphiques bas niveau (qui sont en gros seulement DirectX (proprio, windows only), et OpenGL (Libre), à l'heure actuelle, n'est-ce pas?).
Et dc là où je veux en venir, c'est d'une part qu'on sait tous ici qu'il est important que les drivers (l'interface software-hardware) doit être Libre, afin qu'il soit facile de connaître l'interface hardware, de modifier et améliorer les drivers (ou bien de le porter rapidement sur d'autres plateformes non officiellement supportées, etc.), et tout simplement de savoir exactement ce que fait un driver, qui est qd même un machin qui s'installe au coeur (kernel) d'un système, et donc potentiellement "dangereux" et tout puissant. D'autre part, il n'existe pas encore de librairie de plus haut niveau que l'interface du driver pour la carte physique (équivalent à OpenGL/DirectX)... A moins qu'il s'agisse du "AGEIA PhysX SDK" qui est annoncé "gratuit" (à l'heure actuelle en tous cas).
Pour moi, cela pose de sérieux problèmes. Si -- comme ils l'annoncent eux-même -- ils sont vraiment actuellement les seuls du marché, et bien il risque rapidement d'y avoir monopole. De là, qui nous prouve qu'ils fourniront toujours leur sdk gratuitement? En outre, gratuit ou non, c'est toujours un danger du seul fait de la non Liberté du SDK pour les dévs, de même que du driver pour les utilisateurs (enfin... à moins que je me plante, mais je ne vois nulle part mention de Logiciel Libre. J'ai l'impression que ce sont des logiciels proprios).
En fait pour que ça devienne intéressant, il faut selon moi:
1/ des drivers Libres, et donc aussi une interface hardware documentée.
2/ une librairie middleware Libre à la place du SDK qui soit une sorte de norme au même titre que OpenGL l'est, de sorte que les drivers soient conscients de cette interface et la supporte.
Se baser uniquement sur le SDK proprio fourni est dangereux (risque de monopole, et d'abus qui s'en suivent), et en plus prépare des problèmes futurs de compatibilité, et donc beaucoup de boulot pour les dévs. En effet, si les librairies physiques existantes (assez haut niveau) décident (intelligemment cependant) de pouvoir utiliser les possibilités d'une telle carte, ils devront s'interfacer avec le SDK proprio. Or si à l'avenir, d'autres entreprises arrivent avec leur propre carte, puis leur propre SDK, etc. ben les librairies physiques haut niveau devront prendre en compte toutes les possibilités hardware, et dc tous les SDK différents. C'est un boulot très chiant qui devrait être fait à un niveau inférieur. Alors que s'il existe un middleware physique bas niveau Libre équivalent à OpenGL, normé, dans ce cas les librairies Physiques haut niveau pourront se baser simplement sur ce middleware, et donc être facilement intéropérable (puisque ce seront simplement aux constructeurs de cartes physiques de faire en sorte que leurs drivers suivent la norme d'interface du middleware Libre et normé, ce qui est bien plus logique et simple. On ne peut pas décemment demander à un développeur ayant besoin de physique de se renseigner sur toutes les cartes physiques existantes, et de toutes les supporter). En gros puisque y aura plein de cartes différentes, de constructeurs différents, etc., il faut bien que le "jeu" (ou bien le programme qui utilise la carte) soit complètement indépendant de la carte présente, qu'il marche quelle que soit la carte physique (comme actuellement qque soit la carte 3D grâce à OpenGL)...
Donc pour moi, ce genre de produit sera bon quand on sera sûr qu'il y ait des drivers Libre et une interface normée.
Ce qui serait très très intelligent de la part de son entreprise, c'est de ne surtout pas jouer le jeu du monopole dès maintenant. Ils sont les premiers, mais ils ne seront sûrement pas les derniers. Dc la chose à faire de leur part, ce serait de créer un mouvement Libre (création d'une fondation par exemple comme bcp le font) pour le développement d'un "SDK Libre et interopérable" pour le calcul physique, où tous les futurs constructeurs de carte physique pourront venir participer afin de faire évoluer ce SDK commun, comme évolue OpenGL à l'heure actuelle ( http://opengl.org/about/arb/overview/ -> liste des contributeurs à OpenGL). Autant faire les choses bien dès le début, sinon les divers constructeurs vont vite se marcher sur les pieds, et ça sera une technologie morte née.
Ensuite si y a des erreurs ds mon argumentation, merci de me corriger. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Questions sur la normalisation
Posté par benoar . Évalué à 3.
Au début on fait chacun ses APIs de son côté, incompatibles (à l'époque pour la 3D il y avait Glide (3DFX), ??? (PowerVR), OpenGL, Direct3D, etc...) et c'est celui qui a le meilleur marketing qui gagne. Après, les concurrents se rangent du côté du gagnant pour pas mourrir.
Bref, je sens que ça va pas être si rose que ce que tu propose...
[^] # Re: Questions sur la normalisation
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
D'un autre côté, ne peut-on pas considérer que nous sommes à une période de l'industrie informatique où les développeurs sont davantage conscients des nécessités de l'intéropérabilité?
Il fut une époque où tout le monde programmait en assembleur. A cette époque, le terme même "intéropérable" ne devait avoir aucun sens. Puis on a commencé à utiliser des langages plus haut niveau, mais comme de toutes façons, il n'y avait pas encore vraiment d'historique important de la programmation, avec des "bons usages de la programmation", ou tout simplement les principes de librairies, de module, en somme de réutilisabilité du code, ben pas non plus grande intéropérabilité...
De nos jour par contre, les programmes sont de plus en plus complexes, imposants, voire inhumains au niveau code. Les programmeurs savent que pour des programmes commerciaux d'envergure (les jeux en sont particulièrement), ils ne peuvent plus se contenter de bidouiller. Il leur faut des bases solides. Ils veulent pouvoir réutiliser le code d'un projet à l'autre. Ils ne veulent pas avoir à réécrire 100 fois les mêmes lignes de code très bas niveau (et donc peu compréhensible après coup). Ils veulent éviter à tout prix d'être dépendant du matériel (à la limite du système d'exploitation, mais carrêment d'éléments disparates de la machine, c'est un vrai bordel!), et donc de réécrire 10 fois plus de code pour la même chose, en fonction du matos. En d'autres termes: les développeurs veulent des briques de bases intéropérables, et réutilisables, ils veulent donc des librairies, et en particulier qui constituent des normes.
A l'heure actuelle, cette boîte est la seule à faire des PPU (à ce que j'ai compris), mais quand il commencera à y en avoir 2, 3, puis 4... à ce moment les développeurs pourraient commencer sérieusement à hésiter à devoir les prendre en compte (car s'ils en prennent un en compte, la question se pose de savoir lequel, et pourquoi pas tous?), étant donné la surcharge multiplicative de travail que cela risque de créer. Je pense sincèrement que le monde du développement de logiciel a évolué, et est moins bordélique qu'à une certaine époque. J'espère avoir raison, et aussi que ces constructeurs de PPU s'en rendront compte. Ce serait bête de reproduire 2 fois de suite la même erreur pour finalement se retrouver au même point d'intéropérabilité, mais quelques années après (donc retard).
Donc d'après moi, je me dis qu'à l'heure actuelle, ce n'est pas la même chose qu'à l'époque des 3dfx, et autres nombreuses interfaces diverses.
Ensuite je peux me tromper. Peut-être les mêmes erreurs vont se reproduire encore et encore... J'en sais rien, on verra bien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Questions sur la normalisation
Posté par kowalsky . Évalué à 3.
compatible Win98, WinMe, Win200, WinXP.
DirectX 9.0c (fournit)
[^] # Re: Questions sur la normalisation
Posté par benoar . Évalué à 2.
Du point de vue du marketteux, le retard de l'interopérabilité des solutions ça veur dire un avantage économique pendant quelques temps (ou alors un cassage de gueule complet, aussi), et donc plein de brouzouffes en plus ! Bref, tu t'es créé ton petit monopole pendant quelques temps. Et après de toutes façons si tu gagne, tout le monde te suivra donc t'auras l'avantage technologique, et si tu perd tu te barre discrètement dans un coin paumé pour que personne te retrouve (mais bien sûr tu laisses les employés dans la merde). Croire que toutes les entreprises "capitalistes" d'aujourd'hui veulent respecter les règles du marché "libre et équitable" c'est oublier qu'elles font aujourd'hui tout pour avoir une position dominante dans leur domaine (quitte à créer son propre domaine, c'est le principe de la différenciation, une des premières chose que j'ai apprise en économie).
Bref, je suis complètement d'accord avec toi sur le fait que ta méthode serait la bonne, que ce serait bien pour tout le monde, je trouve tes remarques très justes. Mais c'est oublier la réalité économique d'aujourd'hui et les buts recherchés par les boites : c'est pas de rendre tout le monde heureux, mais de faire un max de thunes.
Désolé pour le ton pessimiste, mais je suis comme ça en ce moment...
[^] # Re: Questions sur la normalisation
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
Le truc, c'est quand même qu'ils ciblent un marché très précis: les jeux vidéos (même si leur carte pourrait sûrement servir ds d'autres domaines). Or c'est un marché où je pense le travail est immense (par ex, ds un post-mortem de Neverwinter, Bioware annonçait que le jeu avait nécessité 160 années humaines de dév!). Et typiquement pour des progs d'une telle ampleur, surtout quand on en fait plusieurs en parallèles (les grosses boîtes de dév ont svt plusieurs équipes sur plusieurs jeux en cours, et ils enchaînent), ben on veut pouvoir réutiliser la prochaine fois.
Donc s'ils doivent faire un jeu avec un SDK particulier, et qu'ils savent que ds un an, une carte d'un autre constructeur va sortir (surtout si c'est un constructeur majeur), et dc qu'ils devront rajouter le support de cette carte... je suis persuadé qu'ils préféreront pas implémenter du tout dès le début, plutôt qu'être incertain de la viabilité de leur lib à moyen terme... à moins qu'il y ait une norme quelconque des PPU, et qu'ils savent que les nvelles cartes d'autres constructeurs suivront aussi cette norme.
Voilà mon avis. Ils auront peut-être le support de petites boîtes qui ont du mal à avoir une vision d'ensemble, mais les plus grosses boîtes (celles qui vendent vraiment bien) sont -- je pense -- très conscients de ce genre de choses, car ils ont l'habitude des projets de plusieurs années. Et sans ceux-là, leur truc va crever.
Leur seule chance de survie pour moi, c'est que les autres constructeurs qui feront des PPU derrière auront cette idée à leur place, et les inciteront à se réunir pour créer une norme.
Ensuite, je peux me planter, moi je suis pas économiste. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Quel avenir ?
Posté par cortex62 . Évalué à 1.
Le concept est novateur ,certes , mais avant même d' être diffusé il y a déjà de la concurrence: Amd, Intel, Nvidia , Ati (excusez du peu) .
Les processeurs dual-core : 1 noyau pour le rendu 3d, 1 autre le jeu+gestion physique.
Et si ça ne suffit pas , ça sera Nvidia/Ati avec les SLI/Crossfire.
Pensez vous que cette société pourra résister à ce quatuor
[^] # Re: Quel avenir ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je pense que le problème n'est pas là. Cf les cartes 3D.
Le problème, c'est le round-trip cpu -> pci -> ppu -> pci -> cpu hyper lent par rapport à la vitesse du cpu. La carte 3D marche bien car on a un pipeline cpu -> agp -> GPU -> écran.
Donc le PPU doit être bourré de fonctionnalité (comme un cpu) mais en plus, en ayant une puissance de calcul matricielle monstrueuse.
"La première sécurité est la liberté"
[^] # Re: Quel avenir ?
Posté par salvaire . Évalué à 3.
[^] # Re: Quel avenir ?
Posté par cortex62 . Évalué à 2.
# benchmark ?
Posté par Tramoule . Évalué à 1.
J'étais à la recherche d'un test fait par un site genre tom's hardware et je n'ai rien trouvé.
Si quelqun à un lien vers un test de ce cette carte je suis preneur.
Evidemment les jeux actuels n'ont pas été dévellopé pour ce type de carte et donc ne les exploitent surement pas mais je serais quand même curieux de voir si en l'état des choses cela apporte une amélioration.
Si ce n'est pas le cas , je prédit un avenir sombre à ce genre de matériel sur un pc.
Autant sur une console cela aurai un sens puisque les devellopeurs de jeux seraient certain de la trouver de base autant sur un pc j'ai du mal a m'imaginer des boite s'amuser à dévelloper spécialement pour un matériel dont on ne sais absolument pas le taux d'équipement.
# XXX
Posté par Colin Leroy (site web personnel) . Évalué à 10.
Et comme avec Internet, les VHS et les DVDs, l'industrie du porno sera-t-elle la première à utiliser tout le potentiel de cette magnifique technologie? ;-)
[^] # Re: XXX
Posté par salvaire . Évalué à -4.
[^] # Re: XXX
Posté par ackbar . Évalué à 4.
Si c'est douloureux, pense à consulter hein ;)
Enfin remarque, t'as pas précisé pour qui...
Amis de la poésie... -->[]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.