Discussion :

[raptor70]

AMD se rapproche de Pixelux et Bullet pour encourager les moteurs physiques libres

Comme vous le savez surement, NVIDIA a racheté en 2008 la société AGEIA notamment pour bénéficier son moteur physique nommé PhysX. AMD n'est pas en reste car il travaillait avec Havok pour le support des fonctionnalités physique sur le processeur graphique via l'API OpenCL. AMD vient ainsi d'annoncer qu'ils s'était rapproché de Pixelux Entertainement et de la librairie opensource Bullet Physics.

Les trois nouveaux collaborateurs, au sein de l'Open Physics Initiative vont encourager l'utilisation de moteur physique libre dans le développement de jeux. Ainsi, Bullet Physics intégrera la technologie Digital Molecular Matter de Pixelux (Star Wars : The Force unleashed), le tout utilisant OpenCL. Pour complèter, AMD annonce également le support de DirectX 11 par DirectCompute pour Bullet Physics.

Que pensez vous de cette réaction d'AMD face à Nvidia ?
Le choix de partenariat avec Bullet et Pixelux vous parait-il judicieux ?

[deadalnix]

Il va falloir qu'amd choisisse entre le libre et le proprio.

J'ai comme l'impression qu'ils ont un soucis de ce coté en ce moment (deux pilotes pour linux, divers soutins aux moteurs physiques, etc . . .).

J'ai l'impression que certains chez AMD ont comprit leur intérêt en tant que second à couper l'herbe sous le pied du premier grâce au libre, mais que les actionnaires sont durs à convaincre. Connaissant moi même pas trop mal le monde de l'électronique, je sais à quelle point la PI peut être maladive dans ce milieu.

Il va falloir qu'AMD fasse des choix, sans quoi ça va couter cher.

[cyrianox]

Vous souvenez-vous de l'époque d'avant les cartes graphiques ??
Le processeur était utilisé pour tous les traitements graphiques.
Puis on a eu droit à de nouvelles technologies, 3dfx, powervr etc..., chacun y allant de sa propre librairie (opengl, glide, powervr).
Pour les programmeurs, c'était vraiment la galère, il fallait prévoir des versions des jeux pour chaque carte accélératrice.
Là dessus Microsft nous a pondu directx, interface très sympa permettant aux programmeurs de ne plus se soucier du hardware final, on code pour directx, et celui-ci se charge de balancer du code spécifique aux différentes cartes graphiques, ou même au processeur.
Et voila maintenant qu'on en revient à "chacun sa librairie".
Attention les gars, nous (les programmeurs) risquons d'avoir une grosse charge de travail en plus s'il faut recommencer à programmer des blocs de code différents selon qu'on utilise du nVidia ou du ATI.

[Mat.M]

Et voila maintenant qu'on en revient à "chacun sa librairie".
Attention les gars, nous (les programmeurs) risquons d'avoir une grosse charge de travail en plus s'il faut recommencer à programmer des blocs de code différents selon qu'on utilise du nVidia ou du ATI.

je suis entièrement d'accord avec toi..

[deadalnix]

Je refuse expressément d'utiliser toute techno dépendante d'un fabricant. J'ai pas que ça à faire.

Après, s'il y a un petit détail à changer mais que 95% de reste peut rester commun, ça roule, mais s'il faut faire deux fois la même chose, et bien c'est sans moi.

[Happy]

Si je comprend bien, Bullet pourrait être accéléré par des puces ATI ? Ce serait une bonne idée ?

[deadalnix]

Si c'est que par les puces ATI, ça vaut pas le coup. Si c'est pour du GPGPU en général, ça le fait.

[khazna]

Dîtes moi si je me trompe mais j'y vois ceci:
Si le but est atteint, Bullet sera accéléré sur toutes les cartes compatibles OpenCL, au contraire de PhysX qui n'est accéléré que sur CUDA compatibles.
Et évidemment les développeurs utiliseront alors en masse Bullet, ce qui rendra l'argument marketing PhysX nul pour Nvidia.

Si PhysX se met à utiliser OpenCl pour rester interressant aux yeux des développeurs (et devient accéléré sur les GPUs concurrents, même partiellement) ,l'argument serait presque aussinul: l'accélération ne serait plus limitée à NVidia. Mais PhysX garderait un avantage: les développeurs l'utilisant déjà n'en changeront pas.

Donc, si PhysX ne fait pas le pas OpenCL, ce sera sûrement la mort de la bibliothèque sur le long terme (mais dans l'immédiat resterait utilisable au niveau marketing), si elle le fait, NVidia ne pourra plus autant s'en servir comme argument marketing mais survivra.

[deadalnix]

Tu oublie Havok dans la donne

[Yno]

chacun y allant de sa propre librairie (opengl, glide, powervr).
Pour les programmeurs, c'était vraiment la galère, il fallait prévoir des versions des jeux pour chaque carte accélératrice.
Là dessus Microsft nous a pondu directx, interface très sympa permettant aux programmeurs de ne plus se soucier du hardware final

Je ne comprends pas ton argumentation dans la mesure où OpenGL en l'occurrence est justement une tentative (réussie) de standardisation ? De même pour OpenCL par ailleurs.

[stardeath]

Je ne comprends pas ton argumentation dans la mesure où OpenGL en l'occurrence est justement une tentative (réussie) de standardisation ? De même pour OpenCL par ailleurs.

quand tu regardes les headers opengl, il y a encore pas mal de fonctionnalités dépendantes du fabriquant (tous les suffixes ou préfixes en ATI, NV, etc)
avec les api < dx10, tu as juste à tester si tu as la fonctionnalité disponible, et si c'est disponible tu n'as qu'une seule syntaxe pour l'utiliser.

et maintenant avec >= dx10 tu as un pool de fonctionnalités obligatoires, si tu demandes par exemple un device dx10, tu as forcément TOUTES les fonctionnalités dx10 disponibles.
certes ça ne permet pas d'utiliser les meilleures perfs pour chaque fabricant, mais ça simplifie le travail.


bref pour revenir au sujet, soutenir l'open source c'est bien mais ça manque quand même de support, quand une boite paie plein pot une licence physx ou havok, c'est quand même pour avoir les ingénieurs des moteurs physiques sous la main pour régler les problèmes et/ou optimiser le tout.
ce qui n'a pas l'air d'exister (ou du moins j'ai pas vu) chez bullet.