Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

AMD se rapproche de Pixelux et Bullet

Pour encourager les moteurs physiques libres

Le 1^er octobre 2009 à 22:06, par raptor70

10 commentaires

32PARTAGES

Voter pour

1

Voter contre

0

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 ?

Vous avez lu gratuitement 6 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

10 commentaires

Commenter Signaler un problème

Membre émérite

Le 02/10/2009 à 8:54

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.

Voter pour

1

Voter contre

0

Membre régulier

Le 02/10/2009 à 15:11

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.

Voter pour

1

Voter contre

0

Expert éminent sénior

Le 02/10/2009 à 15:34

Citation

Envoyé par cyrianox

Voir le message

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..

Voter pour

1

Voter contre

0

Membre émérite

Le 02/10/2009 à 17:18

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.

Voter pour

1

Voter contre

0

Membre éclairé

Le 02/10/2009 à 17:34

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

Voter pour

1

Voter contre

0

Membre émérite

Le 02/10/2009 à 18:15

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.

Voter pour

1

Voter contre

0

Membre actif

Le 04/10/2009 à 15:37

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.

Voter pour

1

Voter contre

0

Membre émérite

Le 04/10/2009 à 17:32

Tu oublie Havok dans la donne

Voter pour

1

Voter contre

0

Membre habitué

Le 23/05/2010 à 3:46

Citation

Envoyé par cyrianox

Voir le message

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.

Voter pour

1

Voter contre

0

Expert confirmé

Le 23/05/2010 à 10:58

Citation

Envoyé par Yno

Voir le message

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.

Voter pour

1

Voter contre

0

Commenter Signaler un problème