PhysX pour des performances massives via GPU ?

Question

J'ai récemment comparé certains moteurs physiques destinés à la simulation et au développement de jeux.Certains sont gratuits, certains sont open source, certains sont commerciaux (1 est même très commercial $$$$).Havok, Ode, Newton (alias oxNewton), Bullet, PhysX et physique intégrée « brute » dans certains moteurs 3D.

À un moment donné, je suis arrivé à une conclusion ou à une question :Pourquoi devrais-je utiliser autre chose que NVidia PhysX si je peux utiliser ses performances étonnantes (si j'en ai besoin) grâce au traitement GPU ?Avec les futures cartes NVidia, je peux m'attendre à de nouvelles améliorations indépendantes des étapes régulières de génération de processeur.Le SDK est gratuit et est également disponible pour Linux.Bien sûr, il s’agit d’un peu de dépendance vis-à-vis d’un fournisseur et ce n’est pas open source.

Quelle est votre vision ou expérience ?Si vous commenciez dès maintenant le développement, seriez-vous d’accord avec ce qui précède ?

acclamations

Answer 1

Disclaimer: Je ne l'ai jamais utilisé PhysX, mon expérience professionnelle est limitée à Bullet, Newton et ODE. Parmi les trois, ODE est loin mon préféré; il est le plus stable numériquement et les deux autres ont des problèmes de maturité (joints utiles non mis en œuvre, les combinaisons moteur / juridique commun d'adopter des comportements non définis, etc.).

Vous avez fait allusion à la question de vendor lock-in dans votre question, mais il vaut la peine de répéter: si vous utilisez PhysX comme solution unique de la physique, les personnes qui utilisent les cartes AMD ne seront pas en mesure d'exécuter votre jeu (oui, je sais que cela peut astreints au travail , mais ce n'est pas officiel ou pris en charge par NVIDIA). Une façon de contourner cela est de définir un moteur de basculement, en utilisant ODE ou quelque chose sur les systèmes avec les cartes AMD. Cela fonctionne, mais il double votre charge de travail. Il est séduisant de penser que vous serez en mesure de cacher les différences entre les deux moteurs derrière une interface commune et écrire la majeure partie de votre code de la physique du jeu une fois, mais la plupart de vos difficultés avec la physique du jeu sera à faire face aux particularités de votre particulier moteur physique, de décider des valeurs pour des choses comme la friction de contact et de restitution. Ces valeurs ne sont pas ont des significations cohérentes dans les moteurs de physique et (la plupart du temps) ne peuvent pas être dérivées formellement, vous êtes tellement coincé trouver bonne mine, les valeurs jouables par l'expérience. Avec PhysX plus un basculement que vous faites tout ce travail de scut deux fois.

À un niveau supérieur, je ne pense pas que les API de traitement flux ne sont pas encore complètement cuit, et je serais réticent à engager à un jusqu'à ce que, à tout le moins, nous avons comment Larrabee de la réaction du client Intel formes de motifs décoratifs.

Jusqu'à présent, de voir PhysX comme le choix évident pour le développement de jeux haut de gamme, je dirais que ce devrait être évité à moins que vous ne pensez pas que les gens avec les cartes AMD représentent une fraction importante de votre base de joueurs (hautement improbable ) ou si vous avez assez de codage et de la main-d'œuvre d'assurance qualité pour tester deux moteurs de physique (plus plausible, mais si votre entreprise est que riche que je l'ai entendu de bonnes choses à propos de Havok). Ou bien, je suppose que, si vous avez conçu un jeu de physique avec les exigences de performance si intense que seule la physique streaming peut vous satisfaire - mais dans ce cas, je vous conseille de commencer une bande et laisser la loi de Moore faire son travail pour une année ou deux.

Answer 2

Une réponse de mise à jour début 2013 :Je développe pour ce que je considère comme les trois grands systèmes d'exploitation :Linux, OS X, MS.Je développe également avec les trois grandes librairies physiques :PhysX, Havok, Bullet.

Concernant PhysX, j'ai récemment fait quelques tests, la dernière incarnation étant la 3.2.2 au moment d'écrire ces lignes.À mon avis, nVidia a vraiment réduit l'efficacité de la bibliothèque.Le plus gros est le manque d’accélération pour les corps rigides.La bibliothèque n'accélère que les particules et les tissus.Même ceux-ci ne s'interfacent pas avec les corps rigides généraux.Je suis complètement intrigué par le fait que nVidia fasse cela, car ils ont une énorme volonté marketing en poussant des applications accélérées par GPU, en se concentrant sur le calcul scientifique avec une grande force motrice étant la simulation physique.

Ainsi, même si mes attentes concernant le roi de la simulation physique étant PhysX, Havok et Bullet dans cet ordre, je vois l'inverse en réalité.Bullet a publié la bibliothèque 2.8.1 avec un échantillon du support OpenCL.Bullet est une bibliothèque relativement petite avec des licences généreuses.Leur objectif est d'avoir la version 3 avec une accélération de corps rigide OpenCL entièrement intégrée.

Une partie des commentaires parle de plusieurs chemins de code.À mon avis, ce n’est pas très grave.Je prends déjà en charge trois systèmes d'exploitation avec une prise en charge minimale du code dur (threading pour la plupart et je n'utilise pas de code spécifique au système d'exploitation ;utilisez les modèles C++ et std lib).Il en va de même pour les bibliothèques de physique.J'utilise une bibliothèque partagée et résume une interface commune.C'est bien car la physique ne change pas grand-chose ;) Vous devrez toujours configurer un environnement de simulation, gérer les objets, rendre les itérations dans l'environnement, nettoyer une fois terminé.Le reste est flash, mis en œuvre à loisir.

Avec l'avènement d'OpenCL dans les bibliothèques grand public (nVidia Cuda est très proche - voir les démos Bullet OpenCL), le travail du plugin physique va diminuer.

Alors, repartir de zéro et uniquement concerné par la modélisation physique ?Vous ne pouvez pas vous tromper avec Bullet.Petite licence flexible (gratuite), très proche d'OpenCL prête pour la production qui sera multiplateforme sur les trois grandes solutions OS et GPU.

Bonne chance !

Answer 3

Vous pouvez trouver cela intéressant:

http://www.xbitlabs.com/news/video/display /20091001171332_AMD_Nvidia_PhysX_Will_Be_Irrelevant.html

Il est biaisé ... il est essentiellement une interview accordée à AMD ... mais il fait quelques points que je pense méritent d'être examinés dans votre cas.

En raison des questions David Seiler a souligné, les moteurs de commutation physique un peu de temps à l'avenir peut être un énorme problème / insurmontable ... surtout si le gameplay est étroitement lié à la physique.

Donc, si vous voulez vraiment la physique accélérée du matériel dans votre moteur maintenant, allez Physx, mais il faut savoir que lorsque des solutions telles que celles postulée par AMD dans cet article sont disponibles (ils absolument mais ils ne sont pas encore là), vous serez confronté à des choix désagréables:

1) Ressaisissez votre moteur à utiliser (insérer le nom du nouveau moteur physique accélération matérielle multi-plateforme), en changeant potentiellement la dynamique de votre jeu dans une mauvaise voie

2) continuer à utiliser PhysX uniquement, tout en négligeant les utilisateurs AMD

3) essayer d'obtenir Physx travailler sur les GPU AMD (Blech ...)

Mis à part l'idée de David d'utiliser un moteur physique du processeur comme solution de repli (faire deux fois le travail et la production de 2 moteurs qui ne se comportent pas de manière identique) votre seule autre option consiste à utiliser la physique pure CPU.

Cependant, comme des choses comme OpenCL devient mainstream nous pouvons voir ODE / Bullet / parents commencent à intégrer cette ... OIEau si vous codez maintenant avec ODE / Bullet / vous pourriez proche parent (probablement finira par) obtenir l'accélération GPU pour « libre » plus tard (aucune modification à votre code). Il va encore se comporter un peu différemment avec la version GPU (un problème inévitable en raison de l'effet papillon et les différences dans la mise en œuvre à virgule flottante), mais au moins vous aurez la ODE / Bullet / communauté kin travailler avec vous pour réduire cet écart .

C'est ma recommandation: utiliser une bibliothèque de physique open source qui utilise actuellement que la CPU, et attendez qu'il se servir de processeurs graphiques via OpenCL, CUDA, la langue de flux d'ATI, etc. Performance sera extrêmement rapide quand cela arrive, et vous vous éviterez des maux de tête.

Answer 4

L'avantage hypothétique des futures cartes de GFX est bien beau, mais il y aura aussi les avantages futurs de cœurs de processeurs supplémentaires aussi. Pouvez-vous être sûr que les futures cartes de GFX auront toujours la capacité de rechange pour votre physique?

Mais sans doute la meilleure raison, mais un peu vague dans ce cas, est que la performance est pas tout. Comme pour toute bibliothèque 3ème partie, vous devrez peut-être soutenir et mettre à jour ce code pour les années à venir, et vous allez vouloir vous assurer que les interfaces sont raisonnables, la documentation est bon, et qu'il a les capacités que vous besoin.

Il peut aussi y avoir des préoccupations plus mathématiques telles que certaines API qui offrent l'équation plus stable résolution et autres, mais je vais laisser un commentaire sur ce à un expert.

Answer 5

Je l'ai utilisé ODE et maintenant avec PhysX . PhysX fait construire des scènes plus facile et (mon opinion personnelle) mais semble plus réaliste, il n'y a pas de documentation adéquate pour PhysX ; en fait guère de documentation du tout. D'autre part, ODE est open source et il y a beaucoup de documents, des tutoriels, etc. PS: L'utilisation accelaration GPU me aide et beaucoup de mes collègues; nous utilisons APEX destruction et PhysX particules.

Answer 6

PhysX fonctionne avec des cartes non nVidia, il ne comprend tout simplement pas accéléré. Le laisser dans la même position, les autres moteurs doivent commencer. Le problème est que si vous avez une simulation physique qui ne peut fonctionner avec une accélération de la physique du matériel.

Answer 7

si tout votre code est massivement paralelizable, alors allez-y!

pour tout le reste, les GPUs sont très insuffisants.